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

 

최종 발표 및 평가

📌 회차 정보

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

8주차다. 멘토링 프로그램의 마지막 회차.

5/27 최종 발표를 끝내고 돌아왔다. 시연 영상도 매끄럽게 재생됐고 박사님 평가 피드백도 받았다. 근데 그 피드백 내용 보고 팀에서 결론 난 게 — 여기서 끝내지 말고 진짜 서비스로 올려보자. 이번 글은 발표 후기 + 박사님 피드백 정리 + 앞으로 어떻게 할지.

---

1. 들어가기 전에

이번 회차 포맷은 이렇다.

• 최종 발표 진행 및 팀별 발표
• 프로젝트 성과 평가 및 피드백
• 향후 발전 방향 논의

이번 5/27은 멘토링 프로그램 전체의 최종 평가 발표. 시연 + 발표 자료 + Q&A까지 정식 절차로 진행됐다.

---

2. 발표 당일 — 영상으로 시연을 대체했다

원래는 라이브 시연으로 가려고 했는데, 발표 환경 점검 단계에서 변수가 생겼다. 차원/디바이스 환경 문제로 라이브 진행이 안전하지 않다고 판단해서 막판에 시연 영상으로 전환했다.

다행히 7주차에 백업용으로 시연 영상을 미리 찍어뒀었다 ("라이브 데모 실패 대비"). 그게 결국 메인 시연 자료로 격상된 셈. 영상 재생 자체는 문제 없이 매끄럽게 돌아갔다.

지나고 보니 잘한 결정이었다.

• 발표자가 라이브 디바이스 조작에 신경 안 쓰고 설명에만 집중 가능
• 영상에 GPT-4o로 빠릿빠릿하게 응답하는 AI 일기 생성 장면이 그대로 들어가 있어서 흐름이 매끄러움
• 시연 도중 터질 걱정 자체가 없음

라이브 시연이 더 멋있어 보이긴 하지만, 발표의 목적은 "기능을 보여주는 것"이지 "라이브로 한다는 것"이 아님. 환경 변수에 휘둘리는 것보다 안정적으로 보여주는 게 맞았다. 그리고 7주차에 백업 영상을 미리 찍어둔 게 진짜 신의 한 수였음. 그 작업 안 했으면 막판에 패닉이었을 것.

발표 후 받은 의견 — 글씨 크기 옵션

박사님 평가 피드백은 따로 정리(아래)했고, 발표 직후 추가로 인상 깊었던 의견 하나.

우리가 글씨 크기를 Small / Medium / Large 로 선택할 수 있게 만들었는데, 이런 의견을 받았다.

"노년층은 어차피 글씨 큰 걸 무조건 선호한다. 굳이 옵션을 둘 필요 없이 그냥 기본 폰트를 크게 고정해도 되지 않냐."

듣는 순간 머리를 한 대 맞은 느낌이었다. 우리는 "선택지를 주는 게 사용자 친화적" 이라고 생각해서 세 단계로 만들었는데, 정작 타겟 사용자 입장에선 "고를 필요 자체가 없는 게 더 친절" 한 상황이었던 것.

이게 정확히 박사님이 평가에서 짚어준 "개발자 시선 vs 사용자 시선" 의 차이였다. 개발자는 "유연성을 줘야 한다"고 생각하고, 사용자는 "결정 안 하게 해줘야 편하다"고 느낌. 같은 인터페이스를 두 각도에서 보는 셈.

향후 개선 항목에 바로 추가했다. 글씨 크기 옵션 제거 + 기본 폰트 크게 고정.

---

3. 박사님 평가 피드백

발표 끝나고 멘토 박사님께서 정리해주신 피드백이 있는데, 이 내용이 8주차 글의 진짜 메인이다. 박사님께서 짚어주신 3가지를 정리.

① 개발자 시선 → 사용자 시선으로의 전환

"에뮬레이터가 아닌 실제 기기 환경에서 고령층을 위한 '제로 타이핑' UI를 고민하고 설계한 것은 타겟 유저에 대한 깊은 이해를 보여줍니다."

이건 우리 프로젝트의 핵심 가치였다. 노년층이 키보드 타이핑하는 것 자체가 진입 장벽이라는 가정에서 출발해서, 사진 + 기분 선택 + 한 줄 코멘트 만으로 일기가 완성되는 구조를 만들었다. 박사님이 이 부분을 콕 짚어주신 게 인상 깊었음.

