이 기사는 2026년 7월 시점의 정보를 바탕으로 합니다. 모델의 능력이나 에이전트 제품의 상황은 변화가 빠른 영역이므로, 읽으시는 시점에는 상황이 바뀌어 있을 가능성이 있습니다.

모델의 세대교체가 가져오는 것은 동일한 태스크(Task)의 성공률 향상만이 아닙니다. 어느 공정을 에이전트에게 위임할 수 있는가 하는, 경계선의 이동을 동반합니다.

테스트나 규칙 등, 지식을 어디에 작성할 것인가에 대한 설계(이 기사에서는 「지식 집약 구조」라고 부릅니다)는 이 위임의 경계선에 맞춰 조정됩니다. 경계가 움직이면, 오래된 경계를 전제로 한 제약은 안전책에서 발목을 잡는 장애물로 반전됩니다.

그렇기에 지식 집약 구조에는 최종 형태가 없으며, 낡아지는 것을 전제로 계속해서 다시 그려 나갈 수밖에 없습니다. 실무상의 규율은 어떤 경계를 전제로 구조를 그렸는지를 기록하고, 경계가 움직였을 때 낮은 비용으로 업데이트할 수 있는 형태로 유지하는 것입니다.

새로운 모델의 평가는 「벤치마크가 몇 포인트 올랐는가」로 이야기되곤 합니다. 하지만 프로젝트를 운영하는 관점에서는 성공률 수치보다 중요한 변화가 있습니다. 그것은 「어제까지 인간이 할 수밖에 없었던 공정을 오늘부터 에이전트에게 맡길 수 있게 된다」는 위임 경계선의 이동입니다.

경계선이 움직이면 프로젝트에 관한 지식을 어디에 작성해야 할지도 바뀝니다. 무엇을 테스트로 고정하고, 무엇을 규칙으로서 문서화하며, 무엇을 작성하지 않고 에이전트의 판단에 맡길 것인가. 이 배분은 경계선의 위치를 전제로 한 설계 판단이기 때문입니다.

이 기사는 코딩 에이전트(Coding Agent)를 프로젝트에 도입하고 있으며, 테스트 전략이나 에이전트용 규칙(CLAUDE.md 등)의 배치 방법을 재고하고 싶은 개발자·팀 리더를 대상으로 합니다. 먼저 필자가 이러한 관점에 이르게 된 경험을 소개하고, 다음으로 핵심이 되는 사고방식을 제시하며, 두 가지 실례(테스트 의미의 반전, 하네스(Harness)로의 위임 범위 확대)로 뒷받침한 뒤, 마지막으로 실무상의 규율로 연결합니다. 개별 도구의 셋업 절차는 다루지 않습니다.

이 기사를 쓰게 된 계기는 어떤 퍼포먼스 튜닝(Performance Tuning) 세션이었습니다. 처리 속도 개선을 목적으로, 「동일한 결과를 유지할 수 있다면 로직 자체를 변경해도 좋다」고 지정하여 에이전트(모델은 Fable)에게 작업을 맡겼습니다.

에이전트는 개선으로 이어질 법한 가설을 여러 개 스스로 제안했습니다. 그리고 어떤 가설이 목적에 가장 부합하는지 확인하는 테스트 코드(Test Code)를 스스로 작성하고, 측정하여 비교했습니다. 인간이 전달한 것은 목적과 「로직 변경 가능」이라는 허가뿐입니다. 가설 수립부터 검증 수단 준비까지 에이전트 측에서 완결되었고, 세션은 마지막까지 진행되었습니다.

이 경험에서 인상 깊었던 것은 성능 수치보다 맡길 수 있는 범위의 변화였습니다. 얼마 전까지만 해도 「구현을 맡긴다」였던 것이 「검증 방법을 생각하는 것까지 맡긴다」로 확장되어 있었습니다.

동시에 인간 측의 책임도 변하고 있었습니다. 구현 코드를 하나씩 리뷰하는 대신, 에이전트가 준비한 테스트 코드의 방침이 타당한지를 확인하는 것. 그것이 인간 측의 일이 되어 있었습니다. 이 변화를 일반화한 것이 다음에 서술할 위임의 경계선이라는 관점입니다.

어느 공정을 에이전트에게 맡길 수 있는지는 두 가지 축의 조합으로 결정됩니다.

능력: 모델이 해당 공정을 충분히 수행할 수 있는가 -
권한: 그것을 실행하도록 해도 되는가 (어디까지를 인간이 확인하고, 어디서부터 앞을 신뢰하여 맡길 것인가)

