코딩 에이전트를 다룬다면, 지금 그것을 지켜보는 것들을 세어보세요. 린터(Linters). Git 훅(Git hooks). CI. 사양서(Specs). 메모리 저장소(memory store). 그리고 에이전트가 따라야 할 규칙 파일(rules file)까지. 반 다스 시스템들이 모두 에이전트가 올바른 방식으로 올바른 것을 구축하는지 확인하고 있습니다.

이제, 당신 자신을 현재 진행 중인 열한 가지 일 전반에 걸쳐 방향성을 유지하게 해주는 것들을 세어보세요. 우리 대부분에게는 우리가 업데이트했다는 것을 희망하는 마크다운 파일(markdown file)입니다.

우리는 에이전트를 위한 하네스(harnesses)를 만드는 데 2년을 보냈고, 우리의 작업은 명예에 맡겼습니다. 두 축으로 도구들을 매핑해 보면 그 간극은 구체적이고 보기 힘든 구멍이 됩니다. 이 게시물이 바로 그 지도입니다.

(이 글은 세 부분 중 두 번째 부분입니다. 첫 번째 부분인 AI 방향성세: 결함이 아닌 컨텍스트의 누락에서는 당신이 지불하는 비용이 성격상의 결함이라기보다는 컨텍스트 버그라는 것을 주장했습니다. 읽지 않았다면 읽을 필요는 없습니다. 이 글은 독립적으로 이해할 수 있습니다.)

하나의 루프가 아닌 두 개의 루프

사람들이

각각의 루프가 깨지는 순간, 당신은 그 차이를 느낍니다. 실행 루프 (execution loop)가 깨질 때는 무언가 비명을 지릅니다. 실패한 테스트, 빨간색 빌드 (red build), 혹은 리뷰 코멘트 같은 것들 말이죠. 하지만 방향 설정 루프 (orientation loop)가 깨질 때는 아무도 비명을 지르지 않습니다. 에이전트 (agent)는 당신이 어제 거절했던 것을 자신 있게 다시 제안합니다. 당신은 오늘 아침 이미 가지고 있었던 정신적 지도 (mental map)를 다시 구축해야 합니다. 유일한 신호는 도구가 약속했던 것보다 당신의 속도가 느려지고 있다는 막연한 느낌뿐입니다. 한 가지 실패는 시끄럽고 도구에 의해 감지되지만, 다른 한 가지는 조용하기 때문에 대신 도덕적 비난의 대상이 되어버립니다.

martinfowler.com에 글을 기고하는 Kief Morris는 Humans and Agents in Software Engineering Loops에서 이를 주의 깊게 매핑합니다. 그의 주제는 _에이전트의 루프 내에서 인간이 어디에 위치하는가_입니다: 루프 안 (in the loop, 모든 결과물을 검사함)에 있는지, 아니면 루프 위 (on the loop, 결과물을 생성하는 하네스 (harness)를 형성함)에 있는지에 대한 것입니다. 그가 표현했듯이, "'루프 위(on the loop)' 방식은 결과물을 만들어낸 하네스를 변경하는 것입니다." Birgitta Böckeler는 동반 기사인 Harness engineering for coding agent users에서 그 관행에 이름을 붙였습니다.

이 포스트는 그 다음 단계입니다. 에이전트의 루프에서 당신이 어디에 앉아 있는가가 아니라, 당신만의 루프가 무엇인지, 그리고 우리가 이제 에이전트를 제어하는 법을 배운 것처럼 그 루프를 제어할 수 있는 무언가가 있는지에 대한 것입니다. 즉, 운영자 (operator)를 향해 다시 겨냥된 하네스 엔지니어링 (Harness engineering)입니다.

지도

두 개의 축이 역할을 수행합니다.

• 가로축, 도구가 제공하는 계층: 실행 (Execution) (단일 작업)에서 방향 설정 (Orientation) (여러 작업에 걸침)까지.
• 세로축, 유지되는 방식: 조언 (Advisory) (도구가 읽히고 최신 상태로 유지되기를 바람)에서 하네스화 (Harnessed) (도구가 연결되어 있어 조용히 표류하거나 노후화될 수 없음)까지.

