같은 요구사항, 같은 기술 스택, 완전히 다른 결과물

들어가며: 왜 같은 프로젝트를 두 번 만들었나?

Vibe Coding으로 복잡한 요구 사항을 다루어 보려고, GPTers와 유사한 학습 플랫폼을 만들기로 했다. 많은 사람들이 접근하는 방법에 따라서 요구 사항(PRD)를 만들고 단계적 접근 방법 (Iterative Approach)를 따라서 접근했다. 기능을 하나씩 완성해가며 쌓아올리는 방법이다.

 

그런데, 의문이 생겼다. 이 방법이 정말 좋은 것인가?

 

이 때 떠오른 방법이 Christopher Alexander의 Nature Of Order에서 설명하는 생성적인 접근법(Generative Sequence)을 써보고 비교해보고 싶었다. 즉, 구조적 개선을 중심으로 점진적으로 진화시키는 방법이다.

 

결론부터 말하자면, 둘 다 만들어봤다.

 

그리고 그 과정에서 깨달았다. 개발 철학의 차이가 코드 몇 줄보다 훨씬 큰 영향을 미친다는 것을.

---

Part 1: 두 프로젝트의 탄생

StudyBlog: "완성된 기능을 쌓아가는 방식"

핵심 철학: "작동하는 것부터 만들자"

Phase 1 (MVP)
├── Iteration 1: 프로젝트 초기 설정
├── Iteration 2: 인증 시스템 ✅
├── Iteration 3: 게시물 CRUD ✅
├── Iteration 4: 카테고리 시스템 ✅
└── Iteration 5: UI 개선 ✅

Phase 2
└── Iteration 6: 코드 품질 개선 🔄

결과:

•  기본 블로그 기능 완벽 작동
•  Supabase + Drizzle ORM으로 안정적인 DB
•  다크모드, 반응형 디자인

하지만:

• 일반적인 블로그와 차별화 포인트 부족
• AI 기능은 "미래 계획"으로만 존재

StudyBlogGenSeq: "구조를 진화시키는 방식"

핵심 철학: "이 변경이 사용자 경험을 어떻게 개선하는가?"

이 방식은 Christopher Alexander가 건축에서 설명한 원리와 놀랍도록 유사하다.

Alexander는 이렇게 말한다:

 

"만약 당신이 정말로 땅, 부지, 그리고 형성되어가는 건물의 전체성(wholeness)을 따르고, 그 전체성이 자연스럽게 전개되도록 허용한다면—처음의 (그리고 임의적인) 이미지는 점차적으로 상식, 즉 현실과 자리하고 있는 것의 전체성에 자리를 내주게 될 것이다."

 

소프트웨어 개발에서도 마찬가지다. "AI 학습 플랫폼"이라는 초기 이미지에서 출발했지만, 실제로 사용자가 글을 쓰는 과정을 관찰하고, 그들이 겪는 어려움을 이해하면서, 현실이 말해주는 바에 따라 구조가 진화했다.

 

Phase 1: Foundation ✅
Phase 2: AI Editor Core ✅
├── 실시간 문장 개선 (GPT-4o-mini)
├── 자동 태그 생성 (16개 키워드 감지)
├── 템플릿 시스템 (학습경험/프로젝트후기/튜토리얼)
└── Multi-provider AI 아키텍처 (OpenAI/Claude)

Phase 3: Database & Community 🔄
└── LocalStorage → Supabase 전환 예정

결과:

• 실제로 작동하는 AI 글쓰기 어시스턴트
•  템플릿으로 초보자도 구조화된 글 작성
•  2초 후 자동 태그, 8초 후 문장 개선 제안
• 완전한 Write → Publish → Explore 워크플로우
•  LocalStorage로 즉시 발행 가능

트레이드오프:

• AI 비용 지속 발생 ($100-200/월 예상)

---

Part 2: 철학의 차이가 만든 결과들

1. "무엇을 먼저 만드는가?"

Alexander의 건축 비유를 계속해보자. 그는 원통형 집의 이미지에서 출발한 건축가를 예로 든다.

Iteration 방식 (StudyBlog)은 이렇게 말한다:

• "원통형 집을 짓기로 했어. 먼저 기초를 완성하고, 그 다음 벽을 세우고, 지붕을 올리고, 마지막에 창문을 내자."
• 각 단계는 완벽하게 끝나야 다음으로 진행할 수 있다.
• 이미지가 주도권을 갖는다.

Transformation 방식 (StudyBlogGenSeq)은 이렇게 말한다:

• "원통형이라는 이미지로 시작했지만, 이 땅의 경사를 보니 다른 형태가 더 자연스럽겠어."
• "나무의 위치를 보니 창문은 여기에 있어야 해."
• "전망을 고려하면 현관의 방향이 바뀌어야 해."
• 현실이 주도권을 갖는다.