둘 중 하나의 축만 움직여도 경계선은 이동합니다. 예를 들어 코딩 에이전트에게 쉘(Shell) 실행 권한을 부여하는 것은 권한 축의 이동이며, 모델의 세대교체는 능력 축의 이동입니다. 능력은 계속 확대되고 권한도 실적에 따라 단계적으로 개방되기 때문에, 경계선은 앞으로도 계속 움직일 것입니다.

단, 두 축은 대칭적이지 않습니다. 능력적으로 실행 가능한 공정이라도 「실행해서는 안 된다」는 판단은 계속 남기 때문입니다. 예를 들어 경영에 관련된 판단에서는 보조하는 에이전트의 성능이 아무리 올라가도 결재를 수행하는 것은 항상 인간입니다. 이러한 판단 기준은 코드 어디에도 적혀 있지 않으며, 에이전트가 코드를 읽어도 도출해낼 수 없습니다. 권한의 경계선은 개방되는 한편, 인간 측에 남는 마지노선이 있습니다.

프로젝트의 지식은 놓는 위치에 따라 구속의 강도가 달라집니다. 위치는 크게 세 가지 층으로 나뉘며, 각 층에는 여러 메커니즘이 속합니다.

강제의 층: 테스트, 에이전트의 hook, CI, 권한의 deny 리스트 등. 위반하면 앞으로 나아갈 수 없는 형태로 기계적으로 강제됩니다 -
지침의 층: 규칙, 스킬, 문서 등. 에이전트의 제안을 방향 지시합니다 -
기록의 층: 커밋 로그(Commit Log) 등의 작업 기록. 나중에 참조할 수 있습니다 -

그리고 "무엇을 어느 정도의 강도로 고정할 것인가"에 대한 판단은 에이전트에 대한 신뢰도, 즉 위임 경계(Delegation Boundary)의 위치에 따라 달라집니다.

운용의 예시를 하나 들어보겠습니다. 요구사항을 전달받아 구현안 제안까지 맡길 수 있는, 넓은 경계를 가진 에이전트를 도입한 프로젝트라면 지식의 배치 위치를 다음과 같이 이동할 수 있습니다.

강제의 층: 동작을 세밀하게 고정하던 테스트를 얇게 만들고, 반드시 지켜야 할 최후의 보루 이외에는 지침의 층(규칙)으로 격하시킴 -
지침의 층: 규칙 중 에이전트가 상식으로서 확실히 알고 있는 사항은 삭제함 -
기록의 층: 작업 경위나 시행착오는 에이전트가 승인 없이 자유롭게 커밋 로그(Commit Log)에 기록하도록 허용함

경계가 앞쪽에 있는(구현의 일부만을 맡기는) 프로젝트라면, 동일한 지식을 더 강력한 층에 배치하게 됩니다. 배분은 경계의 위치에 따라 결정됩니다.

문제는 경계가 이동한 이후입니다. 에이전트의 능력 부족을 보완하기 위해 설정한 제약은, 그 부족함이 해소되는 순간 의미가 변합니다. 지켜주던 울타리가 탐색을 방해하는 족쇄가 됩니다. 구조 자체는 한 줄도 변하지 않았는데, 경계의 위치가 바뀌는 것만으로 동일한 구조의 가치가 반전되는 것입니다.

이하에서는 경계의 이동이 구조의 의미를 어떻게 바꾸는지 두 가지 실례를 통해 확인하겠습니다.

"테스트는 두껍고 포괄적일수록 안전하다"라는 전제에 대한 비판은 새로운 것이 아닙니다. Kent Beck은 2008년에 "나는 동작하는 코드에 대가를 받는다. 테스트에 받는 것이 아니다"라고 언급했으며, Google Testing Blog는 2015년에 동작은 같지만 구현 변경으로 인해 실패하는 테스트는 유해하다고 지적했습니다. 1999년부터 2019년까지 테스트의 중후화(Heavyweight)를 경계하는 주장은 반복적으로 발표되어 왔습니다1.

이러한 지적이 계속되었음에도 테스트의 중후화는 쉽게 사라지지 않았습니다. 중후화에는 이유가 있기 때문입니다. 자동 테스트는 코드의 품질이나 일관성을 지키는 메커니즘(거버넌스, Governance)으로서 가장 도입하기 쉬운 수단입니다. 그 때문에 본래 설계 사상의 공유나 팀 육성과 같은 다른 방법으로 케어해야 할 부분까지 테스트로 전가되기 쉬운 구조가 있었습니다.

