AI와 함께한 모든 순간을 경험치로 — Juicify 플러그인 제작기
AI를 쓰면서 배운 것들이 자꾸 흘러가는 느낌, 혹시 아시나요? 경험을 자산으로 바꾸는 Claude Code 플러그인을 만들게 된 과정을 나눠요.
- 배경: AI 도구를 열심히 쓰는데, 배운 것들이 기록 없이 흘러가 버리는 문제를 느꼈어요
- 핵심 인사이트: “쓰고 넘어가기”를 “쓰고 남기기”로 바꾸려면, 경험을 자산으로 변환하는 구조가 필요했고, 그 결과물이 Juicify 플러그인이에요
- 이런 분에게: AI를 많이 쓰는데 “나는 뭘 배운 거지?” 싶을 때가 있는 분
열심히 했는데, 뭐가 남았지?
AI 도구를 쓰면서 이런 느낌 받아본 적 있으신가요?
하루에도 몇 번씩 AI와 대화하면서, 문제를 풀고, 코드를 짜고, 아이디어를 발전시키고. 그 순간에는 분명히 뭔가를 배운 것 같은데, 다음 날이 되면 기억나는 게 별로 없어요. “어제 뭐 했더라?” 하면 결과물은 있는데, 그 과정에서 내가 뭘 깨달았는지는 흐릿해져 있는 거죠.
저도 그랬어요. 셀포지(Selforge) 프로젝트를 하면서 매일 AI와 함께 작업했는데, 어느 날 문득 돌아보니까 결과물은 쌓여 있는데 “내 경험치”라고 부를 수 있는 건 머릿속 어딘가에 흩어져 있었어요. 작업 로그도, 시행착오 기록도, 다른 사람의 도구에서 배운 것도 — 다 흘러가고 있었던 거예요.
처음에는 분석 도구 하나로 시작했어요
셀포지에서 AI 에이전트를 만들다 보면, 다른 사람들이 만든 스킬을 많이 살펴보게 돼요. “이 스킬은 왜 이렇게 설계했을까?”, “이 프롬프트 패턴은 어떤 의도가 있을까?” — 이런 궁금증이 자꾸 생기더라고요.
그래서 처음에 만든 게 dissect(디섹트)라는 스킬이었어요. “해부하다”라는 뜻 그대로, 다른 사람의 스킬을 분석해서 인사이트를 뽑아내는 도구였죠. 한국어로, 개인 용도로 쓰려고 만든 거였어요.
근데 써보니까 정말 유용했어요. 다른 사람의 스킬을 그냥 “설치해서 사용”하는 것과, “왜 이렇게 만들었는지 이해하고 흡수”하는 것은 완전히 다른 경험이더라고요. 그냥 남의 도구를 빌려 쓰는 거랑, 그 도구 뒤에 있는 사고방식을 내 것으로 만드는 거랑의 차이랄까요.
“이거 다른 사람한테도 공유하면 좋겠는데?” 하는 생각이 자연스럽게 들었어요.
시도와 실패: “해부”라는 이름의 한계
dissect를 공유하려고 마켓플레이스를 살펴봤는데, 두 가지 문제가 보였어요.
첫째, 이름이 주는 인상. “해부”라는 단어가 정확하긴 한데, 학술적이고 딱딱해요. 마켓플레이스에서 스크롤하다가 “dissect”를 보면 “뭔가 무거운 분석 도구겠구나” 하고 넘어갈 것 같았어요. 호기심을 끌기 어려웠죠.
둘째, 한국어 품질 문제. 스킬을 영어로 써서 글로벌 배포에 맞추려고 했더니, AI가 한국어로 결과를 낼 때 번역체가 나오는 거예요. 이건 이전 글 “AI가 자꾸 번역체로 말해요”에서 자세히 다뤘는데 — 간단히 말하면, 영어로 쓴 프롬프트를 읽은 AI는 영어로 사고하기 때문에, 한국어 출력이 번역체가 되는 문제였어요.
그리고 개인 도구로만 쓸 때는 몰랐던 근본적인 질문이 생겼어요. “분석 도구 하나만으로 충분한가?” 작업하면서 느낀 건, 경험이 흘러가는 지점이 한 곳이 아니라 여러 곳이라는 거였거든요.
전환점: “경험의 자산화”라는 공통 분모
그때 만들고 있던 다른 스킬이 하나 있었어요. 작업이 끝나면 “무엇을 발견했고, 왜 그렇게 판단했고, 다음에는 뭘 다르게 할지”를 케이스 스터디로 정리해주는 도구요. 원래 이름은 case-study였는데, dissect와는 별개로 쓰고 있었어요.
두 스킬을 나란히 놓고 보니까, 공통점이 보이더라고요.
dissect는 다른 사람의 스킬에서 인사이트를 뽑아내고, case-study는 내 작업 경험에서 인사이트를 뽑아내요. 입력은 다르지만, 하는 일의 본질은 같았어요 — 흘러가는 경험을 잡아서, 나중에 다시 쓸 수 있는 형태로 바꾸는 것.
“이 두 개를 따로 두지 말고, ‘경험의 자산화’라는 하나의 테마로 묶으면 어떨까?”
이 생각이 전환점이었어요.
해결: Juicify — 갈아서 주스로 만들다
이름부터 다시 생각했어요. “해부”보다 직관적이고, 고유하고, 호기심을 끄는 이름이 필요했거든요.
여러 후보를 놓고 고민하다가 떠오른 게 Juicify — “갈아서 주스로 만든다”는 비유였어요. 과일을 그냥 먹으면 그걸로 끝이지만, 갈아서 주스로 만들면 영양소를 더 효율적으로 흡수할 수 있잖아요. 경험도 마찬가지라는 거죠. 그냥 하고 넘어가면 소비로 끝나지만, 갈아서 핵심을 뽑아내면 재사용 가능한 자산이 되는 거예요.
마켓플레이스에서 “Juicify”를 보면 “이게 뭐지?” 하고 한 번은 클릭해볼 것 같다는 판단도 있었고요.
이 비유를 중심으로 구조를 잡았어요:
- 플러그인 이름은 Juicify (브랜드)
- 하위 스킬은
*-juice패턴 (skill-juice, work-juice, …) - “짜낸다”, “갈아서 주스로 만든다”는 비유는 제목과 도입부에만 쓰고, 실제 본문은 직관적인 한국어로
세 번째가 중요했어요. 처음에는 비유를 본문 전체에 밀어넣었거든요. “인사이트를 짜내고”, “지식을 농축하고” 같은 식으로요. 근데 읽어보면 오히려 어색하더라고요. 브랜딩은 문 앞에서 인상을 주는 역할이면 충분하고, 문 안으로 들어오면 직관적인 말이 더 잘 읽혀요.
한국어 품질 문제도 이 과정에서 해결했어요. frontmatter(이름, 설명 같은 메타 정보)는 영어로 두고, AI가 읽고 따르는 본문은 한국어로 쓰는 구조로 바꿨어요. 이렇게 하면 글로벌 마켓플레이스에서 발견되면서도, 한국어 사용자에게는 자연스러운 결과물을 줄 수 있거든요.
4개 스킬, 하나의 목적
Juicify는 현재 4개의 스킬을 담고 있어요. 시선의 방향은 각각 다르지만, 목적은 하나예요 — 경험을 자산으로 바꾸는 것.
skill-juice는 바깥에서 안으로의 시선이에요. 다른 사람이 만든 스킬을 6개 렌즈(설계 철학, 시스템적 사고, 엔지니어링 테크닉, 프롬프트 설계, 사용자 경험, 내 작업에 적용)로 분석해요. “이 스킬이 뭘 하는가”가 아니라 “왜 이렇게 설계했는가”를 파고드는 거죠.
work-juice는 과거에서 현재로의 시선이에요. 완료된 작업 사이클(이슈 발견 → 원인 분석 → 개선 → 검증)을 케이스 스터디 리포트로 정리해요. 핵심 질문은 “이번에 무엇을 배웠는가?”예요.
idea-juice는 현재에서 미래로의 시선이에요. 대화나 작업 중에 떠오른 아이디어를 콘텐츠 준비 노트로 변환해요. “이 아이디어로 뭘 만들 수 있을까?”가 핵심 질문이에요.
guide-juice는 안에서 밖으로의 시선이에요. 내가 이해한 개념이나 구조를 다른 사람에게 전달 가능한 가이드 문서로 바꿔줘요. “이걸 어떻게 설명할 수 있을까?”가 핵심 질문이고요.
이 네 가지가 커버하는 범위를 보면 — 남의 것에서 배우고(skill-juice), 내 경험에서 배우고(work-juice), 떠오른 생각을 키우고(idea-juice), 아는 것을 전달하고(guide-juice). 결국 “배우고 쓰고 넘어가기”의 모든 지점에서, 자산이 될 수 있는 걸 잡아내는 거예요.
*-juice라는 네이밍 패턴 덕분에 확장도 편해요. 나중에 book-juice(독서에서 인사이트 추출), code-juice(코드 리뷰에서 패턴 추출) 같은 걸 추가하더라도 이름 고민 없이 패턴만 따르면 되거든요.
검증: 3채널 배포까지
Juicify가 실제로 쓸 만한지 확인한 방법이 좀 재미있어요. skill-juice로 Juicify 자기 자신을 분석해봤거든요. 6렌즈 분석이 한국어로 자연스럽게 나오는 걸 확인했고, 분석 과정에서 description 개선점까지 발견했어요 — 워크플로우를 요약하면 Claude가 본문을 건너뛴다는 걸 알게 돼서, description을 “언제 쓸 것인가”라는 트리거 조건으로 바꿨어요.
work-juice로는 이 플러그인을 만든 과정 자체를 케이스 스터디로 정리했고요.
배포는 세 채널로 동시에 진행했어요:
- GitHub 레포 — 소스코드 직접 접근용
- anthropics/skills PR — 커뮤니티 기여
- 공식 마켓플레이스 —
/plugin install juicify로 설치 가능
배포하면서 배운 건, Claude Code 플러그인은 .claude-plugin/plugin.json 구조만 갖추면 세 채널 모두에 대응할 수 있다는 거예요. 배포 가능성이 조금이라도 있는 스킬이라면, 처음부터 플러그인으로 패키징하는 게 나중에 재작업을 줄여줘요.
인사이트: 소비와 자산화의 차이
Juicify를 만들면서 가장 크게 느낀 건 이거예요.
AI 도구를 “잘 쓰는 것”과 “쓰면서 성장하는 것”은 다른 문제라는 거요.
AI가 워낙 빠르게 결과를 내주다 보니, 우리도 빠르게 소비하게 돼요. 문제가 생기면 물어보고, 답을 받고, 적용하고, 다음 문제로 넘어가고. 이 사이클이 빨라질수록 오히려 “내가 뭘 배운 거지?”라는 느낌이 커지는 것 같아요.
핵심은 경험과 소비 사이에 변환 단계를 하나 끼워 넣는 거예요. 다른 사람의 도구를 설치하고 넘어가지 말고, 왜 이렇게 만들었는지 한 번 들여다보기. 작업이 끝났을 때 그냥 다음으로 넘어가지 말고, 뭘 배웠는지 한 번 정리해보기. 아이디어가 떠올랐을 때 메모만 하고 잊지 말고, 나중에 쓸 수 있는 형태로 키워놓기.
이게 꼭 Juicify라는 도구가 있어야만 되는 건 아니에요. 방법은 각자의 방식이면 되고요. 중요한 건, “쓰고 넘어가기”와 “쓰고 남기기” 사이에 의식적인 단계를 만드는 것 자체예요.
마무리
AI 도구가 점점 더 많아지고 강력해지는 시대에, 도구를 잘 쓰는 것만큼 중요한 게 하나 있는 것 같아요. 그 과정에서 나한테 뭐가 남는지를 챙기는 거요.
Juicify는 저 자신의 이 고민에서 출발한 도구예요. 혹시 비슷한 느낌을 받고 계신 분이 있다면, 꼭 이 플러그인이 아니더라도 자기만의 “자산화 루틴”을 한번 만들어보시는 건 어떨까요? 경험이 흘러가지 않고 쌓이기 시작하면, 생각보다 많은 게 달라지더라고요.