핵심 요약
OpenAI의 한 팀은 사람이 직접 코드를 쓰지 않고 Codex만으로 제품 베타를 만들며, 소프트웨어 개발의 중심이 "코딩"에서 "환경 설계와 피드백 루프 설계"로 이동하는 모습을 확인했다.
핵심은 좋은 모델 자체보다, 에이전트가 읽고 실행하고 검증할 수 있게 만든 리포지터리 구조, 문서 체계, 아키텍처 제약, 관측 가능성, 자동 정리 시스템에 있었다.
에이전트의 생산성을 높이려면 더 많은 자유보다 더 나은 발판이 필요하며, 사람은 구현자보다 조정자이자 시스템 설계자로 역할이 바뀐다.
실험의 출발점과 결과
이 팀은 빈 git 리포지터리에서 시작해 초기 구조, CI, 문서, 설정까지 Codex가 만들도록 했다.
5개월 뒤에는 애플리케이션 로직, 테스트, 인프라, 내부 도구, 문서까지 포함한 대규모 코드베이스가 형성됐고, 소수의 엔지니어가 많은 PR을 처리하며 실제 내부 사용자와 외부 테스트까지 지원했다.
중요한 점은 "AI가 코드 일부를 도와줬다"가 아니라, 코드 작성 자체를 사람의 기본 업무에서 떼어냈다는 데 있다. 이 실험은 에이전트를 보조 도구가 아니라 실행 주체로 둔 개발 방식의 가능성을 탐색한 사례다.
엔지니어의 역할은 코더에서 조정자로 이동한다
이 방식에서는 엔지니어의 핵심 업무가 달라진다.
직접 함수를 짜고 버그를 손으로 고치는 대신, 큰 목표를 작은 작업으로 나누고, 에이전트가 일하기 좋은 구조를 만들고, 실패 원인을 "모델 탓"이 아니라 "환경의 부족함"으로 해석한다.
즉, 사람은 삽을 드는 노동자보다 공사 감독에 가깝다. 어떤 기능이 필요한지 정의하고, 어떤 제약이 필요한지 정하고, 에이전트가 계속 스스로 수정하고 검토할 수 있는 루프를 설계하는 일이 더 중요해진다.
좋은 프롬프트보다 중요한 것은 실행 가능한 환경이다
초기 속도가 느렸던 이유는 모델이 약해서가 아니라, 에이전트가 쓸 수 있는 도구와 구조가 부족했기 때문이다.
에이전트는 목표만 던져준다고 잘 움직이지 않는다. 읽을 수 있는 문서, 실행할 수 있는 스크립트, 검토 가능한 출력, 검증 가능한 기준이 있어야 안정적으로 일한다.
그래서 핵심 질문은 "무엇을 시킬까?"보다 "어떻게 하면 에이전트가 이 작업을 혼자 끝낼 수 있을까?"가 된다. 이는 프롬프트 엔지니어링보다 작업 환경 엔지니어링에 가깝다.
에이전트도 UI와 로그를 읽어야 한다
처리량이 커질수록 사람의 QA는 병목이 된다.
이를 줄이기 위해 팀은 Codex가 앱을 직접 실행하고, UI를 탐색하고, 스크린샷과 DOM을 읽고, 로그와 메트릭을 조회하게 만들었다. 즉, 사람 테스터가 하던 관찰 업무 일부를 에이전트에게 넘긴 것이다.
이 구조가 있으면 "버그를 고쳐라"보다 "이 사용자 여정에서 응답 지연이 2초를 넘지 않게 해라" 같은 목표 지시가 가능해진다. 에이전트가 코드를 바꾸는 것뿐 아니라 결과를 스스로 확인할 수 있기 때문이다.
문서는 설명서가 아니라 지도여야 한다
큰 AGENTS.md 하나에 모든 규칙을 몰아넣는 방식은 실패했다.
이유는 단순하다. 너무 많은 지침은 오히려 중요한 것을 흐리게 하고, 오래된 내용이 쌓이며, 무엇이 진짜 최신 정보인지 판단하기 어렵게 만든다.
그래서 짧은 AGENTS.md는 입구만 맡고, 실제 지식은 구조화된 docs/ 아래에 나뉘어 저장한다. 설계 문서, 제품 명세, 실행 계획, 기술 부채, 참고 자료가 각각 제자리에 있어야 에이전트가 필요한 것만 단계적으로 찾을 수 있다.
좋은 문서는 백과사전보다 지하철 노선도에 가깝다. 처음부터 모든 역을 외우게 하는 대신, 어디서 출발해 어디로 가야 하는지 빠르게 잡아주어야 한다.
리포지터리에 없는 지식은 에이전트에게 없는 지식이다
Slack 대화, 회의 기억, Google Docs 속 맥락은 에이전트가 직접 볼 수 없다.
따라서 팀의 암묵지와 의사결정 이유를 리포지터리 안의 버전 관리되는 형태로 옮기는 것이 매우 중요하다. 코드, 마크다운, 스키마, 계획 문서처럼 에이전트가 검색 가능한 형식으로 존재해야만 추론의 재료가 된다.
이 원칙은 인간 팀에도 유익하다. 새로 합류한 사람도 같은 정보를 볼 수 있기 때문이다. 에이전트 친화적인 코드베이스는 종종 온보딩 친화적인 코드베이스이기도 하다.
에이전트 친화적 아키텍처는 자유보다 경계를 중시한다
이 팀은 엄격한 계층 구조와 명시적 경계를 둔 아키텍처를 사용했다.
비즈니스 도메인 안에서 데이터와 로직은 정해진 층을 따라 이동하고, 인증이나 텔레메트리 같은 횡단 관심사는 정해진 인터페이스를 통해서만 들어오게 했다. 그리고 이 규칙을 문서가 아니라 린터와 구조 테스트로 강제했다.
이 방식은 사람만 개발할 때는 답답하게 느껴질 수 있다. 하지만 에이전트에게는 오히려 고속도로 차선처럼 작동한다. 어디로 가도 되는지 명확할수록 속도와 일관성이 함께 올라간다.
취향은 말보다 규칙으로 남겨야 한다
코드 스타일과 품질 기준을 사람 리뷰에만 의존하면, 에이전트가 만든 대량의 변경을 따라잡기 어렵다.
그래서 팀은 구조화된 로깅, 파일 크기 제한, 네이밍 규칙, 안정성 요구사항 등을 맞춤형 린트와 테스트로 옮겼다. 심지어 에러 메시지에도 수정 힌트를 담아, 실패 자체가 에이전트에게 학습 가능한 피드백이 되게 했다.
핵심은 모든 선택을 중앙 통제하는 것이 아니다. 꼭 지켜야 할 불변 조건만 강하게 고정하고, 그 안에서는 에이전트가 자율적으로 구현하게 하는 것이다.
처리량이 커지면 병합 철학도 바뀐다
에이전트는 많은 PR을 빠르게 만든다. 이때 기존의 엄격한 병합 대기 문화는 오히려 전체 흐름을 막을 수 있다.
이 팀은 짧은 수명의 PR, 적은 차단 게이트, 빠른 후속 수정 중심의 운영으로 바꿨다. 테스트가 일시적으로 흔들려도 모든 것을 멈추기보다, 빠르게 수정하는 편이 더 싸다고 본 것이다.
즉, 저속 수공업 공정의 품질 관리 방식과 고속 자동화 공정의 품질 관리 방식은 달라야 한다. 처리량이 바뀌면 좋은 프로세스의 정의도 바뀐다.
자율성은 기능보다 루프로 만들어진다
이 리포지터리는 점차 Codex가 한 번의 요청으로 버그 재현, 수정, 검증, 영상 기록, PR 생성, 리뷰 대응, 빌드 실패 수정, 병합까지 이어갈 수 있는 수준에 도달했다.
이런 자율성은 모델이 갑자기 똑똑해져서 생긴 것이 아니다. 테스트, 리뷰, 검증, 복구, 에스컬레이션 경로가 리포지터리와 도구 안에 축적된 결과다.
즉, 자율성은 능력치 하나가 아니라 잘 설계된 반복 루프의 총합이다.
에이전트가 늘리면 엔트로피도 늘어난다
에이전트는 기존 패턴을 빠르게 복제한다. 좋은 패턴도 퍼지지만, 어설픈 패턴도 함께 퍼진다.
처음에는 사람이 매주 시간을 들여 이런 "AI 슬로프"를 정리했지만 확장되지 않았다. 이후 팀은 품질 원칙을 명문화하고, 정기적으로 코드베이스를 검사해 리팩터링 PR을 자동 생성하는 백그라운드 작업을 만들었다.
이는 쓰레기가 쌓인 뒤 대청소하는 방식보다, 로봇 청소기가 계속 돌며 먼지를 쌓이지 않게 하는 방식에 가깝다. 기술 부채를 한 번에 갚기보다 조금씩 자동 상환하는 셈이다.
인사이트
에이전트 우선 개발의 본질은 "AI에게 코딩을 시킨다"가 아니다. 더 정확히는, 에이전트가 일할 수 있도록 코드베이스를 기계가 읽는 공장처럼 재설계하는 일이다.
실무에 적용하려면 먼저 세 가지를 점검하면 좋다. 지식이 리포지터리 안에 있는가, 아키텍처 제약이 자동으로 강제되는가, 에이전트가 결과를 스스로 검증할 수 있는가.
작게 시작한다면, 거대한 자동화보다 먼저 짧은 AGENTS.md, 구조화된 docs/, 맞춤형 린트 하나, 자동 문서 점검 하나부터 만드는 것이 가장 현실적인 출발점이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.