게이트는 차단하고 있었다, 검사기는 죽은 채로

Summary

한 문장으로

문지기는 계속 문을 막고 있었다. 다만 그는 아무것도 보고 있지 않았다.

12일 동안 죽어 있었다

1글자가 원인 (")

3겹의 은폐

0건 유출

먼저 배경을 짧게. 저는 코드를 서버에 올리기 전에 자동으로 문을 막는 장치를 여러 개 두고 씁니다. 그중 하나가 QA 게이트입니다. 화면을 진짜로 열어보고 버튼을 눌러봤다는 증거 파일을 요구하고, 그 증거가 제대로 채워졌는지 검사한 다음, 통과해야만 올리기를 허용합니다.

이 사건은 그 “검사” 부분이 조용히 죽어 있었다는 이야기입니다. 그런데 문은 계속 닫혀 있었습니다. 그래서 12일 동안 아무도 눈치채지 못했습니다.

Reproduction

죽은 검사기는 어떻게 생겼나

“죽었다”는 건 주장입니다. 그래서 결함이 있던 시점의 게이트를 그대로 꺼내, 격리된 빈 저장소에서 세 번 돌려봤습니다. 결과가 판정을 대신합니다.

실험	검사기	넣은 증거	게이트가 뱉은 말
A	죽음	완벽하게 채운 증거	`증거 검사가 결과를 내지 못했습니다(빈 출력 — 실행 실패 가능)`
B	살아있음	같은 증거 (A와 동일)	`screenshot_evidence 비어있음; api_logs.captured=false; db_verification.crud_roundtrip=MISSING …`
C	죽음	일부러 망가뜨린 증거	`증거 검사가 결과를 내지 못했습니다(빈 출력 — 실행 실패 가능)`

세 번 다 exit 2 (차단). 문은 계속 닫혀 있었다.

A와 C를 비교하세요. 완벽한 증거를 줘도, 일부러 망가뜨린 증거를 줘도 토씨 하나 똑같은 말이 나옵니다. 죽은 검사기는 증거를 읽지 않습니다. 무엇을 넣든 같은 값을 뱉는 상수가 된 겁니다.

B는 살아있는 검사기가 같은 증거에서 실제로 무엇을 짚어내는지 보여줍니다 — 스크린샷 증거가 비었고, API 로그를 안 찍었고, DB 왕복 확인이 없다는 구체적인 4건. 이게 원래 나왔어야 할 말입니다.

Root cause

주석 안의 큰따옴표 한 개

검사기는 셸 스크립트 안에 파이썬 코드를 큰따옴표로 감싸서 집어넣는 방식이었습니다. 이렇게 생겼습니다.

셸에게 #은 주석이 아니다. 문자열 안이면 그냥 글자다. 그래서 주석에 있던 따옴표가 문자열을 닫아버렸다.

셸은 파이썬 문법을 모릅니다. #이 주석이라는 것도 모릅니다. 셸이 아는 건 “따옴표가 열렸으니 다음 따옴표까지가 문자열” 하나뿐입니다. 그래서 주석 안에 있던 따옴표에서 문자열을 닫아버렸고, 파이썬은 앞의 26줄만 받아 문법 오류로 죽었습니다.

더 아픈 건 그 주석의 내용입니다. “독립 리뷰 지적”이라고 적혀 있습니다. 이전 리뷰 지적을 고치면서 설명을 붙이다가 검사기를 죽인 겁니다. 고치는 행위가 고장을 냈습니다.

Concealment

왜 12일 동안 몰랐나 — 세 겹의 은폐

검사기가 죽으면 보통은 티가 납니다. 이 경우엔 세 가지가 겹쳐서 신호가 하나도 밖으로 안 나왔습니다.

1

구문 검사가 통과한다

셸 문법만 보면 이 파일은 멀쩡하다. 따옴표 개수는 짝이 맞으니까. 문법 검사기(bash -n)를 돌려도 통과한다 — 잘못 짝지어졌을 뿐, 안 짝지어진 게 아니라서.

2

에러 메시지를 버리고 있었다

파이썬은 죽으면서 문법 오류를 외친다. 그런데 그 줄 끝에 2>/dev/null 이 붙어 있었다 — “에러는 버려라”는 뜻이다. 비명이 허공으로 갔다. 원래는 잡음을 줄이려고 붙인 것이었다.

3

게이트는 계속 차단하고 있었다

가장 헷갈리는 부분. 검사기가 죽었는데도 문은 계속 닫혀 있었고 차단 메시지도 나왔다. 겉으로는 “게이트가 잘 돌고 있네”로 보인다. 심지어 그 차단이 맞는 판정일 때도 있었다 — 우연히.

고장이 “정상처럼 보이는 방향”으로 났다는 게 이 사건의 핵심입니다. 죽은 검사기가 문을 열어젖혔다면 그날 바로 들켰을 겁니다. 문을 닫아버렸기 때문에 12일을 버텼습니다.

What saved it

유출이 0인 이유는 운이 아니다

검사기가 죽은 채로 12일이었는데 잘못된 코드가 나간 적은 없습니다. 그 이유는 한 달 전에 넣어둔 다른 규칙 때문입니다.

가정

결과 없으면 통과

흔한 기본값

검사기가 죽어서 아무 말도 못 한다
말이 없으니 문제 없음으로 간주된다
12일치 코드가 검사 없이 전부 통과
이 글은 사고 수습기가 됐을 것이다

실제

결과 없으면 차단

사건보다 먼저 들어가 있던 규칙

검사기가 죽어서 아무 말도 못 한다
말이 없으면 통과가 아니라 차단이다
죽은 채로도 문은 계속 닫혀 있었다
유출 0건

이 “결과 없으면 차단” 규칙은 사건보다 먼저 들어가 있었습니다. 커밋 메시지가 그대로 남아 있습니다 — 증거 검사가 결과를 못 내면 통과가 아니라 차단. 그때는 이런 사고를 예상하고 넣은 게 아니었는데, 결과적으로 이걸 막았습니다.

측정할 수 없다는 것은 통과했다는 뜻이 아니다.

Discovery

찾아낸 건 다른 회사 모델이었다

저는 코드를 올리기 전에 다른 회사 AI에게 교차 리뷰를 시킵니다. 제 코드를 쓴 모델과 검토하는 모델이 다릅니다. 같은 모델은 자기가 놓친 걸 또 놓치기 때문입니다.

이번엔 그 리뷰가 게이트 자체를 파고들었습니다. 라운드가 거듭될수록 다른 결함이 나왔습니다.

지적	무엇이 문제였나	어떻게 드러났나
검사기 사망	주석 안 따옴표가 파이썬을 끊었다	빈 출력 + 에러 버려짐
push 다중 우회	한 줄에 두 번 올리면 두 번째를 안 봤다	명령 파서가 첫 건만 인식
다른 저장소 판정	A를 올리는데 B의 증거를 검사했다	작업 폴더 추적 누락
빈 칸 소실	구분자를 탭으로 써서 빈 값이 사라졌다	탭·공백은 연속되면 하나로 뭉개진다
구버전 셸 사망	최신 셸은 통과, 실제 실행 셸은 죽었다	맥 기본 셸이 옛 버전

전부 재현해서 확인한 뒤 고쳤다. “아마 그럴 것”로 고친 항목은 없다.

여기서 제가 배운 건 조금 다릅니다. 리뷰가 제 코드를 막아준 게 아닙니다. 리뷰는 제 감시 장치가 죽어 있다는 걸 찾아냈습니다. 감시자를 감시할 사람이 필요하다는 게 이 사건의 결론입니다.

Prevention

같은 방식으로 다시 죽지 않게

한 번 고치고 끝내면 다음에 또 같은 식으로 죽습니다. 그래서 이 종류의 죽음을 자동으로 찾아내는 검사기를 따로 만들었습니다.

A

셸 안에 박힌 파이썬을 전부 찾아낸다

따옴표로 감싼 것, 문서 블록으로 넣은 것, 옵션 뒤에 붙인 것까지 — 형태별로 추출한다.

B

문법 검사가 아니라 실제로 돌려본다

이번 결함은 문법 검사를 통과했다. 그래서 그 파일이 실제로 쓰는 셸로 실행해 죽는지 확인한다 — 맥 기본 셸(구버전)까지 같이.

C

올리기 전에 자동으로 막는다

감시 장치 계열 파일에서 이 결함이 나오면 커밋·푸시 단계에서 차단한다. 사람이 기억해야 하는 규칙이 아니라 기계가 세는 규칙으로.

문서에 “따옴표 조심하세요”라고 적는 것으로는 부족합니다. 문서는 읽히지 않거나, 읽혀도 잊힙니다. 종료 코드로 판정되는 규칙만 실제로 강제됩니다.

Honest limits

아직 못 막는 것

이 검사기가 모든 무음 사망을 막지는 못합니다. 남은 구멍을 적어둡니다.

다른 언어로 같은 사고 — 셸 안에 박은 것이 파이썬이 아니라 다른 언어면 지금 검사기는 못 봅니다.
실행은 되는데 판정이 틀린 경우 — 이 검사기는 “죽었나”만 봅니다. 살아서 엉뚱한 답을 내는 건 여전히 사람이 봐야 합니다.
에러를 버리는 습관 자체 — 잡음을 줄이려고 에러를 버리는 코드는 아직 여러 곳에 남아 있습니다. 다음 무음 사망은 거기서 날 겁니다.

감시 장치가 있다는 사실은, 그것이 살아 있다는 증거가 아니다.

게이트는 차단하고 있었다검사기는 죽은 채로

결과 없으면 통과

결과 없으면 차단

게이트는 차단하고 있었다
검사기는 죽은 채로