본문으로 건너뛰기
{junghyeon.dev}

[번역] Harness 엔지니어링: 에이전트 우선 세계에서 Codex를 활용하는 방법

39 min read
#AI#번역#OpenAI#Codex#에이전트

이 글은 개인 학습을 위해 Claude Opus 4.6으로 번역되었으며, 공공 공유를 위한 목적으로 블로그에 게시해둡니다. 원문: Harness engineering: leveraging Codex in an agent-first world 원문의 의미와 뉘앙스를 최대한 살리되, 기술 용어에 대해서는 역주를 추가했습니다.

Ryan Lopopolo, Technical Staff 멤버 | 2026년 2월 11일

지난 5개월간 우리 팀은 하나의 실험을 진행해 왔습니다. 수동으로 작성된 코드 단 한 줄 없이 소프트웨어 제품의 내부 베타 버전을 구축하고 출시하는 것이었습니다.

이 제품은 매일 사용하는 내부 사용자와 외부 알파 테스터를 보유하고 있습니다. 출시되고, 배포되고, 오류가 발생하고, 수정됩니다. 다른 점은, 애플리케이션 로직, 테스트, CI 구성, 문서화, 옵저버빌리티(observability, 시스템의 내부 상태를 외부에서 관측할 수 있는 능력), 내부 툴링에 이르는 모든 코드 한 줄 한 줄이 Codex에 의해 작성되었다는 것입니다. 우리는 코드를 직접 손으로 작성했을 때보다 약 1/10의 시간으로 이를 구축했다고 추정합니다.

인간이 방향을 잡는다. 에이전트가 실행한다.

엔지니어링 속도를 몇 배로 끌어올리는 데 필요한 것을 구축하기 위해, 우리는 의도적으로 이 제약을 선택했습니다. 최종적으로 100만 줄에 달하게 될 코드를 단 몇 주 만에 출시해야 했습니다. 그러기 위해서는 소프트웨어 엔지니어링 팀의 주된 역할이 더 이상 코드를 작성하는 것이 아니라, 환경을 설계하고, 의도를 명시하고, Codex 에이전트가 신뢰할 수 있는 작업을 수행하도록 피드백 루프를 구축하는 것으로 바뀔 때 무엇이 달라지는지 이해해야 했습니다.

이 글은 에이전트 팀과 함께 완전히 새로운 제품을 만들면서 우리가 배운 것들, 즉 무엇이 실패했는지, 무엇이 효과를 발휘했는지, 그리고 우리의 진정한 유일의 희소 자원인 인간의 시간과 주의력을 어떻게 최대화할 것인지에 관한 것입니다.

우리는 빈 git 저장소에서 시작했습니다

빈 저장소에 첫 번째 커밋이 들어온 것은 2025년 8월 말이었습니다.

초기 스캐폴드(scaffold, 프로젝트의 기본 뼈대가 되는 디렉터리 구조·설정 파일·보일러플레이트 코드를 자동 생성하는 것)—저장소 구조, CI 구성, 포매팅 규칙, 패키지 매니저 설정, 애플리케이션 프레임워크—는 소수의 기존 템플릿을 기반으로 GPT-5를 사용하는 Codex CLI에 의해 생성되었습니다. 에이전트가 저장소에서 어떻게 작업할지 지시하는 초기 AGENTS.md 파일조차도 Codex가 직접 작성했습니다.

시스템을 고정시킬 기존의 인간 작성 코드가 없었습니다. 처음부터 저장소는 에이전트에 의해 형성되었습니다.

5개월 후, 저장소는 애플리케이션 로직, 인프라, 툴링, 문서화, 내부 개발자 유틸리티에 걸쳐 약 100만 줄의 코드를 포함하게 되었습니다. 그 기간 동안 단 세 명의 엔지니어로 구성된 소규모 팀이 Codex를 운영하며 약 1,500개의 풀 리퀘스트(Pull Request, 이하 PR)를 열고 병합했습니다. 이는 엔지니어 1인당 하루 평균 3.5개의 PR에 해당하며, 놀랍게도 팀이 현재 7명으로 늘어나면서 처리량은 오히려 증가했습니다. 중요한 점은, 이것이 단순히 결과물을 위한 결과물이 아니었다는 것입니다. 이 제품은 매일 사용하는 핵심 사용자를 포함하여 수백 명의 내부 사용자들이 실제로 사용했습니다.

