에이전틱 코딩(Agentic coding)은 소프트웨어 개발자의 의미를 변화시키고 있습니다.

전통적으로 코드를 작성하는 일은 개발자 일과의 상당 부분을 차지했습니다. AI 코드 에이전트(AI code agents)가 점점 더 유능해짐에 따라, 개발자의 역할은 모든 줄을 직접 작성하는 것에서 AI가 생성한 작업물을 가이드하고, 감독하며, 검증하는 것으로 변화하고 있습니다.

이제 전형적인 워크플로우는 다음과 같은 모습입니다:

1. 비즈니스 요구사항과 아키텍처 결정 사항을 정확하게 포착하는 고품질의 지식 베이스(knowledge base)를 유지합니다.
2. 해당 지식 베이스로부터 기술 사양(technical specifications)을 생성할 적절한 LLM을 선택합니다.
3. 코드가 작성되기 전에 생성된 사양을 검토하고 승인합니다.
4. 코딩 모델(coding model)을 사용하여 승인된 사양을 구현합니다.
5. AI가 생성한 코드, 추론(reasoning), 주석을 검토하고 필요한 경우 개선합니다.
6. 최종 게이트키퍼(gatekeeper) 역할을 수행하며, 모든 변경 사항이 정확성, 보안, 유지보수성 및 성능 측면에서 프로덕션 표준을 충족하는지 확인합니다.

에이전틱 코딩은 개발자를 대체하는 것이 아니라, 우리의 노력을 모든 줄을 작성하는 것에서 검토, 오케스트레이션(orchestrating), 그리고 검증으로 전환시킵니다. 강력한 엔지니어링 판단력은 가치가 낮아지는 것이 아니라 오히려 더 중요해지고 있습니다.

저는 **감독형 보안 에이전틱 코딩 (Supervised Secure Agentic Coding, SSAC)**이라는 이름으로 .NET 백엔드 개발을 위한 이 워크플로우를 실험해 왔습니다.

순수 에이전틱 코딩의 문제점

코드베이스에 AI 에이전트를 풀어놓는 것은 종종 해커톤을 진행하는 것과 비슷하게 느껴집니다. 초기에는 빠른 성과가 나타나지만, 품질이 일관되지 않으며, 무언가가 프로덕션에 준비되기 전에 많은 정리 작업이 필요합니다.

실패 모드(failure modes)는 예측 가능합니다:

• 요청 불일치 (Request misalignment) — 코드가 컴파일되고 실행은 되지만 실제 비즈니스 요구사항과 일치하지 않습니다.
• 과도하게 복잡한 생성 (Over-complex generation) — 불필요한 추상화, 추가적인 의존성(dependencies), 팀이 요청하지 않은 범위의 작업이 포함됩니다.
• 급격한 AI 기술 부채 (Rapid AI technical debt) — 일관되지 않은 패턴과 지름길(shortcuts)이 인간 팀이 허용하는 것보다 더 빠르게 축적됩니다.
• 과잉 확신 및 환각 (Overconfidence and hallucinations) — 자신감 있게 들리는 출력물이 잘못된 API, 발명된 타입(types), 또는 깨진 가정을 숨기고 있습니다.

해결책은 에이전트(agents)를 포기하는 것이 아닙니다. 대신 그들을 **유능하지만 주니어급 기여자 (capable but junior contributor)**처럼 대하는 것입니다. 즉, 명확한 경계(boundaries)를 설정하고, 적절한 도구(tools)를 제공하며, 무엇인가가 배포되기 전에 검토 단계(review gate)를 거치게 하는 것입니다.

SSAC의 세 가지 기둥

1. 아키텍처 제약 사항으로서의 가드레일 (Guardrails as Architectural Constraints)

가드레일(guardrails)이 없다면, 에이전트는 데이터 모델을 임의로 만들어내거나, 기존 패턴을 우회하거나, 사용 중인 기술 스택(stack)에 맞지 않는 라이브러리를 가져올 수 있습니다.

에이전트에게 줄 수 있는 제약 사항의 예시:

이 엔드포인트(endpoint)를 구현할 수 있지만, 반드시 기존의 리포지토리 패턴(repository patterns)을 따라야 하며, 승인 없이 데이터베이스 스키마(database schema)를 변경할 수 없고, 모든 공개 API(public API)에는 일관된 에러 처리(error handling)가 반드시 포함되어야 합니다.

에이전트는 여전히 빠르게 움직이지만, 단지 당신이 정의한 샌드박스(sandbox) 안에서 움직일 뿐입니다.

2. 전문화된 도구로서의 기술 (Skills as Specialized Tooling)

범용 모델(general-purpose model)은 프로젝트가 어떻게 작동하는지 추측해야만 합니다. **기술 (Skills)**은 이러한 추측을 반복 가능한 능력으로 바꿔줍니다. 테스트 실행, 스키마(schema) 쿼리, 내부 문서 읽기, 코드베이스에서 선례 검색, 또는 팀이 이미 사용 중인 사양(spec) 형식 따르기 등이 이에 해당합니다.

