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

📌 회차 정보

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

내일 발표다.

이번 주는 발표 시연 안정화 + 성능 점검에 시간을 거의 다 썼다. 코드를 새로 짜기보단 이미 만들어둔 게 시연 도중 안 터지게 다듬는 작업. 막상 시연용 데이터 넣고 돌려보니까 평소엔 안 보이던 게 보였다.

이번 글은 시연 점검하면서 잡은 것들 위주로 가볍게 정리.

---

1. 들어가기 전에

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

• 기능 개발 진행 상황 점검 (~5주차)
• 추가 기능 개발 및 테스트 (~5주차)
• 최종 점검 및 발표 준비 (6주차)
• 실전 적용 및 개선 (7주차~) ← 지금

원래는 "실 운영 테스트"가 메인이어야 하는데, 우리 팀은 배포를 아직 안 했다. 학생 프로젝트라 클라우드 비용 부담도 있고, 노년층 대상이라 실 사용자 받기 전에 좀 더 다듬는 게 맞다는 결론. 그래서 7주차는 로컬 환경 + 시연용 데이터셋에서의 점검에 집중.

---

2. 7주차에 한 일

작업 상태

발표 자료 마무리 + 리허설	✅
시연용 더미 데이터 세팅	✅
API 응답 시간 측정 + 병목 구간 확인	✅
AI 모델 교체 (Gemini → GPT-4o)	✅
쿼리 가벼운 정리	✅
배포 환경 결정	⏳ (발표 후로 미룸)

---

3. AI 모델, 결국 GPT-4o로 바꿨다

6주차 글에서 "최종 모델은 Gemini 2.5 Flash"라고 적어놨는데, 이번 주에 다시 GPT-4o로 갈아탔다. 한 주 만에 또 바뀐 셈.

왜 또 바꿨냐

시연 리허설을 돌리면서 보니까, 응답 속도 체감이 의외로 중요했다.

• 자정 스케줄러로 자동 생성되는 경우야 사용자가 응답 속도 신경 안 씀
• 근데 시연 도중 "AI 일기 초안 만들기" 시연은 발표 자리에서 즉시 응답이 나와야 함. 1~2초만 지연돼도 어색함
• 두 모델 다 충분히 빠르긴 한데, GPT-4o가 응답 시작이 좀 더 빨라서 시연 흐름이 부드러움

비용 차이는 분명히 있지만, 발표 시연 + 초반 베타 테스트 단계에선 호출량 자체가 적기 때문에 가격 영향이 크지 않았다. 본격 운영 단계 들어가면 다시 한번 비교해볼 예정.

6주차에 "운영 환경까지 고려해서 Gemini 갔다"고 했는데, 결국 7주차에는 "시연 안정성"이라는 또 다른 컨텍스트가 추가되면서 결정이 바뀐 거. ML 모델 선택은 한 번 정하면 끝나는 게 아니라는 걸 또 배움.

---

4. 시연 돌려보니까 보이는 것들

평소 개발할 땐 데이터가 적어서 모든 게 빠릿빠릿했는데, 시연용으로 유저/일기 더미 데이터를 좀 넣고 돌려보니까 안 보이던 게 보이기 시작.

1. 일기 목록 조회가 살짝 느려짐

일기 목록 API 응답이 데이터 적을 땐 빠릿하다가, 더미 데이터 좀 쌓이니까 눈에 띄게 느려졌다. JPA 로그 켜놓고 보니까 연관 엔티티(중간기록, 사용자 정보)를 하나씩 따로 가져오는 전형적인 N+1 패턴이 있었음.

알고는 있었는데 콘솔에 SELECT 문이 쫙 깔리는 거 직접 보니까 머쓱.

대응: 일기 목록 조회 쿼리에서 연관 엔티티를 함께 가져오도록 fetch 방식 정리. 코드 자체는 어노테이션 하나 정도 추가 수준이라 크게 손댄 건 아니고, 시연 데이터셋에선 체감상 확실히 빨라짐.

