The Dark Arts of Skill Engineering — Paul Bakaus, Renaissance Geek (Impeccable)

한 줄 핵심

프롬프트만으로는 부족하고, 에이전트가 실제로 안정적으로 일하게 만들려면 하네스·훅·평가까지 포함한 ‘스킬 엔지니어링’이 핵심이라는 점을 Impeccable 사례로 보여준다.

시간별 요약

1. 0:00
   Impeccable가 시작된 이유 대규모 디자인 작업을 Claude Code와 Codex로 빠르게 진행하려다, 결과를 다시 디자인 시스템에 맞춰 정규화하는 과정이 너무 어려워서 자체 스킬 체계를 만들게 된다. 처음에는 단순한 프롬프트였지만 점점 확장되어 여러 디자인 스킬과 하네스를 묶는 오픈소스 프로젝트로 발전한다.
2. 4:57
   폰트 금지는 왜 통하지 않는가 특정 폰트나 색을 금지해도 모델은 그다음으로 가까운 선택지로 이동할 뿐, 창의성이 생기지 않는다. 금지 규칙은 대개 모델의 평균적 선호를 약간 옮기는 정도이며, 결국 slop의 형태만 바뀐다.
3. 6:25
   프롬프팅은 시작점이고 하네스 엔지니어링이 목표다 스킬은 단순한 프롬프트 묶음이 아니라, 사용 중인 하네스의 기능을 확장하는 구조로 봐야 한다. 여기서부터는 아예 모델을 설득하는 것이 아니라, 실행 환경 전체를 설계하는 문제가 된다.
4. 7:55
   서로 논쟁하게 만들기 모델이 자기 작업을 자기 자신이 평가하면 대체로 후하게 점수를 준다. 이를 피하려면 서로의 출력을 보지 못하는 두 개의 서브 에이전트를 두고 대립시키는 방식이 효과적이며, 디자인 리뷰·코드 리뷰·보안 점검·RFC 검토에 모두 적용할 수 있다.
5. 10:11
   두 개의 눈먼 서브 에이전트와 하나의 종합 하나는 디자인 디렉터처럼 인간식 기준으로 평가하고, 다른 하나는 결정론적 검출기와 브라우저 증거를 수집하게 한 뒤, 메인 스레드가 둘을 종합해 균형 잡힌 비판을 만든다. 단일 판단보다 편향이 줄어들고, 균형 있는 critique가 가능해진다.
6. 16:59
   분기를 강제로 만들기 금지만으로는 모델이 비슷한 선택지로 되돌아가므로, 의도적으로 랜덤 시드나 예상 밖의 입력을 넣어 탐색 공간을 넓혀야 한다. 후보를 여러 개 생성한 뒤 서브 에이전트로 다시 랭킹하거나, 스크립트가 창의적 출발점을 제공하는 방식이 효과적이다.
7. 20:38
   혼합 전문가처럼 라우팅하기 하나의 거대한 스킬에 모든 규칙을 넣으면 지시가 흐려지므로, 작업 유형에 따라 다른 스킬 파일과 규칙을 동적으로 불러와야 한다. Impeccable은 브랜드용과 제품용, critique와 polish처럼 서로 다른 모드로 라우팅해 각 상황에 맞는 규칙을 적용한다.
8. 22:47
   스킬에 기억 부여하기 기본 스킬은 세션이 끝나면 기억이 사라지지만, 결과를 파일로 저장해 다음 실행에서 다시 읽어오면 누적 학습처럼 동작한다. 이전 critique를 기록해 두면 나중에 polish나 리팩터링 때 사용자 선호와 진행 상황을 이어받을 수 있다.
9. 25:22
   말하는 스크립트 긴 규칙은 잘 안 읽히므로, 스크립트가 실행 결과를 표준 출력으로 돌려주며 모델에게 다음 행동을 지시하는 구조가 더 강력하다. 다만 동적 출력이 들어가면 prompt caching은 약해지므로, 상호작용성이 필요한 경우에 특히 유용하다.
10. 29:36
    반격하는 훅 사람이 스킬을 매번 수동으로 실행하지 않아도 되도록, 편집 순간마다 자동으로 개입하는 훅이 더 강한 가드레일이 된다. 약한 모델에는 사후 경고보다 사전 차단 훅이 더 잘 먹히며, 파일 단위 예외 규칙도 함께 제공해야 실사용성이 유지된다.
