하네스(Harness)는 왜 한국형 팀에 잘 안 맞는가 — 오픈 유어 코드, 그 어려운 한 마디

1. 하네스(Harness)는 무엇인가

미첼 하시모토(Mitchell Hashimoto)가 처음 던진 질문은 단순했다. "왜 AI 코딩 에이전트는 같은 실수를 반복하는가?" 프롬프트에 "이렇게 하지 마라"고 백 번을 적어도, 모델은 다음 세션에서 똑같은 곳에서 넘어진다. 그래서 그는 결론을 내렸다 — 실수가 반복될 수 없도록 환경 자체를 엔지니어링해야 한다. 이것이 하네스 엔지니어링의 출발점이다.

비유는 야생마와 마구다. 야생마(Claude, GPT, Gemini)는 혼자 두면 어디로 튈지 모른다. 마구(Harness)를 채우면 말의 힘은 줄어드는 게 아니라, 트랙 안에서 올바른 방향으로 집중된다. 마구는 고삐, 안장, 트랙, 코치, 경기 기록까지 포함한다.

OpenAI는 2026년 2월 공식 블로그에서 한 가지 사실을 공개했다 — Codex 팀이 5개월 동안 100만 줄 규모의 프로덕션 시스템을 구축했고, 사람이 직접 쓴 코드는 0줄이었다. 엔지니어 3명이 하루 평균 3.5개의 PR을 머지하면서. 비결은 모델이 아니라 시스템이었다. 저장소 구조, AGENTS.md, 의존성 레이어(Types→Config→Repo→Service→Runtime→UI), 린터, CI 게이트, 피드백 루프 — 그 전체가 하네스다.

LangChain의 사례는 더 직설적이다. 모델을 바꾸지 않고 하네스만 개선하여 코딩 에이전트 벤치마크 SWE-bench에서 52.8% → 66.5%로, 30위권에서 5위권으로 뛰어올랐다.

2. 프롬프트 엔지니어, 컨텍스트 엔지니어, 그리고 스킬 2.0 — 그 다음

지난 2년 동안 우리는 세 번의 이름표를 거쳤다.

이 세 가지의 공통점을 한 번 보자. 모두 "개인이 AI를 얼마나 잘 다루느냐"의 이야기다. 누가 더 좋은 프롬프트를 쓰느냐, 누가 더 영리한 스킬을 만드느냐, 누구의 컨텍스트가 더 정교하냐 — 결국 개인 역량의 게임이다.

하네스는 거기서 한 발 더 나간다. 하네스는 개인이 아니라 팀의 작업 환경 자체를 설계한다. AGENTS.md는 신규 입사자가 첫날 읽는 온보딩 문서이며, 훅(Hook)은 코드 저장 전 자동으로 작동하는 안전 시스템이고, 가비지 컬렉션 에이전트는 주기적으로 팀의 코드베이스를 청소한다. 누가 어느 자리에 앉아도 같은 품질이 나와야 한다.

그리고 결정적으로 — 하네스는 모든 활동을 로그로 남긴다. 사소한 PR 하나, 평가 점수 1점의 변화, 반복된 실패 패턴 하나하나가 다음 회차의 학습 재료가 된다. BloomLabs Content Harness가 12회 실행을 넘어 이벤트 소싱 스냅샷 패턴까지 도입한 이유가 이것이다 — 로그가 너무 쌓여서.

여기서 첫 번째 질문이 떨어진다. "우리 팀은 사소한 업무 하나하나를 정말 로그로 남길 준비가 되어 있는가?"

3. 우리는 오픈마인드인가 — 컨플루언스와 노션 사이의 간극

한국 IT 조직에서 자주 보이는 풍경 하나를 그려보자. 회사는 수천만 원짜리 Atlassian Confluence 라이선스를 도입한다. 그런데 정작 시니어 개발자의 머릿속 도메인 지식은 그 사람의 개인 노션에 정리되어 있다. 또는 머릿속에만 있다.

DDD(Domain-Driven Design)에서 에릭 에반스가 강조한 가장 중요한 자산은 유비쿼터스 언어(Ubiquitous Language)다. 도메인 전문가와 개발자가 같은 단어, 같은 뉘앙스로 도메인을 이야기할 수 있어야 한다는 것. 그런데 한국 조직에서 이 유비쿼터스 언어는 어디에 있는가? 컨플루언스에는 6개월 전 파워포인트로 만든 아키텍처 다이어그램의 PNG 캡처만 있고, 진짜 도메인의 뉘앙스 — "이 필드는 왜 이렇게 생겼는가", "이 예외 케이스는 누가 발견했는가", "이 비즈니스 룰은 어느 회의에서 결정됐는가" — 는 그 일을 처음 한 사람의 머릿속에 있다.

