"제사보다 젯밥" — 부동산 스터디 워크스페이스 분석으로 Claude Code 개발 워크플로우 개선점 찾기

소개

Chat APT 스터디에 참여하게 됐는데, 솔직히 말하면 "제사보다 젯밥"에 관심이 있었습니다.

부동산 분석 자체도 의미 있지만, 스터디장님(지피타쿠님)이 만드신 워크스페이스의 구조와 설계가 눈에 들어왔습니다. 5개 독립 AI 에이전트가 병렬로 토론하는 Council 시스템, 지식 베이스 연동, 독립성 보장 규칙, 의사결정 기록 체계 — 이런 패턴들이 부동산뿐 아니라 일반 개발 워크플로우에도 그대로 적용 가능하겠다는 생각이 들었습니다.

그래서 1주차 과제로 거시/미시 분석을 하기에 앞서, "내 작업 프로세스 자체를 먼저 분석하자"는 접근을 택했습니다. 스터디장님 워크스페이스에서 벤치마킹할 구조적 패턴을 뽑고, 현재 내 Claude Code 환경(38개 플러그인, 15개 커맨드, 4개 훅)을 종합 진단해서 개선안을 도출하는 것이 목표였습니다.


진행 방법

사용 도구

  • Claude Code (Opus, /effort max 모드)

  • /insights — 내 전체 사용 패턴 분석 리포트 (6주간 1,246세션, 521커밋)

  • Gmail MCP — 스터디 1주차 안내 메일 맥락 확인

  • WebFetch — 스터디 소개 페이지 분석

  • Explore 에이전트 — 워크스페이스 구조 병렬 탐색

  • GitHub CLI — naver-land CLI 레포 및 autoresearch 관련 레포 분석

Step 1: 스터디장님 워크스페이스 구조 분석

스터디에서 공유받은 chatapt-budongsan-debate 워크스페이스를 Claude Code로 열고, 전체 구조를 탐색했습니다.

프롬프트:
"현재 프로젝트 폴더에 대한 분석을 해보자. 어떻게 활용하면 좋을지."

Claude가 병렬로 분석한 결과, 핵심 패턴이 드러났습니다:

chatapt-budongsan-debate/
├── 00-system/           # 페르소나 프롬프트 + 프로토콜 + 템플릿
│   ├── prompts/         # Bull, Bear, Analyst, Veteran, Regulator (5인)
│   ├── protocols/       # 독립성 보장 규칙, 분석 절차
│   └── templates/       # 세션/분석/의사결정 기록 양식
├── 30-analysis/         # 토론 세션 + 리서치 결과물
├── 40-knowledge-index/  # 지식 베이스 (책에서 축적한 데이터)
├── 50-decisions/        # 의사결정 기록 + 사후 회고
├── 70-playbook/         # 성공 패턴 / 실패 교훈 / 인사이트
├── 90-archive/          # 완료된 분석
└── .claude/skills/      # budongsan-council, agent-council, research

핵심 발견: "지식 축적 → 멀티 관점 분석 → 의사결정 기록 → 회고" 사이클이 체계적으로 설계되어 있다는 것. 특히 5인 Council의 독립성 원칙("사용자가 좋아 보인다 해도 동조하지 않는다")은 AI 편향을 방지하는 훌륭한 패턴이었습니다.

Step 2: 내 환경 전체 진단

프롬프트:
"현재 워크스페이스의 구조를 부동산이 아니라 일반적인 개발 환경에 적용한다면
어떻게 하는게 좋을까? 이외에 설치하고 사용이 안되고 같이 사용하면 좋을
스킬들, 플러그인 마켓플레이스는 등록했으나 미사용 스킬들 중 사용하면 좋은
스킬들 등 복합적으로 현재 워크스페이스를 기반으로 개선안 도출해줘."

주요 발견:

  • 코드 리뷰 도구가 4곳에 분산 (code-review, pr-review-toolkit, superpowers, feature-dev) → 상황별 선택 기준 부재

  • 멀티에이전트 도구도 4곳 분산 (superpowers, kkirikkiri, fireauto, pumasi)

  • PM 스킬 60개+ 중 실제 사용은 5개 미만

  • kotlin-lsp, swift-lsp — 해당 언어 프로젝트 없음

