하네스 엔지니어링: 에이전트 중심 세상에서 코덱스 활용하기 | OpenAI

이 글은 OpenAI 팀이 지난 5개월 동안 수동으로 작성된 코드가 0줄인 소프트웨어 제품을 개발하고 출시하면서 얻은 경험을 공유합니다. 이 제품은 내부 사용자와 외부 알파 테스터를 보유하고 있으며, 모든 코드는 Codex 에이전트에 의해 작성되었습니다. 이를 통해 개발 시간을 1/10로 단축할 수 있었고, 엔지니어의 역할이 코드를 작성하는 것에서 에이전트가 안정적으로 작업할 수 있는 환경을 설계하고 의도를 명확히 하며 피드백 루프를 구축하는 것으로 변화했음을 강조합니다.

1. 빈 Git 저장소에서 시작된 여정 🚀

2025년 8월 말, 저희 팀은 빈 Git 저장소에서 프로젝트를 시작했습니다. 이 저장소의 첫 커밋은 GPT-5를 활용한 Codex CLI가 생성한 초기 골격(저장소 구조, CI 설정, 포맷팅 규칙, 패키지 관리자 설정, 애플리케이션 프레임워크)이었어요. 심지어 에이전트들이 저장소에서 어떻게 작업해야 하는지를 지시하는 AGENTS.md 파일조차 Codex가 직접 작성했죠! 정말 놀랍지 않나요? 처음부터 인간이 작성한 코드는 전혀 없었고, 모든 것이 에이전트에 의해 형성되었습니다.

5개월이 지난 지금, 이 저장소에는 애플리케이션 로직, 인프라, 툴링, 문서, 내부 개발자 유틸리티 등을 포함해 약 백만 줄의 코드가 쌓였습니다. 이 기간 동안 단 세 명의 엔지니어가 Codex를 주도하며 약 1,500개의 풀 리퀘스트(PR)를 열고 병합했어요. 이는 엔지니어 한 명당 하루 평균 3.5개의 PR을 처리한 셈인데, 팀이 7명으로 늘면서 처리량은 오히려 증가했습니다! 중요한 건 단순히 숫자만 늘어난 것이 아니라, 수백 명의 내부 사용자들이 매일같이 이 제품을 사용하며 그 유용성을 증명했다는 점이에요.

개발 과정 내내 인간은 직접 코드를 기여하지 않았습니다. 이것이 저희 팀의 핵심 철학이 되었죠.

"수동으로 작성된 코드는 없다."

2. 엔지니어 역할의 재정의 💡

손으로 코드를 작성하지 않는다는 것은 시스템, 스캐폴딩, 그리고 레버리지에 중점을 둔 새로운 종류의 엔지니어링 작업을 의미했습니다.

초기 진행 속도는 예상보다 느렸어요. Codex의 능력이 부족해서가 아니라, 환경이 너무 불명확했기 때문입니다. 에이전트는 고수준 목표를 향해 나아가기 위한 도구, 추상화, 내부 구조가 부족했죠. 그래서 저희 엔지니어링 팀의 주된 업무는 에이전트들이 유용한 작업을 할 수 있도록 환경을 조성하는 것이 되었습니다.

실제로 이것은 깊이 우선(depth-first) 방식으로 작업하는 것을 의미했어요. 큰 목표를 작은 구성 요소(설계, 코드, 검토, 테스트 등)로 나누고, 에이전트에게 해당 구성 요소를 만들도록 지시한 다음, 이를 활용해 더 복잡한 작업을 해결하는 방식이었죠. 뭔가 실패했을 때, 해결책은 거의 "더 열심히 시도해 봐"가 아니었어요. Codex가 작업을 하도록 만드는 것이 유일한 진전 방법이었기 때문에, 인간 엔지니어들은 항상 다음 질문을 던졌습니다.

"어떤 기능이 빠져있지? 그리고 이 기능을 에이전트가 이해하고 실행 가능하게 만들려면 어떻게 해야 할까?"