테스트는 구현 방침의 공간에 대한 가지치기(Pruning)로서 작동합니다. 하나의 테스트는 "이 동작을 바꾸는 구현은 금지"라는 선언이며, 테스트를 늘릴수록 살아남는 구현은 작성한 인간이 예기한 형태로 좁혀집니다. 인간만이 구현하던 시대에도 이 가지치기 비용은 지불되고 있었습니다. 테스트의 수만큼 유지보수 공수가 늘어나고, 기존 테스트가 신규 기능 추가를 어렵게 만드는 상황도 있었습니다. 그럼에도 불구하고, 가지치기 당해서 곤란할 정도로 넓은 탐색은 애초에 실행할 수 없었습니다. 여러 구현안을 써보며 비교하는 데 인력을 투입하는 것은 경제적으로 성립하지 않았기 때문입니다. 유지보수 비용이 들더라도 탐색을 잃음으로써 발생하는 비용이 작았기에, 변경을 기계적으로 감지해 주는 중후한 테스트는 수지타산이 맞는 보험이었습니다.

이러한 중후하고 구현에 밀접하게 결합된 테스트가 안고 있던 문제는 코딩 에이전트의 등장으로 드러나기 쉬워졌습니다. 에이전트가 넓은 구현 공간을 탐색하고 인간이 예기하지 못한 구현안을 제안할 수 있게 되면 손익 계산이 달라집니다. 포괄적인 테스트는 "이전과 동일한 동작"을 통째로 고정해 버리기 때문에, 본질과 관계없는 동작의 차이까지 테스트를 실패하게 만들고 제안을 거부합니다. 가지치기로 인해 상실되는 탐색 가치는 모델의 제안 능력에 비례하여 증대됩니다.

즉, "얇은 테스트가 좋다"라는 주장 자체는 20년 된 재확인에 불과하지만, 그 무게감이 달라졌습니다. 과거에는 인간의 리팩터링(Refactoring) 자유도를 위한 조언이었던 것이, 이제는 에이전트의 탐색을 활용하기 위해 필수적인 전제가 된 것입니다.

테스트를 얇게 만드는 것은 구현의 선택을 에이전트에게 위임하는 것과 동전의 양면과 같습니다. 지켜야 할 최후의 보루만을 테스트로 남기고 나머지는 맡기는 것. 이것은 움직이는 경계선에 맞춘 지식 집약 구조의 재설계입니다.

에이전트를 루프(Loop)로 계속 돌려 결과물을 만들게 하는 메커니즘(Harness)은 이전부터 존재했습니다. Geoffrey Huntley가 2025년 7월에 공개한 Ralph loop는 자연어로 작성된 하나의 사양서(PROMPT.md)를 루프를 통해 에이전트에게 계속 제공하는 수법입니다. OpenAI Codex의 goal mode 역시 목표를 부여하여 에이전트를 자율적으로 구동시키는 공식 기능입니다2.

주목해야 할 점은 goal mode의 공식적인 방식입니다. 측정 가능한 타겟이나 테스트 기준을 목표(Goal)에 작성하도록 되어 있습니다. 즉, 완료를 판정하는 기준은 인간이 준비하여 전달하는 설계입니다. 경계선이 이 위치에 있는 동안에는 판정 기준을 공급하는 것이 인간의 업무로 남게 됩니다.

경계선이 앞으로 이동하면, 동일한 하네스(Harness)에 맡길 수 있는 범위가 넓어집니다. 참조가 되는 정보(기존 구현이나 사양)로부터 에이전트 스스로가 판정 기준을 도출할 수 있다면, 인간이 모든 기준을 일일이 작성할 필요가 없어지며, 에이전트는 판정 기준 그 자체를 제안할 수 있게 됩니다. 인간의 역할은 기준을 처음부터 쓰는 것에서, 제안된 기준을 확인하고 승인하는 것으로 옮겨갑니다. 메커니즘은 그대로 유지된 채, 위임의 범위가 '작업의 실행'에서 '판정 기준의 제안'까지 확장되는 것입니다. 이것 또한 경계선 이동의 한 가지 현상입니다.

경계선이 실제로 움직였음을 보여주는 사례로 Bun의 이식(Porting)이 있습니다. Bun의 코어 런타임(Core Runtime)은 GitHub PR #30412(브랜치명 claude/phase-a-port)에서 Zig에서 Rust로 이식되었습니다. PR 생성은 2026년 5월 8일, main으로의 머지(Merge)는 5월 14일이며, 추가된 행수는 약 100만 행(1,009,257행)입니다. Bun 팀은 Anthropic 산하에 있으며, 이식 과정에는 Claude Code가 대규모로 사용되었습니다.

이 이식에서 흥미로운 점은 다음 두 가지입니다.

