사람은 의도와 계약을 갖고, AI는 루프를 돌린다: 계약 루프 개발의 방법론

계약 루프 개발(Contract Loop Development)은 AI 에이전트에게 코드를 작성하도록 하는 것을 전제로 제가 구축하고 있는 개발 진행 방식입니다. 정해진 것은 간단합니다. 사람이 책임지는 부분은 '무엇을 위해 만들 것인가 (의도)'와 '무엇이 일어나면 완성으로 간주할 것인가 (계약)' 두 가지뿐입니다. 구현, 검증, 합류는 AI의 루프에 맡깁니다. 어디까지 맡길지는 변경 리스크를 기준으로 결정하며, 실적 수치가 좋아지면 사람의 개입을 줄여나갑니다.

이 글은 연재의 첫 번째 글로 전체적인 그림만 다룹니다. 왜 이런 형태가 되었는지, 전체가 무엇으로 구성되어 있는지, 어떤 규칙으로 작동하는지, 그리고 하나의 변경 사항이 최종적으로 적용되기까지의 흐름입니다. 스크립트나 설정에 대한 세부적인 이야기는 다음 글에서 다루겠습니다.

AI가 작성하는 속도와 검증하는 속도의 괴리

AI에게 코드를 작성하게 하면, 작성 속도는 확실히 빨라집니다. 하지만 작성된 것이 올바른지 확인하는 속도는 거의 변하지 않습니다. 검증하는 것은 결국 사람이나 테스트이기 때문입니다. 이 차이가 있으면, 출력이 늘어날수록 검증할 수 없는 것들이 쌓이게 됩니다.

저만의 문제는 아닌 것 같습니다. 외부에서 세 가지 움직임을 꼽아보겠습니다.

첫 번째는 Andrej Karpathy의 발언입니다. 그는 2025년 2월 게시물에서 AI의 출력에 의존하여 코드의 존재조차 잊어버리는 개발을 '바이브 코딩(Vibe Coding)'이라고 불렀습니다. 그는 그로부터 1년 후에는 LLM 에이전트를 통한 프로그래밍이 전문가들의 표준적인 흐름이 되어가고 있지만, 감독과 정밀 검토는 이전보다 더 많이 필요하다고 적었습니다. 현재 제가 좋아하는 명칭은 '에이전틱 엔지니어링(Agentic Engineering)'입니다. 이는 코드를 직접 작성하는 것이 아니라, 작성하는 에이전트를 지휘하고 감독하는 입장에 놓인다는 의미를 담고 있습니다 (The New Stack, 2026년 2월 10일 기사).

두 번째는 DORA의 2025년판 조사입니다. 약 5,000명의 기술직 종사자를 대상으로 한 조사를 바탕으로 AI의 주된 역할은 증폭기(Amplifier)라고 보고 있습니다. 조직의 강점과 약점 모두 AI에 의해 커진다는 것입니다. 반면, 보상은 도구 자체보다는 조직의 시스템 측면에서 발생한다는 내용도 담겨 있습니다.

세 번째는 '루프 엔지니어링(Loop Engineering)'입니다. 이는 2026년 6월경부터 실무자들 사이에서 사용되기 시작한 용어로, arXiv 논문에 실려 있습니다 (심사 중이라고 표시된 프리프린트). 에이전트에게 매번 지시를 내리는 것이 아니라, 에이전트에게 지시를 내릴 '시스템' 자체를 설계하는 것입니다. 이 시스템은 주기적으로, 또는 리포지토리에서 무언가 발생했을 때 에이전트를 구동하고, 기계적으로 검증 가능한 조건이 충족되면 멈춥니다. 논문에서는 잘 만들어진 루프의 요소로 기계적 검증이 가능한 정지 조건, 상태를 보존하는 파일, 검증 담당자, 사람에게 인계하는 지점 등을 제시했습니다.

이 세 가지에서 제가 읽어낸 것은, AI가 작성하는 양이 늘어날수록 결과물을 결정하는 것은 '검증하고 멈추는 시스템'의 완성도라는 것입니다. 이는 저의 해석입니다. 계약 루프 개발은 이 시스템을 사람의 주의력에 의존하지 않고 문서와 스크립트로 구성하기 위한 방법론입니다.

