정렬(Alignment)이 에이전트 제어 평면(Agent Control Plane)으로 이동하고 있습니다

요약(tl;dr) - 플랜 모드(Plan Mode), 결과물(Outcomes), 기술(Skills), 그리고 에이전트-심판(agent-as-judge) 워크플로우는 하나의 공통된 패턴을 가리킵니다. 신뢰할 수 있는 코딩 에이전트는 단일 프롬프트(Prompt)에 덜 의존하며, 모델 주변의 계획(Planning), 조종(Steering), 메모리(Memory), 그리고 검증(Verification) 시스템에 더 많이 의존합니다.

코딩 에이전트는 안전하면서도 여전히 잘못된 작업을 수행할 수 있습니다.

전형적인 실패 사례는 파괴적인 행동이 아닙니다. 그것은 요청된 변경 사항과 구현된 변경 사항 사이의 작은 불일치입니다. 예를 들어, 이슈에서 /api/upload에 슬라이딩 윈도우(Sliding-window) 방식의 속도 제한기(Rate limiter)를 요청했는데, 에이전트가 /api/files에 토큰 버킷(Token bucket)을 구현하고, 불필요한 설정 플래그를 추가하며, 그 잘못된 해석에 맞춰 문서를 업데이트하는 식입니다. 이 경우 테스트는 여전히 통과할 수도 있습니다.

문제는 광범위한 의미에서의 모델 안전성(Model safety)이 아닙니다. 그것은 불완전한 요구사항 하에서, 프롬프트에 작성되지 않았을 수도 있는 제약 조건이 존재하는 특정 리포지토리(Repository) 내부의 의도 정렬(Intent alignment) 문제입니다.

현재의 툴링(Tooling)은 해결책이 더 이상 단순히 더 똑똑한 모델을 기다리는 것만이 아님을 시사합니다. 계획(Plans), 기술(Skills), 지속적인 지침(Persistent instructions), 루브릭(Rubrics), 심판 에이전트(Judge agents), 리뷰 에이전트(Review agents), 작업(Tasks), 그리고 메모리(Memory)가 모두 동일한 시스템의 일부가 되고 있습니다.

이러한 도구들을 종합해 보면, 정렬(Alignment)은 모델 자체에 집중되기보다는 모델 주변의 제어 평면(Control plane), 즉 에이전트의 작업을 형성하는 산출물(Artifacts), 루브릭(Rubrics), 리뷰어(Reviewers), 메모리(Memories), 그리고 인간의 의사결정 지점들에 더 많이 의존하게 되고 있음을 알 수 있습니다.

기존의 프롬프트 루프는 너무 좁습니다

기본적인 워크플로우는 여전히 의도를 단 한 번의 교환으로 포착할 수 있는 것으로 취급합니다:

에이전트에게 긴 프롬프트(Prompt), /goal, 또는 일련의 지침 묶음을 제공합니다.
에이전트가 파일을 수정하고, 테스트를 실행하며, 어쩌면 리뷰어를 생성하도록 둡니다.
결과물인 디프(Diff)를 검토합니다.
무엇을 오해했는지 설명합니다.
결과가 수용 가능할 때까지 반복합니다.

작업 단위가 하나의 채팅 세션과 하나의 어시스턴트(Assistant)였을 때는 그 루프가 말이 되었습니다. 하지만 에이전트가 몇 시간 동안 실행되고, 많은 파일을 건드리며, 테스트를 작성하고, 인간이 검토할 수 있는 속도보다 더 빠르게 변경 사항을 만들어내기 시작하면서 이 루프는 무너지기 시작합니다.

그러한 환경에서 최종 풀 리퀘스트 (Pull Request)는 의도 (Intent)를 전달하기에 충분히 큰 채널이 아닙니다.

차이점 (Diff)이 생성될 때쯤이면, 에이전트는 이미 여러 중요한 결정들을 내린 상태입니다. 어떤 파일이 중요한지, 어떤 제약 사항이 선택 사항인지, 어떤 기존 패턴을 복사할지, 무엇이 "완료"를 의미하는지, 그리고 테스트가 없을 때 어떻게 행동할지 등이 그것입니다. 만약 이러한 결정들이 잘못되었다면, 검토 (Review)는 조종 기제 (Steering mechanism)가 아니라 재구성 작업 (Reconstruction exercise)이 되어버립니다.

최신 도구들은 에이전트가 작업 전, 중, 후에 자신의 가설 (Assumptions)을 외재화 (Externalize)하도록 함으로써 이 문제를 해결합니다.

첫째, 계획 (Plan)을 수정 가능하게 만들기

