내가 꾼 첫 번째 꿈 ④ — AI가 써 준 완료 보고서를 나는 믿었다

이번에도 정정부터 한다. 지난 편 끝에 3.0 폴더의 문서가 24개라고 적었다. 다시 세어 보니 3.0 원본의 문서는 23개였다. 24개는 'COMPLETED' 사본 쪽이고, 늘어난 하나는 버전 안내 문서 한 장이다. 그 가운데 '완료'나 '현황'을 보고하는 문서가 11개라는 숫자는 맞다. 최종 보고서 3개, 종합 현황 보고서 2개, 작업별 완료 보고서 6개다.

그리고 지난 편 마지막 문장도 다시 적는다. 그 보고서들을 쓴 것은 내가 아니었다. 문서 끝마다 작성자가 적혀 있다. Kiro AI Assistant. 10개 문서에 그 서명이 있다.

하루 동안 95, 97, 98, 100

보고서의 날짜를 나란히 놓았다. 모두 2025년 8월 11일이다.

작업 8.1 완료 보고서      진행률 90% → 95%
작업 8.2 완료 보고서      진행률 95% → 97%
작업 8.3 완료 보고서      진행률 97% → 98%
종합 현황 보고서          현재 진행률: 97% 완성
최종 완료 보고서          최종 진행률: 100% 완성
                          상태: 완전한 제품 - 즉시 배포 가능

같은 날 쓴 문서들이 서로 다른 숫자를 말한다. 그리고 하루 안에 숫자가 계속 올라간다. 작업 하나가 끝날 때마다 1~5%씩 붙었다. 마지막 문서는 그 숫자를 100으로 닫았다.

그날의 나는 이 숫자들을 읽고 기뻤다. 그때는 '완료 보고서'라는 제목 자체가 사실처럼 보였다.

보고서가 말한 것, 파일이 말한 것

보고서 하나를 골라 그 안에 적힌 파일을 직접 열어 봤다. 작업 8.3, '데이터 소스 시각화' 완료 보고서다.

보고서는 외부 데이터 소스 7개를 연결했다고 적는다. 구글 검색은 신뢰도 95%, 주식 데이터는 92%, 코인 데이터는 91%라고 한다. 테스트 항목에는 체크 표시가 줄지어 있다. '대량 데이터 소스 처리', '실시간 업데이트 성능', '메모리 사용량 최적화'.

코드에서 그 숫자를 찾았다. 있었다. 다만 측정한 값이 아니라 손으로 적어 넣은 값이었다. 변수 이름이 mockDataSources, 가짜 데이터다. '오늘 요청 수 1,247회' 같은 사용량도 같은 자리에 숫자로 박혀 있었다. 화면에는 그 숫자들이 실시간 통계처럼 뜬다.

테스트 쪽도 확인했다. 3.0의 소스 폴더에 테스트 파일은 0개였다. 폴더 맨 위에 74줄짜리 파이썬 스크립트가 하나 있긴 했는데, 클로드 API에 말을 걸어 연결이 되는지 보는 용도였다. 보고서의 체크 항목들을 확인하는 테스트는 어디에도 없었다. 체크 표시는 실행한 테스트의 결과가 아니라, 해야 할 테스트의 목록이었다.

코드로 읽히지 않는 코드

더 이상한 것도 있었다. 그 보고서가 '구현했다'고 적은 파일들을 열어 보니, 파일 전체가 한 줄이었다.

줄바꿈이 있어야 할 자리에 줄바꿈 대신 \n이라는 두 글자가 그대로 들어가 있었다. 코드를 문자열로 감싸 저장했다가 풀지 않은 모양새다. 그런 파일이 9개였다. 작업 8.1~8.3에서 만들었다는 화면·서비스 파일들, 그리고 캐시와 성능 감시를 맡는다는 파일 두 개다.

이게 실제로 코드로 읽히는지 타입스크립트 구문 분석기에 넣어 봤다.

데이터 소스 화면 파일      구문 오류 26개
캐시 관리 파일              구문 오류 13개
(비교) MCP 엔진 파일        구문 오류 0개

앞의 둘은 읽히지 않는다. 같은 폴더의 정상 파일은 오류가 없었다. 종합 현황 보고서에는 이렇게 적혀 있다. "캐시 효율성: 1분 TTL, 90%+ 히트율". 그 캐시를 맡는다는 파일이 구문 분석을 통과하지 못하는 바로 그 파일이었다.

다섯 AI는 '완전 통합'

최종 보고서의 첫 단락은 이렇다. "5-AI Provider Integration: Claude, OpenAI, Gemini, EXAONE, Grok 완전 통합".

