지난번에는 제가 결제 인프라를 출시할 때 사용하는 세 가지 기술 워크플로우(three-skill workflow)와, 코드가 병목 현상이 아니게 된 이후 병목 현상이 어디로 이동했는지에 대해 글을 썼습니다.

에이전트 기반 엔지니어링 (Agentic Engineering)은 바이브 코딩 (Vibe Coding)이 아니다: 분산 시스템을 출시하기 위해 제가 사용하는 세 가지 기술 루프 (Three-Skill Loop)

mtsammy40 profile

Samuel Mutemi

Samuel Mutemi

Samuel Mutemi

팔로우

8월 2일

에이전트 기반 엔지니어링 (Agentic Engineering)은 바이브 코딩 (Vibe Coding)이 아니다: 분산 시스템을 출시하기 위해 제가 사용하는 세 가지 기술 루프 (Three-Skill Loop)

#webdev #ai #programming #automation

2개의 반응1개의 댓글

읽기 시간 11분

제 워크플로우(workflow)를 논할 때 자주 받는 질문인 '왜 이 접근 방식인가?'에 대해 답변하는 것이 신중한 태도라고 생각했습니다. 현재 이 분야에는 수십 가지의 명명된 방법론들이 존재하며, 그중 몇몇은 제 회사 전체 고객 수보다 더 많은 GitHub 스타를 보유하고 있기도 합니다. 저는 특정한 이유로 특정한 조합을 선택했습니다.

따라서 이 포스트는 제가 시작할 때 가졌더라면 좋았을 조사 결과입니다. 먼저 제가 거부했던 부분들을 포함하여 이 지형을 솔직하게 훑어보겠습니다. 그런 다음 왜 제가 명세 기반 개발 (spec-driven development)과 루프 엔지니어링 (loop engineering)의 조합에 도달했는지, 그리고 각 절반이 실제로 무엇을 하고 있는지 말씀드리겠습니다.

핵심 질문

이 지형을 제가 이해할 수 있게 만들어준 관점은 다음과 같습니다.

컨텍스트 윈도우 (Context windows)는 휘발성 메모리입니다. 그것들은 채워지고, 압축되며, 맥락을 놓치기도 합니다. 모든 세션은 종료되며, 그 세션이 가졌던 이해도 함께 사라집니다. 따라서 모든 에이전트 방법론 (agentic methodology)은, 저자가 그렇게 정의하든 아니든, 단 하나의 질문에 대한 해답입니다.

에이전트 실행(agent runs) 사이에서 진실은 어디에 존재하는가?

그것이 전부입니다. 그것이 전체 분류 체계 (taxonomy)입니다. 방법론들을 지속 가능한 상태 (durable state)를 어디에 저장하는지에 따라 분류하면, 방법론 간의 차이점은 마케팅 용어가 아닌 아키텍처 (architecture)로서 드러나기 시작합니다.

이제 하나씩 살펴보겠습니다.

1. 프롬프트 네이티브 개발 (Prompt-native development, 바이브 코딩)

진실은 채팅 속에 존재합니다. 당신이 설명하면, 코드를 얻고, 눈으로 확인하고, 계속 진행합니다.

이 내용은 1부에서 다루었으므로 다시 논쟁하지는 않겠습니다. 다만 이것이 스파이크 (spikes), 일회용 스크립트, 그리고 익숙하지 않은 API를 탐색하는 데에는 여전히 적절한 도구라는 점과, 이 방식의 결정적인 특징은 세션 이후에 아무것도 살아남지 않는다는 점을 언급해 두겠습니다. 컨텍스트 (context)가 압축되면, 당신의 의도 (intent)도 함께 압축됩니다.

지도상의 위치: 기점 (origin point). 다른 모든 것들은 이 방식이 잃어버리는 것들로부터 살아남기 위한 전략입니다.

2. 컨텍스트 엔지니어링 (Context engineering, 그리고 그 사촌 격인 하네스 엔지니어링)

진실은 조립된 컨텍스트 (assembled context) 속에 존재합니다: AGENTS.md, CLAUDE.md, 저장소 컨벤션 (repo conventions), 검색 전략 (retrieval strategy), 에이전트 탐색을 위해 설계된 파일 레이아웃 (file layout) 등입니다.

이것은 에이전트가 실행 시작 시점에 읽는 내용이 실제로 에이전트를 올바른 방향으로 안내하도록 보장하는 규율 (discipline)입니다. 현재 이에 대한 실제적인 연구가 진행 중이며, 파일 네이티브 에이전트 시스템 (file-native agentic systems)을 위한 구조화된 컨텍스트 엔지니어링 (structured context engineering)에 관한 연구 결과물들이 축적되고 있습니다. 또한 모델 자체가 아닌 모델 주변의 스캐폴딩 (scaffolding)을 연구하는 "하네스 엔지니어링 (harness engineering)"이라는 새로운 연구 흐름도 등장하고 있습니다.

