코드는 멀쩡한데 결과가 틀렸다: 2026년 트러블슈팅을 바꾼 다섯 편의 논문

장애를 다뤄본 사람은 안다. 가장 무서운 것은 서버가 죽는 일이 아니다. 죽지 않고 틀린 값을 계속 내놓는 것이다. 로그는 깨끗하고, 알람은 안 울리고, 코드 리뷰를 아무리 돌려도 잘못된 줄이 없다. 그런데 결과가 이상하다.

2026년 7월 시애틀에서 열린 OSDI 2026에는 이 문제를 정면으로 다룬 논문이 유난히 많았다. 게다가 상당수가 학회가 따로 표기하는 “Operational Systems” 트랙 — 즉 실제로 시스템을 운영하는 회사의 엔지니어가 자기 장애 이력을 들고 나온 논문이다. 바이트댄스, 마이크로소프트 애저, 화웨이, 알리바바가 각자의 현장을 열어 보였다.

이 글은 그중 다섯 편을 골라 트러블슈팅 방법이 어떻게 바뀌고 있는지를 정리한다. 기법 소개보다 중요한 것은 이 논문들이 공유하는 사고방식이다. 요약하면 이렇다. 추론을 줄이고, 비교를 늘리고, 모를 때는 모른다고 말한다.

장면 ①. “코드는 멀쩡했다” — GPU가 조용히 틀린 값을 낼 때

첫 번째는 상하이교통대와 바이트댄스 Seed의 「SDCs in the Wild」다. 프로덕션 클러스터에서 건져낸 SDC 결함 GPU 23장을 해부한 논문이다. SDC(Silent Data Corruption)는 하드웨어가 오류 신호 없이 틀린 값을 내는 현상을 말한다.

논문에서 가장 아픈 문장은 기법 설명이 아니라 현장 묘사다. 엔지니어를 괴롭히는 것은 오류의 빈도가 아니라 모호함이라는 것이다. GPU의 SDC는 갑작스러운 크래시나 손실 급등처럼 나타나는데, 이건 소프트웨어 버그나 수치 불안정과 겉모습이 완전히 똑같다. 그래서 엔지니어는 본능적으로 코드를 먼저 의심하고, 며칠에서 몇 주를 파이프라인을 쪼개며 보낸다. 하드웨어 결함이라는 결론은 대개 다른 모든 가설이 소진된 뒤에야 나온다.

논문이 든 실제 사례 두 가지가 이 함정을 잘 보여준다.

• MoE 학습 중 shape mismatch 크래시. 토큰 개수를 집계하는 연산에서 SDC가 나서 버퍼 크기가 조용히 틀어졌고, 예외는 한참 뒤 다른 줄에서 터졌다. 터진 자리의 코드는 정상이었다. 오류 메시지가 진짜 원인을 가리키지 않는 전형적인 경우다.
• 같은 체크포인트에서 시작한 10번의 재실행. 1번에서 손실이 튀었고, 2번에서 재현됐다. 그런데 3·4번은 멀쩡했다. 5·6번에서 다시 튀었는데 이번엔 완전히 다른 스텝에서 튀었다. 코드 버그라면 논리적으로 같은 지점에서 실패한다. 실패 지점이 매번 다르다는 사실 자체가 하드웨어를 가리키는 단서였다.

규모 데이터도 인상적이다. 메타는 16,000장 GPU 학습에서 약 2.78시간마다 하드웨어 장애를 겪었고 그중 1.4%가 GPU SDC였다고 보고했다(라마 3 405B 학습은 54일간 16,384장에서 419건의 예기치 못한 중단을 기록했고, 절반 이상이 GPU와 HBM3 문제였다). 구글은 TPU 클러스터에서 1~2주에 한 번 SDC를 관측한다고 밝혔고, 바이트댄스는 3개월 동안 6,096건의 암묵적 오류를 기록했다.

