1월에 「AI 부하 10명」 기사를 쓴 이후로, 계속 같은 실험을 이어오고 있다. 다만 대상은 코드가 아니다. 조사, 문서 작성, 수신함 처리, 정례 회의 준비. 이른바 지적 노동의 잡다한 모든 것을 Claude Code의 루프(Loop)에 실어 돌려왔다.

결론부터 말하자면, 돌아간다. 다만 코딩 에이전트(Coding Agent)의 설계를 그대로 가져오면, 2주 정도 지나면 깨닫게 된다. 이 루프에서 가장 중요한 부품은 루프 안에 있지 않다.

그 이야기를 하려 한다.

루프 엔지니어링(Loop Engineering)이란 무엇인가, 30초 요약

올해 6월에 이름이 붙은 사고방식이다. 에이전트의 정체는 「while 루프 안의 LLM」이며, 설계해야 할 것은 프롬프트(Prompt)의 문구가 아니라 루프 그 자체다. 구체적으로는 다음 4가지다.

트리거(Trigger): 언제 움직이기 시작하는가 -
토폴로지(Topology): 누가(어느 에이전트가) 무엇을 담당하는가 -
검증기(Verifier): 자신의 일을 어떻게 체크하는가 -
정지 규칙(Termination Rule): 언제 멈추는가 -

자세한 해설은 이미 좋은 글들이 많으므로 끝부분의 링크에 양보하겠다. 여기서 말하고 싶은 것은 단 하나, 현재 이 담론은 거의 100% 개발자의 세계 이야기라는 점이다. Worktrees, CI, 서브 에이전트(Sub-agent), 코드 리뷰(Code Review). 정비해야 할 인프라로서 연결되는 것은 전부 코드를 쓰는 팀의 도구들이다.

개인 스케일로 가져오는 것은 goryugo 님이 개인의 지식 관리에서 실천하고 있으며, 이는 좋은 글이므로 먼저 읽어보길 권한다 (비엔지니어를 위한 Claude 루프 엔지니어링). 본고는 그 옆자리에 앉는다. 아웃풋(Output)이 자신 이외의 인간에게 전달되는 일, 즉 업무 스케일로 돌리면 어떻게 되는가에 대한 이야기다.

코딩과 다른 점은 3가지가 있다

1. 검증기가 테스트가 아니다

코드에는 assert가 있다. 문서에는 없다. "그럴싸하지만 틀린" 출력은 컴파일 에러(Compile Error)를 내지 않고 조용히 통과한다. 업무 루프에서 처음 부딪히는 벽은 바로 여기다.

하지만 포기하기엔 이르다. 문서에도 기계적으로 검증할 수 있는 층이 분명히 존재한다.

표기 및 용어의 lint: 금지 표현, 흔들리는 용어, 무너진 표기법. 정규 표현식(Regular Expression)으로 잡을 수 있는 것은 전부 잡는다 -
정본(正本)과의 대조: 용어집, 결정 기록, 과거의 성과물과 모순되지 않는가. "어딘가에 올바른 리스트가 있다" 타입의 주장은 대조를 자동화할 수 있다 (이 「정본」을 만드는 방법은 후반부에서 자세히 다룬다) -
날짜와 요일의 검산: 인간도 AI도 요일을 틀린다. 캘린더 계산으로 넘길 수 있는 것은 기계에 맡긴다 -
구조의 정합성: 본문을 수정했는데 목차, 변경 이력, 관련 부분이 옛날 그대로인 상태를 검출한다

포인트는 의미의 정확성까지 기계에게 판단하게 하려 하지 않는 것이다. 기계로 판단할 수 있는 층만 기계에 맡기고, 의미의 판단은 인간의 일로 남겨둔다. 그럼에도 체감상 에러의 과반수는 이 기계 층에서 막힌다. 정합성 주도 개발(CoDD)에서 했던 "가짜 성공을 방지한다"라는 사상의 업무 버전이라고 생각하면 된다.

2. 트리거는 「이벤트」보다 「시각과 수신함」

개발 루프는 이벤트 주도(Event-driven) 방식이 잘 어울린다. Issue가 생성되면 움직이고, CI가 실패하면 고친다. 업무 루프의 기점은 훨씬 수수하며, 시각과 수신함이다.

