로또 미션 회고

SeokHwan An·2024년 9월 3일
초록스터디
0

초록스터디

목록 보기
5/6

6월부터 시작된 로또 미션이 8월이 되어서 마무리가 되었습니다. 로또 미션은 우리가 시중에서 구매할 수 있는 로또 시스템을 만드는 것으로 본 미션의 핵심은 클린 코드 였습니다. 해당 목적을 달성하기 위해 원시값 포장, 일급 컬렉션 등의 키워드가 등장했습니다. 이번 미션을 진행하면서 경험을 학습 측면의 관점과 운영적인 측면의 관점에서 회고를 진행하고자 합니다.

운영적인 측면

운영 측면에서 가장 큰 변화는 진행 방식의 개선이었습니다. 이전 자동차 미션에서 발생했던 일정 지연과 2단계씩 진행할 때 집중도가 낮아지는 문제를 해결하기 위해, 이번 로또 미션에서는 한 스프린트 당 2개의 단계를 진행하는 대신, 1개의 단계만 진행하는 방식으로 변경했습니다.

스프린트 단위를 줄인 목표는 미션의 진행 주기를 짧게 하여, 미션을 늘어지지 않고 신속하게 완료하는 것이었습니다. 또한 PR 요청 범위가 줄어들면 리뷰어 입장에서 부담이 적어지고, 리뷰의 질이 향상될 것이라고 기대했습니다.

새로운 운영 방식을 적용한 결과, 로또 미션은 반은 성공적이었고, 반은 그렇지 않았다고 느꼈습니다. 우선 성공적인 부분은 대부분의 스터디원들이 미션을 한 단계씩 진행하면서 부담이 줄었고, 기간 내에 미션을 완료하기 수월했다는 점입니다. 또한, 이전보다 각 단계에 집중할 수 있었다는 긍정적인 피드백을 받았습니다.

반면, 실패한 부분 혹은 개선이 필요했던 부분은 여전히 미션 진행이 늘어지는 문제였습니다. 야근과 취업 준비로 인해 일부 미션이 지연된 경우도 있었지만, 전반적으로 구현 속도와 코드 리뷰 속도 사이의 차이가 원인이었습니다. 대부분 스터디원들이 기간 내에 구현을 완료했으나, 코드 리뷰 과정에서 지연이 발생했습니다. 이 문제의 원인에 대해 고민한 결과, 다음과 같은 두 가지를 생각해 보았습니다.

  1. 다른 사람의 코드를 읽는 데 어려움을 겪음
  2. 코드 리뷰를 처음 해보는 상황에서 가이드라인의 부족

이 두 가지가 코드 리뷰 시간 지연의 주요 원인이라고 판단했습니다. 1번 문제는 코드 리뷰에 익숙해지면서 해결될 수 있을 것이라고 생각했고, 2번 문제는 당장 가이드라인을 만드는 것이 어려운 상황이므로, 다음 사다리 미션에서는 제가 모든 스터디원들의 코드 리뷰를 맡아 가이드라인을 만들어볼 계획입니다.

학습적인 측면

저는 로또 미션을 진행하면서 방어적 복사 를 잘 활용해야한다는 것과 도메인과 뷰사이에 보이지 않은 의존성을 잘 제거해야한다는 것을 느꼈습니다. 이 둘과 관련된 사항은 이전 포스팅 으로 정리를 했었습니다.

로또 미션 중 발생한 참조 문제를 간단히 요약하면, 로또 생성 과정에서 여러 개의 로또가 모두 동일한 결과값을 가지는 문제가 있었습니다. 이 문제의 원인은 캐싱된 로또 숫자 리스트(Numbers: 1부터 45 사이의 수)를 사용하여 로또를 생성할 때, 생성된 로또들이 캐싱된 리스트를 참조했기 때문입니다. 그 결과, Numbers를 가공할 때마다 이미 생성된 로또들도 영향을 받았습니다.

이 문제를 해결하기 위해서는, 캐싱된 로또 숫자 리스트에서 로또를 추출한 후, 방어적 복사를 통해 Numbers와의 의존성을 끊어야 합니다. (자세한 내용 보기: 로또 미션 중 발생한 참조 문제)

다음으로는 도메인과 뷰 사이의 간접적인 의존성 문제입니다. 도메인이 뷰에 의존하지 않아야 하는 이유는, 화면과 비즈니스 로직을 분리하여 각각 독립적으로 발전시킬 수 있기 때문입니다. 도메인이 뷰에 의존하게 되면, 화면상의 변화(비즈니스 로직의 변화가 아님)에도 도메인 코드가 수정되어야 하는 상황이 발생할 수 있습니다. 이는 유지보수 과정에서 예측 불가능한 문제를 초래할 수 있습니다.

한 스터디원의 코드 구조도(의존도)가 위와 같았습니다. 현재 뷰는 DTO에 의존하고 있어 도메인에는 직접적인 영향이 없을 것처럼 보였습니다. 하지만 실제로는 도메인이 DTO를 생성하면서 도메인이 DTO에 의존하는 문제가 발생했습니다. 이로 인해 발생할 수 있는 문제 상황은 다음과 같습니다.

만약 뷰에서 화면에 노출해야 할 정보가 수정되면, DTO도 수정되어야 합니다. 이 경우, 도메인이 DTO를 생성하고 있기 때문에 도메인의 코드 역시 변경되어야 하는 상황이 발생합니다. 즉, 도메인이 뷰에 직접적으로 의존하지는 않지만, 간접적으로 화면 변화에 의해 영향을 받는다는 점을 알 수 있었습니다.

이를 해결하기 위한 방법으로는 DTO가 스스로를 생성하는 방안을 고려할 수 있습니다. 즉, DTO가 도메인을 파라미터로 받아 자신을 생성하는 방식입니다. 이렇게 하면 의존도가 변경되어, 도메인과 뷰가 서로 직간접적으로 의존하지 않게 됩니다. (자세한 내용 보기: Domain이 DTO를 생성해도 될까)

로또 미션을 우아한테크코스 프리코스 때 처음 구현해보고, 이번에 다시 구현하면서 1년간 큰 성장을 했음을 느꼈습니다. 이전에는 단순히 미션을 구현하는 데 급급했지만, 이제는 다양한 개념을 적용하고 발생한 문제를 보다 논리적으로 파악할 수 있게 되었습니다. 이 경험을 통해 최근 느꼈던 성장에 대한 의구심이 자신감으로 바뀌기 시작했습니다.

내가 구현한 PR

내가 리뷰한 PR

profile
SeokHwan An
이전 포스트

Domain이 DTO를 생성해도 될까?

다음 포스트

테스트가 용이한 코드는 어떤 코드 일까?

0개의 댓글