OpenAI 하네스 엔지니어링 - 에이전트 우선 개발로 5개월간 코드 없이 제품 구축

게시 2026/03/16 업데이트 2026/03/16

By Juho

25 분읽는 시간

개요

OpenAI 내부 팀이 5개월간 수동으로 코드를 한 줄도 직접 작성하지 않고 소프트웨어 제품의 내부 베타를 구축하고 출시한 실험 결과를 공개했다. 모든 코드 라인(애플리케이션 로직, 테스트, CI 구성, 문서화, 관측 가능성, 내부 툴링)이 Codex에 의해 작성되었으며, 수작업으로 코드를 작성했을 때의 약 1/10 시간으로 완성되었다. 이 글에서는 에이전트 팀과 함께 제품을 구축하면서 얻은 교훈과, 희소 자원인 사람의 시간과 주의를 극대화하는 방법을 설명한다.

배경

2025년 8월 말, 빈 git 리포지터리에 첫 번째 커밋이 이루어졌다. 초기 스캐폴드(리포지터리 구조, CI 구성, 서식 지정 규칙, 패키지 관리자 설정, 애플리케이션 프레임워크)는 GPT-5를 사용하여 Codex CLI에서 생성되었다. 에이전트에게 리포지터리 작업 방법을 알려주는 초기 AGENTS.md 파일도 Codex가 직접 작성했다. 시스템을 뒷받침할 사람이 작성한 기존 코드가 전혀 없었으며, 처음부터 리포지터리는 에이전트에 의해 형성되었다. 핵심 철학은 “수동으로 작성한 코드가 없다”는 것이었고, 이 제약을 의도적으로 선택하여 엔지니어링 속도를 몇 배로 높이는 데 필요한 것을 구축했다.

핵심 내용

실험 결과 요약

5개월 후 리포지터리에는 애플리케이션 로직, 인프라, 툴링, 문서화, 내부 개발자 유틸리티 전반에 걸쳐 약 100만 라인의 코드가 포함되었다.

항목	결과
실험 기간	5개월
생성된 코드	약 100만 라인
처리된 PR	약 1,500개
초기 엔지니어 수	3명
일인당 일일 PR 병합	평균 3.5개
현재 팀 규모	7명 (처리량 증가)

단지 출력을 위한 출력이 아니었다. 이 제품은 매일 사용하는 내부 파워 유저를 포함해 수백 명의 사용자가 내부적으로 사용해 왔다. 내부 일일 사용자와 외부 알파 테스터가 배정되어 있고, 출시, 배포, 고장, 수리 작업이 실제로 진행되었다.

엔지니어의 역할 재정의

사람이 직접 코딩을 하지 않기 때문에 시스템, 스캐폴딩, 레버리지에 중점을 둔 다른 종류의 엔지니어링 작업이 필요했다.

초기 진행은 예상보다 더뎠다. 이는 Codex의 역량이 부족해서가 아니라 환경이 제대로 갖춰지지 않았기 때문이다. 에이전트가 상위 목표를 달성하기 위한 도구, 추상화, 내부 구조가 부족했던 것이다.

실제 작업 방식은 큰 목표를 더 작은 빌딩 블록(설계, 코드, 검토, 테스트 등)으로 세분화하고, 에이전트가 이러한 블록을 구성하도록 유도한 다음, 이를 사용하여 더 복잡한 작업을 해결하는 깊이 우선 작업이었다. 실패했을 때 “더욱 분발”하는 것으로는 문제를 해결할 수 없었다. 엔지니어들은 항상 “어떤 기능이 누락되어 있으며, 에이전트가 읽기 쉽고 실행 가능하게 만들려면 어떻게 해야 할까?”라는 고민을 했다.

사람은 거의 전적으로 프롬프트를 통해 시스템과 상호작용한다. 에이전트에게 로컬에서 자체 변경 사항을 검토하고, 에이전트 검토를 추가로 요청하고, 피드백에 응답하고, 모든 에이전트 검토자가 만족할 때까지 반복하도록 지시한다. Codex는 표준 개발 도구(gh, 로컬 스크립트, 리포지터리 내장 스킬)를 직접 사용하여 컨텍스트를 수집한다. 시간이 지남에 따라 거의 모든 검토 작업을 에이전트 간에 처리되도록 전환해 왔다.

