[2026 ABC 프로젝트 멘토링 1기] 프로젝트 6주차

📌 회차 정보

• 기간: 2026.05.07 ~ 2026.05.13 (6주차)
• 담당 파트: 백엔드 (BE1)
• 스택: Spring Boot 4.x / Java 21 / PostgreSQL / JPA

다음 주 발표다.

이번 주는 박사님한테 시연 보여드리고 피드백을 한 보따리 받았다. 11개. 그걸 적용하고, 발표 자료 만들고, 마지막으로 신규 기능 두 개까지 욱여넣은 한 주였다. 손이 제일 많이 움직인 주 중 하나였던 것 같음.

이번 글은 박사님 피드백 11개 정리 + 발표 D-9 점검 톤으로 간다.

---

 

 

1. 들어가기 전에

이번 회차부터 포맷이 또 바뀌었다.

• 기능 개발 진행 상황 점검 (~5주차)
• 추가 기능 개발 및 테스트 (~5주차)
• 최종 점검 및 발표 준비 (6주차~) ← 지금
  • 프로젝트 최종 점검 및 디버깅
  • 발표 자료 준비 및 피드백
  • 최종 리허설 및 개선 사항 적용

발표는 외부 발표회 (멘토링 기관 주관) 라서 그냥 데모만 보여주는 게 아니라 시연이 매끄럽게 돌아야 한다.

그래서 이 단계에선 신규 기능보단 디버깅 + 점검이 메인이라고 생각했었는데... 박사님 피드백이 들어오면서 신규 기능 두 개가 추가로 박혔다.

---

2. 6주차에 한 일

작업 상태

박사님 최종 피드백 11개 반영	✅
신규 기능 — GPS 자동 위치 설정	✅
신규 기능 — 사진 장소 맞히기 퀴즈	✅
AI 모델 최종 결정 (Gemini 2.5 Flash)	✅
프로젝트 최종 점검 및 디버깅	🔄
발표 자료 준비	🔄
최종 리허설	⏳

 

---

3. 박사님 최종 피드백 — 11개 정리

이번 주 메인. 박사님이 시연 보고 한 번에 11개 피드백을 주셨다. 사소해 보이지만 사용자가 직접 부딪히는 디테일이라 다 잡아야 했음.

카테고리별로 묶어서 정리.

🔧 데이터 일관성 / 버그

1. 호칭 변경 시 기존 일기 호칭도 변경할지 + 호칭 변경 후 신규 일기 호칭 미적용 버그

이게 제일 골치 아팠다. 사용자가 "할머니" → "어머님"으로 바꾸면, 이미 만들어진 일기에 박혀 있던 "할머니" 호칭은 어떻게 할지 + 새로 작성하는 일기에 왜 호칭이 안 바뀌는지 두 가지 문제.

대응

• 신규 일기 미적용 버그 → AI 프롬프트 생성 시점에 사용자 호칭을 매번 다시 조회하도록 수정
• 기존 일기는 박사님이랑 상의 결과 그대로 두기로 — 일기는 시점별 기록이라는 성격상 과거 호칭도 보존하는 게 맞다는 결론

📍 위치 / 회원정보

5. 회원가입 시 GPS로 대전 내 위치 자동 설정 + 수정 가능

원래는 회원가입 때 주소를 직접 입력받았는데, 노년층한테 동 단위까지 직접 고르게 하는 건 불친절했다. 회원가입 플로우 수정해서 GPS 자동 설정 도입.

대응

• 회원가입 진입 시 GPS로 자동 위치 받아오는 단계 추가
• 받아온 좌표를 동 단위로 변환
• 자동 설정 후 사용자가 수정할 수 있도록 유지

회원가입 플로우 손대는 게 부담스러웠는데 (이미 다 만들어둔 거 건드리는 거니까) 박사님 의견이 맞아서 결국 들어갔다.

🧠 AI 분석 고도화

10. AI 분석에 이름 / 특정 장소 / 특정 시간대 움직임 활용

원래는 "기분 + 사진 메타데이터"만 프롬프트에 넣었는데, 박사님이 노년층 일기에서 진짜 의미 있는 건 누구를 만났고, 어디 갔고, 언제 뭘 했는지 패턴이라고 지적.

대응

• 사용자 한 줄 코멘트에서 인명/장소/시간 추출하는 전처리 추가
• 이걸 프롬프트에 함께 넣어서 일기 초안의 디테일 살림
• 결과적으로 "오늘 평온한 하루였다" 같은 일반적 문장이 줄고, "오후에 손녀 지수가 다녀갔다" 같은 구체적 문장이 나오기 시작함

🎯 신규 기능 — 퀴즈

7. 사진 장소 맞히기 퀴즈 (알츠하이머 예방)

이건 신규 기능 추가. 사용자가 그 날 올린 사진의 장소를 다음 날 맞혀보게 하는 기능. 단순한 회상 훈련인데 알츠하이머 증상 예방에 효과가 있다는 박사님 의견.

대응

• Quiz 엔티티 신규 설계 (출제 정보 + 정답 + 사용자 응답)
• 사진 메타데이터에서 장소 좌표 → 동/구 단위 정답으로 변환
• 자정 스케줄러에서 어제 사진 중 1개 골라서 다음 날 퀴즈로 자동 출제

