AI 코딩 시대의 새 방법론 「하네스 엔지니어링」의 출발점을 다룬다. 단어의 어원과 다섯 가지 의미, 60년에 걸친 인간—도구 관계의 변천, 그리고 Prompt → Context → Harness로 이어진 세 번의 명명을 정리한다.
또 하나의 「XX Engineering」인가. 눈을 흘기기 전에, 이 단어가 어디서 왔고 왜 정확한 표현인지부터 확인한다.
Vibe Coding도 다 익히지 못했고, Prompt Engineering 강의는 아직 팔리고 있으며, Context Engineering의 잉크도 마르지 않았다. 지난 1년 사이 「XX Engineering」류 신조어만 네다섯 개가 등장했다. 회의적인 반응은 정상이다.
그러나 이번에는 상황이 다르다. 특정 KOL이 트위터에서 즉흥적으로 만든 단어가 아니다. OpenAI가 공식 블로그 포스트를 발표했고, Mitchell Hashimoto가 장문의 글을 썼으며, Martin Fowler 팀이 분석을 내놓았고, LangChain이 기술 해부를 발표했다. 서로 무관한 팀들이 몇 달 사이에 같은 대상을 가리키며 같은 단어를 사용했다. 각자 비슷한 일을 하던 사람들이 서로를 발견하고, 소통을 위한 공통의 이름이 필요해진 상황에 가깝다.
Harness는 AI 업계가 발명한 단어가 아니다. 최소 1300년경 고프랑스어 「harnois」까지 거슬러 올라가며, 더 이르게는 고대 노르드어에서 유래했을 가능성이 있다. 원뜻은 「군대의 보급품」으로, 처음에는 갑옷과 군사 장비를 가리키다가 이후 마구(馬具)의 의미로 발전했다. 동사 「to harness」의 비유적 의미 — 통제하여 동력으로 활용한다 — 는 1690년대에 이미 등장했다. 300여 년 전부터 사람들은 이 단어로 「힘을 길들이는 일」을 묘사해 왔다.
가죽끈과 금속 연결부로 말을 마차·쟁기에 연결한다. 하네스 없는 말은 힘이 아무리 세도 방향이 없어 수레를 끌지 못한다. 고삐는 말을 강하게 만들지 않지만, 말의 힘을 쓸모 있게 만든다.
우주선 전기 하네스는 극도로 엄격한 표준을 따른다. 케이블 배선, 압착 강도까지 규정한다. 우주에서 선 하나가 풀리면 임무 전체가 끝난다. 혼란한 물리 환경에서 신호를 정확히 전달하는 정밀 제약 체계다.
1950–60년대 메인프레임 디버깅에서 유래했다. stub과 driver의 집합으로 통제된 환경을 만들어 피시험 대상이 예측 가능하게 동작하도록 한다. AI agent 하네스와 개념적으로 완전히 동형이다.
암벽등반·번지점프·건설 현장의 안전 장구다. 행동의 자유는 제한하지 않지만 실족 시 추락을 방지한다. AI agent의 guardrail은 안전벨트의 디지털 버전이다.
자동차의 배선 다발은 엔진·계기판·조명·센서를 연결한다. 에너지를 만들지도 계산을 하지도 않지만, 이것이 없으면 부품들은 서로 모르는 섬이다. 모델·도구·문서·테스트·배포 파이프라인을 하나의 시스템으로 잇는 연결층이다.
| 영역 | Harness 형태 | 핵심 기능 | AI Agent 대응물 |
|---|---|---|---|
| 승마 | 고삐 / 마구 | 방향과 힘의 유도 | 제약 + 방향 |
| 항공우주 | 전기 와이어링 하네스 | 정밀 신호 전송 | 정보 / 컨텍스트 파이프라인 |
| 소프트웨어 테스트 | 테스트 하네스 | 격리 + 모의 환경 | 샌드박스 + 피드백 루프 |
| 안전 | 안전벨트 | 실패 시 보호 | Guardrails / 롤백 |
| 군사(어원) | 갑옷 / 장비 | 보호 + 역량 부여 | Agent의 완전한 장비 |
다섯 영역, 다섯 종류의 하네스가 결국 같은 일을 한다 — 핵심 동력을 대체하지 않고, 그 동력을 통제 가능하고 신뢰 가능하며 쓸모 있게 만든다.
주목할 세부가 두 가지 있다. 첫째, 하네스를 프롬프트나 설정 파일이라 하지 않고 tool shell — 하나의 셸 전체라고 말한다. AI에게 건네는 한마디가 아니라, AI가 그 안에서 구동되는 환경이다. 둘째, 하네스가 AI를 더 똑똑하게 만든다고 말하지 않는다. 두뇌는 그대로다. 하네스는 두뇌가 손을 쓸 수 있게 한다.
「결국 오래된 것에 새 이름을 붙인 것 아닌가」라는 반응은 절반은 옳다. 항공우주 엔지니어는 60년 전부터 유사한 일을 해 왔다. NASA가 우주선의 자동 임무 수행을 위해 설계한 제약·피드백 루프·중복 점검·예외 처리는 오늘날의 하네스와 본질적으로 다르지 않다. 산업 제어의 PLC 안전 인터록도, 소프트웨어 테스트의 test harness도 마찬가지다. AI 업계는 하네스 엔지니어링을 발명한 것이 아니라, 수십 년 전부터 존재한 공학적 규율이 자신에게도 필요함을 뒤늦게 인식했다.
누군가는 CLAUDE.md를 쓰고, 누군가는 AGENTS.md를 쓰고, 누군가는 hooks와 CI 파이프라인을 구성한다. 같은 부류의 일이지만 공통의 단어가 없으면 경험이 전파되지 않는다. 단어가 생기자 비로소 대화가 가능해졌다. Harness Engineering의 가치는 무언가를 발명한 데 있지 않다. 한 무리의 사람들에게 일의 무게중심이 바뀌었음 — 코드를 쓰는 일에서 환경을 설계하는 일로, 실행자에서 아키텍트로 — 을 자각시킨 데 있다. 전환은 이미 일어났고, 이제 이름을 얻었을 뿐이다.
천공카드에서 CLAUDE.md까지, 60년 동안 인간과 프로그래밍 도구의 관계는 여러 번 뒤집혔다. 뒤집힐 때마다 「프로그래머는 끝났다」는 말이 나왔지만, 실제로 바뀐 것은 언제나 프로그래머가 하는 일의 내용이었다.
독일 가르미슈, NATO 소프트웨어 공학 회의. 서로 다른 유형의 프로젝트들이 동일한 곤경 — 만성 지연, 예산 초과, 결함투성이 산출물 — 을 겪고 있음이 드러났다. 합의는 하나였다: 「소프트웨어 위기」가 진행 중이다. Dijkstra는 훗날 「1968년 나는 깊은 우울을 겪었다」고 썼고, goto 문이 프로그램 품질을 떨어뜨린다는 유명한 주장을 내놓았다.
Winston Royce의 논문 「Managing the Development of Large Software Systems」. 역설적이게도 Royce는 논문에서 「waterfall」이라는 단어를 쓴 적도, 그것이 유효한 방법론이라고 주장한 적도 없다. 오히려 단일 순차 통과 방식이 「위험하고 실패를 부른다」고 경고하며 최소 두 번의 반복을 권고했다. 그러나 후대 독자들은 순차 흐름도만 기억했다.
GoF가 「Design Patterns」를 출간하고 23개 고전 패턴을 정의했다. 영문판 50만 부 이상, 13개 언어로 번역. 의의는 23개의 해법 자체가 아니라, 코드의 형태를 논의 가능한 대상으로 만든 최초의 시도라는 데 있다. 인간은 코드를 쓰는 것을 넘어, 코드가 어떤 모양이어야 하는지를 체계적으로 사고하기 시작했다.
17명의 개발자가 「애자일 소프트웨어 개발 선언」을 발표했다. 첫 번째 가치는 「프로세스와 도구보다 개인과 상호작용」. 비슷한 시기 Kent Beck이 TDD와 CI를 보급했다. 이 두 실천이 근본적인 것을 바꿨다 — 인간이 자동화 도구와 체계적으로 협업하기 시작했다. 자동화 테스트가 제2의 눈이 되었고, 인간은 홀로 코드를 쓰는 존재에서 「코드 작성 + 검증 메커니즘 설계」의 존재로 이동했다.
2009년 첫 DevOps Days(벨기에 겐트), 2013년 Docker 오픈소스화, 2014년 Kubernetes 공개. 진정한 전환점은 Docker나 K8s 자체가 아니라 Terraform(Mitchell Hashimoto 작품)·Ansible·Helm이 가져온 이념 — Infrastructure as Code다. 인간은 절차를 일일이 지시하는 대신 기대 상태를 선언하기 시작했다. 「인스턴스 3개, 각 2GB 메모리, 이 이미지로」라고 쓰면 도구가 알아서 실현한다.
2021년 6월 29일, GitHub이 OpenAI Codex 모델 기반의 Copilot 기술 프리뷰를 발표했다(ChatGPT 공개 이전이다). 사용자가 한 줄을 쓰면 AI가 다음 줄을 추측한다. 인간이 여전히 핸들을 잡고 AI는 가속 보조일 뿐이었다. 손을 놓을 수는 없지만, 가속 페달은 확실히 가벼워졌다. 2022년 상용화되어 최초의 상업적 AI 코딩 어시스턴트가 되었고, 같은 해 11월 ChatGPT가 판 전체를 열어젖혔다.
3월 Cognition Labs가 「최초의 완전 자율 AI 소프트웨어 엔지니어」 Devin을 발표했다. SWE-Bench 무보조 해결률 13.86%로 종전 최고 1.96%를 크게 상회했다. 숫자는 작지만 의미는 컸다 — AI가 계획·작성·테스트·PR 제출까지 처음으로 끝에서 끝까지 시도했다. 같은 해 Cursor가 부상했다. MIT 졸업생 4명이 IDE 플러그인이 아닌 IDE 자체를 만들어 16개월 만에 사용자 100만, ARR 1억 달러를 넘겼다. 보도에 따르면 마케팅 비용은 0이었다.
2월, 두 사건이 거의 동시에 일어났다. Anthropic이 터미널 네이티브 AI agent인 Claude Code를 발표했다 — IDE에서 자동완성을 띄우는 것이 아니라 코드베이스에 직접 들어가 파일을 읽고, 코드를 고치고, 테스트를 돌리고, 커밋하고, 외부 도구와 상호작용한다. 두 달이 안 되어 DAU 35만, 연말 연환산 매출 10억 달러 돌파. 같은 달 Andrej Karpathy가 vibe coding이라는 단어를 만들었다 — diff를 보지 않고 모든 변경을 수락하고, 에러 메시지를 그대로 AI에 붙여 넣는다. 코드는 AI의 일이 되고 인간은 「이 느낌이 맞는지」만 책임진다.
2월, OpenAI Codex 팀이 데이터를 공개했다. 이것이 변곡점이다. 숫자 자체(100만 라인 중 고품질 비율은 물음표다) 때문이 아니라, 새로운 작업 방식 — 엔지니어의 주업이 코드 작성이 아니라 환경 설계, 의도 명세, 피드백 루프 구축 — 을 대표하기 때문이다. OpenAI는 이 방식을 Harness Engineering이라 명명했다.
| 시대 | 인간의 일 | 도구의 일 | 핵심 기술 |
|---|---|---|---|
| 1960s–1990s수작업 코딩 | 모든 줄을 직접 작성 | 컴파일 · 실행 | 프로그래밍 언어 숙련 |
| 2001–2010애자일 | 코드 작성 + 프로세스 설계 | 자동화 테스트 · CI | 프로그래밍 + 협업 + 테스트 설계 |
| 2010–2020DevOps | 기대 상태 기술 | 자동 배포 · 모니터링 | 시스템 사고 + 인프라 설계 |
| 2021–2023AI 보조 | 코드 작성 + AI 자동완성 검수 | 자동완성 · 제안 | 프로그래밍 + Prompt 역량 |
| 2024–2025AI Agent | 의도 기술 + 결과 리뷰 | 자율 작성 + 테스트 + 반복 | Context 설계 + 리뷰 역량 |
| 2026–Harness 시대 | 환경 설계 + 제약 정의 | 환경 안에서의 자율 동작 | 시스템 아키텍처 + Harness 설계 |
표를 세로로 읽으면 하나의 숨은 흐름이 보인다. 1960년대에는 모든 줄을 손으로 만졌다. 2001년 검증 작업의 일부를 자동화에 넘겼고, 2014년 선언형 언어로 기대 상태를 기술하기 시작했으며, 2021년 AI가 코드 작성을 돕고, 2025년 AI가 독립적으로 코드를 쓰고, 2026년 인간의 주업은 AI가 일하는 환경의 설계가 되었다. 매 단계마다 인간은 「실행」에서 「설계」 쪽으로 한 층씩 물러섰다.
수동적 후퇴가 아니다. 더 높은 층위의 설계에 시간을 쓸수록 총산출이 커진다는 자각의 결과다. Kent Beck이 TDD를 만든 것은 코드를 못 써서가 아니라, 테스트를 먼저 쓰면 코드 품질이 좋아진다는 것을 발견했기 때문이다. Mitchell Hashimoto가 Terraform을 만든 것도 서버 설정을 못 해서가 아니라, 선언형 기술이 인프라를 더 신뢰할 수 있게 만들기 때문이었다.
60년 동안 인간과 도구의 관계는 네 번 뒤집혔다. 뒤집힐 때마다 「프로그래머」라는 단어의 의미가 달라졌다.
Prompt에서 Context로, 다시 Harness로. 세 개의 독립된 개념이 아니라 같은 일에 대한 세 번의 각성이다. 명명이 이뤄질 때마다 한 무리의 사람들이 자기 일의 무게중심이 바뀌었음을 자각했다.
ChatGPT와 Copilot의 등장으로 자연어로 AI에게 일을 시킬 수 있게 되자, 「어떻게 물어야 좋은 답을 얻는가」가 문제가 되었다. 역할 설정, few-shot 예시, chain-of-thought 유도 — 단어 하나의 차이가 출력 품질을 좌우하므로 모든 단어를 정성껏 고른다. 마구(馬具)의 비유로 말하면 Prompt Engineering은 말에게 건네는 말이다. 왼쪽으로. 더 빨리. 꽃은 밟지 마라.
유효하지만 근본적 한계가 있다 — 일회성이고, 무(無)맥락이며, 재사용이 불가능하다. 좋은 프롬프트를 하나 써도 장면이 바뀌면 다시 써야 한다. 프롬프트 한 줄을 시스템으로 만들 수는 없다. 단순 과제에는 충분하지만, 실세계의 복잡한 프로젝트 앞에서 지시 한 줄은 아무것도 지탱하지 못한다.
2025년 6월, 두 사람이 거의 동시에 이 일에 이름을 붙였다.
Context Engineering은 말이 길을 보도록 돕는 모든 것이다. 지도, 이정표, 지형 정보. 어디로 가라고 말하는 대신 지형 전체를 보여 주고 스스로 경로를 판단하게 한다. 지시 한 줄 작성에서 정보 패키지 설계로 — 질적 변화다. 그러나 경계도 있다. 「AI에게 무엇을 보여 줄 것인가」는 해결했지만 「AI가 어떤 환경에서 구동되는가」는 해결하지 못했다. 실행할 도구, 준수할 제약, 자기 수정을 위한 피드백 루프가 없다면 완벽한 컨텍스트도 예쁜 참고자료 더미에 불과하다.
2026년 2월 5일, Mitchell Hashimoto(HashiCorp 공동창업자, Terraform 창시자, 현재 터미널 에뮬레이터 Ghostty 전업 개발. AI 기업 지분이 없어 관점의 중립성이 높다)가 블로그 「My AI Adoption Journey」를 발표했다. 글 서두에는 「이 글은 전부 손으로 직접 썼다」는 선언이 붙어 있다 — 2026년의 업계 분위기다. 그는 AI 회의론자에서 agent 헤비유저가 된 6단계 여정을 기술하며 다섯 번째 단계에서 새 개념을 도입했다. 정의는 지극히 소박하다.
6일 뒤인 2월 11일 OpenAI가 공식 블로그에서 같은 단어를 썼다. Martin Fowler 팀이 분석을 잇고 LangChain이 기술 해부를 냈다. 한 달 만에 「Harness Engineering」은 개인 블로그 용어에서 업계 합의로 격상되었다. Harness Engineering은 고삐·안장·울타리, 그리고 트랙 그 자체다. 말에게 하는 말(Prompt)도, 말이 보는 것(Context)도 아니라, 말에게 채우는 장비 일체에 트랙과 가드레일과 체크포인트를 더한 것 — 열 마리의 말을 동시에 안전하게 달리게 하는 시스템이다.
Prompt는 무엇을 묻는가를 관장하고, Context는 모델에게 무엇을 보여 주는가를 관장하며, Harness는 전체가 어떻게 돌아가는가를 관장한다. Context는 Harness의 부분집합이다. Harness는 여기에 제약·피드백·품질 검사를 더 관장한다. CLAUDE.md는 Context이고, hooks는 Harness의 제약층이며, CI 테스트는 Harness의 피드백층이다. 셋이 합쳐져야 완전한 하네스가 된다.
| 차원 | Prompt Engineering | Context Engineering | Harness Engineering |
|---|---|---|---|
| 시기 | 2022–2024 | 2025 | 2026 |
| 핵심 질문 | 어떻게 묻는가 | 어떤 정보를 주는가 | 시스템 전체가 어떻게 돌아가는가 |
| 마구 비유 | 말에게 하는 말 | 말이 길을 보도록 돕는 모든 것 | 고삐 + 안장 + 울타리 + 트랙 |
| 인간의 역할 | 질문자 | 큐레이터 | 아키텍트 |
| 재사용성 | 낮음 (매번 재작성) | 중간 (템플릿화) | 높음 (시스템화) |
| 명명자 | 커뮤니티 자생 | Karpathy / Tobi Lutke | Mitchell Hashimoto / OpenAI |
이름이 없어도 일은 굴러간다. 저자 花叔 자신도 2025년 8월 Claude Code 자동화 글쓰기 워크플로를 구축하며 라우터가 된 CLAUDE.md, 핵심 작업 전후로 검사를 주입하는 hooks, 모듈화를 위한 skills, 지식 베이스를 쌓았다 — 누가 이름을 알려 주지 않았는데도 하네스가 저절로 자라났다. Mitchell Hashimoto도 몇 달을 하고 나서야 이것이 하나의 부류의 일임을 깨닫고 스스로 이름을 붙였다.
이름이 생기자 상황이 달라졌다. LangChain은 「The Anatomy of an Agent Harness」로 구성 요소를 체계적으로 해부할 수 있게 되었고, Martin Fowler 팀은 3기둥 프레임(컨텍스트 엔지니어링·아키텍처 제약·엔트로피 관리)으로 OpenAI의 실천을 분석할 수 있게 되었다. 개념이 이름을 얻으면 논의되고, 해부되고, 가르칠 수 있게 된다.
맨몸의 모델은 하네스가 상태·도구 실행·피드백 루프·실행 가능한 제약을 부여한 뒤에야 agent가 된다. 모델은 엔진이고 하네스는 차체·핸들·브레이크·계기판이다. LangChain의 코딩 agent는 모델을 전혀 바꾸지 않고 시스템 프롬프트·도구 구성·미들웨어 훅만 수정하여 Terminal Bench 2.0 점수를 52.8% → 66.5%로 올렸고, 순위는 Top 30 → Top 5로 뛰었다. 같은 엔진에 차체만 바꿔도 성적은 하늘과 땅 차이다.
매 명명은 앞의 것을 뒤집는 것이 아니라 포함하며 한 겹 바깥으로 확장한다. 이것이 이번이 다르게 느껴지는 이유다. Prompt Engineering은 모델이 강해지면 필요 없어질 임시 기술로 여겨졌고, Context Engineering은 복잡한 프롬프트의 화려한 이름 정도로 치부되기도 했다. 그러나 Harness Engineering이 가리키는 것은 기교가 아니라 새로운 공학적 실천이다. DevOps가, 애자일이 실천에서 떠올라 이름을 얻고 전파 가능한 방법론이 되었듯이. 2009년 첫 DevOps Days 때도 이 단어가 10년 뒤 모든 기술 팀의 표준이 될 줄은 아무도 몰랐다. Harness Engineering은 지금 그 단계에 있다.
이야기는 세 번에서 멈추지 않았다. Andrej Karpathy는 2025년 말 손으로 코드를 쓰지 않기로 결정하고 AI agent 프로그래밍에 전면 의존했다. 자신의 AutoResearch 프로젝트 — 훈련 코드 630줄과 markdown 프롬프트 하나 — 로 이틀간 700회의 실험을 돌려 20개의 최적화 항목을 발견했다. 연구 흐름 전체의 하네스가 markdown 파일 하나였다. 그는 이 일에 Agentic Engineering이라는 이름을 붙였다 — AI를 지휘하는 것이 아니라 자율 구동 시스템을 설계한다는, agent의 자율성에 대한 강조다.
Context Engineering 진영도 멈추지 않았다. 동료 심사를 거친 한 논문이 9,649회의 실험을 수행해 명확한 결론을 냈다 — 컨텍스트의 체계적 관리가 프롬프트 한 줄을 공들여 다듬는 것보다 훨씬 유효하다. 2년 전 트위터의 개념이 이제 하드 데이터를 얻었다.
명명은 계속되고 매번 시야를 넓히지만 핵심 통찰은 변하지 않는다 — 병목은 모델이 아니라 모델이 구동되는 환경에 있다. Harness라 부르든 Agentic이라 부르든 가리키는 것은 같다. 방향은 이미 분명해졌다. 이어지는 Part 2에서 이 방향의 구체적 형태 — 하네스의 다섯 구성 요소 — 를 다룬다.