OpenAI 하네스 엔지니어링 — AI 에이전트 중심 개발 방식
OpenAI 하네스 엔지니어링 — AI 에이전트 중심 개발 방식
원문 정보
- 제목: "Harness Engineering: Leveraging Codex in an Agent-First World" (하네스 엔지니어링: 에이전트 중심 세계에서의 Codex 활용)
- 저자: Ryan Lopopolo (OpenAI 기술スタッフ) — Victor Zhu, Zach Brock 공동 기여
- 게시일: 2026년 2월 11일 (HN에 6월 7일 재게시 — 4개월 만)
- HN 점수: 280점, 188개 댓글
"하네스 엔지니어링"이 무엇인가
하네스(harness)는 말을驾驭하는 장비, 즉 말탈과 안장을 의미합니다. 여기서 "하네스 엔지니어링"은 AI 에이전트를 직접 조종하는 것이 아니라, AI가 잘 일할 수 있는 환경·도구·피드백 루프를 설계하는 작업을 뜻합니다. 마치 말을 직접 뛰게 하는 대신, 말탈과 안장을 제대로 조여주는 것과 같습니다.
핵심 실험
OpenAI 내부 팀이 5개월 동안 진행한 실험입니다:
- 3명(→7명)의 엔지니어가 OpenAI의 Codex(GPT-5 기반)를 사용해 내부 베타 제품을 구축
- 사람이 직접 쓴 코드는 0줄 — 모든 코드, 테스트, CI 설정, 문서, 도구가 AI가 생성
- 결과: 약 100만 줄의 코드, 약 1,500개의 풀 리퀘스트(PR), 엔지니어 1인당 하루 3.5개 PR 병합
- 전통적인 방식보다 약 1/10의 시간에 완료
기존 방식과 다른 점
보통 AI 코딩 도구를 쓸 때, 사람은 코드를 쓰고 AI가 보충하는 방식입니다. 하지만 이 팀은 완전히 반대입니다: 사람은 절대 코드를 직접 쓰지 않고, 대신 AI가 "무엇을 해야 할지"를 이해할 수 있도록 문서를 작성하고, 테스트 환경을 만들고, 규칙을 설정합니다. 사람이 실패한 작업이 있을 때 "더 잘 써달라"고 요청하는 것이 아니라, "에이전트에게 어떤 능력이 부족한가?"를 물어보고 그 부분을 채워줍니다.
주요 전략 6가지
1. UI 검증 자동화
Codex가 브라우저(Chrome DevTools Protocol)를 직접 조작해서 DOM 스냅샷(웹페이지 구조의 텍스트적 표현)과 스크린샷을 찍고, UI 버그를 재현하고 수정을 검증합니다. 사람이 눈으로 확인하지 않아도 됩니다. 예를 들어, 버튼이 제대로 표시되는지, 페이지가 정상적으로 로딩되는지를 AI가 스스로 확인합니다.
2. 관측성(Observability) 연결
로그(시스템이 남기는 기록), 메트릭(수치적 지표), 트레이스(성능 추적 데이터)를 Codex가 직접 쿼리(검색)할 수 있도록 로컬 환경에 Vector, Victoria Metrics 같은 도구를 설치합니다. "서비스 시작을 800ms 이내로 해라" 같은 지시를 AI가 직접 측정하고 수정할 수 있습니다. 마치 자동차 정비사가 계기판을 보며 엔진 상태를 확인하는 것처럼, AI도 시스템의 건강 상태를 직접 읽어낼 수 있습니다.
3. 지식 구조화
"하나의 거대한 AGENTS.md 파일" 방식은 실패했습니다. 컨텍스트(AI가 동시에 읽을 수 있는 정보량)를 차지하고, 바로 낡아지고, 검증이 어렵습니다. 대신 AGENTS.md를 약 100줄짜리 "목차"로 만들고, 실제 지식은 docs/ 폴더에 구조적으로 정리합니다. 마치 책의 목차와 본문을 분리한 것 같습니다. 목차는 짧게 유지하고, 필요한 정보는 본문에서 찾아보게 하는 전략입니다.
4. 아키텍처 강제
각 비즈니스 도메인(기능 영역)을 엄격한 계층 구조로 나눕니다 (Types → Config → Repo → Service → Runtime → UI). 커스텀 린터(코드 검사 도구)가 규칙을 강제합니다. 이 규칙을 위반하면 AI가 자동으로 수정하지 못합니다. 이는 마치 건물을 지을 때 설계도를 먼저 정하고, 그 설계도에 맞게만 지을 수 있게 하는 것과 같습니다.
5. 엔트로피 관리 (가비지 컬렉션)
AI가 기존 코드의 패턴을 그대로 복제하다 보니, 나쁜 패턴도 전파됩니다. 처음에는 매주 금요일에 사람이 "AI slop"(AI가 만든 형편없는 코드)를 수동으로 정리했지만, 이는 확장되지 않았습니다. 대신 "골든 원칙"을 리포지토리에 기록하고, 백그라운드 Codex 작업이 규칙 위반을 스캔하고 리팩토링 PR을 자동으로 엽니다. 이는 컴퓨터의 가비지 컬렉션(쓰레기 수집)과 비슷합니다 — 사용하지 않는 메모리를 자동으로 정리하듯, 나쁜 코드 패턴을 자동으로 정리합니다.
6. 점진적 자율성
이제 Codex는 단일 프롬프트(명령)로 버그 재현 → 영상 기록 → 수정 → 검증 → PR 생성 → 피드백 응답 → 병합까지 스스로 완료합니다. 사람이 개입하는 것은 판단이 필요할 때뿐입니다. 마치 자동주행 자동차가 대부분을 스스로 운전하지만, 복잡한 교차로에서는 사람이 개입하는 것과 같습니다.
핵심 메시지
"소프트웨어를 만드는 일은 여전히 규율을 필요로 하지만, 그 규율이 코드 자체가 아니라 코드를 감싸는 구조(스캐폴딩)에 나타난다." 즉, 중요한 것은 코딩 실력이 아니라 AI에게 올바른 환경을 제공하는 능력입니다.
커뮤니티 반응
반대/회의적 입장 — "실제 제품이 뭐냐?"
가장 큰 비판은 "100만 줄 코드를 만들었다지만, 실제로 어떤 제품을 만들었는지 보여주지 않는다"는 것입니다.
- mwkaufma: "채굴꾼에게 곡괭이를 파는 또 다른 숨 막히는 홍보문구야. 금광은 어디에? chatbot이 chatbot에게 git을 통해 코드 더미를 생성하게 해서 실제로 _만든_ 놀라운 제품은 어디에?"
- h4ny: "AI 회의론자는 아니지만, 이 글의 의도에 회의적이야. 에이전트 중심 엔지니어링에 대한 훌륭한 주장을 펼치면서 실제 제품, 실제 사용자, 실제 성장하는 팀을 기반으로 한 진짜 사례처럼 보이려 하는데, 만든 것조차 보여주지 않아."
- osigurdson: "오픈소스로 공개해야 해. 그렇지 않으면 OpenAI 외부의 누구도 통찰을 얻을 수 없어."
이 비판의 핵심은 "OpenAI가 자신의 도구(Codex)를 홍보하기 위해 쓴 글인데, 검증할 수 있는 데이터(코드, 제품)를 공개하지 않으면 홍보문구일 뿐"이라는 것입니다.
비판 — "코드 줄 수는 성과 지표가 아니다"
- yurimo: "왜 거대한 양의 코드 생성이 자랑거리야? 지난 3년 동안 소프트웨어가 훨씬 좋아졌다고 느껴지지 않아, 오히려 더 형편없어졌어. 품질 신호로 '생성된 코드 줄 수' 같은 단순한 목표를 선택하는 게 이상해."
- darepublic: "반쯤 완성된 CRUD 앱(데이터 추가/조회/수정/삭제 앱)을 만들려고 100만 줄의 코드를 썼어?"
- charintstr: "대기업에서 vibe coding(느낌만으로 코딩)을 하고 있어. 이번 반년 동안 약 10만 줄을 만들었고 팀 내 상위 10%야. 코드가 절대적인 쓰레기이거나, GPT 5.5보다 한 세대 앞선 내부 모델을 쓰고 있을 거야."
긍정/실용적 입장 — "유용한 통찰이 있다"
- patdoli: "'우리는 ChatGPT를 프로젝트 매니저로 써봤어. 1주일 만에 140개 이상의 규칙 문서, 아키텍처, 프레임워크를 만들었지만, 코드 한 줄도 없었어. 검토 결과: 완벽하게 안전한 빈 금고.' 하네스는 중요하지만, 코드와 함께 만들지 않으면 소설 쓰는 거야."
- epolanski: "저는 소프트웨어 엔지니어링이 가는 방향이 전혀 마음에 들지 않아. 하지만 동료들의 생산성이 품질 저하 없이 크게 증가했어. 하네스 엔지니어링이 우리 일의 가장 중요한 부분이 되고 있고, AI 회사가 어떻게 처리하는지 엿볼 수 있는 것은 흥미로워."
- shepherdjerred: "이것은 제가 하고 있는 것과 정확히 일치해. Claude/Codex에게 스스로의 작업을 검증할 수 있는 방법을 제공해. 모든 컨텍스트를 리포지토리 안에 유지."
- mohsen1: "5개월 동안 같은 실험을 tsz 프로젝트에서 했어. 비슷한 결론에 도달했어. OpenAI는 모호한 주장만 하지만, 나는 결과를 공유할 수 있어!"
비용 문제
- thelucent: "$20 플랜 사용자로서, 이 순수 에이전트 방식은 불가능해 — 한도를 빠르게 초과하고 결과가 적어. 내가 잘 작동하는 방법은 사람이 쓴 코드를 참조로 제공하고, AI에게 확장하라고 요청하는 거야." — 비용 문제가 핵심입니다. OpenAI는 내부 도구라 비용이 문제가 아니지만, 일반 사용자는 API 한도 때문에 이 방식을 따라갈 수 없습니다.
직업적 우려
- apical_dendrite: "왜 우리는 예술가나 영화 업계 사람들이 AI에 항의하는 것처럼 AI에 항의하지 않는가? 이 글은 시각 예술가들이 느끼는同样的 공포를 불러일으켜야 해. 시니어 엔지니어라면, 너의 기술의 대부분이 곧 완전히 무가치해질 것이라고 효과적으로 말하고 있어."
- murat124: "전자담배 공장에서 작업자들이 컨베이어 벨트에서 전자담배를 가져다가 입에 물고 5초 동안 강하게 빨아대는 영상을 봤어. AI가 작성한 수백 줄의 변경 사항을 사람이 리뷰하는 것과 다르지 않아." — 사람이 AI 코드를 제대로 리뷰하지 못하고 형식적으로 확인만 한다는 비유입니다.
새로운 시각
"하네스 엔지니어링"은 이미 존재하던 관행의 명명일 뿐
이 글이 주장하는 많은 전략 — 계층적 아키텍처, 린터 강제, 테스트 자동화, 문서화 —는 사실 20년 이상 소프트웨어 엔지니어링에서 "좋은 관행"으로 알려온 것입니다. OpenAI가 한 것은 이 관행들을 AI 에이전트에게 적용했을 때 얼마나 더 중요한지 보여준 것입니다. AI 코딩은 "좋은 관행을 따르지 않으면 더 빠르게 엉망이 된다"는 사실을 극적으로 증명합니다.
코드 줄 수를 자랑하는 아이러니
OpenAI가 "100만 줄의 코드"를 자랑하지만, HN 댓글에서 가장 많이 지적받은 것도 바로 "코드 줄 수"입니다. 이는 AI 코딩 시대에 "무엇을 측정해야 하는가"라는 근본적인 질문을 던집니다. 전통적으로 LOC(Lines of Code, 코드 줄 수)는 부정적인 지표로 여겨졌는데, AI 시대에 오히려 성과 지표로 사용하는 것은 역진보일 수 있습니다.
비용의 민주화 문제
이 글에서 가장 무시된 점은 비용입니다. OpenAI는 GPT-5를 내부적으로 무료(또는 매우 저렴하게) 사용할 수 있습니다. 하지만 $20/월 플랜 사용자나 중소기업은 같은 접근을 시도하면 몇 시간 만에 API 한도를 초과합니다. "에이전트 중심 세계"는 실제로는 "에이전트를 감당할 수 있는 회사의 세계"일 뿐입니다.
"AI slop 정리"가 금요일例行作業라는 사실
흥미로운 점은 OpenAI조차 매주 금요일에 "AI slop"(AI가 만든 형편없는 코드)를 정리했다는 것입니다. 이는 AI 코딩이 완벽하지 않다는 것을 스스로 인정하는 것입니다. 그리고 이를 "가비지 컬렉션"으로 자동화했다는 것은, AI 코딩의 핵심 문제가 코드 생성이 아니라 코드 정리라는 것을 시사합니다.
자녀/미래 영향
아인, 석현, 은한을 위한 시사점
- 코딩 교육의 방향 전환: 아이들이 프로그래밍을 배울 때, "코드 쓰기"보다는 "문제 정의하기"와 "시스템 설계하기"에 더 초점을 맞춰야 합니다. AI가 코드를 써주는 시대에는, 무엇을 만들어야 할지 정의하는 능력이 코딩 기술보다 중요해질 것입니다.
- 검증 능력의 중요성: AI가 만든 코드를 평가할 수 있는 안목이 필요합니다. "이 코드가 올바른가?"를 판단하려면 여전히 컴퓨터 과학의 기본 원리를 이해해야 합니다. AI가 답을 주더라도, 답이 맞는지 확인하려면 지식이 필요합니다.
- 도구 활용 능력: 하네스 엔지니어링의 본질은 "올바른 도구를 올바른 환경에 연결하는 것"입니다. 이는 특정 프로그래밍 언어를 아는 것보다 더 일반적인 능력입니다. 아이들이 다양한 도구를 조합하고 자동화하는 경험을 쌓도록 하는 것이 중요합니다.
- 직업 선택: 소프트웨어 엔지니어링의 본질이 바뀔 수 있습니다. 하지만 동시에 새로운 직업 — "AI 하네스 디자이너", "에이전트 환경 엔지니어" 등 — 이 탄생할 것입니다. 중요한 것은 특정 도구에 얽매이기보다 문제 해결 사고력을 기르는 것입니다.
- 비판적 사고: 이 글 자체가 "검증할 수 없는 주장"이라는 점을孩子们과 함께 논의하는 것도 좋은 교육입니다. "100만 줄의 코드"라는 숫자에 현혹되지 않고, "무엇을 만들었는지 보여주라"는 질문을 하는 태도는 AI 시대에 가장 중요한 능력 중 하나입니다.