Claude Code로부터 직접 들은 내용을 바탕으로, 어떻게 활용해야 루프 엔지니어링 (Loop Engineering)을 실천할 수 있을지 시행착오를 거치며 시도했던 과정을 정리한 글입니다.

루프 엔지니어링 (Loop Engineering)에 대해서는 이미 많은 기사가 소개되어 있으므로 여기서는 생략하겠습니다. 이 기사에서 상세히 해설해 주고 있습니다. 저 또한 이 기사를 참고하여 배웠으며, 매우 감사하게 생각합니다.

루프 엔지니어링 (Loop Engineering)의 핵심 모듈인 6가지 요소로 꼽히는 Automations / Worktrees / Skills / Connectors / Sub-agents / Memory 중에서도, Automations에 대해서는 이미지가 잘 떠오르지 않았습니다.

Claude Code의 경우 auto accept를 on으로 설정해 두면 Automations을 실천할 수 있는 것인가... 정도의 해석이었습니다. 요컨대, 이러한 요소들을 활용하여 루프 엔지니어링 (Loop Engineering)의 플로우를 어느 수준까지 실천하고 있는지 파악하지 못하고 있었습니다.

그래서 이 글에서는,

루프 엔지니어링 (Loop Engineering)을 의식하지 않는 AI를 활용한 개발 플로우로 간단한 개발- AI와 함께 개발하는 과정에서 개인적으로 '이건 괜찮을지도 모른다'라고 생각하는 개발 플로우입니다

그 개발 수법을 루프 엔지니어링 (Loop Engineering)과 대조하여 피드백을 획득- 피드백 중에서도 제가 인상 깊었던 것을 4가지 정도 뽑아내어, 공통되는 배움을 2가지 제시합니다

• 본 글에서는 이 피드백 및 배움을 핵심 내용으로 삼습니다

여담: 배움을 즉시 사용하기 위한 하네스 키트 (Harness Kit) 개발

얻은 배움을 매번 리포지토리 (Repository)마다 구현하는 것은 힘들기 때문에, 설치하는 것만으로 루프 엔지니어링 (Loop Engineering)을 실천할 수 있는 개발 키트를 만들어 보았습니다. 그 개요를 간단히 정리합니다

라는 흐름으로 정리해 나가겠습니다.

루프 엔지니어링 (Loop Engineering)을 의식하지 않는 개발

기존의 AI를 활용한 개발은 아래와 같은 플로우로 진행했습니다.

노란색 테두리가 제가 수행한 파트, 파란색 테두리는 에이전트 (Agent)가 수행한 파트입니다. 작업의 일부를 에이전트 (Agent)에게 위임하고는 있지만, 그때마다의 지시나 확인은 제가 수행하고 있기 때문에 노란색 테두리가 많이 보입니다. 이 노란색 테두리를 필요 최소한으로 줄여나갈 수 있다면 좋을 것 같습니다.

나름의 포인트

갑자기 구현하게 하는 것이 아니라, Plan 모드에서 계획을 세우는 것을 프랙티스 (Practice)로서 실천하고 있었습니다. 그 바탕 위에서, 인간이 나중에 사양을 확인할 수 있도록 기능 단위로 Issue를 발행하고, 대응하는 PR을 머지 (Merge)하면 해당 Issue를 ADR화하는 플로우입니다.

AI 에이전트 (Agent)를 사용한 개발에서는 의사결정의 경위가 망각되는 것이 문제가 되기 쉽습니다. 특히 컴팩션 (Compaction)이 이루어질 때 많이 발생하지 않을까 합니다. 의사결정의 경위가 망각되면, 그 상황에 맞춰 편리한 아키텍처 (Architecture)를 선택하게 되어 어느샌가 처음에 결정한 설계 방침에서 벗어나 버리는... 상황이 발생하곤 합니다.

그 대책으로서, 의사결정의 경위는 Issue를 최종적으로 ADR화함으로써 설계 방침을 지킬 수 있도록 이러한 플로우로 개발하고 있었습니다.

준비 작업

이 개발을 진행하는 단계부터 루프 엔지니어링 (Loop Engineering)을 손쉽게 실천할 수 있는 툴 (Tool) 개발을 염두에 두고 있었기에, 약간 그쪽을 향한 준비를 하고 있었습니다.

그 준비란, 역할별로 세션 (Session)을 만들어 가는 것입니다. 이번에는 구현자 / Issue 리뷰어 / Issue 리뷰 대응자 / PR 리뷰어 / PR 리뷰 리뷰 대응자라는 5가지 역할을 상정하여 5개의 세션으로 개발을 진행했습니다.