개발할 땐 그냥 "기능이 잘 돌아가게" 만 신경 썼는데, 결국 가장 가치 있게 평가받은 건 "이걸 누가 쓸 건지" 에 대한 고민 이었다.

② 제약 속에서 유연한 대안 찾기

"비용 문제로 전화번호 인증을 이메일로 대체하고, 초기 DB 설계와 프롬프트 튜닝의 파급력을 깨달은 것은 교과서에서 배울 수 없었던 내용으로 생각합니다."

4주차 멘토 피드백 받았을 때 떠올리면 — 전화번호 인증을 이메일로 대체한 것, DB 설계(BIGINT/BIGSERIAL → SERIAL)를 재검토한 것, 매주 프롬프트 튜닝을 다시 한 것. 그땐 그냥 피드백 받고 처리한 거였는데, 박사님 입장에선 이게 "제약 속에서 유연하게 대안 찾는 실무 마인드" 였다는 거.

개발 공부할 때 흔히 "베스트 프랙티스"만 쫓게 되는데, 진짜 실무는 제약 안에서 차선책을 찾는 능력 이라는 걸 다시 배움.

③ 협업의 뼈대

"환경 설정 표준화, API 명세 공유, 연동 오류 해결 등 보이지 않는 과정을 토론과 협의로 잘 풀어낸 점을 높이 평가합니다."

이게 진짜 의외였다. 코드가 잘 돌아간다거나 기능이 많다거나 그런 거보다, .env 정리하고 API 명세 공유하고 깃 브랜치 관리한 거 를 박사님이 더 높게 봐주신 것.

생각해보면 우리 시리즈 글에서도 가장 많이 나온 단어가 "협업"이었다. 4주차 .env 표준화, 5주차 API 명세 정리, 6주차 박사님 피드백 11개 같이 나누기. "보이지 않는 과정" 이라는 표현이 진짜 와닿음.

그리고 마지막에 박사님께서 한 말씀

"여러분이 만든 서비스는 '완성'이 아니라 훌륭한 시작점이라고 생각합니다."

이 한 줄이 진짜 컸다. 회고록 초안에 "비록 완벽한 결과물은 아니지만..." 같은 표현을 적어놨었는데, 박사님이 그걸 짚어서 — "실무에서 '완벽한 결과물'이란 존재하지 않는다. 서비스는 출시된 순간부터 사용자 피드백을 받아 끊임없이 수정되고 발전하는 생명체" — 라고 정리해주셨다.

그리고 한마디 더.

"여러분들께서 제작한 애플리케이션을 더 발전시켜 나갔으면 좋겠습니다. 어떤 것을 시작한 후, 제대로 마무리하는 것도 여러분께 큰 자산이 될 것입니다."

이 문장 보고 팀 회의 결과 — 그래서 "여기서 끝내지 말고 실 서비스로 운영해보자" 가 됐다.

---

4. 8주 회고

매주 글 쓰면서 그때그때 회고는 했지만, 8주 전체를 놓고 보는 회고는 또 다른 느낌.

주차별 한 줄 요약

주차 한 줄

1주차	ERD 그리고 카카오 KOE006에 멘붕
2주차	API 양치기 — 백엔드 명세 거의 다 박음
3주차	시험기간 + 코드 리뷰만
4주차	멘토 피드백 한 보따리 받고 정리
5주차	AI 모델 비교, 자정 스케줄러 구현
6주차	박사님 피드백 11개 적용 + 신규 기능(Quiz, GPS)
7주차	발표 직전 시연 안정화 + 모델 GPT-4o로 교체
8주차	최종 발표

처음 KOE006으로 패닉했던 게 어제 같은데 어느새 8주차.

기억에 남는 기술 결정 3개

1) OpenRouter로 멀티 모델 테스트

처음엔 OpenAI API만 붙이려고 했는데 멘토 추천으로 OpenRouter를 알게 됐다. 모델 갈아끼우는 게 문자열 한 줄 수정인 게 진짜 신세계. 5주차 Gemini → 6주차 Gemini → 7주차 GPT-4o — 매주 결정이 바뀌었는데도 OpenRouter 덕에 코드 거의 안 건드림.

2) 자정 자동 일기 생성 (Scheduler)

노년층이 매일 "최종 일기 작성" 버튼을 정확히 누를 거라는 가정 자체가 비현실적이었다는 박사님 지적이 컸다. @Scheduled 한 줄 코드처럼 보이지만 시간대, 빈 데이터, 외부 API 재시도까지 잡으니까 진짜 신경 쓸 게 많은 기능. "기능 90%랑 100%의 거리는 멀다" 는 걸 가장 잘 보여준 작업.

