🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

한 팀이 5개월 동안 사람이 직접 코드를 쓰지 않고 Codex만으로 내부 베타 제품을 구축·배포하며, 엔지니어의 역할이 코드 작성에서 환경 설계, 의도 명세, 피드백 루프 구축으로 이동한다는 점을 실험적으로 보여준다.

📌 핵심 요약

• 팀은 빈 Git 저장소에서 시작해 약 5개월 동안 애플리케이션 로직, 테스트, CI 설정, 문서, 관측성, 내부 도구까지 모든 코드를 Codex가 작성하도록 하는 실험을 진행했다.
• 제품은 내부 일일 사용자와 외부 알파 테스터가 사용하는 실제 소프트웨어였고, 배포되고 고장 나며 수정되는 정상적인 제품 수명주기를 거쳤다.
• 사람은 코드를 직접 작성하지 않고 목표를 쪼개고, 에이전트가 이해할 수 있는 구조와 도구를 만들고, 리뷰·테스트·관측 피드백 루프를 설계하는 역할을 맡았다.
• 코드베이스와 문서 체계는 Codex가 직접 탐색하고 판단할 수 있도록 저장소 내부에 구조화되었으며, AGENTS.md는 백과사전이 아니라 더 깊은 문서로 안내하는 목차 역할을 했다.
• 저자들은 에이전트가 빠르게 움직이게 하려면 세부 구현을 일일이 지시하기보다 아키텍처 경계, 의존성 방향, 로깅·스키마·구조 규칙 같은 불변조건을 기계적으로 강제해야 한다고 강조한다.

🧩 주요 포인트

1. 팀은 빈 Git 저장소에서 시작해 약 5개월 동안 애플리케이션 로직, 테스트, CI 설정, 문서, 관측성, 내부 도구까지 모든 코드를 Codex가 작성하도록 하는 실험을 진행했다.
2. 제품은 내부 일일 사용자와 외부 알파 테스터가 사용하는 실제 소프트웨어였고, 배포되고 고장 나며 수정되는 정상적인 제품 수명주기를 거쳤다.
3. 사람은 코드를 직접 작성하지 않고 목표를 쪼개고, 에이전트가 이해할 수 있는 구조와 도구를 만들고, 리뷰·테스트·관측 피드백 루프를 설계하는 역할을 맡았다.
4. 코드베이스와 문서 체계는 Codex가 직접 탐색하고 판단할 수 있도록 저장소 내부에 구조화되었으며, AGENTS.md는 백과사전이 아니라 더 깊은 문서로 안내하는 목차 역할을 했다.
5. 저자들은 에이전트가 빠르게 움직이게 하려면 세부 구현을 일일이 지시하기보다 아키텍처 경계, 의존성 방향, 로깅·스키마·구조 규칙 같은 불변조건을 기계적으로 강제해야 한다고 강조한다.

🧠 상세 정리

1. 0줄의 수동 코드라는 실험

글은 지난 5개월 동안 한 팀이 내부 베타 소프트웨어 제품을 만들고 배포하면서 사람이 직접 작성한 코드를 0줄로 유지한 실험에서 출발한다. 제품은 단순한 데모가 아니라 내부 일일 사용자와 외부 알파 테스터가 존재하고, 실제로 배포되고, 깨지고, 다시 고쳐지는 운영 대상이었다. 애플리케이션 로직뿐 아니라 테스트, CI 설정, 문서, 관측성, 내부 도구까지 모든 코드가 Codex에 의해 작성되었다. 저자들은 이 방식으로 사람이 직접 코드를 썼을 때보다 약 10분의 1 정도의 시간에 제품을 만들었다고 추정한다. 핵심 구호는 “사람은 방향을 잡고, 에이전트가 실행한다”는 것이다.

2. 빈 저장소에서 시작된 에이전트 주도 코드베이스

첫 커밋은 2025년 8월 말 빈 저장소에 들어갔고, 초기 저장소 구조, CI 설정, 포매팅 규칙, 패키지 매니저 설정, 애플리케이션 프레임워크까지 Codex CLI와 GPT-5가 생성했다. 에이전트가 저장소에서 어떻게 일해야 하는지를 설명하는 AGENTS.md조차 Codex가 작성했다. 이 때문에 기존의 사람이 쓴 코드가 시스템을 고정하거나 기준점 역할을 하지 않았고, 처음부터 저장소의 형태가 에이전트에 의해 만들어졌다. 5개월 뒤 저장소는 애플리케이션 로직, 인프라, 도구, 문서, 내부 개발 유틸리티를 포함해 약 백만 줄 규모가 되었다. 세 명의 엔지니어가 Codex를 운용하며 약 1,500개의 PR을 열고 병합했고, 팀이 일곱 명으로 늘어난 뒤에도 처리량은 오히려 증가했다.

3. 엔지니어 역할의 재정의

