하네스 엔지니어링 중간점검 — 만능 해결사인가, 나에게 맞는 도구인가?

2026년 AI 코딩의 가장 뜨거운 키워드는 단연 '하네스 엔지니어링(Harness Engineering)'이다. 유튜브를 열면 하네스 극찬 영상이 쏟아지고, 커뮤니티에는 "하네스 없이 바이브 코딩은 무의미하다"는 글이 넘친다. 그런데 정작 Claude Code의 스킬(Skills) 2.0이 뭔지도 모르는 상태에서 갑자기 하네스라니 — 이 녀석은 대체 뭘 하는 녀석일까?

이 글은 하네스 엔지니어링의 본질을 이해하고, 한 경험 많은 개발자의 "나는 하네스를 도입하지 않기로 했다"는 선언을 겸허하게 받아들이며, 나 자신이 개발 중인 '글쓰기 하네스'를 중간점검하는 기록이다. Claude Code로 바이브 코딩을 하고 있거나, AI 에이전트의 품질 관리 방법을 고민하는 개발자라면 이 여정이 참고가 될 것이다.

1. 스킬 2.0도 모르는데 갑자기 하네스가 등장 — 이 녀석은 뭐 하는 녀석이지?

스킬(Skills)이란 무엇인가

Claude Code에서 스킬이란 SKILL.md 파일에 정의된 '프로그래밍 가능한 에이전트 행동 단위'다. 슬래시 커맨드(/commit, /review-pr 등)로 호출하면 해당 스킬이 자체 컨텍스트 윈도우에서 실행된다. 즉, AI에게 "이 상황에서는 이렇게 행동해라"고 가르치는 행동 명세서(behavioral specification)다.

2026년 초 Skills 2.0(정확히는 2.1.3)에서 중요한 변화가 일어났다. 슬래시 커맨드와 스킬이 완전히 통합된 것이다. 이전에는 "슬래시 커맨드 ≠ 스킬"이었지만, 이제 "슬래시 커맨드 = 스킬 + user-invocable: true"로 멘탈 모델이 단일화되었다.

스킬의 핵심 기능은 다음과 같다:

• 격리된 서브에이전트: 자체 컨텍스트 윈도우에서 실행되어 메인 대화를 오염시키지 않는다

• 도구 제한(allowed-tools): 특정 스킬이 사용할 수 있는 도구를 명시적으로 제한한다

• 모델 오버라이드: 스킬별로 다른 AI 모델을 지정할 수 있다

스킬의 은퇴 기능과 개선 기능

여기서 주목할 것은 스킬이 갖는 자기 평가(eval) 메커니즘이다. 스킬은 단순히 실행만 하는 게 아니라, 실행 결과를 평가하고, 평가 결과에 따라 행동을 개선할 수 있다.

예를 들어 콘텐츠를 작성하는 스킬이 있다고 하자. 이 스킬은:

1. 작성 → 2. 평가(eval) → 3. 점수가 낮으면 재작성 → 4. 점수가 충분하면 발행

이 루프가 바로 'Generator-Evaluator 아키텍처'의 원형이다. GAN(Generative Adversarial Network)에서 영감을 받은 구조로, 생성과 평가를 분리함으로써 "자기 평가의 맹점(self-evaluation blindness)"을 해결한다.

그리고 특정 스킬이 반복적으로 낮은 점수를 받으면?

• LLM의 발전또는 AI툴발전으로 더이상 쓸모가 없어짐으로 측정 -  이제 웬만한 표준 웹개발 프레임워크는 그것을 잘 사용하는 입문서 정도(고급까지가능) 는 구구절절 이야기 안해도 되는것처럼

그 스킬을 '은퇴'시키고  더이상 필요없지는 스킬을 정리하는것이다. ( 아직은 홍수처럼 더 생겨날테지만 ) 
개인적으로 스킬2,0의 핵심기능중 가장 높이평가하는 부분은 Eval의 평가작동이 은퇴 시점감지하고 없앨준비도 초반에 하란 이야기로 해석함

그래서 하네스란 무엇인가 — IT 세계의 동물 이야기

하네스 엔지니어링을 이해하려면, IT 세계가 왜 이렇게 동물을 사랑하는지부터 보면 쉽다.

하네스 엔지니어링은 이 스킬 시스템을 더 큰 그림으로 확장한 것이다. 동물원 관리자(ZooKeeper)가 우리를 만들고, 목장 주인(Rancher)이 목초지를 조성하듯, 하네스 엔지니어는 AI가 올바른 방향으로 달릴 수 있는 환경과 방향을 설계한다.

