[TeamBlog] V1 리뷰 - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki
estar.yoon(윤동규)/인공지능
프로젝트 개요
주요 기능 챗봇에서 Gemini API를 활용하여 면접모드의 프롬프팅, 프롬프팅 인젝션 보안처리, 꼬리질문 생성, 비용과 한국어 성능을 위한 Naver Colova + Gemini API 혼합 활용, Backend(SpringBoot)와 연동을 구현하였습니다.
Keep (잘한 점, 유지할 점)
- MVP 단계에서 처음 설계 한 것 보다 더 많은 것을 구현하였다.
- 기간 내에 프로젝트를 완성하였다.
- SpringBoot와 연동 과정에서 빠르게 로깅 처리를 하여 빠르게 문제를 해결하게 되었다.
- 설계가 단단하여 다양한 오류에서도 유연하게 대처 가능했다.
Problem (아쉬운 점, 문제점)
- 백엔드도 처음 배울 뿐만아니라 SSE Streaming도 처음해서 백엔드와 연동 과정에서 어려움이 있었다.
- 로깅을 조금만 더 빨리 도입했다면 일정을 더 줄일 수 있었을 것 같다. 다음부턴 개발보다 로깅을 먼저 구현해둬야겠다.
- AI를 활용하여 코딩을 하다보니 내가 구현한 코드에 대한 이해도가 부족하다.
Try (시도할 점)
- 다양한 기술을 도입할 땐 구현 방법보단 그 원리에 대해서 이해하고 도입해야겠다.
- 일정을 좀 더 촘촘하게 짜야겠다.
- 다양한 정보가 들어올 때 모든 걸 다 해보는 것 보다 우선 순위를 정하는 것이 중요할 것 같다.
neon.ahn(안혜원)/풀스택(Frontend)
프로젝트 개요
캘린더, 투두리스트, 챗봇(AI), 마이페이지(프로필) 기능을 구현했으며, 전반적인 UI도 함께 개선했다.
Keep (잘한 점, 유지할 점)
- 일정 지연 없이 계획대로 기능 구현을 완료했다.
- 큰 기능을 작은 단위로 쪼개 커밋/PR 단위로 진행해 병목을 줄였다.
- 우선순위를 명확히 두고 완료 기준을 지켰다.
- 핵심 기능을 먼저 개발한 뒤, UI/UX 개선을 추가 작업으로 분리했다.
Problem (아쉬운 점, 문제점)
- 일정에 쫓겨 문서화를 충분히 남기지 못한 점이 아쉽다.
- 결과적으로 코드 작성 의사결정 근거가 빈약한 점이 아쉽다.
Try (시도할 점)
- V2에서는 사용한 코드와 기술의 동작 원리를 충분히 이해한 상태에서 구현하겠다.
- 리팩토링/성능 개선 시에는 문제 상황, 개선 근거와 기대 효과를 명확히 정리한 뒤, 그 내용을 문서로 남기면서 진행하겠다
yun.jeon(전윤철)/풀스택(Backend)
주요 기능으로 Spring Security + Google OAuth2 기반 인증/인가, 회원 도메인, AI 챗봇 도메인, 알림 도메인, 캘린더 및 To-do 도메인을 개발했다.
프로젝트 개요
Keep (잘한 점, 유지할 점)
- MVP 단계에서부터 처음 사용해보는 기술 스택이 많았으나 예전에 비해 두려움이 사라진 것 같다. AI의 도움을 받아서 그런 것도 있겠지만 긍정적인 마인드셋인 것 같다.
- OAuth2 활용 회원가입 플로우가 조금 복잡하게 느껴졌지만 시퀀스 다이어그램 등의 보조 자료를 활용해 이해를 가져가니 좀 더 수월하게 구현할 수 있었다.
- FastAPI 서버와의 연동 중 생겼던 이슈들을 해결하는 과정에서 로깅의 중요성을 깨달을 수 있었다. 그와 관련하여 Log Injection이라는 새로운 개념도 알게 되었고, 로그로부터 발생할 수 있는 보안 취약점에 대해서도 생각해볼 수 있었다.
Problem (아쉬운 점, 문제점)
- SSE Streaming(Spring Webflux)을 구현하는 과정에서 기본적인 이해가 전무한 상태에서 진행하려니 너무 힘들었다. 배포 일정을 맞춰야 한다는 생각에 AI의 도움을 많이 받아 구현했는데, 디버깅도 어려워지고 로직 플로우 추적도 힘들어지는 결과를 낳았다.
- 코드 작성의 근거가 상당히 빈약하다. ‘왜 이렇게 작성했는가?’라는 질문에 제대로 대답할 수 있는 부분이 많지 않다.
Try (시도할 점)
- 기능 구현에 사용해본 적 없는 기술 스택을 도입할 땐 항상 기본적인 동작 흐름을 정리하고 진행해야겠다. 로직의 기본 동작 흐름에 내가 적용하려는 기술이 어떻게 얹어지고, 어떤 트레이드 오프가 있는지 확실히 짚고 넘어가는 게 중요한 것 같다.
- 다음 스프린트부터는 기능 추가와 성능 개선(+리팩토링)을 병행해야 하는데, 특히나 성능 개선과 리팩토링을 위해서는 내가 작성한 코드의 근거를 필수적으로 숙지하고 있어야겠다.
- 트러블 슈팅 문서화가 다소 빈약한 부분이 있었는데 이 부분은 시간을 별도로 할애해서라도 잘 정리를 해두어야겠다.