사람이 코드를 직접 쓰지 않는 제약은 엔지니어링의 중심을 코드 작성에서 시스템, 발판, 레버리지 설계로 이동시켰다. 초기 진행이 예상보다 느렸던 이유는 Codex가 무능해서가 아니라 환경이 충분히 명세되어 있지 않았기 때문이었다. 에이전트가 높은 수준의 목표를 향해 움직이려면 필요한 도구, 추상화, 내부 구조가 있어야 했고, 이를 마련하는 일이 인간 엔지니어의 주된 업무가 되었다. 팀은 큰 목표를 설계, 코드, 리뷰, 테스트 같은 더 작은 구성요소로 쪼개고, Codex가 그 블록을 만들게 한 뒤 다시 더 복잡한 작업을 가능하게 하는 방식으로 일했다. 실패가 발생했을 때도 “더 열심히 시도하라”가 아니라 “어떤 능력이 부족하며, 그것을 에이전트에게 읽히고 강제 가능한 형태로 어떻게 만들 것인가”를 묻는 식이었다.

4. 프롬프트, PR, 에이전트 리뷰 루프

사람과 시스템의 상호작용은 거의 전적으로 프롬프트를 통해 이루어진다. 엔지니어는 작업을 설명하고 에이전트를 실행하며, Codex가 pull request를 열도록 한다. PR을 완료 단계까지 가져가기 위해 팀은 Codex에게 로컬에서 자기 변경사항을 검토하게 하고, 로컬과 클라우드에서 추가적인 에이전트 리뷰를 요청하며, 사람 또는 에이전트가 준 피드백에 응답하게 한다. 모든 에이전트 리뷰어가 만족할 때까지 반복되는 이 과정은 글에서 Ralph Wiggum Loop에 비유된다. Codex는 gh, 로컬 스크립트, 저장소에 포함된 스킬 같은 표준 개발 도구를 직접 사용해 맥락을 수집하므로, 사람이 CLI에 내용을 복사해 붙여넣는 부담도 줄어든다. 사람의 PR 리뷰는 가능하지만 필수는 아니며, 시간이 지나면서 대부분의 리뷰 노력은 에이전트 간 상호작용으로 옮겨갔다.

5. 애플리케이션을 에이전트가 읽을 수 있게 만들기

코드 생산량이 늘어나자 병목은 사람의 QA 역량으로 이동했다. 팀은 제한된 자원이 인간의 시간과 주의력이라는 점을 전제로, 애플리케이션 UI, 로그, 메트릭을 Codex가 직접 읽고 다룰 수 있게 만들었다. 예를 들어 Git worktree마다 애플리케이션을 부팅할 수 있게 해 Codex가 변경사항별로 독립 인스턴스를 실행하고 조작할 수 있도록 했다. 또한 Chrome DevTools Protocol을 에이전트 런타임에 연결하고, DOM 스냅샷, 스크린샷, 내비게이션을 다루는 스킬을 만들었다. 이를 통해 Codex는 버그를 재현하고, 수정사항을 검증하며, UI 동작을 직접 추론할 수 있게 되었다.

6. 관측성까지 포함한 고립된 작업 환경

팀은 관측성 도구에도 같은 원칙을 적용했다. 로그, 메트릭, 트레이스는 각 worktree에 대해 일시적으로 만들어지는 로컬 관측성 스택을 통해 Codex에 노출된다. Codex는 해당 작업에 완전히 격리된 애플리케이션 버전에서 일하고, 그 애플리케이션의 로그와 메트릭도 작업이 끝나면 함께 제거된다. 에이전트는 LogQL로 로그를 조회하고 PromQL로 메트릭을 조회할 수 있다. 이런 맥락이 제공되면 “서비스 시작이 800ms 안에 끝나도록 보장하라”거나 “네 가지 핵심 사용자 여정에서 어떤 span도 2초를 넘지 않게 하라” 같은 지시가 실행 가능한 작업이 된다. 글은 단일 Codex 실행이 한 작업을 여섯 시간 이상 수행하는 경우도 흔하며, 때로는 사람이 자는 동안 진행된다고 설명한다.

7. 저장소 지식을 시스템 오브 레코드로 만들기

대규모·복잡 작업에서 에이전트를 효과적으로 만들 때 가장 큰 과제 중 하나는 맥락 관리였다. 팀이 일찍 배운 교훈은 Codex에게 1,000쪽짜리 설명서를 주는 대신 지도를 주어야 한다는 것이었다. 그래서 AGENTS.md를 백과사전처럼 쓰지 않고 목차처럼 다룬다. 약 100줄 정도의 짧은 AGENTS.md는 컨텍스트에 주입되는 안정적 진입점이며, 더 깊은 진실의 원천은 구조화된 docs/ 디렉터리에 둔다. 설계 문서는 검증 상태와 핵심 신념을 포함해 색인화되고, 아키텍처 문서는 도메인과 패키지 계층의 상위 지도를 제공하며, 품질 문서는 제품 도메인과 아키텍처 계층별 격차를 추적한다. 계획 역시 일급 산출물로 취급되어 가벼운 계획부터 실행 계획, 진행 로그, 의사결정 로그까지 저장소에 체크인된다.

8. 점진적 공개와 문서 관리의 기계적 강제