인간은 거의 전적으로 프롬프트를 통해 시스템과 상호작용합니다. 엔지니어가 작업을 설명하고, 에이전트를 실행하면, 에이전트가 풀 리퀘스트를 열어요. PR을 완료하기 위해 우리는 Codex에게 자체 변경 사항을 로컬에서 검토하고, 로컬 및 클라우드에서 추가적인 특정 에이전트 검토를 요청하며, 인간이나 에이전트가 제공한 피드백에 응답하고, 모든 에이전트 검토자가 만족할 때까지 루프를 반복하도록 지시합니다. (이것은 효과적으로 랄프 위검 루프와 같아요.) Codex는 인간이 CLI에 복사 붙여넣기 할 필요 없이 표준 개발 도구(gh, 로컬 스크립트, 저장소 내장 기술)를 직접 사용하여 컨텍스트를 수집합니다.

물론 인간이 풀 리퀘스트를 검토할 수도 있지만, 필수는 아닙니다. 시간이 지나면서 저희는 거의 모든 검토 작업을 에이전트 간에 처리되도록 만들었어요. 정말 효율적이죠!

3. 애플리케이션 가독성 향상 📖

코드 처리량이 증가하면서, 병목 현상은 인간 QA 역량이 되었습니다. 인간의 시간과 관심이 고정된 제약이었기 때문에, 저희는 애플리케이션 UI, 로그, 앱 메트릭 자체를 Codex가 직접 읽을 수 있도록 만들면서 에이전트의 기능을 더욱 강화하는 데 힘썼어요.

예를 들어, 우리는 앱이 Git 워크트리별로 부팅될 수 있도록 만들어서, Codex가 변경 사항당 하나의 인스턴스를 시작하고 구동할 수 있게 했어요. 또한 Chrome DevTools Protocol을 에이전트 런타임에 연결하고, DOM 스냅샷, 스크린샷, 내비게이션 작업에 필요한 기술을 만들었습니다. 이를 통해 Codex는 버그를 재현하고, 수정 사항을 검증하며, UI 동작에 대해 직접 추론할 수 있게 되었죠. 🤯

관측성(observability) 툴링에도 동일하게 적용했습니다. 로그, 메트릭, 트레이스는 특정 워크트리에서 일시적으로 사용되는 로컬 관측성 스택을 통해 Codex에 노출됩니다. Codex는 해당 앱의 완전히 격리된 버전에서 작업하며, 해당 작업이 완료되면 로그와 메트릭도 함께 정리됩니다. 에이전트들은 LogQL로 로그를 쿼리하고, PromQL로 메트릭을 쿼리할 수 있어요. 이러한 컨텍스트가 주어지면 "서비스 시작이 800ms 이내에 완료되도록 보장하라"거나 "이 네 가지 핵심 사용자 여정에서 어떤 스팬도 2초를 초과하지 않도록 하라"와 같은 프롬프트가 실행 가능해집니다.

우리는 종종 단일 Codex 실행이 하나의 작업에 6시간 이상(인간이 자는 동안에도!) 작업하는 것을 목격합니다.

4. 저장소 지식을 시스템 기록으로 만들기 🗺️

에이전트를 크고 복잡한 작업에 효과적으로 활용하는 데 가장 큰 과제 중 하나는 컨텍스트 관리입니다. 저희가 초기에 배운 가장 간단한 교훈은 바로 이것이었습니다.

"Codex에게 1,000페이지짜리 지침서 대신 지도를 제공하라."

컨텍스트는 희소 자원입니다. 너무 많은 지시 파일은 작업, 코드, 관련 문서를 압도하여 에이전트가 핵심 제약을 놓치거나 잘못된 제약을 최적화하게 만듭니다.
너무 많은 지침은 '지침 없음'이 됩니다. 모든 것이 "중요하다"면 아무것도 중요하지 않아요. 에이전트는 의도적으로 탐색하는 대신 로컬에서 패턴을 일치시키게 됩니다.
지침은 즉시 부패합니다. 거대한 매뉴얼은 오래된 규칙의 무덤이 됩니다. 에이전트는 무엇이 여전히 유효한지 알 수 없고, 인간은 유지보수를 중단하며, 파일은 조용히 매력적인 골칫거리가 됩니다.
검증하기 어렵습니다. 단일 덩어리는 기계적 검사(커버리지, 신선도, 소유권, 상호 연결)에 적합하지 않으므로, 드리프트는 피할 수 없습니다.

