[Capstone-Start] 스타트 단계 마무리 - 전체 정리/회고
📅 기간: 2026. 06. 22 (2026. 03. 12 – 06. 22)
💬 내용: 캡스톤 스타트 단계 전체 정리
캡스톤 스타트 단계가 끝났다. 3월 중순에 아이디어를 정한 것부터 6월 중순 공모전 신청까지 약 3개월이 걸렸다. 이 글은 그 3개월을 한 번에 묶어서 보는 정리/회고하는 글이다.
1. 스타트 단계가 뭐였나
졸업프로젝트는 스타트와 그로쓰 두 단계로 나뉜다. 스타트는 첫 학기에 하는 단계이고, 완성된 제품을 내는 게 목표가 아니다. 아이디어를 정하고, 기획을 구체화하고, MVP 수준까지 만들어 보는 데까지가 범위다. 실제 개발과 완성은 다음 학기 그로쓰에서 한다.
그래서 스타트의 결과물은 “동작하는 완성품”이 아니라 “방향이 정해진 기획 + 돌아가는 MVP + 다음 단계 계획” 세 가지다.
2. 한 일 정리
크게 다섯 묶음으로 나눌 수 있다.
① 기획 (3월 ~ 5월 초)
- 아이디어 선정
- 프로젝트 소개 페이지 제작·배포
- PMF, Elevator Speech 정리
- 시나리오 1차 초안 → 확정
- Figma 프로토타입
② 학습 (5월 중순)
- Dart 문법 학습 시리즈 - 타입/Null Safety, async·Stream, 함수·클로저, Generics·Sealed, Records·Patterns, Extension·Mixin
- 프론트엔드를 Flutter로 바꾸기로 하면서 Dart를 처음부터 봤다.
③ 개발 (5월 중순 ~ 말)
- Flutter 부트스트랩, 코어 인프라, 디자인 시스템
- MVP 첫 커밋 (8화면)
- UI 리스타일, GitHub Pages 배포, 설정 모달
- 식단 사진 분석은 4월에 Gemini API로 먼저 만들어 둠
④ 점검·정리 (5월 말 ~ 6월 초)
- 시나리오 확정 (셀프 데모 가이드)
- README 다이어그램 SVG화, What’s Next 로드맵
- 지도교수 면담 안건·피드백
⑤ 마무리 (6월 중순)
- 공모전 지원 (10개 검토 → 7개)
- 팀·개인 포스트모템 작성
스타트 단계 글이 스물다섯 편 넘게 쌓였는데, 절반 가까이가 개발이 아니라 기획과 학습이었다. 매번 글로 남겨 둔 덕에 이 회고도 다시 찾을 필요 없이 정리할 수 있었다. 날짜순으로 펴면 이렇다.
| 날짜 | 글 | 분류 |
|---|---|---|
| 03-12 | 아이디어 선정 | 기획 |
| 03-23 | 소개 페이지 제작·배포 | 기획 |
| 04-12 | Gemini API 연동·식단 분석 | 개발 |
| 04-25 | PMF | 기획 |
| 05-07 | Elevator Speech | 기획 |
| 05-12 | 시나리오 1차(v1) | 기획 |
| 05-14 | Figma 프로토타입 | 기획 |
| 05-15 | Dart: 타입·Null Safety | 학습 |
| 05-16 | Dart: Future·async·Stream | 학습 |
| 05-17 | Flutter 마이그레이션 계획 | 개발 |
| 05-18 | Dart: 함수·클로저 | 학습 |
| 05-19 | Flutter 부트스트랩 | 개발 |
| 05-20 | Flutter 코어 인프라 | 개발 |
| 05-21 | Dart: Generics·Sealed·freezed | 학습 |
| 05-22 | Flutter 디자인 시스템 | 개발 |
| 05-23 | Flutter MVP Day | 개발 |
| 05-24 | UI 리스타일·README 다이어그램 | 개발 |
| 05-25 | GitHub Pages 배포·설정 모달 | 개발 |
| 05-26 | Dart: Records·Patterns | 학습 |
| 05-27 | Dart: Extension·Mixin·Codegen | 학습 |
| 05-29 | 시나리오 확정(Self-Demo) | 점검 |
| 05-31 | fireworks-tech-graph 다이어그램 | 점검 |
| 05-31 | What’s Next 로드맵 | 점검 |
| 06-01 | 교수 면담 안건 | 점검 |
| 06-05 | 교수 면담 피드백 | 점검 |
| 06-21 | 공모전 지원 | 마무리 |
| 06-22 | 스타트 마무리 (이 글) | 마무리 |
전체 목록은 카테고리 페이지에서도 볼 수 있다.
3. 기술 스택 정리
스타트 단계에서 정하거나 실제로 쓴 기술을 묶으면 이렇다. 깊이 들어갔다기보다 “무엇을 골랐나” 수준이다.
- 프론트엔드 - Flutter / Dart. 상태관리 Riverpod, 라우팅 go_router(StatefulShellRoute), 로컬 DB drift, 불변 모델 freezed, 차트 fl_chart.
- AI - 식단 사진 분석 Gemini Vision API, 객체 탐지 YOLOv8. 코치용 RAG는 임베딩·벡터 검색(Pinecone)·LLM으로 구조만 설계했고, 실운영·파인튜닝은 그로쓰에서 한다.
- 백엔드·데이터 - Spring Boot REST API는 기초·설계 수준. 백엔드가 붙기 전이라 프론트 단독 구동용 LocalApiInterceptor + drift를 쓰고, API_CATALOG.md로 스키마를 미리 맞춰 뒀다.
- 협업·인프라 - GitHub Flow(Issue·PR·리뷰·라벨), GitHub Actions CI/CD(format·analyze·test), GitHub Pages 배포, 테스트는 golden_toolkit 시각 회귀 + 위젯·모델·통합(커버리지 63%).
4. 잘된 점
포스트모템에서 팀이 공통으로 꼽은 잘된 점은 대략 이렇다.
- 방향을 초기에 정하고 학기 내내 유지했다. “단순 식단 기록”이 아니라 “AI 기반 만성질환 관리”라는 정체성을 초반에 확정했고, PMF·페르소나(김민수)·시나리오·경쟁 분석을 개발 전에 해 둬서 중간에 주제가 흔들리지 않았다. 캡스톤에서 제일 흔한 실패가 “방향이 자꾸 바뀌어 아무것도 못 끝내는 것”인데 그건 피했다.
- 기능을 늘리지 않고 MVP 중심으로 완주했다. 헬스케어는 욕심내면 끝이 없어서, “할 수 있는 것”과 “하고 싶은 것”을 팀 차원에서 계속 구분했다.
- 단계를 나눠서 개발했다. 디자인 시스템 → 8화면 MVP → 통합·폴리시 → 품질(테스트) → 릴리즈 → UX 정렬 순으로, 각 단계 종료 조건을 정하고 커밋·PR을 쌓았다. 그래서 “지금 어디까지 됐는지”가 항상 보였다.
- 백엔드가 없는 상태를 설계로 우회했다. 네트워크 인터셉터(LocalApiInterceptor) + 로컬 DB(drift)로 프론트만으로 실제 API가 붙은 것처럼 동작하게 만들었고, API_CATALOG.md로 백엔드와 주고받을 스키마를 미리 합의해 뒀다.
- GitHub로 실제 협업을 했다. 파일 공유가 아니라 Issue / PR / 리뷰 / 라벨을 쓰고 모든 변경을 PR·리뷰로 머지했다. 개인 프로젝트에서는 못 해 보는 부분이다.
- 한이음 드림업 멘토링으로 외부 피드백을 받았다. 학생 시야만으로 판단하기 어려운 부분을 외부 멘토 관점에서 점검받았다.
5. 아쉬운 점, 그로쓰에서 보완할 것
반대로 아쉬운 점도 분명했다.
- 실사용자 검증·데이터가 부족했다. AI 개인화를 내세웠는데 실제 사용자 데이터를 모으지 못해서 “정말 효과가 있는가”를 수치로 입증하긴 어려웠다. 추천·코칭 품질은 결국 쌓인 데이터에서 나오는데 한 학기로는 못 채웠다.
- AI 핵심 기능이 조사·설계·프로토타입에 머물렀다. 차별점인 Vision AI 식단 인식과 RAG 코치가 구조 설계까지는 갔지만 실제 운영 수준까진 못 갔다. “흥미로운 기술”과 “한 학기 안에 되는 것” 사이의 균형이 중요하다는 걸 확인했다.
- 테스트·접근성이 밀렸다. 개발에 집중하느라 테스트 커버리지가 목표(70%+) 대비 63%에 머물렀고, 만성질환 사용자(중장년 비중)를 생각하면 글자 크기·고대비 같은 접근성을 초기 설계에 더 일찍 반영했어야 했다.
- 일정이 특정 시점에 몰렸다. 시험·다른 과제와 겹치면서 분산 관리에 실패한 구간이 있었다.
그로쓰에서 보완할 방향은 면담·포스트모템에서 이렇게 정리했다 - 베타 테스트·피드백 수집을 일정에 정식으로 넣기, 추천 성능 측정 지표 만들기, AI를 “동작하는 최소 단위”부터 점진적으로 키우기, Must/Nice-to-have를 초반에 문서로 고정하기, 마일스톤·주간 목표로 일정 분산하기.
6. 주제는 적절했나, 바꿀 생각은 없나
적절성 - 한 학기 해 본 결과 주제 선정은 적절했다고 본다. 2030 세대에서도 당뇨·고혈압 위험군이 늘고 있어 현실성·사회적 수요가 분명하고, 헬스케어는 데이터·AI·사용자 행동·지속성까지 같이 봐야 하는 도메인이라 전공 프로젝트로서 학습 밀도도 높았다. 다만 신뢰성·개인정보·규제(IRB)·지속 사용 등 고려 요소가 많아 난이도가 높고, 상용 수준까지 가려면 의료·영양 전문가 협업이 필요하다는 것도 같이 알게 됐다. 그래서 “진단”이 아니라 “생활 코칭”으로 범위를 조정했다.
처음과 지금을 비교하면 범위가 이렇게 바뀌었다.
- 처음: 식단·운동·일정·챗봇을 다 합친 범용 AI 건강 비서
- 지금: 만성질환(고혈압·당뇨) 관리에 초점을 맞춘 On-Care
마지막 면담에서도 “기술보다 차별점”이라는 피드백을 받았고, 범위를 좁히니 RAG에 넣을 문서(진료지침·논문), 식단에서 볼 지표(염분·당) 같은 게 더 분명해졌다.
주제 변경 여부 - 그로쓰에 가면서 주제를 바꿀 계획은 없다. 지금까지 만든 On-Care를 더 고도화한다. 새 주제를 새로 잡기보다, 이미 차별점이 어느 정도 검증된 현재 걸 키우는 게 낫다고 판단했다.
7. 공모전 지원
스타트 마무리 즈음, On-Care로 나갈 수 있는 공모전을 모아서 검토했다. 지원 가능한 게 10개였고 그중 7개에 냈다. 어떤 걸 왜 냈고 왜 안 냈는지는 따로 정리했다 → 공모전 지원 글.
8. 다음 단계 (그로쓰)
방학 동안 미리 작업해 두고, 2학기에 그로쓰 단계를 진행한다. 우선순위는 다음과 같다.
- AI 피드백 프롬프트 분리 (식단 / 운동 따로 호출 후 UI에서 합치기)
- RAG 문서 소스 결정 (고혈압·당뇨 진료지침 + 최근 논문)
- YOLOv8 → Gemini Vision 2-stage 비교 실험 (비용·정확도·속도)
- YOLOv8 한국 음식 파인튜닝
- 트레이너 연계 기능
단계별 후속 조치는 What’s Next 로드맵과 6/5 면담 글에 정리해 뒀다.
9. 스타트 단계를 닫으며
스타트 단계는 여기서 마무리한다. 단계가 끝난 시점의 결과물은 이렇다.
- MVP - 8화면 규모의 Flutter 앱. GitHub Pages에 배포해 링크로 바로 볼 수 있다.
- 확정 시나리오·셀프 데모 가이드 - 시연 흐름이 고정돼 있다.
- 기획 문서 세트 - PMF, 페르소나(김민수), 경쟁 분석, 시나리오, README 다이어그램.
- 협업 인프라 - GitHub flow(Issue·PR·리뷰·라벨), CI/CD, API_CATALOG로 합의한 백엔드 스키마.
- 공모전 7건 접수 - On-Care를 외부에 처음 내본 사례.
숫자로 보면
| 항목 | 값 |
|---|---|
| 기간 | 3개월 (3/12 – 6/22) |
| 개발일지 | 25편 (+ 공모전·마무리 2편) |
| MVP 화면 | 8개 |
| 테스트 커버리지 | 63% (목표 70%+) |
| 공모전 | 10개 검토 / 7개 지원 |
스타트의 목표였던 “방향 + 돌아가는 MVP + 다음 단계 계획” 세 가지는 만들어졌고, 그래서 이 단계는 여기서 닫는다. 완성품은 아니고, 완성은 그로쓰의 몫이다. 이어지는 작업은 방학 선행 개발부터 시작한다.
다음 글부터는 카테고리가 Capstone-Start에서 Capstone-Growth로 넘어간다.
📌 요약
3개월 동안 아이디어 선정부터 MVP·배포, 교수 면담, 공모전 지원까지 진행했다. 잘된 점은 방향을 초기에 고정하고 MVP 중심으로 완주한 것, 단계형 개발과 GitHub 협업을 한 것이고, 아쉬운 점은 실사용자 검증·AI 핵심 기능·테스트가 한 학기 안에 충분히 안 됐다는 것이다. 주제(만성질환 특화 On-Care)는 적절했다고 보고 그로쓰에서도 바꾸지 않는다. 공모전은 10개를 검토해 7개에 냈다. 다음은 방학 선행 개발로 이어진다.