프롬프트를 넘어선 스킬 엔지니어링의 비기

원문 제목: [한영자막] 스킬 엔지니어링의 숨겨진 비기(Dark Arts)를 소개합니다 — Paul Bakaus (Impeccable) 원문 URL: https://www.youtube.com/watch?v=LXdWUZYzins 날짜: 2026-09-27 채널: Tech Bridge 발표자: Paul Bakaus 자막: YouTube 영어 자동 자막(한국어 번역·의역) 영상 길이: 약 64분 24초 핵심 프로젝트: Impeccable — https://impeccable.style/ 관련 저장소: https://github.com/pbakaus/impeccable-talks

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트에게 좋은 문장을 입력하는 것만으로는 좋은 스킬을 만들 수 없다. 스킬을 사용하는 하네스의 기능·모델·상태·피드백 루프까지 설계해야 일관되고 결정론적인 결과가 나온다.==

• 프롬프트의 금지 목록은 모델을 창의적으로 만들기보다 잠재공간의 다음 유행 클러스터로 이동시킬 뿐이다.
• 서로 보지 못한 하위 에이전트의 적대적 검토, 결정론적 스크립트, 훅, 브라우저 연결, 세션 간 메모리가 판단 품질을 보완한다.
• 스킬을 여러 하네스와 여러 모델에 배포하려면 모델별·하네스별 빌드와 약한 모델을 위한 게이트가 필요하다.
• taste처럼 본질적으로 인간적인 판단은 자동 평가가 완전히 대체할 수 없으므로, 자동 평가는 첫 번째 필터로 두고 사람이 최종 판단해야 한다.

Impeccable은 한때 약 55줄의 프롬프트와 금지 문장으로 시작했다. 그러나 에이전트가 만드는 결과를 디자인 시스템으로 되돌리는 일, 같은 스타일의 반복을 피하는 일, 모델마다 다른 지시 이행 방식에 대응하는 일이 단순한 문장으로 해결되지 않았다. 그래서 스킬을 여러 전문 하위 스킬, 스크립트, 메모리, 훅, 브라우저 기반 상호작용, 모델별 규칙을 가진 작은 하네스로 확장했다. 핵심 전환은 “스킬은 포장된 프롬프트”라는 생각을 버리고 “사용 중인 에이전트 하네스의 능력을 확장하는 프로그램”으로 보는 데 있다.

1. 출발점: 프롬프트만으로는 AI 슬롭을 이길 수 없다

1.1. Impeccable이 만들어진 배경

1. 빠른 생성과 디자인 시스템 복귀 사이의 간극

   1. Paul Bakaus는 대형 엔터프라이즈 앱을 만들면서 여러 화면과 상태를 빠르게 설계하기 위해 에이전트와 코딩 하네스를 사용했다.
   2. 에이전트는 곧바로 볼 수 있는 결과물을 만들었지만, 결과를 기존 디자인 시스템에 맞게 정규화하는 과정은 매우 어려웠다.
   3. 첫 개인용 스킬인 normalize는 에이전트가 만든 화면을 디자인 시스템으로 되돌리는 역할을 했다.
   4. Anthropic의 프런트엔드 디자인 스킬을 출발점으로 삼은 뒤, 디자인·비평·다듬기 기능을 하나씩 추가해 Impeccable로 확장했다.
   5. 이후 오픈 소스로 공개했고, 다른 사용자도 유용하게 쓸 수 있다는 사실을 확인했다.

2. 출발 당시의 한계

   1. 초기 스킬은 스크립트나 라우팅 없이 약 55줄의 프롬프트만 가진 순수한 지시문이었다.
   2. “일반적인 AI 미학을 쓰지 말라”, “Inter·Roboto·Arial·시스템 폰트를 피하라”, “보라색 그라디언트와 흰 배경을 피하라”, “Space Grotesk 같은 흔한 선택으로 수렴하지 말라”는 식의 문장이 중심이었다.
   3. 가끔은 작동했지만 대부분은 모델이 지시를 자기 방식으로 재해석하거나 무시했다.

1.2. ‘슬롭’은 고정된 시각 스타일이 아니다

1. 유행의 이동

   1. 한때 AI 생성물의 표식은 보라색 그라디언트였지만, 금지 규칙이 퍼진 뒤에는 베이지 배경과 기울임꼴 세리프, 대문자 히어로 문구, 상단의 eyebrow/kicker 라벨이 반복되는 “클로 베이지(Claw beige)”가 새로운 표식이 됐다.
   2. 가짜 어린이용 iPad 리더 앱을 예로 들면, 그 디자인 자체가 나쁜 것은 아니지만 너무 많은 AI 생성물에서 같은 조합이 반복되기 때문에 즉시 AI 슬롭으로 인식된다.
   3. Tailwind의 기본 샘플 페이지가 보라색 테마를 널리 퍼뜨린 것처럼, 기본값은 인터넷 전체의 시각적 중력을 만든다.
   4. 과거 jQuery UI의 첫 기본 테마를 주황색으로 만들었을 때도 사용자가 테마를 바꿀 것이라 생각했지만, 실제로는 웹 전체가 주황색으로 보이게 됐다.