저장소 내부 지식 구조의 목적은 에이전트에게 처음부터 모든 정보를 밀어 넣는 것이 아니라 점진적 공개를 가능하게 하는 것이다. 에이전트는 작고 안정적인 진입점에서 시작해 다음에 어디를 봐야 하는지 배운다. 활성 계획, 완료된 계획, 알려진 기술 부채가 모두 버전 관리되고 함께 배치되기 때문에 외부 맥락에 의존하지 않고도 작업을 이어갈 수 있다. 팀은 이 구조가 유지되도록 전용 린터와 CI 작업을 마련해 지식 베이스가 최신 상태인지, 상호 링크가 올바른지, 구조가 지켜지는지 검증한다. 반복적인 “문서 정원관리” 에이전트는 실제 코드 동작과 맞지 않는 오래되거나 쓸모없는 문서를 찾아 수정 PR을 연다. 문서도 사람이 기억하는 보조 자료가 아니라 에이전트가 작업하는 운영 표면의 일부가 된 것이다.

9. 에이전트 가독성을 최우선으로 한 설계

코드베이스가 전적으로 에이전트에 의해 생성되기 때문에, 저장소는 먼저 Codex가 읽고 이해하기 쉬운 방향으로 최적화되었다. 사람이 새로 입사한 엔지니어를 위해 코드 탐색성을 높이듯, 이 팀의 목표는 에이전트가 저장소 자체만으로 전체 비즈니스 도메인을 추론할 수 있게 하는 것이었다. 에이전트 관점에서 실행 중 접근할 수 없는 정보는 사실상 존재하지 않는다. Google Docs, 채팅 스레드, 사람의 머릿속에 있는 지식은 시스템에 보이지 않으므로, 코드, 마크다운, 스키마, 실행 가능한 계획 같은 저장소 로컬의 버전 관리 산출물이 중요해진다. 팀은 시간이 지날수록 더 많은 맥락을 저장소 안으로 밀어 넣어야 한다는 점을 배웠고, Slack에서 합의된 아키텍처 패턴도 에이전트가 발견할 수 없다면 몇 달 뒤 입사한 신입에게 알려지지 않은 지식과 다르지 않다고 본다.

10. 불변조건으로 아키텍처와 취향을 강제하기

저자들은 문서만으로는 완전히 에이전트가 생성한 코드베이스의 일관성을 지킬 수 없다고 말한다. 대신 세부 구현을 과도하게 지시하지 않고 불변조건을 강제함으로써 에이전트가 빠르게 배포하면서도 기반을 훼손하지 않게 한다. 예를 들어 데이터 형태는 경계에서 파싱해야 한다는 원칙은 요구하지만, 어떤 라이브러리를 써야 하는지는 지정하지 않는다. 애플리케이션은 각 비즈니스 도메인을 고정된 계층으로 나누고, Types, Config, Repo, Service, Runtime, UI 같은 방향으로만 의존할 수 있도록 설계된다. 인증, 커넥터, 텔레메트리, feature flag 같은 횡단 관심사는 Providers라는 명시적 인터페이스를 통해서만 들어오며, 그 외의 경로는 금지된다. 이러한 규칙은 Codex가 만든 커스텀 린터와 구조 테스트로 기계적으로 검증되며, 저자들은 이런 제약이 에이전트 시대에는 속도와 아키텍처 안정성을 동시에 가능하게 하는 초기 전제라고 본다.

🧾 핵심 주장 / 시사점

• 에이전트 기반 개발에서 병목은 코드 작성 능력보다 에이전트가 볼 수 있고 검증할 수 있는 환경을 얼마나 잘 설계하느냐로 이동한다.
• 저장소 내부의 문서, 계획, 스키마, 관측성, 테스트는 보조 자료가 아니라 에이전트가 일할 수 있게 만드는 핵심 실행 인프라가 된다.
• 속도를 높이려면 구현을 세세히 지시하기보다 계층, 의존성 방향, 경계 파싱, 구조적 테스트 같은 불변조건을 기계적으로 강제하는 편이 더 효과적이다.

✅ 액션 아이템

• 에이전트가 스스로 탐색할 수 있도록 저장소 문서 구조를 점검하고, AGENTS.md를 세부 설명이 아닌 핵심 문서로 이어지는 목차 형태로 정리한다.
• 새 기능 작업을 에이전트에게 맡기기 전에 목표를 작은 단위로 나누고, 테스트·리뷰·관측성 피드백이 자동으로 돌아가는 흐름을 먼저 설계한다.
• 아키텍처 경계, 의존성 방향, 로깅·스키마·구조 규칙처럼 반복적으로 지켜야 할 불변조건을 자동 검사나 CI 규칙으로 강제한다.

❓ 열린 질문

• 우리 팀에서 사람이 직접 구현하는 시간을 줄이고 에이전트가 맡길 수 있는 작업 범위는 테스트, 문서, 내부 도구 중 어디부터인가?
• 에이전트가 빠르게 수정·배포하더라도 제품 품질을 유지하려면 어떤 리뷰, 테스트, 관측성 신호를 필수 피드백 루프로 묶어야 하는가?
• AGENTS.md와 저장소 문서가 에이전트에게 충분한 방향을 주면서도 과도한 지시서가 되지 않게 하려면 어떤 정보만 상위에 남겨야 하는가?