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

이 글은 하네스 엔지니어링의 본질을 이해하고, 한 경험 많은 개발자의 "나는 하네스를 도입하지 않기로 했다"는 선언을 겸허하게 받아들이며, 나 자신이 개발 중인 '글쓰기 하네스'를 중간점검하는 기록이다.

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

스킬(Skills)이란 무엇인가

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

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

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

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

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

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

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

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

그리고 특정 스킬이 반복적으로 낮은 점수를 받으면? 그 스킬을 '은퇴'시키고 새로운 버전으로 교체할 수 있다. 이것이 스킬의 은퇴 기능이다. 코드로 치면 deprecated API를 새 API로 마이그레이션하는 것과 같다.

그래서 하네스란 무엇인가

하네스 엔지니어링은 이 스킬 시스템을 더 큰 그림으로 확장한 것이다.

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

구성요소

설명

비유

Context Engineering

AI가 필요한 정보에 접근하도록 보장

직원에게 업무 매뉴얼을 주는 것

Architectural Constraints

제안이 아닌 기계적 강제

공장의 안전 가드레일

Entropy Management

주기적 정리와 검증

주기적인 코드 리뷰

쉽게 말하면, "모델은 CPU고 하네스는 OS다." 아무리 CPU가 강력해도 OS가 나쁘면 성능이 저하된다. 하네스는 AI 에이전트가 프로덕션 수준으로 안정적으로 작동하도록 감싸는 환경 전체를 의미한다.

스킬 2.0과 하네스의 관계

스킬과 하네스는 경쟁 관계가 아니다. 계층 관계다.

하네스 = CLAUDE.md(정적 컨텍스트) + Skills(동적 행동) + Constraints(제약) + Feedback Loop(피드백)

스킬이 개별 병사라면, 하네스는 그 병사들이 움직이는 전장의 전체 작전 계획이다.

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

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

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

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

하지만 어둠도 있다

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

토큰 낭비 문제

ETH Zurich 연구에 따르면, AI가 생성한 CLAUDE.md 파일은 "성능을 저하시키면서 토큰을 20% 이상 더 소비"했다. 에이전트가 컨텍스트 파일 지시를 처리하는 데 14~22%의 추론 토큰을 추가로 사용했지만, 해결률은 개선되지 않았다 (출처: HumanLayer Blog).

과도한 제약의 역효과

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

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):

핵심: 과도한 구조화는 에이전트의 자율성을 제한하고, 구현 복잡성이 'last-mile implementation'에서 반복적으로 실패로 이어진다. 하네스 엔지니어링도 같은 위험을 안고 있다.

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

원문의 핵심 주장

26년 경력의 IT 개발자이자 저자인 고승원 님은 페이스북에 "나는 바이브코딩에서 하네스 엔지니어링을 쓰지 않기로 했다"는 글을 올렸다 (출처: 고승원 님 페이스북).

"하네스 엔지니어링은 분명 좋다. 다만 나와 안 맞을 뿐이다."

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

가두리 양식장 비유

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

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

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

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

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

순서

문서

역할

1

brd.md (비즈니스 요구사항)

무엇을 만들 것인가

2

cps.md (맥락·문제·솔루션)

왜 만드는가

3

design.md (설계)

어떻게 구현할 것인가

4

plan.md (구현 계획)

언제 무엇을 할 것인가

5

todo.md (작업 목록)

지금 무엇을 하고 있는가

6

test.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. 그럼에도 하네스가 주는 가치가 있는가?

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

개선해야 할 지점

중간점검 결과 — 4가지 개선 과제

1. 평가 축의 유연화

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

2. 컨텍스트 로딩 최적화

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

3. 창의적 탈출구

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

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

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

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

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

시기

접근법

인간의 역할

2024

바이브 코딩

"이거 만들어줘" → 수락

2025

스펙 기반 개발

구조화된 명세 작성 → 검토

2026

하네스 엔지니어링

환경 설계 → 제약과 피드백 루프

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

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

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

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

"바이브코딩의 핵심은 AI를 얼마나 통제하느냐가 아니라, 인간의 통찰력이 담긴 설계를 AI와 얼마나 밀도 있게 공유하느냐에 달려 있다."

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

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

참고 자료