• 아침 일찍: 오늘의 상황 정리(예정, 기한, 미독, 미처리)를 한 장으로 요약
• 주간: 정례 회의 준비 일체를 요일 고정으로 사전 준비
• 수시: 수신함에 무언가 들어오면 분류하여 초안 작성까지 진행

또 하나, 굳이 멈추는 시간을 만드는 것도 업무 측면의 지혜다. 우리 루프는 야간에는 돌리지 않는다. 사고 방지라기보다는 리뷰 속도와의 균형 문제인데, 자율 실행의 성과물은 인간이 읽는 속도를 쉽게 초과한다. 읽히지 않는 성과물이 쌓이는 것은 팔리지 않는 재고가 쌓이는 것과 같다.

3. 출구에 undo가 없다

이것이 결정적인 차이다. 코드의 실패는 머지(Merge) 전이라면 내부 사고로 끝난다. 업무의 출력은 다르다. 보낸 채팅은 취소할 수 없다. 공유한 문서는 읽힌다. 외부로의 답변은 남는다.

즉 업무 루프에서는 「생성의 실패」보다 「전송의 실패」가 차원이 다르게 비용이 크다. 그리고 검증기와 정지 규칙을 아무리 다듬어도 이 문제는 해결할 수 없다. 생성물이 완벽하게 정확하더라도, "그것을 지금, 그 상대에게, 에이전트의 독단으로 보내도 되는가"는 별개의 문제이기 때문이다.

제4의 설계 대상: 「맡겨도 되는가」의 설계

그렇기에 업무 루프에는 트리거, 토폴로지, 검증기, 정지 규칙에 더해 네 번째 설계 대상이 필요하다. 맨데이트(Mandate, 권한과 책임)의 설계다. 무엇을 에이전트의 독단으로 하게 할 것인지, 무엇을 인간의 승인 단계로 넘길 것인지.

나의 구현은 허탈할 정도로 단순하며, 조작을 두 종류로 나누는 것뿐이다.

• 내향적 조작 (Internal Operations) (초안 작성, 분석, 정리, 로컬 파일 조작): 에이전트의 독단으로 전 자동 수행
• 외향적 조작 (External Operations) (전송, 공개, 정본(正本)의 쓰기 작업): 실행하지 않고, **승인 큐 (Approval Queue)**에 쌓음

전체적인 모습은 다음과 같다.

에이전트는 외향적 조작에 부딪히면, 실행하는 대신 큐에 한 건을 작성하고 다음 업무로 넘어간다. 인간은 하루에 몇 번 큐를 열어 승인·수정·거절을 처리한다. 이것만으로도 「자율의 속도」와 「취소할 수 없는 사고 제로」를 양립할 수 있다.

큐의 엔트리(Entry)는 다음과 같은 형식을 취하고 있다.

## Q-2026-07-25-01
- 유형: 전송 (채팅 답장 초안)
- 수신인: ○○님
...

가장 효과적인 것은 「망설임」란이다. 승인하는 인간이 전문을 정독하지 않더라도, 어디를 보면 출하 판정을 내릴 수 있는지를 에이전트 측에서 신고하게 한다. 이렇게 하면 큐 처리는 건당 수십 초 내에 끝난다. 반대로 이 칸이 없으면 인간이 모든 결과물을 정독해야 하는 상황이 벌어지며, 루프의 속도 이점이 승인 단계에서 전부 녹아 없어진다.

이 메커니즘이 필요하다는 것을 뼈저리게 느낀 것은, 사실 반대편의 사고 때문이었다. 어느 심야, 큐를 거치지 않고 내 손으로 직접 답장을 보냈는데, 상대방 이름의 한자를 한 글자 오기입한 채로 보내버렸다. 문장은 완벽했다. 생성은 성공했으나, 전송이 실패한 것이다. 다음 날 아침의 첫 업무는 사과가 되었다. 이후 이름과 고유명사는 연락처의 정본(正本)과 대조하는 lint를 검증기에 추가했고, 외부로 나가는 것은 예외 없이 큐를 통하게 하고 있다. 인간은 큐 안에서는 검증기이지만, 큐 밖에서는 최약의 실행기다.

이 계층, 부품이 나오기 시작했다. 하지만 설계론은 아직 없다

approval layer라는 용어가 올해 상반기부터 유통되기 시작했고, 승인 게이트를 제공하는 SDK도 있으며, Microsoft는 Agent Governance Toolkit을 내놓았고, OWASP는 Agentic Top 10을 발표했다. EU의 AI 규제 고위험 의무도 올해 8월에 시작된다. 방 안은 이미 만원이다.

