실전 Agentic Coding – Diverge · Decide · Converge

나는 개인 프로젝트에서 서로 다른 모델과 Reasoning 단계들을 꽤 의식적으로 시험해 본다. 학문적인 호기심 때문이 아니라 차이를 바로 체감하기 때문이다. 규모는 크지만 대부분 기계적인 리팩터링 하나도 강력한 High-Reasoning 모델로는 아주 잘 끝낼 수 있다. 동시에 제한된 주간 할당량의 놀라울 정도로 큰 부분을 소모할 수도 있다.

그래서 이런 작업에는 요즘 일부러 낮은 Reasoning 단계를 자주 사용한다. 그 모델들이 본질적으로 더 낫다고 생각해서도 아니고, 고성능 모델이 가격만큼의 가치가 없다고 생각해서도 아니다. Requirements Engineering, 아키텍처 질문, 어려운 분석에서는 지금도 강력한 Frontier 모델을 거의 포기하고 싶지 않다. 하지만 반복적인 작업에서는 이제 다른 질문을 하게 된다. 정말 이 작업에도 같은 수준의 모델 지능이 필요한가?

기업 환경에서는 이런 피드백이 더 약한 경우가 많다. Token 사용량, Credits, API 비용은 중앙에서 부담하고 개별 개발자는 간접적으로만 보게 된다. 충분히 이해할 수 있는 상황이지만, 그 결과 모델 지능을 의식적으로 Routing하지 않는 작업 방식이 쉽게 생긴다. 가장 강한 모델이 있으니 그냥 가장 강한 모델을 쓴다. 개인 사용에서는 단순한 리팩터링 하나가 갑자기 주간 할당량의 상당 부분을 먹어버리는 순간을 훨씬 빨리 체감한다.

이 경험은 내가 Agentic Coding을 보는 방식을 바꾸었다.

현재 사용할 수 있는 가장 강한 모델이 모든 작업에 자동으로 가장 합리적인 모델이 되는 것은 아니다.

그래서 나에게 더 흥미로운 질문은 이제 *어떤 모델이 가장 좋은가?*가 아니다. 오히려 다음이다.

이 구체적인 작업은 현재 진행 단계에서 실제로 어느 정도의 모델 지능을 더 필요로 하는가?

이 답은 우리가 그 활동에 Requirements, Architecture, Coding, Testing이라는 어떤 라벨을 붙이는지와 생각보다 관계가 적다. 더 중요한 것은 따로 있다. 아직 열려 있는 중요한 의사결정이 몇 개나 남아 있는가?

열린 의사결정 공간

Agentic Work를 대략 두 종류로 나누고 싶어지는 유혹이 있다. Requirements와 Architecture는 큰 모델에, Coding과 Tests는 작은 모델에 맡긴다는 식이다. 단순하지만 기술적으로는 너무 거칠다.

Coding도 매우 탐색적일 수 있다. 낯선 Legacy 시스템에서 재현하기 어려운 오류를 찾거나, 아키텍처 경계를 복원하거나, 지속 가능한 리팩터링 전략을 설계해야 한다면 우리는 코드 위에서 일하고 있지만 여전히 큰 의사결정 공간 안에 있다. 반대로 Requirements는 이미 거의 수렴한 상태일 수 있다. 기존 도메인 Contract에 정확히 정의된 필드 하나를 추가하는 작업이라면 남은 결정이 거의 없을 수도 있다.

그래서 나에게 더 유용한 축은 열린 의사결정 공간이다.

위쪽에 있을수록 우리는 의미 있는 Variance를 더 많이 필요로 한다. 대안을 보고 싶고, 가정을 공격하고 싶고, 관계를 발견하고 싶고, 때로는 스스로 생각하지 못한 해결책도 제안받고 싶다. 의사결정 공간이 작아질수록 원하는 Variance는 줄어든다.

변하는 것은 작업만이 아니다. 그 작업 안에서 모델이 맡아야 하는 역할도 달라진다.

Diverge: Variance가 필요한 단계