그 역할에 특화된 세션으로 진행함으로써 축적된 정보로부터 회고 등을 하기 쉬워질 것이라고 생각했기 때문입니다.

루프 엔지니어링 (Loop Engineering)과 대조해 본다면?

나름대로 경험에 기반한 괜찮은 개발 플로우를 만들고 있는 것이 아닌가... 라고 생각하고 있었습니다만, 아래 기사를 중심으로 루프 엔지니어링 (Loop Engineering)과 대조해 보니 엄격한 피드백이 있었습니다.

이 기사로부터 저 나름대로 포인트라고 생각한 원칙 같은 것을 4가지 꼽아보겠습니다.

• Automations가 루프 (Loop)의 정의적인 핵심이다

• 인간이 기동하지 않아도 일을 발견하고 기동한다

• 구현자 ≠ 평가자

• 쓰는 자에게 자신의 일을 채점하게 하지 마라

• 상태는 대화 외부에 둔다

• 에이전트 (Agent)는 잊어버리지만, 리포지토리 (Repository)는 잊지 않는다

• 완료는 자기 신고가 아니라 증명이다

• 객관적으로 통과시킬 수 있는 게이트 (Gate)가 필요하다

이에 더해, 6가지 핵심 모듈의 관점에서 본 채점 요약은 다음과 같습니다. 특히 수동으로 프롬프트를 전송했다는 점에서 Automations 항목은 최하위 평가를 받았습니다.

위의 개발 플로우에서는 각 역할별 세션에서 다음과 같은 프롬프트를 매번 실행했기 때문에, 당연히 이것만으로는 루프가 자동으로 돌아가고 있다고 말할 수 없습니다.

• Issue 리뷰어 세션: Issue#xx의 리뷰를 실시해줘
• PR 리뷰 대응 세션: PR#yy의 리뷰 대응을 실시해줘
• 구현자 세션: Ready to implement 라벨이 붙은 Issue에 대응하는 PR을 생성해줘

피드백 중에서 배울 점이 컸던 것들을 몇 가지 뽑아보겠습니다.

✅ 평가 관점과 평가 기준은 별개다

Sub-agents 항목에서 구현자와 평가자를 나누는 것은 프랙티스(Practice)로서 실천하고 있었습니다. 이번에는 사정상 서브 에이전트(Sub-agent)가 아니라 세션으로 나누었습니다.

PR 리뷰어로서 역할을 나누어 code-review 내장 스킬을 사용하여 리뷰하고, 그 결과들을 통합하여 PR에 코멘트를 남기도록 운영했습니다. 하지만 이 운영에 대해 "평가 기준이 부족하다!"라는 피드백이 있었습니다. 저는 code-review 스킬로 다각적인 리뷰를 수행하고 있으니 문제없지 않을까 생각했지만, 심층 분석을 통해 제가 '평가 관점'과 '평가 기준'을 혼동하고 있었다는 것을 알게 되었습니다.

code-review 스킬은 다음과 같은 스킬입니다. 이는 평가 관점을 다각적으로 설정하여 리뷰를 할 수 있을 뿐, 평가 기준은 "치명적인 리뷰 결과가 없을 것"이라는 합격 조건뿐이었다는 것이 문제였습니다.

현재 작업의 diff를 버그 탐지계와 정리계로 나뉜 여러 관점별로 병렬 검사하고, 도출된 지적 후보를 독립적으로 검증한 후 중요도 순으로 보고하는 내장 리뷰. 보고에 집중하며 수정은 하지 않음. 인간이 명시적으로 기동하는 전용 스킬로, ultra 지정 시 클라우드의 멀티 에이전트(Multi-agent) 리뷰로 확장 가능.

다음 개발에서는 평가 기준으로 **"리뷰 및 대응 주고받기 횟수가 5회 이상이면서 치명적인 리뷰 피드백이 남아 있는 경우"**와 **"2회 연속 개선 없음 (감소하지 않는 경향)"**을 정지 조건 중 인간에게 에스컬레이션(Escalation)이 필요한 불합격 조건으로 설정했습니다. 이와 함께 평가자의 피드백을 더해 어떻게 상태 전이(State Transition)를 시킬지 결정하는 플로우로 만들었습니다.

판단 플로우

이것은 Automations 항목이 F인 이유 중 4번과 통하는 점이었습니다.

✅ 상태 전이에 인간 확인 상태를 추가

Memory / State 항목에서 에이전트가 병렬로 작업하기 위해 공유 가능한 태스크 진행 보드(이하 대장)가 필요했습니다. 대장은 Issue와 PR 각각에 상태를 두고, 실제 작업에 맞춰 상태를 업데이트하는 구조로 만들었습니다.

