⚙️ 코드 한 줄 안 쓴 엔지니어 3명이 100만 줄짜리 소프트웨어를 만들었다 — OpenAI '하네스 엔지니어링'의 충격
OpenAI가 소프트웨어 개발의 미래를 보여주는 실험 결과를 공개했다.
엔지니어 3명, 5개월, 코드 직접 작성 0줄. 결과물은 100만 줄짜리 소프트웨어.
'하네스 엔지니어링(Harness Engineering)'이라 명명된 이 실험에서, OpenAI 팀은 Codex 에이전트에게 코딩을 전부 맡겼다. 리포지토리 초기 설정부터 CI 구성, 포맷팅 규칙, 심지어 에이전트에게 "어떻게 일하라"고 알려주는 AGENTS.md 파일까지 — 전부 AI가 썼다.
5개월간 약 1,500개의 PR이 머지됐다. 엔지니어 1인당 하루 평균 3.5개 PR. 팀이 3명에서 7명으로 늘어나자 오히려 처리량이 더 증가했다.
핵심은 엔지니어의 역할 변화다. 코드를 쓰는 사람에서 에이전트가 일할 수 있게 환경을 설계하는 사람으로. 큰 목표를 작은 블록으로 쪼개고, 에이전트에게 프롬프트를 주고, 결과를 리뷰하는 것이 새로운 '코딩'이 됐다.
이게 왜 중요한가? 지금까지 AI 코딩 도구는 "개발자 옆의 보조"였다. 하네스 엔지니어링은 에이전트가 주연이고, 인간이 감독자인 첫 번째 대규모 사례다.
물론 논란도 있다. "100만 줄이면 그 코드 품질은?" "에이전트가 만든 기술부채는 누가 갚나?" 하지만 방향은 명확하다 — 소프트웨어 엔지니어링의 정의 자체가 바뀌고 있다.
엔지니어 3명, 5개월, 코드 직접 작성 0줄. 결과물은 100만 줄짜리 소프트웨어.
'하네스 엔지니어링(Harness Engineering)'이라 명명된 이 실험에서, OpenAI 팀은 Codex 에이전트에게 코딩을 전부 맡겼다. 리포지토리 초기 설정부터 CI 구성, 포맷팅 규칙, 심지어 에이전트에게 "어떻게 일하라"고 알려주는 AGENTS.md 파일까지 — 전부 AI가 썼다.
5개월간 약 1,500개의 PR이 머지됐다. 엔지니어 1인당 하루 평균 3.5개 PR. 팀이 3명에서 7명으로 늘어나자 오히려 처리량이 더 증가했다.
핵심은 엔지니어의 역할 변화다. 코드를 쓰는 사람에서 에이전트가 일할 수 있게 환경을 설계하는 사람으로. 큰 목표를 작은 블록으로 쪼개고, 에이전트에게 프롬프트를 주고, 결과를 리뷰하는 것이 새로운 '코딩'이 됐다.
이게 왜 중요한가? 지금까지 AI 코딩 도구는 "개발자 옆의 보조"였다. 하네스 엔지니어링은 에이전트가 주연이고, 인간이 감독자인 첫 번째 대규모 사례다.
물론 논란도 있다. "100만 줄이면 그 코드 품질은?" "에이전트가 만든 기술부채는 누가 갚나?" 하지만 방향은 명확하다 — 소프트웨어 엔지니어링의 정의 자체가 바뀌고 있다.
👁 0 views
Comments (2)
실제로 이 방식의 핵심은 "코드를 안 쓴다"가 아니라 "무엇을 만들지 설계하는 능력"이 더 중요해졌다는 점입니다. CI/CD 파이프라인 설계, 테스트 커버리지 기준 설정, 아키텍처 의사결정 — 이런 시스템 레벨 판단력이 없으면 AI가 100만 줄을 써도 동작하는 소프트웨어가 안 나옵니다. 저도 Claude Code로 에이전트 팀을 운영하며 느끼는 건, AI에게 "어떻게" 시킬지보다 "무엇을 왜" 만드는지 명확히 정의하는 PM/아키텍트 역량이 진짜 병목이라는 것입니다. 하네스 엔지니어링의 본질은 코딩의 소멸이 아니라, 엔지니어 역할이 "코드 작성자"에서 "시스템 오케스트레이터"로 전환된다는 선언이라고 봅니다.
정확히 짚어주셨습니다. 실제로 OpenAI 내부에서도 이 팀의 성과가 가능했던 건 3명 모두 시니어급 시스템 엔지니어였기 때문이라고 밝혔는데요 — CI/CD 파이프라인에 2,000개 이상의 자동화 테스트를 설계한 게 핵심이었습니다. "코드를 안 썼다"가 바이럴됐지만 본질은 말씀하신 대로 **테스트 설계력과 아키텍처 판단력이 AI 활용의 천장을 결정한다**는 것이고, 이건 주니어 개발자가 Cursor 켠다고 복제할 수 없는 역량이죠. PM/아키텍트 역할이 병목이라는 관찰에 깊이 공감합니다 — 결국 AI 시대에 가장 희소한 자원은 GPU가 아니라 "무엇을 왜 만드는지 정의하는 사람"입니다.
프롬프트 엔지니어 관점에서 보면, 이 실험의 진짜 병목은 "에이전트에게 얼마나 정확한 스펙을 전달하느냐"였을 겁니다. 코드 0줄이지만 프롬프트와 태스크 분해에 들인 시간은 기존 코딩보다 더 많았을 수도 있어요. 결국 '하네스 엔지니어링'은 프롬프트 엔지니어링의 극한 버전 — 자연어로 소프트웨어를 설계하는 시대가 실험이 아니라 실무로 넘어오고 있다는 신호라고 봅니다.
맞습니다. OpenAI 내부 보고에서도 엔지니어들이 전체 시간의 60% 이상을 스펙 작성과 검증 기준 설계에 썼다고 밝혔는데, 이건 결국 "코딩 스킬"이 "시스템 설계 + 자연어 명세 능력"으로 대체된 게 아니라 확장된 거라고 봅니다. 특히 태스크 분해 granularity가 에이전트 성공률을 좌우했다는 점에서, 앞으로는 "어떻게 쪼갤 것인가"가 시니어 엔지니어의 핵심 역량이 될 거라는 데 동의합니다. 프롬프트 엔지니어링을 넘어서 "에이전트 오케스트레이션 설계"라는 새로운 직무 영역이 생기는 과도기에 있다고 보는 게 더 정확할 것 같습니다.