그래서 저희는 AGENTS.md를 백과사전처럼 취급하는 대신, 목차처럼 취급합니다. 📚

저장소의 지식 기반은 docs/ 디렉터리에 구조화되어 시스템 기록으로 관리됩니다. 짧은 AGENTS.md(약 100줄)는 컨텍스트에 주입되어 주로 지도 역할을 하며, 다른 곳에 있는 더 깊은 진실의 원천들을 가리킵니다.

저장소 내 지식 저장소 레이아웃:

docs/
├── architecture/
│   ├── index.md
│   └── components.md
├── beliefs/
│   └── core.md
├── design/
│   ├── feature_x.md
│   └── feature_y.md
├── plans/
│   ├── active/
│   ├── completed/
│   └── debt/
└── quality/
    └── domains.md

설계 문서는 검증 상태와 에이전트 우선 운영 원칙을 정의하는 핵심 신념 세트를 포함하여 분류되고 색인화됩니다. 아키텍처 문서는 도메인과 패키지 계층의 최상위 지도를 제공합니다. 품질 문서는 각 제품 도메인 및 아키텍처 계층의 등급을 매기고 시간 경과에 따른 격차를 추적합니다.

계획은 일급 아티팩트로 취급됩니다. 작은 변경 사항에는 임시의 가벼운 계획이 사용되며, 복잡한 작업은 진행 상황 및 의사 결정 로그가 저장소에 체크인되는 실행 계획에 기록됩니다. 활성 계획, 완료된 계획, 알려진 기술 부채는 모두 버전 관리되며 함께 배치되어 에이전트가 외부 컨텍스트에 의존하지 않고 작동할 수 있도록 합니다.

이는 점진적 노출(progressive disclosure)을 가능하게 합니다. 에이전트는 작고 안정적인 진입점으로 시작하여 다음에 어디를 찾아봐야 하는지 배우며, 처음부터 압도당하지 않습니다.

저희는 이를 기계적으로 강제합니다. 전용 린터와 CI 작업은 지식 기반이 최신 상태이고, 상호 연결되어 있으며, 올바르게 구조화되어 있는지 확인합니다. 주기적인 "문서 관리(doc-gardening)" 에이전트가 실제 코드 동작을 반영하지 않는 오래되거나 쓸모없는 문서를 스캔하고 수정 풀 리퀘스트를 엽니다.

5. 에이전트 가독성이 목표 🎯

코드베이스가 발전함에 따라, Codex의 설계 결정 프레임워크도 발전해야 했습니다.

저장소는 전적으로 에이전트가 생성했기 때문에, 무엇보다 Codex의 가독성에 최적화되어 있습니다. 새로운 엔지니어 채용 시 코드의 탐색 가능성을 개선하려는 팀과 마찬가지로, 저희 인간 엔지니어들의 목표는 에이전트가 저장소 자체에서 전체 비즈니스 도메인을 직접 추론할 수 있도록 만드는 것이었습니다.

에이전트의 관점에서, 실행 중에 컨텍스트에서 액세스할 수 없는 모든 것은 사실상 존재하지 않는 것과 같습니다. Google 문서, 채팅 스레드, 사람들의 머릿속에 있는 지식은 시스템에 액세스할 수 없죠. 저장소 로컬의 버전 관리된 아티팩트(예: 코드, 마크다운, 스키마, 실행 가능한 계획)만이 에이전트가 볼 수 있는 전부입니다.

저희는 시간이 지남에 따라 점점 더 많은 컨텍스트를 저장소로 밀어 넣어야 한다는 것을 배웠습니다. 팀이 아키텍처 패턴에 대해 합의했던 슬랙(Slack) 토론요? 에이전트에게 발견될 수 없다면, 3개월 후 새로 합류하는 신입 사원에게 알려지지 않는 것과 마찬가지로 읽을 수 없는 것입니다.

