4. 스프린트 2 리뷰 및 회고 - 100-hours-a-week/7-team-ddb-wiki GitHub Wiki

리뷰

리뷰 항목 내용 (시연 결과물) 담당자 피드백 개선 방향
[FE] 1단계: 기술 스택 선정 설계 문서 작성 1. Notion - 프론트엔드 기술 스택 설계 문서 2. Wiki - 프론트엔드 기술 스택 설계 문서 suzy 기술 하나를 선정할 때도 버전이나 연관 기술까지 함께 조사하면서 시간이 오래 걸린 느낌이 있었다. 주요 라이브러리 및 프레임워크의 최신 동향을 평소에도 꾸준히 모니터링하고, 관심 기술 목록을 만들어둘 것.
[FE] 2단계: 유저 플로우 차트 작성 1. draw.io - 유저 플로우 차트 2. Notion - 유저 플로우 차트 3. Wiki - 유저 플로우 차트 suzy 작성 자체는 오래 걸리지 않았지만, 기획 변경에 따라 유저 플로우를 수정하는 일이 있었다. 기획 단계에서 핵심 플로우를 충분히 논의하고 확정한 뒤 차트를 작성할 것.
[FE] 3단계: 프로젝트 도메인 테크스펙 작성 커뮤니티 도메인 유저 도메인 온보딩 도메인 공통 도메인 장소 도메인 suzy 도메인 구조를 충분히 고민해볼 수 있었고, 이 과정이 폴더 구조 설계에도 큰 도움이 됐다. 유저 도메인은 LLM의 도움을 받아 작성하기도 했다. LLM과 같은 도구는 적극 활용하되, 셀프 리뷰로 품질을 보장할 것.
[FE] 4단계: 프론트엔드 개발 표준 및 구조 설계 개발 표준 및 구조 설계 문서 suzy 전체적인 컨벤션, 코드 구조, SEO 전략 등 프로젝트 전반을 정리할 수 있었다. 다만, 디테일이 부족해서 진행하면서 수정 사항이 생길 수 있을 것 같다. 실제 코드 예시와 함께 표준을 문서화하고, 진행 중 발견되는 개선점을 위키나 노션에 즉시 반영하여 지속적으로 업데이트할 것.
[BE] 1단계: 기술 스택 선정 및 문서 작성 1. Notion - 백엔드 기술 스택 설계 문서 2. Wiki - 백엔드 기술 스택 설계 문서 ej 기능별로 어떤 기술을 활용할 것인지 기준을 세우고 조사한 점이 좋았다. 기술 스택 관련 사전 경험이 없던 부분도 많이 정리되었음. 기술 스택을 선택할 때 트레이드오프를 명확히 하고, 다른 팀원과 기술적 의사결정 과정도 함께 공유할 것.
[BE] 2단계: 유저 플로우 기반 API 설계 및 문서화 1. API 명세 문서 (Notion) 2. API 명세 문서 (Wiki) ej 도메인별로 나눠 설계가 잘 되어있고, 플로우에 맞게 API 구조를 고려한 점이 좋았다. 다만 실제 구현 시 일부 변경 가능성이 있음. Swagger 또는 Postman과 같은 도구로 API 시각화 및 검증을 병행하고, 실제 구현과 문서 싱크를 잘 맞출 것.
[BE] 3단계: 도메인 모델 및 ERD 설계 1. ERDcloud - ERD 2. Wiki - 도메인 모델 및 ERD 설계 문서 ej 주요 엔티티 간 관계, 속성 정의 등이 잘 정리되어 있었다. ERDcloud를 활용해 시각적으로 구조를 쉽게 파악할 수 있음. ERD와 실제 DB 스키마가 일치하도록 지속적인 점검 필요. 변경 사항 발생 시 문서 및 DB 동기화에 주의할 것.
[BE] 4단계: 서버 구조 및 코드 컨벤션 설계 Notion - 서버 구조 및 컨벤션 문서 ej 폴더 구조, 네이밍 컨벤션, 계층 분리 등 기본적인 백엔드 구조 설계가 잘 되어 있었다. 실제 구현에 유연하게 적용 가능할 듯. 예외 처리, 로깅, 인증 관련 공통 모듈 설계도 함께 포함하면 더 견고한 구조가 될 것. 이후 팀 내 공유로 일관된 코드 작성 기대.
[CLOUD] 1단계: Big Bang 방식 수작업 배포 설계 https://github.com/100-hours-a-week/7-team-ddb-wiki/wiki/%E2%98%81%EF%B8%8F-1%EB%8B%A8%EA%B3%84-:-Big-Bang-%EB%B0%A9%EC%8B%9D-%EC%88%98%EC%9E%91%EC%97%85-%EB%B0%B0%ED%8F%AC lily, peter 전반적인 설계 단계에서 왜 사용해야 하는지 이유가 부족한 것 같다. 실제 개발을 진행하면서 직접 겪어보고 다시 이유를 생각해보기
[CLOUD] 2단계: CI(지속적 통합) 파이프라인 구축 설계 https://github.com/100-hours-a-week/7-team-ddb-wiki/wiki/%E2%98%81%EF%B8%8F-2%EB%8B%A8%EA%B3%84-:-CI-%ED%8C%8C%EC%9D%B4%ED%94%84%EB%9D%BC%EC%9D%B8-%EA%B5%AC%EC%B6%95-%EC%84%A4%EA%B3%84 lily, peter CI 파이프라인 구축 설계가 Jenkins 기반으로 되었는데 세부 단계에 대한 구체성이 부족해 실제 구현 시 혼선이 생길 우려가 있다. 각 단계의 세부 프로세스를 문서화를 꼼꼼하게 하고 CI 실패 처리를 보다 완벽하게 해야한다.
[CLOUD] 3단계: CD(지속적 배포) 파이프라인 구축 https://github.com/100-hours-a-week/7-team-ddb-wiki/wiki/%E2%98%81%EF%B8%8F-3%EB%8B%A8%EA%B3%84-:-CD-%ED%8C%8C%EC%9D%B4%ED%94%84%EB%9D%BC%EC%9D%B8-%EA%B5%AC%EC%B6%95 lily, peter CD 파이프라인 구축이 CI 이후 이어지는 흐름으로 자연스럽게 설계된 점은 좋다. 하지만 배포 전략과 롤링 프로세스 및 스크립트가 명확하지 않다. 각 단계의 세부 프로세스를 문서화를 꼼꼼하게 하고 CD 실패 처리를 보다 완벽하게 해야한다.
[CLOUD] 4단계: Docker 컨테이너화 배포 https://github.com/100-hours-a-week/7-team-ddb-wiki/wiki/%E2%98%81%EF%B8%8F-4%EB%8B%A8%EA%B3%84:-Docker-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88%ED%99%94-%EB%B0%B0%ED%8F%AC lily GCP, 모니터링 도구에 대해 더 깊은 이해가 필요한 것 같다. AI와 벡터 db는 어떻게 올릴지 다시 고민해보아야 할 것 같다. 도구에 대한 탐구
[CLOUD] 5단계: Kubeadm 오케스트레이션 https://github.com/100-hours-a-week/7-team-ddb-wiki/wiki/%E2%98%81%EF%B8%8F-5%EB%8B%A8%EA%B3%84:-Kubeadm-%EC%98%A4%EC%BC%80%EC%8A%A4%ED%8A%B8%EB%A0%88%EC%9D%B4%EC%85%98 peter 매일 인프라 구축을 자동화해야하는데, kuberntes cluster 구축을 스크립트화 해야하는데 트러블 슈팅이 많을 것같다. 스크립팅 공부
[AI] 1단계 : 모델 API 설계 1단계 : 모델 API 설계 juny 처음 작성했던 내용은 API 명세서보다 기능 흐름도에 가까울 정도로 이해도가 적었음 피드백을 통해 바로잡으며 API 명세서에 대한 이해를 많이 한 것 같음, 다음에는 용도에 맞게 깔끔하게 작성할 수 있도록 하자
[AI] 2단계 : 모델 추론 성능 최적화 2단계 : 모델 추론 성능 최적화 juny 기존에는 모델 선정 시 성능, 최근에 나온 것 들을 최우선으로 생각했던 것 같고, 메모리, 추론 시간 등의 소요 비용은 고려하지 못했던 것 같음 단순한 성능 뿐 아니라 다양한 수치들을 비교하며 적절한 모델을 선정하는 작업의 중요성을 크게 느낌. 심지어 성능을 낮추면서 다른 수치를 높여야 할 상황도 많기에 다음에는 더 많은 모델을 비교해보고 합리적인 선택을 할 수 있도록 하자
[AI] 3단계 : 서비스 아키텍처 모듈화 3단계 : 서비스 아키텍처 모듈화 jensen 아키텍쳐를 처음 구성하다 보니 어려움이 많았고 모듈화 작업이 헷갈렸다   프로젝트 모듈 구조를 이해하며 사용하는 방법을 익혁으니 앞으로도 모듈화를 잘 할수 있도록 해야겠다
[AI] 4단계 : LangChain 기반 멀티스텝 AI 구현 검토 4단계 : LangChain 기반 멀티스텝 AI 구현 검토 juny 기존에는 서비스의 규모, 종류에 상관 없이 최신 기술들을 무조건 도입해야 한다 생각했음. 기술 자체의 도입을 검토하는 과정을 거치면서 이 기술이 현재 기술 흐름에 적합한지, 어떻게 도입하는 것이 옳은 방향인지 고려해보도록 하자
[AI] 5단계 : RAG 도입 가능성 점검 5단계 : RAG 도입 가능성 점검 jensen 왜 사용하지 않는지 그리고 이를 대체하기 위해 어떻게 진행하는지 고려해보며 기술을 선정하였다.  프로젝트 진행에 있어 사용에 적합한지 고려하기
[AI] 6단계 : MCP 도입 가능성 점검 6단계 : MCP 도입 가능성 점검 jensen  최신 기술이지만 프로젝트와 맞지 않아 제외 프로젝트 진행에 있어 사용에 적합한지 고려하기 
[AI] 7단계 : 서비스 인프라 확장성과 모니터링 설계 7단계 : 서비스 인프라 확장성과 모니터링 설계 juny AI 연구만 하면서 한번도 접하지 못했던 분야이고, 몰랐던 부분이 정말 많았다는 생각을 했음. 개발자가 되려면 전체 아키텍처에 대한 이해는 필수라고 생각함. 내가 직접 그려보고, 이미 그려져 있다면 구조를 한번씩 파악해보도록 하자
[AI] 8단계 : 최종 통합 설계 및 회고 8단계 : 최종 통합 설계 및 회고 jensen  지금까지 진행했던 설계를 통합하고 진행과정에서 변경된 내용들을 반영하여 최종 설계문서를 작성하였다.  프로젝트 설계를 진행할 때는 여러 고려사항을 잘 논의하고 확실한 구조를 설계하도록 하자