이는 원래부터 필요성을 이해하고 있었기에 도입했으나, 에이전트가 작업하는 도중 인간에게 에스컬레이션이 필요한 불합격 = 이상 정지 상황이 발생했을 때, 이를 한눈에 알 수 있는 상태가 존재하지 않아 작업이 건전하게 진행되고 있는지 알 수 없는 상황에 빠졌습니다.

다음 개발에서는 이상 정지를 인간이 확인해야 할 시그널로 삼기 위해, 에이전트가 앞서 언급한 기준에 따라 인간의 확인이 필요하다고 판단하면 requires human review라는 상태로 전이시키도록 했습니다. 이 상태로 전이될 때 알림을 보냄으로써, 루프 엔지니어링(Loop Engineering) 내에서도 최소화해야 할 인간의 개입 타이밍을 명확히 했습니다.

Issue 상태 전이

PR 상태 전이

이것은 Automations 항목이 F인 이유 중 5번과 통하는 점이었습니다.

✅ 인간 확인에도 강약을 조절하기

Automations 항목의 평가가 F였던 큰 이유 중 하나는, 루프 엔지니어링을 의식하지 않는 개발에서는 에이전트의 작업마다 매번 Yes/No를 전달했다는 점입니다. 이는 사소한 docs 수정도, main으로의 머지(Merge)도 동일한 중요성을 가진 "보고 → 승인" 과정을 요구했다는 뜻입니다. 이에 대한 피드백은 매우 엄격했습니다. "스루풋(Throughput)이 인간 1 사이클 = 1 단위로 고정되어, 병목(Bottleneck)은 설계상 당신 자신이다"라는 것이었습니다.

이 피드백으로부터 정말로 인간이 필요한 확인과, 불안하니까 일단 해두는 확인을 구분할 필요가 있으며, 그 분류의 축으로서 두 가지 질문을 생각했습니다.

실수했을 때 되돌릴 수 있는가? (가역성)
실수했을 때 피해가 어디까지 확산되는가? (영향 범위)

이 두 축으로 모든 게이트(Gate)를 전수 조사하여, "되돌릴 수 있고 피해가 좁은 조작은 확인 과정을 제외하고 사후 차분 요약(Diff Summary)으로 파악", "되돌릴 수 없고 피해가 넓은 조작에만 동기식 확인을 남긴다"와 같이 강약을 조절함으로써, 인간의 확인을 단순히 "줄이는" 것만으로는 부족하며, 배치 장소와 무게를 설계하는 방향으로 정했습니다.

가역성 × 영향 범위 매트릭스

이렇게 분류한 결과, 다음과 같은 4가지 패턴이 나왔습니다. 다음 개발에서는 이와 같이 개발 과정의 작업을 분류함으로써, 모든 작업에 대해 균일하게 승인을 요구하는 것이 아니라, 에이전트(Agent)에게 위임할 부분 / 인간이 확실히 확인해야 할 부분으로 가중치를 두도록 했습니다.

작업 공정의 분류

이는 Automations 항목이 F인 이유 중 2번과 일맥상통하는 점이었습니다.

✅ 일의 발견을 인간의 업무로 만들지 않는다

Automations 항목이 F인 가장 큰 이유는 "일의 자율적 발견이 없음"이었습니다. 루프 엔지니어링 (Loop Engineering)을 의식하지 않는 개발에서는, 개발하고자 하는 대상에 대해 아래의 3단계로 이슈(Issue)를 기표하고 에픽 이슈(Epic Issue)별로 개발을 진행해 왔습니다. 물론, 페이즈(Phase)를 나누는 작업이나 페이즈별 이슈 기표를 모두 제가 수동으로 수행했습니다.

이슈 트리 (Issue Tree)

다음 개발에서는 이 "일의 발견"을 이번 개발 플로우에서의 이슈 트리 구축으로 정의하여 반영하고 싶다고 생각했습니다. 그래서, 개발에 착수할 수 있는 상태 = 이슈가 어느 정도 정리되어 리뷰를 시작할 수 있는 상태가 되기까지를 6단계로 나누어 보았습니다.

일의 발견 단계

