LLM Wiki

매퍼코 3스킬 워크플로우

11 min read

매퍼코 3스킬 워크플로우

한 줄 정의

맥퍼커(도메인 맵핑) → G스텍(스펙 브레인스토밍) → 슈퍼파워즈(서브 에이전트 구현)로 역할을 분리하고, 크로스 모델 리뷰(Claude + Codex)로 품질을 확보하는 2~3시간짜리 AI 코딩 워크플로우.

핵심 요지

  • 단일 스킬에는 한계가 있다. 도메인 → 스펙 → 구현으로 역할을 분리해 조합해야 한다.
  • 코드를 짜기 전에 1시간가량 도메인 인터뷰와 스펙 검토를 먼저 해야 헛수고가 줄어든다.
  • 큰 작업을 2~5분 단위로 쪼개 서브 에이전트에게 분배하고, 중간 검수와 크로스 모델 리뷰로 품질을 확보한다.
  • 구현 후 도메인 파일을 기준으로 코드를 다시 점검해 단순히 동작하는 코드가 아니라 도메인 개념이 드러나는 코드로 만든다.

상세

3스킬 역할 분리

스킬단계역할핵심 목적
맥퍼커 (MacFocus)도메인도메인 맵핑 + DDD 아키텍처링서비스의 단어·개념·관계를 AI에게 정확히 주입, 코드 경계 확보
G스텍 (GStack)스펙제품 스펙 브레인스토밍뭘 빼고 뭘 살릴지 밀도 있게 다듬음, 스펙의 핵심과 노이즈를 확 갈라냄
슈퍼파워즈 (Superpowers)구현실제 코딩 + 서브 에이전트 드리븐 개발브레인스토밍 결과를 코드로 풀어내는 엔진

맥퍼커: 도메인 맵핑

맥퍼커의 주된 목적은 도메인 맵핑이다. 서비스에 등장하는 단어, 개념, 관계를 AI(Claude)에게 정확하게 알려주는 것이다.

  • 예시: “주문”이라는 단어는 일반 쇼핑몰 주문, 음식 배달 주문, B2B 발주와 의미가 다르다. 그냥 “주문”이라고 던지면 AI가 헷갈린다.
  • 맥퍼커는 이를 계속 캐묻고 정리해 도메인 파일(context.md)으로 만든다.
  • 해강은 기본 도메인 맵핑에 한 단계 더 나아가 DDD(Domain-Driven Design) 아키텍처링을 커스텀으로 얹었다.
  • 도메인 용어를 사전처럼만 쓰는 것이 아니라, 실제 코드 구조(폴더 경계, 모듈 경계, 함수 시그니처)에 반영되도록 한다.
  • 효과: 용어가 단순한 약속이 아니라 코드 아키텍처를 결정하는 1차 자료가 된다.

G스텍: 스펙 브레인스토밍

G스텍의 강점은 브레인스토밍이며, 특히 제품 스펙을 적을 때 핵심 역할을 한다.

  • “아이디어 같이 생각해줘” 수준이 아니라, 스펙에서 뭘 빼고 뭘 살릴지 심도 있게 캐묻는다.
  • 기능 추가 제안 시 통과시키지 않는다: “이게 진짜 핵심 가치에 붙는 기능인가?”, “누가 쓰는가?”, “없으면 어떻게 되는가?”, “비슷한 걸 이미 쓰는 사람이 있는가?”
  • 대표적인 스킬로 YC 오피스 아워 방식이 있다. 6가지 강제 질문을 던진다:
    1. 누가 정말 이걸 원하는가?
    2. 지금 이걸 어떻게 해결하고 있는가?
    3. 이게 진짜 절박한 문제인가?
    4. 가장 작은 단위가 무엇인가?
    5. 직접 본 적이 있는가?
    6. 미래가 보이는가?

슈퍼파워즈: 실제 구현

슈퍼파워즈는 실제 구현 단계의 엔진이다. 세 가지를 메인으로 사용한다:

  1. 브레인스토밍 (구현 상세화): G스텍 브레인스토밍 결과를 받아 코드로 어떻게 풀 것인지 상세 스펙을 확정 짓는다.
  2. 라이팅 플랜 + 플랜 리뷰 에이전트: 구현 계획(플랜)을 작성한 뒤 커스텀 리뷰 에이전트로 플랜을 검토하고 수정하는 루프를 돈다.
  3. 서브 에이전트 드리븐 디벨로먼트: 큰 작업을 여러 개로 쪼갠 뒤 각각을 별도의 서브 에이전트에게 맡긴다. 코드 작업 시 스펙 한 줄을 2~5분짜리 작업 단위까지 쪼개서 분배한다.