개발 과정 전반에 걸쳐 인간은 직접 코드를 기여한 적이 없었습니다. 이것이 팀의 핵심 철학이 되었습니다: 수동으로 작성된 코드는 없다.

엔지니어의 역할을 재정의하다

인간이 직접 코딩하지 않는 상황은 시스템, 스캐폴딩(scaffolding, 에이전트가 작업할 수 있는 기반 구조를 만드는 활동 전반), 레버리지에 집중하는 새로운 종류의 엔지니어링 작업을 만들어냈습니다.

초기 진행은 예상보다 느렸습니다. Codex의 능력이 부족해서가 아니라, 환경이 충분히 명세되지 않았기 때문이었습니다. 에이전트는 높은 수준의 목표를 향해 진행하는 데 필요한 도구, 추상화, 내부 구조가 부족했습니다. 우리 엔지니어링 팀의 주된 역할은 에이전트가 유용한 작업을 수행할 수 있도록 환경을 만드는 것이 되었습니다.

실제로 이는 깊이 우선(depth-first)으로 작업하는 것을 의미했습니다. 더 큰 목표를 작은 빌딩 블록(설계, 코드, 리뷰, 테스트 등)으로 분해하고, 에이전트에게 그 블록들을 구축하도록 프롬프트를 제시하고, 이를 활용하여 더 복잡한 작업을 가능하게 하는 방식이었습니다. 무언가 실패했을 때, 해결책은 거의 항상 "더 열심히 시도하기"가 아니었습니다. 진행의 유일한 방법은 Codex가 작업을 수행하게 하는 것이었기에, 인간 엔지니어는 항상 그 작업에 개입하여 "어떤 역량이 부족한가, 그리고 에이전트가 이를 이해하고 실행하도록 어떻게 만들 것인가?"라고 물었습니다.

인간은 거의 전적으로 프롬프트를 통해 시스템과 상호작용합니다. 엔지니어가 작업을 설명하고, 에이전트를 실행하고, 에이전트가 PR을 열도록 합니다. PR을 완료 상태로 이끌기 위해, 우리는 Codex에게 로컬에서 자체 변경 사항을 리뷰하고, 로컬과 클라우드 양쪽에서 추가적인 에이전트 리뷰를 요청하고, 인간 또는 에이전트의 피드백에 응답하고, 모든 에이전트 리뷰어가 만족할 때까지 루프 안에서 반복하도록 지시합니다. 사실상 이것은 '랄프 위검 루프(Ralph Wiggum Loop)'입니다.

역주: 랄프 위검 루프는 Geoffrey Huntley가 고안한 에이전트 코딩 패턴입니다. AI 에이전트에게 동일한 작업을 중단 조건이 충족될 때까지 반복 실행시키며, 에이전트는 매 반복마다 이전 결과(git 히스토리 등)를 참고해 점진적으로 개선합니다. 이름은 심슨즈의 랄프 위검에서 따왔습니다 — 늘 혼란스럽고 실수투성이지만 절대 멈추지 않는 캐릭터입니다.

Codex는 인간이 일일이 CLI에 복사-붙여넣기를 하지 않아도 컨텍스트를 수집할 수 있도록, 표준 개발 도구(gh, 로컬 스크립트, 저장소 내장 스킬)를 직접 사용합니다.

인간이 PR을 리뷰할 수 있지만, 반드시 해야 하는 것은 아닙니다. 시간이 지남에 따라 우리는 거의 모든 리뷰 작업을 에이전트 간에 처리되도록 밀어붙였습니다.

애플리케이션 가독성 높이기

코드 처리량이 증가함에 따라 병목은 인간의 QA(품질 보증) 처리 능력이 되었습니다. 고정된 제약 조건이 인간의 시간과 주의력이었기 때문에, 우리는 애플리케이션 UI, 로그, 앱 메트릭 같은 것들을 Codex가 직접 읽을 수 있게 만들어 에이전트의 역량을 확장하는 작업을 했습니다.

