하네스 스킬이라 부르기로 했다 — 잘하고 있다는 착각을 깨고 내 하네스를 열기까지#

2026-06-08

이름 없는 것들 앞에서#

LLM Wiki라는 것을 처음 봤을 때, 그리고 GStack을 봤을 때, 필자가 가장 먼저 한 생각은 의외로 “이걸 뭐라고 불러야 하지?” 였습니다.

둘 다 AI 에이전트를 더 잘 다루기 위한 수단이라는 점은 분명했습니다. 필자가 이전 글에서 정리한 하네스 엔지니어링, 즉 AI 에이전트를 안전하고 안정적으로 운용하기 위한 인프라 설계 분야의 관점에서 보면, 이런 것들은 명백히 “하네스를 만들 때 가져다 쓰는 도구"였습니다.

그런데 막상 한 단어로 묶으려니 막혔습니다. “프레임워크” 라고 부르자니 어딘가 어색했습니다. 소프트웨어에서 프레임워크는 보통 제어 흐름을 가져가는 코드 골격을 뜻합니다. LangChain처럼 “당신이 내 규칙대로 코드를 끼워 넣으면 내가 실행시켜준다"는 역전된 구조 말입니다. 반면 LLM Wiki나 GStack은 실행 골격이라기보다, 에이전트 위에 얹어서 참조하거나 적용하는 구조화된 자산에 가까웠습니다. 프레임워크라는 단어는 이 결을 제대로 담지 못했습니다.

이 사소해 보이는 명명의 고민이, 생각보다 멀리까지 필자를 데려갔습니다.

표준 용어는 아직 없었다#

그래서 직접 조사해 봤습니다. 결론부터 말하면, 이런 것들을 딱 집어 부르는 표준 용어는 아직 없습니다.

2026년에 들어 업계의 어휘는 빠르게 수렴하고 있습니다. “Agent = Model + Harness(에이전트는 모델과 하네스의 합)“라는 정의가 자리를 잡았고, 하네스를 이루는 부품을 하네스 구성 요소(Harness Component) 또는 하네스 프리미티브(Harness Primitive) 라 부릅니다. LangChain은 Skill을 “하네스 레벨 프리미티브"라고 명명했습니다. 그러나 LLM Wiki나 GStack처럼 “하네스를 강화할 목적으로 가져다 얹는 패키지화된 수단” 그 자체를 가리키는 합의된 이름은 비어 있었습니다.

흥미롭게도, 이 둘은 실제로 동일한 메커니즘으로 배포됩니다. GStack은 Claude Code의 스킬 팩으로, LLM Wiki는 스킬 또는 AGENTS.md 프로토콜 파일로 설치됩니다. 둘 다 형식상으로는 스킬(Skill) 입니다.

그렇다면 그냥 “스킬"이라 부르면 될까요? 문제가 있습니다. 사용자가 직접 작성하는 일반 스킬(특정 작업을 수행하는 스킬)과 혼동됩니다. 구분의 축은 형식이 아니라 목적에 있었습니다. 작업을 수행하는 스킬과, 에이전트의 운영 환경 자체를 구성하는 스킬은 다릅니다.

그래서 필자는 이것들을 “하네스 스킬(Harness Skill)”, 그 묶음을 “하네스 스킬팩(Harness Skill Pack)” 이라 부르기로 했습니다. 표준 용어가 아니라 필자의 명명입니다. 다만 비어 있던 자리였기에, 충돌할 기존 표준도 없고 “skill / skill pack"이라는 업계 표현 위에 목적 수식어만 얹은 합리적 확장이라고 판단했습니다.

이름을 붙이고 나니, 정작 더 불편한 질문이 떠올랐습니다.

필자는 닫혀 있었다#

필자는 회사 업무와 개인 작업 모두에서 Cursor, Claude Code, Hermes를 적극적으로 사용합니다. 하네스 구성도 필자의 사용 패턴에 맞게 자체적으로 구축해 왔습니다. 솔직히 말하면, 나름 하네스 엔지니어링을 잘하고 있는 편이라고 생각했습니다.