그리고 업계 표준 대응책 — 전 GPU에 합성 스트레스 테스트를 도는 방식 — 은 결함 장비의 60% 이상을 놓쳤다. 이유는 특성 분석에서 나온다.

• 수명 주기 전체에 걸쳐 나타난다. 번인 단계에서 잡힌 것은 25%뿐이고, 40%는 배포 1년쯤 지나서 나타났다. 제조 불량이 아니라 누적 열화이고, 한번 시작되면 오류율이 점점 올라간다.
• 데이터와 유닛에 의존적이다. 일반 테스트는 통과하는데 특정 커널·특정 입력 범위에서만 틀린다. 흥미롭게도 FP32·FP64 CUDA 코어가 텐서 코어보다 더 자주 틀렸다. 고정밀 연산 유닛이 물리적으로 크고 복잡해서 결함이 드러날 확률이 높다는 설명이다.
• ECC와 온도 센서에 안 걸린다. 메모리 오류가 아니라 연산 로직의 비트 오류이기 때문이다.

그래서 이 논문의 진단 시스템 SDCHunter는 합성 벤치마크를 버리고 문제를 터뜨린 그 워크로드와 그 데이터를 그대로 재생한다. 재현 확률이 100%인 GPU도 있지만 100만분의 1 수준인 GPU도 있어서, 일반 테스트로는 애초에 잡힐 수가 없다.

방식은 2단계다. 먼저 클러스터를 데이터 병렬 축으로 두 복제본으로 갈라 같은 배치를 먹이고 파이프라인 경계에서만 텐서 해시를 비교한다(오버헤드 3%). 두 복제본의 서명이 갈리는 지점을 몇 시간 안에 찾아 해당 구간을 빼고 학습을 재개한다. 그 다음 의심 그룹과 정상 그룹을 결정적으로 재생하며 모든 중간 텐서의 서명을 비교해 처음 갈라지는 텐서와 커널을 찾고, 그 자리에서 결함 장비로 역추적한다.

핵심은 복구와 디버깅을 분리했다는 점이다. 학습은 한 시간 안에 재개되고, 결함 GPU 확정은 오프라인에서 별도로 한 시간 안에 끝난다. 배포 이후 지금까지 40건의 SDC 사고를 처리했고, 진단 시간은 며칠에서 한 시간 아래로 내려갔다.

이 모든 것의 전제는 결정적 실행이다. 시드를 고정하고, 결정적 커널을 강제하고, 통신 순서를 표준화한다. 흔히 “결정성은 성능을 깎는다”고 믿지만, 이 논문의 프로덕션 측정에서는 스텝 타임 차이가 0.01% 이내였고 정규화한 디버깅 시간은 70% 줄었다.

장면 ②. 두 실행을 비트 단위로 맞춰본다

같은 문제를 다른 각도에서 푼 것이 미시간대와 바이트댄스 Seed의 OpGuard다. 여기서 나오는 사건 하나가 이 분야의 난이도를 압축해서 보여준다.

1,000장 GPU로 돌리던 비전-언어 모델 학습에서 3,000스텝이 지난 뒤 그래디언트 노름 알람이 울렸다. 숙련된 개발자들이 닷새 동안 실험을 반복하고, 플래그를 껐다 켜고, 커널을 바꿔 끼웠지만 진전이 없었다. 진짜 원인은 임베딩 backward 커널의 아주 작은 레이스 컨디션이었다. 드문 토큰 패턴에서 몇 개 행이 틀어졌고, 다음 스텝의 forward가 그 오염된 가중치를 읽어 텐서 병렬 그룹 전체로 퍼뜨렸다. 손실 곡선이 눈에 띄게 갈라졌을 때는 이미 대부분의 GPU가 오염된 텐서를 들고 있었다.

여기서 문제는 도구가 없어서가 아니다. 개발자들은 정상 실행과 버그 실행을 비교하고 있었다. 다만 비교 대상이 손실과 그래디언트 노름 같은 집계 지표였다. 수백만 개 연산의 결과를 하나로 뭉친 값이라 오류가 희석되고, 갈라진 것을 봐도 어디서 갈라졌는지를 알려주지 않는다.