예를 들어, Codex가 변경 사항마다 하나의 인스턴스를 실행하고 구동할 수 있도록 git worktree(하나의 저장소에서 여러 작업 디렉터리를 동시에 체크아웃할 수 있는 Git 기능)당 앱을 부팅 가능하게 만들었습니다. 또한 Chrome DevTools Protocol을 에이전트 런타임에 연결하고 DOM 스냅샷, 스크린샷, 내비게이션 작업을 위한 스킬을 만들었습니다. 이를 통해 Codex가 버그를 재현하고, 수정 사항을 검증하고, UI 동작에 대해 직접 추론할 수 있게 되었습니다.

옵저버빌리티 툴링에 대해서도 같은 작업을 했습니다. 로그, 메트릭, 트레이스가 특정 worktree에 대해 임시로 구성되는 로컬 옵저버빌리티 스택을 통해 Codex에 노출됩니다. Codex는 해당 앱의 완전히 격리된 버전에서 작업합니다. 로그와 메트릭을 포함하여, 작업이 완료되면 모두 삭제됩니다. 에이전트는 LogQL로 로그를, PromQL로 메트릭을 쿼리할 수 있습니다. 이 컨텍스트가 제공되면 "서비스 시작이 800ms 이내에 완료되도록 하라" 또는 "이 4가지 핵심 사용자 여정에서 어떤 스팬도 2초를 초과하지 않도록 하라"와 같은 프롬프트가 실행 가능해집니다.

단일 Codex 실행이 하나의 작업을 6시간 이상 작업하는 경우도 자주 봅니다(종종 인간이 잠자는 동안에).

저장소 지식을 시스템의 기준으로 삼다

컨텍스트 관리는 에이전트가 크고 복잡한 작업에서 효과적으로 작동하게 만드는 데 있어 가장 큰 도전 중 하나입니다. 초기에 배운 가장 중요한 교훈 중 하나는 단순했습니다: Codex에게 1,000페이지짜리 사용 설명서가 아닌 지도를 주라.

우리는 "하나의 거대한 AGENTS.md" 방식을 시도했습니다. 예측 가능한 방식으로 실패했습니다:

  • 컨텍스트는 희소 자원입니다. 거대한 지시 파일은 작업, 코드, 관련 문서를 밀어냅니다. 그래서 에이전트는 핵심 제약 조건을 놓치거나, 잘못된 것에 최적화하기 시작합니다.
  • 너무 많은 지침은 지침이 아닙니다. 모든 것이 "중요"할 때, 아무것도 중요하지 않습니다. 에이전트는 의도적으로 탐색하는 대신 국지적으로 패턴 매칭을 하게 됩니다.
  • 빠르게 낡아집니다. 단일 거대 매뉴얼은 폐기된 규칙이 쌓이는 묘지가 됩니다. 에이전트는 무엇이 여전히 유효한지 알 수 없고, 인간은 유지보수를 멈추며, 파일은 조용히 짐이 됩니다.
  • 검증이 어렵습니다. 단일 덩어리는 기계적인 검사(커버리지, 최신성, 소유권, 교차 링크)에 적합하지 않아 드리프트(drift, 시간이 지나면서 코드나 문서가 원래 의도에서 점점 벗어나는 현상)는 필연적입니다.

그래서 우리는 AGENTS.md를 백과사전이 아닌 목차로 취급합니다.

저장소의 지식 베이스는 시스템의 기준으로 취급되는 구조화된 docs/ 디렉터리에 있습니다. 간결한 AGENTS.md(약 100줄)가 컨텍스트에 주입되며, 주로 다른 곳에 있는 더 깊은 진실의 원천을 가리키는 지도 역할을 합니다.

AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│   ├── index.md
│   ├── core-beliefs.md
│   └── ...
├── exec-plans/
│   ├── active/
│   ├── completed/
│   └── tech-debt-tracker.md
├── generated/
│   └── db-schema.md
├── product-specs/
│   ├── index.md
│   ├── new-user-onboarding.md
│   └── ...
├── references/
│   ├── design-system-reference-llms.txt
│   ├── nixpacks-llms.txt
│   ├── uv-llms.txt
│   └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md