2. 금지 목록의 구조적 실패

   1. 특정 폰트나 색상을 금지하면 모델은 더 창의적인 공간으로 이동하지 않고 잠재공간 안의 다음으로 가까운 선택지로 옮겨 간다.
   2. “Space Grotesk를 쓰지 말라”는 규칙은 “비슷하게 인기 있는 다른 폰트”를 고르게 할 뿐이다.
   3. 모델이 가장 높은 확률로 고르는 중앙값, 즉 모델의 중력은 정교한 250줄의 산문으로도 쉽게 바뀌지 않는다.
   4. 따라서 문제는 더 강한 주문을 쓰는 데 있지 않고, 모델이 기본 선택지에서 벗어나도록 외부 신호와 실행 구조를 공급하는 데 있다.

2. 첫 번째 비기: 한 모델의 자신감을 깨고 서로 논쟁시키기

2.1. 자기 검토가 실패하는 이유

1. 자기가 만든 결과를 높게 평가하는 앵커링

   1. Codex나 Claude Code에 자기 작업을 검토하라고 하면 대체로 높은 점수를 준다.
   2. 이미 만든 결과에 판단이 고정되어 “내가 만들었고 잘했으니 좋은 결과”라는 식의 자기 채점이 된다.
   3. 코드 리뷰, 디자인 리뷰, 보안 감사, 계획서·RFC 검토 모두 같은 자기 확증 문제를 가진다.

2. 결정론적 검사만으로도 충분하지 않은 이유

   1. Impeccable의 결정론적 디자인 린터는 낮은 대비, 너무 많은 폰트, 요소가 가장자리에 지나치게 붙은 문제처럼 측정 가능한 polish 오류를 찾는다.
   2. 아름답지만 측정 가능한 오류가 500개인 페이지를 같은 스레드에서 평가하면, 모델은 오류 개수만 보고 전체 디자인이 나쁘다고 결론낼 수 있다.
   3. 반대로 비어 있거나 형편없는 페이지는 결정론적 규칙을 위반하지 않을 수 있고, 모델은 “발견된 문제가 없으니 좋은 디자인”이라고 오판할 수 있다.

2.2. 두 개의 눈먼 하위 에이전트

1. 역할을 분리한 적대적 검토

   1. 첫 번째 하위 에이전트는 디자인 디렉터 역할을 맡아 브라우저 도구로 계층 구조, AI 슬롭, 휴리스틱, 사용자 경험을 사람처럼 평가한다.
   2. 두 번째 하위 에이전트는 결정론적 검사기를 실행하고 브라우저 증거를 수집한다.
   3. 두 하위 에이전트는 서로의 결과를 보지 못한다. 한쪽의 확신이나 표현이 다른 쪽의 판단을 오염시키지 않도록 하는 장치다.
   4. 메인 스레드는 두 결과를 받은 뒤 종합해 균형 잡힌 비평을 만든다.

2. 재사용 가능한 패턴

   1. 서로 독립적인 두 관점은 하나의 자신만만한 추측보다 강하다.
   2. 코드 리뷰에서는 사람이 읽는 구조적 평가와 테스트·린터 출력을 분리할 수 있다.
   3. 보안 감사에서는 공격자 관점과 정적 분석 결과를 독립적으로 수집할 수 있다.
   4. 계획서나 RFC에서는 복수의 LLM 심사자가 서로의 초안에 끌리지 않은 상태로 평가한 뒤 최종 에이전트가 순위를 종합할 수 있다.

3. 하네스 권한이라는 현실 제약

   1. Claude Code는 하위 에이전트를 프로그램 방식으로 쉽게 만들 수 있지만, Codex는 사용자가 명시적으로 요청한 경우에만 하위 에이전트를 사용할 수 있다.
   2. 따라서 배포 가능한 스킬이 Codex에서 자동으로 두 에이전트를 만들 것이라고 가정하면 실패한다.
   3. 가능한 하위 에이전트 기능이 있지만 권한이 없으면 작업을 멈추고 사용자에게 허락을 요청하도록 지시해야 한다.
   4. “하위 에이전트를 쓰지 않으면 성능이 저하된 경험을 제공하게 된다”고 명시하면, 쉬운 경로를 택하려는 모델이 권한을 요청할 가능성이 커진다.
   5. 스킬이 하네스마다 다른 권한 모델을 고려하지 않으면, 같은 명령이 어떤 환경에서는 균형 잡힌 비평을 만들고 다른 환경에서는 단일 모델의 자기 평가로 축소된다.

3. 두 번째 비기: 금지 대신 반끌개로 잠재공간에서 탈출시키기

3.1. 안티-어트랙터(anti-attractor)의 원리

1. 금지 규칙의 한계

   1. 모델에게 특정 선택을 금지하면 선택 공간 전체가 바뀌는 것이 아니라, 같은 클러스터 안에서 다음 확률 높은 선택으로 이동한다.
   2. 이것이 “보라색 그라디언트 금지 후 클로 베이지”처럼 슬롭의 스타일만 이동하는 이유다.

