자율 AI 코딩 에이전트 파이프라인 구축: TDD 증거, 가드레일 및 다중 에이전트 협업

원문 출처: tamiz.pro.

현재 AI 지원 개발의 상태는 주로 자동 완성(autocomplete)에 의해 정의됩니다. GitHub Copilot이나 Cursor 같은 도구들은 우리가 코드를 작성하는 속도를 혁신적으로 변화시켰지만, 이들은 여전히 수동적인 보조 역할에 머물러 있습니다. 이들은 제안할 뿐이며, 우리는 결정합니다. 이들은 완성할 뿐이며, 우리는 검증합니다. 그러나 소프트웨어 엔지니어링의 다음 영역은 단순히 더 빠른 타이핑이 아니라 자율 에이전시(autonomous agency)입니다. 우리는 "코드를 작성하는 것을 도와주는 AI"에서 "기능을 검증하고 배포하는 AI"로 이동하고 있습니다.

AI 에이전트가 단순히 토큰을 생성하는 것이 아니라, 실제로 기능을 처음부터 끝까지 엔지니어링할 수 있는 파이프라인을 구축하려면 아키텍처의 근본적인 변화가 필요합니다. 이는 신뢰 기반 통합("이게 작동하길 바라야 해")에서 증거 기반 통합("작동한다는 것을 증명하는 테스트가 여기 있어")으로 이동해야 함을 의미합니다. 본 심층 분석에서는 이러한 시스템을 구축하는 데 필요한 아키텍처 패턴, 즉 검증 엔진으로서의 테스트 주도 개발(Test-Driven Development, TDD), 환각(hallucination) 유발 버그를 방지하기 위한 LLM 기반 리뷰 가드레일(guardrails), 그리고 복잡한 시스템 설계를 처리하기 위한 다중 에이전트 협업에 대해 탐구합니다.

1. "느낌으로 코딩하기(Vibe Coding)"의 한계점

"느낌으로 코딩하기"—엄격한 검증 없이 직관과 빠른 AI 생성을 기반으로 소프트웨어를 작성하는 행위—는 프로토타입에는 잘 작동합니다. 하지만 실제 운영 환경에서는 치명적으로 실패합니다. 핵심 문제는 대규모 언어 모델(Large Language Models, LLMs)이 결정론적(deterministic)이지 않고 확률적(probabilistic)이라는 점입니다. 이들은 상태를 이해하지 못하며, 단지 다음에 나올 가능성이 높은 토큰을 예측할 뿐입니다. 단순히 UserService와 UserRepository를 작성하는 에이전트는 진공 상태에서 작동하고 있는 것과 같습니다. 피드백 루프가 없습니다.

운영 등급(production-grade)의 파이프라인을 구축하려면, 우리는 이 루프를 닫아야 합니다. 에이전트는 코드 생성을 마친 후 멈춰서는 안 됩니다. 증거가 반박할 수 없을 때만 멈춰야 합니다. 이 증거는 세 가지 출처에서 나옵니다:

행동 증거 (Behavioral Evidence): 통과하는 단위 테스트(Unit tests) 및 통합 테스트(Integration tests).
정적 증거 (Static Evidence): 통과하는 린터(Linters), 타입 체커(Type checkers), 보안 스캐너(Security scanners).
논리 증거 (Logical Evidence): 요구사항에 논리가 일치하는지 검증하는 리뷰 에이전트.

2. 에이전트를 위한 상태 기계로서의 TDD

전통적으로 테스트 주도 개발(Test-Driven Development, TDD)은 인간의 규율입니다. 이는 구현 전에 테스트를 작성하도록 강제하여 코드가 실제로 테스트 가능하게 만듭니다. AI 에이전트에게 TDD는 규율이 아니라 제어 흐름 메커니즘입니다.

자율 파이프라인에서 '테스트'는 수용 기준(acceptance criterion)입니다. 에이전트가 요구사항을 명확히 설명하는 실패 테스트를 작성할 수 없다면, 그 에이전트는 요구사항을 이해하지 못한 것입니다.

코드 속의 TDD 루프

CodeAgent 클래스를 상상해 보세요. 이 클래스는 단일한 generate 메서드를 가지고 있지 않습니다. 대신 refactor, implement, 그리고 verify라는 라이프사이클을 가집니다.

class FeatureAgent:
    def __init__(self, llm: BaseLLM, file_system: LocalFS, test_runner: ShellRunner):
        self.llm = llm
...