애플리케이션의 가독성 향상

코드 처리량이 증가하면서 인적 QA 역량에 병목 현상이 발생했다. 사람의 시간과 주의력이 고정된 제약이었기 때문에, 애플리케이션 UI, 로그, 앱 메트릭 등을 Codex가 직접 읽고 이해할 수 있도록 했다.

git worktree별로 앱을 부팅할 수 있게 하여 Codex가 변경사항마다 하나의 인스턴스를 실행하고 제어할 수 있도록 했다. Chrome DevTools Protocol을 에이전트 런타임에 연결하고 DOM 스냅샷, 스크린샷, 탐색 작업을 위한 스킬을 만들었다. 이를 통해 Codex는 버그를 재현하고, 수정사항을 검증하며, UI 동작에 대해 직접 추론할 수 있었다.

관측 가능성 툴링에서도 마찬가지였다. 로그, 메트릭, 추적은 각 워크트리에 대해 일시적으로 유지되는 로컬 관측 가능성 스택을 통해 Codex에 노출된다. 에이전트는 LogQL로 로그를, PromQL로 메트릭을 쿼리할 수 있다. 이러한 컨텍스트가 주어지면 “서비스 시작이 800ms 이내에 완료되도록” 하거나 “이 네 가지 핵심 사용자 여정에서 어떤 스팬도 2초를 초과하지 않도록” 하는 등의 프롬프트를 다루기 쉬워진다.

한 번의 Codex 실행으로 6시간 이상(종종 사람이 잠자는 동안) 한 가지 작업을 수행하는 경우가 많다.

리포지터리 지식을 기록 시스템으로

컨텍스트 관리는 에이전트가 크고 복잡한 작업을 수행하는 데 있어 가장 큰 과제 중 하나다. 초기 교훈 중 하나는 간단했다. Codex에 1,000페이지의 설명서가 아닌 맵을 제공해야 한다는 것이다.

“하나의 큰 AGENTS.md” 접근 방식을 시도했지만 다음과 같이 실패했다.

문제	설명
컨텍스트 희석	거대한 지침 파일이 작업, 코드, 문서를 복잡하게 만들어 에이전트가 핵심 제약을 놓침
지침 과잉	모든 것이 “중요”하면 중요한 것은 아무것도 없음
유지관리 불가	획일적인 거대 매뉴얼이 낡은 규칙의 무덤으로 변함
검증 어려움	단일 블롭은 기계적 점검에 적합하지 않아 드리프트가 불가피

따라서 AGENTS.md를 백과사전이 아닌 목차로 취급한다. 리포지터리의 지식 베이스는 기록 시스템으로 취급되는 구조화된 docs/ 디렉터리에 있다. 짧은 AGENTS.md(약 100라인)는 컨텍스트에 삽입되어 주로 맵 역할을 하며, 다른 곳에 있는 더 심층적이고 신뢰할 수 있는 정보 소스를 알려준다.

설계 문서는 검증 상태와 에이전트 우선 운영 원칙을 정의하는 핵심 신념을 포함하여 분류되고 색인화된다. 계획은 일급 아티팩트로 간주된다. 복잡한 작업은 진행 상황과 의사결정 로그와 함께 실행 계획에 포함되어 리포지터리에 저장된다. 진행 중인 계획, 완료된 계획, 알려진 기술 부채는 모두 버전화되어 관리되고 동일한 위치에 배치된다.

전용 린터와 CI 작업은 지식 베이스가 최신 상태이고, 교차 링크되어 있으며, 올바르게 구성되어 있는지 검증한다. 반복 실행되는 “doc-gardening” 에이전트가 실제 코드 동작을 반영하지 않는 오래되거나 더 이상 유효하지 않은 문서를 검토하여 수정용 pull request를 연다.