2. 예상하지 못한 씨앗 공급

   1. 안티-어트랙터는 사용자의 입력이나 스크립트가 만든 무작위 씨앗을 모델에 제공해 다음 토큰 예측의 익숙한 경로를 끊는다.
   2. 씨앗은 완성된 답이 아니라 완전히 다른 방향을 열어 주는 출발점이어야 한다.
   3. 같은 요구사항이라도 사용자 입력, 무작위 색상 씨앗, 선택된 변형 수에 따라 결과가 크게 달라지도록 설계한다.

3.2. 세 가지 탈출 기법

1. 안전한 선택지를 깎아내기(shave the safe picks)

   1. 모델에게 상위 세 개의 폰트를 먼저 제시하게 한다.
   2. 그 세 선택을 버리라고 한 뒤 다시 선택하게 한다.
   3. 이 과정을 세 번 반복하면 모델이 처음 예측한 다음 토큰에서 멀어져 잠재공간의 더 먼 영역으로 이동한다.
   4. 다만 결국 다시 수렴할 수 있으므로 제한적인 기법이다.

2. 대량 생성 후 독립 순위 매기기

   1. 셰이더 라이브러리인 Radiant Shaders를 만들 때 새 셰이더 열 개를 요청할 때마다 같은 아이디어가 반복되는 문제가 있었다.
   2. Rihanna나 Beyoncé라면 어떤 셰이더가 될지 묻는 방식으로 예상 밖의 창의적 씨앗을 넣었다.
   3. 그런 씨앗으로 100개의 아이디어를 생성한 다음, 이전 대화 맥락을 모르는 하위 에이전트가 전체를 순위 매기게 했다.
   4. 새 하위 에이전트는 앞에서 생성한 순서나 모델의 직전 선호에 끌리지 않으므로 반복성을 줄인다.

3. 스크립트가 만드는 무작위 씨앗

   1. Impeccable은 프로젝트를 시작할 때 color.js를 실행한다.
   2. 이 스크립트에는 완성된 팔레트가 아니라 손으로 고른 100개 이상의 기본 색상이 있다.
   3. 모델은 그중 하나를 창작의 불씨로 삼아 주변 팔레트를 만들고, 사용자가 마음에 들지 않으면 다른 방향을 요청할 수 있다.
   4. 중요한 점은 무작위 결과를 최종 정답으로 강요하는 것이 아니라, 기본 선택과 다른 출발점을 제공하는 데 있다.

4. 세 번째 비기: 하나의 거대한 스킬 대신 내부적으로 라우팅되는 전문가 혼합

4.1. 컨텍스트가 늘어날수록 지시가 흐려지는 문제

1. 거대한 if/else 프롬프트의 실패

   1. 일반 목적 스킬에 기능을 계속 추가하면 모델이 어떤 규칙을 현재 작업에 적용해야 하는지 구분하기 어려워진다.
   2. “랜딩 페이지면 이 규칙, 제품이면 저 규칙”을 하나의 문서 안에 거대한 if/else 블록으로 넣으면 토큰을 낭비하고 지시 이행도 약해진다.
   3. Anthropic의 이전 프런트엔드 디자인 스킬이 랜딩 페이지에는 적절한 “시스템 폰트를 피하라”는 규칙을 제품 UI에도 적용하면 문제가 된다.
   4. 제품 UI는 운영체제와 자연스럽게 느껴지도록 시스템 폰트를 써야 할 때가 많기 때문이다.

2. 전문 기능별 진입점

   1. Impeccable은 critique, polish 같은 명령을 별도 하위 스킬로 분리한다.
   2. 호출된 작업에 맞는 MD 파일만 뒤에서 로드하므로 하나의 거대한 SKILL.md가 모든 지시를 들고 있지 않다.
   3. 복수의 도구를 가진 스킬, 필요할 때만 컨텍스트를 불러오는 스킬, 사용자 유형·행동별 에이전트 툴킷에도 같은 구조를 적용할 수 있다.

4.2. 브랜드 디자인과 제품 디자인의 내부 라우팅

1. 서로 다른 레지스터

   1. 브랜드 디자인은 시선을 끌고 개성을 표현하는 랜딩 페이지에 가깝다.
   2. 제품 디자인은 반복 사용, 네이티브함, 기능적 명료성이 중요하다.
   3. 같은 “예쁜 화면”이라는 목표 아래 두 작업을 묶으면 시스템 폰트·색상·정보 밀도에 대한 규칙이 충돌한다.

2. 브리프에 따른 자동 선택

   1. Impeccable은 사용자의 브리프와 입력을 바탕으로 브랜드를 만드는지 실제 제품을 만드는지 판별한다.
   2. 판별 결과에 따라 완전히 다른 규칙 집합을 로드해 두 디자인 레지스터를 분리한다.
   3. “전문가 혼합(Mixture of Experts)”처럼 각 하위 스킬은 특정 작업에 최적화되고 라우터가 적합한 전문가를 고른다.

5. 네 번째 비기: 스킬에 장기 기억을 부여해 실행을 누적시키기

5.1. 기본 스킬의 무기억성

