[우아한 테크코스 8기] 3주차 프리코스 회고

3주차 미션: Lotto

 

3주차 로또 미션은 이전 미션들보다 훨씬 복잡한 구조를 가지면서, 책임을 어디에 둘 것인가 에 대한 고민을 많이 했던것 같습니다.

 

 

리드미에 기능을 모두 정리한 후, 기능 단위 커밋을 진행했습니다.

 

 

1. 생성 책임의 위치

 

로또 번호를 생성하는 책임을 어디에 둘지 가장 많이 고민했습니다.
Lotto는 값 객체로, 이미 생성된 번호를 받아서 검증하고 보관하는 역할에 충실해야 한다고 판단했습니다.
따라서 로또 번호 생성 책임은 Lottos에서 담당하도록 분리했습니다.
Lottos는 사용자가 구입한 여러 장의 로또를 관리하며, 내부적으로 각 Lotto 객체를 생성하는 책임을 가집니다.
이렇게 역할을 분리하니 Lotto는 불변 객체로 유지할 수 있었고, 테스트 역시 훨씬 수월해졌습니다.

 

2. 등수와 당첨금의 관리

로또 결과를 관리하는 과정에서 등수와 당첨금을 별도의 enum으로 관리하는 것이 유지보수에 유리하다고 판단했습니다.
Rank enum을 통해 각 등수에 해당하는 일치 개수와 상금을 명확하게 표현하고, 이를 기반으로 수익률을 계산했습니다.
이 과정에서 enum이 단순한 상수 집합이 아니라, 로직을 함께 가지는 유용한 객체가 될 수 있다는 점을 다시 느꼈습니다.

 

3. 로또 결과 계산 구조

LottoWin 클래스는 당첨 번호를 기준으로 각 로또를 비교하여 결과를 반환하도록 설계했습니다.
처음에는 비교 로직을 Lottos 내부에 두었지만, 이는 도메인의 책임이 혼재된다는 판단 하에 LottoWin으로 분리했습니다.
결과적으로 LottoWin은 결과 집계에만 집중하고, LottoRank에서 등수 계산 및 수익률 계산을 담당하도록 역할을 세분화했습니다.
이 과정을 통해 “책임을 분리한다는 것”이 단순히 클래스를 늘리는 것이 아니라, 의도를 명확히 표현하는 설계 행위라는 점을 느낄 수 있었습니다.

 

4. 서비스 계층에 대한 고민

도메인 설계 이후, LottoService를 별도로 두는 것이 적절한지 고민했습니다.
도메인 내부에서 이미 대부분의 비즈니스 로직이 처리되고 있어, 현재 구조에서는 컨트롤러가 게임의 흐름을 관리하고 도메인이 실질적인 로직을 수행하는 형태로도 충분하다고 판단했습니다.
하지만 규모가 커지거나 외부 API 연동이 추가된다면, 서비스 계층을 두어 도메인과 어플리케이션 로직을 분리하는 방향이 바람직할 것 같다는 생각을 했습니다.

 

5. 복잡성이 높아질수록 느낀 점

이전 미션보다 훨씬 복잡한 구조를 설계하다 보니, 클래스 간 의존 관계와 책임의 경계를 정하는 것이 가장 어려웠습니다.
특히 “생성 책임을 어디에 둘지”, “값 객체가 가져야 할 최소한의 역할은 무엇인지”와 같은 고민을 많이 했습니다.
미션을 통해 객체지향 설계의 핵심은 단순히 코드를 나누는 것이 아니라, 각 객체가 자기 역할에만 집중하도록 만드는 것임을 다시 느꼈습니다.

 

6. 배운 점

복잡한 로직일수록 명확한 역할 분리가 테스트 용이성과 유지보수성에 영향을 준다는 것을 깨닫게 된 것 같습니다.

enum을 통해 도메인 로직을 표현하는 방법을 배웠습니다.

단일 책임 원칙을 지키기 위해선, 먼저 무엇이 이 객체의 핵심 관심사인가를 명확히 정의해야 함을 느낄수 있었습니다.

 

3주차 로또 미션은 단순한 기능 구현보다, 객체 간 관계를 설계하는 능력을 길러준 미션이었습니다.