스킬 엔지니어링의 어두운 기술: 프롬프트를 넘어 하니스를 설계하는 법

메타데이터

• 원문 제목: The Dark Arts of Skill Engineering — Paul Bakaus, Renaissance Geek (Impeccable)
• URL: https://www.youtube.com/watch?v=SQMCtZX3trg
• 날짜: 2026-09-21
• 처리일: 2026-09-22
• 채널: AI Engineer
• 발표자: Paul Bakaus
• 주제: 스킬 엔지니어링(Skill Engineering), 하니스 엔지니어링(Harness Engineering), 멀티 에이전트, 모델별 배포

---

📌 핵심 질문 / 논점

==좋은 에이전트 스킬은 잘 쓴 프롬프트가 아니라, 서브 에이전트·스크립트·메모리·훅·브라우저·평가 하니스를 조합해 모델이 원하는 작업을 건너뛸 수 없도록 만든 하니스 확장이다.==

• 프롬프트로 특정 폰트나 색상을 금지하면 모델은 창의적으로 변하는 대신 잠재 공간의 다음 유행 묶음으로 이동한다.
• 동일 모델이 자기 결과물을 평가하면 이미 만든 결과에 고정되므로, 서로의 작업을 보지 못하는 두 서브 에이전트의 독립적인 의견과 합성이 필요하다.
• 배포 가능한 스킬은 Claude, Codex, Cursor, Gemini 등 하니스와 모델마다 다른 권한·도구·실패 경향을 보정해야 한다.
• 사용자가 매번 기억해야 하는 명령보다 모든 편집에 자동으로 작동하는 훅과, 결과를 검증하는 평가 루프가 강력하다.

Paul Bakaus는 대규모 엔터프라이즈 앱을 에이전트로 빠르게 설계하면서, 생성된 UI를 기존 디자인 시스템으로 되돌리는 일이 어렵다는 문제를 겪었다. 이를 해결하기 위해 만든 Impeccable은 normalize에서 시작해 critique, polish, live mode, 디자인 훅, 모델별 컴파일러와 평가 하니스까지 확장됐다. 핵심 변화는 “스킬 = 지침이 들어 있는 Markdown 파일”이라는 생각을 버리고 “스킬 = 사용하는 하니스에 기능을 추가하는 작은 제품”으로 보는 것이다.

1. Impeccable이 스킬 엔지니어링 문제에서 출발한 이유

생성형 UI는 빠르게 만들 수 있지만, 좋은 결과를 안정적으로 반복하고 디자인 시스템에 맞추는 일은 별개의 공학 문제다.

1.1. 디자인 스킬의 시작

1. 엔터프라이즈 앱의 현실

   1. 여러 화면과 상태를 가진 큰 앱을 에이전트와 빠르게 설계하려면 매번 수작업으로 디자인하는 방식은 느리다.
   2. 에이전트는 짧은 시간에 볼 수 있는 결과를 만들어 주지만, 결과가 기존 디자인 시스템과 일치하지 않는 문제가 생긴다.
   3. 첫 번째 스킬 normalize는 에이전트가 만든 결과를 디자인 시스템으로 되돌리는 역할을 했다.

2. 개인용 도구에서 오픈소스로

   1. Anthropic의 프런트엔드 디자인 스킬을 참고하면서 디자인 관련 기능을 점차 추가했다.
   2. 사람들이 비슷한 문제를 겪는다는 판단으로 Impeccable을 오픈소스 스킬로 공개했다.
   3. 발표의 대상은 Impeccable의 사용법 자체가 아니라, 단순 프롬프트가 여러 하니스 기능을 사용하는 시스템으로 커지는 과정에서 얻은 원칙이다.

1.2. ‘AI 슬롭’은 움직이는 목표다