1. 세션이 끝나면 사라지는 판단

   1. 스킬은 기본적으로 장기 메모리가 없고, 이전 실행의 발견과 사용자 선호를 자동으로 누적하지 않는다.
   2. 하지만 스킬 폴더나 현재 저장소에 파일을 저장하면 세션을 넘어 실행을 이어갈 수 있다.
   3. Claude에는 스킬 디렉터리를 가리키는 환경 변수가 있지만, 다른 하네스에서도 현재 저장소의 전용 폴더를 사용하는 방식으로 우회할 수 있다.

2. 비평을 다음 작업의 입력으로 만들기

   1. Impeccable의 비평 결과는 저장소 안의 전용 파일로 기록되고 기본적으로 Git에서 무시된다.
   2. 이후 다른 세션에서 polish를 실행하면 기존 비평을 읽어 어떤 문제가 발견됐고 페이지가 어떻게 변했는지 확인한다.
   3. 과거 비평을 모두 보면서 개선의 진행 상황을 추적할 수 있다.

5.2. 사용자 선호와 복합 엔지니어링

1. 반대 의견도 기억하기

   1. 사용자가 “이 비평에는 동의하지 않는다. 내 Instrument 폰트가 마음에 든다”고 말하면 그 판단을 사용자 선호로 기록할 수 있다.
   2. 다음 실행부터는 같은 폰트를 오류로 되돌려 지적하지 않고 선호를 존중한다.
   3. 비평을 매번 처음부터 반복하는 대신 사용자와 스킬이 함께 학습하는 컨텍스트가 생긴다.

2. 재개 가능한 실행

   1. 여러 세션에 걸친 리팩터링, 마이그레이션, 진행률 추적, 재개 가능한 에이전트에 같은 패턴을 적용할 수 있다.
   2. 예를 들어 한 번에 전체 코드베이스를 바꾸지 않고 오늘 담당할 TSX 파일 하나를 정해 그 파일과 연결된 코드를 리팩터링한다.
   3. 다음 세션은 이전 작업의 파일·결정·진행 상태를 읽고 다음 파일로 이동한다.
   4. 작은 실행의 결과가 다음 실행의 컨텍스트가 되어 전체 작업이 누적된다.

6. 다섯 번째 비기: 산문 속 규칙을 실행 가능한 출력으로 끌어내기

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

1. 배포 환경의 모델은 제각각이다

   1. 개인이 하나의 강한 모델만 쓸 때는 지시가 대체로 작동하는지 확인하기 쉽다.
   2. 공개 스킬에는 Sonnet, Haiku, Grok, Gemini 등 다양한 모델이 들어오며, 모델마다 긴 규칙 문서를 읽고 따르는 능력이 다르다.
   3. GPT-5 mini 같은 약한 모델은 특정 MD 파일을 로드하지 않거나 라이브 모드를 시작하지 않는 등 긴 스킬에서 지시를 놓칠 수 있다.
   4. 따라서 스킬은 가장 강한 모델이 아니라 지시 이행이 가장 약한 모델을 기준으로 설계해야 한다.

2. 산문보다 표준 출력이 강한 이유

   1. Impeccable의 context.mjs는 매 호출마다 실행된다.
   2. product.md가 있으면 대상 사용자와 달성하려는 목표 같은 제품 전략 컨텍스트를, design.md가 있으면 디자인 규칙을 읽어 세션에 넣는다.
   3. 파일이 없을 때는 단순히 “파일이 없다”고 말하지 않고, 다음에 무엇을 해야 하는지를 구조화된 JSON으로 출력한다.
   4. 새 버전이 있으면 사용자에게 업데이트 여부를 묻고 업데이트 방법까지 출력한다.
   5. 스크립트의 표준 출력이나 종료 결과로 전달된 구체적 지시는 메인 스킬의 긴 산문 속 임의의 규칙보다 모델이 훨씬 잘 따르는 경향이 있다.

6.2. 동적 지시의 이득과 비용

1. 적용할 상황

   1. 환경 인식형 설정, 동적 온보딩, 저장소 상태에 따른 분기, 조건부 실행, 다음 단계 안내에 특히 효과적이다.
   2. 모델이 반드시 확인해야 하는 전제와 다음 행동을 산문 속에 묻어두지 않고 실행 시점에 바로 꺼내 보여 준다.

2. 프롬프트 캐시와의 트레이드오프

   1. 스크립트 결과가 실행마다 달라질 수 있으므로 동적으로 삽입되는 지시는 전체 스킬의 정적 부분처럼 캐시하기 어렵다.
   2. 스킬 자체는 캐시될 수 있지만, 동적 셸 실행 결과가 포함된 부분은 캐시되지 않는다.
   3. 같은 스킬을 매우 자주 반복해 프롬프트 캐시 효율을 극대화해야 한다면 부적합할 수 있다.
   4. 반대로 상호작용이 많고 저장소·환경 상태에 따라 흐름이 달라지는 작업에서는 캐시 비용보다 지시 이행 개선이 더 크다.

7. 여섯 번째 비기: 사용자가 기억할 명령이 아니라 항상 작동하는 훅

7.1. 수동 명령의 망각을 피하는 피드백 루프