OpGuard의 제안은 단순하다. 비교를 비트 단위로, 그리고 훨씬 이른 지점에서 하자는 것이다. 두 실행을 모델 수준 연산 경계의 시퀀스로 보고, 대응하는 경계의 텐서가 비트까지 동일한 최장 접두사를 계산한다. 그 다음 첫 번째로 어긋나는 경계가 곧 두 실행이 최초로 갈라진 지점이고, 그것이 디버깅의 축이 된다. 앞의 사례에서 손실 차이는 3080스텝까지 정확히 0이었고 3081스텝에서 -1.0014e-05로 벌어졌다 — 사람 눈에는 노이즈처럼 보이는 값이지만, 비트 비교에는 명백한 경계다.

어려운 부분은 “양성 비결정성”을 걷어내는 일이다. 스케줄이나 커널 구현이 달라도 의미가 같은 지점을 찾아 지문을 뜨고, 무해한 차이를 오류로 오인하지 않게 통제한다. 그래야 첫 불일치가 곧 오류의 증거가 된다. ByteDance의 사전학습·후속학습 워크로드에 배포돼 20건이 넘는 프로덕션 문제를 진단했고, 기존 검사가 놓친 커널 레이스와 SDC가 포함됐다. 디버깅 시간은 며칠에서 몇 분으로 줄었다.

장면 ③. 감지는 가볍게, 확증은 파이프라인 빈틈에서

칭화대와 바이트댄스의 AEGIS는 같은 SDC 문제를 사후 진단이 아니라 상시 감지로 접근한다.

지금까지의 선택지는 셋 다 불만족스러웠다. 오프라인 진단 도구는 학습을 멈춰 세우고 제한된 테스트만 돌린다. 재실행 비교는 확실하지만 계산을 두 번 하는 셈이라 이 규모에서는 감당이 안 된다. 알고리즘 기반 온라인 검출(체크섬류)은 이론적으로 매력적이지만, 저정밀 연산에서는 체크섬 불일치가 보통의 부동소수점 오차에 묻혀버린다.

AEGIS의 해법은 검출을 두 단계로 쪼개는 cSensor–cVerifier 구조다. cSensor는 학습과 함께 돌면서 아주 가볍게 “수상함”만 감지하고, 나중에 확인할 최소한의 맥락을 붙잡아 둔다(프레임워크가 그 상태를 덮어쓰기 전에). 확증은 cVerifier가 맡되, 파이프라인 버블처럼 자연히 노는 구간에 검증 작업을 밀어 넣는다. 즉 감지는 임계 경로 위에, 확증은 임계 경로 밖에 둔다.

저정밀 문제는 하드웨어 특성으로 우회했다. 현대 GPU의 텐서 유닛이 고정밀로 누산한다는 점을 이용해 혼합 정밀 체크섬을 쓰면, SDC와 정상적인 수치 오차를 구분할 수 있다.

결과는 3,500만 GPU 시간 규모의 프로덕션 배포에서 SDC 사고 18건과 불량 GPU 13장을 찾아냈고, 성능 오버헤드는 0.86%였다. 상시 감지를 1% 미만의 비용으로 붙일 수 있다는 것이 이 논문의 실질적인 메시지다.

장면 ④. 프로파일러가 거짓말을 하고 있었다

네 번째는 성격이 다르다. 화웨이 컴파일러 팀과 토론토대·YScope의 「When Sampling Lies」다. 대상은 클라우드가 아니라 스마트폰(하모니OS)이지만, 교훈은 프로파일러를 쓰는 모든 사람에게 해당된다.

사건은 이렇게 시작한다. 엔지니어들이 ARMv8.1의 LSE 명령을 활용해 명령어 수를 줄이는 최적화를 넣고 확인차 perf를 돌렸다. 그런데 perf는 명령어 수가 6%, 약 9천만 개 늘었다고 보고했다. 실행마다 수치는 흔들렸지만 “늘었다”는 방향은 일관됐다. 엔지니어들은 그 결과를 믿고 몇 주 동안 원인을 찾아 헤맸다.