Cursor의 Plan Mode는 에이전트가 코드를 변경하기 전에 조사하고, 명확한 질문을 던지며, 수정 가능한 마크다운 (Markdown) 계획을 작성하도록 합니다. Cognition의 Devin 2.0은 초기 단계에서 예비 계획과 관련 파일들을 사용자 앞에 제시합니다. JetBrains Junie, GitHub Spec Kit, 그리고 AWS Kiro는 모두 다음과 유사한 순서를 향해 나아가고 있습니다:

requirements.md → plan.md → tasks → code

이 순서에서 중요한 부분은 오해 (Misunderstanding)를 프로세스의 더 이른 단계로 이동시킨다는 점입니다.

만약 에이전트가 계획 단계에서 요청을 오해했다면, 수정은 대개 마크다운 파일의 문장 하나로 끝납니다. 하지만 구현 (Implementation) 중에 요청을 오해했다면, 수정에는 차이점 검토 (Diff review), 재작업 (Rework), 그리고 이미 코드베이스 전반에 퍼졌을지도 모를 부작용 (Side effects)에 대한 정리 작업이 필요합니다.

유용한 계획은 코드가 존재하기 전에 중요한 제약 사항들을 검사 가능하게 (Inspectable) 만듭니다: /api/files 대신 /api/upload를 사용할 것, 새로운 설정 플래그 (Configuration flag)를 피할 것, 기존의 제한기 (Limiter)를 재사용할 것, 회귀 테스트 (Regression test)를 먼저 추가할 것 등입니다.

계획은 첫 번째 정렬 표면 (Alignment surface)입니다.

조종 (Steering)은 실행 중에도 계속되어야 한다

계획이 있다고 해서 긴 에이전트 실행 과정에서의 드리프트 (Drift)가 사라지는 것은 아닙니다.

Anthropic의 Measuring AI agent autonomy in practice 보고서에 따르면, Claude Code는 이제 어려운 작업에 대해 스스로 명확한 설명을 요구하며 중단하는 빈도가 인간 리뷰어가 인간 쌍(human pairs)을 중단시키는 빈도보다 더 높다고 합니다. 이러한 동작은 단순한 UX(사용자 경험) 디테일이 아닙니다. 그것은 제어 메커니즘 (control mechanism)입니다.

유용한 에이전트는 자신이 추측하고 있을 때를 식별할 수 있어야 합니다.

작업 목록 (Task lists)도 동일한 목적을 수행합니다. 이는 단순히 진행 상황을 보고하는 것이 아닙니다. 작업이 진행 중인 동안 에이전트의 분해 (decomposition) 과정을 드러냅니다:

- [ ] 업로드 속도 제한 (rate-limit) 미들웨어 추가
- [ ] 새로운 제한 (limiter) 설정 플래그 생성
- [ ] /api/files 테스트 업데이트

두 번째와 세 번째 항목은 오해를 보여주며, 이는 수정 비용이 여전히 저렴할 때 발견됩니다. 최종 디프 (diff)가 나올 때까지 기다리면 동일한 문제를 격리하기가 더 어려워집니다.

병렬 기술 (Parallel skills)은 이를 더욱 중요하게 만듭니다. 프론트엔드 기술, 마이그레이션 기술, 테스트 작성 기술, 그리고 리뷰어 에이전트가 모두 동시에 실행될 수 있습니다. 이는 처리량 (throughput)을 높일 수 있지만, 각 작업자 (worker)가 자신의 가정 (assumptions), 작업 (tasks), 그리고 중간 상태 (intermediate state)를 드러내지 않는 한, 시스템이 '완료 (done)'에 대한 서로 다른 정의를 선택할 수 있는 지점들을 더 많이 만들어냅니다.

워크플로 (workflow)에 여러 에이전트가 관여하게 되면, 채팅과 PR (Pull Request) 리뷰만으로는 충분하지 않습니다. 시스템은 작업이 진행 중인 동안 각 에이전트가 자신이 무엇을 하고 있다고 믿는지에 대한 가시성 (visibility)을 확보해야 합니다.

의도 (Intent)는 세션 동안 유지되어야 한다

다음 문제는 메모리 (memory)입니다.

이것은 사용자 개인화 (user personalization)를 위한 메모리가 아니며, 단순히 재사용 가능한 기술의 라이브러리도 아닙니다. 절차 (Procedures)도 유용하지만, 더 중요한 계층은 실행 가능한 메모리 (actionable memory)입니다. 즉, 시스템이 이전 실행에서 발생한 일로부터 무엇을 배우느냐 하는 것입니다.

모든 진지한 에이전트 실행은 흔적을 남깁니다. 에이전트가 작성한 계획, 열었던 파일, 세운 가정, 실행한 명령, 무시한 리뷰어의 코멘트, 그리고 마침내 작업을 수용 가능하게 만든 인간의 수정 사항은 모두 유용한 신호 (signals)입니다.