3) 호칭 변경 버그를 통한 데이터 일관성 학습

박사님 피드백 1번. 사용자가 호칭을 바꿔도 새 일기에 안 적용되던 버그. 파보니 프롬프트 생성 시점에 사용자 호칭이 캐싱돼 있었음. 이 작은 버그가 "사용자 데이터가 시스템 곳곳에 박혔을 때 동기화를 어떻게 보장하는지" 라는 더 큰 주제로 이어졌다.

---

5. 향후 방향 — 진짜 서비스로 만들기

박사님 피드백 + 팀 회의 결과, 여기서 끝내지 말고 실 서비스로 운영해보자 는 결론.

수개월 내 정식 출시를 목표로 두고, 단계별로 이렇게 잡았다.

단기 (배포 준비)

• 글씨 크기 옵션 제거 + 기본 폰트 크게 고정 — 발표 피드백 즉시 반영. 노년층은 옵션 고를 필요 없이 큰 글씨가 디폴트인 게 맞음
• 배포 환경 결정 — 아직 미정. AWS / GCP / 프리티어 옵션 비교 중. 학생 프로젝트 시작점이라 비용 부담 최소화부터.
• .env 분리 정리 — 개발용 / 운영용 환경 변수 깔끔하게 분리
• HTTPS + 도메인 + 백업 정책 — 실 사용자 데이터 들어오기 전 필수 작업
• 모니터링 도구 도입 — 최소한 에러 추적 + API 호출량 + Gemini/GPT-4o 비용 알람

중기 (실 사용자 받기)

• 베타 테스트 — 박사님 피드백 + 평가 Q&A에서도 지적받은 부분. 가족 / 지인의 부모님부터 시작해서 점진적으로 확대
• AI 비용 감시 + 모델 분기 — GPT-4o 호출량 임계치 넘으면 Gemini Flash로 분기하는 구조

장기 (서비스로 자리잡기)

• 퀴즈 기능 효과 검증 — 박사님 자문 기반이지만 실제 사용 데이터로 검증
• 공공기관 연계 검토 — 원래 기획에 있던 "장시간 활동 미감지 시 긴급 신고" 같은 기능
• 사용자층 확장 — 일기 자동 생성 자체는 보호자 / 다른 연령층한테도 가치 있을 수 있음

수개월 내 1차 배포 목표인데, 실제 일정은 학교 일정 + 팀원 사정 같이 봐야 해서 디테일은 추후 정리.

---

6. 시리즈를 마치며

프로젝트는 안 끝났지만, 멘토링 프로그램 시리즈 글은 여기서 마무리.

8주 동안 매주 한 편씩 글을 썼다. 처음엔 의무감으로 시작했는데, 글로 정리하면서 머리속이 같이 정리되는 게 신기했다. 매주 "이번 주에 뭐 했지" 떠올리는 그 시간이 사실 진짜 학습이었던 것 같음.

특히 4주차 멘토 발언 — "라이브러리 동작을 본인이 다이어그램으로 못 그리면 모르는 거다." 이게 글쓰기에도 똑같이 적용되는 듯. 본인 코드를 본인 언어로 설명 못 하면 사실 모르는 것. 매주 글로 풀어내면서 모르는 채로 넘어갔던 게 진짜 알게 되는 경험이 많았다.

박사님이 마지막에 한 말씀 — "이 기술을 누구에게, 어떤 문제를 해결하기 위해 사용할 것인가" 라는 질문을 항상 던지라는 말 — 이게 8주 동안 매주 글 쓰면서 진짜로 배운 한 줄인 것 같다. 기술 자체가 아니라 누구의 어떤 문제를 푸는 기술 이냐가 결국 본질이라는 것.

---

마무리

• 8주 멘토링 끝
• 발표 무사히 끝
• 시리즈 블로그도 여기까지
• 근데 프로젝트는 박사님 말씀대로, 완성이 아니라 시작점

읽어주신 분들 진짜 감사합니다. 누군가의 KOE006 디버깅에, 누군가의 OpenRouter 첫 시도에, 누군가의 자정 스케줄러 설계에 이 시리즈가 한 줄이라도 도움이 됐으면 좋겠습니다.

실 서비스로 올라가면 그땐 새로운 시리즈로 또 만나요 🙇

---