Step 3: /insights로 데이터 기반 자기 진단

/insights

6주간 사용 데이터 분석 리포트 (클코 세션 파일들 날려먹어서 제대로 분석 된건지는..ㅋㅋ)

항목

분석 세션

244개

커밋 수

521개

만족도

78% (full/mostly achieved)

최다 마찰

wrong approach 67건

2위 마찰

buggy code 43건

3위 마찰

misunderstood request 30건

Step 4: 교차 분석

스터디장님 워크스페이스 패턴 × 내 마찰 데이터 × 외부 사례를 교차하니 구체적 개선안이 나왔습니다.

외부 사례로 3개 GitHub 레포와 @keke_appa님이 공유한 멀티 에이전트 개발 규칙도 참고했습니다:

  • karpathy/autoresearch (5.7만 스타) — AI 자동 실험 루프의 원조. "수정 → 측정 → 개선이면 keep, 아니면 discard" 패턴

  • VoidLight00/autoimprove-cc — 위 패턴의 Claude Code 네이티브 구현. SKILL.md를 자동 개선

  • @keke_appa님의 멀티 에이전트 개발 규칙 — Codex + Claude + Kimi 병렬 운영, 문서 먼저 원칙, 에이전트별 Daily 기록

Step 5: 사례글 작성도 Claude Code로

분석 결과를 스터디 사례글로 정리하는 것까지 Claude Code에 맡겼습니다.

프롬프트:
"지피터스 스터디로 [스터디 URL] 에 참여 중이고, 스터디장님이 1주차 안내로
지메일 공유를 해줬다. 제사보다 젯밥에 관심이 있다고 부동산에 대한 claude code
활용에 앞서, 현재 내 작업 프로세스에 대한 검토 및 스터디장님 워크스페이스에서
벤치마킹할 부분들에 대한 검토를 하고자 하였다. 이에 대한 사례글 작성 해줘."

Claude가 Gmail MCP로 스터디 1주차 안내 메일을 읽고, WebFetch로 스터디 소개 페이지를 분석한 뒤, 대화 전체 맥락(Step 1~4)을 종합해서 사례글 초안을 생성했습니다. 조사 → 분석 → 문서화까지 하나의 세션에서 끊김 없이 진행한 셈입니다.


결과와 배운 점

배운 점과 나만의 꿀팁

1. "워크스페이스 = 사고 프레임워크"

스터디장님 워크스페이스를 보고 깨달은 것은, 폴더 구조가 단순한 파일 정리가 아니라 "어떤 순서로 생각할 것인가"의 설계라는 점입니다. 00-system → 30-analysis → 50-decisions → 70-playbook이 곧 "규칙 정의 → 분석 실행 → 결정 → 회고" 사이클입니다.

이걸 일반 개발에 매핑하면:

CLAUDE.md (규칙)  →  구현 (코드)  →  ADR (결정 기록)  →  memory/ (회고)

2. /insights 교차 분석이 핵심

/insights 혼자로는 "wrong approach가 67건이네" 수준이고, 워크스페이스 분석 혼자로는 "이런 구조가 있네" 수준입니다. 둘을 교차하니 "wrong approach의 원인이 도구 선택 기준 부재 → 스터디장님 Council처럼 역할별 분리하면 해결"이라는 구체적 액션이 나왔습니다.

3. 독립성 규칙이야말로 가장 이식 가능한 자산

스터디장님 워크스페이스에서 가장 인상 깊었던 건 폴더 구조가 아니라 독립성 원칙이었습니다:

independence_rules:
  no_user_bias: "사용자가 좋아 보인다 해도 동조하지 않는다"
  data_first: "느낌상... 발언 금지"
  uncomfortable_truth: "듣고 싶지 않은 것도 직접 말한다"
  no_softening: "조금 높은 편 ❌ → PIR 15배로 평균 대비 25% 고평가 ✅"
  source_or_silence: "출처 없는 주장은 하지 않는다"

