「이거 괜찮아?」라고 AI에게 묻고, 「괜찮습니다, 문제없습니다」라는 답변을 듣는다. 그러고 나서 안심하던 시기가 있었습니다——조금 전까지만 해도, 저는 그것을 확인이라고 생각했었습니다.

하지만 그것은 검증이 아니라, 기도였습니다. AI의 「괜찮습니다」는 첫 번째 부탁과 마찬가지로, 확률적으로 틀립니다. 마지막 회는, 그 자기 신고를 믿지 않기 위한 이야기입니다.

「AI에게 체크하게 합시다」만으로는 부족했다

검증의 교과서적인 답은 「AI에게 리뷰나 테스트를 시킵시다」입니다. 저도 그렇게 하고 있었습니다.

하지만, 출력을 한 본인에게 「맞아?」라고 묻는 것은, 답안지를 작성한 사람에게 채점을 맡기는 것과 같습니다. 틀렸을 때일수록 「괜찮습니다」라고 답변이 돌아옵니다. 순서대로 적어보겠습니다.

타입 체크(Type Check)는 통과했는데, 실서비스가 무너졌다

구체적인 사고 사례를 적겠습니다.

어떤 화면을 수정했을 때, 타입 체크 (tsc)도 빌드 (build)도 통과했습니다. 초록색이었기에 안심하고 커밋 (commit)했습니다. 그런데 실서비스(본방)를 열어보니, 화면 하단의 네비게이션이 무너져 있었습니다. 타입 체크는 「타입이 맞는지」를 볼 뿐, 「외관이 올바른지」는 일절 보지 않습니다. 「빌드가 통과된다」와 「올바르게 동작한다」는 별개의 문제였습니다.

게다가 당시에는, 로컬에서 확인하지 않고 푸시 (push)했다가 CI (자동 테스트)에서 떨어지는 것을 몇 번이고 반복하고 있었습니다. 수정하고 다시 푸시하고, 또 떨어집니다. 하루 CI 실행 시간의 상당 부분을 이 왕복 과정에서 허비하고 있었습니다. 「CI에 던져서 확인한다」를 검증 대신 하고 있었던 결과였습니다.

자기 신고가 아니라, 기계의 게이트와 실기의 증거로 확인한다

도달한 원칙은 「기계로 떨어뜨린다」와 「실기로 본다」의 2개 축입니다. 구체적으로 4가지를 실천하고 있습니다.

첫 번째. push 하기 전에, 로컬에서 물리적으로 떨어뜨린다. push 직전에 npm run verify (타입 체크, lint, build를 일괄 실행)를 강제하는 메커니즘을 넣어, 이것이 초록색이 되지 않으면 push 할 수 없도록 했습니다. CI에 던지기 전에 로컬에서 멈추기 때문에, 아까와 같은 무의미한 왕복이 사라집니다.

두 번째. UI는 반드시 눈으로 본다. 타입 체크의 초록색만 보고 commit 하지 않고, 변경한 화면은 브라우저에서 실제로 열어서 확인합니다. 무너짐은 인간의 눈에는 금방 보입니다.

세 번째. 스크린샷의 차분을 기계에게 시킨다. 각 화면의 이미지를 기준 이미지와 자동으로 비교하여 (visual regression), 외관의 어긋남을 검지합니다. 매번 모든 화면을 인간이 대조하는 것은 지속하기 어려우므로, 이 부분은 기계에 맡깁니다.

네 번째. 「현재의 올바른 동작」을 동결한다. 예를 들어 세액 계산에서, 규칙 배열의 선두를 암묵적으로 사용하고 있어서, 2029년에 세율이 바뀌었을 때 잘못된 값을 반환하는 구조적 버그가 있었습니다. 이를 「날짜(적용일)로 올바른 규칙을 선택하도록」 수정한 뒤, 그 올바른 동작을 테스트 (test)로 고정하여, 다시는 조용히 망가지지 않도록 했습니다. 이론상의 계산으로 「맞을 것이다」라고 판단하지 않고, 실제 데이터로 확인하는 것이 원칙입니다.

그럼에도, 모든 것을 다 확인할 수는 없다

솔직히 말하면, 모든 경로를 검증할 수 있는 것은 아닙니다.

검증에도 비용이 듭니다. 그래서 위험한 곳(실서비스에 나가는 것, 돈이나 법령에 관련된 것)에는 두텁게, 그렇지 않은 곳은 얇게, 라고 완급 조절을 하고 있습니다. 완벽한 검증보다, 지속 가능한 검증을 선택하고 있는 것이 실태입니다. 누락은 발생합니다. 발생하면, 그 경로에 검증을 하나 추가합니다. 첫 번째 가드레일과 마찬가지로, 키워 나간다는 전제의 운용입니다.

가져갈 점: 「괜찮아?」를 그만두고, 증거를 보자

내일부터 쓸 수 있는 척도 하나를 꼽는다면, AI에게 「괜찮아?」라고 묻고 싶어질 때, 대신 「어떻게 확인했어? 그 증거(화면 / 로그 / 테스트 결과)를 보여줘」로 바꾸는 것입니다. 질문을 기도에서 증거로 바꾸는 것만으로도, 보이는 사고의 수가 달라집니다.

다만, 전부를 기계화할 필요는 없습니다. 하지만 「인간이 초록색 체크 마크만 보고 안심하는」 상태만큼은 피하는 것이 좋습니다. 초록색은 출발점이지, 골인 지점이 아니었습니다.

요약

AI의 「했습니다」는 출발점이며, 확인하는 것은 자신의 일입니다. 검증은 기도가 아니라, 기계의 게이트와 실기의 증거로 수행합니다.

• 「빌드가 통과한다(Build passes)」와 「올바르게 동작한다」는 별개의 문제다. 타입 체크(Type check)의 초록색 불이 외관을 보장하지는 않는다.
• 출력한 본인에게 「맞아?」라고 묻는 것은 검증이 아니라 기도다. 확률적으로 틀릴 수밖에 없다.
• 「기계로 걸러내기 (pre-push / 시각적 회귀 테스트 (Visual regression) / 동작의 동결)」와 「실기(Real device)로 확인하기」라는 2개의 축으로 확인한다.
• 검증에도 비용이 든다. 위험한 곳에는 두껍게, 그 외에는 얇게. 완벽함보다는 지속 가능한 검증을 선택한다.

지금까지 총 6회——가드레일(Guardrail) / 셋업(Setup) / 문서=구현(Documentation=Implementation) / 실행 관리(Execution management) / 지속성(Continuity) / 검증(Verification)——에 대해 써왔습니다. 전체를 관통해 보면 모든 장의 결론은 같았습니다. AI의 자제나 부탁에 의존하지 않고, 리포지토리(Repository)의 구조와 기계적 게이트(Gate)를 통해 사고가 발생할 수 없도록 만드는 것입니다. 혼자서 AI와 함께 프로덕션을 운영한다는 것은, 똑똑한 프롬프트(Prompt)를 작성하는 것이 아니라, 실수하더라도 멈춰 설 수 있는 구조를 먼저 마련해 두는 것이라고 생각합니다.

Discussion