AI가 "다 고쳤습니다"라고 했고, 검사하는 AI는 "아니요"라고 했습니다

📝 한줄 요약

자료를 더 넣기 전에 도구가 멀쩡한지 확인만 하려던 참이었습니다. 그런데 확인하는 명령 자체가 제 기록을 망가뜨렸고, 고치는 과정에서 만드는 AI와 검사하는 AI를 따로 두자 혼자서는 못 봤을 결함이 세 건 더 나왔습니다.

바쁘시면 이것만 읽어도 돼요:

• "미리보기만 한다"는 뜻의 명령이 실제로는 제 기록을 덮어썼습니다. 도구 설명에 그렇게 적혀 있었고, 제가 그걸 안 읽고 실행했어요

• 지난 편에서 만든 "지우는 기능"은 알고 보니 이 사고의 뒤처리 도구였습니다. 원인은 손도 안 댄 채였고요

• 고치는 일을 혼자 안 하고 만드는 AI 하나, 검사하는 AI 둘로 나눴습니다

• 만든 쪽이 "다 고쳤습니다, 검사 95개 통과"라고 했는데 검사하는 쪽이 "아니요"라며 새 결함 3건을 찾아냈습니다

• 그중 압권은 "검사가 문제를 피해 가도록 짜여 있다"는 지적이었어요. 통과는 하는데 문제는 그대로였습니다

• 결과: 결함 5건 수정, 두 번 커밋. 그리고 "통과했다"와 "고쳐졌다"는 다른 말이라는 걸 배웠습니다

🎯 이런 분들께 도움돼요

• AI에게 일을 시켜봤는데, "완료했습니다"를 어떻게 믿어야 할지 몰랐던 분

• AI 하나로는 부족해서 여러 개를 조합해보고 싶은데 효과가 있을지 궁금한 분

• 자동화를 만들어놓고 정말 제대로 돌아가는지 확인해본 적은 없는 분

😫 문제 상황 (Before)

지난 편 마지막에 이렇게 적어뒀습니다.

도구는 더 만들 게 없고, 부족한 건 재료입니다. 그래서 다음은 영상 전사를 더 넣는 일입니다.

그래서 이번엔 재료를 넣을 차례였어요. 그런데 새 재료를 밀어 넣기 전에 한 가지가 걸렸습니다. 이 도구, 지금 멀쩡한가?

몇 편에 걸쳐 기능을 계속 붙여왔거든요. 분류하고, 검증하고, 문서로 만들고, 서로 연결하고, 지난 편엔 지우는 기능까지. 정작 "다 붙여놓고 한꺼번에 돌려본 적"은 없었습니다. 새 재료가 들어오면 이 모든 단계를 다 거치는데, 중간에 뭐가 어긋나 있으면 재료만 낭비되는 셈이잖아요.

그래서 넣기 전에 점검부터 하기로 했습니다. 이 프로젝트에는 "완료로 마크하기 전 반드시 실행하라"고 적어둔 검증 명령 목록이 있어서, 그걸 그대로 돌려보면 되는 일이었어요.

십 분이면 끝날 줄 알았습니다.

🛠️ 사용한 도구

• 도구: Claude Code (지휘·검증) · Codex CLI (구현) · Antigravity CLI (감사)

• 모델: Claude Opus 5 · GPT-5.6 · Gemini 3.6 Flash

• 특이사항: 세 AI를 각각 다른 터미널 창에 띄우고 역할을 나눠 운영

🔧 작업 과정

"미리보기만 한다"는 말을 믿었습니다

지금 만들어진 시스템이 문제 없는지 다시 검증해줘

점검 목록에 적힌 명령을 순서대로 돌렸습니다. 앞의 두 개는 통과. 세 번째는 실제 영상 전사 하나를 넣고 파이프라인을 끝까지 돌려보는 명령이었는데, 여기엔 "미리보기" 옵션이 붙어 있었어요. 실제로 뭘 만들진 않고 "이렇게 될 겁니다"만 보여주는 옵션이요.