내가 오늘 하는 일의 상당 부분은 명확한 구현 지시로 시작하지 않는다. Tickets는 불완전하다. Requirements는 기존 동작 안에 암묵적으로만 존재하는 경우가 있다. Legacy 시스템은 자신의 아키텍처를 설명해 주지 않는다. 코드, 의존성, 과거의 의사결정에서 그것을 다시 복원하도록 강요한다. 오류의 원인은 처음에는 알 수 없고, 큰 변경에는 서로 다른 Trade-offs를 가진 여러 개의 그럴듯한 선택지가 존재한다.

이런 지점에서는 나는 Exploration을 원한다. 강력한 Planning 또는 Reasoning 모델에 문제를 주고, 실제 도메인 문제가 무엇인지, 기존 동작에 어떤 암묵적 Requirements가 숨어 있는지, 시스템의 어떤 부분이 영향을 받는지, 어떤 대안이 존재하는지, 서로 다른 아키텍처 선택이 어떤 결과를 낳는지부터 분석하게 한다. 특히 모델이 내 가정까지 공격해 주는 것이 중요하다. 때로는 일부러 이렇게만 말한다. 나를 놀라게 해봐.

특히 Requirements Engineering에서는 현재 거의 전적으로 강력한 Frontier 모델과 작업한다. 이것은 어떤 모델이 객관적으로 최고의 Requirements 모델이라는 주장도 아니다. 지금 내 실무 방식을 설명하는 것뿐이다. 나에게 핵심 가치는 단순히 더 좋은 문장이 아니라, 아직 의도적으로 닫지 않은 해결 공간을 함께 탐색할 수 있다는 데 있다.

POC도 나에게는 이 범주에 속한다. POC의 목적 자체가 종종 열린 기술 질문에 답하는 것이기 때문이다. 그 과정에서 코드가 만들어진다고 해서 그 작업이 자동으로 수렴된 구현 작업이 되는 것은 아니다. Legacy 분석, 원인을 모르는 오류, 또는 여러 가지 가능한 구조적 절단을 먼저 이해하고 싶은 리팩터링 질문도 마찬가지다.

이 단계에서 창의성은 실제로 Capability다. 아직 어떤 해법이 맞는지 모르기 때문에 창의성이 필요하다.

Decide: 불확실성이 모르게 코드로 흘러들어가면 안 된다

Exploration만으로 좋은 소프트웨어가 만들어지지는 않는다. 어느 시점에는 가능한 해법이 구체적인 결정으로 바뀌어야 한다. 여기서 나는 Agent가 Sparring Partner일 때와 자율적 의사결정자일 때의 중요한 차이를 본다.

모델은 선택지를 만들고, Trade-offs를 설명하고, 내가 선호하는 선택을 비판하고, 다른 선택이 가져올 결과를 보여줄 수 있다. 하지만 무엇을 실제로 만들 것인지에 대한 책임은 여전히 책임 있는 Engineering Team에 남는다.

따라서 실제로 Decide는 단순히 하나의 대안을 고르는 것보다 훨씬 많은 것을 의미한다. 분석 결과를 평가하고, 강한 모델에 다시 비춰 보고, 더 날카롭게 만들고, 마지막에는 명시적인 구현 지시로 번역한다. 이 과정은 여러 라운드가 될 수 있다.

중요한 것은 모든 작은 일을 정식 Architecture Decision Record로 만들자는 것이 아니다. 중요한 것은 관련된 결정이 기계적인 구현이 시작되기 전에 보이도록 만드는 것이다.

이것은 이 시리즈의 앞선 글들의 논리를 이어간다. Requirements Engineering은 도메인 모호성을 줄인다. Architecture는 구조적 해결 공간을 제한한다. 정보 보호는 Agent의 Context와 Capability를 제한한다. Decide는 그 경계 안에서 다음 질문에 답한다. 아직 열려 있는 결정 중에서 지금 실제로 무엇을 결정할 것인가?

그런 결정을 해결하지 않은 채 Coding 작업에 더 많이 넘길수록 Agent가 스스로 결정해야 할 부분도 늘어난다. 잘 될 수도 있고 매우 그럴듯해 보일 수도 있다. 하지만 그 순간 우리는 Software Design의 일부를 코드 생성 과정에 암묵적으로 위임한 셈이다.

옮기는 것만으로는 리팩터링이 아니다

내 실무의 작은 사례 하나가 이 경계를 아주 분명하게 보여줬다.