AI와 혼자 제품을 만들면서 실제로 부딪혔던 문제들을 나열하겠습니다. 오른쪽 열이 이 방법론으로 해결하는 방식입니다.

전체는 '의도・계약・루프' 3층으로 구성되어 있다

위쪽 층일수록 사람이 가지고, 아래쪽 층일수록 AI가 가집니다. 층과 층을 연결하는 것은 대화가 아니라 문서와 스크립트입니다. 대화는 다음 세션으로 가져갈 수 없지만, 리포지토리는 남기 때문입니다.

의도(Intent)는 목적, 업무 용어, 업무 경계, 미완성 요구사항 등 사람이 결정합니다. 업무 용어는 용어집에 모으고, 사양과 코드, 화면 모두 이 용어집에 있는 단어만 사용합니다. 새로운 단어는 사람이 승인한 후에 추가합니다. 단어가 갖춰지면 AI의 설명이 짧아지고, 코드 이름도 일관성을 가지기 때문입니다.

계약(Contract)은 WHEN(무엇을 했을 때)과 THEN(무슨 일이 일어날지) 형태로 작성된 시나리오입니다. '계약'이라고 부르는 이유는 사람과 AI 사이에 '여기까지 하면 완성'으로 합의하는 문서이기 때문입니다. AI가 초안을 작성하고 사람이 승인하는 순간 성립합니다.

루프(Loop)는 구현하고, 검증하고, 심사하고, 통합하기까지의 반복 과정입니다. 돌리는 것은 AI이지만, 통과 여부, 멈출지 여부, 통합해도 좋을지는 AI에게 결정하게 하지 않습니다.

원칙: 나중에 추적할 수 있는 형태로 맡기기

이 방법론의 규칙은 모두 '맡긴 결과를 나중에 기계적으로 추적할 수 있도록 하는 것'에 있습니다.

사람이 가진 것은, 의도와 계약뿐

목적, 업무 용어와 경계, 시나리오로 작성된 수용 조건은 사람이 결정합니다. 어떻게 만들지는 사람도 규칙도 지정하지 않습니다. 절차까지 지시하면, 모델이 진화했을 때 그 지시가 발목을 잡는 역할을 하기 때문입니다. 태스크 목록에도 적는 것은 '어떤 시나리오를 충족해야 완료인가'뿐입니다.

정확성을 결정하는 곳은 하나로 통일한다

판단 역할은 3가지 스크립트에 고정되어 있습니다.

• 합격/불합격 여부는 verify가 결정합니다
• 루프를 멈출지 여부는 stop-gate가 결정합니다
• 병합해도 되는지는 merge-gate가 결정합니다

문서로 작성된 규칙이나 AI의 자체 판단으로는 합격/불합격을 결정하지 않습니다. 판단 장소가 여러 곳에 있으면, 루프가 멈췄을 때 어느 것이 멈춘 것인지 알 수 없기 때문입니다.

stop-gate는 AI가 작업을 마치려 할 때 호출되는 후크(hook)입니다 (Claude Code의 Stop Hook을 사용합니다). 검증을 실행하여 PASS이면 종료를 인정하고, FAIL이면 종료를 멈추며, 실패 내용을 AI에게 반환합니다. AI가 남은 길은 수정하는 것뿐입니다.

다만, 계속 멈춰 있기만 해서는 막힌 루프가 영원히 돌게 됩니다. 그래서 stop-gate는 실패 내용에서 '지문(fingerprint)'을 만들어 이전과 비교하고, 같은 실패가 3번 연속될 경우 등에는 사람에게 인계하여 종료를 인정합니다. 인계 기록은 나중에 원인을 조사할 자료가 됩니다. 앞서 논문의 '사람에게 인계하는 지점'에 해당합니다.

어디까지 맡길지는 리스크로 결정하고 실적으로 확장한다

변경의 리스크는 변경한 파일의 경로만으로 기계적으로 결정합니다. 무엇이 위험한지는 사람이 프로젝트별로 결정하여 설정에 적어둡니다. 예를 들어 인증이나 데이터베이스 마이그레이션과 관련된 곳은 high, 어디에도 해당하지 않는 변경은 low입니다. 자율도는 3단계가 있습니다.