OpenAI의 정의를 빌리면, 하네스 엔지니어링은 다음 세 가지를 설계하는 분야다:

쉽게 말하면, "모델은 CPU고 하네스는 OS다." 아무리 CPU가 강력해도 OS가 나쁘면 성능이 저하된다. 마구(馬具)의 비유로 돌아오면 — AI는 강력한 말이고, 엔지니어의 역할은 코드를 직접 짜는 것이 아니라, 말이 올바른 방향으로 힘을 쓸 수 있도록 마구를 설계하는 것이다.

스킬 2.0과 하네스의 관계 — 라이브러리, 툴킷, 프레임워크

스킬과 하네스는 경쟁 관계가 아니다. 웹 개발에 익숙한 개발자라면 이 비유가 와닿을 것이다:

CLAUDE.md는 하네스와 유사한 역할을 하지만, 하네스는 여기서 한 단계 더 나아간다. harness/knowledge/(도메인 지식), harness/agents/(에이전트 행동 정의), harness/engine/(워크플로우 규칙) 같은 구조화된 레이어로 분리하여, 웹 프레임워크의 MVC 패턴처럼 관심사를 분리한다.

2. 하네스는 우리에게 도움을 줄 것인가? 고통을 줄 것인가?

하네스가 보여준 놀라운 성과

하네스 엔지니어링의 효과를 보여주는 수치들은 확실히 인상적이다:

• LangChain: 모델은 동일하게 두고 하네스만 변경했더니 벤치마크가 52.8% → 66.5%로 상승, Top 30에서 Top 5로 진입했다 (출처: Anthropic Engineering Blog)

• OpenAI: 5개월간 100만 줄 이상의 앱을 인간 코드 0줄로 구축, "인간 팀 대비 약 1/10 시간" (출처: OpenAI - Harness Engineering)

• Anthropic의 Feature List 패턴: 200개 이상의 피처를 JSON으로 정의하고, AI가 모두 통과할 때까지 반복 실행

이런 수치만 보면 하네스를 도입하지 않을 이유가 없어 보인다.

하지만 어둠도 있다

반대편의 데이터도 간과할 수 없다:

과도한 제약의 역효과

Vercel v0 팀은 사용 가능한 도구의 80%를 제거했더니 측정 가능한 수준으로 더 나은 결과를 얻었다. "더 많은 도구는 더 많은 혼란, 더 많은 잘못된 도구 선택, 더 많은 실패한 작업"을 의미했다 (출처: HumanLayer - Skill Issue).

AI 코드 품질 통계

2025 Qodo 보고서에 따르면, AI 코딩 도구를 하루 여러 번 사용하는 개발자 중 51%가 더 많은 코드 품질 문제를, 53%가 더 많은 보안 취약점을 보고했다. CodeRabbit 분석에서는 AI 생성 코드가 인간 코드 대비 1.7배 더 많은 이슈를 생성했다 (출처: Qodo Report, CodeRabbit Report).

Martin Fowler의 사이트에서 Birgitta Boeckeler(Thoughtworks)는 OpenAI의 하네스 접근법에서 "기능과 동작의 검증이 부재"함을 지적했다 (출처: Martin Fowler - Harness Engineering).

팔란티어의 온톨로지 — 구조화의 함정

하네스 엔지니어링의 '과도한 구조화' 문제를 이해하려면 팔란티어(Palantir)의 온톨로지(Ontology)를 살펴볼 필요가 있다.

팔란티어의 온톨로지는 실세계 대응물(물리적 자산, 고객 주문, 금융 거래)과 연결되는 운영 레이어다. AI 에이전트가 운영 변경을 제안하면 Git의 브랜칭처럼 존재하고, 인간이 승인하면 머지된다. 이론적으로 완벽해 보이는 이 구조에 대해 HN(Hacker News) 커뮤니티에서는 날카로운 비판이 쏟아졌다 (출처: HN Discussion):

• "이건 그냥 뷰, 물리화된 뷰, UDF, 저장 프로시저를 팬시한 기업 용어로 포장한 것"

• "OWL(Web Ontology Language)은 전이적 속성, 합집합, 카디널리티를 검증 가능한 결정 가능성 보장으로 지원하지만 Palantir 모델은 이를 결여"

• "고객을 Palantir 생태계에 종속시키고 유연성을 희생"

3. "나는 하네스를 도입하지 않기로 했다" — 겸허한 분석

원문의 핵심 주장

고승원 님은 페이스북에 "나는 바이브코딩에서 하네스 엔지니어링을 쓰지 않기로 했다"는 글을 올렸다 (출처: 고승원 님 페이스북).