설계 문서는 목록화되고 인덱싱되어 있으며, 검증 상태와 에이전트 우선 운영 원칙을 정의하는 핵심 신념 세트를 포함합니다. 아키텍처 문서는 도메인과 패키지 레이어링에 대한 최상위 수준의 지도를 제공합니다. 품질 문서는 각 제품 도메인과 아키텍처 레이어를 등급으로 평가하고 시간에 따른 격차를 추적합니다.

계획은 일급(first-class) 결과물로 취급됩니다. 작은 변경에는 임시적인 경량 계획이 사용되며, 복잡한 작업은 진행 상황과 의사결정 로그가 있는 실행 계획으로 저장소에 체크인됩니다. 활성 계획, 완료된 계획, 알려진 기술 부채가 모두 버전 관리되고 같은 위치에 있어, 에이전트가 외부 컨텍스트에 의존하지 않고 작동할 수 있습니다.

이를 통해 점진적 공개(progressive disclosure)가 가능해집니다. 에이전트는 처음부터 압도당하는 대신, 작고 안정적인 진입점에서 시작하여 다음에 어디를 봐야 할지 안내받습니다.

우리는 이를 기계적으로 강제합니다. 전용 린터(linter, 코드의 스타일·규칙 위반을 자동으로 검사하는 도구)와 CI 작업이 지식 베이스가 최신 상태이고, 교차 링크되어 있으며, 올바르게 구조화되어 있는지 검증합니다. 정기적으로 실행되는 "문서 정원 관리(doc-gardening)" 에이전트가 실제 코드 동작을 반영하지 않는 오래되거나 더 이상 유효하지 않은 문서를 스캔하고 수정 PR을 엽니다.

에이전트 가독성이 목표다

코드베이스가 진화함에 따라 Codex가 설계 결정을 내리는 프레임워크도 함께 진화해야 했습니다.

저장소가 전적으로 에이전트에 의해 생성되었기 때문에, 무엇보다 Codex의 가독성에 최적화되어 있습니다. 팀이 신규 입사 엔지니어를 위해 코드의 탐색 가능성을 높이려는 것과 같은 방식으로, 우리 인간 엔지니어의 목표는 에이전트가 저장소 자체로부터 전체 비즈니스 도메인에 대해 직접 추론할 수 있게 만드는 것이었습니다.

에이전트의 관점에서, 실행 중에 컨텍스트 내에서 접근할 수 없는 것은 사실상 존재하지 않는 것입니다. Google Docs, 채팅 스레드, 또는 사람들의 머릿속에 있는 지식은 시스템에서 접근할 수 없습니다. 저장소 로컬의, 버전 관리된 결과물들(코드, 마크다운, 스키마, 실행 가능한 계획 등)만이 에이전트가 볼 수 있는 전부입니다.

시간이 지날수록 더 많은 컨텍스트를 저장소에 밀어 넣어야 한다는 것을 배웠습니다. 아키텍처 패턴에 대해 팀이 합의한 Slack 논의? 에이전트가 발견할 수 없다면, 3개월 후 입사한 새로운 직원이 모르는 것과 마찬가지로 에이전트에게도 읽을 수 없는 것입니다.

Codex에 더 많은 컨텍스트를 제공한다는 것은, 즉흥적인 지시로 압도하는 것이 아니라 에이전트가 추론할 수 있도록 올바른 정보를 체계화하고 노출하는 것을 의미합니다. 새로운 팀원에게 제품 원칙, 엔지니어링 규범, 팀 문화(이모지 선호도 포함)를 소개하는 방식으로 에이전트에게 이 정보를 제공하면 더 잘 정렬된 출력을 얻을 수 있습니다.

이러한 관점은 많은 트레이드오프를 명확하게 해주었습니다. 우리는 저장소 내에서 완전히 내재화하고 추론할 수 있는 의존성과 추상화를 선호했습니다. "지루한" 기술이라고 묘사되는 기술들은 구성 가능성, API 안정성, 그리고 학습 데이터셋에서의 표현 덕분에 에이전트가 모델링하기 더 쉬운 경향이 있습니다. 일부 경우에는 공개 라이브러리의 불투명한 동작을 우회하는 것보다 에이전트가 기능의 하위 집합을 직접 재구현하도록 하는 것이 더 저렴했습니다. 예를 들어 일반적인 p-limit 스타일의 패키지를 가져오는 대신, 자체 map-with-concurrency 헬퍼를 구현했습니다. 이것은 우리의 OpenTelemetry 계측과 긴밀하게 통합되어 있고, 100%의 테스트 커버리지를 가지며, 런타임이 기대하는 방식과 정확히 같이 동작합니다.