1. 스킬을 설치해도 호출하지 않는 문제

   1. 사용자는 Impeccable을 설치한 뒤에도 프런트엔드 작업 중 명시적으로 호출하지 않을 수 있다.
   2. 그러면 에이전트가 디자인 시스템을 따르지 않거나 금지된 패턴을 반복해도 스킬이 개입하지 못한다.
   3. 이 문제는 “명령을 더 잘 기억하라”가 아니라, 편집 이벤트마다 자동 검증이 들어가도록 설계해야 해결된다.

2. 훅이 하는 일

   1. Impeccable은 설치 시 Claude Code, Cursor, Codex, GitHub Copilot에 디자인 훅을 설치한다.
   2. 훅은 모든 편집에 반응하는 디자인 린터처럼 동작하며, 잘못된 대비나 불필요한 이미지 애니메이션 같은 위반을 에이전트에 되돌려 보낸다.
   3. 에이전트가 별도 명령을 기억하지 않아도 피드백 루프가 계속 작동한다.

7.2. pre-tool과 post-tool의 선택

1. 강한 모델의 사후 교정

   1. post-tool 훅은 에이전트가 파일을 쓴 직후 실행된다.
   2. “색상 대비가 나쁘다”, “이미지에 불필요한 호버 확대가 있다”는 피드백을 받은 뒤 모델이 스스로 고치게 한다.
   3. 강한 모델에서는 작성 후 교정이 충분히 잘 작동할 수 있다.

2. 약한 모델의 사전 차단

   1. Composer처럼 상대적으로 약한 모델은 post-tool 지시를 보고도 잘 고치지 못할 수 있다.
   2. pre-tool 훅은 파일 쓰기 전에 위반을 차단해 애초에 잘못된 코드가 저장되지 않게 한다.
   3. 더 무겁고 강압적인 방식이지만 특정 모델과 하네스 조합에서는 이 편이 안정적이다.

3. 사용자별 예외 처리

   1. 훅은 설계 시스템, ESLint 규칙, 구문 규칙, 코드 리뷰 정책에 맞게 확장할 수 있다.
   2. 자동 검사에는 오탐이 생기므로 파일 단위, CSS 규칙 단위 등 세밀한 ignore 규칙이 반드시 필요하다.
   3. 예외를 설정할 수 없으면 훅이 빠르게 성가신 방해물이 된다.
   4. 기억해야 실행되는 명령보다 수동 개입 없이 작동하는 수동적 가드레일이 더 강한 이유가 여기에 있다.

8. 일곱 번째 비기: 채팅창을 넘어 하네스의 브라우저를 라이브 와이어로 연결하기

8.1. 픽셀 작업을 텍스트 대화로만 할 수 없는 이유

1. 하네스 전체를 설계 공간으로 보기

   1. Codex Desktop, Cursor, Claude Code, GitHub Copilot에는 각기 다른 브라우저·스크린샷·백그라운드 실행 기능이 있다.
   2. 스킬은 프롬프트만 호출하는 대신 이런 기능을 조합해 사용자의 실제 작업 흐름을 개선해야 한다.
   3. 디자인처럼 시각적 피드백이 핵심인 문제는 채팅으로 픽셀을 설명하는 것보다 페이지에서 직접 선택하는 편이 빠르다.

2. Impeccable 라이브 모드의 구조

   1. MCP를 사용하는 대신 작은 로컬 서버를 실행하고 개발 서버에 스니펫을 삽입한다.
   2. 페이지에서 일어난 상호작용은 Server-Sent Events로 로컬 서버에 돌아온다.
   3. 이벤트 처리가 끝나면 로컬 서버 프로세스가 스스로 종료된다.
   4. 종료 시 표준 출력에 메시지를 남기면 메인 에이전트가 이를 읽고 다음 행동을 시작한다.
   5. 스킬 내부에는 특정 이벤트가 오면 선택한 영역을 특수 태그로 감싸고, 해당 영역의 변형을 만들고, 다시 브라우저로 보내라는 지시가 들어 있다.

8.2. 페이지에서 선택하고 결과를 즉시 비교하기

1. 선택과 변형

   1. 라이브 모드를 켜면 페이지 하단에 작은 바가 나타나고, 사용자는 화면의 어느 요소든 선택할 수 있다.
   2. 오버레이에서 critique, polish 같은 하위 명령과 원하는 변형 개수를 선택한다.
   3. 선택 이벤트가 메인 스레드에 전달되면 에이전트가 해당 요소를 표시하고 여러 CSS 변형을 생성한다.
   4. 변형을 클릭해 비교하고 마음에 들면 accept, 원치 않으면 Escape로 빠져나온다.

2. HTML을 인터페이스로 사용하기

   1. 요소 삽입, 화면 위에 그리기, 주석과 코멘트 남기기, 음성 받아쓰기까지 같은 브라우저 인터페이스에서 처리할 수 있다.
   2. 이러한 신호는 다시 메인 에이전트로 돌아가 페이지를 조정하는 지시가 된다.
   3. HTML은 단순 Markdown보다 시각적 상태와 관계를 표현하기에 적합하므로, 디자인 메타데이터나 분석 결과도 HTML로 보여 주면 유리하다.
   4. 핵심은 채팅과 앱 브라우저를 직접 연결해 사용자가 화면에서 피드백하고 에이전트가 코드로 응답하는 양방향 루프를 만드는 것이다.