저는 컨텍스트 엔지니어링 (Context Engineering)이 경쟁 방법론이라고 생각하지 않습니다. 저는 그것이 하나의 기질 (Substrate)이라고 생각합니다. 이 목록에 있는 다른 모든 접근 방식은 스스로 인정하든 그렇지 않든 컨텍스트 엔지니어링을 수행하고 있습니다. 명세 (Spec)는 컨텍스트이고, 작업 목록 (Task list)은 컨텍스트이며, 테스트 실패 (Test failure) 또한 컨텍스트입니다. 이를 명시적으로 이야기하는 사람들은 단지 그 메커니즘에 대해 솔직할 뿐입니다.

나의 견해: 필요조건이지만 충분조건은 아닙니다. 완벽하게 설계된 컨텍스트라 할지라도, 여전히 무엇을 구축해야 하는지, 혹은 그것이 제대로 작동했는지 어떻게 알 수 있는지는 알려주지 않습니다.

3. 명세 기반 개발 (Spec-driven development)

진실은 모든 세션보다 더 오래 지속되는 명세 산출물 (Specification artifact) 안에 존재합니다.

이것은 단연코 가장 큰 클러스터이며, 정확하게 정의할 가치가 있습니다. 왜냐하면 현재 "SDD"는 적어도 의미론적으로 서로 다른 네 가지를 지칭하고 있기 때문입니다. 공통된 맥락은 구조화된 명세(보통 Markdown 형식이며, 때로는 기계 판독 가능함)가 사후에 작성되는 문서가 아니라, 구현(Implementation), 테스트, 그리고 문서(Docs)가 파생되는 권위 있는 소스(Authoritative source)가 된다는 점입니다.

변형 방식들은 주로 얼마나 많은 격식 (Ceremony)을 요구하는지, 그리고 명세를 얼마나 문자 그대로의 소스 코드 (Literal source code)에 가깝게 밀어붙이는지에 따라 달라집니다.

린(Lean)하고 헌법 중심적인, GitHub Spec Kit

명세(Specify), 계획(Plan), 작업(Tasks), 구현(Implement)의 4단계 워크플로우를 가집니다. 모든 명세는 지속적인 규칙, 스택, 컨벤션, 타협 불가능한 사항들을 인코딩하는 프로젝트 전반의 "헌법 (Constitution)"을 상속받습니다. GitHub의 배포 덕분에 이 카테고리에서 가장 많은 스타를 받은 옵션이 되었습니다.

장점: 최소한의 격식, 도구에 구애받지 않음(Tool-agnostic), 헌법이라는 아이디어가 진정으로 탁월함. 단점: 그린필드(Greenfield, 신규 프로젝트)와 적절한 규모의 변경 사항에 최적화되어 있음; 작은 편집 사항들은 단계별 구조와 충돌함.

경량화되고 브라운필드 우선인, OpenSpec

완전히 새로운 작업보다는 _수정 (Modifications)_을 위해 특화되어 설계되었습니다. ADDED, MODIFIED, REMOVED와 같은 델타 마커 (Delta markers)를 사용하여, 변경 제안이 세상을 다시 설명하는 대신 무엇이 변하는지를 기술합니다.

만약 당신의 현실이 모든 작업이 수정 사항(amendment)인 성숙한 코드베이스라면, 이것이 목록에서 가장 정직한 모델입니다. 또한 실행 비용도 가장 저렴합니다.

완전한 애자일 시뮬레이션, BMAD-METHOD

최대주의적(maximalist) 옵션입니다. Analyst, PM, Architect, Scrum Master, Developer, QA 등 12개 이상의 특화된 에이전트 페르소나(agent personas)가 전체 소프트웨어 개발 생명주기(SDLC)를 반영하는 파이프라인을 통해 산출물(artifacts)을 전달합니다.

BMAD에 대해 공정하게 평가하자면, 이 방식은 진정으로 인상적이며 이미 PRD(제품 요구 사항 문서)와 스프린트 스토리(sprint stories) 방식으로 사고하는 팀들의 실제 문제를 해결해 줍니다. 하지만 제가 가장 설득력 있다고 느끼는 비판은 구조적인 측면입니다. 페르소나 파이프라인의 품질은 가장 취약한 인수인계(handoff) 단계의 품질과 같습니다. Architect가 PM이 문서화하지 않은 가정을 세우면, Scrum Master는 이를 충실히 스토리로 전파하고, Developer는 완전한 확신을 가지고 이를 구현합니다. 그리고 당신은 이를 QA 단계나 운영(production) 환경에서 발견하게 됩니다. 페르소나가 많아질수록 인수인계 접점이 늘어나며, 인수인계 실패는 매우 까다로운 디버깅 대상이 됩니다. 왜냐하면 개별 에이전트들은 모두 합리적으로 행동했기 때문입니다.

