본문 바로가기
강의

계획을 6명이 검토했는데, 실행하니 9개가 터졌다

설계 문서를 전문가 여럿이 통과시켜도 실제로 돌리면 결함이 쏟아진다. 검토가 잡는 문제와 실행이 잡는 문제는 종류가 다르기 때문이다. AI에게 일 시킬 때 '작은 실행 테스트'를 왜 미리 박아야 하는지 직접 겪은 사고로 풀었다.

레시피를 백 번 읽어도, 우리 집 오븐이 10도 높다는 건 실제로 한 번 구워봐야 안다. 계획서 검토는 레시피 읽기, 실행 테스트는 실제로 구워보기다.

이 글 3줄 요약

  • 문서를 아무리 꼼꼼히 검토해도 잡히지 않는 문제가 있다. 그건 오직 실제로 한 번 돌려봐야 드러난다.
  • 검토는 오타·모순·논리를 잡고, 실행은 환경·순서·버전 충돌을 잡는다. 둘은 다른 그물이라 한쪽만으론 절반만 거른다.
  • AI가 "다 됐습니다" 하면 "실제로 실행한 결과를 보여줘"라고 되물어라. 말이 아니라 실행 결과가 증거다.

나는 개발자가 아니라 AI에게 일을 시키며 개발을 배우는 사람이다. 그래서 초보가 계획 단계에서 빠지는 안심에 나도 똑같이 데인 적이 있다. "잘 세웠고 검토까지 마쳤으니 됐다"는 안심 말이다.

전문가 6명이 통과시킨 계획이 실행 한 번에 무너졌다

한 작업의 설계 문서를 전문가 여섯 명이 돌아가며 검토했고, 다들 "통과" 판정을 내렸다. 당연히 안심했다. 그런데 그 계획을 실제로 한 번 돌려보자마자 결함이 아홉 개나 튀어나왔다.

문서에선 하나도 안 보이던 것들이었다. 특정 환경에서만 나는 오류, 순서를 바꿔야 돌아가는 단계, 버전이 안 맞아 충돌하는 부분. 여섯 명의 눈이 부족했던 게 아니라, 애초에 읽어서 잡을 수 있는 종류의 문제가 아니었던 것이다.

검토와 실행은 서로 다른 그물이다

그물걸리는 문제
검토 (읽기)오타, 앞뒤 모순, 논리 구멍
실행 (돌리기)환경 오류, 실행 순서, 버전 충돌

두 그물에 걸리는 것은 겹치지 않는다. 그래서 한쪽만 쳐서는 딱 절반만 거른다. 여섯 명이 통과시켰다는 건 '읽어서 잡을 문제'가 없다는 뜻이지, '돌려도 문제없다'는 보장이 결코 아니었다.

레시피를 백 번 읽어도 우리 집 오븐은 모른다

계획서 검토가 레시피 읽기라면, 실행 테스트는 실제로 구워보기다. "다 검토했는데 왜 실행하니 터지죠?"라는 배신감은, 안 구워보고 레시피만 읽은 채 완성을 기대한 것과 같다.

AI에게 일 시킬 때 이렇게 박아라

  1. 계획을 통째로 끝까지 실행하지 말고, 첫 조각만 진짜로 돌려본다.
  2. 그 결과를 눈으로 확인하고 다음 조각으로 넘어간다.
  3. AI가 "완료했습니다" 하면 "실제로 실행한 결과를 보여줘"라고 되묻는다.

핵심은 전체를 다 짜고 마지막에 한 번 돌리는 게 아니라, 조각마다 "여기까지 진짜 돌아가는지" 확인점을 미리 넣는 것이다. 그래야 문제가 생겨도 어느 조각에서 터졌는지 바로 좁혀진다. 맨 끝에 한 번만 돌리면 터졌을 때 원인을 몰라 처음부터 다시 뒤진다.

딱 세 줄만 가져가세요

  • 검토를 여러 명이 통과시켜도 실행은 별개다. 사람 눈으로 못 잡는 종류의 문제가 따로 있다.
  • 오타·모순·논리는 검토로, 환경·버전·순서 충돌은 실행으로만 잡힌다.
  • AI가 "다 됐어요" 하면 "실제로 돌려서 결과를 보여줘"라고 되묻고, 조각마다 확인점을 미리 박아라.

계획을 다 검토했다고 안심이 될 때 딱 한 번만 더 의심하자. "이거 진짜 돌려봤나?" AI에게 일을 나눠 시키고 검증하는 더 넓은 이야기는 바이브코딩 강의 12편 — 프로젝트 운영과 검증에서 이어진다.

자주 묻는 질문

여러 사람이 검토해서 통과시킨 계획인데도 실행하면 문제가 생기나요?

생깁니다. 사람 눈으로 못 잡는 종류의 문제가 따로 있기 때문입니다. 검토는 오타, 앞뒤 모순, 논리 구멍처럼 '읽으면 보이는 것'을 잡습니다. 반면 내 컴퓨터 환경에서만 나는 오류, 순서를 바꿔야 돌아가는 단계, 프로그램 버전끼리의 충돌 같은 건 아무리 읽어도 안 보이고 실제로 돌려야 튀어나옵니다. 검토를 여러 명이 통과시켰다는 건 '읽어서 잡을 문제'가 없다는 뜻이지, '실행해도 문제없다'는 보장이 아닙니다.

그럼 검토는 의미가 없는 건가요?

아닙니다. 검토와 실행은 서로 다른 그물이라 둘 다 필요합니다. 검토 그물엔 오타·모순·논리가 걸리고, 실행 그물엔 환경·순서·버전 충돌이 걸립니다. 한쪽만으로는 절반만 거르는 셈입니다. 검토를 건너뛰라는 게 아니라, 검토를 마쳤다고 안심하고 실행 테스트를 생략하지 말라는 뜻입니다. 두 그물을 다 쳐야 새는 게 없습니다.

AI에게 일을 시킬 때 실행 테스트는 어떻게 넣나요?

전체를 다 만든 뒤 마지막에 한 번 돌리는 게 아니라, 조각마다 확인점을 넣는 게 핵심입니다. '여기까지 진짜 돌아가는지' 확인하는 지점을 계획 중간중간에 미리 박아두세요. 그러면 문제가 생겨도 어느 조각에서 터졌는지 바로 좁혀집니다. 반대로 전체를 다 짜고 맨 끝에 한 번만 돌리면, 터졌을 때 원인을 찾느라 더 오래 헤맵니다.

AI가 '다 됐습니다'라고 하면 그대로 믿어도 되나요?

'다 됐습니다'는 검증이 아니라 말일 뿐입니다. AI가 완료를 선언하면 '실제로 실행한 결과를 보여줘'라고 되물으세요. 말이 아니라 실행 결과가 증거입니다. 이 한마디를 습관으로 만들면, 나중에 터질 문제를 미리 잡아낼 수 있습니다. 완료 선언과 실제 작동 사이의 간극이 초보가 가장 자주 데이는 지점입니다.

조각마다 테스트하면 오히려 더 느려지지 않나요?

처음엔 느려 보일 수 있지만 전체로 보면 더 빠릅니다. 전체를 다 만든 뒤 한 번에 돌렸다가 터지면, 어디가 원인인지 몰라 전부 다시 뒤져야 합니다. 조각마다 돌리면 문제가 그 조각 안에 갇혀서 원인이 바로 좁혀지고, 고치는 범위도 작아집니다. 결국 다시 하는 횟수가 줄어 전체 시간이 짧아집니다.

관련 글