본격 최적화(인덱스 검토, 페이징 튜닝 등)는 발표 후로 미룸.

2. Gemini API 호출 실패 케이스

GPT-4o로 바꾸기 직전에 자정 스케줄러 돌리다가, Gemini API 쪽에서 일시적 timeout이 나는 케이스를 본 적이 있다. 한 번 실패하면 그 사용자는 그날 일기를 못 받는 구조라 좀 위험했음.

대응: 외부 API 호출에 단순 재시도 로직 추가 (최대 몇 회, 짧은 백오프 정도로). 시연 도중 일시적 네트워크 문제로 터질 확률 자체를 낮춤. 실패 케이스를 큐로 빼서 재처리하는 본격적인 구조는 8주차 이후로.

3. 사진 여러 장 올릴 때

사진 3~5장을 한 번에 올리면 응답이 좀 늦게 옴. EXIF 메타데이터 추출까지 동기로 처리하는 구조라서 그런 것. 발표 시연에선 사진 1~2장만 쓰는 시나리오라서 일단 그대로 두고, 비동기 분리는 8주차에 검토할 예정.

---

5. 시연 준비 — 코드보다 더 신경 쓴 부분

이번 주에 코드보다 더 시간 쓴 게 시연 준비였다. 발표 도중에 뭐라도 하나 터지면 답이 없어서.

• 시연용 더미 계정 + 데이터 세팅 (최근 며칠치 일기 미리 채워둠)
• 사진은 저작권 안전한 무료 이미지로 업로드 (Unsplash 등)
• 자정 스케줄러 결과물 예시 미리 박아둠 — 시연 도중 자정 기다릴 순 없으니까
• 시연 영상 백업 — 라이브 데모 실패 대비. 멘토님 추천대로 미리 녹화해둠

특히 백업 영상이 제일 든든했다. 라이브 시연 망하면 영상 틀고 넘어가면 되니까.

---

6. 이번 주 배운 점

1) 데이터가 들어가야 진짜 문제가 보인다

개발할 땐 데이터 몇 건 갖고 테스트하니까 모든 게 빠릿빠릿했는데, 더미 데이터 좀 쌓이니까 N+1 같은 게 바로 드러났다. 로컬 개발 데이터셋이 너무 가벼우면 진짜 문제는 발견 안 됨.

2) "지금 안 잡아도 되는 거" 구분하는 게 능력

이미지 비동기, 리포트 캐싱, 인덱스 튜닝 — 다 가치 있는 작업이지만 발표 직전에 손대면 안 되는 종류. 시연이 잘 돌아가는 게 우선이고, 본격 최적화는 발표 끝나고 진짜 사용자 데이터 보면서 해도 늦지 않음. 욕심내서 지금 손댔으면 어디 한 곳은 분명 터졌을 듯.

3) 모델 선택은 한 번에 안 끝난다

5주차에 GPT-4o vs Claude vs Gemini 고민하다 6주차에 Gemini로 갔는데, 7주차에 다시 GPT-4o로 옴. 매주 결정이 바뀌는 게 좀 어이없긴 한데, 매번 새로운 컨텍스트(운영 비용 → 시연 속도) 가 들어와서 다시 봐야 했음. 처음부터 완벽한 선택은 없고, 단계마다 다시 점검해야 한다는 걸 배움.

---

7. 내일 — 발표 D-DAY

내일 발표 (5/18). 외부 발표회 (멘토링 기관 주관).

오늘 자기 전에 시연 한 번 더 돌려보고 자야겠다. 떨리긴 하는데 6주 동안 만든 거 잘 보여주고 오면 좋겠음.

발표 끝나고 8주차에 결과랑 같이 정리해서 돌아오겠습니다.

---

마무리

7주차는 코드 짠 양은 적었지만 "어떻게 안정적으로 보여줄까" 에 대해 가장 깊이 고민한 주였다. 개발은 끝나도 끝난 게 아니라는 말이 무슨 뜻인지 알 것 같다.

다음 회차는 발표 후기 + 진짜 운영 테스트 시작 글로 돌아옵니다.