한 줄로
사람 없이 밤새 도는 AI 코딩 루프를 업무 프로젝트에서 만들어 운영했다. 핵심은 AI를 믿는 것이 아니라, AI가 “끝났다”고 말해도 믿지 않는 구조다. AI는 일만 하고, 합격 판정은 테스트와 git 을 직접 보는 프로그램이 낸다. 이 글은 7편 연재의 1편으로, 정의와 핵심 원칙만 다룬다.
무엇을 만들었나
태스크 목록을 주면, 매 사이클 새 AI 세션이 태스크 하나를 맡아 구현하고, 검문을 통과하면 머지한다. 사람은 저녁에 띄우고 아침에 결과와 멈춘 이유 한 줄을 읽는다.
비유하면 지치는 도우미가 교대로 들어오는 작업장이다. 도우미는 어제 일을 기억하지 못한다. 대신 벽에 붙은 작업표와 일지를 읽고 일을 이어받는다. 완성품은 도우미가 아니라 검수대가 통과시킨다.
핵심 원칙 다섯
운영하면서 굳은 것이 다섯이다. 뒤 편들은 전부 이 다섯 중 하나가 깨졌을 때의 이야기다.
- 품질의 상한은 계약이다. 루프의 결과는 태스크 정의(끝난 상태 한 문장, 테스트 명령, 고쳐도 되는 파일)를 넘지 못한다.
- 세션은 일하고, 판정은 프로그램이 한다. 완료 도장은 CLI 가 테스트를 다시 돌리고 git 에 직접 물어서 찍는다.
- 사이클 하나 = 새 세션 하나. 세션은 기억이 없고 상태 파일이 유일한 기억이다.
- 막히면 지어내지 말고 보류한다. 구현 실패와 “구현으로 풀 수 없는 것”을 갈라서, 뒤의 것은 사람에게 넘긴다.
- 장치는 사고가 난 뒤에 붙인다. 처음부터 전부 만들지 않는다. 근거 없이 잡은 숫자는 근거 없다고 적는다.
2번이 이 연재 전체의 축이다. 3편이 이 원칙이 깨졌을 때 무슨 일이 생기는지를 다섯 사례로 보여준다.
공들이는 곳이 코드가 아니었다
이 일을 하다 보면 사람이 공들이는 곳이 코드가 아니다. 계약, 검문, 재시도와 보류 규칙, 동시성 잠금을 설계하는 일이 대부분이다. 그래서 나는 이것을 루프 엔지니어링이라 부른다.
AI가 코드를 짜게 두되, 무엇을 만들지(계약)와 합격 기준(검문)을 사람이 설계해서 사람 없이도 밤새 돌아가게 만든 구조.
업계에 정착된 용어는 아니다. 이 연재에서의 뜻으로만 읽어 주면 된다.
검증된 방법론은 아니다
미리 밝혀둔다. 이건 완성된 방법론이 아니다.
- 시도 횟수 3, 보류 비율 40% 같은 임계값은 직관으로 잡았다. 운영하며 다듬는 중이다
- 사고가 날 때마다 장치를 하나 붙이는 식으로 자랐다. 설계가 먼저 있지 않았다
- 그래서 5번 원칙이 있다 — 내 프로젝트에서 그 사고가 날 수 있을 때만 붙인다
근거 없이 잡은 숫자를 “측정했다”고 쓰지 않는 것이 이 연재의 규칙이다. 6편에 그 규칙이 왜 생겼는지가 나온다.
연재 구성
| 편 | 제목 | 한 줄 요지 |
|---|---|---|
| 1 | 이 글 | 정의와 핵심 원칙 |
| 2 | 최소 뼈대 | 사이클 하나 = 세션 하나 = 태스크 하나 |
| 3 | 거짓 done | 원인이 다섯 번 다 달랐고, 그래서 검사를 겹쳤다 |
| 4 | 계약 | 금지는 값을 대신하지 못한다 |
| 5 | 게이트의 한계 | 테스트가 틀릴 때, 교차 회귀, 권한 |
| 6 | 밤새 돌리기 | 권한 우회의 대가, 병렬, 사람의 개입 |
| 7 | 기획까지 루프로 | 물음을 먼저 쓰고 답하게 한다 |
남는 교훈
“AI가 일을 잘하게 만드는 것”과 “AI가 거짓 완료를 못 하게 만드는 것”은 다른 문제다. 전자는 프롬프트의 일이고 후자는 구조의 일이다.
- 무인 루프에서 최악의 출력은 실패가 아니라 조용한 거짓 완료다. 실패는 아침에 보이지만 거짓 완료는 유일한 기억에 남아 다음 판단을 오염시킨다
- 그래서 판정 권한을 세션에서 떼어냈다. 세션은 구현하고 커밋만 하며, done 은 CLI 가 git 에 물어서 찍는다
- 지금은 사고가 날 때마다 “이게 계약 결함인가, 구현 실패인가, 장치가 필요한가”를 가르는 것으로 시작한다
남겨둔 것도 있다. 임계값 셋(시도 3회, 보류 40%, 사이클 3600초)은 아직 근거가 없다. 일지를 모아 조정할 계획이지만 이번 연재 범위는 아니다.