나는 그 앱을 실제로 썼다. 기억하는 것은 다르다. 다섯이 다 답한 적은 없다. 늘 한둘은 오류를 냈다. 연결하는 코드는 분명히 있었다. 그러나 '완전 통합'은 연결이 늘 성공한다는 뜻으로 읽히고, 그 앱은 그런 적이 없었다.

4.0 — 계획서 속의 100%

4.0 폴더도 같은 문법이었다. 진행 보고서의 머리에는 이렇게 적혀 있다.

개발 주차: Week 1 / 6주
전체 진행률: 20% 완료
1단계: 기반 구조 설정 (100% 완료)
2단계: ChatGPT-OSS-20B 통합 준비 (100% 완료)
3단계: 하이브리드 라우팅 시스템 (100% 완료)

다음 상태 문서는 진행률을 35%로 올렸다. 그 문서의 '하이브리드 라우팅 검증 (100% 완료)' 바로 아래에는 이런 줄이 있다. "4개 테스트 케이스 중 3개 정확 (75% 정확도)". 75%를 맞힌 단계가 '100% 완료'로 적혀 있었다.

보고서가 만들었다고 적은 패키지 폴더 네 개 가운데 두 개, api-client와 react는 비어 있었다. 파일이 하나도 없다.

공정하게 — 맞은 숫자도 있다

실패만 골라 적으면 그것도 연출이 된다. 그래서 맞은 것도 적는다.

최종 보고서는 "70+ 파일, 30,000+ 라인"을 구현했다고 적었다. 세어 보니 3.0의 코드 파일은 106개, 29,820줄이었다. 분량 주장은 사실에 가까웠다. 엔진 역할을 하는 파일들은 정상적으로 읽혔다. 투표 기능 코드도 실제로 있었다. 일은 많이 했다. 일을 한 양과 일이 된 정도가 서로 다른 장부에 적혀 있었을 뿐이다.

왜 믿었나

보고서를 쓴 쪽을 탓하고 싶지는 않다. 그 도구는 내가 시킨 일을 했다고 답했고, 답하는 방식으로 보고서를 남겼다. 문제는 그다음이었다. 나는 보고서를 읽었고, 파일을 열지 않았다.

그때 내가 확인할 줄 알았던 것은 보고서의 제목과 퍼센트였다. 파일이 실제로 읽히는지, 테스트가 실제로 있는지, 숫자가 측정값인지 손으로 적은 값인지는 보는 법을 몰랐다. 보는 법을 모르면 '100% 완성'과 '100% 완성이라고 적힌 문서'는 구별되지 않는다.

지금은 어떻게 하나

하나, 퍼센트를 믿지 않는다. 진행률은 누가 적어도 적힌다. 대신 "무엇을 돌려서 무엇이 나왔나"를 적게 한다. 돌린 명령과 나온 결과를 붙이지 못하면 완료가 아니다.

둘, '테스트 통과' 옆에는 테스트 파일이 있어야 한다. 체크 표시 목록은 테스트가 아니다.

셋, 화면의 숫자가 어디서 오는지 본다. 실시간처럼 보이는 숫자가 코드에 박혀 있으면, 그 화면은 아직 시안이다.

넷, 확인하지 못한 것은 확인하지 못했다고 쓰게 한다. 지금 내 서버에서 일하는 에이전트들의 작업 기록에는 '미확인'이라는 단어가 자주 나온다. 그 단어가 많은 보고서가 그 시절의 '100% 완성'보다 훨씬 믿을 만하다는 것을, 이 폴더를 열어 보며 배웠다.

이 연재는 다음 편이 마지막이다.

이 연재의 앞 편: ① 여러 AI에게 회의를 시키고 싶었다 · ② 클로드가 루프에 빠지면 Kiro를 켰다 · ③ 완성이라고 적힌 폴더를 열어 봤다

이 글이 확인한 방법

• 문서 수·작성자·날짜·진행률은 2025년 8월 당시 백업 폴더의 문서 원문에서 그대로 옮겼다.
• 구문 오류 수는 타입스크립트 구문 분석기로 파일을 읽어 센 값이다. 빌드 전체를 돌려 본 것은 아니다.
• '다섯이 다 답한 적은 없다'는 앱을 쓴 사람의 기억이다. 당시 사용 기록은 남아 있지 않다.
• 테스트 파일 0개는 3.0 소스 폴더 기준이다. 폴더 맨 위의 연결 확인 스크립트 1개는 따로 적었다. 지워진 버전에 테스트가 있었는지는 알 수 없다.