validation에 타협은 없다(feat. 보이스카웃 규칙)

<리팩터링 2판>과 <클린 코드>를 공부하면서 흥미로운 법칙을 알게 되었다. 바로 보이스카웃 규칙 이다. 

캠핑장은 처음 왔을 때보다 더 깨끗하게 하고 떠나라 라는 원칙

이는 리팩터링이라는 단어가 갖는 철학과 너무 잘 맞는다. 이전보다 더 깨끗이 정리한다는 의미는 먼지하나 없이 깔끔하게 정리하는 것을 의미하지는 않는다. 상대적으로 조금 더 깔끔하면 된다. 이 법칙을 지닌 사람이 조직 내 많으면 많을수록 그 효과는 배가되지 않을까? 학교 수업이 끝난 후 모든 학생이 본인의 자리 주변만 정리해도 청소 당번이 따로 필요 없을 것이다.

최근 레거시 코드에 피쳐를 추가할 일이 생겼다. 이미 시작도 전에 나는 법칙에 충만한 한 명의 보이스카웃일 준비를 마쳤다. 내 작업분을 테스트코드 작성과 더불어 마친 후 작업분 주변의 리팩터링 필요를 살핀 후 적당하게 리팩터링까지 할 수 있었다. 나름 뿌듯한 마음으로 동료들에게 PR을 요청했고 동료들의 리뷰가 시작됐다. 리뷰 사항 중 내 리퀘스트 페이로드의 validation이 많이 느슨했던 부분이 발견됐다. 참 부끄럽지만 순간적으로 변명에 대한 생각이 들었다.

‘이미 레거시가 너무 더럽고 충분히 기존코드들보단 깔끔하게 작성했는데..’

 

우선 다신 그러지 않겠다는 다짐으로 치부를 드러내본다.

// post-test.body.ts
// 수정전
@IsNumber()
someNumber!: number;

// 수정후
@IsInt()
@Min(0)
@Max(Number.MAX_SAFE_INTEGER)
someNumber!: number;

0 이상의 정수만을 허용하는 필드에 IsNumber라는 큰 범위의 데코레이터를 설정하고 Safe 한 Min과 Max값도 설정하지 않았다. 이 경우 validation의 책임을 갖는 layer가 책임을 다하지 못했기 때문에 오염된 값이 하위의 layer를 타고 편하게 내려오면서 수많은 곳에서 런타임에러를 발생시킬 수 있다. 더 최악의 경우는 에러 없이 실제 유저들의 데이터가 오염되어 버리는 경우이다. 해당 레거시 페이로드의 주변이 상당히 오염되어 있었지만 내가 작업한 부분과 그 주변을 어떻게 청소할 수 있을지 고려했어야했다. 잠시라도 변명 생각을 했던 내 자신을 반성하며 지적해준것에 진심으로 감사하다고 얘기했다. 그 후 다시 정리를 시작했다. 주변 코드들 중에도 이렇게 범위가 필요이상으로 넓은 프로퍼티들을 테스트코드 작성과 함께 정리할 수 있었다. (레거시는 히스토리 파악이 굉장히 중요하기 때문에 클라이언트 팀원들과의 소통도 충분히 진행했다.)

호기로웠던 모습과 달리 반성과 함께 일을 마무리지었다. 나는 0점짜리 보이스카웃이었다. 왜냐? 위에서 얘기하지 않았지만 리팩터링의 가장 중요한 전제는 적어도 정상동작은 해야한다는 것! 할 일부터 확실하게 한 후에 주변을 정리했어야 했다. 이번 경험을 교훈삼아 점진적으로 성장할 것을 다짐해본다.