1. 반복되는 미적 패턴

   1. AI가 만든 가짜 아동용 리더 앱에는 기울임꼴 세리프, 대문자 히어로 문구, 상단 eyebrow 라벨, 베이지색 배경이 반복된다.
   2. 과거에는 보라색 그라디언트가 AI 생성물의 전형이었다면, 이제는 ‘Claw beige’ 같은 새로운 패턴이 그 자리를 차지한다.
   3. 결과가 반드시 나쁘지는 않지만, 모두가 AI 생성물임을 알아보는 순간 디자인의 개성이 사라진다.

2. 프롬프트와 기도의 한계

   1. 초기 접근은 약 55줄의 이름 붙은 규칙을 적은 시스템 프롬프트뿐이었다.
   2. “Inter, Roboto, Arial 같은 흔한 폰트를 쓰지 말라”, “보라색 그라디언트를 피하라”는 금지 규칙은 때때로 작동했지만 대부분 안정적이지 않았다.
   3. 특정 선택을 금지하면 모델은 더 창의적인 공간으로 이동하지 않고 잠재 공간에서 다음으로 흔한 선택을 고른다.
   4. Tailwind의 기본 샘플이 보라색 테마로 웹을 물들였던 것처럼, jQuery UI의 기본 주황색 테마는 한때 웹 전체를 주황색으로 만들었다.

3. 모델의 중력

   1. 250줄의 정교한 규칙만으로는 모델이 가장 익숙한 선택으로 끌리는 힘을 이기기 어렵다.
   2. 프롬프트는 시작점이지만, 반복 가능한 결과를 내려면 실행 환경 전체를 설계해야 한다.

2. 프롬프트는 바닥이고 하니스 엔지니어링은 천장이다

스킬을 패키지된 프롬프트가 아니라 하니스에 새로운 기능을 더하는 확장으로 이해해야 한다.

2.1. 스킬을 MCP처럼 하니스의 확장으로 보기

1. 프롬프트의 역할

   1. 프롬프트는 모델에게 의도와 규칙을 전달하는 가장 낮은 단계의 도구다.
   2. 모델이 규칙을 읽어도 도구를 호출하지 않거나, 검증을 건너뛰거나, 결과를 재평가하지 않으면 프롬프트만으로는 행동을 강제할 수 없다.

2. 하니스의 역할

   1. MCP가 코딩 하니스에 도구를 추가하듯, 스킬도 현재 하니스에 작업 흐름과 기능을 추가해야 한다.
   2. 서브 에이전트, 셸 스크립트, 브라우저, 백그라운드 작업, 훅, 상태 파일을 연결하면 프롬프트에 없는 실행 능력이 생긴다.
   3. 프롬프트가 주문(spell)이라면 하니스 엔지니어링은 그 주문을 실제로 작동시키는 마법 시스템이다.

2.2. Impeccable이 사용하는 9가지 기법

1. 두 서브 에이전트가 서로의 결과를 보지 못한 채 논쟁하게 만든다.
2. 금지 목록 대신 랜덤 시드와 외부 입력으로 잠재 공간의 수렴을 깨고 발산을 유도한다.
3. 거대한 단일 스킬 대신 목적별 하위 스킬을 라우팅하는 Mixture of Experts 구조를 사용한다.
4. 스킬 폴더에 이전 실행 결과를 저장해 세션을 넘어 기억하게 한다.
5. 스크립트의 표준 출력과 종료 상태로 모델에게 동적 지침을 전달한다.
6. 훅을 사용해 스킬을 잊거나 디자인 시스템을 위반하는 편집을 자동으로 감시한다.
7. 하니스의 브라우저를 실시간 UI 조작과 에이전트 피드백 루프에 연결한다.
8. 각 하니스와 모델의 권한·도구·실패 경향에 맞춰 스킬을 컴파일한다.
9. 가장 약한 모델이 규칙을 지키지 못한다는 전제에서 건너뛸 수 없는 게이트와 평가 하니스를 만든다.

3. 기법 1 — 자기 평가 대신 서브 에이전트끼리 논쟁시키기