Alexander의 말대로:

"점진적으로, 천천히, 단계적으로, 당신의 선행 이미지 속 모든 요소들은 녹아 사라지게 되며, 현실과 상식은 전혀 다른 것을 만들어내게 된다."

 

StudyBlog의 우선순위

1. 인증 → 2. CRUD → 3. 카테고리 → 4. UI → 5. AI(?)

논리: "기본 기능이 완성되어야 AI를 얹을 수 있다"

StudyBlogGenSeq의 우선순위

1. AI 에디터 → 2. 템플릿 → 3. 워크플로우 → 4. DB

논리: "AI가 핵심 차별화 요소다. 먼저 증명하자"

결과의 차이

• StudyBlog: 안정적이지만 평범한 블로그
• StudyBlogGenSeq: AI 기능을 완성하고 불확실한 이 부분에 집중이 가능하다.

---

Part 3: CLAUDE.md - AI 페어 프로그래밍 가이드의 차이

두 프로젝트는 Claude AI와 협업하는 방식도 완전히 달랐다. 그 차이가 CLAUDE.md 파일에 고스란히 담겨있다.

StudyBlog의 CLAUDE.md: "실용적 가이드"

파일명: CLAUDE.md (37줄)

핵심 내용:

# Context Awareness & Code Preservation
- 사용자 정의 코드 구조와 네이밍 보존
- 명시적 지시가 없으면 리팩토링 금지

# Clarity and Traceability
- 생성/수정된 모든 코드에 명확한 설명과 TODO 마커

# Modular Thinking
- 모듈화되고 테스트 가능한 구현
- 유틸 함수, 재사용 가능한 컴포넌트

# Iterative Development
- 작은 테스트 가능한 단계로 분할
- 다음 단계로 진행 전 사용자 확인

# Documentation & Library Integration
- context7 MCP로 최신 문서 검색
- 공식 문서 패턴 우선 사용

특징:

•  실용적이고 간결함
•  전통적인 개발 Best Practice
•  "어떻게 코드를 짜야 하는가"에 집중
•  라이브러리 통합과 문서화 강조

철학: "Claude는 코딩 도우미"

---

StudyBlogGenSeq의 CLAUDE.md: "Transformation Agent"

파일명: CLAUDE.md (96줄, StudyBlog의 2.6배)

핵심 내용:

##  목적: Transformation 중심 AI Pair Programming

- **구조적 생명력(Structural Life) 향상**
- **살아있는 구조(Living PRD)**로 진화
- **Transformation 단위 진행** (Iteration이 아님)
- **맥락 보존(Context-preserving)** 개발

##  운영 원칙

### Generative Sequence 기반 개발 루프
1. 맥락 로드: PRD, 기존 코드, Transformation Log 확인
2. Transformation 정의: '작은 구조적 변화 한 가지'
3. 설계 옵션 제안: 2~3개 대안과 트레이드오프
4. 코드 생성/수정: 작은 PR(diff) 단위
5. 맥락 보존 검증: 구조 퀄리티 메트릭 체크
6. 문서 업데이트: Living PRD, Backlog, Transformation Log
7. 후속 Transformation 제안: 다음 단계 후보 제시

##  Transformation 템플릿
- Intent: 구조 개선 목표 (문제-맥락-해결책)
- Change: 변경 내용
- Constraints: 제약 조건
- Design Options: A/B/C - 트레이드오프 포함
- Chosen & Rationale: 선택과 근거
- Acceptance: 테스트/데모 기준
- Impact: API/데이터/UX/문서 영향
- Structural Quality Metric Change: 응집도/결합도 변화
- Follow-ups: 후속 작업

특징:

•  Christopher Alexander의 철학 반영
•  "구조적 생명력" 향상이 목표
•  Iteration이 아닌 Transformation 단위
•  Living PRD - 문서가 살아 진화함
•  고객을 "공동 설계자"로 간주

철학: "Claude는 Transformation Agent"

---

CLAUDE.md 비교표

항목	StudyBlog	StudyBlogGenSeq
분량	37줄	96줄 (2.6배)
개발 단위	Iteration	Transformation
문서 철학	정적 가이드	Living Document
Claude의 역할	코딩 도우미	Transformation Agent
핵심 개념	Best Practice	Structural Life (구조적 생명력)
의사결정	사용자 확인 후 진행	2-3개 옵션 + 트레이드오프 제시
문서화	코드 설명 중심	PRD/TRANSFORMATIONS/BACKLOG 진화
검증 방식	테스트 케이스	구조 퀄리티 메트릭
고객 관점	피드백 제공자	공동 설계자

---

실제 개발 과정의 차이

StudyBlog 방식 (Iteration)