범인은 최적화가 아니라 측정 도구였다. 원인은 스키드(skid)와 섀도 효과의 결합이다. 현대 프로세서는 카운터가 넘친 바로 그 명령에서 PMU 인터럽트를 정확히 걸지 못하고, 조금 뒤의 명령에 샘플이 붙는다(스키드). 여기까지는 무작위 잡음이다. 그런데 지연이 긴 명령이 재정렬 버퍼를 막으면 스키드 창이 좁아지면서 샘플이 그 명령 쪽으로 쏠린다. 하필 이 최적화가 짧은 명령 여러 개를 긴 원자적 명령 하나로 바꾼 것이었다. 그래서 perf는 일관되게, 그리고 완전히 틀린 값을 냈다.

논문이 적어둔 문장이 인상적이다. 팀은 “perf의 출력을 믿을 수 없다”는 것을 고통스러운 경험으로 배웠고, 존재하지 않는 문제를 쫓느라 몇 달을 썼다고 쓴다. 더 무서운 시나리오도 언급한다 — 실제로는 성능을 떨어뜨리는 최적화가 잘못된 측정 때문에 프로덕션에 배포될 수도 있었다.

문제는 이뿐이 아니었다. 수명이 짧은 함수가 수천 개 있고 뚜렷한 병목이 없는 평평한 프로파일에서, perf는 최고 샘플링 레이트에서도 함수의 62%만 커버했다. 그리고 고빈도 샘플링 자체가 시스템을 흔들어 L1 데이터 캐시 미스를 최대 46배까지 늘렸다.

대안으로 만든 Blink는 인터럽트를 버리고, 함수 진입·종료 같은 지점에서 PMU 카운터를 직접 읽는 계측 방식이다. 스키드와 섀도 효과가 설계상 사라진다. 비활성화 상태에서는 점프 명령 하나만 남도록 자기 패치 방식으로 바이너리를 고쳐 오버헤드를 눌렀다. 결과는 명령어 수 측정 정확도 99.999%, 사용자가 체감하는 프레임 드랍 증가 1% 미만. 무엇보다 perf로는 안정된 결과를 얻으려고 50회 이상 반복 실행해야 했던 측정이 1~2회로 끝난다.

여기서 가져갈 교훈은 도구 이름이 아니다. 모든 관측 도구에는 오차 모델이 있고, 그 모델이 워크로드와 만나는 지점에서 체계적으로 틀릴 수 있다는 것이다. 무작위 잡음은 반복으로 지워지지만, 체계적 편향은 반복해도 지워지지 않는다.

장면 ⑤. “모르겠다”고 말할 권리 — 기권하는 RCA

다섯 번째가 개인적으로 가장 흥미롭다. 애저의 네트워크 RCA 시스템을 다룬 「The Abstention Protocol」이다.

대형 클라우드 네트워크는 항상 어딘가 고장 나 있다. 스위치 수천 대짜리 클러스터라면 CRC 오류가 나는 케이블, 오르내리는 링크, 업그레이드 중인 TOR 스위치가 늘 있다. Clos 토폴로지는 경로가 많아서 이런 결함을 흡수하고 트래픽은 계속 흐른다. 문제는 사고가 났을 때 생긴다. 고장 신호를 보이는 장비가 수십 개인데 그중 대부분은 이번 사고와 무관한 배경 잡음이다.

논문의 이 문장이 온콜을 서 본 사람에게는 뼈아프다. 갓 투입된 온콜 엔지니어는 카운터와 프로브만 봐서는, 이 신호가 지금 조사 중인 사고의 것인지 아니면 언제나 조용히 일어나고 있는 수십 개의 무관한 결함 중 하나인지 구분할 수 없다.