올리는 기준은 최근의 병합(초기값 20건)에서의 '수정률'과 '병합 후 결함'입니다. 수정률은 사람이 손으로 수정한 커밋을 포함한 변경의 비율로, AI 커밋에 붙는 트레일러 유무로 계산합니다. 엄밀하지 않고 근사치입니다. 기준을 충족해도 올릴지 결정하는 것은 사람입니다. 모델이 좋아지면 수정률은 자연스럽게 떨어지고, 시스템을 재구축하지 않아도 맡길 범위가 넓어집니다.

시스템은 실패로부터 키우고, 필요 없어지면 제거한다

처음에는 최소 구성으로 시작합니다. 부품을 추가하는 것은 실패 원인을 조사하여 그 부품이 없으면 같은 실패를 막을 수 없다고 알았을 때만 합니다. 추가하기 전에 그 실패를 재현하는 평가 케이스를 작성합니다. 시스템 자체에 대한 테스트 주도입니다.

개선을 적용할 곳은 자동 검사, 용어집, 사양, 지시문 순으로 생각합니다. 문서의 규칙은 최후의 수단입니다. 문서는 늘릴수록 AI가 매번 읽어야 하는 양도 늘어나지만, 자동 검사는 아무리 많이 추가되어도 읽는 양은 변하지 않습니다.

모든 부품에는 '현재 모델로는 무엇이 불가능하다고 가정하고 있는지'를 적어두고, 그 가정이 무너지면 제거합니다. 부품은 2가지 종류가 있습니다. 판단이나 독립적인 심사처럼 모델의 능력과 관계없이 남기는 것과, 현재 모델의 약점을 보완하는 임시적인 것이 있습니다. 임시 부품은 분기별 1회 또는 새로운 모델이 나올 때마다 하나씩 제거하고 평가 케이스를 다시 돌립니다. 결과가 악화되지 않으면 제거 후보입니다.

Anthropic의 엔지니어링 블로그에도 비슷한 생각이 있습니다. 시스템 부품들은 모두 '모델이 단독으로는 할 수 없는 것'에 대한 가정을 포함하며, 그 가정은 잘못되었거나 금방 구식이 되기 때문에 반복해서 확인할 가치가 있다는 취지입니다. 새로운 모델 등장에 맞춰 부품을 제거하고 구성을 단순화해 온 경위도 적혀 있습니다 (2026년 3월 24일). 추가하는 것보다 제거하는 것이 더 어려우므로, 제거 절차는 처음부터 포함시켜 놓습니다.

하나의 변경이 착지할 때까지

가상의 재고 관리 앱에 '주문을 취소할 수 있게 하고 싶다'라는 요구사항이 온 상황을 따라갑니다.

1. /align: 질문에 답하고, 계약을 만든다

AI는 바로 작성하지 않습니다. 하나씩 질문합니다. '출하가 시작된 주문도 취소할 수 있나요?', '취소는 누가 할 수 있나요?'

답변을 듣는 과정에서 용어집에는 없는 '출하 준비'라는 단어가 나왔습니다. AI는 의미와 코드상의 이름을 제안하고, 사람이 승인한 후에 용어집에 추가합니다.

요건(要件)은 하나의 업무 경계 내에서 동작을 변화시키는 것이므로, 변경의 종류는 M입니다. 종류는 시제품으로 답을 도출하는 탐색과 S·M·L의 4가지입니다. S는 동작이 변하지 않는 수정이고, L은 신기능이나 여러 경계를 넘나드는 변경이라서 무거울수록 절차가 늘어납니다.

AI는 변경 폴더 add-order-cancel을 만들고 다음과 같은 시나리오를 작성합니다.

#### Scenario: 출하 준비 전이라면 취소 가능
- **WHEN** 판매자가, 출하 준비에 들어가기 전의 주문을 취소한다
- **THEN** 주문 상태가 '취소'가 되고, 재고 할당이 해제된다

사람이 이 시나리오를 승인하면, 계약이 성립됩니다. 요건 인덱스(backlog)의 해당 행은 '진행 중(add-order-cancel)'이 되고, 본문은 사양의 차분으로 이동합니다. 요건의 본문은 미착수일 경우 인덱스에, 진행 중일 경우 사양의 차분에, 완료일 경우 정본에 위치가 바뀌지만, 어떤 시점에서도 한 곳에만 존재합니다. 검사용 스크립트가 확인하여 본문이 두 곳에 있으면 verify가 실패합니다.