이건 부동산이 아니라 모든 AI 협업에 적용해야 할 규칙입니다. "이 아키텍처 괜찮지?"라고 물으면 Claude가 동조하기 쉬운데, 독립성 규칙이 있으면 트레이드오프를 먼저 제시하게 됩니다. 전역 CLAUDE.md에 개발 버전으로 추가할 예정:

independence_rules:
  no_confirmation_bias: "먼저 대안과 트레이드오프를 제시한 뒤 판단"
  benchmark_or_silence: "빠를 것 같다 ❌ → p99 latency 12ms ✅"
  uncomfortable_tradeoff: "선호 기술이라도 요구사항에 안 맞으면 직접 말한다"
  docs_or_caveat: "공식 문서에서 확인 안 된 동작은 추측이라고 명시"

4. Autoresearch 루프 — 스킬도 자동으로 개선할 수 있다

Karpathy의 autoresearch(5.7만 스타)가 보여준 패턴은 단순합니다: 코드 수정 → 측정 → 개선이면 keep, 아니면 discard → 반복.

이 패턴은 ML 학습뿐 아니라 번들 사이즈, 테스트 속도, Lighthouse 점수, 심지어 Claude Code 스킬 품질까지 — 숫자로 표현되는 모든 것에 적용할 수 있습니다.

Claude Code 네이티브 구현체(autoimprove-cc)가 이미 존재해서, 설치 후 바로 내 15개 커맨드와 3개 스킬에 자동 개선 루프를 돌릴 수 있습니다.

5. 멀티 에이전트 시대의 개발 규칙

@keke_appa님이 공유한 멀티 에이전트 개발 규칙(Codex + Claude + Kimi 병렬 운영)이 인상적이었습니다. 핵심 패턴 3가지:

  • 문서 먼저 — "모든 개발은 반드시 문서화를 먼저 진행한다." 내 /create-handbook이 비슷한 역할이지만, 이 규칙은 "구현 전에 문서부터"라는 순서가 다름

  • 에이전트별 Daily 기록docs/daily/YYYY-MM-DD/{codex,claude,kimi}.md. 어떤 에이전트가 뭘 했는지 추적 가능

  • AGENTS.mdCLAUDE.md 양방향 동기화 — 에이전트별 지침 분리 + 동기화

6. 설치만 하고 안 쓰는 플러그인 정리가 필요

38개 활성 플러그인 중 실제 자주 쓰는 건 10개 남짓. kotlin-lsp, swift-lsp처럼 해당 언어 프로젝트가 없는데 켜둔 것도 있었고, PM 스킬 60개 중 실용적인 건 5개 정도. 가벼운 환경이 빠른 환경입니다.

시행착오

  • 처음에는 워크스페이스를 그대로 개발 프로젝트에 복사하려 했으나, 부동산 워크스페이스는 비코드 분석 자산이 많아서 폴더가 많은 구조. 일반 개발은 코드 + git이 주 자산이므로 CLAUDE.md + memory + ADR 정도로 경량화하는 게 맞았음

  • /insights 데이터의 초반 마찰(릴리스 노트 한글, main 직접 커밋 등)이 이미 훅으로 해결된 것도 있어서, 현재 시점 기준으로 필터링하는 작업이 필요했음

앞으로의 계획

순위

할 일

출처

1

전역 CLAUDE.md도구 선택 가이드 추가

?

2

개발용 독립성 규칙 추가

스터디장님 워크스페이스

3

디자인 스킬 맵 전역화

-

4

/defer-issue 커맨드 생성

/insights 교차 분석

5

/autoimprove 도입 → 핵심 스킬 자동 개선

autoimprove-cc

6

문서 먼저 원칙 명시

@keke_appa님 개발 규칙

7

불필요 LSP 플러그인 정리

환경 분석

8

project-health에 handbook 최신성 체크

환경 분석

2주차부터는 이 개선된 환경 위에서 실제 부동산 분석을 돌려볼 예정입니다. 네이버 부동산 CLI도 연동해서 Council 토론 시 실시간 매물 데이터를 공급하는 구조를 테스트할 계획입니다.


도움 받은 글

1
1개의 답글

뉴스레터 무료 구독

👉 이 게시글도 읽어보세요