잘 선택된 기술은 에이전트가 추측하는 단계에서 벗어나, 중간 수준의 개발자(mid-level developer)가 첫날 바로 사용할 법한 도구들을 사용하여 작동하도록 전환해 줍니다.

3. 완료의 정의로서의 승인 (Approvals as the Definition of Done)

감독(Supervision)은 선택 사항이 아닙니다. 생성된 코드는 사람이 작성한 코드와 동일한 기준을 통과해야 합니다.

• 작업이 시작되기 전에 수락 기준(Acceptance criteria)이 명시되어야 합니다.
• 검토(review) 전에 자동화된 체크(테스트, 린트(lint), 빌드(build))가 실행되어야 합니다.
• 사람이 풀 리퀘스트(pull request)에서 결과를 승인하거나 거부합니다.

만약 출력물이 보안, 성능, 또는 비즈니스 로직 측면에서 실패한다면, 다른 코드 리뷰와 동일한 루프를 통해 피드백과 함께 에이전트에게 다시 전달됩니다.

두 가지 루프

SSAC은 분리된 두 가지 반복 사이클(iterative cycles)을 기반으로 작동합니다:

SSAC Tow Loops

• 플래닝 루프 (The Planning Loop) (요구사항 → 명세서): 단 한 줄의 코드가 작성되기 전에, 상위 수준의 비즈니스 목표를 엄격하고 결정론적인(deterministic) 마크다운 명세서로 정제합니다.
• 실행 루프 (The Execution Loop) (명세서 → 프로덕션 코드): 에이전트가 로컬에서 코드를 작성하며, 인간의 승인 단계(human approval gate)에 도달할 때까지 로컬 테스트 및 린트(lint)를 통해 반복 수행합니다.

설계 단계부터 보안 확보 (Secure by Design)

많은 기업 환경에서는 소스 코드, 자격 증명(credentials) 또는 내부 스키마(schemas)가 퍼블릭 클라우드 LLM으로 유출되는 것을 허용할 수 없습니다. SSAC는 로컬 우선 (local-first) 접근 방식을 통해 이 문제를 직접적으로 해결합니다.

• **오픈 웨이트 모델 (Open-weight models)**을 vLLM, llama.cpp 또는 Ollama를 통해 실행하여 모든 프로젝트 컨텍스트를 네트워크 경계 내에 유지합니다.
• **GGUF 양자화 (GGUF quantization)**를 사용하면 소비자급 워크스테이션 GPU(16–24 GB VRAM)에서 성능이 뛰어난 모델을 실행할 수 있습니다.
• 전문가 혼합 (Mixture-of-Experts, MoE) 모델은 연산량을 RAM과 VRAM으로 분산하여, 기업용 하드웨어 예산 없이도 더 깊은 추론 능력을 구현합니다.

비용 라우팅(cost routing) 전략은 간단합니다. 일상적인 작업(린팅, 기본적인 리팩토링)에는 오픈 소스 모델을 사용하고, 복잡하고 위험도가 높은 아키텍처 결정에는 프리미엄 클라우드 모델을 엄격하게 예약하여 사용합니다.

오픈 소스 스택 (The Open-Source Stack)

이 프레임워크는 **에이전트 불가지론적(agent-agnostic)이며 LLM 불가지론적(LLM-agnostic)**입니다. 에이전트의 기술과 가드레일(guardrails)만 적절히 구성되어 있다면 에이전트를 자유롭게 교체할 수 있습니다. 데모는 OpenCode를 기본값으로 사용하지만, 워크플로우가 이에 종속되지는 않습니다.

참조 설정에서 사용된 주요 도구는 다음과 같습니다:

• OpenSpec — 명세서 기반(spec-driven) 에이전트 워크플로우
• GitNexus — 코드베이스에 대한 로컬 시맨틱 검색 (semantic search)
• Obsidian MCP — 내부 문서를 에이전트 컨텍스트로 가져오기
• Karpathy LLM Wiki — 위키 스타일의 지식 베이스 인제스션 (ingestion)

이것이 개발자에게 의미하는 바

개발자의 역할은 사라지는 것이 아니라 진화합니다. 당신은 다음과 같은 존재가 됩니다:

• 툴스미스 (toolsmith): 에이전트를 제약하고 활성화하는 가드레일 (guardrails)과 기술을 유지 관리합니다.
• 명세 작성자 (specification writer): 에이전트가 올바르게 구현할 수 있도록 비즈니스 요구사항을 충분히 명확하게 포착합니다.
• 게이트키퍼 (gatekeeper): AI가 생성한 변경 사항을 검토하고, 추론하며, 승인합니다 — 이는 사람이 작성한 코드와 동일한 기준을 따릅니다.

이 모델에서 번창하는 엔지니어는 결과물이 겉보기에 올바르더라도, 그것이 틀렸다는 것을 알 수 있는 충분히 강력한 직관을 가진 사람들입니다.

이것이 .NET 백엔드 개발에서 실제로 어떻게 작동하는지 관심이 있다면, 다음 리포지토리를 확인해 보세요:

👉 github.com/robert-li/SupervisedSecureAgenticCoding

이슈 (Issues), 가드레일 (guardrail) 템플릿, 그리고 .NET 중심의 기술들은 환영하는 기여 사항입니다.