발표 직전에 신규 도메인 추가하는 게 좀 부담이긴 했는데, 박사님 피드백 받은 다음 날 바로 설계 들어가서 시간 안에 끝냈다.

📞 응급 / 알림

9. 비상 연락망 바로 전화 걸기

기존엔 비상 연락처를 저장만 해뒀는데, 노년층이 위급 상황에서 연락처 화면 들어가서 번호 확인하고 다시 전화 거는 건 비현실적이라는 피드백.

대응

• 백엔드는 비상 연락처 조회 API만 빠르게 응답하도록 정리
• 실제 전화 거는 액션은 프론트(tel: 링크) 담당

💬 UI 멘트 / 토스트 (프론트 중심, 백엔드 영향 일부)

이건 프론트 영역이지만 백엔드 응답 메시지에도 영향이 있어서 같이 정리.

• (2) 글씨 키울 때 텍스트 잘림 → 프론트
• (3) 사진 페이지 "선택" 표기 추가 → 프론트
• (4) 메인 화면 인사 멘트 톤 조정 → 프론트
• (6) 일기 저장 시 토스트 메시지 → 백엔드 응답 메시지 통일 + 프론트 토스트
• (8) 사진 페이지 코멘트 멘트 변경 ("누구를 만나셨나요? 무엇을 드셨나요?") → 프론트
• (11) 최종 일기 작성 후 안내 문구 수정 → 프론트

전부 적용 완료. 사소한 거 같아도 11개 한꺼번에 들어오니까 양이 만만치 않았음.

---

4. OpenRouter 최종 모델 — Gemini 2.5 Flash로 갔다

지난 회차에서 GPT-4o랑 Claude 3.5 Sonnet 두 개 놓고 고민한다고 했었는데, 결국 Gemini 2.5 Flash로 결정했다.

5주차 글에선 "Gemini는 노년층 말투에서 어색해서 일단 제외"라고 적었는데, 그건 이전 버전(2.0 Flash) 얘기였다. 이번에 2.5 Flash로 다시 돌려보니까 결과가 확 달라짐.

결정 이유

1. 품질이 GPT-4o, Claude 3.5 Sonnet에 비벼볼 만함 — 2.0 Flash 때 어색했던 톤이 2.5에서 많이 자연스러워짐
2. 비용이 압도적으로 쌈 — GPT-4o 대비 1/N 수준 (정확한 가격은 글 발행 시점에 다시 확인 예정). 자정 스케줄러로 매일 호출하는 구조라 운영비 차이가 큼
3. 응답 속도 빠름 — Flash 라인이라 latency 낮음. 자정 배치 처리 시간이 짧아짐

결정 후 한 일

• 프롬프트 미세 조정 (Gemini가 GPT/Claude랑 토큰 처리 방식 살짝 달라서)
• 박사님 피드백 10번 (이름/장소/시간 활용) 반영해서 프롬프트 재설계
• 응답 안정성 테스트 — 100번 정도 돌려서 JSON 깨지는 케이스 있는지 확인

품질 비교만 갖고 결정 못 하던 게, 운영 환경(매일 자정 N건 호출) 까지 같이 고려하니까 답이 보였다. ML 모델 선택은 단순히 응답 좋은 거 고르는 게 아니라 운영 컨텍스트를 같이 봐야 하는 거구나, 라는 걸 이번에 체감.

---

5. 이번 주 배운 점

1) 발표 직전이라고 신규 기능 못 박는 거 아니다

처음엔 "이 단계에선 디버깅만 하지 신규 기능은 안 들어가지" 싶었는데, 박사님 피드백 받고 보니까 신규 기능 두 개(GPS, 퀴즈)가 더 임팩트 컸다. 마감 직전이라고 보수적으로만 가는 게 답이 아니구나 싶었음.

물론 그만큼 손이 빨라야 하긴 함.

2) 박사님 피드백 11개 = 11번 사용자 입장으로 돌아가기

11개 다 코드 한두 줄짜리 사소한 변경인데, 하나하나가 다 "이걸 진짜 노년층이 쓸 때 어떨까" 라는 관점에서 나온 거였다. 개발자 머리로는 절대 안 보이는 디테일.

특히 9번(비상 연락망 바로 전화) 같은 거. 우리는 "전화번호 저장 → 조회 가능 = 끝"이라고 생각했는데 박사님은 "위급 상황에서 진짜 누를 수 있어야 함"으로 바라봄. 

3) "이미 만들어둔 거 건드리기"의 부담

회원가입 플로우 같은 건 한번 다 만들어두면 다시 손대기 진짜 싫다. 근데 이번 주에 회원가입 플로우 수정하면서 느낀 건 — 사용자 입장에서 좋은 거면 다 갈아엎는 게 맞다.

---

6. 다음 주 — 발표 D-9

남은 일은 이렇다.

순위 작업

1	시연 시나리오 정리 + 리허설
2	발표 자료 마무리
3	최종 디버깅 (시연 도중 안 터지게)
4	백엔드 모니터링 (Gemini API 비용/속도 체크)

 

---

마무리

이번 주는 손도 머리도 다 바쁜 주였다. 박사님 피드백이 의외로 사용자 관점을 다시 잡아주는 계기가 됐고, 신규 기능 두 개도 알차게 들어갔다. 다음 주 발표만 잘 끝내면 한숨 돌릴 수 있을 듯.

발표 끝나면 7주차 글에서 또 정리하겠습니다.

---