[Capstone-Start] 스타트 마지막 지도 교수님 면담 — "기술보다 차별점"
📅 일시: 2026. 06. 05
💬 내용: 캡스톤 스타트 단계 최종 점검 면담 후기
오늘 점심 12시 반, 황의원 교수님 사무실(진선미관 335호)에서 면담을 가졌습니다.
1. 첫 마디 — “기술보다 차별점”
어제(6/4) 그로쓰 단계 팀들 평가에 들어가셨다고 했습니다.
“기술적인 건 사실 대부분 앱 개발하시는 분들이 비슷비슷한 걸 쓰거든요. 항상 이 파이프라인에 RAG 거의 무조건 집어넣고. 요새 졸프 팀들 보면은. 그래서 기술적으로는 뭔가 딱 눈에 띄는 게 없을 수도 있는데, 우리가 하려는 태스크 — 거기에 맞춰서 들어가는 컴포넌트들이 있다는 게 어필이 될 수 있을 것 같다는 생각이 듭니다.”
기술에 초점을 두실 줄 알았는데, 차별점을 더 어필하라는 건 조금 놀랐습니다. 이번 기회로 방향성을 다시 잡게 되어 좋았습니다.
2. 만성질환 특화 — 어떻게 어필할 것인가
“진단으로 가면 개인정보 영역이라 손대기 어렵고, 그래서 생활 코칭 쪽으로 가려고 하는데 어떻게 전문성을 어필하면 좋을까요?” 라고 물었습니다.
“특화가 쉬운 게, 저희가 RAG를 쓰잖아요. 그러면 당연히 전문 지식 문서가 필요할 거고, 그게 일반적인 질환 전체를 타겟으로 하는 게 아니라 고혈압·당뇨 타겟이니까 거기에 맞는 문서를 들고 오면 되거든요. 그것만 모으면 훨씬 더 전문성이 있을 거잖아요. 그 범위 내에서 답을 찾을 거니까.”
문서 소스 선택 가이드도 같이 주셨습니다.
“블로그를 들고 왔다가 전혀 틀린 사실이 들어갈 수도 있잖아요. 우리나라도 그렇고 나라마다 진료 지침이 있어요. 해마다 업데이트되기도 하고. 최근 몇 년 거를 모아서 쓰고, 논문도 몇 개 모아서 썼더니 되게 잘 됐거든요.”
사진 한 장으로 분석되는 흐름이 만성질환 특화 어필의 가장 직관적인 포인트라는 코멘트도 따라왔습니다.
“고혈압은 음식에 들어있는 염분이 중요할 거고, 당뇨도 음식에 들어있는 당이 중요할 거고. 그걸 입력하게 하면 사실 쉽지 않은데, 사용자가 사진부터 자동으로 분석을 해서 관리를 해준다라고 하면, ‘고혈압은 염분, 당뇨는 당 그게 관리가 되는구나, 특화된 게 맞구나’ 라고 생각할 것 같아요.”
3. 교수님이 직접 풀어주신 일화들
질문하기 전에 교수님이 자료를 보시며 자발적으로 풀어주신 일화가 있어 흥미로웠습니다.
스마트워치 자동 기록. 운동 페이지를 보시더니 “운동 기록 앱을 쓰는데 매번 눌러야 되니까 너무 귀찮다” 고 하셨고, 스마트워치 자동 감지 기능도 “지각해서 뛸 때 갑자기 손목 울리니까 너무 거슬려서 그냥 다 꺼놨다” 고 하셨습니다. “조용히 기록하면 좋을 텐데” 가 결론.
포인트 제도. “활동 포인트” 항목을 보시고는 본인 일화로 답을 주셨어요.
“전 앱을 쓰는 이유가 그거거든요. 운동을 며칠 갔다가 쌓이니까. 약간 수집 욕구라 해야 될까요. 한 500회 정도 쌓았는데 지금 계속 쌓이니까 재밌더라고요.”
뉴발란스 앱 사례도 함께. “달리기 하면 포인트를 주고, 그걸로 제품 살 때 할인 받을 수 있어요. 계속 자기네 신발 사게 만드는 시스템이고요.”
한국 음식 YOLOv8. 식단 인식 파이프라인 설명을 들으시고 곧바로 짚으셨어요.
“YOLO로 음식 맞추는 게 이미 있긴 할 거예요. 그런데 카테고리가 엄청 좁아가지고. 진짜 간단한 과일 종류 이런 것만 조금 판별하는 애들밖에 없는 것 같아요. 한국 음식이 다 짜잖아요. 부대찌개 이런 걸 예측을 해야 의미가 있을 것 같다는 생각이 드는데. 튜닝을 해보셔도 될 것 같고, 그것도 사실 기여잖아요.”
식단 웹사이트 즐겨찾기. 교수님이 평소에 쓰는 식단 관리 웹사이트 얘기를 푸셨어요. “현미밥, 닭가슴살 입력하면 100g당 탄수화물·단백질이 자동 계산돼서 들어가요.” 그러면서 비교해 주신 한 줄:
“공공 DB랑 매핑하는 거, 사진만 찍어도 직접 타이핑할 필요 없이 자동으로 다 되면 되게 쓸 만할 것 같다는 생각이 듭니다.”
어제 그로쓰 평가의 시선.
“기술이 너무너무 비슷해요. 거의 다 똑같은 패키지 똑같은 구현하고 UI만 조금 다르고. 그걸로 막 점수를 바르기는 쉽지 않아요. 얼마나 아이디어가 좋고 진짜 쓸 만하고 기존에 없었고 — 거기에 좀 더 집중하게 되더라고요. 그래서 지금 좋기는 합니다. 만성질환은 지속적인 관리가 제일 중요한 거잖아요. 지속성을 높이는 데 정말 크게 일조할 수 있다 — 그걸 할 수 있는 게 쉽게 기록할 수 있는 기능들, 그리고 포인트 제도. 그런 걸 좀 내세울 수 있지 않을까.”
4. AI 피드백 — 통합 호출 vs 분리 호출
식단·운동·통합 피드백을 하나의 LLM 호출로 처리할지 따로 호출할지 여쭤봤어요.
“저도 똑같은 걸 해봤는데, 식단·운동 추천은 평소 따로따로 해서 그냥 UI에서 합쳤어요. 질문 자체가 ‘식단만 추천해 달라’고 하면 식단만 얘기할 거고, ‘운동만 추천하면’ 운동만 얘기를 하니까.”
LLM 답변이 “그러셨군요…” 부터 시작해 길어지는 문제는 프롬프트에 답변 양식을 명시하는 방식으로 해결하셨다고 합니다.
만성질환 사용자 UI에 대한 코멘트도 따로 받았어요.
“젊은 사람 기준이면 괜찮은데, 보통 만성질환은 나이가 좀 있으신 분들이 많다 보니, 글자가 작으면 전혀 못 알아보세요. 그래서 좀 크게 만드느라.”
5. RAG에 과거 기록을 얼마나 포함시킬지
“너무 옛날은 지금 현재 나에게 큰 영향을 미치지 못하는 것 같고요. 최근 5개 이런 식으로 딱 윈도우를 정해놓고 하시면 괜찮지 않을까 생각이 듭니다.”
기준은 두 가지를 병행하라고 하셨어요.
- 절대 기준 — “이 당의 섭취가 많다·적다라는 기준이 보통 있기 때문에” (진료지침 기반)
- 상대 추이 — “점점 당 섭취량이 올라간다, 그래도 미리 사전에 경고할 수도 있잖아요”
“이게 만성질환이고 1년에 한 번이 아니고 매일매일 관리를 할 거니까. 제일 큰 문제는 사람들이 귀찮아서 안 쓴다는 거.”
최근 5개 × (절대 + 상대) — 그로쓰 단계 AI 코치 설계 골격이 잡혀 가는 느낌이 들었습니다.
6. 트레이너 연계 — “숙제 검사”
운동 탭의 트레이너 연계 기능을 설명드리자 교수님이 직접 컨셉을 정리해 주셨어요.
“개인 운동도 하잖아요. 중간중간에 와서 그것도 다 기록해 놨다가, 그러면 그냥 숙제 검사해요. ‘왜 항의했어요? 왜 이걸 드셨어요?’ 그게 사실 PT의 목적이니까. 좋은 것 같습니다.”
“혼자 하는 거는 누가 관리를 안 해주니까. 밥도 그냥 전문가가 옆에서 보고 있는 거 아니잖아요. 그게 데이터가 되면 누가 봐줄 수도 있는 거고, AI가 봐줄 수도 있고.”
5/31 What’s Next 글에서 잡아 둔 그로쓰 방향 (C) — 쌍방향 O2O 피드백 루프 — 와 정확히 일치하는 평가였습니다.
7. 데이터 활용·비즈니스 모델
수집한 헬스 데이터를 다른 사업과 연결할 수 있는지 물어봤습니다.
“앱 내에서 진료를 할 수는 없지만, ‘병원에 오세요’ 라고 권유하는 건 가능해요. 특정 병원이 만들지 않더라도 주변에 있는 병원들 추천해 주고 ‘거기 가보세요’ 하는 정도는 될 수도 있어요.”
외부로 데이터를 보낼 경우 — 개인정보 동의 + 비식별화(이름·생년월일 마스킹). 연구 목적으로 쓸 경우 IRB 승인이 필요한데, 교수님 본인도 3번 거절당한 경험이 있다고 하셨어요.
“자원봉사하는 사람도 있고 와서 10만 원 받으시는 분들도 있는데, 이게 차별이 있으면 안 된다, 막 그러면서 계속 거절을 해가지고.”
8. 식단 인식 2-stage — 직접 비교 실험이 곧 contribution
YOLOv8 → Gemini Vision 2-stage 파이프라인이 정말 비용 절감인지 의문이라고 말씀드렸어요.
“비교하는 방법밖에 없긴 합니다. 직접 해보고 — 토큰 사용 시 얼마 정도 드는지 비교해 볼 수 있고요. 실제로 상용되는 모델 중에서 여러 AI 서비스들을 가져다 쓰는 경우가 많거든요. 물체 탐지는 A 모델, 분류는 B 모델, 설명은 C 모델 — 그런 케이스들이 있긴 있어요.”
“그게 졸프 관점에서 도움이 될 수도 있습니다. 어떤 게 더 optimal한지를 분석을 해 본 거잖아요. 그냥 ‘한번 이렇게 해봤더니 이렇게 돼요’ 보다는 ‘우리가 이러이러한 후보를 고려해 봤는데, 얘는 이래서 장단점이 있고 얘는 이래서 장단점이 있었다, 그래서 우리는 이걸 선택했다’ 라고 하는 게 더 논리적이기.”
비교 분석 자체가 contribution이 된다는 것 — 그로쓰 단계 진입 직후 가장 먼저 손댈 작업이 될 듯합니다. 사실 직접 비교해볼 생각은 못했는데, 좋은 아이디어인 것과 동시에 꽤 힘든 작업이 될 것 같다는 생각이 들었습니다. 그만큼 얻는 것도 많을 것 같습니다!
9. 클로징
면담 끝에 방학 작업을 강력히 권하셨어요.
“이게 그로쓰 가면은 진짜로 만들어야 되는 거잖아요. 가능한 한 빨리 해주시면 좋긴 한 것 같아요. 2학기 수업을 들으시거든요. 그래서 이것만 있는 게 아니고 또 여기서도 온갖 서류를 요청해요. 포스터도 만들어라, 발표 자료 만들어라, 발표 준비하고 데모 내고 코드 내고. 너무 쏟아지니까 너무 힘들어하시더라고요. 가능하면 그냥 개발 미리 해놓고, 방학 때 주기적으로 만나셔서 작업을 좀 하셔도 될 것 같고, 그러면 좀 더 완성도 있는 게 나오는 것 같더라고요.”
면담을 마치며 정리해 주신 한 줄.
“어필은 분명히 될 거예요. 다만 그 수많은 앱 중에 차별점이 뭐냐 — 거기에 100% 집중해서 잘 해결하시면 될 것 같고, 저는 어느 정도 해결이 되고 있다고 보고 있습니다. 지금 이 목표대로 하시면.”
10. 다음 학기로 가져갈 후속 조치
그로쓰 단계 진입 전 — 방학 중
- AI 피드백 프롬프트 분리 설계 (식단 / 운동 따로 호출 후 UI 합성)
- LLM 응답 양식 표준화 (장황한 답변 방지)
- 만성질환 사용자용 UI 가독성 (글자 크기·고대비)
- RAG 문서 소스 결정 (국내외 진료지침 + 최근 논문 리스트업)
- YOLOv8 → Gemini Vision 비교 실험 설계 (토큰 비용·정확도·레이턴시)
- 정기 미팅 유지
그로쓰 단계 전반
- YOLOv8 한국 음식 파인튜닝 (데이터셋 확보 + 라벨링 전략)
- RAG 슬라이딩 윈도우(최근 5개) + 절대/상대 기준 컨텍스트 설계
- 트레이너 연계 웹 대시보드 PoC
- 비교 실험 결과를 보고서 contribution 챕터로 정리
그로쓰 단계 후반
- 웨어러블·CGM·혈압계 기기 연동 (외주 가능성 검토)
- IRB 자료 사전 준비 (장기 사업화 옵션)
- 비식별화 파이프라인 (외부 데이터 공유 시)
📌 요약
황의원 교수님 면담에서 발표·심사 관점, 만성질환 도메인 특화, AI 피드백 설계, RAG 컨텍스트 전략, 트레이너 연계, 데이터 활용·IRB, 식단 인식 파이프라인 비교 실험까지 코멘트를 받았습니다. 핵심은 “기술보다 차별점, 그리고 만성질환의 지속성·귀찮음을 앱이 얼마나 잘 해소하는가” — RAG 문서 소스(진료지침 + 논문), 사진 기반 자동 영양 분석, 포인트 제도, 트레이너 연계가 차별점으로 평가됐습니다. 방학 중에 진행할 작업과 그로쓰 단계 전·중·후로 나눈 후속 조치도 함께 정리했습니다.