배경
BehaviorLab은 개인 투자자의 투자거래 데이터를 분석해서 "당신의 투자 습관"을 보여주는 코칭 플랫폼이다. 오천피, 천스닥이라고는 하지만 손실비율은 70-80%, 과매매 회전율은 3-5배씩이나 된다. 손절타이밍을 놓쳐 손실이 확대되고 FOMO 추격매수를 하는 안타까운 지인들이 넘 많다. 25년 이상 여의도에서 애널리스트, 펀드매니저, 컴플라이언스, 투자솔루션 전문가로 일했지만, 나 자신도 23년 2차전지 폭등과 폭락장에서 FOMO와 패닉셀로 며칠 사이에 수천만원을 날려버린 고통스러운 경험이 있었다.
핵심문제는, '종목선택'이 아닌 '규율 없는 투자행동편향과 습관'이라고 난 가설을 세웠다. 기존 시장은 더 많은 정보와 매수, 매도 트레이딩을 하라는 경쟁에 몰두하지만, 손절을 제때 못하고, 이익 나자마자 팔고, 손실은 오래 가져가는 행동, 패닉셀, FOMO, 레버리지가 문제라고 진단했다.
Behavior Lab의 솔루션은 '감정을 데이타로, 충동을 이기는 습관'으로 전환하는 것이다. 개인도 전문가적인 위험분석관리툴을 써야하는 시대라는 것이 Behavior Lab의 서비스 기회이다.
MVP 구현도 중요하지만 진짜 중요한 것은 검증
"아이디어 → 가설 → 구현 → 실제 데이터로 검증"이 가능해졌다. 상상이 아니라 유저로부터 검증이 가능해졌다. 중요한 것은 구현하고, 그리고 더 중요한 것은 검증받는 경험이다. 내가 생각하는 문제의 정의가 진짜 바른 가설인지, 또. 진짜 문제를 해결할 수 있는지. 그게 진짜 경쟁력이다.
진짜 필요한 경험은 사용자 인터뷰, 문제 정의, 데이타 기반의 판단, 개선 사이클 경험, A/B 테스트 실제, 사용자 확보이다.
MVP 진행 방법
이걸 검증하려면 실제로 작동하는 무언가가 필요하다는 것이었다. 수많은 거래로그와 포지션의 실제 데이타를 넣고 market regime의 환경요소도 고려하는 맥락있는 추론을 해야만, 투자행동의 패턴 데이타를 제대로 분석하고 이해할 수 있다. 개발자 외주? 최소 2-3개월에 수천만원, 그리고 그 사이에 틀린 가설이나 로직들이 나온다면? 직접 만들어야했다. AI와 함께.
워크플로우 5가지 원칙
7일 만에 MVP를 완성할 수 있었던 건 AI가 똑똑해서가 아니다. AI와 일하는 방식을 정립했기 때문이다. 초보자이지만 중요한 스킬과 습관을 get했다.
#원칙 1: Single Source of Truth - GitHub Issues가 유일한 진실
정보의 출처가 하나여야 한다 . GitHub Issues. md에 모든 to do list 할 일을 적었다. 누가 해주나? AI가. Plan Agent가 Issue를 척척 설계해주었다
인증 시스템을 만들어야 했다. 나는
#4번 Issue 구현 계획 세워줘. 이메일+비밀번호 인증이야.이메일과 비밀번호로 로그인"이라고만 생각했다.
AI가 돌아온 답:
인증 시스템 구현 계획입니다:
>
> 1. 모델 설계: User 테이블에 email, password_digest 컬럼
> 2. 회원가입: 이메일 중복 검사, 비밀번호 해싱
> 3. 로그인: 세션 기반 인증, 쿠키 보안 설정
> 4. 로그아웃: 세션 무효화
> 5. 인증 미들웨어: 보호된 페이지 접근 제어
> 6. 테스트: 7개 케이스 (회원가입 성공/실패, 로그인 성공/실패, ...)
>
> 완료 조건(DoD):
> - 모든 테스트 통과
> - 비밀번호 평문 저장 금지 확인
> - 세션 쿠키 httpOnly 설정 확인#원칙 2. Github Project: 36개 이슈를 어떻게 관리했나, 프로젝트 관리비법
AI와 대화하면서 계획을 세우다 보니, Issue가 계속 늘어났다. 최종적으로 36개 Issue가 됐다. 각 Issue 안에는 세부 to do 체크리스트까지.
#1 프로젝트 초기 설정
#2 로컬 개발 환경 구성
#3 DB 스키마 설계
#4 인증 API 구현
#5 CSV Import 기능
#6 BI 계산 엔진 - LCA
#7 BI 계산 엔진 - TSI
#8 BI 계산 엔진 - RRR
...
#33 보안 요구사항 구현
```세부 To-Do 체크리스트
각 Issue 안에는 세부 작업이 체크리스트로 들어있다:
```
#4 인증 API 구현
├─ [ ] User 모델 생성
├─ [ ] 회원가입 엔드포인트
├─ [ ] 로그인 엔드포인트
├─ [ ] 로그아웃 엔드포인트
├─ [ ] 세션 관리 미들웨어
├─ [ ] 테스트 7개 작성
└─ [ ] 문서 업데이트kanban 보드로 진도 관리로 프로젝트의 뼈대구축하기를 했다
GitHub Projects 보드를 이렇게 구성했다:
```
┌─────────────┬─────────────┬─────────────┐
│ To Do │ In Progress │ Done │
├─────────────┼─────────────┼─────────────┤
│ #28 리포트 │ #27 대시보드│ ✅ #1 초기설정 │
│ #29 알림 │ │ ✅ #2 환경구성 │
│ #30 설정 │ │ ✅ #3 DB스키마 │
│ ... │ │ ✅ #4 인증API │
│ │ │ ✅ ... │
└─────────────┴─────────────┴─────────────┘
진도율: 24/36 (67%)매일 아침 이 보드를 열어서 "오늘은 뭘 In Progress로 옮길까?"를 결정했다. AI에게도 항상 Issue 번호를 먼저 알려줬다. #이슈와 to do check 이걸 하나씩 체크하면서 진행하니까:
- "지금 어디까지 했지?" → 체크리스트만 보면 됨
- "다음에 뭘 해야 하지?" → 다음 미체크 항목
- "진짜 끝난 건가?" → 전부 체크 + 테스트 통과 = 끝
#원칙 3: Commit = 완료
작업 끝났어? → 커밋했어? → 안 했으면 끝난 게 아냐
초반에는 "AI가 코드 만들어줬으니 끝!"이라고 생각했다. 하지만 다음 날 돌아오면 "어제 뭘 했더라?"를 AI에게 물어봐야 했다. AI는 이전 대화를 기억하지 못한다.
해결책: 커밋 메시지가 곧 작업 기록이다.
feat(bi): LCA 손절회피 계산 엔진 구현 — Closes #8이렇게 하면:
- 다음 날 커밋 로그만 보면 어제 뭘 했는지 안다
- GitHub이 자동으로 Issue를 닫아준다
- 별도의 "Work Log"를 쓰는 이중 작업이 사라진다
#원칙 4: 병렬 브랜치 전략
서로 안 겹치는 작업? → 브랜치 나눠서 동시에 진행 → 나중에 합치기
처음에는 모든 작업을 순서대로 했다. "A 끝나면 B, B 끝나면 C." 하지만 AI에게 물어보니 "A와 C는 독립적이라 동시에 해도 됩니다"라고 했다.
예를 들어:
* 6c3fadd Merge branch 'feat/kis-api-import' into feat/core-models
|\
| * 9b1103c feat(import): KIS API Import show 뷰 + 테스트 완성
* | be1f7ad fix(import): Orphan Sell nil guard 수정 + 테스트 6개
|/
* e4ec090 feat(import): KIS API 연동 + Orphan Sell 감지
#원칙 5: /clear 습관으로 다음작업은 깨끗하게 시작
커밋했어? → /clear → 새로운 대화 시작
솔직히 힘들었던 것: 테스트의 압박
#1. "테스트 통과해야 다음 단계"의 고통
워크플로우에서 가장 힘들었던 건 "테스트 전부 통과해야 커밋" 규칙이었다.
코드 작성 완료! → 테스트 실행 → 3개 실패 😱
→ 수정 → 테스트 실행 → 1개 실패 😭
→ 수정 → 테스트 실행 → 전부 통과 ✅
→ 이제야 커밋 가능
이 사이클이 하루에 수십 번 반복됐다. 솔직히 "그냥 커밋하고 나중에 고치면 안 되나?" 하는 유혹이 매번 왔다. 테스트를 미뤄서 아낀 30분 때문에 버그로 반나절을 날릴 수 있어서 무조건 테스트 통과 후 커밋. 아무리 힘들어도. 다행히 AI가 테스트 작성을 많이 도와줬다:
LCA 계산 로직 구현했으니까 테스트도 만들어줘.
경계값(0, 0.5, 1)이랑 예외 케이스 포함해서.AI가 테스트 케이스를 제안하면, 내가 검토하고 실행한다. 테스트 "작성"은 AI가, 테스트 "통과 확인"은 내가. 이 분업 덕분에 테스트 지옥에서 살아남았다.
#2. 보 안이 뚫려서 정보가 노출되면? 막혔던 부분에 5중 보안 레이어를 체계적으로 제안받다
개발 초기에 보안 점검을 하다가 불안해졌다. "혹시 API 키나 중요한 정보가 노출되면 어쩌지?"
이 프로젝트의 보안 리스크를 점검해줘. 특히 키나 민감 정보 노출 가능성.AI의 답이 놀라웠다. 단순히 "이거 조심하세요"가 아니라, 다층 보안 구조를 제안했다:
5중 보안 레이어 제안:
>
> Layer 1 (코드 레벨): 환경변수 사용, 하드코딩 금지
> Layer 2 (Git 레벨): .gitignore로 민감 파일 제외
> Layer 3 (배포 레벨): 프로덕션 키는 서버에서만 관리
> Layer 4 (런타임 레벨): 로그에 민감 정보 필터링
> Layer 5 (모니터링 레벨): 이상 접근 탐지보안을 "규칙"으로 생각했는데, "레이어"로 생각하니까 명확해졌다. 각 레이어가 뚫려도 다음 레이어가 막아준다.
7일의 결과
산출물- Behavior Lab 웹페이지
| 데이터베이스 | 11개 테이블 |
| 계산 엔진 | 5개 BI 지표 (LCA, TSI, RRR, GLA, BCI) |
| 화면 | 대시보드, 온보딩, 로그인 |
| 커밋 | 30개 이상 |
| 테스트 | 전체 통과 |
다음 할일
#phase 1 kamal 배포후 사용자 인터뷰, A/B 테스트
#phase 2 to do list