개발자: "인증 시스템 만들어줘"
Claude: "Supabase Auth 사용하시겠습니까?"
개발자: "응"
Claude: [코드 생성]
개발자: "좋아, 다음은 게시물 CRUD 만들어줘"

특징: 명확하고 빠름, 한 번에 한 가지 완성

---

StudyBlogGenSeq 방식 (Transformation)

개발자: "사용자가 글을 잘 쓸 수 있게 도와주고 싶어"

Claude (Transformation Agent):
"T-20251003-001: AI 글쓰기 어시스턴트 추가

Intent:
- 초보자도 구조화된 글을 쓸 수 있게 AI 제안 제공
- 사용자 경험의 핵심 차별화 요소

Design Options:
A) OpenAI만 사용 (빠름, 비용 $0.15/1M tokens)
B) Claude만 사용 (고품질 한국어, $3.00/1M tokens)
C) Multi-provider (유연성, Factory Pattern)

트레이드오프:
- A: 빠르지만 한국어 품질 낮음
- B: 품질 좋지만 비용 20배
- C: 복잡하지만 상황별 선택 가능

Chosen: C (Multi-provider)
Rationale:
- 개발 시 Mock 사용 (비용 $0)
- 프로덕션 시 OpenAI/Claude 선택 가능
- 한 Provider 장애 시 Fallback

Impact:
- 사용자: 8초 대기 후 개선안 확인
- 비용: $50/월 (1000 요청)
- 코드: Factory Pattern 추가

Structural Quality Metric:
- 응집도: AI 서비스 레이어 분리 → 향상
- 결합도: Interface로 Provider 격리 → 감소
- 테스트 용이성: Mock으로 API 없이 테스트 가능

Follow-ups:
- T-20251003-002: 요청 캐싱으로 비용 50% 절감
- T-20251003-003: 사용자 피드백 수집 시스템

특징: 느리지만 깊이 있음, 구조적 사고 강제됨

---

어느 것이 더 나은가?

StudyBlog 방식의 장점

 

• 빠른 진행: 질문-답변-구현으로 즉시 완성
•  명확한 목표: 한 번에 한 가지만
•  낮은 진입 장벽: 전통적인 개발 방식
•  실용성: Best Practice 즉시 적용

StudyBlogGenSeq 방식의 장점

• 구조적 사고: 왜, 어떻게, 다음은?
•  의사결정 기록: Transformation Log로 근거 추적
•  진화하는 문서: Living PRD가 계속 업데이트
•  트레이드오프 인식: A vs B vs C를 항상 고려

 

---

깨달은 것

1. CLAUDE.md는 "개발 철학의 선언문"

• StudyBlog: "Claude야, 내가 시키는 대로 코드 짜줘"
• StudyBlogGenSeq: "Claude야, 나와 함께 구조를 진화시켜줘"

2. 같은 AI, 다른 역할

• 코딩 도우미 Claude: 빠르지만 얕은 협업
• Transformation Agent Claude: 느리지만 깊은 협업

3. 문서는 "과거 기록" vs "미래 설계도"

StudyBlog:

## Iteration 3
- [x] 게시물 CRUD 완료
- [x] 카테고리 추가

→ "무엇을 했는가"

StudyBlogGenSeq:

## T-20251003-001
Intent: 초보자도 전문가처럼
Options: A/B/C
Chosen: C
Follow-ups: 캐싱, 피드백

→ "왜 이렇게 했는가, 다음은?"

4. 속도 vs 품질의 트레이드오프

• Iteration 방식: 빠르게 완성 → 나중에 리팩토링 (언제?)
• Transformation 방식: 천천히 진화 → 구조는 항상 깔끔 (하지만 느림)

---

결론: 당신의 CLAUDE.md는 어떤가?

이 글을 읽는 당신에게 질문하고 싶다.

당신의 CLAUDE.md는 어떤 철학을 담고 있는가?

• Claude를 "코딩 도구"로 쓰는가?
• Claude를 "공동 설계자"로 쓰는가?

빠른 완성이 목표라면 → StudyBlog 방식

• 37줄의 간결한 가이드
• Iteration 단위
• Best Practice 즉시 적용

구조적 진화가 목표라면 → StudyBlogGenSeq 방식

• 96줄의 Transformation 철학
• Living PRD
• 트레이드오프 기반 의사결정

정답은 없다. 하지만 선택은 해야 한다.

그리고 그 선택이 CLAUDE.md에 담겨야 한다.

왜냐하면, CLAUDE.md는 단순한 설정 파일이 아니라, 당신의 개발 철학이 담긴 선언문이기 때문이다.

참고 문서

StudyBlog: https://github.com/blcktgr73/StudyBlog
StudyBlogGenSeq: https://github.com/blcktgr73/StudyBlogGenSeq