안심하고 실행했습니다. 결과도 깔끔했어요. "이런 문서가 생길 예정입니다" 하고 목록이 쭉 나왔거든요.

습관적으로 변경 사항을 확인해봤습니다. 기존 문서 세 개가 이미 바뀌어 있었습니다.

미리보기가 아니었습니다. 도구 설명을 열어보니 이렇게 적혀 있었어요.

"검증 목적 실행임을 출력에 표시하되 로컬 산출물은 실제 생성"

말하자면 화면에 "미리보기"라고 써주기만 하고, 파일은 진짜로 만드는 옵션이었습니다. 이름과 하는 일이 정반대였어요.

피해도 단순하지 않았습니다. 같은 영상을 두 번째로 돌리니 AI가 지난번과 다른 문장을 골라왔거든요. 원래 문서에 있던 인용 다섯 개 중 셋이 다른 문장으로 갈렸고, 문서 제목도 바뀌어서 같은 내용이 이름만 다른 채로 두 벌이 됐습니다. 처음 만든 날짜도 오늘 날짜로 덮어써졌고요. 이 위키는 "언제 어느 영상의 누가 이렇게 말했다"가 전부인데, 그 날짜가 사라진 겁니다.

다행히 되돌릴 수 있었습니다. 바뀐 파일은 이전 상태로 복원하고, 새로 생긴 아홉 개는 지웠어요.

그러고 나서야 지난 편이 떠올랐습니다. 지난 편에서 저는 "가짜 자료에서 나온 문서 4건"을 걷어냈어요. 그때 그걸 치우려고 지우는 기능까지 새로 만들었고요. 그런데 그 문서들이 왜 위키에 들어와 있었을까요?

아마 그때도 이 명령을 "안전하다"고 믿고 돌렸을 겁니다.

지난 편에 만든 건 뒤처리 도구였습니다. 원인은 그대로 두고 결과만 치웠던 거예요. 그러니 오늘 또 같은 자리에서 미끄러진 거고요.

혼자 고치지 않기로 했습니다

고칠 목록이 세 개 나왔습니다. 평소 같으면 그냥 제가 AI에게 시켜서 고치고 끝냈을 텐데, 이번엔 방식을 바꿔봤습니다.

오케스트레이션에서 워커를 코덱스로 하고 리뷰를 다시 클로드로해줘

이유가 있었어요. 오늘 제가 밟은 함정이 "설명은 멀쩡한데 실제 동작이 다른" 종류였거든요. 이런 건 만든 사람이 자기 결과를 볼 때 잘 안 보입니다. "내가 의도한 대로 됐나"를 보게 되지, "정말 그렇게 됐나"를 보진 않으니까요.

그래서 세 개의 AI를 각각 다른 창에 띄우고 역할을 나눴습니다.

핵심은 만드는 쪽과 검사하는 쪽이 서로 다른 프로그램이라는 점입니다. 같은 창에서 "이제 네가 만든 걸 검토해봐"라고 하면, AI는 자기가 방금 한 말에 이끌립니다. 창을 분리하면 검사하는 쪽은 결과물만 보고 판단하게 되고요.

일을 넘길 때 지시문에 이 문장을 넣었습니다.

검증 조건이 틀렸다고 판단되면 고치지 말고 보고하라

이 프로젝트에서 전에 세 번 효과를 본 문장인데, 세 번 다 틀린 쪽은 검증 조건이었습니다. 이 문장이 없으면 AI는 "통과시키는 것"을 목표로 삼아서 검사 조건 쪽을 슬쩍 우회하는 코드를 짜거든요.

"다 고쳤습니다" 다음에 "아니요"가 왔습니다

한 시간쯤 뒤에 만든 쪽에서 보고가 올라왔습니다.

세 결함 수정 완료. 검사 95개 전부 통과, 실제로 돌려본 결과 기록에 변경 없음.

숫자만 보면 완벽했어요. 저 같으면 여기서 저장하고 끝냈을 겁니다.