여기서 핵심 구성 요소는 test_runner입니다. 에이전트는 코드가 작동한다고 추측하는 것이 아닙니다. 실제로 실행하고 있습니다. 이는 아키텍처를 '블랙 박스'(입력 프롬프트 -> 출력 코드)에서 '강화 루프'(입력 프롬프트 -> 출력 코드 -> 환경 피드백 -> 오류 수정)로 전환시킵니다.

3. 리뷰 가드레일: LLM 비평가 (Critic)

테스트가 통과하더라도 코드가 나쁠 수 있습니다. 사용 중단된 API를 사용하거나, 보안 모범 사례를 무시하거나, 아키텍처 패턴을 위반할 수 있습니다(예: 컨트롤러가 데이터베이스와 직접 통신하는 경우). 바로 여기에 '가드레일' 에이전트가 등장합니다.

이 파이프라인에서는 LLM을 코더가 아닌 리뷰어로 취급합니다. 비평에 초점을 맞춘 별도의 프롬프트 컨텍스트를 사용합니다. 이는 종종 'LLM-as-a-Judge' 패턴이라고 불립니다.

비평가 아키텍처 설계

비평가(Critic) 에이전트는 상태 비저장(stateless)이며 빨라야 합니다. TDD 에이전트가 생성한 diff를 읽고 구조화된 JSON 판결을 출력해야 합니다.

By forcing the Critic가 구조화된 데이터를 출력하도록 강제함으로써, 우리는 파이프라인을 결정론적(deterministic)으로 만듭니다. 그러면 메인 오케스트레이터는 이 JSON을 구문 분석할 수 있습니다. 만약 severity가 "high"라면, 파이프라인은 중단되고 제안을 TDD 에이전트에게 다시 피드백합니다. 이는 에이전트가 Critic의 프롬프트에 정의된 규칙에 의해 묶이는, 일종의 "Constitutional AI" 제약을 만듭니다.

4. 다중 에이전트 조정(Multi-Agent Coordination): 오케스트레이터

단일 에이전트가 모놀리식 프롬프트 컨텍스트 내에서 작업할 경우, 빠르게 컨텍스트 창의 한계에 부딪히고 혼란스러워질 것입니다. 복잡한 기능(예: "Stripe 결제 시스템 추가")은 관심사 분리(separation of concerns)를 요구합니다.

우리는 슈퍼바이저-워커(Supervisor-Worker) 아키텍처로 전환합니다.

아키텍트 에이전트 (The Architect Agent): 높은 수준의 요구사항을 읽고 작업 목록으로 분해합니다(예: "1. Stripe 클라이언트 래퍼 생성", "2. 웹훅 핸들러 추가", "3. 데이터베이스 스키마 업데이트").
워커들 (The Workers): 특정 작업을 처리하는 전문 에이전트(DB Agent, API Agent, Test Agent)입니다.
오케스트레이터 (The Orchestrator): 작업의 DAG(Directed Acyclic Graph, 방향성 비순환 그래프)를 관리하는 결정론적인 Python/TypeScript 스크립트입니다. 이는 제어 흐름에 LLM을 사용하지 않습니다. 오직 작업 항목에 대해서만 LLM을 사용합니다.

결정론적 오케스트레이션이 중요한 이유

"LLM에게 다음에 어떤 에이전트를 호출할지 결정하게 하자."라고 생각할 수도 있습니다. 이것은 무한 루프와 예측 불가능한 비용의 지름길입니다. LLM은 지휘자가 되어서는 안 됩니다. 플레이어가 되어야 합니다. 지휘자는 당신의 코드여야 합니다.

