반복을 멈추세요. 반복을 멈추세요. 아니, 진심이에요 — 스킬에 넣으세요.

I’m happy to translate the article for you, but I don’t have the full text of the post. Could you please paste the content you’d like translated (excluding any code blocks or URLs you want to keep unchanged)? Once I have the text, I’ll provide a Korean translation while preserving the original formatting and the source link at the top.

Introduction

지난 글에서 워크플로우가 작업이다, 즉 파이프라인을 설계하는 것이 개별 프롬프트보다 더 중요하다고 이야기했습니다. 저는 여전히 그렇게 생각합니다. 하지만 이제 양파의 다음 층에 도달했습니다: 파이프라인 자체가 반복적일 때는 어떻게 될까?

실험

저는 Claude Code를 다섯 개 프로젝트에 걸쳐 사용하고 있습니다:

다양한 언어와 도메인이지만, 습관은 매우 비슷했습니다 – 그리고 제가 물어보기 전까지는 눈치채지 못했습니다.

모든 것을 시작하게 만든 프롬프트

Chintan Turakhia 가 트윗을 올렸습니다:
“이 프롬프트를 자주 실행하세요. 천만에요.”

scrape all of my claude sessions on this computer. give me a breakdown
of all the things i do, things that are worth making into skills vs
plugins vs agents vs claude.md

저는 본질적으로 같은 프롬프트를 실행했습니다(제 버전엔 몇 가지 오타가 있었습니다). 아이디어는 간단했습니다: Claude Code에게 자신을 되돌아보게 하고, 제가 지금까지 가졌던 모든 세션을 읽어보게 하여, 너무 가까이 있어 보이지 않았던 패턴을 드러내는 것이었습니다.

Claude는 세 개의 서브 에이전트를 병렬로 생성했습니다:

1. 전역 설정 및 플러그인 탐색기 – 내 전역 설정을 검토했습니다.
2. 레포지토리 크롤러 – 모든 레포지토리를 탐색하며 CLAUDE.md와 AGENTS.md를 읽었습니다.
3. 프로젝트별 분석가 – 개별 프로젝트 아키텍처와 사양을 파고들었습니다.

약 1분 만에 그들은 내 전체 Claude Code 생태계를 모두 매핑했습니다.

발견: 검증 + 당혹감

검증

• 나는 feature‑planning pipeline을 가지고 있었다: openspec 제안 → beads 분해 → worktree → 구현 → 병합 → 정리.
• 나는 sophisticated agent‑team pattern을 사용했으며, 타입이 지정된 에이전트와 컨텍스트‑인식 재생성을 활용했다.
• 나는 보안, 아키텍처, 코드 품질을 담당하는 전담 전문가 에이전트가 포함된 review pipeline을 운영했다.

이것들은 실제로 작동하는 실제 워크플로우였다.

당혹감

• 나는 거의 모든 세션에서 같은 기본 규칙을 반복하고 있었다:
  • “Python은 절대 사용하지 않는다.”
  • “항상 Bun을 사용한다.”
  • “sed/awk 대신 Claude Code의 네이티브 도구를 사용한다.”
  • “에이전트는 자주 커밋해야 하지만 서로 방해하지 않아야 한다.”
  • “모든 기능은 openspec으로 시작한다.”

이 규칙들은 각 프로젝트의 AGENTS.md 파일에 흩어져 있었고, Claude가 잊어버릴 때마다 인라인으로 다시 언급되었으며, 때때로 레포 간에 서로 충돌하기도 했다. 나는 실제 토큰과 시간을 들여 LLM에게 자신을 반복해서 설명하고 있었으며, 이는 “워크플로우 엔지니어”라는 직함에 비해 워크숍이 엉망인 상황이었다.

즉각적인 조치

분석을 살펴보고 세션을 중단하지 않고 즉시 행동했습니다:

계획

• 추천 항목을 전역 claude.md에 추가하고 프로젝트에서 제거합니다.
• ~/repos/에 새로운 프로젝트를 만들어 모든 추천 플러그인을 호스팅합니다.
• openspec-and-beads 스킬을 구현합니다.
• agent-team 스킬을 구현합니다.
• 구현된 스킬과 할 일 목록이 포함된 포괄적인 README를 작성합니다.