모델에게 자신의 결과를 평가하게 하면 자기 작업을 기준점으로 삼으므로, 독립적인 시선과 합성 과정이 필요하다.

3.1. 자기 리뷰의 앵커링 문제

1. 자기 숙제 채점

   1. Codex나 Claude Code에 방금 만든 코드를 리뷰하라고 하면 모델은 자신이 잘 만들었다고 평가하는 경향이 있다.
   2. 모델은 이미 생성한 구조에 고정되어 문제를 발견해도 자신의 선택을 합리화한다.
   3. 디자인 리뷰, 코드 리뷰, 보안 감사, RFC 검토처럼 자기 결과를 평가하는 모든 작업에 같은 문제가 생긴다.

2. 결정적 검사만으로도 부족하다

   1. 좋은 페이지라도 대비, 글꼴 수, 화면 가장자리와의 거리 같은 결정적 규칙을 위반할 수 있다.
   2. 반대로 빈 페이지나 나쁜 페이지는 결정적 린터가 잡을 규칙이 없어 “문제가 없다”고 평가할 수 있다.
   3. 숫자로 표시된 위반 수만 보여 주면 모델은 위반이 500개라는 사실만 보고 좋은 디자인을 나쁘다고 결론 내릴 수 있다.

3.2. 두 개의 독립적인 관점과 합성

1. 디자인 디렉터 에이전트

   1. 브라우저를 사용해 실제 화면을 본다.
   2. 시각적 위계, AI 슬롭, 휴리스틱, 전체적인 인상을 평가한다.
   3. 결정적 규칙보다 사람이 디자인을 보는 방식에 가까운 비평을 만든다.

2. 결정적 검사 에이전트

   1. 디자인 린터를 실행한다.
   2. 대비, 과도한 폰트, 요소의 가장자리 간격 등 브라우저 증거와 수치화 가능한 문제를 수집한다.
   3. 첫 번째 에이전트의 인상에 영향을 받지 않도록 별도 컨텍스트에서 실행한다.

3. 메인 스레드의 합성

   1. 두 에이전트가 서로의 작업을 보지 못하게 한다.
   2. 두 결과가 모두 도착한 뒤 메인 에이전트가 장점과 문제를 합친다.
   3. 하나의 자신만만한 추측보다 두 개의 맹목적인 의견과 합성이 균형 잡힌 비평을 만든다.

4. 서브 에이전트 권한 차이

   1. Codex는 사용자가 명시적으로 서브 에이전트 사용을 요청해야 하는 권한 모델을 가질 수 있다.
   2. 배포되는 스킬이 자동으로 서브 에이전트를 호출할 수 없다면, 스킬은 기능이 제한된 상태임을 사용자에게 알리고 권한을 요청해야 한다.
   3. 에이전트는 호출하지 않아도 되는 경로를 발견하면 더 쉬운 경로를 선택하므로, 서브 에이전트를 쓰지 않으면 “품질이 저하된 경험”이라고 명시하는 것이 호출을 유도한다.

4. 기법 2 — 금지 목록이 아니라 발산을 강제하기

특정 선택을 금지하는 방식은 모델의 창의성을 넓히지 못한다. 예측된 선택을 폐기하고 외부의 예상치 못한 시드를 주입해야 한다.

4.1. 안티 어트랙터(anti-attractor)

1. 금지의 한계

   1. “Space Grotesk를 사용하지 말라”고 하면 모델은 같은 잠재 클러스터 안의 다음 폰트를 선택한다.
   2. 금지 목록은 모델을 기존 클러스터 밖으로 끌어내지 못한다.
   3. 디자인이 조금 달라질 뿐 전체 웹이 같은 패턴으로 수렴하는 문제는 남는다.

