스킬을 몇 개 만들어보신 분들은 한 번쯤 느껴보셨을 거예요. "A 스킬에서 B를 부르고, B가 다시 C를 부르게 하면 굉장히 똑똑해질 것 같은데… 왜 자꾸 중간에 엉뚱한 쪽으로 새지?"
이게 바로 Skill Graphs 1.0의 한계입니다. 스킬끼리 의존성 체인을 길게 엮을수록 에이전트가 중간에 길을 잃어요. 최근 해외 커뮤니티에서 화제가 된 Skill Graphs 2.0 아이디어는 이 문제를 정면으로 다룹니다. 스킬을 깊이 쌓는 대신 atoms → molecules → compounds 3단계로 재구성하자는 제안이에요. 핵심은 "같은 시간과 집중력으로 100배 더 많은 일을 뽑아내는 구조"입니다.
이 글에서는 Skill Graphs 1.0이 왜 무너지는지, 2.0의 3단계 구조는 정확히 뭔지, 그리고 왜 이게 Brain RAM 관점에서 레버리지를 폭발시키는지 하나씩 정리했습니다.
네 개의 흑백 원자 그림
이 글을 읽으면
내가 만든 Claude 스킬을 atoms/molecules/compounds 3단계로 재설계하는 실전 프레임워크와, 왜 compound 레벨에서 에이전트를 운전해야 레버리지가 100배가 되는지 이해할 수 있어요.
1. Skill Graphs 1.0이 왜 무너졌는가
스킬은 지식 + 프로세스를 마크다운 파일에 담아 에이전트가 반복 실행할 수 있게 만든 단위입니다. 처음 이 개념이 나왔을 때, 많은 사람들이 Obsidian의 노트 링크처럼 스킬끼리 서로 참조하는 그래프를 그려보자고 했어요.
직관적으론 굉장히 말이 됩니다. 큰 프로세스를 하나의 스킬에 담으려 하면 너무 무거워지니까, 작은 스킬들이 서로를 부르게 설계하면 위키처럼 지식 그래프가 완성되지 않을까?
그런데 실전에서 이런 문제가 터졌습니다.
깊이 2 이상부터 신뢰도 급락: A가 B를 명시적으로 부르면 잘 작동해요. 하지만 B가 다시 C를, C가 D를 부르는 깊은 체인으로 가면 에이전트가 중간에 길을 잃습니다.
의존성이 조밀해질수록 비결정성 폭발: 위키피디아처럼 빽빽한 그래프에서는 무슨 경로로 탐색할지 예측이 안 돼요. 사용자 의도가 있는데도 판단을 에이전트에 지나치게 위임하게 됩니다.
순환 참조 지옥: 스킬끼리 서로를 참조하기 시작하면 무한 루프가 돕니다. 어디까지 들어갈지 제어도 어렵고요.
Reddit이나 X에서 이 방식을 실제로 돌려본 사람들이 공통으로 지적한 증상이에요. 그래서 "스킬 그래프는 실패한 아이디어냐"라는 질문이 나왔는데, 답은 아니오입니다. 스킬을 합성해서 레버리지를 키우는 방향은 여전히 맞아요. 다만 합성 방식이 달라야 합니다.
2. 스킬은 3개 층위로 존재한다 — atoms, molecules, compounds
Skill Graphs 2.0의 핵심 아이디어는 이거예요. 스킬은 추상화 레벨이 다 다르다. 하나의 평면에 놓고 서로 링크시키지 말고, 수직으로 3층을 만들자.
상위 레벨일수록 에이전트에게 오케스트레이션 판단을 더 많이 넘김
하위 레벨일수록 에이전트에게 아주 명확한 워크플로우를 강제해 결정론에 가깝게 만듦
Claude가 추천하는 네이밍은 atoms → molecules → compounds지만, 실제로는 capabilities → composites → playbooks처럼 더 실무 친화적인 이름으로 바꿔 쓰는 팀도 많습니다. 중요한 건 이름이 아니라 레벨 분리예요.
3. Atoms — 결정론에 가까운 단일 목적 스킬
Atoms는 더 이 상 쪼갤 수 없는 원자 스킬입니다. 하나의 목적만, 아주 좁게 수행해요.
예시
LinkedIn 프로필 스크래핑
경쟁사 블로그 글 목록 가져오기
Apollo에서 사람 찾기
Hunter로 이메일 검증
이메일 도달률 체크
특정 주제 리서치
PR 하나 리뷰
설계 원칙
초고신뢰도: LLM이 가능한 범위에서 가장 결정론에 가깝게 동작해야 합니다. 100번 돌리면 100번 같은 결과에 수렴하도록요.
다른 스킬을 (대체로) 부르지 않음: atom은 다른 atom을 부르지 않아요. 의존성을 만들지 않는 게 핵심입니다.
좁고 명확한 입출력: 입력 1개, 출력 1개 정도로 인터페이스가 단순해야 합니다.
지피터스 멤버분들이 이미 만들어 쓰시는 스킬 중 상당수가 사실 atom 레벨이에요. 예를 들어 "GSC에서 특정 URL 성과 조회"나 "Mixpanel WAU 쿼리"처럼 하나의 도구에 하나의 액션만 하는 스킬들이요.
4. Molecules — 구조화된 워크플로우
Molecule은 2~10개의 atom을 조합해 범위 있는 문제를 푸는 스킬입니다.
두 가지 패턴이 흔해요.
패턴 1: 순차 체인
atom-1로 리드 찾기 → atom-2로 정성화 →
atom-3로 정보 보강 → atom-4로 스프레드시트에 추가패턴 2: 오케스트레이터
molecule이 5개의 atom을 "알고 있고", 프롬프트에 따라 어떤 atom을 어떤 순서로 쓸지 판단
판단의 폭은 넓지만, 선택 후보는 5개로 명확히 제한됨
설계 원칙
가능한 한 많은 합성 로직을 스킬 자체에 박아 넣는다: 런타임에 에이전트가 내려야 할 결정을 최소화합니다. "언제 어떤 atom을 부를지"를 스킬 마크다운에 명시적으로 써두는 게 핵심이에요.
여전히 매우 신뢰도 높아야 함: atom만큼은 아니지만, molecule도 대부분 예상 가능한 결과를 내야 합니다.
에이전트에게 넘기는 판단은 "계산된 자유": 자율성은 있되, 스킬이 미리 그어둔 테두리 안에서만 허용됩니다.
지피터스의 weekly-report 스킬이 좋은 molecule 예시예요. Mixpanel 조회 atom + GSC 조회 atom + EBP 계산 atom을 정해진 순서로 엮어서 "주간 리포트"라는 molecule을 만들거든요.
5. Compounds — 진짜 자율성을 위임하는 오케스트레이터
Compound는 여러 molecule을 돌리는 상위 오케스트레이터입니다.
예시
"아웃바운드 세일즈 플레이북을 돌려라"
"이 기능을 기획하고, 구현하고, 리뷰와 QA까지 끝내라"
"이번 주 콘텐츠 루틴을 실행해라" (키워드 발굴 → 글쓰기 → 등록 → 성과 측정까지)
설계 원칙
에이전트에게 진짜 판단을 위임하는 층위: 여기서부터는 어떤 molecule을 고를지, 중간에 방향을 틀지 에이전트가 결정합니다.
본질적으로 덜 결정론적: 여러 층에서 판단이 필요하다 보니 실행마다 결과가 미묘하게 달라질 수 있어요.
가장 설계하기 어려운 층: compound 하나를 안정적으로 만드는 데 시간이 가장 오래 걸립니다.
여전히 인간이 운전해야 한다: 오늘날 기준으로 compound는 혼자 두면 안 됩니다. 사람이 옆에서 방향을 잡아줘야 해요.
자동차 구매에 관심이 있는 사람의 수를 보여주는 막대 차트
6. Brain RAM — 왜 레버리지가 100배까지 벌어지는가
여기서부터가 진짜 이 프레임워크의 핵심입니다.
AI 시대에 진짜 희소한 자원은 GPU도, 모델 성능도 아닙니다. 당신의 뇌 RAM이에요. 즉 "동시에 몇 개의 에이전트 작업을 머리에 담고 컨텍스트 스위칭할 수 있느냐"입니다.
가정을 하나 해볼게요. 당신이 동시에 5개의 에이전트를 병렬로 운전할 수 있다고 칩시다. 그리고 각 레벨의 배율이 이렇다고 해요.
1 compound = 10 molecules
1 molecule = 10 atoms
이제 계산이 재밌어집니다.
Case A — 원자 작업을 운전하는 경우
5개 슬롯 × atomic 작업 = 5개의 원자 단위 작업
이건 본질적으로 결정론적인 일이라 사실 "운전"이 필요 없어요. RAM 슬롯 하나가 통째로 저부가가치 작업에 막혀 있는 겁니다. 자율주행이 되는 차에서 굳이 핸들을 잡고 있는 셈이죠.
Case B — 복합 작업을 운전하는 경우
5개 슬롯 × compound 작업 = 5 compounds = 50 molecules (5 × 10) = 500 atoms (50 × 10)
같은 5개의 슬롯, 같은 시간, 같은 집중력인데 결과물이 100배 차이가 납니다.
이 비유는 1000명 규모 회사의 CTO가 일하는 방식하고 똑같아요. CTO는 모든 버그를 직접 고치지 않습니다. 믿을 만한 엔지니어에게 맡기고, 본인은 한 단계 위의 의사결정을 해요. 당신의 에이전트도 마찬가지여야 합니다. 신뢰할 수 있는 atom이 있다면, 당신은 compound 층위에서 운전해야 해요.
7. 내 스킬 재분류하기 — 실전 체크리스트
지금 이 순간 당신이 만든 스킬들을 3개 폴더로 나눠봅시다.
STEP 1: Atoms 폴더에 넣을 스킬 체크
하나의 도구, 하나의 액션만 수행하는가?
다른 스킬을 호출하지 않는가?
100번 돌려도 거의 같은 결과가 나오는가?
세 개 다 YES면 atom입니다.
STEP 2: Molecules 폴더로 갈 스킬 체크
2~10개의 atom을 엮어서 완결된 태스크를 수행하는가?
"언제 어떤 atom을 부를지"가 스킬 안에 명시적으로 쓰여 있는가?
결과물이 대부분 예상 가능한가?
세 개 다 YES면 molecule입니다.
STEP 3: Compounds 폴더로 갈 스킬 체크
여러 molecule을 조합해 큰 목표를 달성하는가?
중간에 방향 전환 같은 판단이 필요한가?
사람이 옆에서 방향을 잡아줘야 안정적으로 돌아가는가?
세 개 다 YES면 compound예요.
분류가 끝나면 한 가지를 더 점검하세요. 깊은 의존성 체인이 있다면 반드시 끊어야 합니다. atom이 다른 atom을 부르고 있다거나, molecule이 또 다른 molecule을 체인으로 부르고 있다면, 한 레벨 위의 compound로 올려서 거기서 오케스트레이션하도록 리팩터링하는 게 좋아요.
8. 한계와 아직 풀리지 않은 문제
이 프레임워크가 만능은 아닙니다. 원문 저자도 솔직하게 인정하는 지점들이 있어요.
atom이 흔들리면 모든 층이 무너진다: compound의 신뢰도는 그 아래 모든 atom의 신뢰도 곱이에요. atom 하나가 95%면, 10개 체인의 molecule은 이미 60% 근처까지 떨어집니다.
compound의 천장: 8~10개 molecule을 엮은 compound부터는 자체 신뢰도가 떨어지기 시작합니다. 더 위의 추상화가 필요할 때가 곧 옵니다.
테스트 비용이 만만치 않음: 각 레벨의 스킬 신뢰도를 검증하는 게 실제로는 엄청난 시간이 듭니다. 자동 테스트 솔루션이 나올 때까지는 손품이 많이 들어요.
그럼에도 방향성은 명확합니다. 더 높은 레벨로 운전대를 옮겨라. 지금 molecule을 운전하고 있다면 compound로, compound가 익숙해지면 그 위 층위로.
마무리
Skill Graphs 1.0의 문제는 "합성"이 아니라 "잘못된 합성"이었어요. 옆으로 뻗는 링크 그래프는 깊이가 깊어질수록 무너집니다. 대신 위로 쌓는 3층 구조(atoms → molecules → compounds)로 바꾸면 같은 Brain RAM으로 100배의 산출을 뽑을 수 있어요.
오늘 할 일은 딱 하나입니다. 내가 만든 Claude 스킬들을 펼쳐놓고, 각자 어느 층에 속하는지 라벨을 붙여보세요. 깊은 의존성이 있으면 끊고, atom부터 단단하게 다져주세요. 거기서부터 당신의 Claude 스킬 활용법이 다시 시작됩니다.
💡 한 발 더 — 나의 생각
이 3층 구조가 Claude 스킬 설계에만 적용된다고 보면 반은 놓치는 거예요. 저는 이걸 지피터스 콘텐츠 루틴 전체에 그대로 대입해봤습니다.
atoms: GSC 특정 URL 조회, Mixpanel 이벤트 쿼리, Unsplash 이미지 검색, 단일 H2 섹션 작성
molecules: 주제 1개에 대한 키워드 리서치 + 제목 후보 3개 도출(
gpters-post스킬 초반부), 성과 측정 파이프라인(content-pipeline)compounds:
daily-content루틴 전체(패턴 반영 → 키워드 → 글쓰기 → 등록 → 측정 → 피드백)
이렇게 놓고 보니 한 가지가 선명해졌어요. 제가 그동안 "바쁘다"고 느꼈던 이유는 컴파운드 운전자여야 하는데 자꾸 atom을 직접 손으로 돌리고 있어서였습니다. Unsplash에서 이미지 하나 검색하는 건 atom인데, 여기에 내 RAM 슬롯을 쓰면 그만큼 compound 쪽에서 큰 판단을 못 해요.
그리고 한 국 AI 커뮤니티에 특히 해주고 싶은 이야기가 있어요. 한국 팀은 종종 "하나의 초거대 프롬프트"로 모든 걸 해결하려는 경향이 있어요. 실리콘밸리 팀이 compound/molecule/atom을 분리하는 동안, 우리는 16,000자짜리 시스템 프롬프트 하나에 모든 걸 우겨 넣죠. 단기적으로는 빨라 보여도 테스트 불가능·디버깅 불가능·재사용 불가능이라는 세 가지 부채가 동시에 쌓입니다.
앞으로 3~6개월 안에 "스킬 아키텍처"가 AI 팀의 역량 차이를 가르는 진짜 변수가 될 거라고 봅니다. GPU도, 모델도, 프롬프트 엔지니어링 기법도 결국 평준화됩니다. 하지만 당신 팀이 얼마나 단단한 atom을 갖고 있고, 그걸 얼마나 깔끔한 molecule로 조립하고, 얼마나 자율적인 compound로 운영하는지는 복제가 어렵거든요. 지금부터 쌓기 시작하면 그게 진짜 해자가 됩니다.
원문: Skill Graphs 2.0 — A new way to think about composing skills to increase leverage
