[Guild Plugin] Skill이 아니라 조직을 키운다

개요

Claude Code 같은 AI 코딩 도구로 개발하다 보면, 코드는 빠르게 나오지만 곧 다른 종류의 벽에 부딪힙니다. 그래서 저는 AI와 좀 더 체계적으로 개발하기 위해 SDD Plugin을 만들었습니다. GitHub Issue를 기반으로 분석 → 설계 → 구현 → 테스트 4단계를 거치게 해서, 분석 없는 코딩·설계 없는 구현·대화 유실 같은 문제를 잡아 주는 Claude Code용 플러그인입니다.

그런데 실무에서 계속 쓰다 보니 한 층 위의 문제가 남아 있었습니다. 결과물(코드)은 쌓이는데, 그 코드를 만드는 도구 자체는 스스로 나아지지 않는다는 것입니다. 이 글에서는 그 문제가 무엇이었는지, 그리고 그것을 사람들이 일하는 방식 — 즉 조직 — 에서 힌트를 얻어 풀어 본 배경을 정리합니다. (그렇게 만든 도구가 이 시리즈에서 소개할 Guild Plugin입니다.)

Guild Plugin의 소스 코드와 설치 방법은 dev-yakuza/deku-claude-plugins 저장소에서 확인할 수 있습니다.

이 글은 Guild Plugin 시리즈의 1부입니다. 시리즈는 다음으로 이어집니다.

1부. Skill이 아니라 조직을 키운다 (이 글)

2부. 에이전트 조직의 구조와 개발 흐름

3부. 성장 엔진 ①② — 결과물과 개발자의 공진화

4부. 성장 엔진 ③ + 안전 — 감독자(사람)도 함께 자란다

SDD Plugin의 배경은 AI 코딩의 함정과 해결 방향, 전체 구조는 SDD Plugin의 전체 구조와 사용법에서 다루고 있습니다.

SDD Plugin으로 얻은 것

SDD Plugin은 AI 코딩의 대표적인 함정을 프로세스로 막아 주었습니다.

분석 없는 코딩 → 요구사항을 먼저 분석하고 수용 기준(AC)을 세운 뒤 구현합니다.
설계 없는 구현 → 뼈대(설계)를 먼저 잡고, 테스터가 구현을 보지 않고 테스트 케이스를 먼저 작성합니다.
대화 유실 → 상태를 GitHub Issue/PR에 남겨, 세션이 끊겨도 이어서 진행할 수 있습니다.

덕분에 “이번 작업”은 훨씬 체계적으로 진행할 수 있게 되었습니다. 하지만 여기엔 한 가지 전제가 숨어 있었습니다. 프로세스와 스킬 자체는 사람이 미리 잘 만들어 두어야 한다는 것입니다.

도구가 자라지 않는다는 문제

AI와 개발을 반복할수록, 제가 계속 마주친 것은 이런 장면들이었습니다.

같은 실수를 프로젝트마다, 이슈마다 반복합니다. (예: “이 값은 하드코딩하지 말고 공용 설정에서 가져와야 한다”고 알려줘도, 다음엔 또 하드코딩합니다.)
한 번 교정해 주어도 다음 세션에는 잊습니다. 대화는 유실되고, 스킬 파일은 그대로이기 때문입니다.
프로젝트의 컨벤션·함정을 매번 사람이 다시 설명해야 합니다.
스킬을 개선하려면, 결국 사람이 직접 프롬프트와 지침을 손으로 고쳐야 합니다.

정리하면 이렇습니다. SDD Plugin은 “이번 작업을 잘하게” 해 주지만, “다음 작업을 더 잘하게” 만드는 일은 여전히 온전히 사람의 몫이었습니다. 결과물은 매일 쌓이는데, 그 결과물을 만드는 도구는 스스로 자라지 않습니다. 개선이 전적으로 사람의 수동 노동에 묶여 있는 것입니다.

이게 왜 근본적인 문제일까요? AI와 함께 개발하는 시간이 길어질수록, 도구도 그 경험만큼 함께 나아져야 합니다. 그렇지 않으면 우리는 매번 같은 온보딩을, 같은 교정을, 같은 설명을 반복하게 됩니다. 도구가 정적(static)이면, 축적이 일어나지 않습니다.

사람은 어떻게 계속 나아지는가

그래서 질문을 바꿔 보았습니다. “스킬을 어떻게 더 잘 관리할까?”가 아니라, “사람은 어떻게 계속 나아지는가?” 입니다.

이에 대한 힌트를 얻기 위해, 저는 소프트웨어 개발 조직을 관찰했습니다. 그리고 그 안에서 발견한 공통점은 다음과 같습니다.

분업과 전문가 — 아키텍트, 테스터, 리뷰어, 보안 담당처럼 역할이 나뉘어 있고, 필요할 때 소집됩니다.
신입 온보딩 — 새 사람이 와도 프로젝트 지식을 전수받아 빠르게 합류합니다.
코드 리뷰 — 만든 사람과 다른 사람이 독립적인 2차 의견을 냅니다.
회고 — 무엇이 잘되고 무엇이 어긋났는지 돌아보고, 다음에 반영합니다.
인사(HR) — 잘하는 사람은 성장하고, 역할이 잘 맞지 않는 사람은 역할을 바꾸고, 새로운 사람이 필요하게 되면 새 사람을 뽑습니다.
지식 공유와 문서 — 사람이 바뀌어도 문서를 통해서 또는 인수인계를 통해서 지식이 공유됩니다. 즉, 사람이 바뀌어도 조직의 지식은 남습니다.

핵심은 이것입니다. 조직은 일을 하면서, 그 일이 남긴 흔적으로 스스로 더 나아지고, 구성원이 바뀌어도 지식이 남는 구조입니다. 좋은 팀이 좋은 결과물을 만들고, 그 결과물의 흔적이 다시 팀을 개선합니다.

“도구도 이래야 하지 않을까?” — 이것이 Guild plugin의 개발에 출발점이었습니다.

Guild plugin은 레포 전용 에이전트 조직

Guild plugin은 레포마다 전용 에이전트 조직을 생성하는 Claude Code 플러그인입니다.

/gld init을 실행하면, 그 레포를 분석해 전용 길드(조직)가 만들어집니다. 길드 마스터인 리더와, 아키텍트·개발자·테스터·QA를 비롯한 역할 에이전트들이 창단됩니다. 개발 흐름(분석 → 설계 → 구현 → 테스트 → QA)은 이 조직이 협업으로 수행합니다.

그런데 여기서 그치지 않습니다. Guild는 개발을 하면서 남긴 흔적 — 사람의 교정, 되돌림(revert), 반복되는 마찰 — 을 읽어, 조직이 스스로 자랍니다. 반복해서 교정받은 내용은 역할의 습관이 되고, 발견한 코드 사실은 조직의 지식이 되며, 테스트로 못 잡는 규칙은 게이트로 승격됩니다.

SDD Plugin이 **“개발 흐름”**이었다면, Guild는 **“그 흐름을 수행하면서 스스로 성장하는 조직”**입니다. Guild는 SDD Plugin의 문제의식을 이어받은 후속이자, 한 단계 일반화한 결과입니다.