그 수직축이 바로 중요한 부분이며, ETH Zurich의 연구진은 이를 수치화했습니다. 138개의 태스크에 걸쳐 4개의 코딩 에이전트 (coding agents)를 테스트한 결과, 그들은 AGENTS.md 파일이 거의 도움이 되지 않는다는 것을 발견했습니다. 개발자가 작성한 파일은 미미한 이득을 가져다주는 반면, AI가 작성한 파일은 성능을 약간 저하시키며, 어느 쪽이든 컨텍스트 (context) 비용이 실행 시 20% 이상 더 많이 발생합니다. 그 이유는 바로 축 (axis) 때문입니다. 파일은 단지 조언일 뿐입니다. 에이전트가 이를 따르도록 강제하는 것도 없고, 제대로 따랐는지 확인하는 것도 없으므로, 에이전트는 때로는 따르고 때로는 건너뜁니다. 하네스 (harness)는 요청하지 않습니다. 그 차이가 아래에 언급된 모든 강제된 도구들이 존재하는 이유이며, 바로 그 빈 공간(empty corner)에 결여된 핵심 요소입니다.

The loop-tooling landscape: Execution to Orientation across the bottom, Advisory to Harnessed up the side. Enforcement fills three corners; the orientation-harnessed corner sits empty

구석구석 살펴보겠습니다.

실행 (Execution)과 조언 (advisory), 대중적인 영역. CLAUDE.md 및 AGENTS.md, 스펙 기반 개발 (Spec Kit), 외부 메모리 저장소 (external memory stores), Claude Code의 네이티브 태스크 (Tasks), Vibe Kanban과 같은 에이전트 오케스트레이션 (agent-orchestration) 보드. 이들은 엄청나게 유용하지만, 설계상 조언적 (advisory) 입니다. 즉, 에이전트가 읽어주기를 바라는 파일이거나, 최신 상태로 유지되기를 바라는 스펙 (spec)인 것입니다. 거의 모든 이들이 이 영역에 머물고 있습니다.

빌드(build)를 위한 실행 및 활용된, 제품화된 강제성 (enforcement). 이 영역은 실재하며 성숙해 있습니다: 기반이 되는 기본 요소들(git, Claude Code hooks, CI) 위에 구축된 Husky, Lefthook, pre-commit, Trunk, GitHub branch protection 등이 있습니다. 이것들은 코드가 깨끗하기를 희망하지 않습니다. 코드가 깨끗해질 때까지 커밋을 거부하고, 빌드를 실패시키며, 머지(merge)를 차단합니다. 강제성 (Enforcement)은 생소한 것이 아닙니다. 이는 이미 해결된, 출시된 제품 카테고리입니다.

규율에 의해 수동으로 만들어지고 정직한, 방향 설정 (orientation) 및 권고 (advisory). 이곳이 바로 오늘날 여러분의 자체적인 루프가 존재하는 곳입니다: 매 세션마다 다시 읽는 STATUS.md나 CURRENT-FOCUS, todo.txt, Taskwarrior, 혹은 혼자 운영하는 Linear 보드 같은 것들 말이죠. 모두 운영자(operator)를 향해 있고, 모두 실재하며, 모두 여러분이 업데이트하는 것을 기억함으로써 정직하게 유지됩니다. 강제성은 없습니다.

활용되었으나, 비어 있는 방향 설정 (orientation). 여러분이 실행하는 루프를 위한 하네스(harness): 여러분과 에이전트가 모두 읽을 수 있으며, 조용히 방치한 채 계속해서 그 위에 빌드해 나갈 수 없는, 여러분이 무엇을 작업하고 있는지에 대한 정직하고 공유된 모습입니다. 생각할 수 있는 모든 도구를 매핑해 보십시오. 이 영역은 비어 있을 것입니다.

실제로 사용하는 도구에 적용해 보기

이 관점은 스스로 실행할 수 있을 때만 가치가 있으므로, 몇 가지 실제 도구를 배치해 봅시다.

세션 전반에 걸쳐 컨텍스트를 저장하고 회상하는 에이전트인 **메모리 MCP (memory MCP)**를 예로 들어보겠습니다. 진정으로 유용하며,

**Claude Code의 네이티브 태스크 (native Tasks)**나 Vibe Kanban(호스팅 제품은 현재 종료 중이지만, 프로젝트는 오픈 소스로 계속됨)과 같은 보드를 예로 들어보겠습니다. 이들은 세션 전반에 걸쳐 작업 단위(units of work)를 추적하기 때문에 오리엔테이션(orientation)에 더 가깝습니다. 하지만 여전히 권고(advisory) 수준에 머뭅니다. 보드는 마지막으로 업데이트한 사람이 얼마나 잘 관리했느냐만큼만 현실을 반영하며, 정보가 오래되었더라도 다음 동작을 차단하지 않기 때문입니다. 중앙에서 왼쪽, 아래쪽에 위치합니다.