게다가 이런 장애는 대부분 fail-stop이 아니라 그레이 페일러(gray failure)다. 광 모듈이 헐거워져 한 방향 링크에서 패킷 2%를 흘리거나, 라인카드의 비트 플립이 특정 ECMP 경로로 해시되는 흐름의 헤더만 망가뜨리거나, 펌웨어 버그로 스위치가 재부팅됐다가 헬스 모니터가 눈치채기 전에 복구되는 식이다.

기존 시스템은 신호마다 점수를 매겨 가중합이 가장 높은 장비를 범인으로 지목했다. 이 방식은 예측 가능한 방향으로 실패했다. 배경 결함이 늘 점수를 조금씩 보태기 때문에 네트워크에 죄가 없을 때도 범인이 나왔고, 한 장애 유형의 오탐을 줄이려고 가중치를 조정하면 다른 유형의 오탐이 늘었다. 오탐률은 18~22% 사이에서 통제되지 않았다.

새 시스템 CoreSec의 발상은 이 문제를 점수 문제가 아니라 조합 문제로 본 것이다. 어떤 텔레메트리도 모든 장애 유형에 대해 믿을 만하지 않다. 능동 프로브는 링크 장애를 빨리 잡지만 소프트웨어 결함을 놓치고, 장비 카운터는 하드웨어 열화를 잡지만 잡음이 많고, 트래픽 기반 신호는 고객 영향을 반영하지만 커버리지가 성기다.

그래서 CoreSec은 리눅스 인증 모듈(PAM)의 구조를 빌려 온다. PAM이 비밀번호·생체인식·하드웨어 토큰 같은 독립적인 검사에 각각 required·sufficient·optional 플래그를 달아 조합하듯, 각 텔레메트리 에이전트에 requisite / required / sufficient / optional 플래그를 붙여 조합한다. 그리고 결정적으로, 결과에 정상·비정상 말고 세 번째 값을 둔다.

증거가 없거나 서로 충돌하면 시스템은 기권(abstain)한다.

이 한 가지 설계 결정의 효과가 숫자로 나온다. 애저에서 3년간 70만 건이 넘는 사고를 처리하면서 오탐률이 18~22%에서 1% 미만으로 떨어졌다. 팀은 기권을 관대하게 다루지 않고 명시적인 미탐(false negative)으로 계산했는데, 그 비율도 초기 10%에서 최근 6개월 1.5%까지 내려갔다. 수작업 RCA로 정규직 세 명분의 일이 사라졌다.

자동화된 진단이 신뢰를 잃는 이유는 대개 답을 못 내서가 아니라 틀린 답을 자신 있게 내서다. 모르는 경우를 “모른다”고 표시할 수 있으면 나머지 답의 신뢰도가 올라가고, 그제서야 사람이 그 결과를 실제로 쓴다.

덤. 평소엔 얕게, 이상할 때만 깊게

알리바바와 상하이교통대의 StriaTrace는 LLM 추론 서비스의 트레이싱을 다룬다. 학습과 달리 추론은 지연에 민감해서, 산발적인 이상 하나가 곧 SLO 위반이다. 그런데 기존 프로파일러는 오버헤드가 10~20%라 상시 켤 수 없다.

세 가지 원칙이 명료하다. 동기화 지점만 추적하고(CPU 계측 지점을 함수 1,000개 규모에서 10개 규모로 줄였다), 임계 경로만 추적하고, 이상할 때만 자세히 추적한다. 그 결과 트레이싱 오버헤드를 97.8% 줄이면서 수백 건의 이상을 진단했고 19가지 서로 다른 근본 원인을 정리했다.

관측성 예산을 평평하게 쓰지 말고 적응적으로 쓰라는 이야기다. 평소에는 얕게, 이상 징후가 있을 때만 깊게.

다섯 장면을 관통하는 세 가지 원리

기법은 제각각이지만 밑에 깔린 원리는 세 개로 모인다.