이 한 문장에 핵심이 담겨 있다. 하네스가 나쁘다는 것이 아니라, 자신의 맥락에서 최적이 아니라는 판단이다.

가두리 양식장 비유

고승원 님은 하네스를 '가두리 양식장'에 비유했다. AI를 촘촘한 테스트 그물 안에 가두고, "이 그물을 벗어나지 말고 통과할 때까지 무한 반복하라"고 명령하는 방식이라는 것이다.

이 비유가 날카로운 이유가 있다. 앞서 살펴본 데이터가 이를 뒷받침한다:

• ETH Zurich의 "토큰은 더 쓰면서 해결률은 개선 안 됨" 발견

• Vercel의 "도구 80%를 제거했더니 오히려 더 잘 됨" 사례

• Martin Fowler 사이트의 "기능 검증 부재" 지적

품질의 역설: 테스트를 통과하는 것과 우아한 설계를 만드는 것은 같지 않다. 하네스가 '오답을 줄이는 소거법'에는 탁월하지만, '가두리 밖의 더 넓은 바다'에 있는 창의적 해결책을 AI에게 허용하지 않을 수 있다.

6개 문서 기반 워크플로우 — 대안의 설계

고승원 님이 제안하는 대안은 '6개 문서(md) 기반 워크플로우'다:

이 문서들을 CLAUDE.md가 앵커로 묶어주면, AI는 "가두리에 갇히지 않고도 프로젝트 핵심 설계 원칙과 자신의 위치를 명확히 이해"한다.

흥미롭게도 이 접근법은 GitHub와 Thoughtworks Technology Radar에 등재된 'Spec-Driven Development'와 정확히 겹친다 (출처: GitHub Blog, Thoughtworks Radar). 26년 현장 경험에서 우러난 판단이 업계의 최신 방법론과 동기화된 셈이다.

이 판단을 내리려면 어떤 경험이 필요한가

"하네스를 도입하지 않겠다"는 결정은 아무나 내릴 수 없다. 이 판단이 설득력을 가지는 이유는:

1. 충분한 실험: 본인이 직접 하네스 엔지니어링을 "다양한 실험을 진행"했다고 밝혔다

2. 비교 대상의 존재: 26년간 축적한 문서 기반 워크플로우라는 검증된 대안이 있다

3. 양날의 칼 인식: "하네스는 분명 좋다"고 인정한 후에 "나와 안 맞다"고 판단했다

하네스를 써보지 않고 부정하는 것과, 써본 후에 자신의 맥락에서 최적이 아니라고 판단하는 것은 전혀 다른 무게를 가진다.

4. 나의 글쓰기 하네스 — 중간점검

내가 만들고 있는 하네스

나는 현재 개인 테크니컬 라이팅용 하네스를 개발 중이다. 코딩이 아닌 '글쓰기'에 하네스를 적용하고 있다. 구조는 다음과 같다:

harness/
├── knowledge/    ← 글쓰기 기법, 독자 분석, 출처 품질 기준
├── agents/       ← 리서처, 작성자, 평가자 에이전트
└── engine/       ← 워크플로우, RPG 레벨 시스템, 로그 관리

이 하네스는 6가지 콘텐츠 유형(Memorizer, Confluence, 위키, 로컬 문서 등)에 대해 idle → researching → writing → evaluating → publishing → recording 상태 흐름을 따른다. 5축 평가(외부 자료 품질, 비개발자 접근성, 독자 명확성, 구조 완결성, 사실 정확성)로 품질을 관리하고, 70점 이상이어야 발행된다.

4일간 18편의 글을 작성했고, 평균 84.7점, A등급 비율 61%를 기록했다. 겉으로 보면 잘 돌아가고 있다.

비평을 받아들이며 — 나의 하네스도 가두리인가?

고승원 님의 비평을 거울삼아 자문해본다.

Q1. 나의 하네스도 '소거법'에 갇혀 있는가?

솔직히 말하면, 일부분 그렇다. 5축 평가에서 70점 이상을 맞추기 위해 글이 '평가 기준에 맞추는 방향'으로 수렴할 위험이 있다. 참신한 구조의 글, 실험적인 문체의 글이 평가 체계에 맞지 않아 걸러질 수 있다.

Q2. 토큰 낭비가 발생하고 있는가?

발생한다. 매 글마다 harness/knowledge/ 파일 3개, agents/ 파일 3개, engine/ 워크플로우 파일을 로드한다. ETH Zurich가 지적한 "컨텍스트 파일 처리에 추론 토큰 14~22% 추가 소비" 문제가 나에게도 해당된다.

Q3. 그럼에도 하네스가 주는 가치가 있는가?

있다. 그것도 명확하게. 글쓰기에서 하네스의 가치는 코딩과 다르다:

• 일관된 품질 유지: 5축 평가 없이는 "이번에는 출처를 덜 찾아도 괜찮겠지"라는 게으름이 끼어든다

• 성장 추적: RPG 레벨 시스템이 없었다면 18편을 연속으로 쓸 동기가 부족했을 것이다

• 워크플로우 표준화: 매번 "웹 조사부터 할까, 바로 쓸까" 고민하지 않아도 된다

개선해야 할 지점

1. 평가 축의 유연화

현재 5축은 모든 글에 동일하게 적용된다. 글의 유형(기술 튜토리얼 vs 에세이 vs 분석 보고서)에 따라 가중치를 달리 해야 한다. 가두리의 그물 간격을 글마다 조절하는 것이다.

2. 컨텍스트 로딩 최적화

매번 전체 knowledge/ 파일을 로드하는 대신, 글의 유형에 따라 필요한 파일만 선별 로드하는 '선택적 컨텍스트' 메커니즘이 필요하다.

3. 창의적 탈출구

평가 루프에 "이 글은 실험적이므로 특정 축 평가를 면제한다"는 옵션을 만들어야 한다. 가두리 밖으로 나갈 수 있는 문을 열어두는 것이다.

4. 6개 문서 워크플로우와의 접목

고승원 님의 brd→cps→design→plan→todo→test 흐름은 코딩뿐 아니라 글쓰기에도 적용 가능하다. 현재 나의 하네스에는 'CPS(왜 이 글을 쓰는가)'에 해당하는 단계가 약하다.

5. 마무리 — 당신에게 하네스는 필요한가?

패러다임의 진화를 정리하면 이렇다:

하네스 엔지니어링은 분명 강력하다. LangChain의 벤치마크 점프, OpenAI의 100만 줄 앱, Anthropic의 Feature List 패턴 — 이런 성과를 무시할 수 없다.

그러나 동시에 "가두리 양식장"이라는 비유도 유효하다. ETH Zurich의 토큰 낭비 연구, Vercel의 도구 감축 실험, Martin Fowler 사이트의 검증 부재 지적 — 이런 경고도 무시할 수 없다.

나 자신의 글쓰기 하네스를 4일간 운영하면서 느낀 것은 이것이다: 하네스는 만능 해결사가 아니다. '나에게 맞느냐'가 핵심이다.

• 코딩에서: 반복적 테스트 검증이 중요한 프로덕션 코드 → 하네스가 강력한 선택

• 코딩에서: 설계 철학과 문서 중심 협업이 핵심 → 6개 문서 워크플로우가 더 맞을 수 있음

• 글쓰기에서: 일관된 품질과 성장 추적이 필요 → 하네스의 평가 루프가 유용

• 글쓰기에서: 실험적이고 자유로운 글쓰기 → 하네스가 오히려 족쇄

고승원 님의 말을 빌려 결론을 맺는다:

그래서 묻는다 — 당신에게 하네스는 가두리인가, 항해의 장비인가?

이 질문에 대한 답은 당신만이 알고 있다.

참고 자료

• 클러스터는 목장이다 — ZooKeeper, Rancher, 그리고 AI 마구(Harness) — IT 세계의 동물 비유로 하네스 엔지니어링을 이해하는 선행 글

• Anthropic - Effective Harnesses for Long-Running Agents

• OpenAI - Harness Engineering

• Martin Fowler - Harness Engineering

• HumanLayer - Skill Issue: Harness Engineering for Coding Agents

• Qodo - State of AI Code Quality 2025

• CodeRabbit - AI vs Human Code Generation Report

• GitHub Blog - Spec-Driven Development

• Thoughtworks - Spec-Driven Development (Technology Radar)

• 고승원 님 페이스북 — "나는 바이브코딩에서 하네스 엔지니어링을 쓰지 않기로 했다"

• HN Discussion - Palantir Ontology

글작성 하네스의 연관아티컬

• 클러스터는 목장이다 — ZooKeeper, Rancher, 그리고 AI 마구(Harness)
• AI에게 마구를 씌우다 — 하네스 엔지니어링, 코드를 넘어 글쓰기까지
• 하네스 엔지니어링 — 민호의 하네스로 배우는 AI 팀 설계

웹애니 이펙트  전용으로 디벨롭중인 이 하네스의 파생 브랜치

• 하네스로 애니메이션 스킬업 — WPF에서 Pencil, 그리고 웹까지

보너스 : 이 라이팅은  글작성 하네스를 통해 진행되었으며 - 후속 하네스평가 첨부

• 하네스 평가편 — tech-writer 5축 평가 및 개선 기록