• 참조 구현이 판정 기준을 겸함: PR 본문에는 "아키텍처도 데이터 구조도 기존과 동일함"이라고 명시되어 있으며, 리포지토리 내의 이식 계획서에는 Zig 구현과 Rust 구현의 출력을 대조하는 shadow-diff 검증이 기록되어 있습니다. 기존 테스트 스위트(Test Suite)의 통과와 더불어, 기존 구현 그 자체가 '정확성'의 참조로서 기능했습니다.
• 경계가 모두 움직인 것은 아님: 머지 후에도 안정 버전(Stable version)은 Zig 기반의 v1.3.14로 유지되고 있으며, Rust 버전은 canary 버전으로만 제공됩니다. 어떤 차이를 허용하여 안정 버전에 포함할지에 대한 판단은 인간의 몫으로 남아 있습니다.

100만 행 규모의 이식을 에이전트 측의 검증 루프(Verification Loop)로 돌릴 수 있게 된 한편, 최종 판단의 권한은 인간이 보유하고 있습니다. 능력 축은 크게 움직였지만, 권한 축은 부분적으로만 움직였다는 경계의 움직임을 여기서 확인할 수 있습니다.

경계선이 계속 움직인다면, 지식 집약 구조는 "한 번 올바르게 설계하고 끝"낼 수 없습니다. 실무에서 할 수 있는 일은 업데이트 비용을 낮춰두는 것입니다. 구체적으로는 두 가지 규율로 요약됩니다.

문서화해야 할 범위는 "에이전트가 확실히 가지고 있지 않은 지식"입니다. 현재의 모델이 확실히 지킬 수 있는 보편적인 사항(예를 들어 "메모리 누수(Memory Leak)를 일으키지 말 것")을 규칙에 적을 필요는 없습니다. 다만, 이 기준선은 모델에 따라 달라집니다. 적지 않고 넘어간 전제는 모델을 교체하는 순간 누락됩니다. 따라서 어떤 모델 능력을 전제로 그 선을 그었는지를 규칙 자체에 기록해 두어야 합니다.

같은 배움을 반복해서 재발견하고 있다면, 그 지식은 더 강력한 계층(규칙이나 테스트)으로 승격시킬 시기입니다. 반대로, 제약을 두었던 이유가 환경 변화로 사라졌다면 강등하거나 폐기합니다. 이 강등 판정을 가능하게 하는 것은 제약을 두었을 때의 이유를 기록해 두는 것입니다. "왜 이 제약을 두었는가"를 버리고 제약만 남겨두면, 경계가 이동한 뒤에 그 제약이 낡은 것인지 아닌지를 판정할 수 없게 됩니다. 승격 메커니즘만 있고 버리는 메커니즘이 없는 구조는 과거 환경의 잔재로 가득 차게 될 것입니다.

마지막으로, 이 주장은 자기 자신에게도 적용됩니다. 이 기사가 보여준 정리 또한 2026년 7월 시점의 능력과 권한의 경계에 맞춰 조정된 조감도입니다. 경계가 더욱 이동한다면, "테스트를 얇게 만들기", "전제 모델을 병기하기"와 같은 규율의 구체적인 형태도 다시 그려야 할 것입니다. 변하지 않는 것은, 구조가 어떤 경계를 전제로 하고 있는지를 자각하고, 경계의 이동을 감지하면 구조를 의심하는 자세입니다.

모델의 세대교체를 평가할 때, "똑똑해졌는가"와 더불어 "맡길 수 있는 범위가 어떻게 변했는가"를 살펴보는 것을 추천합니다. 경계선이 움직였다고 느껴진다면 테스트, 규칙, 로그의 배분을 재검토할 타이밍입니다. 과거의 안전장치가 지금의 족쇄가 되어 있지는 않은지. 그 점검 자체를 프로젝트의 상시적인 업무로 편입시키는 것이, 경계선이 계속해서 움직이는 시대와 함께 살아가는 방법이라고 생각합니다.

• Brian Marick의 「How to Misuse Code Coverage」(1999). Kent Beck의 『Test-Driven Development: By Example』(2002), 그리고 Stack Overflow 답변(2008). Ian Cooper의 「TDD, Where Did It All Go Wrong」(NDC Oslo 2013). DHH의 「Test-induced design damage」(2014). James O. Coplien의 「Why Most Unit Testing is Waste」(2014). Google Testing Blog의 「Change-Detector Tests Considered Harmful」(2015). Kent C. Dodds의 「Write tests. Not too many. Mostly integration.」(2018). Kent Beck의 「Test Desiderata」(2019). ↩

goal mode 공식 문서에 대한 내용은 2026년 6월 21일 조회 시점의 것입니다. ↩