한 Coding Agent가 Business Orchestration을 UI Component 안에 구현했다. 나에게는 즉시 보이는 Architecture Smell이었다. 그 Component는 우리의 아키텍처 관점에서 자신이 맡아서는 안 되는 것들을 조정하고 있었다.

그래서 나는 Agent에게 이 Business Orchestration이 UI 밖으로 나가야 한다고 설명했다. 반응은 형식적으로 완벽했다. Agent는 그 로직을 Facade로 옮겼다.

하지만 불행히도 문제는 해결되지 않았다.

책임은 이제 다른 파일에 있었지만 실제 Orchestration의 구조적 절단은 여전히 잘못되어 있었다. Agent는 내 눈에 보이는 지시는 지켰지만 그 아래에 있는 아키텍처 결정을 다시 풀지는 않았다.

바로 이런 지점에서 Code Production과 Software Engineering의 차이가 특히 잘 보인다.

Architecture Smell을 알아보는 것은 종종 쉽다. 거기서 더 나은 구조를 도출하는 것이 실제 Engineering 작업이다.

나는 이런 경우 의식적으로 다시 분석과 계획으로 돌아간다. 다음 위치로 한 번 더 옮기라는 Prompt를 주는 대신, 관련 Context를 강한 Reasoning 모델에 다시 넣고 책임과 의존성을 분석하게 한다. 그리고 결과를 직접 검토한 뒤 다시 결정한다.

이것은 Diverge · Decide · Converge가 선형 Pipeline이 아니라는 점도 보여준다. 구현 자체가 새로운 정보를 만들 수 있다. Smell은 이미 결정했다고 생각했던 문제가 실제로는 충분히 해결되지 않았음을 보여줄 수도 있다.

그때는 의사결정 공간을 다시 열어야 한다.

Converge: 최대한의 지루함

핵심 의사결정이 실제로 끝나면 Coding Agent에 대한 내 기대는 완전히 달라진다. 그때는 더 이상 놀라움을 원하지 않는다.

작업 지시가 Scope를 설명한다. Agent Files가 규칙을 설명한다. Skills나 프로젝트별 Instructions가 이미 알려진 절차를 제공한다. Layering과 Slicing은 정의되어 있다. Patterns가 존재한다. Tests, Linter, Architecture Rules와 다른 Verification Mechanisms가 결과를 제한한다.

그때 내가 원하는 생성 코드의 이상형은 아주 간단히 요약할 수 있다.

최대한의 지루함.

아무도 요구하지 않은 새로운 Pattern은 필요 없다. 더 우아해 보인다는 이유로 추가 추상화를 만들 필요도 없다. 아키텍처 경계를 즉흥적으로 재해석하거나, 의도적으로 로컬하게 해결하려는 문제를 창의적으로 일반화할 필요도 없다.

충분히 수렴한 Task에서는 창의성이 반드시 Capability인 것은 아니다. Drift가 될 수도 있다.

전형적인 후보는 Mapper, DTO 변환, 간단한 Adapter, Moves와 Renames, 기계적 리팩터링, 명확하게 설명된 CRUD 일부, 또는 이미 자리 잡은 Pattern을 따라가는 Unit Tests다. 하지만 이것마저 새로운 고정 규칙으로 만들면 안 된다.

한 Unit Test는 거의 기계적일 수 있다. 이 Use Case의 기존 Tests와 같은 방식으로 구현해. 반면 다른 작업은 이럴 수 있다. 이 낯선 알고리즘을 분석하고 중요한 Invariants를 찾아 그로부터 신뢰할 수 있는 Test Strategy를 설계해. 둘 다 Unit Tests를 만든다. 의사결정 공간은 전혀 다르다.

Refactoring도 마찬가지다. 이미 명확히 식별된 구조를 Rename하거나 Move하는 것은, 어떤 구조가 도메인과 아키텍처 관점에서 맞는지를 결정하는 것과 다른 문제다.

그래서 나에게 Task Type은 기껏해야 Proxy다.

실제 질문은 어떤 파일 유형이나 Artefact를 만드는지가 아니라, 남은 작업에 Exploration, Judgment, Verification이 실제로 얼마나 필요한가이다.

Model Routing은 의사결정 공간을 따라야 한다