9. 여덟 번째와 아홉 번째 비기: 모든 하네스에 컴파일하고, 약한 모델에는 건너뛸 수 없는 게이트를 준다

9.1. “내 컴퓨터에서는 작동했다”가 배포에서 깨지는 이유

1. 하네스별 기능 차이

   1. 하위 에이전트 생성은 Claude에서 프로그램 방식으로 쉽지만 Codex는 사용자 승인이 필요하고 Cursor는 대체로 에이전트가 선택한다.
   2. 사용자 질문 도구는 Claude에서 자연스럽지만 Codex의 유사 도구는 Plan 모드에서만 쓸 수 있다.
   3. Plan 모드가 아니라면 Codex는 질문을 표시하지 않고 문맥에서 추론해 버릴 수 있으므로, 스킬이 “추론하지 말고 멈춰서 질문하라”고 명시해야 한다.
   4. Claude의 백그라운드 작업은 완료 시 모델을 깨워 후속 처리를 하지만, Codex와 일부 하네스는 작업 완료를 자동으로 전달하지 않는다.
   5. 그래서 라이브 모드는 Cursor와 Codex에서 포그라운드 작업으로 실행해 채팅을 막는 대신, 완료 이벤트를 확실히 처리하도록 만든다.
   6. 파일 감시 도구의 존재와 throttling 정도, 편집 훅의 문법과 시점도 하네스마다 다르다.

2. 모델별 과적합 패턴

   1. Gemini는 이미지에 애니메이션을 붙이고 호버 확대를 만드는 경향이 강해, 원치 않으면 이미지 애니메이션 금지 규칙을 별도로 줘야 한다.
   2. Codex는 이유를 알기 어려울 정도로 나쁜 자간, 지나치게 둥근 모서리, 병원 사이트에도 적용할 법한 헤어라인 테두리를 선호한다.
   3. 이런 꼬리(tail)는 디자인뿐 아니라 아키텍처, 코드 구조, 선호 npm 패키지 선택에도 나타난다.
   4. 한 모델을 교정하는 문장을 모든 모델에 넣으면 다른 모델이 반대 방향으로 과잉 교정할 수 있다.

3. 하네스별·모델별 빌드

   1. Impeccable은 각 모델과 하네스에 맞는 빌드를 생성한다.
   2. 사용자 질문 도구를 고르는 치환 변수, Gemini·Codex 등에 맞는 XML 블록, 모델별 과적합 방지 규칙을 동적으로 삽입한다.
   3. 일반적인 NPX 스킬 설치기는 하나의 디렉터리를 모든 하네스에 복사하거나 심볼릭 링크하므로 이런 차이를 보존하지 못한다.
   4. 그래서 Impeccable은 자체 CLI 설치기와 컴파일러를 만들었다. 여러 하네스에 올바른 파일·훅을 설치하는 비용은 크지만, 실제 배포 안정성을 위해 감수할 가치가 있다.

9.2. 가장 약한 모델을 위한 불가역적 게이트

1. 모델이 건너뛸 수 있는 규칙은 반드시 건너뛴다

   1. 약한 모델도 의견을 만들 수 있지만, 사용자가 정한 절차를 끝까지 지키는 규율이 약하다.
   2. GPT 계열과 Codex는 “gate”라는 개념을 잘 따르므로, Codex 전용 지시 문서에 모든 단계를 게이트로 명시한다.
   3. 게이트를 압축해 “1·2·5단계만 했다”고 넘어가지 못하게 해야 한다.

2. 통과 상태를 기록하기

   1. 각 게이트가 끝날 때마다 성공 결과를 잠그고 “게이트 1 통과”처럼 기록한다.
   2. 다음 단계는 이전 게이트의 성공 기록이 있어야만 실행되도록 한다.
   3. 모델이 어려운 단계에서 빠져나갈 수 있는 우회로를 남겨두면 반드시 그 우회로를 택하므로, 핵심 절차를 선택 사항이 아닌 검증 가능한 상태 전이로 만들어야 한다.
   4. 프롬프트를 하네스 확장으로 바꾸는 마지막 단계는 문장을 늘리는 것이 아니라 실행·검증·기록을 건너뛸 수 없게 만드는 것이다.

주요 발언 모음

“프롬프팅은 입문 단계이고, 도착해야 할 곳은 하네스 엔지니어링이다.”

“스킬은 단순히 포장한 프롬프트가 아니라, 사용 중인 하네스를 확장하는 것이다.”

“두 개의 눈먼 의견이 하나의 자신만만한 추측보다 낫다.”

“금지 규칙은 모델을 자기 클러스터 안에서만 움직인다.”

“모델이 건너뛸 수 있는 게이트라면, 모델은 그것을 건너뛴다.”

“약한 모델도 의견은 있지만, 당신의 규칙을 따를 규율을 잃는다.”

“taste는 상처와 독특함의 결과다. 모두가 같은 taste를 사용하면 그것은 더 이상 tasteful하지 않다.”