에이전트가 직접 검사하고, 검증하고, 수정할 수 있는 형태로 더 많은 시스템을 가져오는 것은 레버리지를 높입니다. Codex뿐만 아니라 코드베이스를 작업하는 다른 에이전트(예: Aardvark)에게도 마찬가지입니다.

아키텍처와 취향 강제하기

문서화만으로는 완전히 에이전트가 생성한 코드베이스를 일관성 있게 유지하지 못합니다. 구현을 세세히 관리하는 대신 불변성(invariants, 시스템 전체에서 항상 참이어야 하는 규칙)을 강제함으로써, 에이전트가 기반을 무너뜨리지 않으면서 빠르게 출시할 수 있게 했습니다. 예를 들어, 우리는 Codex가 경계에서 데이터 형태를 파싱하도록 요구하지만, 그 방법에 대해서는 규정하지 않습니다(모델은 Zod를 좋아하는 것 같지만, 우리가 그 특정 라이브러리를 지정하지는 않았습니다).

에이전트는 엄격한 경계와 예측 가능한 구조를 가진 환경에서 가장 효과적이므로, 우리는 애플리케이션을 엄격한 아키텍처 모델을 중심으로 구축했습니다. 각 비즈니스 도메인은 고정된 레이어 세트로 나뉘며, 의존성 방향이 엄격하게 검증되고 허용 가능한 에지의 수가 제한됩니다. 이 제약 조건은 커스텀 린터(물론, Codex가 생성한!)와 구조적 테스트를 통해 기계적으로 강제됩니다.

아래 다이어그램은 규칙을 보여줍니다: 각 비즈니스 도메인(예: 앱 설정) 내에서 코드는 고정된 레이어 세트를 통해 "앞으로만" 의존할 수 있습니다 (Types → Config → Repo → Service → Runtime → UI). 횡단 관심사(auth, 커넥터, 텔레메트리, 기능 플래그)는 단일 명시적 인터페이스인 Providers를 통해 진입합니다. 그 외의 것은 모두 허용되지 않으며 기계적으로 강제됩니다.

이것은 수백 명의 엔지니어가 있을 때까지 보통 연기하는 종류의 아키텍처입니다. 코딩 에이전트를 사용하면 이것이 초기 전제 조건이 됩니다. 제약 조건이야말로 속도를 가능하게 하면서도 아키텍처 드리프트를 방지하는 장치입니다.

실제로 우리는 이 규칙들을 커스텀 린터와 구조적 테스트, 그리고 소수의 "취향 불변성(taste invariants)"으로 강제합니다. 예를 들어, 구조화된 로깅, 스키마와 타입에 대한 명명 규칙, 파일 크기 제한, 플랫폼별 신뢰성 요구사항을 커스텀 린트로 정적으로 강제합니다. 린트가 커스텀이기 때문에, 오류 메시지 자체에 에이전트가 따를 수 있는 수정 지시사항을 포함시킵니다.

인간 중심 워크플로에서는 이 규칙들이 까다롭거나 제한적으로 느껴질 수 있습니다. 에이전트와 함께하면, 이것들은 효과를 배가시키는 장치가 됩니다. 한번 코드로 정의되면, 동시에 모든 곳에 적용됩니다.

동시에, 제약 조건이 중요한 곳과 그렇지 않은 곳에 대해 명시적입니다. 이것은 대규모 엔지니어링 플랫폼 조직을 이끄는 것과 유사합니다: 경계는 중앙에서 강제하고, 로컬에서는 자율성을 허용합니다. 경계, 정확성, 재현성에 대해서는 깊이 신경 씁니다. 그 경계 내에서는 팀, 또는 에이전트에게 솔루션 표현 방법에 대한 상당한 자유를 허용합니다.

결과물 코드가 항상 인간의 스타일 선호도와 일치하지는 않으며, 그것은 괜찮습니다. 출력이 올바르고, 유지 관리 가능하며, 향후 에이전트 실행에 가독 가능하다면 기준을 충족하는 것입니다.

