오래된 SW 엔지니어의 평생 공부

우리는 오랫동안 소프트웨어 제품을 만들기 위해서, User Story, Use Case, Functional Scenario를 사용해 왔다.
이 도구들은 “무엇을 만들어야 하는가”를 정리하는 데 매우 효과적이다.

지난 번에 Generative Sequence를 사용해서 같은 프로젝트를 다르게 개발하는 방법을 사용하였다.

한단계 좀 더 나아가서, 이번 시나리오 플래닝 프로젝트처럼

• 아직 사용자의 경험이 명확하지 않고
• 문제 정의 자체가 진행 중에 바뀌며
• 정답보다 탐색(Exploration)이 중요한 상황에서는 다른 질문이 필요했다.

“이 기능이 맞는가?”가 아니라
“이 경험이 살아 있는가?”

이 질문에 답하는 과정에서, Generative Sequence와 User Story Map을 함께 사용하면서
개발의 감각 자체가 달라지기 시작했다.

1. Generative Sequence: 고객을 ‘공동 설계자’로 바라보기

Generative Sequence는 완성된 설계를 먼저 두지 않는다.
대신 매 순간 이렇게 묻는다.

• 지금 이 변화가 전체 경험을 더 살아 있게 만드는가
• 이 작은 변화가 다음 변화를 자연스럽게 부르는가

이 관점에서 고객은
더 이상 완성된 결과물에 피드백을 주는 사람이 아니다.

다음 구조를 함께 만들어 가는 공동 설계자가 된다.

이번 프로젝트에서도 우리는 요구사항을 “확정”하기보다,

• 사용자가 어느 Phase에서 멈칫하는지
• 왜 다음 단계로 넘어가기 어려운지
• 이 단계가 정말 이 시점에 필요한지

를 관찰했고, 그 막힘을 해소하는 작은 Transformation을 반복했다.

그 결과, PRD는 문서가 아니라 계속 진화하는 구조(Living PRD)가 되었다.

2. User Story Map은 User Story와 다르다

User Story Map은 User Story를 정리한 또 다른 형식이 아니다.
사고의 출발점 자체가 다르다.

① 기능이 아니라 ‘경험의 흐름’이 중심이다

User Story는 쉽게 기능 단위로 쪼개진다.

“사용자로서 ○○을 하고 싶다.”

반면 User Story Map은 이렇게 묻는다.

• 사용자는 어떤 순서로 움직이는가
• 이 흐름에서 어디서 이해하고, 어디서 고민하고, 어디서 결단하는가

이번 시나리오 플래닝 프로젝트에서도 Phase 1~8은 단순한 단계가 아니라
하나의 사용자 여정으로 보이기 시작했다.

② 목록(List)이 아니라 지도(Map)다

목록 기반 개발에서는 “이 스토리는 끝났다”가 중요하다.

지도 기반 개발에서는

👉 “여기서 경험이 끊긴다”가 즉시 보인다.

실제로 Story 하나가 빠지거나 어색해질 때,
사용자 경험의 단절이 바로 드러났다.

③ 개발 중 ‘생각의 방향’이 달라진다

이 차이는 개발 과정에서 더 분명해진다.

기존 Iterative 개발

기능 구현 → 테스트 → 다음 기능

User Story Map × Generative Sequence

사용자 행동 상상
 → 이를 가능하게 하는 Task
 → 구현 중 “이 Activity 정의가 이상한데?” 인식
 → Activity 재정의
 → Story Map 수정

개발이 진행될수록 스토리가 고정되는 게 아니라 사용자 경험의 정의가 점점 정교해진다.

3. “경험이 깨지는 순간”을 아주 빨리 알아차린다

User Story Map의 가장 큰 장점은 이것이다.

사용자 경험이 깨지는 순간을, 개발자가 즉시 인지할 수 있다.

• 왜 이 Phase에서 사용자가 다음으로 못 가는지
• 이 기능이 앞뒤 맥락 없이 튀어나온 건 아닌지
• 지금 추가하려는 변화가 흐름을 강화하는지, 분절시키는지

이 모든 것이 지도 위에서 바로 보인다.

그래서 우리는 큰 리팩토링 전에, “이 방향은 아닌 것 같다”는 신호를
아주 이른 시점에 감지할 수 있었다. 

이것이 우리가 더 Adaptive하게 움직일 수 있었던 이유다.

4. 시나리오 플래닝 프로젝트에서 얻은 구체적 장점

이번 프로젝트에서 이 접근이 특히 잘 맞았던 이유는 명확하다.

• Phase 중심이 아닌 사용자 여정 중심 구조
  → 사용자가 “왜 이 단계를 하는지”를 자연스럽게 이해
• Transformation 단위 개발과의 궁합
  → 기능 추가가 아니라 _경험을 더 살아 있게 만드는가_로 평가
• Living PRD의 현실화
  → PRD, User Story, Transformation Log가 하나의 구조로 함께 진화
• AI를 공동 설계 파트너로 사용 가능
  → “이 기능 만들어줘”가 아니라
  “이 경험의 다음 변화를 어떻게 설계할까?”를 묻게 됨

마무리하며

이번 경험을 통해 확신하게 되었다.

좋은 개발은 기능을 잘 쌓는 일이 아니라,
경험이 스스로 자라나게 돕는 일이다.

User Story와 Iteration은 여전히 중요하다.

하지만 불확실성이 큰 문제, 아직 정답이 없는 영역에서는 그것만으로는 부족하다.

User Story Map은
👉 경험을 보는 눈을 제공하고,
Generative Sequence는
👉 그 경험을 살아 있게 만드는 변화의 리듬을 제공한다.

그리고 이 둘이 만날 때, 우리는 고객을 요구사항의 출처가 아니라 진짜 ‘공동 설계자’로 대하게 된다.

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

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 방식 (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