당신이 고친 그 파일, 실제로 실행되는 게 맞나

디버깅에서 가장 허무한 순간은, 몇 시간 고치고 테스트해 "됐다!" 했는데 — 그 코드가 실제로는 실행되지 않는 걸 깨달을 때입니다. 프로덕션은 다른 경로로 돌고 있었던 거죠. 이 함정을 피하는 원칙이 "프로덕션 경로로 검증하라"입니다.

테스트한 것 vs 실제 도는 것

도식 렌더링 중…

흔한 함정 두 가지:

• 런처 파일 ≠ 실제 실행 경로 — 편의를 위해 만든 launch 스크립트를 고쳐 테스트했는데, 프로덕션 dispatch는 그 스크립트를 안 거치는 경우. 고친 게 안 도는 겁니다.
• 편집본 ≠ 설치본 — 소스를 고쳤지만, 실제로 실행되는 건 빌드된 설치본(복사본)인 경우. 소스 변경이 반영 안 됩니다. (게다가 묵은 바이트코드 캐시가 옛 코드를 붙들고 있으면 더 헷갈립니다.)

⚠️ "내 PC에선 되는데"의 뿌리 — 이 격차가 "내 환경에선 되는데 프로덕션에선 안 됨"의 근원입니다. 테스트 경로와 프로덕션 경로가 다르면, 테스트는 프로덕션에 대해 아무것도 보장하지 않습니다. 둘을 일치시키는 게(dev/prod parity) 신뢰의 전제입니다.

원칙 — 진짜 입구로 들어가라

💡 검증은 프로덕션 진입점(예: API)을 통해서 — 러너를 ssh로 직접 띄워 테스트하면 편하지만, 그건 오케스트레이터·워커·RuntimeConfig를 우회하는 가짜 경로입니다. 실제 사용자가 거치는 입구(POST /runs 같은)로 똑같이 들어가야, 그 결과가 프로덕션을 대변합니다. 편한 우회로는 빠르지만 거짓 안심을 줍니다.

검증에도 레벨이 있다

"됐다"고 말하기 전에, 어느 수준에서 됐는지 구분해야 합니다.

레벨	의미
L0	코드가 존재/빌드됨
L1	단위 테스트 통과
L2	프로덕션 경로로 E2E 실제 동작
L3	출력(영상·데이터) 눈으로 확인

⚠️ L0를 "검증 완료"라 부르지 마라 — import가 되고 빌드가 통과한 건 L0일 뿐입니다. "PASS"는 L2 이상(프로덕션 경로 E2E)에서만 쓸 수 있습니다. 낮은 레벨의 통과를 높은 레벨인 척하면, strict_pass 사건처럼 "되는 척"이 쌓입니다.

한 줄 정리

📌 런처 파일·편집본을 고쳐 테스트해도, 프로덕션이 다른 경로로 돌면 아무것도 검증 못 한 것이다. 검증은 실제 진입점(API)으로, 프로덕션과 같은 경로로 해야 한다(dev/prod parity). 그리고 "PASS"는 L2(E2E 실제 동작) 이상에서만 — L0(빌드 성공)를 검증 완료라 부르지 마라.