“코드를 직접 쓰지 않는다”는 말이 이제 허언이 아니다. OpenAI 팀이 실제로 5개월간 수동으로 코드를 한 줄도 쓰지 않고 소프트웨어 제품을 만들었다. 그 결과물? 100만 줄이 넘는 코드베이스. 이 실험이 불편한 이유는, 그게 딱 당신이 하는 일이기 때문이다.
그래서 무슨 일이 있었나
2026년 초, OpenAI는 Harness Engineering이라는 이름의 실험 결과를 공개했다. 핵심은 이렇다.
소규모 엔지니어 팀이 5개월 동안 Codex 에이전트를 활용해 내부 소프트웨어 제품 베타 버전을 구축했다. 수동으로 작성된 코드는 단 한 줄도 없었다. 최종 코드베이스는 100만 줄을 넘겼다.
1,500개가 넘는 자동화 풀 리퀘스트. 기능 로직, 인프라 코드, 테스트 — 전부 에이전트가 생성했다. 개발자들은 코드를 쓰지 않았다. 대신 에이전트에게 “어떻게 작동해야 하는가”를 지시하고, PR을 검토하고, 피드백 루프를 설계했다.
이 실험은 단순한 데모가 아니다. 프로덕션 수준의 소프트웨어를 AI만으로 만들 수 있다는 실증이다.
하네스 엔지니어링이란 무엇인가
OpenAI가 새롭게 정의한 개념인 하네스 엔지니어링(Harness Engineering)은 이렇게 설명된다:
“LLM이 CPU라면, 하네스는 운영체제다.”
즉, AI 모델이 코드를 생성하는 건 당연한 일이 됐고, 진짜 중요한 건 그 모델이 올바른 방향으로, 지속적으로, 일관되게 작동하도록 제어하는 시스템을 만드는 것이다.
하네스 엔지니어링의 세 가지 핵심 원칙:
1. 아키텍처 엄격성 단방향 의존성 흐름(Types → Config → Repo → Service → Runtime → UI)을 강제한다. 에이전트가 임의로 구조를 망가뜨리지 못하도록 컨스트레인트를 걸어두는 것이다.
2. 기능 정확성 검증 코드가 “잘 작성됐는가”가 아니라 “실제로 원하는 대로 작동하는가”를 자동으로 검증한다. 에이전트는 코드 품질에는 강하지만, 비즈니스 로직 의도를 이해하는 데는 아직 취약하다.
3. 엔트로피 거버넌스 에이전트가 수천 번의 반복 작업을 거치면서 코드베이스가 점점 복잡해지는 문제(엔트로피 증가)를 방지하는 자동화된 “가비지 컬렉션” 메커니즘이다.
에이전트 루프 예시:
1. 개발자: "사용자 인증 플로우에 MFA 추가해"
2. Codex: PR 생성 (코드 300줄)
3. 자동 테스트 + 아키텍처 검사 통과
4. 개발자: PR 리뷰 → approve
5. 에이전트: 다음 태스크로 이동
반복 x 1,500 = 100만 줄 코드베이스
개발자 역할이 진짜로 바뀌고 있다
불편한 질문부터 하자. 당신이 지금 하는 일의 몇 퍼센트가 코드를 타이핑하는 것인가?
Harness 실험이 보여주는 건, 그 부분이 대체 가능하다는 거다. 그럼 무엇이 남는가?
OpenAI가 이 실험에서 에이전트에게 줄 수 없었던 것들:
- 제품의 방향을 결정하는 판단력
- “왜 이 기능이 필요한가”를 설명하는 컨텍스트
- 엣지케이스를 미리 발견하는 경험
- 팀 내 의사결정과 조율
결국 코드를 쓰는 능력은 점점 commodity가 된다. 반면 에이전트에게 무엇을 시킬지 설계하는 능력이 새로운 핵심 스킬로 부상하고 있다.
Martin Fowler도 이 실험을 분석하며 이렇게 말했다:
“개발자의 역할은 코드를 올바르게 작성하는 방법에서, 에이전트가 지속적으로 올바른 일을 하도록 보장하는 방법으로 전환된다.”
지금 당장 갖춰야 할 역량 3가지
그렇다면 에이전트 시대에 살아남기 위해 무엇을 준비해야 할까? Harness 실험에서 역산한 역량 목록이다.
1. 에이전트 오케스트레이션 능력
단순히 “Claude야, 이거 코드 짜줘”가 아니다. 에이전트가 장기 작업에서 일관성을 유지하도록 컨텍스트 설계, 제약 조건 정의, 피드백 루프 구성을 할 수 있어야 한다. 프롬프트 엔지니어링보다 훨씬 구조적인 작업이다.
2. 시스템 수준의 사고
100만 줄 코드베이스를 에이전트가 망가뜨리지 않으려면, 처음부터 명확한 아키텍처 원칙과 경계가 필요하다. 에이전트는 지시한 대로 움직이기 때문에, 잘못된 구조를 지시하면 그걸 100만 줄 규모로 반복한다.
3. 검증 자동화 설계
Thoughtworks는 Harness 실험에 대해 “기능 정확성 검증에 중대한 격차가 있다”고 지적했다. 에이전트가 생성한 코드가 실제로 원하는 대로 동작하는지 자동으로 검증하는 시스템을 만드는 능력이 점점 중요해진다. 테스트 코드를 쓰는 것보다, 테스트 전략 자체를 설계하는 것이다.
마치며
5개월, 수동 코드 0줄, 100만 줄. 이 숫자 앞에서 “AI는 아직 멀었어”라고 말하기는 어렵다.
동시에 이 실험이 보여주는 건 AI가 개발자를 완전히 대체했다는 게 아니다. 오히려 반대다. 에이전트가 잘 작동하게 만들기 위해, 사람이 더 깊게 생각해야 했다. 제품의 방향, 아키텍처의 설계, 검증의 기준 — 이 모든 것이 사람의 판단에서 시작됐다.
변화는 단순하다. 코드를 쓰는 사람에서, 코드를 쓰는 시스템을 설계하는 사람으로.
지금이 그 전환점이다.
본 글은 정보 제공 및 학습 목적이며, 특정 기술/도구에 대한 투자 또는 도입을 권장하는 것이 아닙니다. 기술 도입 결정과 책임은 본인에게 있습니다.