그런데 검사하는 쪽은 이 보고를 그대로 받아들이지 않았습니다. 보고서를 읽는 대신 자기가 직접 짧은 코드를 짜서 고쳐진 부분을 다시 돌려봤어요. 그러고는 판정을 내렸습니다.

REVISE — 다시 하세요.

고치는 과정에서 새 문제가 세 개 생겼다는 거였습니다.

하나는 끝나지 않는 반복이었어요. 이 도구는 "목록이 오래됐으면 다시 만든다"를 판단하는데, 읽다가 실패한 파일을 세는 데서 빼먹었습니다. 그래서 읽기 실패한 파일이 하나라도 있으면 매번 "오래됐다"고 판단해서 끝없이 다시 만들게 돼 있었어요.

또 하나는 정해진 폴더 밖에서 뻗는 문제였고, 마지막은 목록 파일이 깨져 있으면 새로 만들지 않고 그냥 죽는 문제였습니다.

진짜 날카로웠던 건 네 번째 지적이었습니다.

회귀 테스트가 dir=PROJECT_ROOT로 외부 경로 버그를 우회(workaround) 했으나, 정작 본체 코드의 결함은 수정되지 않았습니다.

풀어 쓰면 이렇습니다. 두 번째 문제("정해진 폴더 밖에서 뻗는다")를 확인하는 검사를 새로 만들긴 했는데, 그 검사가 일부러 폴더 안쪽에서만 시험하도록 짜여 있었어요. 뻗는 조건을 피해서 시험한 겁니다.

그러니 검사는 초록불이 뜹니다. 문제는 그대로인데요.

이게 제가 이번에 가장 크게 배운 지점입니다. "검사 95개 통과"는 "95개를 제대로 검사했다"는 뜻이 아니었어요. 검사가 문제를 비껴가도록 짜여 있으면, 숫자는 늘어나는데 안전은 그대로입니다. 그리고 이건 만든 사람이 절대 못 봅니다. 자기가 짠 검사니까요.

다시 고친 뒤에는 두 검사자 모두 통과를 냈습니다. 이번엔 검사 세 개가 실제로 문제가 터지는 조건을 그대로 재현하도록 다시 짜여 있었고요.

검사자가 범위 밖에서 하나를 더 물어왔습니다

통과 판정과 함께 검사하는 쪽이 이런 말을 덧붙였습니다.

이번 범위 밖이지만 별도 이슈로 트래킹 권고 — 이번 판정은 막지 않음

내용은 이랬습니다. 이 도구는 문서를 만들 때 "정리 노트를 먼저 저장하고, 그다음 위키 문서로 옮기는" 순서로 돌아갑니다. 그런데 옮기는 단계에서 실패하면 정리 노트만 "검증 완료" 딱지를 단 채 남습니다. 위키에는 아무것도 안 생겼는데요.

문제는 다음번입니다. 같은 영상을 다시 넣으면 도구가 그 노트를 보고 "이건 이미 처리했네" 하고 거절합니다. 위키엔 아무것도 없는데 영원히 다시 못 넣는 상태가 되는 거예요.

이건 이번에 생긴 게 아니라 원래부터 있던 문제였습니다. 검사자가 이전 기록과 대조해서 그것까지 확인해줬고요.

partial-write 결함도 다음 라운드로 진행해줘

그래서 한 라운드를 더 돌렸습니다. 순서를 뒤집어서 위키 문서가 무사히 만들어진 뒤에만 노트를 저장하도록요.

그러다 또 제 기록이 오염됐습니다

두 번째 라운드 중간에 만드는 쪽에서 이런 보고가 왔습니다.

[충돌/막힘] 회귀 테스트 중 기존 결함을 발견해 실제 위키에 테스트 산출물 4개가 생성됐습니다.
그러나 지시의 wiki 직접 조작 금지에 따라 해당 파일은 삭제하지 않고 있습니다.
정확히 이 4개 테스트 산출물 삭제 권한이 필요합니다.

시험용 가짜 문서 네 개가 또 진짜 위키에 들어간 겁니다. 지난 편에서 걷어냈던 것과 똑같은 사고가요.