“사용자에게 배포하는 스킬은 작성자가 쓰던 모델에서만 작동해서는 안 된다.”

핵심 데이터 & 수치

• 영상 길이: 약 3,864초(64분 24초)다.
• 초기 스킬 규모: Impeccable은 약 55줄의 프롬프트와 금지 규칙에서 출발했다.
• 색상 씨앗: color.js에는 100개가 넘는 손선택 기본 색상이 들어 있다.
• 셰이더 발산 실험: 반복 아이디어를 피하기 위해 예상 밖의 씨앗으로 약 100개 아이디어를 만든 뒤 독립 하위 에이전트가 순위를 매겼다.
• 모델 평가: 약 20개 분야에서 여러 모델을 대상으로 릴리스마다 5~10회의 테스트를 실행한다.
• 지원 대상 평가 모델: GPT-5.5, Opus, Sonnet, Gemini 등을 예로 든다.
• 프롬프트 캐시: 동적으로 실행된 스크립트 출력은 정적 스킬 본문과 달리 캐시되지 않는 비용이 있다.
• 자동 평가 범위: Claude Code SDK, Codex, Gemini의 도구와 브라우저 스크린샷 흐름을 재현하는 자체 평가 하네스를 사용한다.
• 라이선스: Impeccable은 Apache 2 라이선스로 공개됐다.

평가·테스트에 관한 Q&A

1. 동적 스크립트와 프롬프트 캐시는 양립하는가

스크립트가 매번 다른 결과를 낼 수 있으므로 호출 결과가 포함된 부분은 캐시되지 않는다. 다만 스킬의 정적 본문 자체는 캐시될 수 있다. 반복 실행 비용보다 상호작용 중 지시 이행이 중요한 경우에는 이 트레이드오프가 유효하다.

2. 스킬을 어떻게 평가하고 반복 개선하는가

자체 평가 하네스는 관심 있는 각 하네스와 도구를 가깝게 재현한다. Claude Code SDK, Codex, Gemini를 대상으로 브라우저 스크린샷 같은 도구를 복제하고, 별도의 LLM이 실제 사용자처럼 초기 질문에 응답하게 해 상호작용 흐름도 테스트한다. 여러 분야의 입력을 여러 모델에 5~10회씩 실행하고, Anthropic 프런트엔드 디자인 스킬 같은 경쟁 스킬과 결과를 비교한다.

더 비싼 ablation 테스트에서는 모든 규칙에 고유 XML 태그를 붙인다. 한 번에 하나의 규칙을 제거하고 평가를 실행한 뒤 다시 추가해 결과가 변했는지 결정론적 검사기로 확인한다. 예를 들어 색상 대비에 관한 한 줄을 뺐을 때 해당 규칙이 실제로 어떤 차이를 만드는지 측정한다. 초기의 “감으로 만든” 스킬이 이렇게 테스트된 시스템으로 바뀐다.

3. taste를 모델 평가로 해결할 수 있는가

기능적 판단은 비교적 자동화하기 쉽다. 첫 번째 뷰포트에 필요한 내용이 있는지, 대비가 맞는지 같은 질문은 검사할 수 있다. 그러나 taste는 인간의 경험·상처·독특함에서 나오고 모두가 동일한 taste를 사용하면 금세 진부해진다.

모델은 종종 최대주의적이다. 첫 화면에 요소를 많이 채울수록 더 높은 점수를 주는 경향이 있다. 그래서 어떤 심사자는 모델의 점수를 역전해, 너무 높게 나온 결과를 오히려 나쁜 디자인 신호로 해석하기도 한다. 현재의 디자인 디렉터 심사기는 무작위보다 조금 나은 첫 번째 필터일 뿐이며, 최종 평가와 주석은 사람의 눈으로 수행한다.

4. 스킬의 미래와 배포 방식은 무엇인가

Impeccable의 라이브 모드처럼 스킬 플랫폼의 경계를 넘어서는 기능은 궁극적으로 하네스에 일급 도구로 통합되는 편이 더 낫다. 개인이 자기 업무에 맞춰 쓰는 스킬은 간단해도 되지만, 타인에게 배포하는 스킬은 작성자가 쓰지 않은 모델에서도 작동하도록 훨씬 더 많은 검증을 거쳐야 한다.

현재는 스킬을 공통 방식으로 테스트하는 업계 표준이 없다. Codex와 Claude Code의 마켓플레이스는 특정 제공자에 묶이고, 업데이트 캐시나 설치 메커니즘이 불안정할 때가 있다. NPX 기반 스킬 배포는 유용하지만 하네스별 컴파일을 충분히 지원하지 않는다. MCP를 통한 배포도 가능하지만 컨텍스트 오염이 커질 수 있어 신중히 사용한다. 모든 하네스에 맞는 파일과 훅을 설치하려면 자체 CLI가 번거롭더라도 더 안전한 선택이 될 수 있다.

결론 및 실용적 시사점

