스킬 286개를 담은 팩 하나를 열어봤습니다

클로드 코드를 쓰는 사람들은 보통 스킬을 하나씩 골라 씁니다. 테스트를 강제하는 스킬 하나, 배포 전에 헬스체크를 도는 스킬 하나. 필요할 때마다 찾아서 폴더에 넣는 식이죠.

@undefinedKi가 그 스킬을 286개로 묶은 큐레이션 팩을 올렸습니다. 사람들이 184,032번 봤어요.

저는 목록보다 마지막 경고에 먼저 눈이 갔습니다. "한 번에 286개 다 깔면 최악으로 가는 지름길이다. 플랜 하나와 룰팩 하나로 시작하라." 286개를 모아 놓은 사람이 286개를 깔지 말라고 씁니다.

팩 하나에 뭐가 들어 있나요?

286이라는 수부터 짚고 갑니다. 하루에 하나씩 익혀도 아홉 달 넘게 걸리는 분량이에요. 사람이 하나하나 검토해 고르기엔 이미 너무 많죠.

그래서 작성자는 목록을 여섯 갈래로 나눴습니다. 테스팅, 언어팩, 컨텍스트, 배포, 비코드, 아키텍처.

갈래 이름만 훑어도 작성자가 무엇을 노렸는지 보입니다. 에이전트가 혼자 달릴 때 어디서 넘어지는지, 그 지점마다 스킬을 하나씩 세워 둔 구성이에요.

저는 분류 기준에 눈이 갔습니다. 작성자는 언어 기준으로 언어팩 하나만 묶고, 나머지 다섯은 전부 작업 국면으로 묶었어요. 언제 무엇을 확인하느냐를 기준으로 삼은 거죠. 도구 목록보다 공정표에 가깝습니다.

테스팅 스킬은 무엇을 강제하나요?

테스팅 갈래에 tdd-workflow가 있습니다. 빨강에서 초록으로 가는 순서에 게이트를 겁니다. 실패하는 테스트를 먼저 세우지 않으면 다음 칸으로 넘어가지 못해요.

게이트라는 단어를 눈여겨봐야 합니다. 게이트를 걸면 에이전트는 그 단계를 건너뛸 수 없거든요. 에이전트한테 "테스트를 먼저 짜세요"라고 적어두면 지킬 때도 있고 건너뛸 때도 있습니다. 넘어갈 문을 잠가두면 에이전트에게 다른 선택지가 없어요.

같은 갈래에 eval-harness와 verification-loop도 있습니다. 하나는 결과를 채점하고, 하나는 고칠 때까지 돌아요.

셋을 겹쳐 보면 의도가 분명합니다. 에이전트가 "다 됐습니다"라고 말하는 순간을 믿지 않겠다는 겁니다. 사람이 눈으로 훑어 통과시키는 대신, 기계가 판정하게 만들어요. 에이전트의 자기 보고를 근거로 삼지 않는 구조입니다.

컨텍스트 스킬은 어디를 막나요?

작성자는 컨텍스트 갈래에서 아주 구체적인 버릇을 겨눕니다.

search-first는 코드를 쓰기 전에 문서부터 찾게 만듭니다. iterative-retrieval은 서브에이전트가 레포를 통째로 끌어오지 못하게 막아요.

두 스킬이 겨누는 뿌리는 하나입니다. 모르는 채로 쓰기 시작하고, 모르니까 전부 읽으려 드는 습성. 앞을 안 찾으면 뒤에서 다 퍼오게 되고, 다 퍼오면 에이전트가 정작 중요한 줄을 컨텍스트 창 밖으로 밀어냅니다.

저는 이 갈래가 팩에서 제일 실전적이라고 봅니다. 실패한 코드는 눈에 보이지만, 컨텍스트를 낭비한 실행은 결과만 봐서는 티가 안 나거든요. 답이 어딘가 어긋났는데 왜 어긋났는지 못 짚을 때, 여기서 원인을 찾는 경우가 많아요.

배포와 아키텍처는 어느 지점을 잡나요?

배포 갈래는 도커, CI/CD, 헬스체크, 롤백을 다룹니다. 프리즈마·드리즐·장고 마이그레이션도 여기 들어가요.