2. 예상 밖의 시드

   1. 사용자의 입력이나 외부 스크립트가 모델이 예상하기 어려운 값을 만든다.
   2. 모델은 그 시드를 출발점으로 새로운 방향을 탐색한다.
   3. Impeccable은 프로젝트 시작 시 color.js를 실행해 100개 이상의 손으로 고른 기본 색상에서 시드를 선택한다.

4.2. 발산을 만드는 세 방법

1. 예측된 선택 깎아내기

   1. 모델에게 상위 세 개 폰트를 먼저 말하게 한다.
   2. 그 선택을 버리라고 지시하면 다음 토큰 예측 선택을 세 번 연속 건너뛸 수 있다.
   3. 간단하지만 결국 다시 수렴할 수 있는 제한적인 기법이다.

2. 많이 생성하고 별도 에이전트가 순위를 매기기

   1. 같은 아이디어만 반복되는 셰이더 라이브러리를 만들 때 100개의 후보를 생성한다.
   2. 유명인을 창의적 시드로 사용해 “Rihanna라면 어떤 셰이더일까?”, “Beyoncé라면 어떤 셰이더일까?”처럼 모델이 낯선 연결을 하게 한다.
   3. 이전 컨텍스트를 모르는 서브 에이전트가 후보 전체의 순위를 매기므로 생성 모델의 초기 선호가 평가를 지배하지 않는다.

3. 스크립트 기반 시드

   1. 스크립트가 무작위 색상 팔레트의 시작점을 선택한다.
   2. 모델은 시드를 바탕으로 전체 팔레트를 만들고, 사용자는 결과가 마음에 들지 않으면 다시 선택할 수 있다.
   3. 같은 브리프라도 사용자 입력과 색상 스크립트 결과에 따라 전혀 다른 디자인이 나오게 한다.

5. 기법 3 — 단일 스킬을 Mixture of Experts로 라우팅하기

모든 규칙을 하나의 긴 파일에 넣으면 서로 충돌하고 instruction following 품질이 흐려진다. 작업 종류에 따라 전문 스킬을 선택해야 한다.

5.1. 범용 규칙의 충돌

1. 랜딩 페이지는 개성이 강한 폰트와 브랜드 표현을 원할 수 있다.
2. 제품 UI는 사용자가 익숙하게 느끼도록 시스템 폰트와 일관된 패턴을 원하는 경우가 많다.
3. 하나의 파일에 “시스템 폰트를 피하라”와 “제품 UI에서는 시스템 폰트를 써라”를 모두 넣으면 모델은 조건을 제대로 분리하지 못한다.
4. 거대한 if-else 블록은 토큰을 낭비하고 중요한 지침을 흐린다.

5.2. 내부 라우터와 전문 스킬

1. impeccable critique, impeccable polish 같은 명령은 서로 다른 Markdown 스킬을 로드한다.
2. 브리프를 보고 브랜드 디자인인지 제품 디자인인지 분류한다.
3. 브랜드 디자인에는 주목도와 개성을 위한 규칙을, 제품 디자인에는 네이티브함과 사용성을 위한 규칙을 적용한다.
4. 이 구조는 멀티툴 스킬, 온디맨드 컨텍스트, 대상별 에이전트 툴킷에도 적용된다.

6. 기법 4 — 스킬에 장기 메모리를 부여하기

기본 스킬은 매 실행마다 처음부터 시작하지만, 실행 결과를 폴더에 저장하면 여러 세션의 작업이 누적된다.

6.1. 이전 비평을 다음 작업의 컨텍스트로 사용하기

1. Impeccable의 critique 결과를 스킬 폴더의 파일로 저장한다.
2. 나중에 polish를 요청하면 다른 세션에서도 이전 비평을 읽어 무엇이 발견됐는지 파악한다.
3. 이전 비평에서 사용자가 특정 지적에 동의하지 않았다고 기록하면, 다음 작업에서는 그 선택을 사용자 선호로 존중한다.
4. 실행 이력이 페이지의 변화 과정과 사용자 취향을 함께 보존한다.

6.2. 복합 엔지니어링과 재개 가능한 작업