에이전트의 가독성이 목표

리포지터리가 전적으로 에이전트에 의해 생성되었기 때문에, 우선적으로 Codex의 가독성에 최적화되어 있다. 인간 엔지니어의 목표는 에이전트가 리포지터리 자체에서 직접 전체 비즈니스 도메인에 대해 추론할 수 있도록 하는 것이었다.

에이전트의 관점에서 실행 중에 컨텍스트 내에서 액세스할 수 없는 것은 사실상 존재하지 않는 것이다. Google Docs, 채팅 스레드 또는 사람들의 머릿속에 있는 지식은 시스템에서 접근할 수 없다. 리포지터리 내의 버전 관리되는 아티팩트(코드, 마크다운, 스키마, 실행 계획)에만 접근할 수 있다.

시간이 지나면서 점점 더 많은 컨텍스트를 리포지터리에 추가해야 한다는 것을 알게 되었다. Slack 토론에서 팀이 아키텍처 패턴에 대해 합의하더라도, 에이전트가 검색할 수 없다면 3개월 후 입사한 신입 사원이 알 수 없는 것과 마찬가지다.

팀은 “지루한” 기술을 선호했다. 결합성, API 안정성, 학습 설정 내 표현 덕분에 에이전트가 모델링하기 더 쉬운 경향이 있기 때문이다. 어떤 경우에는 범용 라이브러리를 가져오는 대신 에이전트가 기능의 하위 집합을 직접 재구현하는 것이 더 저렴했다. 예를 들어, 범용 p-limit 스타일 패키지 대신 자체적인 map-with-concurrency 헬퍼를 구현했으며, OpenTelemetry 계측과 긴밀하게 통합되어 있고 테스트 커버리지가 100%인 코드를 만들었다.

아키텍처 및 취향 강제 적용

문서화만으로는 에이전트가 생성한 코드베이스를 완전히 일관되게 유지할 수 없다. 구현을 세세하게 관리하지 않고 불변 조건을 강제 적용함으로써 기초를 튼튼히 유지하면서 에이전트가 빠르게 출시할 수 있도록 한다.

에이전트는 엄격한 경계와 예측 가능한 구조를 갖춘 환경에서 가장 효과적이므로, 엄격한 아키텍처 모델을 중심으로 애플리케이션을 구축했다.

계층	역할
Types	기본 타입 정의
Config	설정 관리
Repo	데이터 접근 계층
Service	비즈니스 로직
Runtime	실행 환경
UI	사용자 인터페이스

각 비즈니스 도메인은 엄격하게 검증된 종속성 방향과 제한된 허용 에지 집합을 사용하여 고정된 계층 집합으로 나뉜다. 교차되는 문제(인증, 커넥터, 텔레메트리, 기능 플래그)는 하나의 명시적인 인터페이스인 Providers를 통해 유입된다. 그 외의 모든 것은 허용되지 않으며 기계적으로 강제 적용된다.

맞춤형 린터와 구조적 테스트를 통해 구조화된 로깅, 스키마 및 유형의 명명 규칙, 파일 크기 제한, 플랫폼별 안정성 요구 사항을 정적으로 적용한다. 린트가 맞춤형이므로 오류 메시지를 작성하여 에이전트 컨텍스트에 수정 지침을 주입한다.

이러한 종류의 아키텍처는 보통 수백 명의 엔지니어가 확보될 때까지 미루는 경우가 많다. 코딩 에이전트에는 초기 전제 조건이 있다. 제약 조건이 있어야 성능 저하나 아키텍처 드리프트 없이 속도를 낼 수 있다.

에이전트가 수행하는 자율적 작업의 범위도 크게 확장되었다. 한 번의 프롬프트를 통해 코드베이스 상태 검증, 버그 재현, 실패 상황 동영상 녹화, 수정사항 구현, 애플리케이션 실행 검증, 해결 동영상 녹화, PR 열기, 피드백 응답, 빌드 실패 감지 및 수정, 판단이 필요한 경우에만 사람에게 에스컬레이션, 변경사항 병합까지 처리할 수 있다.