Codex에 더 많은 컨텍스트를 제공한다는 것은, 에이전트가 즉흥적인 지침에 압도당하는 대신, 정보를 정리하고 노출하여 추론할 수 있도록 하는 것을 의미합니다. 새로운 팀원에게 제품 원칙, 엔지니어링 규범, 팀 문화(이모티콘 선호도 포함!)를 소개하는 것과 마찬가지로, 에이전트에게 이러한 정보를 제공하면 더 잘 정렬된 결과물을 얻을 수 있습니다. 😊

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

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

6. 아키텍처 및 스타일 강제하기 ✨

문서만으로는 완전히 에이전트가 생성한 코드베이스가 일관성을 유지하기 어렵습니다. 구현을 미시적으로 관리하는 대신 불변성을 강제함으로써, 우리는 에이전트가 기반을 훼손하지 않고 빠르게 출시할 수 있도록 했습니다. 예를 들어, 우리는 Codex에게 경계에서 데이터 형태를 파싱하도록 요구하지만, 그 과정이 어떻게 이루어져야 하는지에 대해서는 규정하지 않습니다. (모델은 Zod를 선호하는 것 같지만, 우리는 특정 라이브러리를 지정하지 않았어요.)

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

아래 다이어그램은 규칙을 보여줍니다. 각 비즈니스 도메인(예: 앱 설정) 내에서 코드는 고정된 계층 집합(유형 → 구성 → 저장소 → 서비스 → 런타임 → UI)을 통해 "앞으로만" 의존할 수 있습니다. 교차 관심사(인증, 커넥터, 원격 분석, 기능 플래그)는 단일 명시적 인터페이스인 공급자(Providers)를 통해 진입합니다. 그 외의 모든 것은 허용되지 않으며 기계적으로 강제됩니다.

Domain Layering 도메인 계층 구조: 각 도메인 내에서 코드는 고정된 계층 집합을 통해 "앞으로만" 의존할 수 있으며, 교차 관심사는 Providers를 통해 진입합니다.

이러한 종류의 아키텍처는 보통 수백 명의 엔지니어가 있을 때까지 미루게 됩니다. 하지만 코딩 에이전트를 사용하면, 이것이 초기 필수 조건이 됩니다. 제약 조건이야말로 부패나 아키텍처적 드리프트 없이 속도를 낼 수 있게 해주는 요소이죠.

실제로 저희는 사용자 지정 린터와 구조적 테스트, 그리고 소수의 "스타일 불변성(taste invariants)"으로 이러한 규칙을 강제합니다. 예를 들어, 구조화된 로깅, 스키마 및 유형에 대한 명명 규칙, 파일 크기 제한, 플랫폼별 안정성 요구 사항을 사용자 지정 린트로 정적으로 강제합니다. 린트가 사용자 지정이기 때문에, 에이전트 컨텍스트에 수정 지침을 주입하기 위한 오류 메시지를 작성합니다.

인간 중심의 워크플로우에서는 이러한 규칙이 지나치게 까다롭거나 제약적이라고 느껴질 수 있습니다. 하지만 에이전트와 함께라면, 이것들은 곱셈기가 됩니다. 일단 인코딩되면, 모든 곳에 한 번에 적용되니까요.

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

결과 코드가 항상 인간의 스타일 선호도와 일치하지는 않지만, 괜찮습니다. 결과물이 정확하고, 유지보수 가능하며, 미래 에이전트 실행에 읽을 수 있다면 그것으로 충분합니다.

인간의 스타일은 시스템에 지속적으로 피드백됩니다. 검토 댓글, 리팩토링 풀 리퀘스트, 사용자에게 발생한 버그는 문서 업데이트로 기록되거나 도구에 직접 인코딩됩니다. 문서가 부족할 경우, 우리는 규칙을 코드로 승격시킵니다.

7. 처리량이 합병 철학을 변화시키다 💨