1. 세션마다 컨텍스트를 새로 만드는 대신, 여러 세션에 걸쳐 작업을 재개할 수 있다.
2. 대규모 리팩터링은 한 번에 전체 코드베이스를 넣지 않고 한 세션에 하나의 TSX 파일을 처리한다.
3. 해당 파일과 연결된 파일을 수정하고 다음 세션에 상태를 넘기면, 작업이 파일 단위로 누적된다.
4. 긴 마이그레이션, 진행률 추적, 재개 가능한 에이전트에 특히 유용하다.

7. 기법 5 — 스크립트가 모델에게 직접 말하게 하기

긴 프롬프트에 규칙을 묻어 두기보다 실행 시점의 상태를 스크립트가 확인하고 표준 출력으로 다음 행동을 명시하게 하면 약한 모델도 더 잘 따른다.

7.1. 동적 컨텍스트 조립

1. Impeccable은 호출될 때마다 context.mjs를 실행한다.
2. 저장소에 product.md가 있으면 대상 사용자와 제품 목표를 읽고, design.md와 함께 세션에 삽입한다.
3. 파일이 없으면 무엇이 없고 어떻게 해야 하는지를 구조화된 JSON으로 알려 준다.
4. 최신 버전이 있으면 사용자에게 업데이트 여부를 묻도록 정확한 다음 단계를 출력한다.

7.2. 표준 출력과 캐싱의 교환

1. 스크립트의 표준 출력과 종료 상태는 모델이 일반 prose 규칙보다 강하게 따르는 실행 지침이 된다.
2. 환경 인식 초기화, 저장소 상태 게이트, 동적 온보딩, 적응형 흐름을 만들 수 있다.
3. 단점은 동적 실행 결과가 프롬프트 캐시를 깨뜨린다는 점이다.
4. 반복 실행에서 전체 컨텍스트를 캐시해야 한다면 부적절하지만, 상호작용형 스킬의 방향을 유지하는 데는 효과적이다.

8. 기법 6 — 사용자가 잊어도 작동하는 훅

명령은 사용자가 기억해야 하지만 훅은 모든 편집에 자동으로 작동한다. 스킬의 규칙을 수동 호출이 아니라 피드백 루프로 만든다.

8.1. 디자인 린트 훅

1. Impeccable은 설치 시 Claude Code, Cursor, Codex, GitHub Copilot에 디자인 훅을 연결한다.
2. 모든 편집 때 훅이 실행되어 디자인 시스템 위반을 감시한다.
3. 약한 모델은 파일을 쓴 뒤 경고를 받아도 수정하지 않을 수 있으므로, 일부 환경에서는 post-tool-use 대신 파일 쓰기 전의 pre-tool-use 훅으로 차단한다.
4. 규칙은 개인 디자인 시스템, ESLint, 구문 가이드라인, 코드 리뷰 정책에도 맞출 수 있다.

8.2. 수동 명령보다 수동적 가드레일

1. “작업이 끝난 뒤 Impeccable을 실행하라”는 명령은 쉽게 잊힌다.
2. 모든 편집을 감시하는 훅은 사용자가 호출하지 않아도 올바른 레인으로 되돌린다.
3. Gemini가 모든 이미지에 애니메이션과 hover zoom을 넣는 경향처럼 모델별 반복 오류를 조용히 지적하고 모델이 스스로 수정하게 할 수 있다.
4. 훅에는 오탐이 생기므로 파일·CSS 규칙 단위의 ignore 설정이 필요하다.

9. 기법 7 — 하니스의 브라우저를 실시간 UI로 연결하기

채팅창만으로 픽셀을 조정하기 어렵다면, 하니스에 내장된 브라우저를 사용자와 에이전트가 함께 쓰는 시각적 조종면으로 바꿀 수 있다.

9.1. 라이브 모드의 연결 구조