아키텍처 갈래는 한 줄로 요약할 수 있습니다. 마이그레이션이 불가역이 되기 전에 설계를 검토한다.

작성자는 이 한 줄에 갈래 전체를 담았습니다. 스키마를 밀어버린 뒤에 하는 설계 검토는 검토라기보다 회고거든요. 되돌릴 수 있는 구간과 되돌릴 수 없는 구간을 나눠 놓고, 앞 구간에 사람을 세우는 배치입니다.

배포 갈래도 같은 눈으로 보면 이해됩니다. 헬스체크는 나간 뒤에 살아 있는지 묻고, 롤백은 나간 걸 되돌립니다. 마이그레이션은 되돌리기가 특히 어렵고요. 그래서 작성자는 마이그레이션에만 따로 이름을 달아 배포와 아키텍처 양쪽에 걸쳐 뒀습니다.

언어팩은 언어와 프레임워크 여덟 개를 다룹니다. 파이썬, 고, 러스트, C++, 장고, 라라벨, 스프링부트, 넥스트제이에스. 각각 관용구, 테스트, 보안을 함께 묶었어요. 문법은 아는데 그 생태계의 관례를 모르는 상태, 에이전트가 딱 그 상태입니다.

비코드 갈래도 있습니다. 내 목소리로 글쓰기, 출처 있는 시장조사, 피치덱. 작성자는 코드 밖에서도 같은 원리를 씁니다. 출처를 요구하고, 목소리를 고정하고, 형식을 잠급니다.

왜 다 깔면 최악으로 가나요?

경고는 이렇습니다. 한 번에 286개를 다 깔면 최악으로 가는 지름길이다. 플랜 하나와 룰팩 하나로 시작하라.

큐레이션한 사람이 이 문장을 직접 썼다는 점을 봐야 합니다. 목록을 자랑하는 대신 목록 쓰는 법을 먼저 적었어요.

저는 이 경고를 자백으로 읽습니다. 모으는 일과 잘 쓰는 일이 같지 않다는 자백이요. 스킬은 전부 지시입니다. 지시를 스무 개 얹으면 에이전트는 매 순간 스무 개를 저울질하고, 그중 어느 하나도 제대로 지키지 못해요. 게이트를 스무 개 세우면 에이전트는 어느 게이트도 제대로 못 봅니다.

플랜 하나와 룰팩 하나. 작성자가 겨우 두 개만 처방한 이유가 여기 있다고 봅니다. 무엇을 걸었는지 사람이 한눈에 파악할 만큼만 걸어야 에이전트가 규칙을 지킵니다.

순서도 눈여겨볼 만합니다. 플랜과 룰팩, 둘 다 일을 시작하기 전에 거는 장치예요. 진입로를 좁히는 스킬부터 깔라는 뜻이에요. 뒤에서 걸러내는 장치는 앞을 잡고 난 다음에 넣어도 늦지 않습니다.

남는 생각

전에 anti-slop 규칙 필터를 다룬 적이 있습니다. 그 문서를 쓴 사람도 "이렇게 하라"를 늘리는 대신 이유 없는 선택만 막는 쪽으로 갔죠. 286개 팩을 만든 사람도 같은 방향으로 경고합니다. 규칙을 잘 만드는 사람일수록 개수를 늘리지 않습니다.

에이전트를 오래 굴리다 보면 스킬을 자꾸 더 넣게 됩니다. 좋아 보이는 걸 발견할 때마다 넣거든요. 넣을 때는 늘 근거가 있는데, 빼려고 하면 근거를 찾기 어렵습니다. 그래서 목록은 한 방향으로만 자랍니다.

저는 도구를 잘 쓰려면 모으기보다 덜어내야 한다고 봅니다. 저는 286개를 아는 사람과 다 깐 사람을 구분합니다. 다 깐 사람은 결국 스킬에 끌려다니거든요.

작성자는 무엇을 안 깔지 판단할 재료를 한곳에 모아 줬어요. 그 판단까지 대신해 주는 팩은 없습니다.

---

원문·소스

• 클로드 코드 스킬 286개 큐레이션 팩 (@undefinedKi): https://x.com/undefinedKi/status/2094088284443992514