이러한 증거들은 채팅 기록 속으로 사라져서는 안 됩니다. 그것은 학습 루프 (learning loop)가 될 수 있습니다:

실행 로그 (run logs) → 후보 레슨 (candidate lessons) → 평가자 (evaluator) → 행동 업데이트 (behavior updates) → 향후 실행 (future runs)

속도 제한기 (rate-limiter) 실패 이후, 교훈은 단순히 "속도 제한기 기술을 작성하라"가 아닙니다. 유용한 교훈은 더 좁은 범위여야 합니다: 이슈에서 엔드포인트(endpoint)를 명시하면, 편집하기 전에 경로(route)를 확인하십시오. 계획(plan)에서 명시적으로 요청하지 않는 한 제품 노출형 설정(product-facing configuration)을 도입하지 마십시오. 요청된 알고리즘과 기존 패턴이 일치하지 않으면, 중단하고 질문하십시오.

이것들이 바로 행동 업데이트 (behavior updates)입니다. 이것들은 프로젝트 지침 (project instructions), 플래너 루브릭 (planner rubrics), 리뷰어 체크 (reviewer checks), 중단 정책 (interruption policies), 또는 때로는 기술 (skill)에 반영될 수 있습니다. 또한 이들은 향후 행동을 바꾸기 전에 반드시 평가되어야 합니다. 평가는 해당 교훈이 로그에 의해 뒷받침되는지, 안전할 만큼 충분히 좁은 범위로 설정되었는지, 그리고 동일한 유형의 실수를 방지할 가능성이 있는지 물어야 합니다.

이는 개선 (improvement)을 측정하는 방식 또한 변화시킵니다. 로그, 레슨, 그리고 평가 결과 (evaluation outcomes)를 유지하면 범위 이탈 (scope drift)이 감소하고 있는지, 리뷰어가 반복되는 실수를 덜 잡아내고 있는지, 인간의 수정 (human corrections) 규모가 작아지고 있는지, 그리고 메모리 업데이트 (memory update)가 오류를 줄였는지 아니면 프롬프트 노이즈 (prompt noise)만 추가했는지를 질문하는 것이 가능해집니다.

평가 (evaluation)가 없는 메모리는 큰 가치를 지니지 못합니다. 로그 및 평가와 결합된 메모리는 개선 시스템 (improvement system)이 됩니다.

검증 (Verification)은 의도 (intent)를 확인해야 합니다

테스트 (Tests)는 코드가 작성된 케이스 (cases)에 따라 동작하는지를 설명합니다.

하지만 테스트가 에이전트가 요청된 것을 구축했는지 여부를 반드시 보여주는 것은 아닙니다.

그 간극 때문에 Anthropic의 Outcomes 프리미티브 (primitive)가 흥미로운 것입니다. Outcome은 별도의 에이전트가 새로운 컨텍스트에서 결과를 채점하는 데 사용할 수 있는 마크다운 루브릭 (Markdown rubric)입니다. 플래너 (planner)는 루브릭이 충족될 때까지 루프를 돌 수 있습니다. 여기서 중요한 변화는 시스템이 단순히 명령이 통과했는지만을 묻지 않는다는 점입니다. 구현이 시작되기 전에 작성된 기준 (criteria)을 결과가 충족하는지를 묻습니다.

속도 제한기 예시의 경우, 유용한 루브릭은 다음과 같을 수 있습니다:

다음 조건들을 충족하면 구현이 성공적인 것으로 간주합니다:

/api/upload가 인증된 사용자당 슬라이딩 윈도우 제한 (sliding-window limit)을 강제합니다.
제품에 노출되는 새로운 설정 (configuration)이 도입되지 않습니다.
...

이는 리뷰어에게 계약 (contract)을 제공합니다. 리뷰는 더 이상 단순히 diff가 합리적으로 보이는지 여부에만 의존하지 않습니다.

Agent-as-a-Judge survey 또한 같은 방향을 가리킵니다. 판사 에이전트 (judge agents)는 최종 답변에 대해서만 점수를 매기는 대신 중간 단계 (intermediate steps)를 관찰할 때 더 신뢰할 수 있게 됩니다. 관찰이 중요한 이유는 리뷰 에이전트가 단순히 최종 diff를 검사하는 것뿐만 아니라, 작업이 어떻게 수행되었는지 이해해야 하기 때문입니다.

한 에이전트는 구축하고, 다른 에이전트는 검토합니다. 루브릭 (rubric)은 목표를 정의합니다. 인간은 여전히 어떤 실패가 중요한지를 결정합니다.

스택이 수렴하고 있습니다

계획 (Plan). 조종 (Steer). 기억 (Remember). 검증 (Verify).

이전에는 이들이 별개의 연구 및 제품 스레드로 보였습니다. 이제 이들은 에이전트 스택 (agent stack)의 표준적인 형태가 되어가고 있습니다.