「그거 HITL (Human-in-the-loop) 아니냐」라는 말을 들을 수도 있겠지만, 절반만 맞다. 구조는 HITL이다. 다만 HITL은 「인간을 루프에 넣어라」라는 부품의 이름일 뿐, 어디에 넣을지, 에이전트에게 무엇을 신고하게 할지 (근거·undo 가능성·망설임), 거절 이유를 어떻게 루프의 자산으로 바꿀지, 맡기는 범위를 어떻게 넓혀갈지——를 결정하는 설계의 언어가 아니다. 정지 버튼이 있는 것과, 언제 멈출 것인가에 대한 설계가 있는 것은 별개의 문제다.

즉, 모두 「도구」나 「컴플라이언스 (Compliance)」의 언어로 이야기되고 있다. 루프 설계의 4번째 요소로서, 즉 실무자가 매일 만지는 설계 대상으로 이 계층을 두고 있는 글은 내가 찾은 범위 내에서는 없었다. 그래서 여기에 두려 한다.

3번째까지는 「어떻게 움직일 것인가」의 이야기이고, 4번째만이 「어디까지 맡길 것인가」의 이야기다. 실험실을 나와 업무에 적용할 때 결정적인 것은, 경험상 압도적으로 후자였다.

루프가 읽는 「정본」을 만든다. SSOT의 설계

여기까지 오면서 한 가지 설명을 생략했던 용어가 있다. 검증기 부분에서 나왔던 **「정본과의 대조」**의, 정본(正本)이다. 그리고 4층 등식의 1층인 「컨텍스트 (Context) 설계」의 업무 버전 정답도 사실 이것이 된다.

SSOT (Single Source of Truth)라는 용어가 익숙하지 않은 분들을 위해 먼저 설명해 두겠다. 「이 정보의 정답은 반드시 여기에 있다」라고 정해진 장소를 단 한 곳만 결정해 두는 사고방식이다. 안티 패턴(Anti-pattern)이 더 유명한데, 폴더에 「최종본_v2_수정(3).xlsx」가 5개 나열되어 있어 어떤 것이 진짜 최종본인지 아무도 모르는 상태, 바로 그것이다. 그 반대로 하는 것이다. 동일한 사실을 두 곳 이상에 적지 않는다. 적는 것은 한 곳이며, 다른 곳에서는 그곳을 참조한다. 데이터베이스 설계 세계에서는 고전적인 원칙이지만, 이것을 자신의 업무 맥락 그 자체**에 적용하는 것이 바로 여기서 말하는 내용이다.

에이전트의 루프는 매번 기억이 없는 상태로 일어난다. 코드의 세계라면 리포지토리(Repository) 자체가 문맥이 되어준다. 업무의 문맥은 다르다. 무엇이 결정되어 있는지, 누가 무엇을 언제까지 하는지, 이 용어는 무엇을 가리키는지. 내버려 두면 이것들은 인간의 머릿속과 채팅 기록 깊숙한 곳, 회의 메모 더미 속에 흩어진다. 그 상태로 루프를 돌리면 에이전트는 매번 당신에게 물으러 온다. 그것은 루프가 아니라, 그저 질문이 많은 부하일 뿐이다.

그래서 업무 루프의 토대로서, 이 정본을 디스크 상에 만든다. 나의 최소 세트는 4개의 파일이다.

decisions.md: 무엇이 결정되었는가 (그리고 무엇이 효력을 상실했는가) -
tasks.md: 누가・무엇을・언제까지 (그리고 그 태스크가 어디에서 왔는가) -
glossary.md: 용어를 무엇이라 부르는가 -
people.md: 등장인물과 역할

설계 원칙은 두 가지만 있다.

원칙 1: 출처와 정본(Source of Truth)을 분리한다. 회의 메모·전사(Transcription)·채팅 로그는 '출처'이지 정본이 아니다. 회의 기록으로부터 결정 사항·태스크·용어·인물을 추출하여 정본에 기록한다. 정본은 단 한 곳에만 작성하며, 출처로는 링크를 통해 추적할 수 있도록 한다. 이를 수행하지 않으면 동일한 사실의 서로 다른 버전이 여기저기 증식하여, 에이전트(Agent)가 무엇을 믿어야 할지 알 수 없게 된다. 인간도 알 수 없게 된다.