첫째, 추론 대신 비교다. 다섯 편 중 세 편이 “두 개를 나란히 놓고 어디서 갈라지는지 본다”는 같은 뼈대를 쓴다. 이게 가능하려면 실행이 재현 가능해야 한다. 그래서 결정성은 이제 연구용 사치가 아니라 디버깅 인프라의 전제 조건이다.

둘째, 신호를 일찍, 그리고 날것으로 잡아야 한다. 손실 곡선이나 평균 지연 같은 집계 지표는 이미 수백만 번의 연산을 하나로 뭉갠 뒤라, 오류가 희석되고 위치 정보가 사라진다. 비트 단위 지문, 텐서 서명, 동기화 지점 같은 것이 뭉개지기 전의 신호다.

셋째, 도구의 한계를 모델링한다. 프로파일러는 스키드로 틀리고, 점수 기반 RCA는 배경 잡음으로 틀린다. 두 논문 모두 도구를 더 정교하게 만드는 대신 틀리는 방식 자체를 설계에서 제거했다 — 하나는 인터럽트를 없애서, 하나는 “모르겠다”를 출력으로 인정해서.

우리 조직에서 당장 할 수 있는 것

수만 장 GPU가 없어도 옮겨올 수 있는 것들이 있다.

1. 재현 스위치를 미리 만들어 둬라. 시드 고정, 결정적 커널·라이브러리 경로, 고정된 통신·처리 순서를 평소에 켤 수 있게 해두는 것. 사고가 난 뒤에 만들면 이미 늦는다. 성능 걱정은 측정으로 확인할 것 — 앞의 논문에서는 스텝 타임 차이가 0.01% 이내였다.
2. 레퍼런스 실행을 확보하라. “정상이던 마지막 버전”을 같은 입력으로 돌릴 수 있는 상태로 유지하는 것만으로 비교 기반 디버깅의 절반이 끝난다.
3. 비교의 해상도를 올려라. 평균과 합계로 비교하지 말고, 체크섬·해시·지문 같은 뭉개지지 않는 값을 경계마다 남겨라. 갈라지는 첫 지점을 찾는 것이 목표다.
4. 도구의 오차를 문서화하라. 쓰는 프로파일러·APM이 어떤 조건에서 체계적으로 틀리는지 팀 위키에 한 페이지로 정리해두면, 다음에 이상한 숫자를 봤을 때 몇 주를 아낀다.
5. 자동 진단에 “모르겠다”를 넣어라. 알림·RCA·이상탐지 어디든, 증거가 부족할 때 억지로 범인을 지목하지 않게 하는 것. 그리고 기권율을 성과 지표로 함께 추적하라 — 애저 팀이 기권을 미탐으로 계산한 이유가 그것이다.
6. 관측성을 적응적으로 쓰라. 상시 트레이싱은 얕게, 이상 신호가 뜨면 그 구간만 깊게.

조심해서 읽을 것

이 논문들은 대부분 초대형 환경의 이야기다. 수천 장 GPU, 수만 대 스위치, 수억 건 요청 규모에서 의미가 있던 트레이드오프가 작은 환경에서 그대로 성립하지는 않는다. 결정적 실행의 비용도 워크로드마다 다르고, 프로덕션에서 0.01%였다는 수치는 그 환경의 값이다.

성과 숫자도 자사 환경에서 자사 시스템을 평가한 값이라는 점을 감안해야 한다. 의미 있는 것은 절대 수치보다 실패 방식의 구조다 — 합성 테스트가 왜 결함을 놓치는지, 집계 지표가 왜 오류를 희석하는지, 점수 기반 판정이 왜 배경 잡음에 무너지는지. 이 구조는 규모와 무관하게 반복된다.

마지막으로 하나. 다섯 편 모두 자동화가 사람을 대체한다고 말하지 않는다. SDCHunter는 학습 재개와 하드웨어 확정을 분리해 사람이 기다리는 시간을 줄였고, CoreSec은 애매한 건을 사람에게 넘기려고 기권을 만들었다. 좋은 트러블슈팅 도구의 목표는 답을 대신 내는 것이 아니라 사람이 확실한 것부터 처리하게 만드는 것에 가깝다.

