코드를 쓰는 개발자는 죽었다: Harness Engineering이 바꾸는 개발의 미래
🎧 Voice Briefing
📅 Generated: 2026. 3. 15. 오후 6:33:32
⏱️ Duration: ~70s

코드를 쓰는 개발자는 죽었다: Harness Engineering이 바꾸는 개발의 미래
프롤로그: 만약 당신이 아직도 코드를 "쓰고" 있다면
모든 사람이 AI로 코드를 쓰고 있다. Copilot을 붙이고, ChatGPT에 프롬프트를 던지고, Claude에게 함수를 짜달라고 한다.
하지만 나는 다른 생각이 든다. 우리는 여전히 "타자치는 원숭이"를 흉내내고 있는 건 아닐까?
2026년 2월, OpenAI의 기술 스태프 Ryan Lopopolo가 공개한 사실은 충격적이다. 3명의 엔지니어가 5개월 만에 100만 줄이 넘는 프로덕션 코드를 완성했다. 단 한 줄의 코드도 인간이 직접 쓰지 않았다.1
이것이 가능했던 이유는 단순하다. 그들은 코드를 쓰지 않았다. 시스템을 설계했다.
I – 100만 줄의 코드, 0줄의 인간 코드
2025년 8월, 완전히 비어있는 Git 레포지토리 하나가 생겼다.
코드 한 줄 없었다. README조차 없었다.
5개월 후, 이 레포지토리에는 100만 줄이 넘는 코드가 쌓여 있었다. 애플리케이션 로직, 인프라, 도구, 문서, 내부 개발 유틸리티까지. 약 1,500개의 풀 리퀘스트가 열리고 머지되었다.1
여기서 핵심이 나온다.
"The model is only one part of the system. The surrounding harness determines whether the system actually works."
— OpenAI
3명의 엔지니어가 한 일은 무엇이었을까? 코드를 쓴 것이 아니다. Codex 에이전트가 코드를 쓸 수 있도록 환경을 설계한 것이다. 초기 스캐폴딩, CI 구성, 포매팅 규칙, 패키지 매니저 설정, 애플리케이션 프레임워크 — 심지어 에이전트에게 작업 방법을 지시하는 AGENTS.md 파일조차 Codex가 작성했다.
이것이 Harness Engineering이다.
II – 모델이 아니라 마구(Harness)가 성패를 결정한다
아이러니하게도, AI 시대에 가장 중요한 것은 AI 모델이 아니다.
Harness — 제약 조건, 피드백 루프, 문서, 린터, 생명주기 관리 시스템 — 이것이 AI 에이전트의 성패를 결정한다. LLM이 CPU라면, Harness는 운영체제다.2
graph TD
subgraph Before ["🔴 과거: 프롬프트 중심"]
A[인간이 코드 작성] --> B[AI가 보조]
B --> C[인간이 검증]
end
subgraph After ["🟢 현재: Harness 중심"]
D[인간이 시스템 설계] --> E[AI가 코드 작성]
E --> F[자동화된 검증 루프]
F --> G[AI가 자기 수정]
G --> E
end
왜 이런 전환이 필요한가?
Agentic AI 채택률이 2025년에 340% 급증했다.3 시장 규모는 2025년 284억 달러에서 2026년 896억 달러로 성장이 예상된다. Gartner는 2026년 말까지 기업 애플리케이션의 40% 가 AI 에이전트를 내장할 것으로 예측한다.4
하지만 여기서 역설이 등장한다.
개발자의 85% 가 AI 도구를 사용하지만, 작업을 완전히 위임할 수 있는 비율은 고작 0~20% 에 불과하다.5
왜 그럴까? AI 모델이 부족해서가 아니다. AI가 작동하는 환경이 부족하기 때문이다.
III – 컨텍스트: AI 시대의 진짜 병목
내가 주목한 부분은 이것이다.
수십 MB짜리 AGENTS.md나 아키텍처 문서를 AI가 토씨 하나 빠트리지 않고 완벽하게 이해하는 단계. 우리는 아직 거기에 도달하지 못했다.
에이전트가 오래 실행될수록, 추적해야 할 정보는 폭발적으로 증가한다. 채팅 이력, 도구 출력, 외부 문서, 중간 추론. 컨텍스트 윈도우가 소진되면 AI는 치명적인 선택을 해야 한다 — 이전 대화를 잘라내거나, 핵심 맥락을 잃거나.6
The New Stack은 이를 정확하게 짚었다.
"병목은 컨텍스트다. 엔지니어가 머릿속에 담고 있는 것과, AI가 이해하거나 전달할 수 있는 것 사이의 간극."
한 엔지니어가 코드베이스를 완전히 이해하기까지 몇 주가 걸린다. 기술 아키텍처뿐 아니라 암묵적 규칙까지. 언제 성능을 가독성보다 우선할지, 어떤 추상화를 팀이 실제로 유지하는지, 엣지 케이스에 대해 얼마나 방어적이어야 하는지.
AI 에이전트는 이런 축적된 지식 없이 코드를 쓴다. 문서를 줄 수는 있지만, 문서는 항상 불완전하다.
다시 말해, Harness Engineering은 이 간극을 메우는 기술이다.
| 구분 | 프롬프트 엔지니어링 | Harness Engineering |
|---|---|---|
| 초점 | ❌ 단일 요청 최적화 | ✅ 시스템 전체 설계 |
| 지속성 | ❌ 대화당 휘발 | ✅ 파일시스템 기반 영속 |
| 검증 | ❌ 인간이 수동 확인 | ✅ 자동화된 검증 루프 |
| 확장성 | ❌ 1회성 | ✅ 1,500 PR 규모 |
| 핵심 역량 | 질문 잘하기 | 아키텍처 설계 |
IV – Software Engineer에서 System Engineer로
그렇다면 개발자는 무엇을 해야 하는가?
OpenAI는 명확하게 말한다. 프롬프트 엔지니어링 단계에서 멈춰 있다면, Harness Engineering으로 나아가야 한다. 최소한 다음의 것들을 반드시 이해해야 한다.
Harness Engineering 5대 역량
| 역량 | 핵심 내용 |
|---|---|
| 🏗️ 소프트웨어 아키텍처 | 모듈 경계, 데이터 흐름, 의존성 구조 |
| 🔗 의존성 경계 | 컴포넌트 간 인터페이스, 계약 설계 |
| 📁 레포지토리 설계 | 디렉토리 구조, 네이밍 컨벤션, 진입점 |
| 📝 문서화 시스템 | 정식 문서 계층, AI가 읽을 수 있는 지식 레이어 |
| 🔄 자동화된 검증 루프 | CI/CD, 린터, 테스트, 자동 수정 파이프라인 |
pie title Harness Engineering 핵심 역량 비중
"소프트웨어 아키텍처" : 30
"문서화 시스템" : 25
"자동화된 검증 루프" : 20
"레포지토리 설계" : 15
"의존성 경계" : 10
Stanford 대학 연구에 따르면, 22~25세 소프트웨어 개발자의 고용은 2022년에서 2025년 사이 약 20% 감소했다.7 IDC는 2026년까지 G2000 기업의 40% 직무가 AI 에이전트와 함께 일하는 형태로 재정의될 것이라 전망한다.8
여기서 의문이 생긴다. 그렇다면 코드를 쓰지 않는 개발자는 정확히 무엇을 하는가?
시스템을 설계한다. AI가 어떤 정보를, 어디서 취득해야 할지에 대한 지도를 쥐어준다. 이것이 Harness Engineering이다.
💭 이 글을 읽고 생각해볼 질문
-
AI가 코드의 80%를 쓰는 시대에, 개발자의 "진짜 전문성"은 어디에 있을까?
-
피드백 루프와 자동 검증 시스템은 AI의 컨텍스트 한계를 실제로 극복할 수 있을까, 아니면 새로운 병목을 만들 뿐일까?
-
Harness Engineering 역량이 고용 시장을 재편한다면, 기존 개발자와 비개발자 사이의 경계는 어떻게 변할까?
댓글로 당신의 생각을 공유해주세요.
결론: 코드의 죽음, 설계의 부활
시의적인 질문부터 시작했다. "AI가 코드를 대체할까?"
하지만 진짜 질문은 더 깊은 곳에 있다.
코드를 쓰는 것은 항상 수단이었다. 목적은 문제를 해결하는 시스템을 만드는 것이었다. AI가 수단을 대체하기 시작한 지금, 우리에게 남은 것은 목적 — 어떤 시스템을, 왜, 어떻게 설계할 것인가 — 에 대한 판단이다.
OpenAI가 빈 레포지토리에서 100만 줄의 코드를 만든 방식은 하나의 증명이다. 미래의 개발자는 코드를 쓰는 사람이 아니라, AI가 코드를 쓸 수 있는 세계를 설계하는 사람이다.
"모델은 시스템의 일부에 불과하다. 주변의 마구(Harness)가 시스템이 실제로 작동하는지를 결정한다." — 당신의 마구는 준비되어 있는가?
Sources
이 글이 도움이 되셨다면, 한 명의 친구에게 공유해주세요.