1. Codex Desktop, Cursor 같은 하니스의 인앱 브라우저에 개발 서버를 띄운다.
2. 작은 임시 서버가 개발 페이지에 스니펫을 삽입한다.
3. 사용자가 페이지에서 요소를 선택하거나 주석을 남기면 Server-Sent Events로 임시 서버에 이벤트를 보낸다.
4. 임시 서버가 종료되면서 표준 출력에 이벤트를 남긴다.
5. 메인 에이전트는 표준 출력을 읽고 어떤 요소의 디자인을 바꿔야 하는지 판단한다.
6. 에이전트가 결과를 다시 서버에 보내면 브라우저에서 즉시 변형안을 확인할 수 있다.

9.2. 사용자 경험

1. 페이지에서 아무 요소나 선택한다.
2. 디자인 스킬의 하위 명령과 원하는 변형 수를 고른다.
3. 선택 신호가 채팅 스레드로 돌아가면 에이전트가 해당 요소를 특수 태그로 감싼다.
4. CSS로 표시된 여러 변형을 브라우저에서 직접 비교하고, 마음에 드는 안은 accept, 아닌 안은 Escape로 취소한다.
5. 요소 삽입, 화면 위 드로잉, 주석, 음성 지시도 같은 루프에 연결할 수 있다.
6. HTML은 Markdown보다 디자인 상태를 시각화하는 데 적합하므로, design.md도 브라우저에서 렌더링해 활용할 수 있다.

10. 기법 8 — ‘내 컴퓨터에서는 됐다’ 문제를 하니스별로 해결하기

공유 스킬은 각 하니스의 권한 모델·도구·백그라운드 작업·모델 편향이 다르다는 사실을 전제로 배포해야 한다.

10.1. 하니스별 기능 차이

1. 서브 에이전트: Claude는 프로그래밍 방식으로 쉽게 생성할 수 있지만 Codex는 사용자 권한이 필요하고 Cursor는 에이전트가 선택하는 경우가 많다.
2. 사용자 질문 도구: Claude의 선택형 질문 도구는 편리하지만 Codex의 질문 도구는 Plan mode에서만 사용할 수 있다.
3. 백그라운드 작업: Claude는 백그라운드 작업이 끝나면 모델을 깨울 수 있지만 Codex는 완료 후 수동 확인이 필요할 수 있다.
4. 실시간 작업: Cursor나 Codex의 라이브 모드는 채팅 스레드를 막는 foreground task로 실행해야 안정적일 수 있다.
5. 파일 감시: Tail watch 같은 로그 감시 기능은 있지만 하니스마다 throttling과 이벤트 전달 방식이 다르다.
6. 설치: 일반적인 패키지 설치기는 한 디렉터리를 여러 하니스에 복사하거나 심볼릭 링크하므로 하니스별 빌드와 훅 배치가 깨질 수 있다.

10.2. 모델별 과적합과 대처

1. Gemini는 이미지에 애니메이션과 hover zoom을 넣는 경향이 있다.
2. Codex는 나쁜 자간, 지나치게 둥근 테두리, 불필요한 hairline border를 좋아한다.
3. 같은 규칙을 모든 모델에 적용하면 한 모델의 편향을 막는 문장이 다른 모델의 행동을 반대로 뒤집을 수 있다.
4. Impeccable은 모델과 하니스별 치환 변수를 사용해 전용 사용자 질문 도구, XML 블록, 편향 회피 지침을 삽입한다.

10.3. 가장 약한 모델을 기준으로 설계하기

1. 약한 모델은 의견을 갖지 못하는 것이 아니라, 긴 지침을 끝까지 지키는 규율이 약하다.
2. GPT-5 mini처럼 규칙 준수가 약한 모델은 긴 스킬의 특정 MD 파일을 로드하거나 라이브 모드를 실행하지 않을 수 있다.
3. Codex/GPT가 좋아하는 “gate”를 활용해 각 단계의 결과를 잠그고, 통과 여부를 기록하게 한다.
4. 규칙을 압축하면 모델은 1·2·5단계만 했다고 넘어갈 수 있으므로, 모든 게이트를 통과했다는 결과를 개별적으로 저장하게 해야 한다.
5. 게이트를 건너뛸 수 있다면 모델은 반드시 건너뛴다. 따라서 중요한 검증은 선택 가능한 문장이 아니라 실행 불가능한 상태 전이로 만들어야 한다.