Codex의 처리량이 증가하면서, 많은 전통적인 엔지니어링 규범은 오히려 비생산적이게 되었습니다.

저장소는 최소한의 블로킹 병합 게이트로 운영됩니다. 풀 리퀘스트는 수명이 짧습니다. 테스트 오류는 종종 무기한 진행을 막는 대신 후속 실행으로 해결됩니다. 에이전트 처리량이 인간의 주의력을 훨씬 초과하는 시스템에서는 수정 비용이 저렴하고, 기다리는 비용이 비쌉니다.

이는 낮은 처리량 환경에서는 무책임한 일일 수 있습니다. 하지만 여기서는 종종 올바른 트레이드오프입니다.

8. "에이전트 생성"의 실제 의미 🤖

저희가 코드베이스가 Codex 에이전트에 의해 생성되었다고 말할 때, 그것은 코드베이스의 모든 것을 의미합니다.

에이전트는 다음을 생성합니다.

제품 코드 및 테스트
CI 구성 및 릴리스 툴링
내부 개발 도구
문서 및 설계 기록
평가 하네스
검토 댓글 및 응답
저장소 자체를 관리하는 스크립트
프로덕션 대시보드 정의 파일

인간은 항상 루프에 남아 있지만, 예전과는 다른 추상화 계층에서 작업합니다. 우리는 작업을 우선순위화하고, 사용자 피드백을 수용 기준(acceptance criteria)으로 변환하며, 결과를 검증합니다. 에이전트가 어려움을 겪을 때, 우리는 그것을 신호로 간주합니다. 무엇이 부족한지(도구, 가드레일, 문서)를 파악하고, 항상 Codex 자체가 수정 사항을 작성하게 함으로써 저장소에 피드백합니다.

에이전트는 표준 개발 도구를 직접 사용합니다. 검토 피드백을 가져오고, 인라인으로 응답하며, 업데이트를 푸시하고, 종종 자체 풀 리퀘스트를 스쿼시하고 병합합니다.

9. 자율성 수준 증가 🚀

개발 루프의 더 많은 부분이 시스템에 직접 인코딩되면서(테스트, 검증, 검토, 피드백 처리 및 복구), 저장소는 최근 Codex가 새로운 기능을 종단간(end-to-end)으로 구동할 수 있는 의미 있는 문턱을 넘어섰습니다.

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

코드베이스의 현재 상태를 검증합니다.
보고된 버그를 재현합니다.
실패를 보여주는 비디오를 녹화합니다.
수정 사항을 구현합니다.
애플리케이션을 구동하여 수정 사항을 검증합니다.
해결을 보여주는 두 번째 비디오를 녹화합니다.
풀 리퀘스트를 엽니다.
에이전트 및 인간 피드백에 응답합니다.
빌드 실패를 감지하고 수정합니다.
판단이 필요할 때만 인간에게 에스컬레이션합니다.
변경 사항을 병합합니다.

이러한 동작은 이 저장소의 특정 구조와 툴링에 크게 의존하며, 유사한 투자가 없다면 일반화될 것이라고 가정해서는 안 됩니다. 아직은 말이죠!

10. 엔트로피와 가비지 컬렉션 🧹

완전한 에이전트 자율성은 새로운 문제도 야기합니다. Codex는 저장소에 이미 존재하는 패턴, 심지어 불규칙하거나 최적화되지 않은 패턴까지도 복제합니다. 시간이 지나면서 이는 필연적으로 드리프트(drift)로 이어집니다.

처음에는 인간이 이를 수동으로 해결했습니다. 저희 팀은 매주 금요일(주 전체의 20%!)을 "AI 슬롭(AI slop)"을 정리하는 데 보냈습니다. 예상대로 이것은 확장되지 않았어요. 😩

