🥕 2025.12.20 🥕
[개발 기록][BE/AI] AI 일기생성 시 사진 한장만 분석 -> 모든 사진 분석되도록 수정
이번 4차 멘토링은 프로젝트의 마무리 단계에서 우리가 구축한 기술적 성과를 어떻게 '언어'와 '시각'으로 전달할 것인가에 대한 치열한 코칭이었습니다. 단순히 "열심히 만들었다"가 아니라, "우리가 왜 이렇게 설계했고, 이 과정이 공학적으로 어떤 의미를 갖는지"를 증명하는 법을 배웠습니다.
특히 이번에는 직접 참여하며 멘토님의 날카로운 피드백을 현장에서 수용할 수 있었는데, 지난 시간들에 참여하지 못했던 것이 더 큰 아쉬움으로 다가올 만큼 밀도 높은 시간이었습니다. 4차 멘토링의 핵심 내용과 제가 느낀 점을 정리해 봅니다.
4차 멘토링과 최종 설계 고도화
1. 조직의 재구성: 이름이 아닌 '역할' 중심의 스크럼
프로젝트 팀 구성 섹션에서 단순히 팀원 이름을 나열하는 방식에서 벗어나, 역할 중심의 조직도로 재편했습니다.
-
구조: 스크럼 마스터를 필두로 프론트엔드, 백엔드, 배포(Infra), AI 파트별 리더를 지정하여 각 도메인의 기술 표준과 책임을 명확히 했습니다.
-
전달 방식: 이론적인 애자일 설명보다는 실제 Jira 화면과 스토리 포인트를 어떻게 측정했는지, 번다운 차트를 통해 스프린트를 어떻게 개선해 나갔는지에 대한 '데이터'를 전면에 배치하기로 했습니다.
2. 아키텍처의 가독성과 논리: 실선과 점선의 차이
아키텍처 설계에서도 '표현의 정교함'이 강조되었습니다.
-
통신 규약의 시각화: 백엔드 아키텍처에서 서비스 간 동기(Sync) 호출은 실선으로, 비동기(Async) 호출은 점선으로 구분하여 데이터 흐름의 성격을 한눈에 파악할 수 있도록 했습니다.
-
AI & RAG 아키텍처: 기록 서비스에서 외부 LLM을 어떻게 호출하는지, 벡터 DB를 어떻게 구축했는지 등 RAG(Retrieval-Augmented Generation) 관점의 경로를 구체적으로 그리는 데 집중했습니다. 불필요한 프론트 구조는 덜어내고 백엔드와 외부 API 간의 상호작용을 강조했습니다.
3. 인프라와 배포: 패킷의 경로를 증명하는 설계
인프라 섹션에서는 클러스터 내부의 복잡한 선들을 정리하고, 실질적인 트래픽의 In/Outbound 경로를 표시하는 데 주력했습니다.
-
EKS 클러스터: 레플리카 간의 불필요한 연결 대신, 트래픽이 합쳐지는 경로를 단순화하여 가독성을 높였습니다.
-
기술적 선택: Kafka의 경우 Docker 이미지로 띄워 운영 효율성을 높이기로 결정했고, Redis 도입 여부 등 남은 기술적 의사결정을 ADR(Architecture Decision Record)에 반영하여 근거를 남기기로 했습니다.
4. 발표 전략: 육하원칙(5W1H)에 기반한 How의 증명
발표 장표는 "What -> Who -> How"의 순서로 구성하여 청중이 기술적 흐름을 놓치지 않게 설계하도록 하는 것입니다.
-
HOW의 강조: 방법론(스크럼)부터 시작해 기술 스택, 아키텍처(BE->인프라->AI), 상세 설계(API, UI, DB), 코드 표준까지 이어지는 흐름을 이미지 중심으로 배치했습니다.
-
시각적 압도: 글씨를 키우고 텍스트를 줄이는 대신, 우리가 고민한 흔적이 담긴 아키텍처 그림과 UI 프레임워크 이미지를 적극 활용하여 효율적인 PPT를 지향했습니다.
💡 멘토링 회고 및 느낀 점
이번 멘토링에 직접 참여하며 느낀 것은, 엔지니어에게 '구현 능력'만큼 중요한 것이 '자신의 설계를 논리적으로 표현하고 PR하는 능력'이라는 사실이었습니다. 멘토님께서 강조하신 "발표와 문서 작성을 잘해야 연봉이 올라간다"는 말씀이 단순히 농담이 아니라, 기술적 가치를 타인에게 전달하는 역량의 중요성을 일깨워주셨습니다.
직접 참여해보니 멘토님의 피드백 하나하나가 프로젝트의 퀄리티를 수직 상승시키는 것을 경험할 수 있었고, 진작 참여하지 못했던 지난 시간들이 더욱 아쉽게 느껴졌습니다. 하지만 남은 최종 시연까지 멘토님의 가이드대로 육하원칙에 따라 우리의 과정을 투명하게 증명하여, 단순한 '과제물'이 아닌 '진짜 서비스'를 세상에 내보이겠다는 각오를 다지게 된 소중한 시간이었습니다.