다양한 시그널을 통해 에이전트가 자동으로 이슈를 기표하지만, 이 단계에서도 중요한 것은 위와 마찬가지로 인간의 확인에 강약을 조절하는 것이었습니다. 기계적으로 검증이 가능한 이슈에 대해서는 자동으로 채택합니다. 반면, 검증할 수 없는 것은 인간의 확인을 필요로 하지만, 확신도(Confidence)를 산출하여 높다면 에이전트 관점에서는 "수행할 의의가 명확함, 실시 여부에 대해 Yes / No만 지시해줘"라고 하고, 낮다면 "태스크로서의 정당성이 불명확함, 정말 해야 할 일인가?"와 같은 시그널로 판단하여 별도의 워크스루(Wall-hitting)를 통해 심화하는 등의 케이스 분류를 했습니다.

검증 가능성 × 확신도

이는 Automations 항목이 F인 이유 중 1번과 일맥상통하는 점이었습니다.

피드백을 통합해 보면?

위에서는 제가 특히 인상 깊었던 피드백을 뽑아 언어화해 보았습니다. 이것들을 되돌아보니 아래 그림과 같이 루프 엔지니어링에 관해 저 나름대로 포인트라고 생각한 원칙들과 강하게 연결되어 있음을 알 수 있었습니다.

나아가 이것들에 공통된 배움으로서 두 가지를 꼽고 싶습니다.

⭐️ 에이전트의 자기 보고를 맹신하지 말고 객관성을 중요시할 것

이는 흔히 말하는 이야기이자 할루시네이션 (Hallucination)에 가까운 이야기입니다만, 이번 개발에서도 에이전트로부터 허위 보고가 올라온 적이 여러 번 있었습니다.

예를 들어, code-review 스킬의 기동을 서브 에이전트 (Sub-agent)에게 위임하고, 리뷰 결과를 통합하여 루트 에이전트 (Root-agent)에게 보고하게 하는 상황입니다. 루트가 세운 서브 에이전트 = 자식 에이전트는 code-review 스킬에 의해 (기본값으로) 8가지 관점을 체크하도록 손자 에이전트 (Grandchild-agent)를 8개 병렬로 실행하는데, 이 중 몇 개가 리뷰 결과를 반환하지 않았음에도 불구하고 "8개의 리뷰 결과가 반환되었으며, 다음과 같은 리포트가 작성되었습니다!"라고 보고해 오는 식입니다.

이를 방지하기 위해서는 프롬프트 (Prompt) 전달 방식 등을 개선할 수도 있지만, 가능한 한 **"객관적으로 판단할 수 있는 기준"**을 마련하거나 "실행하여 확인할 수 있는 기계적 검증" 메커니즘을 추가하는 것이 중요하다는 점을 다시 한번 깨달을 수 있었습니다.

⭐️ 인간의 확인을 없애는 것이 아니라, 요구되는 기준을 명확히 할 것

저는 루프 엔지니어링에서 인간의 확인을 일절 없애는 것이 목표라고 생각했습니다. 최종적인 이상향이라면 그럴지도 모르겠지만, 아직 생성형 AI (Generative AI)의 아웃풋에 대해 인간의 확인을 100% 제거하는 것은 어렵지 않을까 생각합니다.

다만, 매번 아웃풋을 확인해야 하는가라는 질문에 대해서는, 이번 개발 및 피드백을 통해 그럴 필요가 없다는 것을 알게 되었습니다. 확인할 때마다 균일한 가중치를 두는 것이 아니라, "객관적으로 검증이 가능한가" 또는 "의의나 설계가 명확한가"에 따라 자동 채택이나 실시 여부만을 묻는 식으로, 판정 기준을 설정함으로써 판단을 에이전트 (Agent)에게 위임할 것인지 아니면 인간이 확인해야 할 것인지에 대한 그래데이션(Gradation)을 만드는 것이 중요하다는 것을 깨달았습니다.

이를 통해 인간의 개입을 최소한으로 줄일 수 있지 않을까 생각했습니다. 막연하게나마 루프 엔지니어링 (Loop Engineering)에서 집중해야 할 점이 무엇인지 알게 되었기에, 마지막으로 여담 정도로 이러한 개발 플로우를 최대한 자동화하기 위한 하네스 키트 (Harness Kit)를 주제로 개발해 본 이야기를 써보겠습니다.

여담: 배움을 활용한 하네스 키트 개발

위에서 언급한 루프 엔지니어링을 의식하지 않는 개발 플로우를 베이스로 하네스 키트를 도입함으로써, 에이전트에 대한 매번의 지시나 인간의 확인을 최대한 줄이는 아키텍처 (Architecture)를 구상해 보았습니다.

리포지토리 (Repository)에 설치하여 두 개의 명령어를 루프 (Loop)로 계속 돌리는 이미지입니다. 토큰 (Token)은 엄청나게 소모되지만요... (웃음)