그리고 그 사람이 퇴사하면, 도메인의 정수는 우리 회사 자산이 아닌 것이 된다.

하네스를 도입하려고 도메인 지식을 보강하려는 순간, 우리는 깨닫는다 — 채워야 할 빈자리는 너무 많고, 그 자리에 있어야 할 사람은 이미 다른 회사에서 일하고 있다.

문제는 "퇴사한 사람"에 있지 않다. 지금부터 새로 생기는 도메인 지식조차 회사의 공유 공간이 아닌 개인의 노션, 개인의 즐겨찾기, 개인의 머릿속에 쌓이고 있다는 점이다.

4. 왜 이런 문제가 생기는가 — 인수인계와 온보딩의 기묘한 풍경

4.1 인수인계는 퇴사 직전에 시작된다

한국 조직의 인수인계 문서를 떠올려 보자. 그것은 언제 작성되는가? 퇴사 통보 후, 마지막 2주 동안. 그 전까지 그 사람의 일은 어디에도 명문화되어 있지 않다.

외국 사례는 어떨까. 호주에서 일했던 한 개발자의 증언이다. "팀장이 DDD를 도입하자고 했다. 팀원들은 누가 시키지 않았는데도 퇴근 후에 자기가 발견한 도메인 인사이트를 슬랙 채널에 공유하기 시작했다. 이유는 단 하나 — 챔피언(Champion)이 되기 위해서. 보상은 없다. 단지 팀이 인정하는 특정 분야의 자발적 전문가라는 타이틀, 그뿐이다."

이 자발적 공유 문화의 정체는 무엇인가? "내가 이걸 해냈다"고 매일매일 시끄럽게 알리는 것이 미덕인 문화다. 한국식 유교 정서는 정반대다. 깡통처럼 요란하면 안 된다. 묵묵히 일하는 사람이 인정받는다. 그래서 자기가 무엇을 알고 있는지 알리지 않는 것이 미덕이다.

이 두 정서의 차이가 만드는 결과는 잔혹하다. 하네스가 작동하려면 "지금 내가 무엇을 하고 있는지"를 매일 로그로 남기고 소리쳐야 하는데, 우리는 그것을 부끄러워하도록 사회화되었다.

4.2 온보딩 — 한 달 vs 하루

또 다른 차이. 호주의 어느 회사는 입사 첫날 태스크가 떨어졌다. 한국에서는 적어도 1주, 길게는 한 달 동안 "온보딩 기간"이라며 진짜 일을 주지 않는다.

겉보기에는 한국이 친절해 보인다. 그러나 본질은 정반대다. 온보딩 문서가 없기 때문에, 가장 바쁜 시니어가 자기가 시간 날 때마다 신입에게 하나둘 일을 알려주는 식으로 굴러간다. 한 달 동안 일을 안 시키는 게 관례인 이유는, 그 한 달이 시니어가 짬짬이 가르치기에 필요한 시간이기 때문이다.

외국은 다르다. 첫날 계정 발급부터 개발 환경 세팅, 첫 PR까지 하루 안에 끝낸다. 신입이 똑똑해서가 아니다. 플랫폼 엔지니어링이 잘 되어 있기 때문이다. AGENTS.md 같은 문서, 리포지토리 자체에 박혀 있는 셋업 스크립트, 표준화된 개발 컨테이너, 자동 생성되는 권한 — 이 모든 것이 하네스의 일부다.

4.3 폐쇄망과 제로 트러스트 — "운영 DB 권한이 없으면 1도 못 한다"

한국 조직의 또 다른 특징. 운영 DB 접근 권한이 없으면 개발이 1도 안 된다. 폐쇄망 안에서, VPN을 통해, 사무실 데스크톱에서만 일할 수 있다.

글로벌 회사들은 어떻게 일하는가? 세계 어디에서든 노트북만 있으면 일할 수 있다. 운영 DB에 접근할 필요가 없도록 시스템이 설계되어 있기 때문이다 — 충분한 모킹, 충분한 스테이징, 충분한 옵저버빌리티, 충분한 플랫폼 엔지니어링이 있다.