참고로 Microsoft가 Work IQ에서 시작한 것은 이와 반대되는 접근 방식으로, 흩어진 출처 측을 테넌트(Tenant) 전체에서 똑똑하게 읽어내는 것이다. 나는 정본 측을 확정 짓는 파다. 문맥(Context)은 추정하는 것이 아니라, 승인하여 확정하는 것이라고 생각한다.

원칙 2: 결정은 지우지 않는다. 교체한다. decisions.md는 추가 전용으로 한다. 결정이 바뀌면 오래된 행을 지우는 것이 아니라, 새로운 결정에 ✅와 교체 원본으로의 포인터를, 오래된 결정에 ⚠️와 교체 대상(Destination)으로의 포인터를 붙여 둘 다 남긴다. 파일 도입부에는 '현재 유효한 결정' 인덱스를 둔다.

## 현재 유효한 결정 (인덱스)
| topic | 최신 | 요약 |
|---|---|---|
...

엔지니어식으로 말하자면, 이것은 **의사결정의 이벤트 소싱 (Event Sourcing)**이다. 시계열의 본체는 이벤트 로그(Event Log)이고, 도입부의 인덱스는 마테리얼라이즈드 뷰(Materialized View)다. '지금 무엇이 유효한가'는 인덱스를 본다. '왜 이렇게 되었는가'는 동일한 topic을 시계열로 거슬러 올라간다.

이렇게 하면 회의에서 자주 발생하는 그 시간이 사라진다.

A: "그 건 어떻게 됐더라?"
B: "그 건이라니, 어떤 건 말이야?"
C: "무슨 말씀이세요?"

세 사람의 기억이 제각각 퇴화하여, 내용을 맞추는 데만 5분이 녹아내리는 바로 그것이다. decisions.md를 topic으로 grep 하면, 결정 사항과 경위가 10초 만에 나온다. 한 번은 미미하지만, 회의 총량에 곱하면 이 효과는 무시할 수 없다.

또 다른 설계 목표는 grep 가능성이다. topic 명·ID 형식·마커(✅/⚠️)를 고정 서식으로 만든다. 이 파일의 독자는 인간만이 아니다. 오히려 주요 독자는 에이전트이며, 그들은 정규 표현식(Regular Expression)으로 이를 검색한다. 검증기의 '정본 대조'가 기계화될 수 있는 이유는 정본 측이 기계가 검색할 수 있는 형태를 갖추고 있기 때문이다.

구체적 사례: 회의가 끝난 후, 정본이 업데이트되기까지

가장 빈도가 높고 가장 효과적인 루프가 이것이다. 회의 의사록 작성을 예로 들어 처음부터 끝까지 보여준다.

단계 1: 전사 데이터가 내려온다 (트리거). 녹음의 전사 데이터가 지정된 폴더에 놓이면 루프가 발생한다.

단계 2: 에이전트가 구조화된 의사록으로 변환한다. 전사 데이터 전문은 의사록이 아니다. 고정 포맷으로 압축한다.

# 2026-07-17 정기 회의
- 참석: ○○ 부장, △△ 씨, 나
- 목적: 차기 견적 플로우 확정
...

이 변환에는 고생하며 배운 세 가지 규율이 있다.

• 전사 데이터의 고유명사를 신뢰하지 않는다: 음성 인식은 인명·제품명을 소리 나는 대로 적는다. '쿠와'가 사람 이름인지 도구인지 전사 데이터는 알지 못한다. 고유명사는 반드시 people.md / glossary.md와 대조하여 수정하며, 대조할 수 없는 것은 [확인 필요]를 붙인다.
• 결정과 태스크에는 반드시 출처를 붙인다: '누구의 어떤 발언인지' 추적할 수 없는 결정 사항은 적지 않는다. 이후의 '말했다/안 했다' 논쟁은 이 한 줄로 사라진다.
• 정본의 수정은 외부 작업(Outward Operation)으로 취급한다: 의사록에서 decisions.md / tasks.md로 반영하는 것을 에이전트의 독단에 맡기지 않는다. 다음 단계의 이야기다.

단계 3: 정본 업데이트 차분(Diff)이 승인 큐(Queue)에 쌓인다. 에이전트는 의사록에서 'decisions.md에 대한 이 추가 사항', 'tasks.md에 대한 이 3줄'이라는 차분을 만들어 큐에 쌓고 다음 작업으로 넘어간다. 인간이 승인하는 순간 정본이 업데이트되며, 그것이 다음 루프의 문맥이 된다. 회의가 끝나고 정본이 최신이 될 때까지 인간이 하는 일은 오직 승인뿐이다.