비용 또한 무시할 수 없습니다. 한 컨설팅 업체는 보고하기를, BMAD는 워크플로당 평균 수만 개의 토큰을 소모하며, 개발자 한 명당 월간 프런티어 모델(frontier-model) 비용이 수백 달러에서 수천 달러 사이로 발생한다고 합니다. 사용 환경에 따라 차이가 매우 크겠지만, 이는 무시할 수 있는 수준(rounding error)이 아닙니다.

환경 네이티브(Environment-native), Kiro, 그리고 플랫폼 계층

AWS Kiro는 스펙 워크플로(spec workflow)를 위에 얹은 것이 아니라 처음부터 내장하여 구축한 완전한 IDE입니다. 공유된 살아있는 스펙(living spec)을 중심으로 에이전트들을 조율하는 다양한 "에이전트 기반 개발 환경(agentic development environment)" 플랫폼들도 마찬가지입니다.

여기에는 명확한 트레이드오프(trade-off)가 존재합니다. 누군가의 환경으로 이동하는 대신 더 긴밀한 통합을 얻는 것입니다. 팀의 툴링(tooling)이 이미 확정된 상태라면 이는 실제 비용(부담)이 되지만, 그렇지 않다면 실제적인 이점이 됩니다.

소스로서의 스펙(Spec-as-source), Tessl 및 친구들

급진적인 입장: 스펙(spec)이 주요(primary) 산출물이며, 코드는 빌드 결과물이라는 것입니다. 스펙을 수정하고, 다시 생성하십시오. 사람들이 흔히 드는 비유는 Terraform이나 SQL 쿼리 플래너(query planner)입니다. 당신은 의도(intent)를 작성하고, 시스템이 계획(plan)을 생성합니다.

저는 이 방향이 방향성 측면에서는 옳지만, 실무적으로는 시기상조라고 생각하며, 그 이유는 나중에 다시 다루겠습니다.

4. 루프 기반 자율성(Loop-based autonomy), Ralph 기법

진실은 디스크에 존재합니다: 작업 목록(task list), 작업별 스펙(specs), 로그(logs), 그리고 git 히스토리(history) 말입니다.

Geoffrey Huntley는 2025년 중반, Ralph Wiggum의 이름을 따서 이 기법의 이름을 명명했습니다. 이는 단일 반복(iteration)은 무언가 약간 잘못될 수 있는 평범한 에이전트 실행일 뿐이며, 루프(loop)는 하나의 뛰어난 프롬프트(prompt)가 아니라 끈기와 안정적인 진실의 원천(source of truth)을 통해 승리한다는 이론에 근거합니다. 최소한의 형태는 거의 모욕적일 정도로 단순합니다. 할 일 목록(todo list)이 소진될 때까지 비대화형(non-interactive) 에이전트를 다시 호출하는 bash while 루프입니다.

이 기법을 작동하게 만드는 통찰은 사람들이 놓치는 부분입니다: 각 반복은 새로운 컨텍스트(context)를 부여받습니다. 단일한 긴 세션은 피로가 누적되고, 컨텍스트 윈도우(window)가 가득 차며, 압축(compaction) 과정에서 세부 사항이 누락되어 모델이 맥락을 놓치게 됩니다. 디스크의 파일로부터 다시 방향을 잡는 일련의 짧은 세션들은 예리함을 유지합니다. 진행 상황은 채팅창에 머무는 것이 아니라, 커밋된 코드, 작업 파일, 그리고 다음 반복이 부팅 시 읽어들이는 로그에 존재합니다.

현재 가시성을 위한 TUI, verifyCompletion 함수가 통과할 때까지 루프를 도는 Vercel Labs 래퍼(wrapper), 그리고 테스트 게이트가 있는 SDLC(Software Development Life Cycle) 내부에서 의존성 순서로 정렬된 백로그(backlog)에 걸쳐 Ralph를 실행하는 엔터프라이즈 사례 등 많은 구현체가 존재합니다.

함정, 그리고 이는 매우 큰 함정인데: 정식 Ralph는 --yolo 모드로 실행됩니다. 모든 권한을 가지며, 확인 절차가 없습니다. 이는 실제 샌드박싱(sandboxing)을 필수적으로 요구하며, 순수한 형태의 이 기법은 잘못된 반복이 자금을 이동시키거나 테이블(table)을 삭제할 수 있는 환경에서는 사용할 수 없음을 의미합니다.