원인은 이번에 새로 밝혀졌습니다. 시험할 때는 진짜 폴더 대신 임시 폴더에 쓰도록 바꿔놓고 돌리는데, 이 도구의 일부 기능이 바꿔놓은 걸 무시하고 원래 폴더로 가버리는 구조였어요. 시험용으로 갈아 끼운 게 일부에만 먹힌 겁니다.

인상적이었던 건 AI가 스스로 멈췄다는 점입니다. 이 프로젝트에는 "위키 폴더 안의 파일을 코드 밖에서 직접 건드리지 마라"는 규칙을 적어뒀는데, 자기가 만든 쓰레기인데도 그 규칙 때문에 안 지우고 물어본 거예요.

저도 바로 승인하진 않았습니다. 네 개가 정말 시험용인지 두 가지로 대조했어요. 하나는 기록에 추적되지 않는 새 파일인지, 다른 하나는 그 문서가 붙은 분야 이름이 이 위키가 다루는 분야 목록에 있는지. 둘 다 "시험용"으로 나와서 그때 지우라고 했습니다.

자동화가 세 번 연속 실패했습니다

워커는 또 승인을 기다리는데? 왜 계속 감시가 안되지?

이번 작업에서 제일 답답했던 건 결함이 아니라 제가 만든 자동화였습니다.

AI들에게 일을 맡겨놓고 저는 다른 걸 보고 있으면 되는데, 문제는 이 AI들이 명령을 하나 실행할 때마다 "이거 해도 되나요?" 하고 멈춘다는 점이었어요. 그때마다 제가 승인을 눌러줘야 하고요.

그래서 "안전한 명령이면 자동으로 승인해주는" 감시 장치를 만들었습니다. 그리고 세 번 연속으로 실패했어요.

첫 번째는 너무 느렸습니다. 12초마다 확인했는데 그사이에 화면이 바뀌고, 게다가 화면에 빙글빙글 도는 로딩 표시가 글자와 겹쳐서 캡처가 깨지더라고요. 주기를 6초로 줄였습니다.

두 번째도 놓쳤습니다. 알고 보니 승인 창이 한 종류가 아니었어요. "이 명령을 실행할까요?" 말고 "이 파일을 읽어도 될까요?"라는 창이 따로 있었는데, 제 감시 장치는 앞엣것만 찾고 있었습니다.

세 번째가 진짜 원인이었습니다. 유독 한 창에서만 계속 놓쳐서 화면을 직접 읽어봤더니, 읽는 도구가 항상 빈 값을 돌려주고 있었어요. 오류가 난 것도 아니고, 그냥 아무것도 없다고 답한 겁니다. 그러니 제 감시 장치 입장에선 "조용하다"와 "못 읽는다"가 구분이 안 됐어요.

다른 방식으로 화면을 읽어보니 멀쩡하게 나왔습니다. 방법을 바꾸자 그동안 못 보던 승인 대기가 바로 잡혔고요.

그런데 마지막에 한 번 더 놓쳤습니다. 이번엔 원인이 달랐어요. 검사자에게 "판정은 반드시 ACCEPT나 REVISE 같은 정해진 단어로 적어라"라고 지시해뒀고, 감시 장치는 그 단어를 찾고 있었습니다. 화면을 세어보니 이랬습니다.

검사자가 형식을 안 지킨 겁니다. 첫 라운드엔 지켰는데 둘째 라운드엔 그냥 "승인합니다"라고만 썼어요.

여기서 배운 게 오늘의 두 번째 교훈입니다. "약속한 형식"을 기준으로 감시하면, 상대가 형식을 안 지키는 순간 조용히 멈춥니다. 그래서 마지막엔 방식을 바꿨어요. 형식 대신 "저장 기록이 실제로 늘어났는가"를 봤습니다. 이건 AI가 어떻게 말하든 상관없이 사실이니까요. 그 뒤로는 한 번도 안 틀렸습니다.

지우려던 걸 직전에 멈췄습니다

