[Capstone-Start] README "What's Next" 섹션 설계 — 그로쓰 단계 로드맵 정리
📅 일시: 2026. 05. 31
💬 내용: 캡스톤 스타트 단계 마무리에 맞춰, 다음 학기 그로쓰 단계 로드맵을 README “What’s Next” 섹션으로 정리한 작업 회고 (PR #32)
캡스톤 시연 환경이 안정화되고 README 다이어그램까지 SVG로 정리하고 나니, 마지막 한 가지가 남았습니다. 이 프로젝트가 끝이 아니라 출발선이라는 점을 README 어딘가에 명시해야 한다는 것입니다. 캡스톤은 “스타트(Start)”와 “그로쓰(Growth)” 두 학기로 나뉘는데, 평가자와 외부 독자가 README를 봤을 때 “지금 어디까지 왔고, 다음 학기에 어디로 갈 것인가”를 한눈에 잡을 수 있어야 한다는 판단이 들었습니다.
그래서 오늘 PR #32로 README 끝쪽에 “What’s Next” 섹션을 추가했습니다. 코드 변경은 12줄짜리 마크다운 한 덩어리지만, 그 12줄에 어떤 미래를 담을지 결정하는 과정이 이번 작업의 본질이었습니다. 오늘은 그 사고 과정을 정리합니다.
검색해서 들어오신 분께는 캡스톤·졸업 프로젝트의 README에 향후 로드맵 섹션을 어떻게 설계할지에 대한 한 케이스 스터디로 도움이 될 것 같습니다.
1. 왜 “What’s Next” 섹션이 필요한가요
캡스톤은 단순히 만든 결과물을 평가받는 자리가 아니라, “이 아이디어가 한 학기 더 발전할 가치가 있는가” 를 동시에 평가받는 자리입니다. 만든 것만 적힌 README는 “결과물 기록”이지 “다음 학기 제안서”의 역할을 못합니다.
저희 팀은 README의 정보 구조를 다음 흐름으로 가져가고 있습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Hero (한 줄 가치 제안)
↓
Why On-Care (시장의 마찰점)
↓
Problem (5개 페인 포인트)
↓
Solution (4가지 기술적 해법)
↓
Key Features (기능 표)
↓
Vision AI Pipeline (다이어그램)
↓
RAG Pipeline (다이어그램)
↓
System Architecture (다이어그램)
↓
What's Next ← ★ 오늘 추가
↓
Team
위에서부터 “왜 → 무엇을 → 어떻게 → 어디로”의 자연스러운 내러티브가 흐르도록 배치했고, 마지막 두 번째 자리에 What’s Next가 들어가는 게 가장 합리적이라는 판단이었습니다.
2. 3가지 그로쓰 방향 — 어떻게 좁혔는가
다음 학기에 손댈 수 있는 방향은 사실 수십 가지입니다. 알림 정교화, 인증 정식 도입, AI 코치 응답을 진짜 API로 연결, 카메라 권한·촬영 실구현, 사용자 인터뷰 정량 분석 등. 그러나 README의 What’s Next는 모든 To-Do의 목록이 아니라 “이 프로젝트의 다음 한 학기를 결정하는 방향성”이어야 한다고 봤습니다.
그래서 다음 두 가지 기준으로 후보를 좁혔습니다.
- 차별화에 직접 기여하는가 — 단순 기능 추가가 아니라, 기존 시장 헬스케어 앱과의 격차를 만드는 방향인가.
- 한 학기 안에 의미 있는 진척이 가능한가 — 너무 야심 차면 그로쓰 단계 종료 시점에 시연할 게 없습니다.
이 기준으로 3가지가 살아남았습니다.
(A) CGM·웨어러블 연동 — 수동 입력 마찰 완전 제거
캡스톤 스타트 단계의 MVP는 사진 1장으로 식단 기록까지 자동화했지만, 혈당·혈압·체중 같은 생체 신호는 여전히 수동 입력입니다. 이 부분이 그로쓰 단계의 가장 큰 후보였습니다.
| 항목 | 내용 |
|---|---|
| 연동 대상 | CGM(연속혈당측정기) API, Galaxy Watch / Apple Watch SDK |
| 핵심 기대 효과 | 식후 혈당 스파이크·급격한 혈압 상승을 실시간 감지하여 즉각적인 AI 위험 경고 트리거 |
| 차별화 포인트 | 기존 헬스케어 앱은 “기록 도구”에 머무는데, 실시간 감지는 “경고 시스템”의 영역입니다 |
CGM은 당뇨 위험군의 행동 변화를 만드는 데 가장 직접적인 신호입니다. “오늘 점심 후 혈당이 평소보다 30 높습니다”라는 알림이 와야 사용자가 “왜?”를 묻게 되고, 그제서야 식단 기록이 의미를 갖습니다.
(B) 3D Depth·LiDAR 기반 식단 인식 고도화
현재 Vision AI 파이프라인은 YOLOv8 → Gemini Vision API로 음식을 인식하고 공공데이터 식품영양성분 DB에 매핑하지만, 음식의 “양(부피)”을 추정하는 부분이 가장 큰 오차원입니다. 같은 비빔밥이라도 1인분 350g과 1.5인분 525g의 칼로리 차이는 50% 가까이 나는데, 2D 이미지만으로는 정확히 추정하기 어렵습니다.
| 항목 | 내용 |
|---|---|
| 기술 후보 | 스마트폰의 LiDAR 센서(iPhone Pro 모델) 또는 Depth 정보(ARKit/ARCore) |
| 모델 방향 | 음식의 3차원 부피(Volume)를 정밀 추정하는 모델 도입 |
| 기대 효과 | 칼로리·성분 오차 범위 5% 이내로 축소 |
이 방향은 학술적으로도 의미가 있어 보였습니다. 헬스케어 도메인의 컴퓨터 비전 연구로도 충분히 발표 가치가 있고, 정량적 평가가 가능합니다(오차율).
(C) 쌍방향 O2O 피드백 루프 — 트레이너 전용 웹 대시보드
스타트 단계에서는 사용자 → 트레이너로 가는 단방향 데이터 전송(건강 요약본 → 트레이너 채팅)만 구현했습니다. 그런데 헬스케어의 진짜 가치는 트레이너의 운동 처방이 다시 사용자의 AI 코치에 영향을 미치는 양방향 루프에서 나옵니다.
| 항목 | 내용 |
|---|---|
| 산출물 | 트레이너 전용 웹 대시보드 신규 구축 |
| 데이터 흐름 | 트레이너 처방 운동 루틴 → 유저의 AI 맞춤 운동 코칭 엔진에 즉시 동적 반영 |
| 기대 효과 | 온·오프라인 하이브리드 헬스케어 생태계 완성 |
PMF 학습 노트(4/25 글)에서 다뤘던 “전체 제품(Whole Product) 개념”과 직접 연결됩니다. 앱만으로 끝나지 않고, 트레이너 워크플로우까지 묶어야 사용자가 “이 서비스 없으면 안 될 것 같다”는 단계로 진입할 수 있습니다.
3. 마크다운 설계 — 3가지 결정
기능 방향이 정해졌으니 이제 마크다운으로 옮기는 단계입니다. 12줄짜리 변경이지만 다음 세 가지 결정을 거쳤습니다.
결정 1. 헤딩 컨벤션 — ## What's Next
README의 다른 h2 헤딩들(## Why On-Care, ## Solution, ## Team)이 모두 영문 + 이모지 없음 패턴을 따르고 있어, 동일하게 맞췄습니다.
1
## What's Next
내부 한국어 콘텐츠와 영문 헤딩의 혼합이 어색하지 않냐는 의견도 있었지만, 영문 헤딩이 외부 GitHub 트래픽(영어권 방문자 / 추후 OSS 후속 기여자)을 고려한 결정이라 일관성을 우선했습니다.
결정 2. 표 구조 — 2컬럼 vs 3컬럼
처음 영문 원안은 2컬럼(방향 | 설명)이었습니다. 그런데 본문에 옮기면서, 각 방향의 “기대 효과”를 별도 컬럼으로 빼는 게 가독성에 더 좋다는 결론에 도달했습니다. |
1
2
3
4
5
| 방향 | 설명 | 기대효과 |
|------|------|----------|
| **연속혈당측정기 및 웨어러블 연동** | CGM API 및 스마트워치 SDK 연동 | 식후 혈당 스파이크 실시간 감지 ... |
| **3D Depth 기술 기반 식단 인식 고도화** | LiDAR/Depth 활용 3차원 부피 추정 | 칼로리 오차 5% 이내로 축소 |
| **쌍방향 O2O 피드백 루프 및 가상 트레이닝** | 트레이너 전용 웹 대시보드 ... | 온·오프라인 하이브리드 생태계 완성 |
3컬럼 구조는 README의 다른 표(## Solution, ## Key Features)와 시각적 리듬을 맞추기 위함이기도 합니다. 표가 일관되면 페이지를 스크롤하면서 받는 정보 구조의 인상이 더 깔끔합니다.
결정 3. 마무리 한 줄 — blockquote로 비전 응축
3가지 방향을 표로 나열한 다음, 세 방향이 합쳐졌을 때의 한 문장 비전을 blockquote로 강조했습니다.
1
2
> 웨어러블 연동, 3D 식단 인식, 트레이너 연계를 통해 실시간 건강 예측과
> 개인 맞춤 코칭이 가능한 통합 헬스케어 생태계를 구축하는 것을 목표로 합니다.
이 한 줄이 평가자가 What’s Next 섹션을 읽고 머릿속에 남길 한 문장입니다. 표가 “무엇을(What)”이라면, blockquote는 “왜(Why)”이자 “어디로(Where)” 입니다. 표만 두면 To-Do 목록처럼 읽히고, blockquote가 있어야 비로소 비전이 됩니다.
4. 작성 과정에서 했던 작은 실수와 교정
PR을 올리면서 한 번 다시 살펴본 부분도 있었습니다.
- 첫 초안에서는 6개 항목(영문 원안)을 모두 옮겼습니다. 그런데 README에서 6개 표는 정보 밀도가 너무 높아져서, 상위 3개로 압축했습니다. 나머지 3개는 보고서 본문에 남깁니다. README는 “처음 만나는 사람을 위한 자료”라는 원칙을 지켰습니다.
- 처음에는 표 헤더를
방향 | 설명(2컬럼)으로 두었다가, 위에서 적은 이유로방향 | 설명 | 기대효과(3컬럼)으로 늘렸습니다. PR description의 “2컬럼” 언급은 초안 시점 기록이라 그대로 두었습니다. - 헤딩 이모지는 처음에
## 🚀 What's Next로 박았다가, 다른 h2 헤딩과 일관성을 위해 이모지를 제거했습니다.
5. 회고 — 12줄 마크다운이 가르쳐 준 것
이번 PR의 코드 변경은 12줄이지만, 그 12줄을 결정하는 데 약 2시간이 들었습니다. 학기 마지막에 와서 새삼 느낀 것은 다음 세 가지입니다.
- README는 코드의 부산물이 아니라 프로젝트의 entry point입니다. 평가자·OSS 방문자·다음 학기의 본인이 가장 먼저 읽는 자료라, 코드 한 줄보다 신중하게 결정해야 합니다.
- 로드맵은 To-Do 목록과 다릅니다. To-Do는 모두 적으면 되지만, 로드맵은 무엇을 뺄지가 더 중요합니다. 3개로 압축한 결정이 6개 다 적는 것보다 어려웠습니다.
- “기대 효과” 컬럼이 있어야 표가 의미를 갖습니다. 무엇을 할지(What)와 왜 그게 중요한지(Why Impact)는 분리해서 적어야 평가자가 한 줄씩 끊어 읽을 수 있습니다.
이번 학기 캡스톤 스타트는 여기서 마무리되고, 다음 학기 그로쓰 단계에서는 위 3가지 방향 중 우선 (A) 웨어러블 연동에 집중할 가능성이 높습니다. 가장 빠르게 실시연 가능한 차별점이라는 판단입니다. CGM API 연동 가능성, Galaxy Watch SDK 학습, 알림 채널 설계 등이 다음 학기 초반의 학습 노트가 될 것 같습니다.
📌 요약
PR #32로 캡스톤 README에 “What’s Next” 섹션을 추가하면서, 그로쓰 단계 로드맵을 3가지 방향(CGM·웨어러블 연동 / 3D Depth·LiDAR 식단 인식 / 쌍방향 O2O 피드백 루프)으로 압축·구조화한 과정을 정리했습니다. 12줄짜리 마크다운 PR이지만 무엇을 뺄지·헤딩 컨벤션·표 컬럼 수·마무리 비전 문장 등 작은 결정 4개가 들어갔습니다. README의 로드맵 섹션은 To-Do 목록이 아니라 “다음 한 학기의 방향성”을 담는 자리라는 원칙으로, 6개 후보를 3개로 압축하고 마지막 blockquote로 통합 비전을 응축했습니다. 캡스톤·졸업 프로젝트 README에 향후 로드맵을 박을 때 참고가 되기를 바랍니다.