관련 결정이 이미 끝났고, 기존 Pattern이 명확하며, 작업이 관리 가능한 범위에 있고, 결과를 잘 검증할 수 있다면 더 작고 빠르고 저렴한 모델이 흥미로워진다.

반대로 도메인 관점에서 여러 개의 그럴듯한 해법이 존재하거나, 원인을 모르는 문제이거나, Architecture를 바꾸거나, 시스템의 큰 부분을 이해해야 하거나, 복잡한 Trade-offs를 평가해야 한다면 강한 모델의 중요성이 커진다.

이것은 작은 모델이 Deterministic하다는 뜻이 아니다. 작은 모델도 Hallucinate할 수 있고, 규칙을 놓칠 수 있고, 단순한 작업을 오해할 수 있고, 좋은 Instructions가 있어도 잘못된 방향으로 갈 수 있다. 작은 의사결정 공간이 모델의 본성을 바꾸는 것은 아니다. 모델에게 요구되는 작업의 성격을 바꾼다.

작은 의사결정 공간은 작업에 필요한 Exploration과 Judgment의 양을 줄인다.

따라서 저렴한 모델이 경제적인 이유는 어려운 결정을 조금 못하게 맡겨서가 아니다. 어려운 결정을 작업에 넘기기 전에 이미 제거했기 때문에 경제적이 되는 것이다.

여기에 나는 또 하나의 규칙을 둔다. 추측하지 말고 멈춘다.

Agent가 구현 중 필요하지만 아직 결정되지 않은 아키텍처 선택을 만났다면 나는 가장 그럴듯한 선택지를 추측해 주길 원하지 않는다. Contract가 모호하다면 만들어낸 Contract를 원하지 않는다. 기존 시스템에 서로 경쟁하는 두 Patterns가 있고 작업 지시에서 어느 쪽을 이어갈지 드러나지 않는다면 그 자체가 새로운 정보다.

그 다음 단계는 더 이상 Converge가 아니다. 의사결정 공간이 다시 열렸다. 지금 일하는 모델이 작든 크든 상관없이 동일하다.

내 워크플로는 Loop다

그래서 실제로 내 일하는 방식은 몇 년 전과 꽤 달라졌다.

나는 오랫동안 코딩을 정말 좋아하는 개발자였다. Tech Lead였을 때도, 이후 Software Architect가 된 뒤에도 늘 직접 구현했다. 나에게 Coding은 아키텍처를 보이게 만드는 필요한 수단에 불과하지 않았다. Software Development에서 좋아했던 것 자체의 일부였다.

오늘은 내가 직접 쓰는 코드가 놀랄 만큼 적다. 대신 문제를 이해하고, Requirements를 정리하고, 해결 공간을 분석하고, 아키텍처 결정을 하고, Constraints를 만들고, 작업 지시를 정의하고, Agents가 구현하게 하고, 결과를 이해하고 검토하는 데 많은 시간을 쓴다.

실제 작업 하나는 이제 보통 여러 개의 Loop로 이루어진다. 먼저 Ticket과 도메인 문제를 내가 직접 이해하고 분석 요청으로 바꾼다. 강한 모델이 시스템과 문제를 분석한다. 내가 결과를 평가하고 다시 모델에 넣으며, 충분히 신뢰할 수 있는 작업 지시가 나올 때까지 보완한다. 그 뒤에야 Coding Agent가 구현한다.

구현이 끝나도 이 과정은 끝나지 않는다. 내가 결과를 먼저 평가하고 모든 중요한 결과 단계를 강한 모델에 다시 넣는다. 이후 도메인 및 기술 Review, 필요하다면 Correction Brief, 재구현과 Verification이 이어진다. 이 Loop가 깔끔하게 끝난 뒤에야 Commit한다.

여기서 중요한 세부사항이 하나 있다. 나는 이미 오류를 발견한 뒤에만 결과를 강한 모델에 돌려주는 것이 아니다. 모든 중요한 결과 단계에서 그렇게 한다.

내가 직접 Review하고, 그 다음 모델을 추가 Review Channel로 사용한다. 이유는 단순하다. 오랜 Software Development와 Architecture 경험이 있어도 나는 놓치는 것이 있다. 강한 모델도 놓치는 것이 있다.