11. 기법 9 — 평가 하니스로 스킬을 검증하기

공유 스킬은 “내가 써 보니 좋다”를 넘어 여러 모델·하니스·도메인에서 반복 검증되어야 한다.

11.1. Impeccable의 평가 구조

1. Claude Code SDK, Codex, Gemini 등 관심 있는 하니스의 조건과 도구를 재현한다.
2. 브라우저 스크린샷과 대화형 사용자 응답을 포함해 실제 초기화 과정을 모사한다.
3. 별도의 LLM이 사용자를 연기해 질문과 답변이 필요한 상호작용을 테스트한다.
4. Mixture of Expert 디자인 심사자가 결과를 시각적으로 평가한다.
5. 이탈리아 레스토랑 등 약 20개 도메인에서 GPT-5.5, Opus, Sonnet 등 여러 모델을 반복 실행한다.
6. 각 릴리스에서 경쟁 스킬과 비교하고, 결과가 좋아졌는지 나빠졌는지 확인한다.

11.2. 어블레이션 테스트

1. 스킬의 모든 규칙에 고유 XML ID를 부여한다.
2. 한 줄을 제거한 버전과 원본을 각각 모든 모델에 실행한다.
3. 결정적 디자인 검출기로 결과 차이를 측정한다.
4. “색이 있는 배경에 회색을 쓰지 말라” 같은 단일 규칙이 실제로 효과가 있는지 확인한다.
5. 초기에는 바이브 기반이었던 스킬을 규칙 단위로 실험된 시스템으로 바꾼다.

11.3. 취향(taste)은 완전히 자동 평가하기 어렵다

1. 대비·첫 화면에 핵심 콘텐츠가 있는지 같은 기능적 속성은 모델이 평가할 수 있다.
2. 그러나 취향은 개인의 경험과 상처, 고유한 감각에 가깝다.
3. 모두가 같은 취향을 사용하면 그것은 곧 보편적인 패턴이 되어 더 이상 세련되게 느껴지지 않는다.
4. 모델은 첫 화면에 요소를 많이 넣을수록 좋은 점수를 주는 식의 최대주의 편향을 보인다.
5. 따라서 모델 심사자의 점수를 그대로 믿지 않고, 경우에 따라 응답을 역전하거나 사람이 직접 결과를 보고 주석을 달아야 한다.

12. 배포와 스킬의 미래

스킬의 범위가 하니스 통합 기능을 넘어가면, 일급(first-party) 도구와 표준화된 배포·평가가 필요해진다.

12.1. 스킬 플랫폼의 한계

1. Impeccable의 라이브 모드는 스킬만으로 가능한지 실험한 Jurassic Park식 실험이었다.
2. 작동하지만, 일급 하니스 통합이나 전용 도구라면 더 안정적이고 자연스러웠을 기능이 많다.
3. 대부분의 개인용 스킬은 작성자가 직접 쓰면 충분하지만, 다른 사람에게 패키징해 배포하는 스킬은 훨씬 높은 검증 비용을 감당해야 한다.
4. 작성자가 쓰지 않은 모델에서 작동하지 않는 스킬은 생태계의 신뢰를 떨어뜨리므로, 적은 수라도 전투 검증된 스킬을 배포하는 편이 낫다.

12.2. MCP와 배포 표준의 문제