그래서, 이것이 엔지니어의 기술인가

제목을 회수하겠다. 네 가지 부품을 업무의 언어로 다시 바꾸면 다음과 같다.

• 트리거(Trigger)는,
  준비 (段取り) - 검증기(Verifier)는,
  체크리스트 (Checklist) - 정지 규칙(Stop Rule)은,
  마감 (Deadline) - 그리고 권한(Mandate)은,
  결재 (決裁)

전부 일을 돌리는 사람이 예전부터 가지고 있던 개념이다. 엔지니어링의 언어로 재발견되었을 뿐, 이것은 원래 업무 설계의 이야기라고 생각한다. 특히 권한(Mandate) 설계에 이르러서는 엔지니어링 어휘가 처음부터 존재하지 않는다. "어디까지 맡길 것인가", "누가 책임을 질 것인가"——그것은 예전부터 사람에게 일을 맡기는 쪽의 언어다.

따라서 지금 업무 루프(Loop) 설계에서 가장 실력이 드러나는 사람은 사실 코드를 짤 수 있는 사람이 아니다. 자신의 업무 준비와 체크리스트와 마감과 결재를 언어화할 수 있는 사람이다. 코드는 에이전트(Agent)가 짠다. 루프의 설계도는 그 일을 가장 잘 아는 사람만이 그릴 수 있다.

돌려보니 무엇이 변했는가

프롬프트를 입력하는 시간이 사라진다. 대신 늘어나는 것은 큐(Queue)를 처리하는 시간과 검증기를 육성하는 시간이다.

그리고 업무의 단위가 바뀐다. 검증기에 규칙을 하나 추가하면 이후의 모든 출력에 적용된다. 큐의 "망설임" 항목 형식을 하나 개선하면 이후의 모든 승인이 빨라진다. 즉 일상의 업무가 "작업"에서 **"루프의 개선"**으로 변해간다. 이 감각은 shogun으로 오케스트레이션(Orchestration)을 구성했을 때나, CoDD로 검증을 구성했을 때와도 같으며, 아마도 이 일 방식의 중독성의 정체일 것이다.

덧붙여, 세상의 "AI 에이전트 제품을 도입했습니다"라는 이야기와의 거리도 명확해진다. 완성품 에이전트란, 타인이 결정한 트리거·검증기·정지 규칙·권한이 동결된 제품을 말한다. 자신의 업무에 맞는지 여부는 이 4가지가 맞는지에 따라 결정되는데, 그 부분은 대개 변경할 수 없다. 에이전트는 사는 것이 아니라, 루프는 설계하는 것이라고 생각한다.

계보 이야기

내 안에서 이것은 3번째 작업에 해당한다. multi-agent-shogun으로 병렬 오케스트레이션을, CoDD로 결과물의 검증을 수행했다. 올해 하반기에는 이 업무 루프와 권한(Mandate)의 형식을 도구의 형태로 만들어 나갈 것이다. CoDD에는 독립 구현체도 생겨나고 있는데, 솔직히 이런 것이 가장 기쁘다.

4층(4th layer)에는 아마 반년 이내에 누군가가 이름을 붙일 것이다. 이름이 붙기 전에 도구와 형식을 놓아두기로 한다. 평소 하던 방식이다.

그래서, 당신의 루프는 어디까지 맡기고 있는가?

참고 링크

• What is "loop engineering?" (The Pragmatic Engineer)
• Loop Engineering (O'Reilly Radar)
• 루프 엔지니어링이란? 제4세대 AI 개발 완전 가이드 (Hexabase)
• 비엔지니어를 위한 claude 루프 엔지니어링 (goryugo)
• Why AI Agents Need an Approval Layer (Velt)
• Human-in-the-Loop AI Agents: When Approvals Matter (getclaw)
• Agent Governance Toolkit (Microsoft)
• awesome-ai-agent-governance (GitHub)

덤. 이 기사 자체도 그 업무 루프로 작성되었다. 초안은 에이전트가 구성하고, published: false 상태로 리포지토리에 쌓였다——즉 당신이 이것을 읽고 있다는 것은 승인 큐가 1건, 무사히 처리되었다는 뜻이다.

Discussion