Human Review는 Model Review를 대체하지 않는다. Model Review도 Human Review를 대체하지 않는다.

이 방식이 과학적으로 최적이라고 주장하지 않는다. 지금 내 Workflow일 뿐이다. 하지만 이 시리즈의 Convincingly Wrong에서 이미 다뤘던 문제의 직접적인 결과다. Plausibility는 Verification이 아니다.

Diff가 합리적으로 보여도 도메인 관점에서 틀릴 수 있다. Model Review가 설득력 있게 들려도 무언가를 놓칠 수 있다. 경험 많은 개발자가 Patch를 이해해도 상호작용 하나를 빠뜨릴 수 있다. 그래서 나에게 품질은 점점 여러 독립적인 통제 수단에서 나온다. 내 이해, Model Review, Tests, Static Rules, 그리고 가능한 곳에서는 재현 가능한 도메인 Verification이다.

좋은 아키텍처는 변경의 사전 작업을 줄인다

여기서 나는 일상적으로 더 강하게 느끼는 또 다른 연결점을 본다. 단순한 CRUD Feature가 자동으로 단순한 Agent Task가 되는 것은 아니다.

도메인 관점에서는 평범한 Comment Feature를 생각해 보자. 명확한 Boundary, 알려진 Layering, 자리 잡은 Slice, 기존 CRUD Patterns, 명확한 Contracts가 있는 Greenfield 시스템이라면 작업은 실제로 빠르게 수렴할 수 있다. Agent는 먼저 이 Feature가 어디에 속하는지, 여러 기존 Patterns 중 어떤 것이 맞는지 복원할 필요가 없다.

반대로 오래된 Legacy 시스템에서는 같은 도메인 기능이 훨씬 앞 단계부터 시작하는 경우가 많다. 먼저 시스템의 어느 부분이 실제 책임을 갖는지 파악해야 한다. 서로 경쟁하는 구조가 나타나고, Dependencies를 복원해야 하며, 동시에 새 Feature가 Legacy를 더 늘려서도 안 된다. 경우에 따라 기존 구조를 막아낼 Boundary부터 찾아야 한다.

내 실무에서는 이 부분만 몇 시간이 걸릴 수 있다. 뒤의 CRUD가 복잡해서가 아니라, 구현 전에 충분히 신뢰할 수 있는 의사결정 공간을 먼저 만들어야 하기 때문이다.

우선 이것은 개인 경험이다. Repository 구조와 Context Retrieval에 관한 인접 연구와 그 한계는 8편 – Architecture as a Constraint에서 정리했다. Diverge · Decide · Converge에서 중요한 것은 그중 운영상의 질문이다. 작업이 구현 단계로 넘어가기 전에 아직 어떤 구조적 결정을 정리해야 하는가?

좋은 아키텍처가 Agent를 더 똑똑하게 만들지는 않는다. 하지만 의미 있는 구현에 들어가기 전에 필요한 일을 줄일 수는 있다.

Ownership, Boundaries, Layering, Contracts, Tests, Architecture Rules는 사람을 위한 Maintainability Tools일 뿐만 아니라 Orientation이다. Orientation이 있으면 Agent가 먼저 “우리가 실제로 무엇을 뜻했는지” 복원해야 하는 작업이 줄어든다.

여기서는 Tokens만큼 시간도 중요하다. 긴 분석 Loop는 Agent Runtime, Context, Model Usage, 읽기, Reviews, 보완, 사람의 주의를 소모한다. 잘 정의되지 않은 Task에서 가장 비싼 부분은 결국 Code Generation이 아닐 수도 있다. 어떤 코드가 만들어져야 하는지 분명해질 때까지 드는 작업이 더 비쌀 수 있다.

전체 경제성 분석은 별도의 글이 필요하다. 이 글에서는 열린 의사결정 공간이 품질 문제일 뿐 아니라 비용 요인이기도 하다는 점만 확인하면 충분하다.

Model Routing은 경제적으로도 중요해진다

현재 가격 구조를 잠깐만 봐도 차이가 어느 정도까지 벌어질 수 있는지 알 수 있다.

