2026년 4월 21일 기준 DOT Studio는 Tal, Dance, Performer, Act 구조를 로컬 workspace와 registry로 관리하는 시각 작업공간이다.
Claude Code의 skills와 agents는 같은 문제를 다른 층에서 푼다.
처음엔 조금 기대했다.
드디어 에이전트 설정도 npm install처럼 깔끔하게 공유되는 건가.
우리 .claude/skills/와 .claude/agents/도 registry로 밀어 넣으면 끝나는 건가.
블로그 파이프라인, 인박스 정리, 트레이딩 점검, LLM Wiki lint 같은 작업도 전부 패키지처럼 관리하면 멋있지 않나.
그런데 공식 문서를 읽고 우리 워크스페이스에 대입해보니 답이 조금 달랐다.
DOT Studio는 Claude Code의 skills나 agents를 단순히 대체하는 도구라기보다,
에이전트 행동을 패키지 단위로 설명하고,
설치하고,
조합하고,
시각적으로 점검하려는 운영 레이어에 가깝다.
반대로 Claude Code의 skills와 subagents는 Claude Code 안에서 바로 쓰는 작업 단위다.
즉 질문은 이거다.
DOT Studio를 쓰면 Claude Code skills·agents가 필요 없어질까.
아니다.
둘은 겹치는 듯 보이지만 실제 도입 판단은 다르다.
팀이 지금 고통받는 지점이 “반복 절차를 Claude Code 안에서 잘 부르는 것”이라면 skills와 agents가 먼저다.
팀이 지금 고통받는 지점이 “에이전트 행동을 여러 프로젝트와 사람에게 설명 가능한 패키지로 공유하는 것”이라면 DOT 쪽을 볼 만하다.
이 글은 설치 감탄문이 아니다.
이번에는 dance-of-tal을 실제로 설치 실행하지 않았다.
대신 2026년 4월 21일 기준 공식 문서와 우리 워크스페이스의 .claude 구조를 놓고,
도입 전에 보는 운영 비교표를 만든다.
우리 작업공간 기준으로는 .claude/agents/ 아래 Markdown agent 파일이 129개 있다.
.claude/skills/ 아래 active SKILL.md 정의는 59개 있다.
이미 작은 팀 자동화라기보다는 꽤 자란 운영 폴더다.
이 정도가 되면 새 도구를 붙일 때 질문이 바뀐다.
“멋있나?”가 아니다.
“이 복잡도를 줄이나, 아니면 이름만 하나 더 늘리나?”다.
먼저 보는 답
DOT Studio는 시각 작업공간이다.
DOT CLI는 agent package manager에 가깝다.
Claude Code skills는 반복 절차를 필요한 순간에 불러오는 작업 능력이다.
Claude Code subagents는 한 세션 안에서 역할과 context를 분리하는 실행 단위다.
우리 식으로 줄이면 이렇다.
SKILL.md는 레시피다.
agents/*.md는 역할 카드다.
DOT의 Tal은 정체성과 기준이다.
DOT의 Dance는 재사용 skill 패키지다.
DOT의 Performer는 Tal과 Dance, 모델 설정을 묶은 실행 가능한 agent instance다.
DOT의 Act는 여러 Performer가 참여하는 협업 장면이다.
비슷한 단어가 많아서 머리가 살짝 출근 거부를 한다.
그래도 구분은 가능하다.
Claude Code 쪽은 “이 프로젝트 안에서 Claude가 지금 어떻게 일할까”에 가깝다.
DOT 쪽은 “이 에이전트 행동 묶음을 어떻게 설치, 조합, 공유, 점검할까”에 가깝다.
그래서 나는 이렇게 판단한다.
개인 또는 작은 팀이 Claude Code 안에서 반복 작업을 안정화하는 단계라면 먼저 skills와 agents를 정리한다.
여러 repo, 여러 런타임, 여러 팀원에게 같은 agent behavior를 배포해야 한다면 DOT를 실험 후보로 올린다.
이미 .claude가 잘 굴러가는데 단지 새 UI가 예뻐 보여서 DOT Studio부터 붙이는 건 우선순위가 낮다.
반대로 지금 skill, agent, prompt, MCP 설정이 프로젝트마다 흩어져 있고,
누가 어떤 behavior를 쓰는지 추적이 안 된다면 DOT의 패키지 관점은 꽤 매력적이다.
DOT가 관리하려는 단위
Dance of Tal 문서는 DOT를 agent package manager라고 설명한다.
핵심은 네 가지 단위다.
Tal.
Dance.
Performer.
Act.
공식 Core Concepts 문서 기준으로 Tal은 AI의 identity와 rules다.
누구처럼 행동할지,
어떤 기준을 항상 적용할지,
무엇을 절대 하지 말아야 할지 같은 baseline instruction layer다.
우리 .claude 구조에 비유하면 AGENTS.md나 CLAUDE.md의 공통 정체성 부분과 닮았다.
물론 완전히 같지는 않다.
Tal은 DOT asset으로 registry와 URN 체계 안에 들어간다.
Claude Code의 AGENTS.md는 프로젝트 안에서 읽히는 운영 지침에 더 가깝다.
Dance는 reusable skill module이다.
DOT 문서는 PR review format, threat-modeling checklist, structured output convention 같은 것을 Dance 후보로 든다.
여기서 Claude Code skills와 가장 많이 겹친다.
실제로 DOT CLI 문서는 dot init dance --name my-skill이 SKILL.md, scripts/, references/ 구조를 만든다고 설명한다.
이 부분은 꽤 노골적으로 Claude Code skill 생태계와 닿아 있다.
다만 DOT의 Dance는 설치와 업데이트, registry 공유까지 염두에 둔 패키지로 읽힌다.
Claude Code skill은 Claude Code가 현재 작업에서 필요할 때 로드하는 능력이다.
Performer는 runnable composition이다.
Tal과 Dance, 모델 설정을 묶어 실제로 실행 가능한 agent instance로 만든다.
DOT 문서는 Performer를 package.json에 비유한다.
이 비유는 이해가 쉽다.
Tal이 identity module이고,
Dance가 skill dependency라면,
Performer는 어떤 조합을 쓸지 잠그는 실행 묶음이다.
우리 .claude/agents/blog-pipeline-team/blog-writer.md 같은 파일은 역할 문서다.
반면 DOT Performer는 역할뿐 아니라 연결된 Dances와 model config까지 조합하는 쪽에 더 가깝다.
Act는 multi-performer choreography다.
여러 Performer가 어떤 관계로 협업할지 정의한다.
Planner와 Implementer.
Lead와 Reviewer.
Incident commander와 Specialist.
이런 구성이 Act에 들어갈 수 있다.
우리 블로그 파이프라인으로 치면 글감 수집,
초안 작성,
리뷰,
발행을 한 줄로 밀어 넣는 흐름이 Act 후보처럼 보인다.
다만 현재 우리 운영에서는 이 흐름이 .claude/agents/blog-pipeline-team.md, 스크립트, 시트 상태값으로 나뉘어 있다.
DOT Act로 옮기려면 단순 복사가 아니라 상태, 발행 권한, 리뷰 gate를 새로 맵핑해야 한다.
여기서 대충 옮기면 예쁘게 망한다.
예쁜 망함은 그래도 망함이다.
DOT CLI와 Studio의 차이
DOT 문서를 보면 CLI와 Studio는 역할이 다르다.
CLI는 빠른 파일 기반 workflow다.
dot init으로 .dance-of-tal/ workspace를 만든다.
dot add <owner>/<repo>로 GitHub에서 Dance skill을 가져온다.
dot install <urn>으로 registry asset을 설치한다.
dot check와 dot update로 설치된 Dance skill 업데이트를 확인한다.
dot publish로 Tal, Performer, Act 같은 asset을 registry에 올린다.
이건 개발자에게 익숙한 방향이다.
설정과 prompt를 “어딘가 복붙한 파일”이 아니라 installable asset으로 다루려는 흐름이다.
Studio는 시각 작업공간이다.
공식 Studio 문서는 Performer를 시각적으로 조합하고,
multi-performer Act를 만들고,
draft를 관리하고,
direct mode와 safe mode로 실행할 수 있다고 설명한다.
Studio 문서에서 눈에 띄는 건 safe mode다.
Direct mode는 실제 working directory를 대상으로 실행한다.
Safe mode는 shadow workspace에서 실행하고 review 후 적용하는 흐름이다.
이건 Claude Code를 팀에서 쓸 때 늘 나오는 걱정과 연결된다.
AI가 여러 파일을 건드릴 때 바로 실제 프로젝트에 반영해도 되는가.
리뷰 전용 공간이 필요한가.
누가 approve하는가.
Studio는 이 문제를 제품 레벨에서 다루려는 쪽이다.
또 OpenCode Runtime 문서를 보면 Studio는 workspace와 choreography를 정의하고,
OpenCode가 model execution, tool execution, session handling, provider API 연결을 맡는다.
이 경계도 중요하다.
Studio가 모든 runtime 문제를 마법처럼 없애는 건 아니다.
모델이 runtime에 설정되어 있지 않으면 Studio가 갑자기 모델을 만들어내지는 못한다.
도구 권한,
세션,
safe mode 결과 적용 방식은 여전히 운영자가 이해해야 한다.
즉 DOT Studio는 “에이전트 행동을 눈으로 보게 해주는 층”이지,
팀 운영 책임을 없애는 버튼은 아니다.
그 버튼 있으면 나도 사고 싶다.
아마 가격표 보기 전에 지갑이 먼저 도망가겠지만.
Claude Code skills가 푸는 문제
Claude Code skills 문서는 skills를 Claude의 capability 확장 방식으로 설명한다.
핵심 파일은 SKILL.md다.
frontmatter와 Markdown instructions로 구성된다.
Claude는 관련 상황에서 skill을 자동으로 불러오거나,
사용자가 /skill-name으로 직접 호출할 수 있다.
중요한 문장은 이거다.
skill의 본문은 사용될 때만 로드된다.
그래서 긴 참고자료와 절차를 CLAUDE.md에 계속 넣어두는 것보다 낫다.
우리 워크스페이스에서 이 말은 바로 체감된다.
블로그 글 작성 규칙은 .claude/rules/blog-writing.md에 있다.
Notion inbox sync는 .claude/skills/notion-inbox-sync/SKILL.md와 실행 스크립트로 묶여 있다.
블로그 채널 검수는 blog-channel-qc skill로 분리돼 있다.
LLM Wiki lint도 별도 skill로 있다.
이걸 전부 AGENTS.md나 CLAUDE.md에 넣으면?
Claude가 매번 모든 절차를 들고 다니는 가방맨이 된다.
가방은 많을수록 똑똑해지는 게 아니라 느려진다.
skills의 좋은 사용처는 반복 playbook이다.
한 번만 할 일은 skill이 아니다.
매주 하는 일,
실수하면 손실이 큰 일,
참고 파일과 체크리스트가 같이 필요한 일,
스크립트 실행이 필요한 일,
이런 것이 skill 후보가 된다.
DOT Dance와 닮았지만 운영 위치가 다르다.
Claude Code skill은 Claude Code 안에서 바로 쓰는 실행 지침이다.
DOT Dance는 공유와 설치, registry 관점이 더 강한 skill package다.
그래서 둘 중 하나만 고르는 문제라기보다 순서가 있다.
먼저 Claude Code skill로 절차를 안정화한다.
그 절차가 여러 프로젝트나 여러 사람에게 배포될 만큼 반복되면 DOT Dance 후보로 본다.
이 순서가 덜 위험하다.
처음부터 registry package로 만들면 이름 짓다가 하루가 간다.
이름 짓기는 개발자의 블랙홀이다.
들어가면 회의록만 남는다.
Claude Code subagents가 푸는 문제
Claude Code subagents 문서는 subagents가 별도 context와 tool access, focused system prompt를 가진다고 설명한다.
목적은 네 가지로 볼 수 있다.
main conversation context를 보존한다.
도구 권한을 제한한다.
프로젝트 간 설정을 재사용한다.
특정 domain에 맞게 행동을 전문화한다.
Claude Code에는 Explore, Plan, general-purpose 같은 built-in subagents도 있다.
Explore는 read-only codebase search와 analysis에 최적화되어 있다.
Plan은 plan mode에서 codebase research를 맡는다.
general-purpose는 복잡한 multi-step 작업과 수정까지 처리한다.
우리 블로그 파이프라인에 비유하면 subagent는 “역할 분담”이다.
글감 researcher.
초안 writer.
채널 reviewer.
publisher.
각자 다른 기준과 tool access가 필요하다.
이걸 하나의 대화에서 모두 처리하면 context가 금방 탁해진다.
반대로 subagents는 과하면 의사소통 비용이 생긴다.
작은 수정 하나에 researcher, planner, writer, reviewer를 다 깨우면 작업보다 회의가 길어진다.
사람 회사에서도 익숙한 풍경이다.
회의가 일을 낳고,
일이 회의를 낳는다.
아주 생산적인 무한루프처럼 보이지만 사실은 커피 소비량만 늘어난다.
DOT Act와 Claude Code subagents는 여기서 겹쳐 보인다.
둘 다 multi-role workflow를 다룬다.
하지만 Claude Code subagents는 Claude Code session 안의 역할 분리다.
DOT Act는 여러 Performer의 collaboration contract를 asset으로 정의하는 쪽이다.
즉 subagent는 현재 실행의 역할 분리,
Act는 공유 가능한 협업 설계도에 가깝다.
팀이 “이 작업은 항상 lead-reviewer-worker 구조로 굴러가야 한다”고 정했다면 Act가 후보가 된다.
팀이 “이번 세션에서만 read-only 탐색을 따로 시키자”면 subagent가 충분하다.
우리 .claude 폴더에 대입해보기
이 워크스페이스는 이미 단순하지 않다.
.claude/agents/ 아래 Markdown agent 파일이 129개 있다.
.claude/skills/ 아래 active SKILL.md가 59개 있다.
블로그,
트레이딩,
자산 관리,
인박스,
위키,
온톨로지,
리서치,
운영 점검이 한 폴더 안에 같이 산다.
이 상태에서 DOT를 붙이면 어디가 이득일까.
첫 번째 후보는 skills 배포다.
예를 들어 notion-inbox-sync는 config, script, SKILL.md가 함께 움직인다.
이런 건 Dance package 후보처럼 보인다.
다만 외부 registry에 올릴 수 있는지,
비밀값과 개인 workspace 경로를 어떻게 분리할지,
다른 런타임에서도 똑같이 의미가 있는지 봐야 한다.
두 번째 후보는 blog pipeline role composition이다.
현재는 blog idea capture team,
blog pipeline team,
blog reviewer,
publisher scripts,
Google Sheet 상태값이 연결되어 있다.
이 흐름을 DOT Act로 표현하면 시각적으로는 보기 좋아질 수 있다.
하지만 발행 권한과 계정 정보,
채널별 검수 규칙,
기존 시트 상태 동기화가 같이 붙어야 한다.
이건 단순 migration이 아니다.
운영 설계 작업이다.
세 번째 후보는 onboarding이다.
새 팀원이 들어왔을 때 .claude 폴더 전체를 설명하기는 어렵다.
Tal, Dance, Performer, Act처럼 기능 단위를 나눠 설명하면 더 쉬워질 수 있다.
특히 agent behavior가 registry asset으로 보이면 “지금 활성화된 행동이 무엇인지”를 추적하기 쉽다.
하지만 이 장점은 규모가 있을 때 나온다.
혼자 쓰는 vault라면 굳이 registry 관점까지 올릴 필요가 없을 수 있다.
네 번째 후보는 audit이다.
DOT가 말하는 inspectable workspace와 strict contracts는 운영자에게 매력적이다.
우리도 이미 “어떤 skill이 언제 로드되는지”,
“어떤 agent가 active인지”,
“발행 스크립트가 어떤 권한으로 동작하는지”를 계속 봐야 한다.
DOT가 이걸 더 잘 보이게 만든다면 가치가 있다.
하지만 공식 문서만 봐서는 우리 환경에서 실제 audit 보고서가 얼마나 좋아지는지는 아직 확인하지 않았다.
그래서 이 글의 판단은 보수적으로 간다.
DOT는 바로 본진 교체가 아니라 작은 sandbox 실험부터다.
비교표
| 구분 | DOT Studio / DOT CLI | Claude Code skills | Claude Code subagents |
|---|---|---|---|
| 기본 질문 | agent behavior를 어떻게 설치·조합·공유할까 | 반복 절차를 언제 필요한 만큼 불러올까 | 역할과 context를 어떻게 분리할까 |
| 핵심 파일 | .dance-of-tal/ assets, drafts |
.claude/skills/<name>/SKILL.md |
.claude/agents/<name>.md 또는 user-level agents |
| 핵심 단위 | Tal, Dance, Performer, Act | skill | subagent |
| 강한 지점 | 패키지화, registry, visual composition, safe mode | 반복 playbook, 참고자료, scripts 묶기 | 탐색·리뷰·수정 역할 분리 |
| 약한 지점 | 새 운영 레이어 추가, migration 비용 | 공유·버전 배포는 별도 설계 필요 | 과하면 delegation overhead 증가 |
| 팀 공유 | registry와 URN 중심 | repo에 포함하거나 user/project scope로 관리 | project/user agent 파일로 관리 |
| 시각화 | Studio canvas와 inspector | 기본은 텍스트 | 기본은 텍스트 |
| 실행 안전 | Studio safe mode가 shadow workspace를 제공 | skill 자체가 안전을 보장하진 않음 | tool restriction으로 일부 제어 |
| 우리 적용 순서 | sandbox에서 1개 workflow만 실험 | 이미 주력 운영 단위 | 필요한 역할부터 제한적으로 사용 |
이 표에서 중요한 건 승자가 아니다.
중요한 건 층이다.
skills는 procedure layer다.
subagents는 role execution layer다.
DOT는 package and composition layer다.
이 셋을 한 단어로 뭉개면 “에이전트 자동화”가 된다.
그렇게 부르면 편하다.
그리고 편한 이름은 보통 디버깅할 때 우리를 배신한다.
팀 작업에 붙일 때 좋은 경우
DOT를 검토할 만한 첫 번째 경우는 multi-repo다.
같은 reviewer skill,
같은 incident response role,
같은 sprint planning agent를 여러 repo에서 써야 한다면 복붙은 금방 지친다.
DOT의 dot add, dot install, dot check, dot update 흐름은 이 문제를 겨냥한다.
특히 dot check와 dot update가 중요하다.
skill이 바뀌었는지 확인하고 업데이트하는 방식이 있으면,
팀은 “누가 최신 prompt를 갖고 있나” 문제에서 조금 벗어날 수 있다.
두 번째 경우는 visible composition이 필요한 팀이다.
Claude Code agents와 skills는 텍스트 파일로 관리된다.
개발자에게는 좋다.
그런데 PM, 운영자, 리뷰 담당자가 같이 봐야 한다면 시각 canvas가 도움이 될 수 있다.
Performer가 어떤 Tal과 Dances를 물고 있는지,
Act에 어떤 participant가 있는지,
direct mode인지 safe mode인지 보이는 건 운영 회의에서 쓸모가 있다.
세 번째 경우는 review-first workflow다.
Studio safe mode는 risky refactor나 large AI-assisted edit에 어울린다고 설명된다.
우리 기준으로는 블로그 발행보다는 코드 변경 workflow에 먼저 맞다.
예를 들어 대규모 Markdown refactor,
에이전트 파일 구조 개편,
스킬 migration 같은 작업에서 shadow workspace와 review step은 유용할 수 있다.
네 번째 경우는 agent behavior를 외부 팀과 공유해야 할 때다.
Claude Code skill을 repo에 두는 것만으로도 공유는 된다.
하지만 DOT는 registry와 URN으로 installable asset을 만들려 한다.
팀 밖으로 나가는 순간 이 차이가 커진다.
“이 폴더 복사해서 넣으세요”보다 “이 asset 설치하세요”가 운영 문장으로는 더 낫다.
다섯 번째 경우는 Claude Code만 쓰지 않는 팀이다.
DOT 문서는 Claude Code, Cursor, Windsurf 같은 LLM agent 환경을 언급한다.
우리 AGENTS.md도 멀티 런타임 정책을 갖고 있다.
Cursor, Claude Code, Codex가 .claude/ 폴더를 공통으로 쓰는 구조다.
만약 agent behavior를 특정 IDE의 내부 관습이 아니라 별도 패키지로 들고 가려면 DOT의 방향이 맞을 수 있다.
다만 여기서도 작은 실험이 먼저다.
전체 .claude를 한 번에 DOT로 옮기는 건 하지 않는 편이 낫다.
작은 문 하나 고치려다 집 평면도를 새로 그리는 일이 된다.
아직 과한 경우
첫 번째로 개인 workflow만 있는 경우다.
혼자 쓰고,
한 repo에서만 쓰고,
설정 공유가 거의 없다면 DOT의 registry와 package layer는 과할 수 있다.
Claude Code skills와 agents만 정리해도 충분하다.
두 번째로 현재 절차가 아직 덜 익은 경우다.
매주 바뀌는 prompt를 바로 패키지로 만들면 유지보수 지옥문이 열린다.
먼저 SKILL.md로 굴려보고,
사용 빈도와 실패 지점을 본 뒤,
배포할 가치가 있을 때 패키지화를 검토한다.
세 번째로 secrets 분리가 안 된 경우다.
우리 스크립트 중에는 WordPress 발행,
Telegram 알림,
Google Sheet sync처럼 권한과 credential이 얽힌 것이 있다.
DOT asset으로 행동을 공유하더라도 secret은 local runtime config에 남겨야 한다.
공식 Core Concepts 문서도 mcp_config 같은 설정은 portable하게 두고,
project-specific secrets는 local runtime config에 둬야 한다고 설명한다.
이 선을 안 지키면 agent package manager가 secret package manager로 변신한다.
그 변신은 박수칠 일이 아니다.
네 번째로 팀이 아직 Claude Code 기본 구조를 모르는 경우다.
skills가 무엇인지,
agents가 무엇인지,
MCP가 무엇인지,
CLAUDE.md에 무엇을 남겨야 하는지도 헷갈리는 단계라면 DOT부터 들어가면 인지부하가 늘어난다.
먼저 Claude Code 안에서 procedure, role, tool boundary를 정리한다.
그다음 DOT가 줄일 수 있는 중복을 찾는다.
다섯 번째로 visual workspace가 목적이 되는 경우다.
시각화는 좋다.
하지만 canvas는 운영을 대신하지 않는다.
Performer 이름이 예쁘고 Act가 그럴듯해도,
실패했을 때 로그와 rollback이 없으면 운영은 여전히 불안하다.
그래서 DOT Studio를 볼 때도 “어떤 화면이 예쁜가”보다 “어떤 실패를 덜 아프게 만드는가”를 봐야 한다.
도입 전 10분 체크
아래 질문에 답하지 못하면 아직 DOT 실험을 미룬다.
-
지금 공유하려는 behavior가 2개 이상의 repo에서 반복되는가.
-
같은 skill이나 prompt를 사람이 복붙해서 관리하고 있는가.
-
최신 버전 확인이 안 돼서 실수가 난 적이 있는가.
-
role, skill, model config 조합을 한눈에 보여줘야 하는 사람이 있는가.
-
risky edit을 shadow workspace에서 먼저 보고 싶은 workflow가 있는가.
-
secret과 portable config를 분리할 수 있는가.
-
registry에 올려도 되는 내용과 private으로 남겨야 할 내용을 구분했는가.
-
현재 Claude Code skills와 agents 이름이 이미 안정됐는가.
-
DOT로 옮길 첫 실험 대상을 하나만 고를 수 있는가.
-
실패하면 원래
.claude운영으로 돌아갈 수 있는가.
여기서 1번부터 3번까지가 전부 아니면 DOT는 아직 이르다.
4번과 5번이 강하면 Studio 실험 가치가 있다.
6번과 7번이 애매하면 멈춘다.
권한과 secret은 귀찮을 때 사고가 난다.
귀찮음은 보안 사고의 친척이다.
아주 가까운 친척이다.
우리라면 이렇게 실험한다
우리 워크스페이스 기준으로는 전체 migration을 하지 않는다.
첫 실험은 blog-channel-qc 같은 작은 skill이 낫다.
이 skill은 역할이 명확하다.
채널 적합도를 본다.
TECHTAEK, TAEK2, 배당노마드의 rubric을 확인한다.
초안이 채널에 맞는지 점검한다.
외부 secret이 거의 필요 없다.
따라서 Dance 후보로 보기 쉽다.
두 번째 후보는 notion-inbox-sync가 아니라 보류다.
실제로는 이쪽이 더 중요한 workflow지만,
config와 외부 API,
Google Sheet,
블로그 idea 상태값이 엮여 있어서 첫 실험으로는 무겁다.
처음부터 이걸 옮기면 DOT 평가가 아니라 운영 이사 프로젝트가 된다.
세 번째 후보는 blog pipeline Act도 보류다.
글감 수집,
초안,
리뷰,
발행을 Act로 표현하면 그림은 좋다.
하지만 실제 발행은 WordPress/Blogger script와 sheet 상태 업데이트,
preflight,
review file,
Telegram contract까지 연결된다.
이건 DOT Studio가 잘못됐다는 뜻이 아니다.
첫 실험으로 너무 크다는 뜻이다.
그래서 순서는 이렇게 간다.
-
작은 skill 하나를 Dance 형태로 모델링한다.
-
local
.dance-of-tal/workspace에만 둔다. -
secret 없는 prompt와 reference만 포함한다.
-
Studio에서 Performer 하나를 만든다.
-
Claude Code 원래 skill 호출과 결과 품질을 비교한다.
-
실패하면 삭제한다.
-
성공하면 두 번째 skill로 넓힌다.
이 정도면 실험 비용이 작다.
실험은 작을수록 솔직해진다.
큰 실험은 보통 이미 회의실 안에서 성공한 척을 한다.
migration을 생각할 때의 매핑표
현재 .claude 요소 |
DOT에서 닮은 요소 | 옮길 때 보는 기준 |
|---|---|---|
| AGENTS.md / CLAUDE.md 공통 원칙 | Tal | 항상 적용되는 identity와 constraints인가 |
.claude/skills/<name>/SKILL.md |
Dance | 반복 가능한 technique인가 |
.claude/agents/<name>.md |
Tal 또는 Performer | role만 있나, skill/model 조합까지 있나 |
| blog pipeline team | Act | 여러 participant와 relation이 안정됐나 |
| scripts | local runtime tool | portable asset에 넣을지 local로 남길지 분리됐나 |
| rules 문서 | Tal 또는 Dance reference | 항상 규칙인지 상황별 절차인지 구분됐나 |
| MEMORY / TELOS | local context | 공유 asset보다 workspace-specific context에 가까운가 |
이 표에서 자주 헷갈리는 건 agents다.
Claude Code agent 파일을 그대로 DOT Performer로 보면 안 된다.
어떤 agent는 identity만 있다.
이 경우 Tal에 가깝다.
어떤 agent는 역할,
사용 skill,
실행 순서,
검수 기준을 함께 갖고 있다.
이 경우 Performer나 Act 쪽에 가깝다.
즉 자동 변환이 아니라 분해가 먼저다.
분해 없이 migration하면 새 구조에서도 같은 혼란이 반복된다.
폴더 이름만 바뀐 혼란은 생각보다 슬프다.
새 집에 이사 갔는데 박스가 그대로인 느낌이다.
실패할 지점
첫 번째 실패는 이름 충돌이다.
Tal, Dance, Performer, Act라는 새 단어를 도입하면 팀은 기존 용어와 같이 기억해야 한다.
이미 skills, agents, commands, hooks, MCP, routines가 있다.
여기에 DOT 단어까지 들어오면 vocabulary tax가 생긴다.
이 비용을 무시하면 onboarding이 어려워진다.
두 번째 실패는 중복 source of truth다.
같은 review 절차가 .claude/skills/blog-channel-qc/SKILL.md에도 있고,
DOT Dance에도 있고,
팀 문서에도 있으면 어디가 진짜인지 모른다.
이건 도구 문제가 아니라 운영 문제다.
DOT를 쓰려면 “원본은 어디인가”를 정해야 한다.
세 번째 실패는 secret과 project path 유출이다.
우리 workflow에는 absolute path,
channel credential,
sheet ID,
publisher config가 엮일 수 있다.
이런 값은 package asset에 들어가면 안 된다.
portable behavior와 local config를 분리해야 한다.
네 번째 실패는 safe mode를 과신하는 것이다.
Safe mode는 shadow workspace에서 review할 수 있게 해준다.
하지만 나쁜 instruction이 좋은 결과로 바뀌지는 않는다.
review step은 안전망이지 판단력을 대신하는 장치가 아니다.
다섯 번째 실패는 너무 큰 첫 프로젝트다.
“우리 전체 .claude를 DOT로 정리하자”는 말은 멋있다.
그리고 바로 피곤하다.
첫 실험은 하나의 skill,
하나의 Performer,
하나의 Act 정도로 끊어야 한다.
운영 도구 실험은 작게 이겨야 오래 간다.
크게 시작하면 보통 크게 미룬다.
지금 판단
2026년 4월 21일 기준으로 나는 DOT Studio를 Claude Code skills·agents의 대체재로 보지 않는다.
보완재로 본다.
특히 agent behavior를 package처럼 설치하고 업데이트하고 공유하려는 팀에게 의미가 있다.
다만 Claude Code 안에서 이미 잘 돌아가는 작은 workflow라면 skills와 agents를 먼저 정리하는 게 낫다.
우리 워크스페이스도 당장 전면 도입보다 작은 실험이 맞다.
blog-channel-qc처럼 secret이 적고 역할이 선명한 skill을 Dance 후보로 보고,
Studio에서 Performer 하나를 구성해본 뒤,
원래 Claude Code skill 호출과 결과를 비교한다.
그 비교에서 얻을 지표는 세 가지다.
설정이 더 설명 가능해졌는가.
공유와 업데이트가 쉬워졌는가.
실행과 review 부담이 줄었는가.
셋 중 둘 이상이 아니면 도입하지 않는다.
새 도구는 일을 줄여야 한다.
일 이름을 새로 붙이는 건 도입이 아니라 장식이다.
장식은 예쁘다.
근데 월요일 오전에는 예쁨보다 덜 터지는 게 이긴다.
관련 글
FAQ
DOT Studio를 쓰면 Claude Code skills가 필요 없어지나?
아니다.
Claude Code skills는 Claude Code 안에서 반복 절차를 실행하는 단위다.
DOT의 Dance는 그런 skill을 패키지와 registry 관점으로 다루려는 단위에 더 가깝다.
먼저 skill로 절차를 안정화하고,
여러 프로젝트나 팀원에게 공유할 가치가 생기면 DOT 쪽을 검토하는 순서가 좋다.
DOT Studio와 DOT CLI 중 무엇을 먼저 봐야 하나?
개발자라면 CLI를 먼저 보는 게 낫다.
dot init,
dot add,
dot install,
dot check,
dot update 흐름이 실제 운영 비용을 더 잘 보여준다.
Studio는 composition과 review workflow를 이해할 때 좋다.
Claude Code subagents와 DOT Act는 같은 건가?
같지 않다.
Claude Code subagents는 한 Claude Code session 안에서 context와 role을 분리하는 실행 단위다.
DOT Act는 여러 Performer의 관계와 collaboration contract를 asset으로 정의하는 쪽에 가깝다.
단발성 탐색이나 리뷰는 subagent가 충분하다.
반복되는 multi-role workflow를 공유 가능한 설계도로 만들고 싶을 때 Act를 본다.
우리 팀이 DOT를 바로 도입해도 될까?
다음 조건이 있으면 실험해볼 만하다.
같은 prompt나 skill을 여러 repo에 복붙하고 있다.
agent behavior의 최신 버전 확인이 어렵다.
PM이나 운영자가 role composition을 눈으로 봐야 한다.
safe mode로 review-first AI edit을 만들고 싶다.
이 조건이 없다면 먼저 Claude Code skills와 agents 정리부터 하는 편이 낫다.
DOT registry에 올리면 안 되는 것은?
secret,
개인 계정 정보,
project-specific absolute path,
private workflow detail,
발행 credential 같은 것은 올리면 안 된다.
공유 가능한 behavior와 local runtime config를 분리해야 한다.
agent package manager가 있다고 해서 모든 것을 package로 만들 필요는 없다.
TECHTAEK 운영 기준으로 첫 실험 대상은?
나는 blog-channel-qc 같은 작은 skill을 먼저 본다.
역할이 선명하고,
secret이 적고,
reference 문서가 있으며,
결과 품질을 비교하기 쉽기 때문이다.
반대로 WordPress 발행이나 Notion inbox sync처럼 외부 권한이 많은 workflow는 첫 실험으로 무겁다.