작업 중에 컴퓨터가 무거워서 살펴봤더니, 배경에서 돌아가는 프로그램이 138개, 메모리 2.3GB를 먹고 있었습니다. 오늘 처음에 AI 팀을 못 띄운 것도 이것 때문이었고요.

날짜를 세어보니 5일에서 16일 전 것이 60개였습니다. 버려진 찌꺼기처럼 보였어요. 그래서 정리하자고 하고 승인까지 받았습니다.

그런데 지우기 직전에 한 번 더 확인해봤습니다. 이것들의 주인이 아직 살아있나?

전부 살아있었습니다. 13일 전에 연 창, 18일 전에 연 창… 제가 닫는 걸 잊고 그냥 둔 것들이요. 버려진 찌꺼기가 아니라 살아있는 창의 일부였습니다. 지웠으면 그 창들이 다 망가졌을 거예요.

승인은 받았지만 그 승인은 "찌꺼기를 지워라"였지 "살아있는 걸 지워라"가 아니었습니다. 전제가 틀렸으면 승인도 무효인 셈이죠.

진짜 해법은 간단했습니다. 안 쓰는 창을 닫으면 딸린 것들이 같이 정리되거든요. 실제로 오늘 쓴 AI 창 네 개를 닫아보니 프로그램이 71개 줄었습니다. 창 하나가 15개씩 물고 있었던 거예요.

✅ 결과 (After)

Before vs After

결과물

두 번 저장했습니다.

• 78a8ff9 — 미리보기·중복 실행·목록 갱신 문제

• 8b72c62 — 중간 실패 시 남는 찌꺼기 문제

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 만드는 AI와 검사하는 AI를 다른 창에 띄우기. 같은 창에서 "네가 만든 거 검토해봐"라고 하면 자기가 방금 한 말에 이끌립니다. 창을 나누면 결과물만 보고 판단해요. 이번에 걸린 결함 세 건은 전부 이 분리 없이는 못 잡았을 것들입니다.

2. "자기 검토했습니다"는 증거로 받지 않기. 만든 쪽 보고에 "코드 리뷰 승인"이라고 적혀 있었는데, 자기가 자기를 검토한 거라 그대로 넘기지 않았습니다. 검사자에게 "저 문장은 증거가 아니니 직접 확인하라"고 명시했어요.

3. "조건이 틀렸다고 판단되면 고치지 말고 보고하라"를 지시문에 넣기. 이 문장이 없으면 AI는 통과시키는 걸 목표로 삼아 조건 쪽을 우회합니다.

4. 감시는 "말"이 아니라 "흔적"으로 하기. AI가 뭐라고 썼는지가 아니라, 저장 기록이 실제로 늘었는지를 보면 틀리지 않습니다.

5. 파괴적인 작업 직전에 전제를 한 번 더 확인하기. 승인을 받았어도 그 승인의 전제가 사실과 다르면 그 승인은 무효입니다.

이렇게 하면 안 돼요

1. "미리보기"라고 쓰여 있다고 믿지 마세요. 실행 전에 그 옵션이 실제로 뭘 하는지 확인하고, 실행 후엔 뭐가 바뀌었는지 보세요. 오늘 사고의 전부가 여기서 시작됐습니다.

2. "검사 N개 통과"를 안전으로 읽지 마세요. 검사가 문제를 비껴가도록 짜여 있으면 숫자만 늘어납니다. 검사를 짠 사람은 이걸 절대 못 봐요.

3. 결과만 치우고 원인을 두지 마세요. 지난 편에서 뒤처리 도구를 만들고 원인은 안 고쳤더니, 이번에 같은 자리에서 또 미끄러졌습니다.

4. AI 창을 열어두고 잊지 마세요. 창 하나가 배경 프로그램 15개를 물고 있습니다. 며칠 방치하면 새 작업을 시작할 수 없을 만큼 쌓여요.

🌍 다른 업무에 적용한다면?

이 구조는 코딩이 아니어도 됩니다. "만든 사람과 검사하는 사람을 나눈다"가 전부거든요.

