기획도 루프로 돌렸다 — 물음을 먼저 쓰게 했다

한 줄로

코딩 루프를 돌리고 나서 보니, 결함은 사람이 손으로 쓴 태스크 목록과 계약에서 나고 있었다(4편). 그래서 그 둘도 루프가 만들게 했다. 핵심은 시험 문제를 내는 패스와 답안을 쓰는 패스를 가른 것이다. 단, 코딩 루프가 안정된 다음에 했다.

기획서도 태스크로 돈다. 다만 코드 대신 문서를 만든다. 시험 문제를 내고 답안을 쓰는 순서다.

물음 쓰기 — AI 가 정본 문서를 읽고 “이 모듈은 무엇을 어떻게 해야 하나”를 물음 목록으로 쓴다. 물음마다 답의 최소 길이를 정한다
답하기 — 다른 패스가 물음 하나하나에 답해 기획서를 쓴다. 물음 파일은 읽기 전용이다
기계 채점 — 답 절이 다 있는가, 길이를 채우는가, 금지어(TBD, TODO, 미정, 추후)가 없는가만 본다
리뷰 채점 — 별도 리뷰 에이전트가 “답이 옳은가”를 본다

2번의 읽기 전용이 이 설계의 전부다. 답하는 쪽이 문제를 쉽게 고쳐 쓰지 못하게 하려는 것이다. 물음이 틀렸으면 고치지 않고 보류한다.

3번의 금지어 검사는 모르는 것을 채워 넣지 말고 보류로 올리라는 뜻이다. TBD 를 쓸 수 있으면 AI 는 모르는 칸을 그걸로 메운다.

4번의 리뷰어는 인용한 조문을 실제로 열어 확인하고, 정본이 안 정한 것을 정한 것처럼 쓰지 않았는지 본다.

다음 태스크는 개발계획, 계약, 코딩 루프가 읽을 태스크 목록을 만든다. 기계는 세 가지만 잰다.

두 번째가 왜 기계 검사인지가 중요하다. 보안 점검이 결함을 찾아도 고칠 자리가 없는 일이 세 번 연속 났기 때문이다. 5편에서 공격 7건 중 6건이 성공한 그 점검이, 찾기만 하고 끝났다.

범위를 빠짐없이 담았는지, 태스크 크기가 적당한지, 파일 소유가 맞는지, 계약 값이 정본과 같은지는 리뷰 에이전트가 본다. 이건 기계로 잴 수 없다.

계획이 나오면 루프는 일부러 멈춘다. 자동으로 코딩으로 넘어가지 않는다.

사람은 만들어진 태스크 목록과 계약을 보고, 괜찮으면 코딩을 띄운다. 나쁘면 계획 단계만 다시 돌린다. 기획서는 그대로 쓴다.

이 자리가 사람의 리뷰 승인을 대신한다. 루프로 기획을 돌리면 계획을 사람이 한 번도 안 본 채로 구현이 시작될 수 있다. 그 대가를 기계 검사와 이 정지 지점이 갚는다.

기획이 만든 인수 테스트가 기획 브랜치에만 있고 코딩 base 의 조상이 아니었다.

코딩 루프는 테스트 파일이 없어 컴파일도 못 했고, 태스크 13개가 전부 보류됐다. 사람에게 맡긴 “브랜치 이어 붙이기” 한 줄을 잊은 탓이었다. 지금은 스크립트가 직접 이어 붙인다.

반대 방향 사고도 있었다. 메인보다 수백 커밋 뒤처진 낡은 base 에서 갈라진 브랜치를 그대로 머지했다면 약 9.7만 줄이 되돌려질 뻔했다. 그래서 띄우기 전에 두 브랜치가 서로 몇 커밋 앞서고 뒤졌는지를 잰다.

기획 이전의 “무엇을 만들지 정하는 단계” 는 루프 밖에 남긴다.

사업 요구를 정하고 큰 모듈을 나누는 일은 사람과의 대화가 본질이기 때문이다. 그 단계에서도 AI 는 초안을 쓰고 검토를 돕지만, 결정은 사람이 한다.

시험 문제를 내는 쪽과 답하는 쪽을 가르면, 답하는 쪽이 문제를 쉽게 만들 수 없다.

연재를 마치며 한 줄로 줄이면 이렇다.

자동화할수록 사람이 더 공들여야 하는 곳은 “무엇을 만들지”와 “어떻게 판정할지”다.

남겨둔 것 — 기획 루프의 리뷰 채점은 여전히 리뷰 에이전트에 기댄다. “범위를 빠짐없이 담았는가”를 기계로 재는 방법은 모른다. 7편 전체 목록은 1편에 있다.