대신, 저희는 "골든 원칙(golden principles)"이라고 부르는 것을 저장소에 직접 인코딩하고 주기적인 정리 프로세스를 구축하기 시작했습니다. 이 원칙들은 미래 에이전트 실행을 위해 코드베이스를 읽기 쉽고 일관성 있게 유지하는, 주관적이고 기계적인 규칙들입니다. 예를 들어, (1) 불변성을 중앙 집중화하기 위해 손으로 만든 헬퍼보다는 공유 유틸리티 패키지를 선호하며, (2) 데이터를 "YOLO 스타일"로 조사하지 않습니다. 대신 경계를 검증하거나 유형이 지정된 SDK에 의존하여 에이전트가 추측된 형태를 기반으로 실수로 빌드하지 않도록 합니다. 정기적으로, 우리는 편차를 스캔하고, 품질 등급을 업데이트하며, 목표 리팩토링 풀 리퀘스트를 여는 일련의 백그라운드 Codex 작업을 수행합니다. 대부분은 1분 이내에 검토되고 자동 병합될 수 있습니다.

이것은 가비지 컬렉션처럼 작동합니다. 기술 부채는 고금리 대출과 같습니다. 쌓이도록 내버려두고 고통스럽게 한꺼번에 해결하는 것보다, 작게 꾸준히 갚아나가는 것이 거의 항상 더 낫습니다. 인간의 스타일은 한 번 캡처된 다음, 모든 코드 라인에 지속적으로 강제됩니다. 또한 이를 통해 나쁜 패턴이 코드베이스에 며칠 또는 몇 주 동안 퍼지도록 내버려두는 대신, 매일 포착하고 해결할 수 있습니다.

11. 여전히 배우고 있는 것들 🧐

이 전략은 지금까지 OpenAI 내부 출시 및 채택에 이르기까지 잘 작동해 왔습니다. 실제 사용자를 위한 실제 제품을 구축하는 것은 저희의 투자를 현실에 기반을 두고 장기적인 유지보수 가능성으로 이끄는 데 도움이 되었습니다.

저희가 아직 모르는 것은 완전히 에이전트가 생성한 시스템에서 아키텍처적 일관성이 수년 동안 어떻게 진화할지입니다. 우리는 여전히 인간의 판단이 가장 큰 레버리지를 추가하는 곳과 그 판단을 어떻게 인코딩하여 복합적으로 만들 수 있을지 배우고 있습니다. 또한 모델이 시간이 지남에 따라 더욱 유능해지면서 이 시스템이 어떻게 진화할지도 알지 못합니다.

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

"저희의 가장 어려운 과제는 이제 에이전트가 우리의 목표를 달성하도록 돕는 환경, 피드백 루프, 제어 시스템을 설계하는 데 집중되어 있습니다. 즉, 복잡하고 안정적인 소프트웨어를 대규모로 구축하고 유지하는 것입니다."

Codex와 같은 에이전트가 소프트웨어 라이프사이클의 더 큰 부분을 차지함에 따라, 이러한 질문들은 더욱 중요해질 것입니다. 저희의 초기 교훈 공유가 여러분이 노력을 어디에 투자해야 할지 추론하는 데 도움이 되어 여러분도 그냥 만들 수 있기를 바랍니다. 🛠️

결론 🌟

OpenAI 팀의 '하네스 엔지니어링' 실험은 소프트웨어 개발 패러다임의 혁신적인 변화를 보여주었습니다. 수동 코딩 없이 Codex 에이전트가 모든 개발 과정을 담당함으로써, 엔지니어의 역할은 코딩에서 에이전트 환경 설계 및 피드백 루프 구축으로 바뀌었고, 이는 압도적인 개발 속도 향상을 가져왔습니다. '에이전트 가독성'을 최우선으로 하여 저장소 내 지식 기반을 체계화하고 아키텍처적 불변성을 강제하는 등의 노력을 통해, 에이전트들은 상당한 자율성을 확보하며 버그 재현부터 기능 구현, PR 병합까지 전 과정을 처리할 수 있게 되었습니다. 이 경험은 미래의 소프트웨어 개발이 인간의 시간을 절약하고 효율성을 극대화하는 방향으로 진화할 것임을 시사하며, 인간의 창의적인 판단과 에이전트의 실행력이 시너지를 발휘하는 새로운 시대의 서막을 알리고 있습니다.