통합 워크플로우

그릴 미(Grimoire) 인터뷰 → 도메인 파일 작성 → G스텍 오피스 아워(결정 잡기)
→ 라이트 스펙 → 라이트 플랜 → 플랜 리뷰(검수)
→ 서브 에이전트 코드 작성 → 코덱스(Codex) 리뷰
→ 임프로브 코드베이스 아키텍처 → 스킬 기반 리팩토링

단계별 상세

  1. 그릴 미로 도메인 인터뷰: “이런 거 만들고 싶어” 한 줄 던지고 Claude에게 심층 인터뷰를 요청한다. 30분~1시간 길이의 인터뷰가 진행되며, 적당히 답하면 안 되고 진짜 깊게 답해야 한다. 인터뷰 결과가 그대로 도메인 파일(context.md)이 된다.

  2. G스텍 오피스 아워로 결정 잡기: 그릴 미가 “어떻게 만들지”를 깊게 파는 도구였다면, 오피스 아워는 “이걸 진짜 만들어야 하는가”를 묻는다. 기술적 깊이와 비즈니스적 임팩트를 동시에 잡는다. 이 과정까지 약 1시간 소요되며, 이때까지 코드는 한 줄도 짜지 않는다.

  3. 슈퍼파워즈로 구현: 라이트 스펙 → 라이트 플랜 → 플랜 리뷰 에이전트(시니어에게 검토받는 것처럼 피드백 받아 수정) → 서브 에이전트 드리븐 디벨로먼트(백그라운드에서 여러 개가 동시에 돌아감, 약 2시간) 순으로 진행한다.

  4. 코덱스 크로스 리뷰: 코덱스(Codex) 플러그인을 Claude Code 안에서 함께 쓴다. GPT 코덱스와 Claude는 서로 다른 모델이므로 한쪽이 짠 코드를 다른 쪽이 본다. 사각지대가 잡히며 세세한 구현에서는 코덱스가 더 잘하는 경우도 많다.

  5. 임프로브 코드베이스 아키텍처: 코드가 거의 완성되면 맥퍼커의 임프로브 코드베이스 아키텍처 스킬을 돌려 도메인 언어 기반으로 더 깊게 모델링할 수 있는 부분을 짚어준다. 추가로 프론트엔드(React, Vercel 베스트 프랙티스)나 백엔드(FastAPI 가이드라인) 스킬을 써서 리팩토링을 유도한다.

예시

  • 주문 도메인 작업: 그릴 미 인터뷰로 “주문”이라는 단어가 일반 쇼핑몰 주문인지 음식 배달 주문인지 B2B 발주인지 확인 → context.md에 도메인 정의 작성 → G스텍 오피스 아워로 주문 기능 중 핵심만 선별 → 슈퍼파워즈로 서브 에이전트 분할 구현 → 코덱스로 코드 리뷰
  • 전체 소요 시간: 2~3시간 이상. 길게 느껴지지만 결과물의 차이가 크다.
  • 코드가 도메인 개념과 맞물려 있어, 나중에 손볼 때 어디를 손대야 할지 보인다.
  • 사람이 나중에 수작업으로 버그를 고칠 수 있는 상태가 된다.

충돌

  • 2026-05-28 확인: 이 워크플로우는 특정 스킬 조합과 해강의 작업 방식에 강하게 묶여 있다. 스킬명, 세션 운용 방식, 크로스 모델 리뷰 기준은 실제 환경에서 달라질 수 있으므로, 다른 리포지토리에 그대로 복제하기 전에 현재 사용 중인 도구와 스킬 구성을 다시 확인해야 한다.
  • 맥퍼커, G스텍, 슈퍼파워즈는 원문 맥락을 반영한 별칭이므로, 동일한 역할을 다른 도구로 치환할 때는 역할 단위로 재해석해야 한다.

관련 노트

그래프 뷰

백링크