흥미로운 통계: 보안 사고의 대부분은 권한을 가진 폐쇄망 내부에서 발생한다. 제로 트러스트(Zero Trust) 관점에서 외부망 작업이 더 위험하다는 사례는 거의 없다. 한국 조직이 보안을 이유로 폐쇄망을 고집하는 동안, 그 폐쇄망 안에서 정말로 도메인을 아는 사람은 점점 더 소수가 되고, 그 소수는 점점 더 강력한 협상권을 갖게 된다.

4.4 회의의 일상 살펴보기 — 침묵이 미덕인 나라, 침묵이 사고인 나라

또 하나의 결정적인 차이. 회의실에서 누가 말하는가.

한국의 도메인 미팅 풍경을 그려보자. 10명이 모였다. 그 중 영향력 있는 1~2명이 회의 시간의 80%를 차지한다. 나머지 5명은 한 마디도 하지 않고 회의가 끝난다. 그리고 아무도 그것을 이상하게 여기지 않는다. 오히려 영향력 있는 사람이 말할 때 침묵해 주는 것이 한국 회의실의 미덕이다.

글로벌 회의실은 정반대다. 어떤 글로벌 팀에서는 — 회의가 끝났는데 한 명이라도 발언하지 않은 사람이 있으면, 그 회의는 "잘못된 회의"로 간주된다. 이유는 단순하다. "그 사람을 회의에 부른 이상, 그 사람의 시간을 썼다. 그런데 그 사람의 의견을 듣지 않았다면, 우리는 전문가 한 명의 시간을 그냥 낭비한 것이다."

한 개발자의 일화. 글로벌 팀에서 회의 한 번을 그냥 침묵으로 흘려보냈더니, 회의가 끝난 직후 동료가 다가와 진지하게 물었다. "오늘 무슨 집안일이라도 있었어? 평소답지 않게 한 마디도 안 했길래 걱정돼서." 그 회사에서는 침묵 자체가 신호로 읽힌다 — 평소에 의견이 있던 사람이 갑자기 말이 없다면, 그건 회의가 잘못된 것이거나 그 사람에게 무슨 일이 생긴 것이다.

한국은 다르다. 영향력 있는 사람의 의견에 반대 의견을 내는 사람은 종종 "지적"을 받는다. 반대를 너무 자주 하면 — 설령 그 반대가 옳더라도 — 핵심 세력권의 왕따가 될 수도 있다. "이것은 일반화의 오류이고, 내 경험만 그런 것이라면 겸허히 받아들이겠다"고 말하고 싶지만, 한국 IT 조직에서 이 패턴을 한 번도 못 본 사람이 얼마나 될까.

이 차이가 하네스와 무슨 상관인가? 아주 큰 상관이 있다. 하네스는 "모든 활동을 로그로 남기고 평가한다"는 정신 위에서 작동한다. 회의에서 5명이 침묵으로 끝낸 회사는, 그 5명의 머릿속 인사이트도 절대 로그로 남지 않는다. AGENTS.md에도, 컨플루언스에도, Memorizer에도 — 어디에도 남지 않는다. 그 5명은 자기 의견을 말하지 않는 것이 미덕이라고 학습했기 때문이다.

회의실에서 침묵하도록 사회화된 사람에게 "당신의 도메인 지식을 매일 로그로 남기세요"라고 말하는 것은, 30년 동안 발언을 참아온 사람에게 갑자기 마이크를 쥐어주는 것과 같다. 마이크가 무거운 게 아니라, 마이크를 잡는 행위 자체가 학습되지 않았다.

5. 도메인 지식의 부채 — 도메인은 곧 밥그릇

5.1 현대차 노조의 아틀라스 거부 사건

2026년 1월, 현대자동차 노조는 공식적으로 선언했다. "노사 합의 없이는 휴머노이드 로봇 1대도 현장에 들여올 수 없다." 대상은 56자유도 관절과 360도 카메라를 갖춘 아틀라스(Atlas) 로봇이었다. 2028년 조지아 메타플랜트(HMGMA)에 배치될 예정이었다.

이 사건의 본질은 무엇인가? 표면적으로는 일자리 보호다. 그러나 산업계의 분석은 한 단계 더 들어간다 — 노조 조직률이 13%까지 떨어지고 조합원 수가 4만 명 아래로 내려간 상황에서, 로봇 거부는 노조의 생존 전략이라는 것이다.