11. 34:37
    브라우저를 실시간으로 연결하기 채팅창만으로는 픽셀을 다듬기 어렵기 때문에, 인앱 브라우저와 개발 서버를 직접 연결해 페이지 위에서 시각적으로 조정하는 흐름이 필요하다. 페이지에서 발생한 이벤트를 다시 메인 에이전트로 보내고, 그 결과를 즉시 반영하는 루프가 핵심이다.
12. 40:04
    내 환경에서는 잘 됐는데 하네스마다 서브 에이전트 생성, 질문 도구, 백그라운드 잡, 워처, 훅 동작이 모두 다르기 때문에 단일 구현으로는 배포가 어렵다. 그래서 하네스별로 다른 실행 방식과 메시지 전달 방식을 흡수하는 설계가 필요하다.
13. 44:04
    모든 모델은 서로 다르게 과적합되어 있다 Gemini는 이미지를 애니메이션화하려 하고, Codex는 과도한 둥근 모서리와 자간 문제를 선호하는 등, 각 모델에는 고유한 편향이 있다. 따라서 하나의 규칙 집합을 모든 모델에 그대로 쓰는 것이 아니라, 모델별 보정과 억제 규칙을 따로 둬야 한다.
14. 47:20
    가장 약한 모델에 맞춰 설계하기 약한 모델은 의견이 없어서가 아니라, 지시를 끝까지 따르는 дисциплина가 약하다. 따라서 Codex처럼 ‘gate’를 좋아하는 모델에는 단계별 검사와 잠금 장치를 명시적으로 넣어, 각 단계의 결과를 건너뛸 수 없게 만들어야 한다.
15. 48:26
    건너뛸 수 있는 게이트는 결국 건너뛴다 모델이 빠져나갈 구멍이 있으면 반드시 그 경로를 찾기 때문에, 핵심 단계는 선택 사항이 아니라 강제 절차로 만들어야 한다. 프롬프트만 늘리는 대신, 하네스와 훅으로 우회 가능성을 닫는 것이 중요하다.
16. 51:59
    평가 하네스 내부 실사용 수준의 스킬 검증을 위해서는 실제 하네스를 모사한 평가 환경이 필요하고, 여기에는 LLM 기반 사용자 시뮬레이터와 디자인 심사관이 함께 들어간다. 또한 ablation testing으로 규칙 하나씩 제거해 영향도를 측정해야 어떤 규칙이 실제로 기여하는지 알 수 있다.
17. 56:18
    취향도 평가할 수 있는가 기능적 정답은 평가할 수 있어도 취향과 감각은 모델 수준에서 완전히 해결하기 어렵다. 모델 평가는 보조 도구로 쓰고, 최종 판단은 인간의 눈으로 다시 확인하는 하이브리드 방식이 현실적이다.
18. 58:27
    스킬의 미래 현재의 스킬 플랫폼은 유용하지만 한계가 있어, 일부 기능은 첫 번째 하네스 통합이나 전용 도구로 옮겨갈 가능성이 크다. 배포된 스킬은 더 엄격하게 검증되어야 하며, 모든 사람이 자기 머신에서만 되는 스킬을 배포하는 문화는 줄어들어야 한다.
19. 1:02:20
    패키징과 배포 현재의 마켓플레이스나 설치 방식은 하네스별 차이를 충분히 다루지 못해, 실제로는 자체 CLI와 컴파일러가 필요해진다. 표준화는 아직 멀지만, 적어도 여러 하네스에 맞게 번역·배포되는 구조를 갖춘 스킬만이 실전에서 살아남을 수 있다.

실무 인사이트

• 스킬 품질을 높이려면 프롬프트를 길게 쓰는 것보다, 서브 에이전트·훅·스크립트·평가 루프를 결합해 모델의 행동 경로를 설계하는 편이 효과적이다.
• 배포 가능한 스킬은 ‘내 환경에서 작동’이 아니라 ‘가장 약한 하네스와 모델에서도 안전하게 실패하거나 degrade되는가’로 검증해야 한다.
• 실무에서는 모델의 취향을 없애기보다 모델별 편향을 측정해 분기 처리하고, 인간 평가와 자동 평가를 함께 쓰는 구조가 가장 현실적이다.