서론 (Introduction)

AI 에이전트에 관한 논의가 "분위기 기반 프롬프팅 (vibe-based prompting)"에서 구조화된 시스템 아키텍처 (system architecture)로 빠르게 변화하고 있습니다. 최근의 발전을 지켜봐 오셨다면, 모델이 자율적으로 실행될 수 있도록 규칙을 설명하는 Andrej Karpathy의 기술 노트인 LOOPS.md를 보셨을 수도 있습니다.

그의 노트 중 한 섹션이 특히 눈에 띄었습니다: "III. 계약을 먼저 협상하라 (NEGOTIATE THE CONTRACT FIRST)."

이 내용을 읽었을 때 매우 익숙한 느낌을 받았습니다. 지난 4월, 저는 Dev.to에 계약 기반 설계: 서로를 망가뜨리지 않고 AI 에이전트를 더 빠르게 작동시키는 방법 (Contract-Based Design: How I Make AI Agents Work Faster Without Breaking Each Other)이라는 제목의 상세 가이드를 게시한 바 있습니다.

서로 다른 규모에서 활동하는 두 명의 독립적인 개발자가 동일한 문제에 대해 정확히 같은 구조적 해결책에 도달했다는 점은 매우 흥미롭습니다. 왜 이 패턴이 업계 표준으로 부상하고 있는지 그 이유를 분석해 보겠습니다.

공통점: 왜 "계약 우선 (Contract-First)"인가?

저의 4월 기사와 Karpathy의 6월/7월 노트 모두 한 가지 결정적인 병목 현상을 강조하고 있습니다: 비구조화된 에이전트 상호작용 (unstructured agent interaction)은 높은 실패율을 초래한다는 점입니다.

에이전트가 즉석에서 코드를 생성하거나 API 호출을 하도록 순진하게 내버려 두면, 드리프트 (drift), 깨진 의존성 (broken dependencies), 그리고 무한 루프 (infinite loops)가 발생합니다. 우리 두 사람이 독립적으로 개발한 해결책은 단순하고 우아한 메커니즘에 의존합니다: 실행 전 협상된 계약으로서 디스크 상의 마크다운 (.md) 파일이 역할을 하는 것입니다.

두 접근 방식을 나란히 비교하면 다음과 같습니다:

특징	나의 "계약 기반 설계 (Contract-Based Design)" (4월)	Karpathy의 "LOOPS.md" (6월/7월)
핵심 파일	입력, 출력 및 경계를 정의하는 작은 .md 파일	마크다운 파일 내의 테스트 가능한 단언 (assertions) 체크리스트
...

아키텍처가 갈라지는 지점 (그리고 서로를 보완하는 지점)

메커니즘은 거의 동일하지만, 우리의 주요 엔지니어링 목표는 약간 달랐습니다. 두 가지를 함께 살펴보면 견고한 시스템을 구축하는 방법에 대한 전체적인 그림을 얻을 수 있습니다:

1. 나의 초점: 병렬 성능을 위한 디커플링 (Decoupling)

나의 이전 포스트에서 주요 목표는 속도와 수평적 확장 (Horizontal Scaling) 이었습니다.
표준적인 파이프라인에서 에이전트들은 순차적으로 의존합니다 (프론트엔드가 백엔드를 기다리고, 백엔드는 데이터베이스를 기다리는 방식). 계약 (Contract)을 먼저 작성함으로써, 당신은 에이전트 간의 의존성 (Agent Dependencies)을 데이터 간의 의존성 (Data Dependencies)으로 전환하게 됩니다.

• .md 계약이 디스크에 저장되면, 프론트엔드 에이전트는 계약에 정의된 모의 데이터 (Mock Data)를 사용하여 빌드할 수 있는 동시에, 백엔드 에이전트는 실제 구현체를 병렬로 빌드할 수 있습니다. 이들은 서로를 차단 (Blocking)하지 않고 병렬로 작동합니다.

2. Karpathy의 초점: 자율적 반복을 위한 가드레일 (Guardrails)

LOOPS.md에서 주요 목표는 장기간의 무인 실행 (Unattended Runs) 시의 신뢰성입니다.
Karpathy는 계약을 독립적인 평가자 (Evaluator) 에이전트를 위한 불변의 루브릭 (Immutable Rubric)으로 사용합니다. 생성자 (Generator)와 평가자 (Evaluator)는 어설션 (Assertions)에 합의할 때까지 마크다운 (Markdown)을 통해 서로

_LOOPS.md_에서 공식화된 것과 정확히 동일한 마크다운 (Markdown) 기반의 계약 (Contract) 패턴을 연구적 관점에서 확인하는 것은 매우 고무적입니다. 이는 에이전트 설계를 고차원적인 연구 프레임워크 (Research Framework) 관점에서 접근하든, 현장에서 밤늦게 디버깅 (Debugging)을 하며 접근하든, 실질적인 현실은 동일하다는 것을 시사합니다. 즉, 엄격하고 사전적인 인터페이스 계약 (Interface Contract) 없이 모델이 코드를 작성하게 두는 방식은 단순히 확장 (Scale)이 불가능하다는 것입니다.

만약 여러분이 자신의 프로젝트에서 이러한 멀티 에이전트 조정 (Multi-agent Coordination) 병목 현상을 해결하고자 하는 개발자라면, 제가 작성한 원본 실습 구현 가이드를 여기서 읽어보실 수 있습니다:

👉 계약 기반 설계: 서로를 망가뜨리지 않고 AI 에이전트를 더 빠르게 작동시키는 방법