하지만 Ralph가 실제로 무엇인지 주목하십시오. 이것은 구조화된 개발의 대체제가 아니라, 당신이 이미 가지고 있는 구조를 위한 _실행 엔진(execution engine)_입니다. 자체 문서에서도 이를 명시하고 있습니다. 이 차이가 매우 중요하다는 사실이 밝혀졌습니다.

5. TDD 거버넌스 (TDD governance)

진실은 테스트 스위트 (test suite) 안에 존재합니다. 테스트가 먼저 작성되며 실행 가능한 명세 (executable specifications) 역할을 수행하므로, 생성이 시작되기 전에 정확성이 정의됩니다.

이 방식은 학계의 진지한 관심을 받고 있습니다. 멀티 에이전트 (multi-agent) 코드 생성에 대한 TDD 거버넌스에 관한 EASE 2026에서 발표된 연구, 그리고 테스트 주도 사이클을 중심으로 에이전트 워크플로 (agentic workflows)를 구축하는 TDFlow와 같은 시스템들이 그 예입니다. 이를 뒷받침하는 논거는 분산 시스템 (distributed-systems) 전문가라면 누구나 공감할 내용입니다. LLM은 비결정론적 (non-deterministic)이며, 동일한 프롬프트 (prompt)가 서로 다른 출력을 생성하고, 멀티 에이전트 환경에서는 작은 논리적 오류가 전체 워크플로로 전파됩니다. 자동화된 가드레일 (guardrails)은 선택 사항이 아닙니다.

또한 연구에 따르면, 테스트 케이스 (test cases)는 실행 가능한 명세로서 기능함으로써 모호성을 줄여줍니다. 이는 SDD가 산문 명세 (prose specs)에 대해 주장하는 바와 동일하며, 서로 다른 방향에서 도달한 결론입니다.

약점: 테스트는 동작 (behavior)은 훌륭하게 명시하지만, 아키텍처 (architecture)는 형편없이 명시합니다. 테스트 스위트는 특정 모듈이 다른 모듈을 알아서는 안 된다거나, 이 큐 (queue)가 최소 한 번 전달 (at-least-once) 방식이라거나, 혹은 특정 제약 조건이 왜 존재하는지에 대해서는 알려줄 수 없습니다. 테스트는 검증 계층 (verification layer)이지, 의도 계층 (intent layer)이 아닙니다.

6. 멀티 에이전트 오케스트레이션 (Multi-agent orchestration)

진실은 오케스트레이터 (orchestrator)의 태스크 그래프 (task graph)와 공유 메모리 (shared memory)에 존재합니다.

Anthropic의 2026 에이전트 코딩 트렌드 연구는 그 형태를 다음과 같이 설명합니다. 단일 에이전트 워크플로가 하나의 컨텍스트 윈도우 (context window)를 통해 순차적으로 처리하는 것과 달리, 오케스트레이터가 전용 컨텍스트 (dedicated context)를 가진 전문화된 에이전트들을 병렬로 조정하고, 그 결과들을 통합된 출력으로 합성하는 방식입니다.

Addy Osmani의 계층화 (tiering)는 제가 발견한 가장 유용한 실무적 프레임워크입니다:

1. Conductor tier (지휘자 계층), 하나의 세션 내에 있는 서브 에이전트(subagents). 추가적인 도구는 필요 없습니다. 당신의 컨텍스트 윈도우(context window)가 한계치입니다.
2. Local orchestration tier (로컬 오케스트레이션 계층), 격리된 git 워크트리(worktrees) 내의 여러 에이전트, 대시보드 및 머지(merge) 제어 기능 포함. 당신이 잘 알고 있는 코드베이스에서 약 3~10개의 에이전트를 운용할 때 가장 효과적입니다.
3. Cloud async tier (클라우드 비동기 계층), 작업을 할당하고, 노트북을 닫은 뒤, 나중에 풀 리퀘스트(pull request)로 돌아오면 됩니다.

정직한 반론을 덧붙이자면: 프로덕션 규모의 오케스트레이션(orchestration)은 수 분기(multi-quarter)가 소요되는 엔지니어링 작업이며, 관측성(observability) 도구들은 비결정론적 흐름(non-deterministic flows)에서 즉각적으로 작동하지 않습니다. 또한, Thoughtworks의 레이더는 AI 지원 개발이 확장됨에 따라 발생하는 _인지 부채(cognitive debt)_의 축적을 경고해 왔는데, 이는 제가 첫 번째 파트에서 다루었던 리뷰 병목 현상의 조직적 버전이라 할 수 있습니다.