핵심: AI의 완료 보고, AI가 만든 집계, 내가 전달한 요청의 뜻은 각각 다시 확인해야 했다. 그래서 작업을 작게 나누고, 결과를 직접 검증하는 절차를 만들었다.

자료 범위: 기억 139개·세션 360개(2026-08-07~09-06). 한 달치 키워드 집계라 단순 지시도 섞여 있으며, 이전 세션 기록은 남아 있지 않다.

복습할 경험 네 가지

• 완료 보고와 숫자는 증거가 아니다. 편집 7건 중 3건만 반영됐는데도 성공 응답이 왔다. 집계가 멈춘 상태에서 나온 0을 근거로 판단한 적도 있다. 결과는 원본과 전수 대조하고, 지적은 재현해 확인한다.
• 한글은 입력할 때 더 위험했다. 「뒀고」가 「뙙고」로 바뀌었다. 찾을 문자열이 깨지면 작업이 실패하지만, 넣을 문자열이 깨지면 그대로 반영된다. 도구에 전달하는 한글을 1~3자로 줄이기 전 114회에서는 찾을 문자열이 깨져 튕긴 것이 7건, 줄인 뒤 1,133회에서는 7건이었다. 문서에 실린 깨짐은 양쪽 모두 0건이었다.
• AI가 요청의 뜻과 승인 범위를 넘겨짚었다. 「배치」를 순서가 아닌 구조 변경으로 받아들였고, 「플랜부터 줘」를 승인으로 오해해 노션 7장을 고쳤다. 계획 제시와 실제 수정의 경계를 먼저 확인한다.
• 긴 작업은 작게 나눠야 깊이를 유지하며 끝까지 진행할 수 있었다. 한 조각마다 산출물 하나와 검증 하나를 끝내고 다음으로 넘어간다. 완료 기준은 전체 결함 0건이 아니라 AI가 새로 만든 결함 0건이다.

루프와 분할

클로드 코드는 한 번 답하면 멈추고 사람의 다음 말을 기다린다. 그래서 일이 길어지면 두 가지 문제가 생긴다. 사람이 자리를 비우면 일이 멈추고, 한 대화에 일을 많이 넣으면 뒤로 갈수록 확인이 얕아진다. 루프와 분할은 이 두 문제를 푸는 방법이다. 둘 다 일을 조각으로 나눈 뒤에 쓰며, 다른 점은 그 조각을 누가 어떤 순서로 하느냐다.

루프 — 한 AI가 조각을 차례로 이어 간다

• 무엇인가: /loop는 같은 지시를 되풀이하도록 걸어 두는 명령이다. 간격을 주면 그 간격마다 다시 돌고, 간격을 빼면 AI가 한 차례를 마칠 때마다 다음 차례를 스스로 예약한다(1분에서 1시간 사이). 여기에 직접 만든 /unattended 스킬을 얹어, push·설정 파일 수정·바깥으로 나가는 쓰기처럼 정해 둔 자리에서만 멈추고 나머지는 묻지 않게 했다.
• 왜 필요했나: 「멈추지 마라」류 요청이 한 달 기록에서 163번 나왔다(키워드 집계). 사람이 자는 동안에도 일이 이어져야 했다.
• 어떻게 돌렸나: 매 차례는 진행 파일부터 읽고, 조각 하나를 만들고 검증한 뒤, 결과를 진행 파일에 적고 다음 차례를 예약한다. 녹스 서버 작업은 이렇게 09-14 낮부터 09-16 오후까지 약 52시간 동안 다음 차례를 88번 스스로 예약하며 이어졌다. 규칙 재배치(09-16)는 조각 18개를 루프로 끝냈고, 조각마다 자가검증을 돌려 26건을 잡았다.
• 막혔던 곳: AI가 답을 질문으로 끝내면 거기서 멈춘다. 무인으로 6시간 돌리는 동안 네 번 멈췄는데, 네 번 다 끝 문장이 물음표였다. 또 대화가 길어지면 앞부분이 요약되며 수치와 근거가 한 문장으로 뭉개진다. 그래서 조각의 결론과 근거는 그 차례 안에 진행 파일로 옮긴다. 루프를 걸지 않으면 한 차례만 돌고 끝나므로, 무인으로 시작할 때는 루프부터 건다.

분할 — 여러 AI가 조각을 나눠 맡는다

• 무엇인가: 메인 AI가 일을 떼어 서브에이전트(보조 AI)에게 맡기는 방식이다. 맡은 쪽은 빈 대화에서 시작해 그 조각만 하고, 결과 보고만 돌려준다. 여러 개를 동시에 띄울 수 있다. 주제마다 세션(대화 창)을 따로 여는 것도 같은 분할이다.
• 왜 필요했나: 한 대화에 파일 내용이 쌓일수록 대화가 무거워지고 확인이 얕아진다. 조각마다 빈 대화에서 시작하면 앞 조각의 짐을 지지 않는다. 조각끼리 서로 기대지 않으면 동시에 돌려 시간도 줄어든다.
• 어떻게 돌렸나: C# 학습 문서 9부를 검토할 때(08-30) 부별로 판정 에이전트 8개를 동시에 띄웠다. 발행본 대조와 노션 반영도 넷씩 두 번에 나눠 맡겼고, 이 대화에서만 에이전트 29개를 썼다.