async function runPipeline() {
    // 1. Plan
    const plan = await architectAgent.plan(featureDescription);
...

5. 파이프라인 구현: 구체적인 예시

실제 시나리오에서 이것이 어떻게 작동하는지 살펴보겠습니다. Node.js/Express 앱에 "비밀번호 찾기" 엔드포인트를 추가하는 상황입니다.

단계 1: 아키텍트

프롬프트: "비밀번호 재설정 토큰을 위한 시스템을 설계하세요. 만료 시간(24시간), 보안(SHA-256 해싱), 데이터베이스 스키마 변경 사항을 고려하세요."

출력 (Architect Agent):

{
  "tasks": [
    { "id": "db", "desc": "Add 'reset_token_hash' and 'reset_expires_at' to users table" }
...

단계 2: TDD 워커 (데이터베이스)

프롬프트: "데이터베이스 마이그레이션이 새 컬럼을 추가하는지 확인하는 테스트를 작성하세요. 그런 다음 마이그레이션 파일을 작성하세요."

워커는 tests/migration.test.ts를 작성합니다:

test('db schema update', async () => {
  const schema = await getSchema();
  expect(schema.tables.users.columns).toContain('reset_token_hash');
...

테스트를 실행합니다. 실패합니다 (Red). 마이그레이션을 작성합니다. 테스트를 다시 실행합니다. 통과합니다 (Green).

단계 3: TDD 워커 (로직)

프롬프트: "tests/token.test.ts의 테스트를 기반으로 토큰 생성 로직을 구현하세요."

워커는 SHA-256을 사용하여 토큰이 저장되기 전에 해시되도록 보장하며 로직을 생성합니다.

단계 4: 크리틱 (The Critic)

프롬프트: "최근 두 커밋의 diff를 검토하세요. 다음 사항을 확인하세요: 1. 토큰이 평문(plain text)으로 저장되었는가? 2. 만료 시간이 쿼리에서 존중되는가? 3. SQL 인젝션이 가능한가?"

크리틱은 코드를 분석합니다. API 엔드포인트의 SELECT 쿼리가 만료 시간 확인을 위해 문자열 보간(string interpolation)을 사용하고 있음을 발견합니다. 이를 'high' 심각도의 문제로 플래그 지정합니다.

단계 5: 오케스트레이터 (The Orchestrator)

오케스트레이터는 'high' 심각도 플래그를 확인합니다. 크리틱의 제안인 "매개변수화된 쿼리(parameterized queries)를 사용하세요"를 받아들입니다. 이를 API 워커에게 전달합니다. 워커는 코드를 업데이트하여 ? 플레이스홀더를 사용하도록 합니다. 크리틱이 재검토하고 통과합니다. 파이프라인은 변경 사항을 커밋합니다.

6. 엣지 케이스 및 실패 모드 처리

이러한 파이프라인을 구축하는 것은 플러그 앤 플레이(plug-and-play)가 아닙니다. 자동화를 망가뜨릴 특정 실패 모드가 있습니다.

컨텍스트 로트 (Context Rot)

에이전트가 더 많은 변경 사항을 만들수록, 컨텍스트 창은 이전 코드로 채워집니다. 에이전트는 프롬프트 초반의 요구사항을 "잊기" 시작합니다.

솔루션: 슬라이딩 윈도우 메모리(Sliding Window Memory). 대화 기록을 '현재 상태(Current State)' 객체로 요약합니다. 원본 기록 대신 이 상태를 다음 프롬프트에 전달합니다.

'환각된 의존성(Hallucinated Dependency)' 문제

에이전트가 import { RedisClient } from 'redis'를 작성했지만, 프로젝트는 ioredis를 사용하고 있습니다.

솔루션: TDD 단계에는 npm install 또는 pip install 확인 절차가 포함되어야 하며, 더 나아가 Critic은 package.json / requirements.txt에 접근하여 임포트를 실제 의존성과 검증해야 합니다.

무한 루프(Infinite Loops)

에이전트가 테스트를 실패하고, 이를 수정하려 시도하지만 다시 실패하며 순환 고리에 빠집니다.

솔루션: 회로 차단기(Circuit Breakers). 재시도 횟수를 제한합니다 (예: 3회 시도). 만약 3번 실패하면 중지하고 HumanInterventionRequired 예외를 발생시킵니다.

7. 보안 고려 사항(Security Considerations)

AI 에이전트에게 코드베이스에 대한 쓰기 접근 권한과 실행 특권을 부여하는 것은 무서운 일입니다.

샌드박싱(Sandboxing): 항상 임시 Docker 컨테이너 내에서 에이전트를 실행해야 합니다. 어떤 에이전트도 개발자의 로컬 환경을 직접 건드려서는 안 됩니다.
최소 권한 원칙(Least Privilege): 에이전트는 코드베이스에 대한 읽기 접근 권한과 특정 브랜치 또는 임시 복사본에 대한 쓰기 접근 권한만 가져야 합니다. main에 푸시할 수 있는 권한은 없어야 합니다. 최종 커밋은 파이프라인에서 생성하고, 사람이 검토하며, 수동으로 병합(또는 엄격한 CI 체크를 통해)되어야 합니다.
프롬프트 주입(Prompt Injection): 에이전트가 외부 데이터(예: GitHub Issues 또는 StackOverflow 답변)를 읽어 LLM에 공급하는 경우, 프롬프트 주입에 취약합니다. 모든 외부 입력은 LLM 컨텍스트에 도달하기 전에 정제해야 합니다.

8. 미래: 에이전트 기반 SWE (Agentic SWE)

우리는 현재 이 분야의 초기 단계에 있습니다. '에이전트 기반 소프트웨어 엔지니어링(Agentic SWE)' 파이프라인은 완전 자율 개발로 가는 다리입니다. 하지만 병목 현상은 LLM의 지능 자체가 아니라, LLM의 신뢰성입니다.

LLM을 TDD 루프에 감싸는 것은 본질적으로 컴파일러와 테스트 러너를 우리의 가드레일로 사용하는 것입니다. LLM이 '두뇌'라면, 테스트 러너가 '안전망'인 셈입니다.

지금 당장은 모든 것을 할 수 있는 범용 에이전트를 만들려고 시도하지 마세요. 한 가지 일을 잘하는 전문화된 에이전트들을 만들고, 이를 결정론적 오케스트레이터(deterministic orchestrator)와 협업시키는 것이 좋습니다. 이것이야말로 AI가 단순히 코드를 작성할 뿐만 아니라, 그것을 _검증_하는 소프트웨어로 나아가는 길입니다.

자주 묻는 질문 (Frequently Asked Questions)

이 에이전트들에 어느 정도의 컨텍스트 창(context window)이 필요한가요?

TDD 워커(TDD Worker)의 경우, 요구사항, 현재 파일, 오류 출력을 담기 위해 16k-32k 컨텍스트 창이면 보통 충분합니다. 크리틱(Critic)의 경우, 전체 diff와 프로젝트 스타일 가이드 전체를 담을 수 있는 공간이 필요합니다. 복잡한 검토에는 32k-128k가 권장됩니다.

크리틱에 코더와 다른 LLM을 사용해야 하나요?

네. 다른 모델(또는 온도를 0.0으로 설정하고 매우 구체적인 '심사위원' 페르소나를 가진 동일한 모델)을 사용하면 에이전트가 자신의 작업을 스스로 승인하는 것('rubber-stamping')을 방지할 수 있습니다. 두 번째 의견은 확증 편향(confirmation bias)보다 항상 더 가치가 높습니다.

여러 파일에 걸친 변경 사항은 어떻게 처리하나요?

오케스트레이터가 작업을 분해해야 합니다. TDD 에이전트에게 전체 백엔드를 다시 작성하도록 요청해서는 안 됩니다. 대신 'User 모델을 소프트 삭제(soft deletes)를 지원하도록 업데이트하고' 그 다음 'UserService를 수정하여 소프트 삭제를 준수하도록 업데이트하라'와 같이 지시해야 합니다. 이렇게 하면 컨텍스트가 작게 유지되고 diff 검토가 가능해집니다.

AI 엔지니어링 및 개발자 도구에 대한 더 많은 통찰력을 얻으려면 Tamiz's Insights를 확인하세요.

다중 에이전트 협업 패턴 (Multi-Agent Coordination Patterns)

단일 에이전트가 집중적인 작업을 처리할 수는 있지만, 실제 코드베이스는 전문화를 요구합니다. 가장 효과적인 자율 파이프라인은 서로 다른 관심사(concerns)를 가진 개별 에이전트들이 소유하는 **다중 에이전트 아키텍처(multi-agent architectures)**를 사용합니다.

역할 기반 에이전트 메쉬 (The Role-Based Agent Mesh)

┌─────────────────────────────────────────────────────────┐
│ 오케스트레이터 에이전트 (Orchestrator Agent) │
│ (작업 분해, 상태 관리, 충돌 해결 등) │
...

각 에이전트는 전체 코드베이스가 아닌 도메인별 컨텍스트를 포함한 **제한된 시스템 프롬프트(narrow system prompt)**를 받습니다. 오케스트레이터는 의존성 DAG(Directed Acyclic Graph, 방향성 비순환 그래프)를 관리합니다:

# orchestrator.py
from dataclasses import dataclass, field
from typing import Literal
...

에이전트 간 통신 프로토콜 (Inter-Agent Communication Protocol)

에이전트는 메모리를 직접 공유하지 않고 **구조화된 아티팩트(structured artifacts)**를 교환합니다. 이는 컨텍스트 오염을 방지하고 파이프라인의 감사 가능성(auditable)을 높여줍니다:

# agent_protocol.py
from pydantic import BaseModel, Field
from typing import Any
...

**테스터 에이전트(Tester agent)**는 코더(Coder)의 아티팩트를 받아 자신만의 아티팩트를 생성합니다:

# tester_agent.py
class TesterAgent(BaseAgent):
    def __init__(self, model: str = "gpt-4", test_runner: TestRunner | None = None):
        super().__init__(model=model)
        self.test_runner = test_runner or LocalTestRunner()