우아한테크코스 프리코스 8기 2주차 회고

1주 차를 돌아보며

1주 차에는 TDD를 이해하고, ‘작게 쪼개며 점진적으로 나아가는 리듬’을 몸에 익히는 데 집중했다. 문제를 세분화하고 하나씩 해결해 나가는 흐름이 내 경험과 잘 맞았고, 덕분에 TDD를 더 깊이 탐구하고 싶다는 생각이 들었다.

켄트 벡의 『테스트 주도 개발』을 읽으면서 한 가지를 강하게 느꼈다. TDD는 처음부터 아키텍처를 완성해놓고 시작하는 방식이 아니라,

“작동하게 만들고 → 테스트로 안정화하고 → 리팩터링으로 구조를 다듬는”
흐름으로 성장하는 개발 방식이라는 점이다.

 

반면 나는 1주 차에 UML을 먼저 그리고 객체 관계를 설정한 뒤 테스트를 작성하는 방식을 습관처럼 사용했다. 돌이켜보면, 그건 반쪽짜리 TDD였다. 그래서 이번 2주 차에는 마음을 완전히 고쳐먹었다. 설계를 미루고, 백지에서 테스트로 길을 찾아가는 ‘진짜 TDD’에 도전하기로 했다.

---

이번 주 개발 과정에서 배운 점

1. 검증의 책임

“들어온 값이 올바른 값인가?”라는 주제는 1주 차부터 끊임없이 논쟁이 되었던 부분이다. 도메인에 두면 객체가 너무 커지고, Validator 등 다른 곳에 두면 응집도가 떨어지는 문제 때문이었다.

결국 나는 결론을 내렸다.

“검증의 성격에 따라 책임의 위치가 달라진다.”

예를 들어 자동차 이름 검증을 보면, 이름이 5자 이하인지 확인하는 것은 도메인의 책임이다. 즉, Car 객체가 스스로 지켜야 하는 불변 조건이다. 반면 입력 문자열이 올바르게 파싱될 수 있는지는 입력 계층의 책임이다.
이 구분을 통해 객체가 스스로의 책임을 지도록 만드는 설계 기준을 명확히 이해하게 되었다.

2. 외부 의존성

2주 차 미션에서 Randoms.pickNumberInRange() 메소드를 사용해 값이 4 이상일 때 자동차가 이동하도록 하는 요구사항이 있었다. 테스트가 어려웠던 이유는 랜덤 로직이 클래스 내부에 직접 포함되어 있었기 때문이다.

해결책은 전략 패턴을 적용해 랜덤 로직을 외부 의존성으로 분리하는 것이었다.

• 자동차 이동 여부 판단을 MoveStrategy 인터페이스로 분리
• 실제 랜덤 로직은 RandomMoveStrategy로 구현
• 테스트 시 람다 () -> true를 사용해 원하는 결과를 검증

이를 통해 결합도를 낮추고, “테스트 가능한 코드가 곧 좋은 설계”라는 TDD 철학을 몸으로 이해할 수 있었다.
전략패턴이 런타임에 결정되어야 진짜 전략패턴이 아닌가? 라는 피드백도 들어왔지만 커뮤니티엣 GoF원문을 찾아본 결과 그런건 상관없다 라는 결론이 나왔다!

---

아쉬웠던 점

1주 차 코드 리뷰를 받고 느낀 점은, 내가 무의식적으로 의미 없는 네이밍이나 구조를 사용했다는 것이다. 예를 들어 addition 같은 메서드명은 명확하지 않았다. 2주 차부터는 의도적으로 네이밍과 구조를 고민하며 개선하려고 노력했다.

받은 피드백중 하나인데 getter를 일급 컬렉션에 썼을때 불변으로 반환 안한것이다.

1주차땐 이걸 해놓고 2주차때 까먹어서 아쉬웠다.

 

또, 일급 컬렉션과 VO(Value Object)의 구분이 여전히 헷갈린다. 값 객체가 컬렉션을 가질 경우 등, 모호한 상황에 대한 이해를 앞으로 더 깊게 탐구하고 싶다.

코드 외적으로는, 켄트 벡의 책을 2주 차 내에 끝내겠다는 목표를 달성하지 못했다. 바쁘다는 핑계였지만, 3주 차 전까지는 반드시 완독하려 한다.

---

다음 주에 도전하고 싶은 점

다음 주에는 더 읽기 좋은 코드를 작성하고 싶다. 『클린 코드』를 읽고 코드 리뷰를 하면서 깨달은 점은, 좋은 코드는 나만 이해하기 쉬운 코드가 아니라, 읽는 사람에게 의도가 자연스럽게 전달되는 코드라는 것이다.

또한, 응용 서비스(Application Service) 레이어 도입을 시도하고 싶다. 프로젝트가 복잡해지면서 하나의 컨트롤러가 여러 도메인을 동시에 제어해야 하는 상황이 생길 수 있기 때문이다. 이번 주차 경험을 통해, 도메인 간 협력을 조율하는 별도의 응용 서비스 계층이 필요함을 느꼈다.

앞으로는 컨트롤러가 도메인 객체에 직접 위임하기보다, 응용 서비스가 역할을 조합하여 하나의 기능을 완성하는 구조를 고려하고자 한다.