이 기사를 도메인 지식의 관점에서 다시 읽어보자. 자동차 조립 라인의 노하우, 그 도메인을 가진 사람들이 자기 도메인이 기계로 대체되는 것을 거부한다. 이것은 AI와 무관한 이야기가 아니다. 자기만이 아는 지식을 누군가(혹은 무언가)에게 전파해서, 자신이 아니어도 일이 굴러가게 만드는 것에 대한 본능적 거부 반응이다.

5.2 회사도 같은 본능을 가졌다

한 가지 불편한 진실. 이 본능은 노동자의 본능만이 아니다. 회사 자체도 같은 본능을 가졌다. 회사가 마지막에 남기고 싶어 하는 사람은 누구인가? 오픈 마인드로 자기 지식을 다 공유한 사람인가, 아니면 지금 굴러가고 있는 레거시를 자기만 굴릴 줄 아는 사람인가?

답은 정해져 있다. 정리해고 명단이 만들어질 때, 살아남는 사람은 후자다. 즉 한국 조직 전체가 "내가 아니면 안 돌아가는 일을 만들어야 살아남는다"는 게임을 학습한 결과로 지금의 모습이 되었다.

이 학습된 생존 전략 위에서 하네스가 외치는 메시지를 다시 읽어보자.

6. 마치며 — 마구는 가벼운데, 가죽끈은 무겁다

하네스(Harness)는 단어 그대로는 "마구"다. 그러나 그 마구를 자세히 들여다보면 — 가죽끈 한 가닥마다 로그, 평가, 공유, 오픈 마인드가 새겨져 있다. 마구가 작동하려면 그 가죽끈이 팽팽해야 한다. 그리고 그 가죽끈은 나만 할 수 있는 업무 지식을 매일 로그로 남기는 행위 위에서만 팽팽해진다.

이것은 AI 시대만의 문제가 아니다. AI가 등장하기 훨씬 전에도 글로벌 오픈마인드 팀은 존재했다 — DDD 챔피언 문화, 트렁크 기반 개발, 페어 프로그래밍, 모브 프로그래밍, 그리고 무수한 오픈소스 프로젝트들. 그들은 AI 없이도 "내가 자리를 비웠을 때 일이 멈추지 않는 팀"을 만들어냈다.

DDD의 본래 정신이 무엇이었는지 다시 떠올려 보자. 에릭 에반스는 DDD를 단순한 객체 설계 패턴으로 정의하지 않았다. 그가 강조한 것은 "도메인의 모름을 알아가는 협력적 탐험"이다. 애자일이 실패한 가장 큰 이유 중 하나는 — 작업의 완료(Done)만 있고, 왜 그 작업을 해야 했는지를 기록한 문서가 어디에도 남지 않았다는 점이다. 대시보드의 카드는 옆 칸으로 옮겨졌지만, 그 카드 뒤의 도메인 지식은 누구의 머릿속에도 명시적으로 들어가지 않았다.

하네스는 본질적으로 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 클로드 스킬 2.0 같은 개인 역량 강화의 도구가 아니다. 하네스의 큰 버전은 업무의 경계를 벗어나 업무의 공유를 원한다. 같은 도메인 지식을 모든 팀원이 동일한 수준으로 가지고 있다는 것을 전제하고, 그것을 강화하고 학습하는 것이 목적이다.

그래서 마지막 질문은, 사실 AI에 관한 것이 아니다.

답을 정하지 못해도 괜찮다. 다만 — 답을 정하기 전까지, 한국 조직에서 하네스는 마구가 아니라 헐거운 끈으로 남을 것이다. AI 네이티브 전환을 외치는 모든 회사가, 사실은 자기 조직의 가장 본능적인 생존 전략과 정면으로 충돌하고 있다는 점만큼은 부정하기 어렵다.

---

참고 자료

• OpenAI, Harness engineering: leveraging Codex in an agent-first world (2026.02)

• OpenAI, Unrolling the Codex agent loop

• Martin Fowler, Harness engineering for coding agent users

• Martin Fowler, Ubiquitous Language

• HumanLayer, Skill Issue: Harness Engineering for Coding Agents

• InfoQ, OpenAI Introduces Harness Engineering

• 문화일보, 로봇 막아선 현대차 노조 "합의 없이 1대도 안 돼"

• 시사저널, 현대차 노조 "합의 없이 로봇 1대도 현장에 못 들어와"

• RealKM, Why do employees hoard their knowledge

• 웹노리 위키, 하네스 엔지니어링 관련 페이지

• 웹노리 위키, 하네스/스킬2.0 관련 페이지