엔트로피 및 가비지 컬렉션

에이전트의 완전한 자율성은 새로운 문제를 야기하기도 한다. Codex는 리포지터리에 이미 존재하는 패턴, 심지어 불균일하거나 최적 상태가 아닌 패턴도 복제한다. 따라서 시간이 지나면 필연적으로 드리프트가 발생한다.

처음에는 매주 금요일(일주일의 20%)마다 “AI 슬로프”를 수동으로 정리했으나, 이 방식은 확장되지 않았다. 대신 “황금 원칙”을 리포지터리에 직접 인코딩하고 정기적인 정리 프로세스를 구축했다.

구체적으로는 다음과 같은 규칙을 적용한다. 불변 조건을 중앙에서 관리하기 위해 직접 만든 헬퍼보다 공유 유틸리티 패키지를 선호한다. “YOLO-style”로 데이터를 탐색하지 않고, 경계를 검증하거나 유형 지정된 SDK에 의존한다. 정기적으로 편차를 검사하고, 품질 등급을 업데이트하며, 대상 리팩터링 PR을 생성하는 Codex 백그라운드 작업을 운영한다. 대부분은 1분 이내에 검토할 수 있으며 자동으로 병합된다.

이것은 가비지 컬렉션처럼 작동한다. 기술 부채는 고금리 대출과 같아서, 이자가 쌓여 한꺼번에 갚는 것보다 조금씩 꾸준히 갚아나가는 편이 훨씬 낫다. 사람의 취향은 한 번 포착되면 코드의 모든 라인에 지속적으로 반영된다.

의미와 시사점

이 실험은 에이전트 우선 개발에 대한 여러 중요한 시사점을 제공한다.

소프트웨어를 구축하는 데는 여전히 규율이 필요하지만, 규율은 코드보다는 스캐폴딩에서 더 많이 드러난다. 코드베이스의 일관성을 유지하는 툴링, 추상화, 피드백 루프는 점점 더 중요해지고 있다.

에이전트가 검사하고 검증하며 직접 수정할 수 있는 형태로 시스템을 더 많이 끌어오면, 코드베이스에서 작업하는 모든 에이전트의 레버리지를 높일 수 있다.

리포지터리는 최소한의 차단 병합 게이트로 운영된다. 에이전트 처리량이 사람의 주의력을 훨씬 초과하는 시스템에서는 수정 비용이 저렴하고 대기 시간은 오래 걸린다. PR은 수명이 짧고, 테스트 불안정성은 후속 실행으로 해결하는 경우가 많다.

아직 알지 못하는 것은 완전한 에이전트 생성 시스템에서 아키텍처 일관성이 수년에 걸쳐 어떻게 진화하는지에 대한 것이다. 사람의 판단이 가장 큰 영향력을 발휘하는 부분과 그 판단을 인코딩하여 복합적으로 활용하는 방법을 여전히 배우고 있다.

결론

OpenAI의 하네스 엔지니어링 실험은 에이전트 우선 개발의 실질적인 가능성과 도전 과제를 동시에 보여준다. 5개월간 수동 코딩 없이 100만 라인의 코드를 생성하고 1,500개의 PR을 처리한 성과는 에이전트 기반 개발이 실용적인 수준에 도달했음을 증명한다. 핵심은 에이전트에게 “무엇을 코딩할지” 지시하는 것이 아니라, 에이전트가 효과적으로 작업할 수 있는 환경(하네스)을 설계하는 것이다. 현재 가장 어려운 과제는 복잡하고 안정적인 소프트웨어를 대규모로 구축하고 유지관리하는 데 도움이 되는 환경, 피드백 루프, 제어 시스템을 설계하는 것이다. Codex와 같은 에이전트가 소프트웨어 라이프사이클에서 더 많은 부분을 차지함에 따라 이러한 질문은 더욱 중요해질 것이다.

Reference

Harness Engineering: Using Codex in an Agent-First World

AI Agent OpenAI