2026년 9월 기준 OpenAI는 ChatGPT Work와 Codex에서 예를 들어 GPT-5.6 Luna를 백만 Input Tokens당 0.20달러, Output Tokens당 1.20달러로, GPT-5.6 Sol을 기간 한정 Promotion 가격으로 각각 4달러와 20달러로, GPT-6 Astra를 10달러와 50달러로 제시한다. 같은 제품 생태계 안에서도 모델 클래스 사이의 차이가 높은 Agent Usage에서는 경제적으로 중요한 수준에 도달한다. OpenAI: Enterprise Rate Card; 추가로 Promotion 안내가 있는 Sol 모델 페이지.

Anthropic도 같은 원리를 보여준다. 현재 API 가격표는 예를 들어 Claude Haiku 4.5의 Input/Output 백만 Token당 1/5달러에서 Claude Sonnet 5의 2/10달러, Claude Fable 5.1의 10/50달러까지 이어진다. 이 수치는 2026년 9월 10일 시점의 스냅샷이지 품질 순위도 아니고 특정 작업에 대한 장기 추천도 아니다. Anthropic: API 가격표.

Reasoning도 단순한 가격 배수보다 더 복잡하다. 앞서 언급한 Enterprise 가격 구조에서는 OpenAI가 GPT-5.6의 서로 다른 Reasoning 단계에 같은 Token 단가를 적용한다. 그렇다고 서로 다른 Reasoning 단계가 같은 총사용량을 만든다는 뜻은 아니다. GitHub는 현재 Copilot 문서에서 높은 Reasoning Level이 더 많은 Tokens를 사용하고 따라서 더 많은 Credits를 소비할 수 있다고 명시한다. 단가와 실제 소비량은 서로 다른 문제다.

나는 이 메커니즘을 개인 사용에서 아주 직접적으로 체감한다. 하나의 기계적 Task에서는 차이가 사소해 보일 수 있다. 하지만 Agent Usage가 높아지면 할당량이 이틀 만에 끝나는지 일주일을 버티는지를 결정하게 된다.

산업도 이미 이에 반응하기 시작했다.

GitHub Copilot에는 이제 Task Optimization이 포함된 자동 Model Selection이 있다. GitHub에 따르면 Router는 Task Complexity와 현재 Model Availability 등을 고려하고, 추가 능력이 필요한 작업에는 더 비싼 Reasoning Models를 남겨 두는 반면 단순한 작업은 더 빠르고 저렴한 모델로 Routing하려고 한다.

GitHub의 자체 권고도 이제 명시적으로 research, plan, then implement 방향으로 간다. 더 강한 Reasoning으로 Planning을 하고, 그 다음 Execution에 적합한 모델로 집중된 구현을 수행한다. 또한 범위가 명확한 Subagents에는 저렴한 모델을 권하고, 정확한 Instructions와 Repository Maps가 불필요한 Exploration을 줄일 수 있다고 설명한다.

Model Routing은 이제 순수한 미래 개념이 아니다. 그래도 나는 이 자동화를 내가 말하는 Decide 단계와 혼동하지 않는다.

Router는 Prompt를 보고 Task가 얼마나 복잡해 보이는지 추정할 수 있다. 하지만 내 조직에서 어떤 Architecture Decision이 허용되는지, 기존의 두 Patterns가 역사적 잔재인지 의도적인 차이인지, 현재 Pattern에서 벗어나는 것이 이번에는 원하는 일인지까지 알지는 못한다. 또한 관련 결정이 Context나 Constraint로 보이지 않는다면 이미 어떤 결정이 내려졌는지 안정적으로 알 수도 없다.

자동 Model Routing은 의사결정 공간의 정의를 대체하지 않는다.

시스템에 우리가 실제로 보여주는 범위 안에서만 최적화할 수 있다.

로컬 모델은 선택 가능한 해결 공간을 넓힌다

Cloud 모델뿐 아니라 로컬로 돌릴 수 있는 모델까지 선택지에 들어오면 Model Routing은 더 흥미로워진다.

현재의 한 예는 Qwen3.8-27B다. Alibaba는 2026년 8월 14일 이를 Open-Weight 모델로 공개했다. 이 Dense 모델은 270억 개의 Language-Model Parameters를 가지고, 서로 다른 Reasoning 설정을 지원하며 Apache 2.0으로 제공된다.