그래서 다른 사람이 만든 하네스 스킬에 손을 대지 않았습니다. 이유는 분명했습니다. 남이 보편적인 의도로 만든 것이 필자의 사용 패턴을 방해할까 봐 두려웠던 것입니다. 내 손에 맞게 다듬어 둔 도구가 있는데, 굳이 남의 방식을 들여와 흐름을 흐트러뜨릴 이유가 없다고 여겼습니다.

그런데 이번에 하네스 스킬이라는 이름을 붙이고 그 세계를 들여다보다가, 불편한 사실을 마주했습니다. 그 방어적인 태도가 사실은 더 나아질 가능성 자체를 차단하고 있었다는 것입니다.

“잘하고 있다"는 느낌은 위험합니다. 그것은 종종 “더 배울 것이 없다"는 착각으로 미끄러집니다. 필자가 자체 하네스에 만족하는 동안, 수만 명이 함께 다듬어 온 검증된 패턴들이 바깥에서 빠르게 진화하고 있었습니다. 내 패턴을 지키느라, 내 패턴을 개선할 재료를 스스로 외면하고 있었던 셈입니다.

이 자각 이후, 필자는 생각을 바꿨습니다. 보편적으로 사랑받는 하네스 스킬들을 하나씩 직접 써보기로 했습니다. 통째로 갈아엎기 위해서가 아니라, 그 안의 좋은 아이디어를 골라 내 하네스에 흡수하기 위해서입니다.

그래서 열어보기로 했다 — 대표 하네스 스킬들#

먼저 무엇이 있는지부터 정리했습니다. GitHub 스타와 실제 채택 폭을 기준으로, 많은 사람에게 사랑받는 하네스 스킬들을 추렸습니다. 중요한 것은 각각이 하네스의 어느 구성 요소를 강화하는가, 그리고 기존 환경에 얼마나 침습적인가 입니다.

컨텍스트 / 메모리 — 침습도 낮음#

Serena 는 언어 서버(LSP) 기반의 시맨틱 코드 도구입니다. 에이전트가 파일을 통째로 읽지 않고 심볼 단위로 코드를 탐색 / 편집하게 해, 토큰을 크게 절약하고 세션 간 프로젝트 메모리도 제공합니다. MCP 서버 하나만 붙이는 방식이라 기존 워크플로우를 거의 건드리지 않습니다.

LLM Wiki 는 Andrej Karpathy가 제안한 패턴으로, 에이전트가 상호 링크된 마크다운 위키를 지속적으로 쌓아 유지합니다. RAG처럼 매번 원본에서 답을 재추출하는 대신, 한 번 컴파일해 계속 최신화합니다. 저장소 기반 메모리(.memory/) 를 이미 쓰고 있다면 사상적으로 가장 잘 맞습니다.

워크플로우 / 스펙 주도 — 중간 침습도#

Claude Task Master 는 요구사항 문서(PRD) 를 의존성 인지 작업 그래프로 분해하고, 각 작업의 복잡도를 점수로 매겨 쪼갤지 추천합니다. Cursor에 MCP로 붙이는 것이 표준 사용법입니다.

GitHub Spec Kit 은 이 분야 최다 스타를 기록한 도구로, “스펙 → 계획 → 작업 → 구현"의 4단계로 스펙을 먼저 확정한 뒤 에이전트가 구현하게 하는 스펙 주도 개발(SDD) 툴킷입니다. 단계별 산출물이 다음 단계의 컨텍스트가 되는 구조라 검증 루프 성격도 가집니다. OpenSpec 은 신규 프로젝트보다 기존 코드베이스(브라운필드) 의 변경 관리에 특화되어 자주 비교됩니다.

올인원 / 팀 시뮬레이션 — 침습도 높음#

이 그룹은 강하게 의견이 박힌(opinionated) 도구들입니다. 효과가 큰 만큼, 자체 하네스가 확립된 사람에게는 충돌 위험도 가장 큽니다.