혼자 운영하는 Linear 보드를 생각해 보세요. 이제 당신은 진정한 오리엔테이션 계층(orientation-layer)이 됩니다. 즉, 작업 전반에 걸쳐 운영자(operator)를 마주하게 됩니다. 이는 우측 하단에 위치합니다. 하지만 이 역시 여전히 권고 수준입니다. Linear는 상태값이 3일 전 것이라고 해서 당신의 작업 시작을 거부하지 않습니다. 정직함은 전적으로 당신에게 달려 있습니다.

어떤 도구를 사용하든 이끌리는 방향은 동일합니다. 요소들은 실행(execution)을 향해 왼쪽으로, 권고(advisory)를 향해 아래로 표류합니다. 우측 상단은 비어 있는 상태로 남습니다. 그리고 어떤 도구가 그 영역으로 이동하게 만들 요소가 무엇인지 보이기 시작합니다. 그 도구는 반드시 '게이트(gate)' 역할을 해야 합니다(마치 pre-commit이 지저분한 커밋을 거부하는 것처럼, 보드가 일치될 때까지 다음 빌드를 거부하는 방식). 또한, 하나의 인터페이스에서 읽는 이들 '모두'에게 서비스를 제공해야 합니다(당신이 우선순위를 정하는 목록이 곧 에이전트가 재정렬(re-orient)을 위해 읽는 목록이 됩니다). 혼자 사용하는 Linear에 게이트를 장착한다면, 이미 목표의 대부분에 도달한 것입니다.

왜 세 개의 모서리는 채워졌고 하나는 채워지지 않았는가

이는 우연이 아니며, 오리엔테이션(orientation) 문제가 작기 때문도 아닙니다. 두 가지 힘이 이 모서리를 비워두었습니다.

1. 고통이 눈에 보이고 수익화가 가능한 곳에 노력이 집중되었습니다. "에이전트가 나쁜 코드를 작성했다"는 문제는 목소리가 크고, 시연 가능하며, 판매할 수 있는 가치가 있습니다. 그래서 실행 루프(execution loop)에는 도구(tools)가 제공되었습니다. 반면 "내가 무엇을 작업하고 있었는지 놓쳤다"는 것은 개인의 결함으로 읽히기 때문에, _조언(advice)_이 제공되었습니다. 즉, 규율을 지키고, 너무 많은 일을 시작하지 말라는 식의 조언 말입니다.
2. 강제성(Enforcement)은 결코 오리엔테이션(orientation)을 향하지 않았습니다. 활용되고 있는 열(column)을 다시 살펴보십시오. 모든 구성 요소는 _빌드 정확성(build correctness)_을 강제합니다: 린트(lint), 테스트(tests), 비밀값(secrets), 머지 규칙(merge rules) 등이 그것입니다. 조건이 충족될 때까지 차단하는 훅(hook)이라는 강제성 프리미티브(enforcement primitive)는 이미 제품화되어 널리 사용되고 있습니다. 하지만 아무도 이를 한 단계 위인, 당신의 보드(board)가 진실을 말하고 있는지에 대한 질문으로 겨냥하지 않았습니다.

따라서 비어 있는 모서리는 "강제성이 드물다"는 뜻이 아닙니다. 그것은 "강제성은 빌드를 위해서는 어디에나 존재하지만, 오리엔테이션을 위해서는 부재한다"는 뜻입니다. 이는 훨씬 더 구체적이며, 해결 가능한 격차입니다. 그리고 이 분리는 명확하게 명명할 가치가 있습니다: 에이전트의 역할은 실행(execution)이고, 우리의 역할은 오리엔테이션(orientation)입니다. 우리는 실행이 조언에만 맡기기에는 너무 중요하다고 판단하여 이를 강제할 수 있도록 만들었습니다. 반면 에이전트가 무엇을 작업할지 자체를 결정하는 부분인 오리엔테이션은 기억(memory)에 맡겨두었습니다.