제조사가 공개한 Coding Benchmarks는 눈에 띈다. Model Card에서 Qwen은 예를 들어 SWE-bench Pro 61.7%, Terminal-Bench 2.1 73.0을 명시된 Evaluation Conditions 아래에서 보고한다. 이 값은 제조사 Benchmark이고 그렇게 읽어야 한다.

이제 Artificial Analysis의 독립적인 측정도 존재한다. 거기에서도 Qwen3.8-27B는 자신의 Open-Weight 크기 등급에서 강한 모델에 속한다. 동시에 Evaluation은 Model Routing 관점에서 흥미로운 Trade-off를 보여준다. Maximum-Reasoning 버전은 매우 많은 Reasoning Output을 생성하고 비교상 훨씬 느리고 장황하다. 즉 로컬 모델에서도 더 많은 Reasoning은 무료 추상화가 아니다.

나는 아직 Qwen3.8-27B에 대한 신뢰할 만한 직접 경험이 없다. 그래서 현재의 Hype를 관심과 어느 정도의 회의감을 함께 가지고 본다. 적어도 이 클래스의 모델은 로컬로 실행 가능한 시스템이 명확히 경계 지어진 소프트웨어 작업에 진지하게 검토될 수 있는 성능 범위까지 왔다는 점은 보여준다. 지금은 그 이상을 추론하지 않겠다.

특히 Local은 Free를 의미하지 않는다. 공식 Model Card는 약 280억 Parameters의 BF16 Dense 모델을 설명하고 동시에 사용할 수 있는 Quantizations도 언급한다. 이것만으로도 우리가 평범한 개발자 인프라를 이야기하는 것이 아님은 분명하다. 고성능 로컬 Inference에는 Memory와 Compute가 필요하고, 운영에는 Hardware Acquisition, Electricity, Cooling, Maintenance, Updates, Utilization이 추가된다.

따라서 로컬은 비용 구조를 없애는 것이 아니라 이동시킨다.

Hardware, 운영, Utilization, 그리고 어떤 조건에서 어느 쪽이 경제적인지는 13편 – Agentic Work의 경제학에서 다룬다.

Specification이 크다고 의사결정 공간이 자동으로 닫히지는 않는다

여기서 자연스러운 오해 하나가 생긴다. 작은 의사결정 공간이 Implementation을 쉽게 만든다면 아주 오래된 소프트웨어 아이디어를 새 옷에 입혀 이렇게 생각할 수 있다. 큰 요구사항 문서를 쓰고 Agent에 넣으면 반대쪽에서 완성된 Product가 나온다는 식이다.

그렇게 되지 않는다.

Specification은 매우 클 수 있으면서 동시에 열린 결정으로 가득할 수 있다. 도메인 설명과 실제 동작하는 시스템 사이에는 Architecture, Ownership, Data Model, UX, Error Behavior, Security, Operational Behavior, Integration Strategy, Test Strategy가 여전히 결정되지 않은 상태로 남을 수 있다. Requirements 문서가 100페이지라고 해서 그 결정들이 사라지는 것은 아니다. 누군가 명시적으로 결정하지 않으면 구현 중에 결정된다. 그리고 그 결정자는 Agent가 된다.

큰 Specification이 자동으로 작은 의사결정 공간을 의미하지 않는다.

그래서 나에게 Spec Driven Development는 불확실성을 더 큰 문서에 쏟아 넣고 그 뒤에 Deterministic Code Generation을 기대하는 것이 아니다. 좋은 Specification은 실제로 결정이 내려진 곳에서 의사결정을 줄인다. Architecture Constraints가 더 줄인다. Contracts가 더 줄인다. Tests와 Verification Rules가 더 줄인다.

그때 비로소 작업이 수렴한다.

바로 이 지점에서 이 시리즈의 이전 글들이 만난다. Requirements Engineering은 도메인 해결 공간을 제한한다. Architecture는 구조적 해결 공간을 제한한다. 정보 보호는 Context와 Action Possibilities를 제한한다. 그리고 이렇게 점점 정의되는 공간 안에서 우리는 언제 Variance를 만들고 언제 줄일지를 의식적으로 결정한다.

코드 생산이 더 저렴해질 때