회고

suzy.kang (강수지) /풀스택

KPT 분류 설명
Keep (유지할 항목) 일정 맞추려고 노력하는 자세. 반복되는 일은 자동화하고 애자일하게 작업하고자 하는 노력. 평일에 남아서 공부하고자 하는 노력
Problem (문제점) 멍 때리는 시간, 주말에 공부 시간이 부족함
Try (시도할 것) 평일에 공부할 때 빠짝 집중하기, 주말 최대한 활용하기

eric.choi(최진우)/풀스택

KPT 분류 설명
Keep (유지할 항목) 일정에 최대한 맞추려고 노력하는 자세
Problem (문제점) 혼자서 고민해서 오래 시간 끄는 문제점
Try (시도할 것) 팀원들과 바로바로 소통

juny.lee(이현준)/인공지능

KPT 분류 설명
Keep (유지할 항목) 진행 사항 정리해서 문서화. 추후 진행 사항에 대해 계획을 세우는 것
Problem (문제점) 체력, 집중력 부족. 주말 시간 활용 능력 부족
Try (시도할 것) 쉴 때 확실히 쉬고 시간 낭비 하지 않기. 팀원들과 효율적으로 자주 소통하기

jensen.hwang(황찬희)/인공지능

KPT 분류 설명
Keep (유지할 항목) 교육장에 오래 있기, 잠꺠려고 노력하기, 운동 꾸준히 하기
Problem (문제점) 집중력 저하, 체력, 멘탈관리
Try (시도할 것) 휴대폰 보지 않기, 작업 계획세워서 진행하기

peter.kang(강동석)/클라우드

KPT 분류 설명
Keep (유지할 항목) 평일, 주말 교육장에 최대한 남아 있어려는자세.커뮤니케이션 노력.끊임없이 고민하는 자세.
Problem (문제점) 깊은 고민에 빠져 쓸데없는 생각까지 이어지는 것.밤에 커피먹어 수면부족으로 이어지는 것.고민한 내용을 따로 적지 않아 다음 똑같은 고민을 다시 한다는 것.
Try (시도할 것) 내가 고민할 영역을 명확히 할것.카페인 섭취 줄여서 컨디션 유지.글쓰기 연습.

lily.shin(신지영)/클라우드

KPT 분류 설명
Keep (유지할 항목) 평일에 매일 남아 작업하는 점. 계획을 세우고 실천하는 자세
Problem (문제점) 궁금해 하지 않는 점. 수면 부족
Try (시도할 것) 주말 중 하루라도 공부 시간 확보하기. 습관적으로 왜?라는 질문을 하면서 진행하기
⚠️ **GitHub.com Fallback** ⚠️