Page History
| Table of Contents | ||||
|---|---|---|---|---|
|
| Note |
|---|
이 글은 2026년 4월 기준으로 작성되었습니다. AI 코딩 도구와 하네스 엔지니어링은 빠르게 변화하는 분야이므로, 참조된 도구 버전과 수치는 해당 시점 기준입니다. |
...
스킬(Skills)이란 무엇인가
Claude Code에서 스킬이란 SKILL.md 파일에 정의된 '프로그래밍 가능한 에이전트 행동 단위'다단순한 프롬프트 템플릿이 아니다. 스스로 테스트하고 수정하며 발전하는 작업 시스템이다 (출처: 비바코딩 — Claude Skill 2.0 출시). 슬래시 커맨드(/commit, /review-pr 등)로 호출하면 해당 스킬이 자체 컨텍스트 윈도우에서 실행된다. 즉, AI에게 "이 상황에서는 이렇게 행동해라"고 가르치는 행동 명세서(behavioral specification)다.
하나의 스킬 폴더는 3가지 핵심 요소로 구성된다:
요소 | 역할 | 비유 |
|---|---|---|
SKILL.md | AI에게 전달하는 업무 매뉴얼. 이름, 단계별 프로세스, 예시 출력, 규칙과 제한 조건을 정의 | 신입 직원에게 주는 SOP 문서 |
참조 자료 | 템플릿, 데이터, 예시 결과물 등 스킬이 참고할 파일들 | SOP와 함께 주는 샘플 포트폴리오 |
스크립트 | 데이터 처리 및 자동화 코드 (Python, Node.js 등) | 직원이 쓰는 업무 도구 |
2026년 초 Skills 2.0(정확히는 2.1.3)에서 0에서 중요한 변화가 일어났다. 슬래시 커맨드와 스킬이 완전히 통합된 것이다. 이전에는 "슬래시 커맨드 ≠ 스킬"이었지만, 이제 "통합되어, 슬래시 커맨드 = 스킬 + user-invocable: true"로 멘탈 모델이 단일화되었다.
스킬의 핵심 기능은 다음과 같다:
격리된 서브에이전트: 자체 컨텍스트 윈도우에서 실행되어 메인 대화를 오염시키지 않는다
도구 제한(allowed-tools): 특정 스킬이 사용할 수 있는 도구를 명시적으로 제한한다
모델 오버라이드: 스킬별로 다른 AI 모델을 지정할 수 있다
스킬의 은퇴 기능과 개선 기능
여기서 주목할 것은 스킬이 갖는 자기 평가(eval) 메커니즘이다. 스킬은 단순히 실행만 하는 게 아니라, 실행 결과를 평가하고, 평가 결과에 따라 행동을 개선할 수 있다.
예를 들어 콘텐츠를 작성하는 스킬이 있다고 하자. 이 스킬은:
작성 → 2. 평가(eval) → 3. 점수가 낮으면 재작성 → 4. 점수가 충분하면 발행
그리고 단순히 구조가 바뀐 것이 아니라, 스킬이 자기 발전하는 시스템으로 진화했다.
Skill 2.0의 3대 핵심 업그레이드
Skill 2.0은 단순 명세서를 넘어 자기 발전하는 시스템으로 진화했다. 핵심은 세 가지다:
업그레이드 | 한줄 설명 | 비유 |
|---|---|---|
1. Evals (자동 테스트) | 샘플 입력 → 결과 생성 → 원하는 출력과 비교. 오류 지점을 자동 식별한다. | 프로그램 출시 전 QA 테스트 |
2. Auto Refinement (자동 개선) | Evals 결과를 기반으로 SKILL.md를 자동 수정. 사람이 수동으로 고칠 필요 없이 스킬이 스스로 발전한다. | 시험 결과를 보고 스스로 공부법을 바꾸는 학생 |
3. Composability (스킬 연결) | 여러 스킬을 파이프라인으로 연결. 주제 조사 → 콘텐츠 작성 → 서식 정리를 하나의 흐름으로. | 공장의 컨베이어 벨트 |
특히 주목할 것은 Evals + Auto Refinement의 조합이다. 이 루프는 이 루프가 바로 'Generator-Evaluator 아키텍처'의 원형이다. GAN(Generative Adversarial Network즉, 생성과 판별을 분리한 AI 학습 구조)에서 영감을 받은 구조로받아, 생성과 평가를 분리함으로써 "자기 평가의 맹점(self-evaluation blindness)"을 해결한다.
스킬의 은퇴 — Evals가 감지하는 수명
그리고 특정 Evals에는 또 하나의 숨은 역할이 있다. 스킬이 반복적으로 낮은 점수를 받으면?
- LLM의 발전또는 AI툴발전으로 발전 또는 AI 도구의 발전으로 더이상 쓸모가 없어짐으로 없어짐을 측정 - — 이제 웬만한 표준 웹개발 프레임워크는 그것을 잘 사용하는 입문서 정도(고급까지가능) 는 구구절절 이야기 안해도 되는것처럼
- 구구절절 입문서 없이도 AI가 잘 다루는 것처럼, 특정 스킬이 더 이상 부가가치를 만들지 못하는 시점이 온다.
그 스킬을 '은퇴'시키고 시키고 더이상 필요없지는 필요없는 스킬을 정리하는것이다정리하는 것이다. ( 아직은 홍수처럼 더 생겨날테지만 )
개인적으로 스킬2,0의 핵심기능중 가장 높이평가하는 부분은 Eval의 평가작동이 은퇴 시점감지하고 없앨준비도 초반에 하란 이야기로 해석함
...
생겨날 테지만, 개인적으로 Skill 2.0의 핵심 기능 중 가장 높이 평가하는 부분은 Eval의 평가 작동이 은퇴 시점까지 감지하고, 처음부터 없앨 준비도 하라는 설계 철학이라고 해석한다.
| Tip |
|---|
벤치마킹: 같은 입력을 여러 번 실행하여 출력 결과의 일관성을 확인하는 기능도 있다. 결과 편차가 크면 SKILL.md의 지침이 모호하다는 신호다. 이것 또한 "프로그램 출시 전 테스트"와 같은 개념이다. |
그래서 하네스란 무엇인가 — IT 세계의 동물 이야기
하네스 엔지니어링을 이해하려면, IT 세계가 왜 이렇게 동물을 사랑하는지부터 보면 쉽다.
| Info |
|---|
동물원 → 목장 → 마구: IT의 동물 비유 3부작 분산 시스템을 관리하는 ZooKeeper는 동물원 관리자였다. "분산 시스템은 동물원이다"라는 솔직한 고백이었다. → 자세한 이야기는 클러스터는 목장이다 — ZooKeeper, Rancher, 그리고 AI 마구(Harness) 참조 |
하네스 엔지니어링은 이 스킬 시스템을 더 큰 그림으로 확장한 것이다. 동물원 관리자(ZooKeeper)가 우리를 만들고, 목장 주인(Rancher)이 목초지를 조성하듯, 하네스 엔지니어는 AI가 올바른 방향으로 달릴 수 있는 환경과 방향을 설계한다.
OpenAI의 정의를 빌리면, 하네스 엔지니어링은 다음 세 가지를 설계하는 분야다:
...
쉽게 말하면, "모델은 CPU고 하네스는 OS다." 아무리 CPU가 강력해도 OS가 나쁘면 성능이 저하된다. 하네스는 AI 에이전트가 프로덕션 수준으로 안정적으로 작동하도록 감싸는 환경 전체를 의미한다마구(馬具)의 비유로 돌아오면 — AI는 강력한 말이고, 엔지니어의 역할은 코드를 직접 짜는 것이 아니라, 말이 올바른 방향으로 힘을 쓸 수 있도록 마구를 설계하는 것이다.
스킬 2.0과 하네스의 관계 — 라이브러리, 툴킷, 프레임워크
스킬과 하네스는 경쟁 관계가 아니다. 계층 관계다.
| Code Block | ||
|---|---|---|
| ||
하네스 = CLAUDE.md(정적 컨텍스트) + Skills(동적 행동) + Constraints(제약) + Feedback Loop(피드백) |
CLAUDE.md는 하네스의 "정적 컨텍스트" 레이어를 담당한다
Skills는 하네스의 "동적 행동" 레이어를 담당한다
하네스는 이 둘을 포괄하는 전체 시스템 설계다
웹 개발에 익숙한 개발자라면 이 비유가 와닿을 것이다:
웹 개발 비유 | AI 코딩 대응 | 역할 |
|---|---|---|
라이브러리 (lodash, axios) | 스킬 (개별 SKILL.md) | 특정 작업을 수행하는 독립 단위. 필요할 때 꺼내 쓴다. |
툴킷 (Material UI, Bootstrap) | 스킬 집합 (일관된 스킬 묶음) | 같은 철학으로 설계된 유용한 스킬의 일관성 집합체. |
프레임워크 (Next.js, Spring) | 하네스 (harness/ 전체 구조) | agents/, engine/, knowledge/ 등의 규칙과 제약으로 구조화된 레이어. 마치 웹 프레임워크처럼 "이 안에서 이 규칙대로 작동하라"고 환경 자체를 제공한다. |
| Note |
|---|
핵심 차이: 웹 프레임워크는 코드가 실행되지만, 하네스는 LLM이 관여한다는 점이 다르다. 그러나 본질은 같다 — 프레임워크 없이 웹을 바닐라 JavaScript로 개발하는 것과, 하네스 없이 CLAUDE.md 하나로 AI를 운용하는 것은 비슷한 차이다. 둘 다 작동은 하지만, 규모가 커질수록 구조화된 프레임워크의 가치가 드러난다. |
CLAUDE.md는 하네스와 유사한 역할을 하지만, 하네스는 여기서 한 단계 더 나아간다. harness/knowledge/(도메인 지식), harness/agents/(에이전트 행동 정의), harness/engine/(워크플로우 규칙) 같은 구조화된 레이어로 분리하여, 웹 프레임워크의 MVC 패턴처럼 관심사를 분리한다스킬이 개별 병사라면, 하네스는 그 병사들이 움직이는 전장의 전체 작전 계획이다.
...
2. 하네스는 우리에게 도움을 줄 것인가? 고통을 줄 것인가?
...
그러나 동시에 "가두리 양식장"이라는 비유도 유효하다. ETH Zurich의 토큰 낭비 연구, Vercel의 도구 감축 실험, Martin Fowler 사이트의 검증 부재 지적 — 이런 경고도 무시할 수 없다.
하네스의 역설 — 대기업과 스타트업이 만나는 지점
대기업은 늘 안정성과 효율을 추구한다. 그러나 아이러니하게도 그들이 갈망하는 것은 스타트업의 속도다. 빠르게 실행하고, 실패를 감수하며, 시장에 먼저 닿는 힘. 그래서 그들은 '하네스'를 찾는다. 조직을 묶어주는 장치이되, 동시에 속도를 방해하지 않는 유연한 구조를.
반대로 스타트업은 자유로움 속에서 시작하지만, 성장의 순간에 부딪힌다. 규칙이 없던 조직은 점점 혼란을 겪고, 결국 질서를 갈망하게 된다. 이때 등장하는 것이 또 다른 형태의 하네스다. 통제와 기준을 부여해 일관된 결과를 만들어내는 장치.
흥미로운 점은, 이 두 흐름이 결국 같은 지점을 향한다는 것이다. 빠르되 무너지지 않기 위해, 자유롭되 흩어지지 않기 위해 — 각자의 방식으로 하네스를 만든다.
| Note |
|---|
하지만 언제나 예외는 존재한다. 어떤 크리에이터는 시스템 없이도 높은 품질을 만들어낸다. 오롯이 개인의 감각과 숙련된 스킬로 결과를 끌어올린다. 그들에게 하네스는 필수가 아니라 선택이다. |
결국 중요한 것은 정답이 아니다. 상황에 맞는 선택이다. 조직의 크기, 단계, 목표에 따라 하네스는 달라져야 한다. 과도하면 속도를 잃고, 부족하면 방향을 잃는다. 하네스는 도구일 뿐이다. 그것을 어떻게, 언제, 얼마나 사용하는지가 결국 결과를 결정한다.
...
나 자신의 글쓰기 하네스를 4일간 운영하면서 느낀 것은 이것이다것도 같은 맥락이다: 하네스는 만능 해결사가 아니다. '나에게 맞느냐'가 핵심이다.
...
이 질문에 대한 답은 당신만이 알고 있다.
...
참고 자료
클러스터는 목장이다 — ZooKeeper, Rancher, 그리고 AI 마구(Harness) — IT 세계의 동물 비유로 하네스 엔지니어링을 이해하는 선행 글
HumanLayer - Skill Issue: Harness Engineering for Coding Agents
고승원 님 페이스북 — "나는 바이브코딩에서 하네스 엔지니어링을 쓰지 않기로 했다"
...