2023년 6월 2주차 주간 회고

야크 털 깎기

야크 털 깎기라는 표현을 들어 보았는가? 보통 어떤 목적을 달성하기 위해 일련의 작업들을 수행하는 과정에서 어느 순간 원래 목적과는 동떨어진 일을 하게 되는 것을 나타내는 데 해당 표현을 사용한다고 한다.

 

세스 고딘의 저서 '이제는 작은 것이 큰 것이다'에는 다음과 같은 사례가 등장한다. (사례는 약간 각색했다.)

 

- 목적: 봄이 왔으니 세차를 한다.
- 행동
1. 세차를 하려고 했는데 호스가 터졌다. 새 호스를 사러 마트에 간다.
2. 호스를 사러 가려고 차에 탔는데 차의 기름이 떨어졌다. 옆 집 이웃에게 기름을 빌리러 간다.
3. 우리 아들이 이웃집 막내아들한테서 보이스카웃에 간다고 베개를 빌려갔던 게 생각났다. 베개를 돌려줘야 기름을 빌려줄 것 같으니 아들한테서 베개를 찾아 돌려주기로 한다.
5. 생각해보니 베개에 넣는 야크(물소) 털이 많이 빠져 있어서 바로 돌려줄 수가 없을 것 같다. 야크 털을 구해 베개의 폼을 충전하기로 한다.
6. 야크 목장에 가서 야크의 털을 깎는다.

 

 

이번 주부터 프로젝트 애플리케이션을 다시 손보기 시작했다. 프로젝트를 진행하던 시기에 목표했었으나 달성하지 못했던 기능들을 추가해보기로 마음먹었고, 지금은 작업을 본격적으로 시작하기 전에 사용자가 사용하는 기능은 동일하지만 내부 로직에서 개선할 수 있는 부분들을 최대한 개선해 이후 기능을 추가하는 과정에 문제가 되지 않게끔 하는 작업들을 진행하고 있다.

 

그 중 첫번째로 일부 도메인 객체들을 통합하는 작업을 진행했다.

 

현재 애플리케이션에서 사용자가 사용할 수 있는 주된 콘텐츠는 '스포츠 경기 인원을 모집하는 글'을 보거나, 작성하거나, 참가하는 것이다. 이때 경기 인원 모집 글과 관련된 리소스를 생성하는 과정에서는 '게시글' 객체와 '경기' 객체가 항상 같이 상호작용하고 있었다.

 

두 객체가 항상 같이 등장해 상호작용한다는 것은 두 객체를 합쳐 하나의 객체로 구성해도 동작을 수행하는 데 무리가 없다고 볼 수 있을 것이라고 생각되었고, 애플리케이션 레이어에서 두 개의 객체를 각각 조회하는 인터페이스를 호출하는 동작을 하나로 줄여서 우선적으로 코드의 복잡성을 가장 효과적으로 줄일 수 있을 것이라고 판단되어 작업을 수행했다.

 

앞으로 애플리케이션이 확장되는 데에는 '경기' 도메인이 핵심적인 역할을 맡아야 할 것이라고 생각해 '게시글'에서 사용하는 데이터들과 동작들을 '경기' 객체에 합쳤다.

 

반응이 즉각적으로 왔다. 게시글 도메인을 없애고 경기 도메인의 내용을 수정하자, 게시글과 경기 도메인이 사용되고 있던 모든 영역의 소스코드에서 문법 오류를 배출시키기 시작했다. 추정으로는 애플리케이션에서 만들었던 전체 클래스의 약 70% 가량에서 오류를 뱉었던 것 같다.

 

그렇게 에러가 나는 코드들과 테스트 코드들을 하나씩 찾아 고치는 과정에서, 그냥 넘어가기가 찝찝한 문제들이 하나 둘 눈에 들어오기 시작했다.

 

- 경기 객체에 경기 시간과 관련된 정보로 직접 정의한 필드를 두는 게 아니라 LocalDateTime을 활용할 수 있을 것 같다.
- Builder를 활용해 객체를 생성하게 하면 가독성에 도움이 될 것 같다.
- 무분별하게 사용되고 있는 fake 객체들을 개선하지 않으면 테스트 코드를 보완하기가 너무 어려울 것 같다.
- 수정해야 하는 부분의 일부 메서드나 변수 네이밍, REST API 경로 같은 것들이 의미를 정확하게 전달하고 있지 못하거나 너무 복잡하게 이름지은 것 같다.
- 경기 목록이나 검색 결과 목록을 조회하는 동작은 쿼리를 개선해야 할 것 같다.
- 검색 결과를 조합하는 Service도 모두 고쳐야 하는 김에, interface 개념을 도입할 수 있을 것 같다.
- ...

 

 