내 역할이 바뀐 것은 어쩌면 내가 가장 크게 적응해야 했던 부분일지도 모른다.

나는 코드를 쓰는 것을 좋아한다. 내 직업적 정체성의 상당 부분을 어려운 기술 문제를 직접 구현할 수 있다는 데 세워 왔다. 그래서 많은 개발자들이 Code Production 자동화를 IDE의 새로운 Refactoring Tool과는 다르게 받아들이는 이유도 이해한다. 20년 동안 코드를 잘 쓰는 능력에 투자해 왔다면, 바로 그 활동이 점점 자동화 가능해지는 일은 완전히 중립적인 경험일 수 없다.

그래도 나는 이것을 개발자의 몰락 이야기로 만드는 것은 유용하지 않다고 생각한다. 내 개인적인 관찰은 다르다.

Code Production은 점점 인간에서 Agent로 이동하고 있다. 그 결과 실제 Software-Engineering Disciplines의 상대적 가치는 올라간다.

Problem Understanding, Requirements Engineering, Architecture, Modeling, Testing, Security, Verification, Technical Decision-Making은 새로운 활동이 아니다. 우리는 오랫동안 우리 업계에서 가장 눈에 잘 보이는 활동인 코드 작성과 그것들을 혼동할 수 있었을 뿐이다.

어쩌면 우리는 다시 Software Engineering을 조금 더 배우고, 코드를 얼마나 빨리 생산할 수 있는지를 자랑하는 데는 조금 덜 집중해야 할지도 모른다. Code Production이 더 저렴해질수록 어떤 코드가 애초에 만들어져야 하는지 결정하는 능력의 상대적 가치는 올라가기 때문이다.

그래서 나에게 오늘의 Agentic Coding은 단순히 Coding을 모델에 넘기는 것이 아니다. 의사결정 공간을 의식적으로 제어하는 것이다. 필요할 때 Exploration을 허용하고, 책임이 필요한 곳에서 결정을 내리고, 이미 결정된 곳에서는 Variance를 줄인다.

그리고 구현 중 새로운 중요한 불확실성이 나타나면 다시 돌아간다. Loop는 다시 시작한다.

Software Engineering은 서로 다른 시점에 서로 다른 양의 Variance를 필요로 한다.

올바른 해법이 아직 무엇인지 모를 때 Diverge한다. 그 불확실성이 코드에 흘러들어가기 전에 Decide한다. 결정이 끝난 뒤에는 Converge한다.

Coding은 점점 더 위임 가능해진다. Software Engineering은 무엇을 만들어야 하는지, 어떤 경계가 적용되는지, 그리고 결과가 실제로 좋은지를 결정하는 discipline으로 남는다.

출처와 맥락

• GitHub Copilot – Auto Model Selection 및 Efficiency Guidance: 2026년 9월 기준 GitHub는 Task Complexity, Cost, Availability를 고려한 실제 Routing을 문서화하고 있으며, 개방도와 난이도가 다른 작업에 서로 다른 Model Capacity와 Reasoning Levels를 권장한다. 이 제품 로직은 Model Routing이 이미 실무에 쓰이고 있음을 보여주지만, 특정 조직의 도메인 및 아키텍처 결정을 자동으로 이해하지는 않는다.
• OpenAI와 Anthropic – 현재 모델 가격: 공식 가격표는 Model Classes 사이의 큰 차이를 보여준다. 위에 링크한 가격표와 모델 페이지는 2026년 9월 10일에 확인했다. GPT-5.6 Sol은 Promotion으로 표시되어 있으며, OpenAI에 따르면 최소 2026년 11월 21일까지 적용된다. 이 가격은 장기적으로 안정적인 관계를 의미하지 않는다.
• Qwen3.8-27B: 출시, Architecture, License, 언급된 Coding Benchmarks는 Qwen의 공식 자료에서 가져왔으므로 Coding Scores는 제조사 Benchmark로 분류해야 한다. Artificial Analysis는 추가 독립 측정을 제공하며 높은 성능뿐 아니라 Maximum-Reasoning Configuration의 높은 Reasoning-Token Volume도 보여준다. 이 글은 필자의 직접적인 실무 경험을 근거로 하지 않는다.