1. MCP 서버에서 스킬을 제공하면 편리하지만, 컨텍스트 오염(context pollution)이 커질 수 있다.
2. Codex와 Claude Code는 각자의 마켓플레이스를 제공하지만 업데이트와 캐시가 안정적이지 않을 수 있다.
3. skills.sh 같은 공통 배포 프로젝트는 여러 공급자를 가로지를 수 있지만, 하니스별 컴파일과 고급 설치 구조를 충분히 지원하지 못한다.
4. Microsoft 등도 표준화를 시도하고 있지만, 현재 업계 공통 배포 표준은 없다.
5. Impeccable은 설치 위치와 훅을 하니스별로 정확히 배치하기 위해 자체 CLI와 컴파일러를 유지한다.

주요 발언 모음

“프롬프트는 시작 단계이고, 하니스 엔지니어링이 도착해야 할 곳이다.”

“두 개의 맹목적인 의견이 하나의 자신만만한 추측보다 낫다.”

“금지는 모델을 잠재 공간 안에서 옮길 뿐이다.”

“패시브 가드레일은 아무도 기억하지 못하는 명령보다 낫다.”

“약한 모델은 의견을 잃는 것이 아니라, 당신의 지침을 따르는 규율을 잃는다.”

“게이트를 건너뛸 수 있다면 모델은 건너뛴다.”

“스킬을 배포하려면 작성자가 사용한 모델이 아닌 모델에서도 작동하는지 검증해야 한다.”

핵심 데이터 & 수치

• 초기 스킬: 약 55줄 프롬프트와 규칙만으로 시작했다.
• 색상 시드: Impeccable의 color.js에는 100개가 넘는 수작업 색상 시드가 있다.
• 평가 범위: 약 20개 도메인과 여러 모델에서 릴리스별로 5~10회 테스트한다.
• 독립 평가: 디자인 디렉터 관점과 결정적 브라우저 검사 관점을 별도 서브 에이전트로 분리한다.
• 지원 하니스: Claude Code, Codex, Cursor, Gemini, GitHub Copilot 등을 하니스별로 다룬다.
• 오픈소스: Impeccable은 Apache 2.0 라이선스로 공개되며 자체 CLI 설치기를 제공한다.

결론 및 시사점

1. 프롬프트를 제품으로 착각하지 말라: 규칙을 적는 일은 시작일 뿐이며, 실행·검증·기억·배포를 함께 설계해야 한다.
2. 서로 독립된 평가를 만들라: 모델에게 자기 결과를 평가시키지 말고, 다른 시선과 결정적 검사를 분리한 뒤 합성하라.
3. 금지 대신 외부 시드를 넣어라: 모델의 익숙한 선택을 차단하는 것보다 예측하기 어려운 입력으로 발산을 유도하는 편이 효과적이다.
4. 하나의 거대한 스킬은 라우터로 분해하라: 브랜드, 제품, 리뷰, 폴리시처럼 목적별 지침을 독립시키면 규칙 충돌과 컨텍스트 낭비가 줄어든다.
5. 실행 결과를 기억하라: 이전 비평·사용자 선호·진행 상태를 파일로 남기면 여러 세션에 걸쳐 작업이 누적된다.
6. 스크립트와 훅을 적극 활용하라: 동적 상태는 스크립트가 계산하고, 반복 위반은 훅이 자동으로 차단해야 한다.
7. 하니스의 기능을 UX로 연결하라: 브라우저·표준 출력·백그라운드 작업·이벤트를 묶으면 채팅창을 넘어선 상호작용이 가능하다.
8. 가장 약한 모델부터 검증하라: 강한 모델에서만 작동하는 스킬은 배포 가능한 제품이 아니다.
9. 건너뛸 수 있는 단계는 실행되지 않는다고 가정하라: 게이트 결과, 권한, 파일 상태를 구조화해 검증을 강제하라.
10. 스킬 생태계는 품질 기준을 높여야 한다: 적은 수의 재현 가능하고 모델·하니스별로 검증된 스킬이 무작정 많은 미검증 스킬보다 가치 있다.