✍️Dev log - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki
"기록하지 않으면 경험은 사라지지만, 기록하면 자산이 됩니다." 이 공간은 우리 팀의 기술적 고민, 트러블 슈팅, 학습 내용을 블로그 형식으로 자유롭게 공유하는 공간입니다.
| 아이콘 | 카테고리 | 설명 |
|---|---|---|
| 📅 | Sprint Plan | 스프린트 일정 및 플래닝 포커 (업무 난이도 산정) |
| 🐞 | Troubleshooting | 개발 중 발생한 에러와 해결 과정을 기록 (How to fix) |
| 🏗️ | Tech Decision | 기술 스택 선정, 아키텍처 설계 등 중요한 의사결정 기록 (ADR) |
| 🚀 | Retrospective | 스프린트 종료 후 회고, KPT(Keep/Problem/Try) 기록 |
(작성된 위키 페이지들을 아래 테이블에 리스트업 해주세요)
| 날짜 | 카테고리 | 제목 | 작성자 | 태그 |
|---|---|---|---|---|
| 2026.01.03 | 📅 Plan | [Sprint 1] 초기 배포 및 로그인 구현 계획 | [Team] | #Planning |
| 2026.01.03 | 🐞 Trouble | [Backend] N+1 문제 해결 및 QueryDSL 도입기 | [홍길동] |
#JPA #Performance
|
| 2026.01.02 | 🏗️ Decision | [Infra] 왜 우리는 EC2 대신 ECS를 선택하지 않았나? | [김철수] |
#AWS #Cost
|
| 2026.01.01 | 🚀 Retro | [Sprint 1] 설계 스프린트 회고 | [Team] | #Retrospective |
새로운 글을 작성할 때는 글의 성격에 맞는 템플릿을 복사하여 사용해 주세요.
템플릿 1: 📅 스프린트 계획 (Sprint Planning)
작성 Tip: 작업일수는 현실적으로 산정하고, 플래닝 포인트의 **'이유'**는 기술적 근거를 바탕으로 작성합니다.
## 스프린트 작업일수
| 스프린트 이름 | 날짜 | 작업일수 | 비고 |
|-------------------------|-------------------------------------|----------|------|
| 스프린트 1 플래닝 | 2099년 00월 00일 | 0 | |
| 스프린트 1 | 2099년 00월 00일 → 2099년 00월 00일 | 0 | |
| 스프린트 1 리뷰&회고 | 2099년 00월 00일 | 0 | |
| 스프린트 2 플래닝 | 2099년 00월 00일 | 0 | |
| 스프린트 2 | 2099년 00월 00일 → 2099년 00월 00일 | 0 | |
| 스프린트 2 리뷰&회고 | 2099년 00월 00일 | 0 | |
| 스프린트 3 플래닝 | 2099년 00월 00일 | 0 | |
| 스프린트 3 | 2099년 00월 00일 → 2099년 00월 00일 | 0 | |
| 스프린트 3 리뷰&회고 | 2099년 00월 00일 | 0 | |
| 스프린트 4 플래닝 | 2099년 00월 00일 | 0 | |
| 스프린트 4 | 2099년 00월 00일 → 2099년 00월 00일 | 0 | |
| 스프린트 4 리뷰&회고 | 2099년 00월 00일 | 0 | |
| 스프린트 5 플래닝 | 2099년 00월 00일 | 0 | |
| 스프린트 5 | 2099년 00월 00일 → 2099년 00월 00일 | 0 | |
| 스프린트 5 리뷰&회고 | 2099년 00월 00일 | 0 | |
**합계 작업일수: 0일**
<br />
## 스프린트 플래닝 포커 카드
| 스프린트 | 우선순위 | 업무명 | 플래닝 포인트 | 담당자 | 이유 |
|----------|-----------|----------------------------|----------------|--------|------|
| 1 | 1 | [업무 내용을 작성하세요] | 0 | [이름] | [업무 난이도 또는 범위 설명] |
| 1 | 2 | [업무 내용을 작성하세요] | 0 | [이름] | [업무 난이도 또는 범위 설명] |
| 1 | 3 | [업무 내용을 작성하세요] | 0 | [이름] | [업무 난이도 또는 범위 설명] |
| 1 | 4 | [업무 내용을 작성하세요] | 0 | [이름] | [업무 난이도 또는 범위 설명] |
**플래닝 포인트: 0**작성 Tip: 에러 로그만 올리지 말고, **"원인 분석"**과 **"해결 과정"**을 논리적으로 적습니다.
# 🐞 [Trouble] 에러 메시지 또는 현상 요약
### 1. 문제 상황 (Problem Context)
* **발생 일시:** YYYY.MM.DD
* **환경:** (예: Local, Prod / Spring Boot 3.0)
* **현상:** (예: 회원가입 시 DB Duplicate Error 발생)
* **에러 로그:** `java.sql.SQLIntegrityConstraintViolationException...`
### 2. 원인 분석 (Root Cause Analysis)
* **가설:** 중복된 이메일로 가입 시도 시 예외 처리가 누락됨.
* **검증:** 로그 확인 결과 Unique Index 위반 확인.
* **최종 원인:** Controller에서 `DataIntegrityViolationException` 미처리.
### 3. 해결 방법 (Solution)
* **시도:** `@ExceptionHandler`를 사용하여 전역 예외 처리 적용.
* **결과:** 409 Conflict 상태 코드와 명확한 에러 메시지 반환 성공.
### 4. 배운 점 (Insights)
* 예외 처리는 개별 메서드보다 Global Handler로 관리하는 것이 효율적이다.작성 Tip: **"왜(Why)"**를 중심으로 주장-논리-근거를 갖춰 작성합니다. 트레이드오프(Trade-off) 필수!
# 🏗️ [Decision] 주제 (예: 상태 관리 라이브러리로 Recoil 선정)
### 1. 배경 및 요구사항 (Context)
* Props Drilling 문제 해결 필요.
* 팀원들이 Redux의 보일러 플레이트를 부담스러워함.
### 2. 대안 비교 (Alternatives)
| 후보 | 장점 | 단점 |
| :--- | :--- | :--- |
| **Redux** | 생태계 큼, 디버깅 강력 | 코드 복잡도 높음, 학습 비용 큼 |
| **Recoil** | React 스러운 문법, 가벼움 | 레퍼런스 적음 |
### 3. 결정 사항 (Decision)
* **결정:** **Recoil** 도입.
* **이유:**
1. 짧은 개발 기간(2주) 고려 시 학습 비용 최소화 필요.
2. `Atom` 개념이 `useState`와 유사하여 팀원 적응 용이.
### 4. 트레이드오프 (Consequences)
* **Risk:** 실험적 기능이라 버그 가능성 있음 → 문제 시 Context API로 전환 계획 수립.작성 Tip: 감상문이 아니라 **"Action Item(다음엔 어떻게 할 것인가)"**을 도출합니다. 이슈로 작성된 스프린트 회고를 모아서 스프린트 종료 후 글로 작성합니다.
# 🚀 [Sprint N] OO기능 개발 회고
### 1. 요약
* **기간:** YYYY.MM.DD ~ YYYY.MM.DD
* **목표 달성률:** 90%
### 2. KPT 회고
#### 🔥 Keep (좋았던 점)
* 데일리 스크럼을 통해 이슈 공유가 빨랐음.
#### 💦 Problem (문제점)
* 배포 자동화가 안 되어 수동 배포에 시간 소요.
#### 🏃 Try (Action Item)
* [Infra] 이번 주 내로 GitHub Actions 구축하기 (담당: OOO)
### 3. 총평
* 개발 속도는 좋았으나 인프라 개선이 시급함.