계층 (Layer)	산출물 (Artifact)	보호 대상
계획 (Plan)	`plan.md`, `.cursor/plans/`, Spec Kit, Playbooks	코드 작성 전 에이전트의 이해도
...

중요한 변화는 에이전트의 신뢰성 (reliability)이 단순히 프롬프팅 (prompting)의 문제가 아니라 시스템의 문제 (systems problem)가 된다는 점입니다.

계획은 인터페이스 (interface)입니다. 기술도 인터페이스입니다. 작업 목록 (task list)도 인터페이스입니다. 루브릭도 인터페이스입니다. 리뷰어 프롬프트도 인터페이스입니다. 각각은 시스템의 한 부분에서 다른 부분으로 의도 (intent)를 전달합니다.

이 작업은 다른 구성 요소 세트에 적용된 소프트웨어 설계 (software design)입니다.

이것이 엔지니어링 팀에 의미하는 바

모델 제공업체는 더 나은 모델을 출시할 수 있습니다. 도구 벤더는 더 나은 플래너 (planners), 사양 워크플로 (spec workflows), 플레이북 (playbooks), 그리고 리뷰 시스템을 출시할 수 있습니다.

하지만 이러한 도구들은 여전히 특정 코드베이스 내부에서 무엇이 정확성 (correctness)을 의미하는지는 알지 못합니다.

그들은 빌링 시스템 (billing system)이 엔터프라이즈 고객에 대해 재시도 (retries)를 다르게 처리한다는 사실을 알지 못합니다. 그들은 마이그레이션 도구가 생 SQL (raw SQL)이 아닌 drizzle:generate를 통해 실행되어야 한다는 사실도 모릅니다. 팀의 모든 구성원이 내재화하고 있기 때문에 암묵적으로 존재하는 제품 제약 조건 (product constraints)이 무엇인지도 알지 못합니다.

그러한 지식은 내구성이 있고 사용 가능한 어딘가에 존재해야 합니다.

만약 지식이 단지 사람의 머릿속에만 있다면, 에이전트 (agent)는 이를 놓칠 것입니다. 만약 지식이 단지 채팅 (chat)에만 있다면, 그것은 사라질 것입니다. 만약 지식이 최종 PR 리뷰 (PR review) 단계에서만 나타난다면, 이미 많은 결정이 내려진 후에야 도달하게 될 것입니다.

실질적인 작업은 명확하며 가치가 있습니다:

팀이 편집할 수 있는 계획 (plans)을 작성합니다.
실행 로그 (run logs), 리뷰어의 발견 사항 (reviewer findings), 그리고 인간의 수정 사항 (human corrections)을 보존합니다.
반복되는 실패를 범위가 지정된 후보 교훈 (scoped candidate lessons)으로 전환합니다.
에이전트의 동작을 변경하기 전에 해당 교훈들을 평가합니다.
구현 전에 성공 기준 (success criteria)을 명시적으로 만듭니다.
메모리 업데이트 (memory updates)가 드리프트 (drift), 반복되는 실수, 그리고 인간의 수정 사항을 줄이는지 측정합니다.

이것이 코딩 에이전트 (coding agents)를 위한 제어 평면 (control plane)입니다.

제어 평면이 주요 편집 영역 (editing surface)이 되고 있습니다

수년 동안 에디터 (editor)는 대부분의 소프트웨어 작업이 이루어지는 곳이었습니다. 코드가 변경되면 컴파일러 (compiler)나 테스트 스위트 (test suite)가 반응했고, 피드백 루프 (feedback loop)는 로컬(local) 상태로 유지되며 가시적이었습니다.

코딩 에이전트 (coding agents)는 그 루프의 일부를 한 단계 위로 이동시킵니다.

이제 중요한 편집은 handler.ts 외부에서 이루어지는 경우가 많습니다: plan.md, SKILL.md, CLAUDE.md, 작업 목록 (task lists), 루브릭 (rubrics), 그리고 리뷰어 지침 (reviewer instructions) 등에서 이루어집니다. 이러한 파일들은 에이전트가 무엇을 보는지, 무엇을 변경할 수 있는지, 진행 상황을 어떻게 보고하는지, 그리고 결과가 어떻게 판단되는지를 결정합니다.

모델 (model)은 여전히 중요하지만, 그것이 제품의 전부는 아닙니다. 제품은 모델을 신뢰할 수 있는 작업으로 전환하는 아티팩트 (artifacts), 리뷰어 (reviewers), 메모리 (memories), 체크 (checks), 그리고 인간의 결정 지점 (human decision points)을 포함하는 주변 시스템입니다.

실질적인 이점은 그 주변 시스템을 잘 설계하는 데서 옵니다.