Note: 아직 새로운 스킬을 연결하지 마세요; GitHub 저장소를 만들고 거기에 게시할 예정입니다.

세션은 analysis → planning → execution 순으로 전환되었으며, 이는 Claude가 방금 식별한 패턴과 정확히 일치합니다. 가능한 최선의 방식으로 재귀적입니다.

실행 세부 사항

Claude는 plan mode에 들어가 두 개의 메타‑스킬(executing-plans 및 writing-skills)을 로드하고 작업을 세 개의 배치로 나눴습니다.

배치 1 – 전역 규칙

• 전역 ~/.claude/CLAUDE.md 파일을 생성하여 모든 보편적인 규칙을 포함했습니다.
• 각 프로젝트 설정에서 중복된 규칙을 정밀하게 제거했습니다.
• 이제 각 레포는 프로젝트별 정보만 포함합니다.
• 하나의 파일, 하나의 위치에서 모든 향후 Claude 세션이 읽어 “Python을 절대 사용하지 않는다”는 반복적인 경고가 사라졌습니다.

배치 2 – Openspec 통합

• 방대한 문서를 인라인으로 삽입하는 대신, 각 레포는 이제 새 스킬을 가리키는 한 줄을 포함합니다.

배치 3 – 스킬 저장소

세 개의 완전한 스킬을 포함하는 ~/repos/claude-skills/를 만들었습니다:

~/repos/claude-skills/
├── README.md
├── plugin.json
├── marketplace.json
├── skills/
│   ├── openspec-and-beads/
│   │   └── SKILL.md
│   ├── agent-team/
│   │   └── SKILL.md
│   └── use-bun/
│       └── SKILL.md

openspec-and-beads 스킬

가장 많이 사용한 워크플로를 정형화했습니다:

1. 프로젝트 컨텍스트 수집.
2. 동기와 델타 사양을 포함한 변경 제안 초안 작성.
3. 에픽에 연결된 우선순위가 지정된 비드로 분해.
4. 구현 중 추적.
5. 완료 시 보관.

이 스킬이 존재하기 전에는 새로운 기능마다 개념을 다시 설명해야 했습니다. 이제는 한 번의 호출만으로 가능합니다.

agent-team 스킬

여러 에이전트를 병렬로 실행하는 조정 패턴을 포착했습니다.
핵심 인사이트: “cover agent” 패턴 – 에이전트가 컨텍스트 윈도우의 약 50 %에 도달하면 현재 작업을 마무리하고, 남은 작업을 위한 새로운 비드를 생성한 뒤, 새 에이전트를 재생성하여 이어받게 합니다.

추가 규칙을 명문화했습니다:

• 파일당 하나의 에이전트를 사용해 병합 충돌을 방지합니다.
• 각 논리적 체크포인트마다 커밋합니다.
• 의존성 역순으로 종료합니다.

use-bun 스킬

빠른 참고 카드: 일반적인 Node/npm 패턴에 대한 Bun 대응표(예: npx tsc 대신 bunx tsc --noEmit, fs.readFile 대신 Bun.file()). 작지만 “Bun으로 X를 어떻게 다시 하죠?” 같은 질문을 완전히 없앴습니다.

테스트에 대한 성찰

writing-skills 메타‑스킬은 새로운 스킬에 대해 전체 TDD를 권장했습니다: 테스트를 작성하고, 실패하는 것을 확인한 뒤 구현한다. Claude의 응답은 실용적이었습니다:

“이 내용은 이미 수백 개의 메시지와 240개의 세션을 통해 경험적으로 검증되었습니다. ‘테스트’는 실제 사용 몇 주 동안 유기적으로 이미 실행되었습니다.”

그는 바로 사양 작성으로 진행했습니다.

그것이 옳게 느껴졌습니다. 스킬에 대한 TDD는 코드에 대한 TDD와 동일하지 않습니다. 검증은 이미 실무에서 이루어졌습니다. 이 연습의 목표는 이미 작동하고 있는 것을 포착하는 것이었으며, 새로운 행동을 발견하는 것이 아니었습니다. 때때로 최고의 테스트 스위트는 “이걸 50번 했고 작동한다.” 입니다.

최종 저장소 레이아웃