노란색 테두리는 제가 수행한 파트, 파란색 테두리는 에이전트가 수행한 파트이며, 여기에 더해 초록색 테두리는 결정론적인 (Deterministic) 메커니즘, 빨간색 테두리는 이상 정지의 집약처를 추가했습니다.

업무 발견 루프를 프로덕트 매니저 (Product Manager) 역할로 지속하고, 승인된 업무를 오케스트레이터 (Orchestrator) 역할이 업무 상태에 따라 데벨로퍼 (Developer) 역할 / 리뷰어 (Reviewer) 역할 등으로 할당하여 머지 (Merge) 직전까지 상호작용을 지속하는 형태로 만들었습니다.

루프 엔지니어링을 의식하지 않는 개발과 비교했을 때, 인간이 확인하고 판단해야 할 포인트는 남아있지만, 많은 부분이 판정 기준을 명확히 함으로써 에이전트가 기계적으로 판단할 수 있게 되었고, 이를 초록색 테두리 영역으로 대체할 수 있었습니다.

다시 루프 엔지니어링과 대조해 본다면?

이 하네스 키트를 도입한 개발 플로우를 다시 6가지 핵심 모듈 (Core Module) 관점에서 채점해 보았습니다.

지난번 채점이 F였던 Automations는

역시 개선이 보였지만 여전히 B였습니다. 위 플로우와 같이 업무 발견부터 PR 머지 직전까지 인간의 확인/간섭을 한계까지 줄일 수 있었습니다. 한편, loop 명령어를 통해 지속적으로 구동하는 것은 가능하지만, 그 가동 상황을 모니터링하는 메커니즘이 없다는 점 때문에 A에는 도달하지 못했다는 평가를 받았습니다.

✅ 추천 포인트 ① 리뷰 관점의 확장성

구현자/대응자 ≠ 평가자라는 원칙을 지키면서, 평가자를 2층 구조로 만들었습니다. 1층은 판정에 필요한 정보 수집을 수행하는 층입니다. 이 층에서는 PR에서 diff를 가져와 여러 관점에서 리뷰를 실시하는 에이전트가 관점별로 기동하여, 규정된 스키마 (Schema) 형식으로 상위 에이전트에게 반환합니다. 2층은 수집된 정보를 바탕으로 판정을 수행하는 층입니다 (이 층이 판정 기준을 가지고 있습니다). 여러 관점에서의 리뷰 결과를 종합하여, 머지 가능 여부를 포함한 최종적인 리뷰 요약 (Summary)을 작성합니다.

이 1층의 정보 수집 관점을 사용하는 측에서 커스터마이징할 수 있도록 설계했습니다. 구현상으로는 관점별로 서브 에이전트 (Sub-agent)를 기동하여 정보를 수집할 뿐이므로, 구체적으로 확인하고 싶은 관점을 규정된 형식의 파일로 작성하여 정보 수집 시 참조되는 디렉토리에 배치함으로써, 리뷰 시 체크하고 싶은 관점을 증감시킬 수 있습니다.

리뷰의 구조화

✅ 추천 포인트 ② 작업 상황 파악을 위한 대시보드 (Dashboard)

전체 진척도는 로컬 파일로 관리하는 구성이기에, 많은 작업이 자동화되어 있을 때 어디서 무엇이 일어나고 있는지 확인하고 싶을 때 어려움을 겪는 상황이 발생했습니다. 특히 requires human review 상태는 인간이 확인해야 할 타이밍이기 때문입니다.

대장(Ledger)에 모든 진척도를 기술하고 있으므로, 대장을 소스 (Source)로 읽어 들여 테스트를 포함한 변환 로직을 거쳐 진척도를 시각화하는 대시보드를 제작했습니다. 각 역할에 대응하는 픽셀 아트 캐릭터가 업무를 수행하면 움직이는데, 이를 보는 재미가 있다는 점도 좋은 포인트입니다.

대장에서 대시보드로

여담치고는 너무 많이 써버렸습니다만, 이에 대한 자세한 내용은 리포지토리를 공개할 수 있는 수준이 되면 다시 블로그에 쓰도록 하겠습니다.

마치며

루프 엔지니어링을 구체화해 보고 싶다는 생각으로 시작한 작업이었지만, 개인적으로 배운 점이 많아 해보길 잘했다고 생각합니다.

Claude Code의 피드백이 반드시 옳다는 보장은 없으므로, 만약 "이러한 관점에서 생각해 보면 좋다!"와 같은 전문가분들의 피드백이 있다면 매우 감사하겠습니다.

본 기사를 읽어주셔서 감사합니다. 조금이라도 배움을 얻어 가실 수 있다면 기쁘겠습니다.

Discussion