oh-my-claudecode(OMC) 는 “Claude Code를 위한 oh-my-zsh"를 표방하며, 32개 전문 에이전트와 40개 이상의 스킬을 제로 설정으로 얹습니다. 스마트 모델 라우팅(단순 작업은 빠른 모델, 복잡한 추론은 강한 모델) 으로 토큰을 절감하고, 검증이 끝날 때까지 멈추지 않는 Ralph 모드 같은 패턴을 제공합니다. BMAD-METHOD 는 분석가 / PM / 아키텍트 / QA 등 12개 이상의 에이전트로 애자일 팀 전체를 시뮬레이션합니다. SuperClaude 는 페르소나와 명령어, 세션 메모리를 한 묶음으로 표준화하는 설정 프레임워크입니다. GStack 은 Y Combinator의 Garry Tan이 만든 가상 엔지니어링 팀 스킬팩으로, “thin harness, fat skills” 철학이라 마음에 드는 역할만 떼어 쓰기가 비교적 쉽습니다.

더 찾아보고 싶다면, Anthropic / Vercel / Stripe 등 공식 팀과 커뮤니티의 스킬을 모은 레지스트리 VoltAgent/awesome-agent-skills 가 좋은 출발점입니다.

통째로 갈아엎지 않는다#

여기서 필자가 새로 세운 원칙이 있습니다. 의견 강한 도구일수록 통째로 채택하지 않는다.

자체 하네스가 있는 사람에게 올인원 도구를 그대로 설치하는 것은 위험합니다. 실제로 OMC의 기본 설치는 글로벌 설정 파일을 통째로 덮어쓰기 때문에, 그동안 다듬어 온 규칙이 한 번에 사라질 수 있습니다. 다행히 프로젝트 한정 설치나 보존 모드 같은 안전장치가 있습니다.

그래서 필자가 정한 흡수의 순서는 이렇습니다.

1. 침습도가 낮은 것부터 — Serena, LLM Wiki처럼 기존 패턴에 더해지기만 하는(additive) 것을 먼저 적용합니다.
2. 워크플로우는 실험으로 — Task Master나 Spec Kit은 별도 프로젝트에서 흐름을 체험해 봅니다.
3. 올인원은 격리된 샌드박스에서 — OMC, GStack 같은 도구는 프로젝트 한정 모드로 별도 저장소에서 평가하고, 마음에 드는 패턴만 떼어 내 하네스에 녹입니다.

핵심은 “전부 받아들이기"가 아니라 “골라서 흡수하기"입니다. 예를 들어 OMC를 통째로 쓰지 않더라도, 그 모델 라우팅이나 “검증 완료까지 지속” 패턴의 아이디어만 가져와 내 하네스에 적용할 수 있습니다. 좋은 하네스는 언제든 떼어낼 수 있는(rippable) 구조를 유지해야 하므로, 외부 패턴도 이 원칙 위에서 실험하면 됩니다.

자신감과 개방성 사이#

이번 일을 겪으며 필자가 배운 것은 도구 목록이 아니라 태도였습니다.

자체 하네스를 구축하고 다듬어 온 시간의 가치는 변하지 않습니다. 그것은 분명한 자산입니다. 다만 그 자산이 “더 이상 배울 것이 없다"는 울타리가 되는 순간, 자신감은 함정으로 바뀝니다. 잘하고 있다는 느낌은, 가끔 멈춰 서서 의심해 봐야 합니다.

이제 필자는 하네스 스킬이라는 이름으로 그 세계를 부르고, 닫아 두었던 문을 열어 하나씩 들여다보고 있습니다. 자체 구축의 가치를 지키되, 바깥의 검증된 패턴에 열려 있는 것. 그 사이의 균형을 찾는 일이, 결국 하네스 엔지니어링을 계속 잘해 나가는 길이라고 믿습니다.

참고 자료#

• Serena — A powerful MCP toolkit for coding
• Andrej Karpathy — LLM Wiki (gist)
• Claude Task Master
• GitHub Spec Kit
• oh-my-claudecode (OMC)
• GStack — Garry Tan’s Claude Code Skill Pack
• SuperClaude Framework
• VoltAgent — awesome-agent-skills