• 보고서·기획서: 한 AI에게 쓰게 하고, 다른 창의 AI에게 원본 자료를 주고 검사시키기. "이 문장의 근거가 자료에 실제로 있나?"를 묻는 게 핵심이에요. 쓴 AI에게 물으면 자기가 쓴 걸 변호합니다.

• 번역·요약: 번역한 AI가 아닌 다른 AI에게 원문과 번역문을 나란히 주고 빠진 내용을 찾게 하기.

• 데이터 정리: 정리한 AI에게 "몇 건 처리했어?"라고 묻지 말고, 원본 파일 개수를 직접 세서 대조하기. 오늘 배운 "말이 아니라 흔적으로 확인하기"와 같습니다.

공통점은 하나예요. 검사하는 쪽에게는 "결과물"이 아니라 "원본"을 줘야 합니다. 결과물만 주면 그럴듯한지만 보게 되거든요.

🚀 앞으로의 계획

지난 편에서 "다음은 전사를 더 넣는 일"이라고 적었는데, 이번에도 못 넣었습니다. 두 편 연속으로 미룬 셈이에요.

그래도 이번엔 미룬 이유가 분명합니다. 재료를 넣는 통로가 새고 있었거든요. 새 영상을 넣었다면 오늘 발견한 결함들을 그대로 통과했을 거고, 그러면 기록이 또 어긋난 채 쌓였을 겁니다.

이제 통로는 막았습니다. 그러니 다음은 정말 재료입니다. 기준은 지난 편에 정해뒀어요. "AI를 얼마나 깊이 아느냐"가 아니라 "AI를 무엇에 빗대어 말하느냐"로 채널을 고르는 것. 지금 이 위키에서 가장 두꺼운 덩어리가 뇌과학이니, 같은 층위로 말하는 영상이 들어와야 연결이 생깁니다.

그리고 하나 더. 오늘 만든 검사 체계를 다른 작업에도 써볼 생각입니다. 만드는 쪽과 검사하는 쪽을 나누는 이 구조가 생각보다 훨씬 잘 들었거든요.

📋 재사용 가능한 프롬프트

프롬프트 1: 만든 결과를 다른 AI에게 검사시키기

다른 AI가 [작업 내용]을 완료했다고 보고했습니다. 이 보고를 그대로 믿지 말고 직접 검증해주세요.

중요: 보고서에 "자체 검토 완료"나 "리뷰 승인" 같은 문구가 있어도 그건 자기 승인이므로 증거로 채택하지 마세요. 직접 실행해서 확인한 것만 근거로 삼아주세요.

특히 다음을 확인해주세요:

1. [확인할 항목 1]

2. [확인할 항목 2]

3. 검사(테스트)가 문제 조건을 실제로 재현하는지, 아니면 피해 가도록 짜여 있는지

판정은 통과 / 재작업 중 하나로 내리고, 각 지적에 어느 파일 몇 번째 줄인지 근거를 붙여주세요.

프롬프트 2: 우회하지 않는 검사 요구하기

[문제 상황]을 재현하는 검사를 추가해주세요.

조건: 문제가 실제로 발생하는 조건을 그대로 만들어서 확인해야 합니다. 가짜로 대체하거나(모킹), 문제가 안 생기는 안전한 설정으로 우회해서 통과시키지 마세요.

검사 조건이 틀렸다고 판단되면 조건을 고치지 말고 저에게 보고해주세요.

프롬프트 3: 파괴적인 작업 전 전제 확인하기

[삭제/정리]하기 전에, 대상이 정말 안전하게 지워도 되는 것인지 먼저 확인해주세요.

확인할 것:

1. 이게 [버려진 것 / 임시 파일]이라는 근거가 무엇인지

2. 아직 사용 중인 것과 어떻게 구분했는지

3. 지웠을 때 영향받는 다른 것이 있는지

확인 결과를 먼저 보고하고, 제 승인을 받은 뒤에 진행해주세요. 확인 과정에서 처음 판단과 다른 사실이 나오면 즉시 멈추고 알려주세요.