누락된 조각이 실제로 얼마나 가까이 있는지 구체적으로 살펴볼 가치가 있습니다. 프리커밋 훅(pre-commit hook)은 단지 동작 전에 실행되어 이를 차단할 수 있는 스크립트일 뿐입니다. Claude Code도 동일한 프리미티브를 제공합니다: 도구가 실행되기 전에 작동하여 이를 거부할 수 있는 훅입니다. 강제된 열 전체가 코드만을 겨냥한 그 하나의 아이디어 위에 구축되어 있습니다. 이를 오리엔테이션으로 겨냥하는 것은 연구 과제가 아닙니다. 그것은 조건만 다를 뿐 동일한 훅입니다: 당신이 그것을 바탕으로 빌드하기 전에, 오늘 보드가 조정(reconciled)되었는가 하는 조건 말입니다. 아무도 이것을 출시하지 않은 이유는 그것이 어려워서가 아니라, 오리엔테이션을 유지하는 것을 '그저 갖추고 있어야 할 것'이 아니라 '강제해야 할 것'으로 정의한 사람이 없었기 때문입니다.

비어 있는 모서리가 흥미로운 지점이다

두 가지 발견을 종합해 보면, 그곳에 무엇이 속해야 하는지 그 형태가 명확해집니다.

• 그것은 **방향성 계층 (orientation-layer)**입니다: 하나의 작업 내부가 아니라, 전체 보드에 걸쳐 이야기의 결(story-grained)을 형성합니다.
• 그것은 제어됩니다 (harnessed): 프리 커밋 훅 (pre-commit hook)이 커밋을 제어하는 방식과 같은 결정론적 게이트 (deterministic gate)입니다. 이는 당신이 조정(reconcile)을 완료할 때까지 다음 빌드를 차단합니다. 당신은 보드가 최신 상태이기를 희망하는 것이 아니라, 그 위에 빌드하기 전에 보드를 조정합니다. 게이트가 당신을 대신해 보드를 정직하게 유지해 주는 것이 아닙니다. 게이트는 당신이 그렇게 하도록 만듭니다.
• 그것은 하나의 표면에서 두 독자 모두에게 봉사합니다 (serves both readers off one surface): 당신은 우선순위를 설정하고 캡처하며, 에이전트는 매 세션마다 방향을 재설정하기 위해 동일한 목록을 읽고 작업이 완료됨에 따라 상태를 표시합니다.

이러한 속성 중 어느 것도 단독으로는 새로운 것이 아닙니다. 파일은 이미 해결된 기질 (substrate)입니다. 에이전트가 읽을 수 있는 상태 (CC Tasks, AGENTS.md)도 존재합니다. 보드도 존재합니다. 강제성 (hooks)도 존재합니다. 부족한 것은 방향성 루프 (orientation loop)를 목표로 하는 이들의 조합입니다. 이 지도가 가시화하는 가장 희귀한 재료는 바로 이 두 가지입니다: **제어됨 (harnessed)**과 하나의 표면에서 두 독자 모두에게 봉사함 (serves-both-off-one-surface).

결론만이 아니라 지도를 가져가세요

여기서 간직해야 할 유용한 것은 "4loops가 빈 모서리에 들어간다"는 사실이 아닙니다. 바로 지도입니다. 다음에 에이전트 도구, 메모리 MCP, 칸반 (kanban), 규칙 파일 컨벤션 (rules-file convention)을 평가할 때, 이 두 축 위에 놓아보십시오. 그것이 어떤 루프에 봉사합니까: 에이전트의 작업입니까, 아니면 작업 전반에 걸친 당신의 방향성입니까? 그리고 그것이 유지(hold) 합니까 (게이트 역할, 강제, 이탈 불가능), 아니면 단지 조언(advise) 합니까 (읽히기를 희망함)? 거의 모든 것이 동일한 세 모서리에 모여 있으며, 당신은 네 번째 모서리의 빈 공간을 스스로 느끼게 될 것입니다.

빌드가 이미 정확성을 강제하는 방식처럼 정직함이 강제되는, 당신의 방향성 루프를 위한 제어 장치(harness)로서 그 모서리에 무엇이 들어갈지는 다음 포스트에서 다룹니다. 이번 포스트는 그 구멍을 놓칠 수 없도록 지도를 충분히 명확하게 그리는 것에만 집중했습니다.

출처

이 포스트가 파생된 프레임워크 (The framing this post branches off)

출처

이 포스트가 파생된 프레임워크 (The framing this post branches off)

• Kief Morris, Humans and Agents in Software Engineering Loops (martinfowler.com, 2026년 3월 4일) — 루프 내(in the loop) 대 루프 위(on the loop).
• Birgitta Böckeler, Harness engineering for coding agent users (martinfowler.com, 2026년 4월 2일) —