인간의 취향은 지속적으로 시스템에 피드백됩니다. 리뷰 코멘트, 리팩터링 PR, 사용자 대면 버그들은 문서 업데이트로 캡처되거나 툴링에 직접 인코딩됩니다. 문서가 부족할 때 우리는 그 규칙을 코드로 승격시킵니다.

처리량이 병합 철학을 바꾼다

Codex의 처리량이 증가하면서 많은 기존 엔지니어링 규범이 역효과를 낳게 되었습니다.

저장소는 최소한의 차단 병합 게이트로 운영됩니다. PR은 수명이 짧습니다. 테스트 불안정성(flake, 동일 코드에서 실행할 때마다 성공/실패가 달라지는 불안정한 테스트)은 진행을 무한정 차단하기보다, 후속 실행에서 해결하는 방식을 택합니다. 에이전트 처리량이 인간의 주의력을 훨씬 초과하는 시스템에서, 고치는 비용은 싸고 기다리는 비용이 비쌉니다.

이는 낮은 처리량 환경에서는 무책임할 것입니다. 여기서는 종종 올바른 트레이드오프입니다.

"에이전트 생성"이 실제로 의미하는 것

우리가 코드베이스가 Codex 에이전트에 의해 생성된다고 할 때, 코드베이스의 모든 것을 의미합니다.

에이전트가 생산하는 것들:

  • 제품 코드와 테스트
  • CI 구성 및 릴리스 툴링
  • 내부 개발자 도구
  • 문서화 및 설계 이력
  • 평가 하네스
  • 리뷰 코멘트와 응답
  • 저장소 자체를 관리하는 스크립트
  • 프로덕션 대시보드 정의 파일

인간은 항상 루프에 남아 있지만, 예전보다 다른 추상화 레이어에서 작업합니다. 우리는 작업을 우선순위화하고, 사용자 피드백을 인수 조건(acceptance criteria)으로 변환하고, 결과를 검증합니다. 에이전트가 어려움을 겪을 때, 우리는 그것을 신호로 취급합니다: 무엇이 부족한지—도구, 가드레일(guardrails, 에이전트가 잘못된 방향으로 벗어나지 않도록 설정하는 제약 조건이나 안전장치), 문서화—를 파악하고 항상 Codex 자체가 수정을 작성하게 하여 저장소에 피드백합니다.

에이전트는 표준 개발 도구를 직접 사용합니다. 리뷰 피드백을 가져오고, 인라인으로 응답하고, 업데이트를 푸시하며, 종종 자신의 PR을 스쿼시(squash, 여러 커밋을 하나로 합치는 것)하고 병합합니다.

증가하는 자율성의 수준

개발 루프의 더 많은 부분이 시스템에 직접 인코딩됨에 따라—테스트, 검증, 리뷰, 피드백 처리, 복구—저장소는 최근 Codex가 새로운 기능을 엔드-투-엔드로 이끌 수 있는 의미 있는 전환점을 넘었습니다.

단일 프롬프트가 주어지면, 에이전트는 이제 다음을 수행할 수 있습니다:

  1. 코드베이스의 현재 상태 검증
  2. 보고된 버그 재현
  3. 실패를 보여주는 비디오 녹화
  4. 수정 구현
  5. 애플리케이션을 구동하여 수정 사항 검증
  6. 해결을 보여주는 두 번째 비디오 녹화
  7. PR 열기
  8. 에이전트 및 인간 피드백에 응답
  9. 빌드 실패 감지 및 해결
  10. 판단이 필요할 때만 인간에게 에스컬레이션(escalation, 상위 판단 권한을 가진 사람에게 문제를 넘기는 것)
  11. 변경 사항 병합

이 동작은 이 저장소의 특정 구조와 툴링에 크게 의존하며, 유사한 투자 없이 일반화된다고 가정해서는 안 됩니다—적어도 아직은요.

엔트로피와 가비지 컬렉션

완전한 에이전트 자율성은 새로운 문제도 가져옵니다. Codex는 저장소에 이미 존재하는 패턴을 복제합니다—고르지 않거나 최적이 아닌 것들도 포함해서. 시간이 지남에 따라 이것은 필연적으로 드리프트로 이어집니다.

