스킬과 하네스
스킬과 하네스의 차이가 뭘까? 여러 하네스가 클로드 코드 스킬의 형태로 배포되기도 하고, 나도 여기저기서 '같은거다'라고 얘기하고 다니기도 했는데, 생각해보니 차이점들도 여럿 보이는 것 같아 정리해봤다.
일단 둘은 개념상으로는 구분되지만 실제 구현체에서는 서로를 포함하거나 서로의 형태로 배포되는 경우가 많다. 스킬은 능력의 패키지고, 그 능력이라는 게 어떤 목적을 달성하기 위한 것이면, 피드백 루프 — 즉 하네스 — 를 통해 목적을 달성하도록 짜여져 있는 경우가 많다. 반대로 하네스라는 것은 목적 달성을 위한 피드백 루프니까, 스킬들의 조합을 통해 에이전트의 행동양식을 정의하고, 그걸 제약조건으로 둘러쳐서 피드백을 만드는 경우가 많다. 은근한 차이는 스킬이 "어떻게 행동할 것인가"를 압축한다면, 하네스는 "그 행동이 목표에 가까워졌는지 어떻게 알 것인가"를 조직한다는 데 있다.
스킬이라는 게 도구, 서브에이전트, 훅을 포함하지만 주로 SKILL.md라는 '프롬프트'의 확장에 가깝다는 점을 생각해보면 이 차이가 더 뚜렷해진다. 스킬에는 지침 문서뿐 아니라 도구 호출 방식, 서브에이전트 사용 규칙, 스크립트, 검증 명령, 출력 형식, 금지 조건이 포함될 수 있다. 결국 스킬은 이전 시대의 프롬프트가 수행했던 역할과 비슷하게 에이전트의 정책을 표현한다고 할 수 있다. 능력이라는 게 결국 어떤 입력이 들어왔을 때 a라는 상태에서 x라는 도구를 호출해서 결과 a'으로 갈 수 있는가, 결과 b로 새지 않을 수 있느냐라는 것이기 때문이다. 이전 시대의 프롬프트가 모델의 응답 성향을 조정했다면, 스킬은 그 역할을 파일시스템, 도구, 실행 환경, 프로젝트 규칙까지 확장한 형태다.
층위로 보면 관계가 분명해진다. 도구는 에이전트가 호출하는 단일 행위의 단위이고, 스킬은 그 도구 호출들을 하나의 정책으로 묶은 한 단계 위의 단위이며, 하네스는 그 정책들이 목적을 향해 탐색되도록 가두는 더 위의 피드백 구조다. 도구가 스킬에 담기고 스킬이 하네스 안에서 작동하는, 아래에서 위로 쌓인 층이다.
하네스가 구체적으로 정하는 것은 이렇다. 무엇을 바꿀 수 있고 무엇은 건드리면 안 되는지, 성공과 실패를 어떻게 판정하며, 실패하면 무엇을 되돌릴지. 그러니까 하네스는 능력 자체를 정의하기보다, 능력이 놓이는 탐색 공간과 그 결과를 거르는 평가 조건을 정의한다. 코드 에이전트라면 테스트 실패, 타입 오류, 빌드 로그, 실행 결과, 사용자 피드백이 그 신호다. 개념적으로 스킬은 에이전트가 참조하는 정책적 자산이고, 하네스는 그 정책이 실제 환경에서 검증되는 외부 구조다. 스킬이 행동의 형식이라면, 하네스는 행동의 선별 조건이다.
하네스의 크기는 천차만별이다. 한쪽 끝에는 출력에 이모지가 섞이면 파일 쓰기를 막아버리는 '이모지 금지 훅' 같은 것이 있다. 코드 몇 줄에 불과하지만 훌륭한 하네스다 — 통과와 실패가 이진으로 명확한 하드 게이트라서 오히려 가장 강력하게 작동한다. 반대쪽 끝에는 여러 세션과 도구에 걸친 거대한 운영 구조 전체가 하네스로 묶이기도 한다. 하네스의 강도는 크기가 아니라 피드백 신호의 명료함에서 온다.
스킬도 두 층으로 볼 수 있다. 개념으로서의 스킬은 업무 능력과 패턴을 패키징한다는 발상이고, 구현으로서의 스킬은 그 발상을 SKILL.md와 훅, 스크립트로 구체화한 산출물이다. 경계가 흐려지는 곳은 바로 이 구현층이다. 스킬에 훅을 함께 패키징할 수 있고, 스크립트도 셀프-피드백을 위한 도구로서 제공하는 경우가 많다는 것을 생각해보면, 스킬은 자기 결과를 관찰하고 수정하는 미니 하네스를 이미 포함하게 된다. 배포 스킬이 빌드, 테스트, 로그 확인, 헬스체크, 실패 시 롤백 조건까지 포함한다면 그것은 실행 지침을 넘어 작은 제어 시스템이다. 반대로 하네스는 여러 스킬을 조합하고, 어떤 스킬을 언제 호출할지 결정하며, 그 결과를 다시 평가하는 상위 피드백 구조가 된다. 하네스라는 것은 스킬에 내장된 미니 하네스일 수도 있지만, 그런 정책들을 바탕으로 탐색을 수행하는 공간 전체의 제약을 의미할 수도 있다.
그러니까 어떤 면에서는 클로드 코드와 같은 코딩 에이전트는 에이전트 런타임이기도 하지만, 에이전트가 환경에 배치되어 작동하도록 하기 위해 그 자체로 스킬과 하네스를 내장하고 있고, 어떤 면에서는 하네스 그 자체라고 봐도 될 것이다. 이들은 모델 호출 UI가 아니라 파일시스템, 셸, 테스트, 버전관리, 승인 흐름, 프로젝트 규칙을 연결하는 에이전트 런타임이면서, 코드 읽기, 수정, 디버깅, 테스트 반복, 커밋 정리 같은 스킬들을 내장하거나 외부에서 추가할 수 있는 스킬 실행기이고, 코드베이스라는 환경 안에서 수정, 실행, 관찰, 재수정을 반복하게 만드는 하네스화된 실행 환경이다. 명확히 정의된 목표와 피드백만 있으면, 정책을 명시적인 프롬프트나 스크립트로 제공하지 않아도, 내장된 능력 그 자체로도 뛰어난 퍼포먼스를 낼 수 있다. 혹은 미리 패키징된 다양한 스킬들을 잘 조합해서 더 정교한 탐색정책을 가지도록 할 수도 있다.
반대로 주로 이야기되는 하네스가 클로드 코드/코덱스 등의 '스킬'의 형태로 구현되어 배포된다는 점도 생각해볼 만하다. 전체 하네스는 목표, 상태, 평가, 권한, 복구까지 포함하므로 그대로 이식하기 어렵지만, 스킬은 특정 런타임이 읽을 수 있는 문서, 훅, 커맨드, 스크립트 묶음으로 배포하기 쉽다. 그래서 "스킬을 만든다"는 행위가 실제로는 에이전트의 탐색 공간, 피드백 조건, 실패 복구 절차를 부분적으로 설계하는 일이 된다. 이때 스킬은 능력 패키지이면서 동시에 하네스 조각의 운반체가 된다.
여기서 결정적인 것은 '스킬'이라는 말 자체가 두 추상 수준을 오간다는 점이다. 구현으로서의 스킬은 SKILL.md 프론트매터, 디렉터리 규약, 마켓플레이스까지 갖춘 프로토콜 수준의 표준인데, 하네스에는 그런 표준층이 없어 대체로 개념 수준에 머문다. 그래서 명세가 없는 하네스를 실어 나르려면 표준을 가진 스킬의 형식을 빌릴 수밖에 없다. Addy Osmani가 스킬을 "증거를 남기는 체크포인트와 종료 조건을 가진 워크플로우"이자 "하네스 엔지니어링의 한 계층"으로 규정한 것이 그 예다. 이때 그가 가리키는 스킬은 SKILL.md 표준이 아니라 개념 수준의 스킬이고, 그 개념은 능력 패키지보다 하네스 쪽으로 기울어 있다. 같은 단어가 두 수준을 오가니, 표준으로서의 스킬과 정확히 포개지지 않는 것도 당연하다. 이 비대칭 덕분에, 하네스를 에이전트 런타임에 얹는 가장 쉽고 'pluggable'한 방식이 사실상 스킬이 된다. 스킬은 표준화된 로드 단위라 런타임에 그대로 끼워 넣을 수 있기 때문이다. 클로드 코드의 플러그인은 그런 스킬들을 묶어 배포하는 클로드 코드 고유의 구현일 뿐 표준은 아니다 — 표준은 스킬이고, 플러그인은 그 표준을 패키징하고 유통하는 한 런타임의 메커니즘이다.
물론 스킬로 구현한 하네스에는 한계가 있다. 런타임과의 통합성은 뛰어나지만 전체를 '감싸는' 데는 약하고, 특정 에이전트 런타임에 종속되기 쉽다. 스킬은 런타임 안에 얹히는 단위라, 런타임 자체를 바깥에서 두르는 상위 제어 구조가 되기는 어렵기 때문이다. 그래서 ouroboros 같은 하네스는 특정 런타임에 매이지 않는 런타임-agnostic한 상위 오케스트레이션으로 구현되기도 한다. 이 정도 스케일이 되면 그것을 더 이상 '스킬'이라고 부르기엔 어색하다 — 이름이 분명히 하네스 쪽으로 넘어간다.
장기 실행 에이전트에서 하네스와 스킬의 차이는 더 극명하게 드러난다. 장기 실행 에이전트의 스케일과 복잡성은 단일 스킬이 아닌 다양한 스킬의 조합으로만 가능하기 때문이다. 며칠 또는 몇 주에 걸친 목표 추구, 세션 간 상태 유지, 실패 복구, 다중 에이전트 협업, 부분 산출물 검증을 단일 스킬만으로는 감당하기 어렵다. 거기서 하네스는 그런 스킬들을 통해, 때로는 복수의 에이전트가 상호작용하여 목적을 향해 나아가는 가운데, 제약조건과 피드백 신호를 제공해주는 전체 시스템을 말하게 된다. 하네스가 그 자체로 적응을 끌어내는 환경이 되는 양상은 환경으로서의 하네스에서 다뤘다.
결국 스킬과 하네스는 배타적인 개념이 아니다. 스킬은 정책을 압축한 실행 단위이고, 하네스는 그 정책이 탐색되고 검증되는 피드백 환경이다. 개념상으로는 스킬이 행동정책이고 하네스가 피드백 구조라는 차이가 있지만, 구현체에서는 스킬이 하네스를 내장하고 하네스가 스킬 형태로 배포된다. 둘이 이렇게 구분되면서도 겹칠 수 있는 건 결국 이것들이 개념이기 때문이다. 프로토콜이라면 명세가 배타적이라 겹칠 수 없지만, 개념은 강조점으로 갈리면서도 외연을 공유한다.
참고
"Agent Skills (Open Standard)." agentskills.io — 최초 개발 Anthropic, 2026.
Addy Osmani. "Building Reliable Long-Running AI Agents." Addyo Substack, 2026.
Addy Osmani. "Agent Skills." O'Reilly Radar, 2026.
Q00. "ouroboros (Agent OS)." GitHub, 2026.