## 📝 한줄 요약
웹 풀스택 개발 50% 진행 후 안드로이드 앱으로 전환 결정. 비개발자가 Claude Code와 협업해 하루 만에 시니어급 마이그레이션 전략과 7개 전문 설계 문서(149KB)를 완성했습니다.
## 😫 문제 상황 (Before)
개인 투자자의 거래 데이터를 분석해서 행동지표(Behavior Index)를 산출하고, AI 코칭으로 투자 행동 개선을 돕는 서비스를 만들고 있었습니다. Rails 웹 풀스택으로 50% 정도 개발을 진행했는데, 본격적인 안드로이드 앱 출시를 앞두고 큰 고민에 빠졌습니다.
**구체적인 문제들:**
1. **복잡한 데이터 흐름**: 거래 데이터 수집 → 행동지표 계산 → AI 분석 → 리포트 생성까지 복잡한 로직인데, 최종 UI가 어떻게 나올지 보이지 않으니 전체 시스템을 직관적으로 이해하기 힘들었습니다.
2. **설계 재검토 필요**: 초기 프로토타입(v2)을 여러 번 수정했지만 계속 아쉬웠습니다. 특히 관계형 데이터베이스 구조도에 공을 들였는데 만족스럽지 않았습니다.
3. **웹→앱 전환 막막**: 공들여 만든 DATABASE-SCHEMA와 Behavior Index 알고리즘, 웹 개발 환경을 버리지 않으면서 안드로이드앱 모바일의 기동성을 확보하려면 어떻게 해야 할지 방향을 못 잡겠더군요.
4. **비개발자의 한계**: 계속 노트에 적으면서 AI의 복잡하고 현란한 제안들을 스스로 이해하려 했지만, 개발 문서의 버전관리가 제대로 안 돼서 좌표를 잃은 느낌이었습니다
이 상태로는 더 이상 진행이 어려웠고, 설계를 전면 재검토해야겠다고 결심했습니다.
## 🛠️ 사용한 도구
- **도구명**: Claude Code
- **모델**: Claude Sonnet 4.5
- **환경**: Ruby on Rails 8.1.1, PostgreSQL 16
- **목표**: 웹(Rails) → 앱(Flutter) 마이그레이션 전략 수립
## 🔧 작업 과정
### 첫 삽: 기존 설계 문서 어디까지 왔나 확인
웹 개발을 50% 진행한 상태이고 2주동안 쉬어서 프로젝트 문서가 여기저기 흩어져 있었습니다. 버전관리가 안 돼서 어떤 게 최신인지도 헷갈렸죠. 일단 Claude에게 "마지막 버전의 데이터 구조도 설계 계획 찾아줘"라고 요청했습니다.
> behavior lab에서 마지막 버전의 데이터 구조도 설계 계획 찾아줘.
Claude가 PRD.md, PROJECT-PLAN.md 같은 핵심 문서들을 분석하더니, 기존 v2.2는 4개 테이블로 구성되어 있었고, 원래 계획했던 7-Table 구상이 있다는 걸 찾아냈습니다.
"아, 내가 초기에 이렇게 설계하려고 했었지!" 하는 기억이 되살아났습니다. 채팅 기록에 남아있던 덕분에 좌표를 되찾을 수 있었습니다.
---
### 막힌 지점: 복잡한 로직, 끝이 안 보인다
여기서 큰 문제에 부딪혔습니다. 투자행동 데이터 분석은 굉장히 복잡합니다. 거래 데이터 수집 → 손절/익절 패턴 분석 → 행동지표 계산 → 위험도 산출 → AI 코칭 메시지...
이 긴 파이프라인의 **최종 결과물(UI)**이 어떻게 나오는지 보이지 않으니, 데이터베이스를 어떻게 설계해야 할지 감이 안 오더군요. Forward(처음부터 끝까지) 방식으로 생각하니 머리가 복잡했습니다.
그래서 접근 방법을 바꿨습니다. "Stitch(게시판)에 올릴 최종 결과물이 뭔지부터 정리하자. 거기서 역으로 거슬러 올라가면 되잖아?"
> v3 설계를 실제로 구현할 때 필요한 프롬프트 문서를 만들어줘.
**Backward 접근**으로 요청하니, Claude가 최종 UI 화면에 필요한 데이터부터 역으로 추적해서 데이터 구조도와 디자인 스크립트를 단숨에 요약해줬습니다. 첫 번째 결과치고는 나쁘지 않았습니다.
### 돌파: v2 반복 끝에 v3 탄생
사실 데이터베이스 구조도는 이번이 처음이 아니었습니다. v2에서 여러 번 시도했지만 계속 아쉬웠습니다. "이건 아닌데..." 하면서도 뭐가 문제인지 명확히 표현하기 어려웠죠.
하지만 이번엔 달랐습니다. Claude에게 계속 push했습니다.
"여기 이 부분이 마음에 안 들어. 종목 정보가 거래 테이블에 중복 저장되는 게 비효율적이야."
"투자 원칙(손절선, 익절선)을 하드코딩이 아니라 DB로 관리하고 싶어."
"시장 급락 구간 같은 맥락 정보를 추적하고 싶은데 어떻게 하지?"
이렇게 계속 불만을 얘기하고 개선을 요청하니, Claude가 10개 테이블 아키텍처로 확장한 v3를 제시했습니다.
- **instruments 테이블**: 종목 정보 분리 (섹터, 베타 등)
- **investment_policies 테이블**: 투자 원칙 DB화
- **market_regimes 테이블**: 시장 국면 추적
- **positions 테이블**: 실시간 보유 현황 + 손절 위반일 추적
드디어 "이거다!" 싶었습니다. v2의 여러 버전을 거쳐 v3에서 만족스러운 결과가 나왔습니다.
---
### 게임 체인저: 비개발자가 시니어급 전략을 받다
이제 가장 중요한 부분이었습니다. 웹에서 안드로이드 앱으로 전환하려는데, 기존 자산(DB 설계, 알고리즘, 웹 구조)을 버리기엔 너무 아까웠습니다.
> Rails 백엔드는 그대로 두고, 프론트엔드를 Flutter로 전환하는 계획 수립해줘.
Claude가 제시한 건 합리적이었어요.
**1) Monorepo 전략**
Rails API 서버 + Flutter 클라이언트를 분리하되, 한 저장소에서 관리하는 시니어 개발자급 아키텍처를 제안했습니다. 비개발자인 저로서는 이런 전략이 있는지도 몰랐습니다.
**2) 기존 자산 최대 활용**
- DATABASE-SCHEMA v3: 그대로 활용
- Behavior Index 알고리즘: Rails 서버에 보존
- 웹 개발 환경: API 서버로 전환만 하면 됨
**3) 모바일 기동성 확보**
Flutter로 네이티브 앱 경험 제공하면서도, 복잡한 비즈니스 로직은 Rails에서 처리. 최고의 조합이었습니다.
**4) 잠재적 문제 + 대안까지**
- 문제: "API 응답 속도가 느려질 수 있음"
- 대안: "캐싱 전략 + 백그라운드 Job 활용"
- 문제: "Flutter 웹 빌드는 SEO 약함"
- 대안: "Rails SSR로 랜딩 페이지 유지"
이 모든 걸 단기간 로드맵으로 정리해줬습니다. Week 1-2는 환경 설정, Week 3-4는 핵심 화면, Week 5는 리포트, Week 6은 QA. 실행 가능한 계획이었습니다. 이 모든걸 다시 2주 안으로 완성하게 push할려구요.
---
### 폭풍 문서화: 하루에 7개 전문 문서
이 과정에서 Claude가 만들어준 문서들입니다.
1. **DATABASE-SCHEMA-v3.md (34KB)** - 10개 테이블 ERD
2. **DESIGN-PROMPTS-v3.md (26KB)** - 단계별 구현 가이드
3. **FLUTTER-MVP-PLAN-v2.md (35KB)** - 6주 마이그레이션 로드맵
4. **MIGRATION-ROADMAP-v3.md (17KB)** - v2→v3 안전한 전환 계획
5. **UI-SCREENS-v3.md (37KB)** - 12개 화면 설계
6. **DATA-STRUCTURE-SUMMARY-v3.md (8KB)** - 한눈에 보는 요약
7. **DESIGN-PROMPTS-v3-SUMMARY.md (12KB)** - 빠른 참조용
총 149KB, 혼자 했으면 최소 일주일은 걸렸을 작업을 하루 만에 끝냈습니다.
---
## ✅ 결과 (After)
### Before vs After
| 항목 | Before | After |
|------|--------|-------|
| 데이터 구조 | v2 (4개 테이블, 만족 못함) | v3 (10개 테이블, 만족) |
| 앱 전환 전략 | 방향 못 잡음 | 6주 실행 로드맵 완성 |
| 설계 문서 | 흩어져서 좌표 상실 | 7개 전문 문서 (149KB) 체계화 |
| 프로젝트 추진력 | 막막해서 멈춤 | 구체적 다음 단계 명확 |
| 소요 시간 | (예상) 일주일 이상 | 실제 하루 (약 8시간) |
### 결과물
**1) 시니어급 아키텍처 전략**
- Monorepo 구조로 Rails + Flutter 통합 관리
- 기존 자산(DB, 알고리즘) 100% 활용
- 잠재적 리스크 + 대안까지 정리
**2) 실행 가능한 로드맵**
- Week별 구체적 작업 명시
- 각 단계별 검증 포인트 포함
- 혼자서도 따라갈 수 있는 수준
**3) 좌표 복구**
- 채팅 기록 덕분에 과거 설계 의도 재발견
- 7개 문서로 현재 상태 명확히 정리
- git commit + 문서 업데이트 습관화 결심
---
## 💬 이 과정에서 배운 AI 활용 팁
### ✅ 효과적이었던 것
**1. 한 방에 완벽 기대 말고, 계속 push하세요**
처음부터 완벽한 답을 기대하지 마세요. v2에서 여러 번 실패했지만, 매번 "이 부분이 마음에 안 들어"라고 구체적으로 피드백하니 v3에서 만족스러운 결과가 나왔습니다.
AI 협업은 "한 방"이 아니라 **"반복 개선"** 프로세스입니다. 불만족스러운 결과에도 포기하지 말고 계속 push하세요.
**2. 막힐 땐 backward로 접근하세요**
Forward(처음→끝) 방식으로 안 풀릴 때, **Backward(끝→처음)** 로 뒤집어보세요.
"데이터 수집부터 어떻게 하지?" → 막힘
"최종 화면에 뭐가 필요하지?" → 역으로 추적 → 해결
복잡한 시스템일수록 결과물부터 거슬러 올라가는 게 직관적입니다.
**3. 문서 업데이트 + git commit으로 좌표 유지하세요**
비개발자라 노트에 적으면서 이해하려 했는데, 개발 문서 버전관리가 안 돼서 좌표를 잃었습니다.
다행히 Claude 채팅 기록이 **복구 포인트(세이브 파일)** 역할을 해줬습니다. 과거 대화를 보며 "아, 이때 이렇게 설계했었지!" 하고 재구성할 수 있었습니다.
앞으로는:
- 주요 설계 문서 업데이트할 때마다 **git commit**
- 커밋 메시지에 "왜 이렇게 바꿨는지" 한 줄 남기기
- Claude 채팅 기록도 중요한 문서로 취급
## 🚀 앞으로의 계획
**1단계: UI 핵심 화면 완성**
- 최종 사용자가 보는 대시보드, 리포트 화면 구체화
- 이미 만든 UI-SCREENS-v3.md 기반으로 목업 제작
**2단계: Flutter 마이그레이션 실행**
**3단계: AI 구현 가이드 활용**
- DESIGN-PROMPTS-v3.md를 따라 단계별 구현
- 막히는 부분은 Claude에게 바로바로 질문
- 각 단계마다 git commit으로 좌표 유지
**작성일**: 2026-01-18
**프로젝트**: BehaviorLab (투자행동연구소)
**도구**: Claude Code (Sonnet 4.5)
**결과**: 7개 설계 문서 (149KB), Flutter 마이그레이션 로드맵, 최종 UI 대시보드화면
행동실험실- 스크린샷
