Post

[Capstone-Start] README "What's Next" 섹션 설계 — 그로쓰 단계 로드맵 정리

[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의 목록이 아니라 “이 프로젝트의 다음 한 학기를 결정하는 방향성”이어야 한다고 봤습니다.

그래서 다음 두 가지 기준으로 후보를 좁혔습니다.

  1. 차별화에 직접 기여하는가 — 단순 기능 추가가 아니라, 기존 시장 헬스케어 앱과의 격차를 만드는 방향인가.
  2. 한 학기 안에 의미 있는 진척이 가능한가 — 너무 야심 차면 그로쓰 단계 종료 시점에 시연할 게 없습니다.

이 기준으로 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시간이 들었습니다. 학기 마지막에 와서 새삼 느낀 것은 다음 세 가지입니다.

  1. README는 코드의 부산물이 아니라 프로젝트의 entry point입니다. 평가자·OSS 방문자·다음 학기의 본인이 가장 먼저 읽는 자료라, 코드 한 줄보다 신중하게 결정해야 합니다.
  2. 로드맵은 To-Do 목록과 다릅니다. To-Do는 모두 적으면 되지만, 로드맵은 무엇을 뺄지가 더 중요합니다. 3개로 압축한 결정이 6개 다 적는 것보다 어려웠습니다.
  3. “기대 효과” 컬럼이 있어야 표가 의미를 갖습니다. 무엇을 할지(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에 향후 로드맵을 박을 때 참고가 되기를 바랍니다.

This post is licensed under CC BY 4.0 by the author.