⚠️ 이 글이 다루는 논문은 모두 OSDI 2026(제20회 USENIX 운영체제 설계·구현 심포지엄, 2026년 7월 시애틀) 발표작이며, 수치는 각 논문이 보고한 값이다. 대부분 자사 프로덕션 환경에서 자사 시스템을 평가한 결과이므로 다른 환경에 그대로 이전되지 않는다. 메타·구글의 장애 통계는 각 논문이 인용한 공개 보고 값을 재인용한 것이다.

자주 묻는 질문

SDC(Silent Data Corruption)가 정확히 무엇인가요?

하드웨어가 어떤 오류 신호도 내지 않고 잘못된 계산 결과를 내놓는 현상입니다. 프로그램이 죽는 크래시나 하드웨어가 감지해 알려주는 오류(DUE)와 달리 아무 경고가 없어서, 학습 손실이 튀거나 엉뚱한 예외가 터지는 형태로 뒤늦게 드러납니다. 원인은 우주선(cosmic ray) 같은 환경 요인, 설계·제조 결함, 그리고 시간이 지나며 진행되는 회로 열화입니다. OSDI 2026 논문에 따르면 GPU SDC는 배포 초기보다 오히려 1년쯤 지나 나타나는 비중이 컸습니다.

결정적(deterministic) 실행을 켜면 성능이 많이 느려지지 않나요?

통념과 달리, 해당 논문의 프로덕션 측정에서는 스텝 타임 차이가 0.01% 이내였고 정규화한 디버깅 시간은 70% 줄었습니다. 다만 이는 특정 환경(대규모 LLM 학습, 정해진 병렬화 구성)의 값입니다. 결정성의 비용은 어떤 비결정성을 제거하느냐에 따라 달라지므로, 도입 전에 자기 워크로드에서 스텝 타임을 직접 재보는 편이 안전합니다. 중요한 것은 필요할 때 켤 수 있게 준비해두는 것입니다.

perf 같은 샘플링 프로파일러를 이제 쓰면 안 되나요?

그렇지 않습니다. 뚜렷한 병목이 있는 워크로드에서는 여전히 훌륭한 도구입니다. 문제가 되는 것은 짧은 함수 수천 개가 고르게 시간을 나눠 쓰는 평평한 프로파일이고, 특히 지연이 긴 명령이 섞이면 스키드와 섀도 효과가 결합해 결과가 체계적으로 편향됩니다. 이때는 반복 실행으로도 오차가 지워지지 않습니다. 측정 대상이 1~2% 수준의 개선이라면 계측 기반 도구로 교차 확인하는 편이 안전합니다.

기권하는 RCA는 결국 “답을 안 준다”는 뜻 아닌가요?

반대에 가깝습니다. 애저 사례에서 기권을 도입한 뒤 오탐률이 18~22%에서 1% 미만으로 떨어졌고, 답을 낸 건의 신뢰도가 올라가면서 실제 운영에 쓰이게 됐습니다. 핵심은 기권을 공짜로 두지 않는 것입니다. 그 팀은 기권을 명시적인 미탐으로 계산해 함께 추적했고, 그 비율도 10%에서 1.5%까지 낮췄습니다. “모르겠다”가 성과 지표에 포함될 때만 이 설계가 건강하게 작동합니다.

소규모 서비스에도 적용할 만한 게 있나요?

가장 비용이 낮은 것부터 세 가지를 권합니다. 첫째, 정상이던 마지막 버전을 같은 입력으로 재현할 수 있게 해두는 것. 둘째, 평균과 합계 대신 경계마다 체크섬이나 해시 같은 뭉개지지 않는 값을 남기는 것. 셋째, 알림과 자동 진단이 증거가 부족할 때 억지로 범인을 지목하지 않게 하는 것입니다. 셋 다 대규모 인프라가 필요 없고, 사고가 났을 때 아끼는 시간은 규모와 무관하게 큽니다.