초기에 인간이 이것을 수동으로 처리했습니다. 우리 팀은 "AI 쓰레기"를 청소하는 데 매주 금요일(주의 20%)을 보냈습니다. 당연히 그 방식은 지속 가능하지 않았습니다.

대신, 우리는 "황금 원칙"이라고 부르는 것을 저장소에 직접 인코딩하고 반복적인 정리 프로세스를 구축하기 시작했습니다. 이 원칙들은 향후 에이전트 실행을 위해 코드베이스를 가독 가능하고 일관성 있게 유지하는, 견해가 담기고 기계적으로 작동하는 규칙입니다. 예를 들어: (1) 불변성을 중앙화하기 위해 직접 작성한 헬퍼보다 공유 유틸리티 패키지를 선호하고, (2) 데이터를 "YOLO 방식"으로 탐색하지 않습니다—에이전트가 추측된 형태를 기반으로 잘못 구축하지 못하도록 경계를 검증하거나 타입이 지정된 SDK에 의존합니다. 정기적인 주기로, 일련의 백그라운드 Codex 작업이 편차를 스캔하고, 품질 등급을 업데이트하고, 표적 리팩터링 PR을 엽니다. 대부분은 1분 이내에 검토하고 자동 병합할 수 있습니다.

이것은 가비지 컬렉션(garbage collection, 더 이상 사용되지 않는 메모리를 자동으로 회수하는 메커니즘)처럼 기능합니다. 기술 부채는 고금리 대출과 같습니다. 고통스러운 급증 상태로 쌓아두고 한꺼번에 해결하는 것보다 지속적으로 작은 단위로 갚는 것이 거의 항상 낫습니다. 인간의 취향은 한 번 캡처되면, 이후 모든 코드 줄에 지속적으로 적용됩니다. 또한 이를 통해 나쁜 패턴을 매일 포착하고 해결할 수 있으며, 코드베이스에서 며칠 혹은 몇 주씩 퍼지도록 내버려 두지 않을 수 있습니다.

우리가 아직 배우고 있는 것

이 전략은 지금까지 OpenAI 내부 출시 및 도입 단계까지 잘 작동해 왔습니다. 실제 사용자를 위한 실제 제품을 구축한 것이 우리의 노력을 현실에 뿌리내리게 했고, 장기적인 유지 관리 가능성을 향해 안내해 주었습니다.

아직 모르는 것은, 완전히 에이전트가 생성하는 시스템에서 수년에 걸쳐 아키텍처 일관성이 어떻게 진화하는가입니다. 우리는 인간의 판단이 가장 큰 레버리지를 더하는 곳이 어디인지, 그리고 그 판단이 복리로 쌓일 수 있도록 어떻게 인코딩할 것인지를 여전히 배우고 있습니다. 또한 모델이 계속 발전함에 따라 이 시스템이 어떻게 진화할지도 아직 알 수 없습니다.

한 가지 분명해진 것이 있습니다: 소프트웨어를 구축하는 것은 여전히 규율을 요구하지만, 그 규율은 이제 코드보다는 스캐폴딩에서 더 많이 나타납니다. 코드베이스를 일관성 있게 유지하는 툴링, 추상화, 피드백 루프가 점점 더 중요해지고 있습니다.

우리의 가장 어려운 도전은 이제 에이전트가 우리의 목표를 달성하도록 돕는 환경, 피드백 루프, 제어 시스템을 설계하는 것에 집중되어 있습니다: 대규모로 복잡하고 신뢰할 수 있는 소프트웨어를 구축하고 유지하는 것.

Codex 같은 에이전트가 소프트웨어 라이프사이클의 더 많은 부분을 담당하게 되면서, 이 질문들은 더욱 중요해질 것입니다. 초기에 얻은 몇 가지 교훈을 공유함으로써, 여러분이 어디에 노력을 투자해야 할지 판단하는 데 도움이 되기를 바랍니다. 그래서 그냥 무언가를 만들어 나갈 수 있기를.

작성자: Ryan Lopopolo

감사의 말: 이 글에 기여한 Victor Zhu와 Zach Brock에게 특별히 감사드리며, 이 새로운 제품을 개발한 전체 팀에게도 감사드립니다.