에러를 잡는 과정에서 고민이 들었던 부분은, 그런 찝찝한 부분들을 이 작업에서 '동시에' 같이 해결하는 게 과연 작업 단위적인 측면에서 맞는가에 대한 부분이었다. 이를테면 '나는 도메인 합치기라는 작업을 하고 있는데, 테스트 코드의 fake 개선을 동시에 하는 게 과연 맞는가?'와 같은.

 

일단은 에러를 잡는 과정에서 문제를 해결하지 않고 그냥 넘어갈 때 그 문제의 맥락이 에러를 수정하는 것을 지나치게 발목잡을 것으로 판단되거나, 그 정도는 같이 해결해도 작업 단위의 맥락을 파악하는 데 큰 지장은 없겠다고 판단한 문제들은 해결하고 넘어가는 것으로 결정했다.

 

이를테면 테스트를 위해 기존에 만들어놓았던 fake 메서드들은 이름은 복잡하고 전달되는 인자들은 무엇인지 이해하기 어려운, 마치 정적 팩터리 메서드와 생성자의 단점만 골라서 조합해놓은 형태를 띄고 있었다. 이들을 Builder로 대체하고, 동작을 수행하는 데 중요한 판단 기준이 되는 식별자 정도만 받아서 객체를 생성하는 fake 메서드를 test package에 정의해 테스트 코드에서만 사용하게끔 하는 식의 개선을 같이 진행했다. 쿼리를 개선하는 문제는 별도의 작업으로 분리해야 할 것 같아 그대로 두었고, 따라서 목록을 조회하는 테스트 코드는 매 반복마다 데이터베이스로부터의 반환값을 설정하기 때문에 테스트 데이터의 크기가 커지는 기존 테스트의 근본적인 문제를 아직은 해결하지는 못했다.

 

수정 과정에서 조금씩 바뀐 리소스 형식과 API를 맞춰주기 위해 프론트엔드 애플리케이션도 손보기 시작해야 하고, 별도의 작업으로 해결하기 위해 분리한 TODO가 산더미같이 쌓였지만, 그래도 이전에는 어디서부터 문제를 해결해야 할지 감을 잡기도 어려워 보였던 문제들이 이제는 어떻게 해결해야 할지 조금씩 보이기 시작한다는 점은 반가운 것 같다.

 

 

우리 가게 리모델링합니다

저번에 가게 문을 닫았었을 때는 하루만에 영업을 재개했었는데, 이번에는 조금 걸릴 것 같다.

 

지원을 잠시 멈춘 지금, 프로젝트에서 해결해야 할 문제들의 유형을 생각해보았다.

 

1. 프로젝트를 진행하면서 겪었던 여러 문제들이 그대로 방치되어 있다.
2. 프로젝트가 내가 기대했던 수준만큼 완성되어 있지 않다.

 

 

문제 해결에 대해서는 지난 과제 테스트를 통해 일부 문제를 해결해보는 경험을 했기 때문에 그 흐름을 이어갈 수 있을 것 같다. 그렇다면 추가로 신경써야 할 부분은, 프로젝트의 나머지 내용들을 얼마만큼 완성할 것인지를 적정 수준에서 선정해야 할 것이라는 생각이다.

 

지금까지 구상한 애플리케이션 완성을 위한 기능의 방향성적인 측면과 구체적인 예시는 다음과 같다. 본격적으로 기능을 추가하기 시작할 때는 구현할 범위를 구체적으로 정함으로써 구현에 드는 시간을 적절히 계산할 수 있어야 할 것이다.

 

- 카테고리를 야구로 한정한다.
이를 위해 신청 정보, 사용자 정보, 통계 등 추가할 기능들을 야구 경기에 적합하게 설정한다.

- 기존에 신경쓰지 못했던 예외처리를 고려한다.
동일 장소에서의 경기 시간 중복, 시간 경과에 따른 일정 종료 등을 고려하게 한다.

- 경기와 관련된 정책을 설정한다.
훈련, 친선경기, 매칭 등의 경기 종류와 관련된 정책을 상세히 설정한다.