Week 12
기간: 2026.02.02 - 2026.02.06
커리큘럼: 백엔드(Spring)
1. Facts — 무엇을 했나?
< Spring >
- [Spring] JWT 리프레시 토큰 도입: Redis로 RT 관리
Access Token의 짧은 만료 전략과 Refresh Token을 Redis에 저장해 무효화/관리 가능성을 확보하는 방식으로 인증 구조를 개선한 내용을 정리했다. - [Spring] SSE + Redis Pub/Sub로 멀티서버 알림 구현하기
SSE 기반 실시간 알림을 구현하고, 멀티 서버 환경에서 Redis Pub/Sub으로 알림 이벤트를 공유해 스케일 아웃 구조에서도 동작하게 만든 과정을 정리했다. - [Spring] JMeter로 동시성 성능 테스트
JMeter로 동시 요청을 발생시켜 응답 시간/처리량/성공 여부 지표를 보며 시스템 성능을 점검하는 테스트 흐름을 정리했다. - [Spring] Swagger(SpringDoc) : API 문서화 + Swagger UI 로그인 테스트
SpringDoc 기반으로 API 문서를 구성하고, Swagger UI에서 인증이 필요한 API를 로그인 흐름과 함께 테스트하는 방법을 정리했다. - [Spring] 동시성 이슈 해결 : Redis, RabbitMQ 활용 (JMeter를 통한 Throughput 비교)
동시성 문제의 원인을 정리하고, Redis/RabbitMQ 등으로 해결을 시도한 뒤 JMeter로 처리량(Throughput)을 비교하는 방식으로 접근 과정을 기록했다. - [Spring] 게시판 프로젝트 : 아키텍처/인증 비교 (RESTful vs MVC, Token vs Session)
게시판 프로젝트를 진행하며 RESTful과 MVC의 흐름 차이, 그리고 Token 기반 인증과 Session 기반 인증의 구조적 차이를 비교 관점으로 정리했다. - [Spring] TDD : JUnit으로 단위 테스트와 통합 테스트 정리
TDD 개념을 기준으로 단위 테스트/통합 테스트를 구분하고,@SpringBootTest,@Transactional,@DataJpaTest, Given-When-Then 패턴과 실습 코드로 테스트 작성 흐름을 정리했다.
2. Feelings — 어떻게 느꼈나?
- 테스트를 “나중에 하는 일”이 아니라 “설계의 시작점”으로 두고 나니, 구현 전에 요구사항이 정리되는 느낌이 확실히 들었다.
@SpringBootTest + @Transactional로 실습 코드를 돌려보면서, 테스트가 끝나면 DB가 롤백되어 다음 테스트에 영향을 주지 않는 흐름이 생각보다 든든하게 느껴졌다.- IntelliJ에서 클래스 단위/메서드 단위로 빠르게 실행해보니, 작은 피드백 루프가 쌓이면서 개발 리듬이 좋아진다는 걸 체감했다.
- 테스트가 실패했을 때 “왜 틀렸는지”가 assert와 스택트레이스로 바로 드러나는 경험을 하면서, 디버깅이 감이 아니라 근거 중심으로 바뀐다는 느낌을 받았다.
3. Findings — 무엇을 배웠나?
-
TDD & 테스트 설계:
- 테스트를 먼저 쓰면 기능 요구사항이 문장 → 검증 코드 형태로 구체화되면서, 구현 방향이 덜 흔들린다.
- Given-When-Then 구조를 유지하면 테스트가 “준비/실행/검증”으로 분리돼 의도가 명확해지고, 유지보수할 때도 읽기 쉽다.
- 단위 테스트/통합 테스트를 구분해 목적(빠른 검증 vs 전체 흐름 검증)에 맞는 범위를 선택하는 게 핵심이다.
-
Spring 테스트 전략:
- Repository 테스트는
@DataJpaTest로 필요한 JPA 설정만 가볍게 로드해 빠르게 검증할 수 있고, 경우에 따라@SpringBootTest로 더 넓은 범위를 검증할 수도 있다. - Service 테스트는 서비스 로직을 중심으로 검증하되, 트랜잭션 롤백 전략을 가져가면 테스트 간 데이터 간섭을 크게 줄일 수 있다.
- 통합 테스트에서는 클래스 단위 실행 시 메서드 간 의존성이 생기기 쉬워서, 데이터 정리(
@AfterEach)나 독립적인 셋업이 중요하다.
- Repository 테스트는
-
IntelliJ 실행 & 결과 해석:
- 클래스 단위 실행은 “전체 흐름이 깨지지 않는지”를 빠르게 확인하는 용도에 좋고, 메서드 단위 실행은 “지금 수정한 포인트만” 즉시 검증할 때 효율적이다.
- 성공(Passed)은 기대 조건이 모두 만족된 상태이고, 실패(Failed)는 assert 불일치처럼 “검증이 깨진 상태”, 에러(Error)는 예외 등으로 “실행 자체가 깨진 상태”로 구분해서 보면 원인 파악이 빨라진다.
4. Future — 다음에 어떻게 활용할까?
- 기능 추가/수정이 들어올 때, 먼저 “어떤 입력에서 어떤 결과가 나와야 하는지”를 테스트로 고정한 뒤 구현을 진행해 변경에 강한 개발 흐름을 만들기.
- Controller는 MockMvc 기반의 계층 테스트로 요청/응답 계약을 안정화하고, Service/Repository는 롤백 전략을 활용해 반복 실행 가능한 테스트 환경을 유지하기.
- 통합 테스트는 핵심 시나리오 위주로 최소화하고, 나머지는 단위 테스트로 촘촘히 커버해서 실행 속도와 신뢰도를 함께 가져가기.
- IntelliJ에서 메서드 단위 실행으로 빠르게 확인 → 클래스 단위 실행으로 회귀(regression) 체크하는 루틴을 습관화하기.
🧩 마무리 한 줄
테스트를 먼저 쓰는 습관을 붙이면서 “구현”이 아니라 “검증 가능한 설계”로 개발 관점이 바뀌었다.
IntelliJ의 빠른 실행/결과 확인까지 합쳐지니, 작은 실패를 빨리 발견하고 안정적으로 고치는 개발 사이클이 만들어졌다.
Eazy하게