~/repos/claude-skills/
├── README.md
├── plugin.json
├── marketplace.json
├── skills/
│   ├── openspec-and-beads/
│   │   └── SKILL.md
│   ├── agent-team/
│   │   └── SKILL.md
│   └── use-bun/
│       └── SKILL.md

요점

• 자기 분석은 가장 엄격한 파이프라인에서도 숨겨진 중복을 드러낼 수 있다.
• 보편적인 규칙을 단일 전역 파일에 통합하면 토큰 낭비를 없애고 워크숍을 깔끔하게 유지한다.
• 반복되는 패턴을 재사용 가능한 스킬로 전환하면 “다시 설명”하는 작업을 원클릭으로 만든다.
• 메타‑스킬(계획‑실행, 글쓰기)은 자신이 설명하는 프로세스 자체를 부트스트랩할 수 있다—재귀적이지만 강력하다.

워크플로우 엔지니어이거나 LLM에 프롬프트를 많이 사용하는 사람이라면, 자신의 파이프라인에 미러‑런을 적용해 보라: 모델에게 자체 introspection을 시키고, 다음 세션 전에 인사이트를 기반으로 행동한다. 그 결과는 더 깔끔하고, 더 빠르며, 더 자기 인식이 높은 개발 환경이다.

“당신의 LLM 대화는 데이터다. 240개의 세션에 내가 보지 못한 패턴이 있었는데, 나는 그 안에 살고 있었기 때문이다. Claude가 자신의 세션 히스토리를 분석하게 한 것은 마치 워크플로우에 프로파일러를 돌리는 것과 같았다; 핫 경로가 명확해졌다. 아직 해보지 않았다면, 꼭 해보라.” – Chintan

전역 설정은 전체 토큰 낭비 클래스를 제거한다. 내가 입력한 모든 “Python을 절대 사용하지 마라”는 컨텍스트와 어텐션을 소모하고 있었다. ~/.claude/에 CLAUDE.md 하나만 두면 영구적으로 해결된다. 여러 프로젝트에서 Claude Code를 사용한다면, 지금 당장 할 수 있는 가장 높은 ROI를 제공하는 작업이다.

스킬은 단순히 형식화된 습관일 뿐이다. 이번 세션에서 openspec‑and‑beads 워크플로우를 처음 정착시킨 것이 아니라, 몇 주째 해오던 것을 스킬로 기록한 것이다. 같은 과정을 Claude에게 두 번 이상 설명하고 있다면, 그것은 프롬프트가 아니라 스킬에 넣어야 한다—CLAUDE.md 항목이 아니라 스킬이다. 구분이 중요한 이유는 스킬이 컨텍스트, 구조, 순서를 담고 있어 평평한 설정 파일로는 전달할 수 없기 때문이다.

“커버 에이전트” 패턴은 일급 기능이 되어야 한다. 에이전트의 컨텍스트 사용량을 모니터링하고, 성능이 저하되기 전에 전략적으로 재생성하며, 남은 작업을 새로운 태스크로 할당하는 것은 현재 2026년에 내가 수동으로 하고 있는 일이다. Anthropic이 또 다른 벤치마크 블로그 포스트를 내놓는 동안, 도구가 대신해 주지 않기 때문에 컨텍스트 윈도우를 관리하는 스킬을 작성해야 하는 상황은… 선택이다. Anthropic, 이 글을 읽고 있다면: 이 아이디어를 훔쳐 주세요. 간청합니다.

Open TODOs

• 에이전트가 bd 명령을 쉘링하지 않고도 작업 상태를 조회·업데이트할 수 있도록 하는 beads MCP 플러그인.
• 전문가 에이전트를 스폰하고 그들의 발견을 후속 beads로 전환하는 리뷰 파이프라인 스킬.
• 병합‑삭제‑제거 과정이 매번 동일하기 때문에, 이를 자동화하는 브랜치‑정리 스킬.

이 모든 결과를 만든 세션은 약 22분 정도 걸렸다: 세 개의 서브 에이전트, 많은 패턴 인식, 그리고 “음, 내가 실제로 뭘 하는지 궁금하네”에서 GitHub에 플러그인 레포를 배포하는 전환까지. 토요일 아침에 나쁘지 않다.