알게 된 점
- 아키텍처란?
코드의 큰 그림이자, 팀 전체가 공유해야 할 변경 난이도 높은 의사결정의 집합임을 실감했다.
- 속도가 느려지는 원인
프로젝트가 커질수록 구조적 부채가 누적되고, 설계 원칙과 패턴을 활용해야 유지보수가 수월해진다.
- SOLID & TDD
‘유지보수하기 쉬운 구조’를 위한 최소 단위 습관이다. 원칙을 인지하고 적용해야 의미가 있다는 점을 배웠다.
- 아키텍처 진화
Layered → Hexagonal → Clean 아키텍처로 갈수록 도메인 독립성이 높아지고, 테스트와 확장 편의성도 함께 커진다.
현실적으로는 기존 구조(Layered) 위에 Clean 원칙을 점진적으로 도입하는 리팩터링 전략이 많이 쓰인다.
SOLID
- SRP : 한 클래스는 하나의 이유로만 변경해야 한다.
- OCP : 기존 코드 변경 없이 확장이 가능해야 한다.
- LSP : 구현체가 인터페이스 규약을 지켜야 다형성이 유지된다.
- ISP : 한 클래스가 자신과 무관한 메서드들까지 가진 커다란 인터페이스를 구현하지 않도록 한다.
- DIP : 상위 모듈은 구체 구현이 아니라추상에 의존해야 테스트가 쉬워진다.
TDD 설계
| 단계 |
설계 신호 |
도입된 패턴/원칙 |
| Red |
가짜 객체 필요 |
DIP (인터페이스 추출) |
| Green |
테스트 격리 OK |
DI / SRP |
| Refactor |
확장성 확보 |
OCP / LSP / ISP |
아키텍처 패턴
| 패턴 |
설명 |
적용 예시 |
| Layered |
Controller → Service → Repository 단방향 의존 |
소규모 팀 / CRUD |
| Hexagonal |
도메인 중심 육각형, 포트/어댑터구조 |
멀티 인터페이스, 도메인 공유 서비스 |
| Clean |
의존성 역전, 추상계층 극대화 |
멀티모듈 대규모 서비스 |
실습: 콘서트 목록 조회 기능 구현 PR
이번 강의를 바탕으로 GitHub PR #3을 콘서트 목록 조회 기능을 구현했다.
- Concert, ConcertDate 엔티티 및 JPA 레포지토리 구현
- 콘서트 목록/공연 날짜 조회 API 및 단위 테스트 추가
- BaseTimeEntity 생성, JPA Auditing 적용
- DTO 및 패키지 구조 정비, 서비스·레포지토리 테스트 코드 보완
고민
- 테스트 코드 작성과 리팩토링:
Mock 객체 생성, 테스트 데이터 중복이 반복되었다.
- 계층별 테스트 책임:
컨트롤러/서비스/레포지토리/통합 테스트 경계가 여전히 헷갈렸다.
- 커밋/PR 관리:
서비스와 테스트 코드를 한 번에 리팩터링 할 때, 커밋을 어떻게 쪼갤지 많이 고민했다.
받은 피드백 요약
- Mock 반복/테스트 데이터 생성: Mockito 어노테이션, Builder/Fixture 활용 추천
- 계층별 테스트: 컨트롤러는 서비스 모킹 후 입출력 검증, 통합테스트는 실제 객체로 연동 검증
- 커밋: 파일 단위가 아닌 기능/변경 단위로 쪼개기 권장
회고
- 실제 코드를 짜며 ‘불편함’을 겪어보니 SOLID, TDD, 계층별 책임 구분의 중요성을 알게되었다.
- 테스트 데이터 중복 제거(Buider/Fixture 활용), 커밋/PR 단위 쪼개기, 도메인 중심 설계와 레이어 분리를 실천해 볼 계획이다.
- 기존 구조를 한 번에 바꾸기보다, 복잡하고 핵심적인 모듈부터 점진적으로 클린 아키텍처를 적용해 나갈 계획이다.