1. 프롬프트를 쓰기 전에 스킬이 확장하려는 하네스의 도구·권한·이벤트 흐름을 목록화한다.
2. 자기 검토가 필요한 작업은 독립적인 역할의 하위 에이전트 두 개와 최종 합성 단계를 분리한다.
3. 금지 목록만 늘리지 말고 무작위 입력, 사용자 입력, 스크립트 출력으로 모델의 안전한 선택지를 벗어나게 한다.
4. 범용 스킬을 거대한 문서로 키우기보다 작업별 하위 스킬과 내부 라우터로 분해한다.
5. 결과·사용자 선호·진행 상태를 파일로 저장해 다음 세션이 이전 실행 위에서 쌓이게 한다.
6. 반드시 필요한 지시는 긴 산문 속에 묻지 말고 실행 시점의 JSON·표준 출력·검증 결과로 직접 삽입한다.
7. 기억해야 실행되는 명령보다 편집마다 자동으로 작동하는 훅과 피드백 루프를 만든다.
8. 약한 모델에서는 post-tool 교정이 실패할 수 있으므로 pre-tool 차단과 세밀한 ignore 규칙을 함께 제공한다.
9. 브라우저·스크린샷·로컬 서버·SSE를 채팅 스레드와 연결하면 시각적 작업을 텍스트 지시만으로 처리하지 않아도 된다.
10. 모델과 하네스의 차이를 숨기지 말고 전용 빌드·치환 변수·XML 블록·설치기로 명시적으로 흡수한다.
11. 가장 약한 모델을 기준으로 게이트를 설계하고 각 게이트의 통과 상태를 기록해 절차를 건너뛰지 못하게 한다.
12. 자동 평가는 기능과 규칙 준수의 첫 필터로 활용하되 taste와 최종 품질 판단은 사람의 눈으로 확인한다.
13. 여러 모델·분야·경쟁 스킬을 포함한 반복 평가와 규칙별 ablation 테스트로 스킬의 실제 기여를 측정한다.
14. 공개 배포하는 스킬의 품질 기준을 “내 환경에서 한 번 작동함”보다 “다른 모델과 하네스에서도 검증됨”으로 높인다.

핵심 요약 (20줄)

1. Paul Bakaus는 Impeccable을 만들며 프롬프트만으로 디자인 품질을 통제하는 데 한계가 있음을 확인했다.

2. Inter·Roboto·보라색 그라디언트 금지 같은 규칙은 창의성을 만들기보다 모델을 다음 유행 클러스터로 옮긴다.

3. 슬롭을 줄이려면 금지보다 모델의 익숙한 선택을 깨는 외부 씨앗과 실행 구조가 필요하다.

4. 자기 결과를 스스로 평가하는 모델은 기존 결과에 앵커링되어 지나치게 높은 점수를 주기 쉽다.

5. 디자인 디렉터 역할과 결정론적 린터 역할을 서로 보지 못하는 하위 에이전트로 분리하면 비평이 균형을 얻는다.

6. Codex처럼 하위 에이전트에 사용자 권한이 필요한 하네스에서는 권한 부족 시 명시적으로 중단하고 요청해야 한다.

7. 상위 폰트를 버리고 다시 고르게 하거나 대량 생성 후 독립 에이전트가 순위를 매기면 결과의 수렴을 늦출 수 있다.

8. color.js처럼 100개가 넘는 손선택 색상에서 무작위 씨앗을 뽑는 스크립트는 반복적인 기본 팔레트를 피하게 한다.

9. 하나의 거대한 스킬 대신 critique와 polish 같은 전문 하위 스킬을 라우팅하는 전문가 혼합 구조가 효과적이다.

10. 브랜드 디자인과 제품 디자인은 폰트·정보 밀도·목표가 다르므로 서로 다른 규칙 레지스터를 사용해야 한다.

11. 비평 결과와 사용자 선호를 저장하면 후속 세션이 이전 판단을 재사용하는 복합 엔지니어링이 가능하다.

12. 환경 상태를 읽는 스크립트의 구조화된 표준 출력은 긴 프롬프트 안에 묻힌 규칙보다 지시 이행률이 높다.

13. 동적 스크립트 출력은 프롬프트 캐시를 일부 포기하게 하지만 상호작용형 작업의 적응성을 높인다.

14. 수동 명령을 잊는 문제는 모든 편집에 반응하는 디자인 훅과 자동 검증 루프로 해결할 수 있다.

15. 약한 모델에는 post-tool 피드백보다 pre-tool 차단이 안정적이며 파일별 예외 설정이 반드시 필요하다.

16. 라이브 모드는 로컬 서버·개발 페이지·SSE·메인 에이전트를 연결해 브라우저에서 직접 요소를 고르고 변형을 비교하게 한다.

17. Claude·Codex·Cursor·Gemini는 하위 에이전트·백그라운드 작업·질문 도구·모델 편향이 서로 다르다.

18. 여러 환경에 배포하려면 하네스별·모델별 빌드와 치환 변수, 전용 설치기가 필요하다.

19. 약한 모델이 단계를 건너뛰지 않도록 게이트마다 성공 상태를 기록하고 선택적 규칙을 검증 가능한 상태 전이로 바꿔야 한다.

20. 자동 평가는 첫 필터일 뿐이며, 공개 스킬은 작성자가 쓰지 않은 모델과 하네스에서도 통과하는 전투 검증을 거쳐야 한다.