2. 루프: 테스트에서 구현까지

사람은 run-change.sh add-order-cancel
을 실행합니다. AI는 태스크 목록의 시나리오를 하나씩, 테스트부터 구현해 나갑니다.

도중에 작업을 끝내려고 할 때 Stop 훅(hook)이 검증을 실행하고, 테스트가 1건 실패했음을 보여주며 종료를 막았습니다. AI는 원인을 고치고, 검증의 마지막 줄이 VERIFY: PASS
이 된 곳에서 루프가 완료됩니다.

완료 조건은 '태스크가 모두 완료되고, 마지막 검증이 PASS인' 단 하나입니다. 검증에는 타입 체크와 테스트 외에, 테스트 무효화 감지도 포함되어 있습니다. 테스트를 약하게 하거나 무효화해서 통과하는 지름길은 여기서 막힙니다.

3. /land: 구현 과정을 모르는 입장에서 심사하기

계속 /land가 작동합니다. reviewer 에이전트가 차분과 계약만 보고 심사하여 합격 판정을 내렸습니다. 구현 과정을 모르기 때문에, 구현한 쪽에 관대하지 않습니다.

화면 변경은 없으므로, 화면을 평가하는 에이전트는 호출되지 않습니다. 화면에 관련된 변경이라면, 실제로 화면을 조작해서 점수를 매깁니다. 평가를 생략할 수 있는 것은 사람이 그때그때 결정했을 때뿐이며, 결정한 사람과 이유는 기록으로 남습니다. 평가에서 불합격되면 /retro로 넘어가 원인을 조사합니다.

4. merge-gate: 합류해도 되는지 결정하기

merge-gate는 이 변경의 위험을 low로 판정했습니다. 다만, 자율 레벨은 아직 A1이므로, 판정은 '사람의 승인이 필요'합니다.

사람이 요점을 확인하고 승인하면, merge-gate는 변경을 정본에 반영하고, 인덱스의 행을 '완료'로 하여 기준 브랜치에 합류시킵니다. 사양의 정본은 직접 편집할 수 없습니다. 업데이트할 수 있는 것은 검증과 심사를 거쳐 승인된 변경을 아카이브할 때뿐입니다.

이 흐름에서 사람이 손을 움직인 곳은 3군데였습니다. 질문에 대한 답변, 용어와 시나리오의 승인, 합류의 승인입니다. 자율 레벨이 올라가면 마지막 승인도 필요 없어집니다.

확인한 범위

특정 AI 도구에 대한 의존성도 적어둡니다. 사양 작성 방식, 스킬 형식, 판정 스크립트는 특정 도구에 의존하지 않습니다. Claude Code에 의존하는 것은 Stop 훅, 권한 설정, 완료 조건까지 작업을 계속하게 하는 /goal 세 가지입니다. 다른 도구에서 사용할 경우, 이 3가지를 해당 도구의 메커니즘으로 대체합니다.

참고

• Karpathy의 발언 (The New Stack): https://thenewstack.io/vibe-coding-is-passe/
• DORA 'State of AI-assisted Software Development 2025': https://dora.dev/dora-report-2025/
• 동일 (Google Research, 조사 인원수는 여기): https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/
• 'Loop Engineering: Building Blocks, Adoption, and Impact' (arXiv): https://arxiv.org/abs/2608.21884
• Anthropic 'Harness design for long-running application development': https://www.anthropic.com/engineering/harness-design-long-running-apps

다음 연재 예정

• 계약 만들기: /align 대화와 시나리오 작성 방법
• 판단을 한 곳에 두기: verify, stop-gate, merge-gate의 역할 분담
• 위임 범위를 넓히기: 리스크 결정 방법과 자율 레벨 높이기
• 실패로부터 시스템 키우기: /retro, 평가 케이스, 빼는(축소하는) 순서

순서와 내용은 작성하면서 변경될 수 있습니다.

이 글은 AI를 활용하여 초안을 작성했으며, 저자가 내용을 확인했습니다.

Discussion