오늘 진행한 일

에러 코드 개편 및 문서화

기존에는 예외가 터질 때 마다 예외 상황을 나타내는 메시지를 담은 response를 보내주었었다. 하지만 이렇게 하니까, 프론트엔드에서는 백엔드가 보내주는 메시지에 의존해서 개발을 할 수 밖에 없다는 문제가 있었다. (상태코드 + 에러 메시지 형태인데 상태 코드는 세분화되어있지 않으므로) 그래서 특정 예외 상황마다 에러 코드를 넣어서 프론트엔드가 에러 코드만 보고도 상황을 파악할 수 있도록 하기로 했다. 하지만 지금까지 도입되어 있는 에러 코드는 어떤 부분은 상세하고, 어떤 부분은 추상적이며, 그에 대한 기준도 명확히 있지 않았다. 원래 오늘 클레이와 하기로 한 부분은 REST Docs에 예외 상황에 대한 문서화가 진행되지 않아 있어 해당 부분을 문서화 하기로 한 부분이었는데, 오히려 에러 코드를 전면 개편할 필요를 더 느껴서 해당 부분을 중점적으로 진행했다.

결국 프론트엔드가 에러 메시지가 아니라 에러 코드만 보고도 예외 처리를 할 수 있도록하는 것이 핵심이었는데, 에러 추상화와 세분화의 경계에서 갈팡질팡을 많이 했다. 너무 추상화를 하면 에러 코드만 보고 어떤 상황에서 발생한 예외인지 알아볼 수 없고, 그렇다고 너무 자세히 쓰면 조금만 다른 예외 상황이 추가되더라도 에러 코드가 계속해서 늘어난다는 단점이 있었다.

정작 코드는 오랜 시간 치지 않고 코드 체계를 아예 개편하는데에 시간을 많이 썼는데, 결론적으로는 원래 도입 의도에 맞춰서 비즈니스 로직 안으로 들어가서는 최대한 에러 코드를 세분화해서 사용하기로 했다. 대신 Presentation Layer에서 바로 터지는 예외들에 대해서는 추상화해서 재활용할 수 있도록 했다.

최종적으로 개편된 에러 코드는 다음과 같은 형식을 가지도록 했다.

XXXYZ
여기서 XXX는 해당 에러 코드를 HTTP Response로 반환했을 때의 상태 코드를 나타내고, Y는 도메인 별로 묶어준 예외 그룹을, Z는 한 그룹 내에서 0번부터 시작하는 일련번호를 나타낸다. 예를 들자면,

40012 라는 에러 코드는, 400 Bad Request를 반환하며, 1번 그룹 (Member 도메인에 관련된 예외)에 속한 2번째 예외 사항에 대한 에러 코드라는 의미다.

예외 코드에 대한 리팩토링 과정에서 개인적으로 반성할 부분이 있었는데, 빠른 시간 내에 결론이 나오지 않고 충분히 논의가 필요한 내용임에도 불구하고, 다른 작업 중인 프론트엔드 팀원들의 사정을 생각하지 않고 에러 코드 논의에 대해 닥달했던 것 같다. 변명하자면 며칠 잠을 못자서 예민한 상태로 리팩토링 하려고 까본 코드 마저 뒤죽박죽이어서 마음이 급했던 것 때문이긴 하지만, 안그래도 리팩토링 작업이 많이 밀려 있는 프론트엔드 크루들을 전혀 배려하지 않은 행동이었던 것 같다. 팀 프로젝트에서 중요한 부분이 협업과 의사소통인데, 둘 다에서 실격이었다고 생각한다. 비슷한 상황이 오면 좀 더 차분하게 팀원들과 얘기할 수 있도록 해야겠다.

오늘 발생한 이슈

ControllerTest와 Documentation 병합

기존에는 컨트롤러에 대한 테스트는 테스트대로 따로 하고, 문서화 작업은 별도의 테스트 코드를 작성해서 진행했었다. 그런데 컨트롤러 테스트와 문서화 모두 MockMvc를 통한 HTTP 요청 -> 서비스 모킹 -> HTTP 응답 검증 과정을 거치고 있기 때문에 문서화가 진행되는 경우 테스트가 중복해서 일어나고 있었다. 애초에 두 테스트의 기본 설정 자체가 비슷하기도 했다. 실제로 코드를 보니 데이터 값만 조금 다르고 테스트 로직은 완전히 똑같은 경우가 많이 있었다. 그래서 Documentation 관련된 클래스를 전부 지우고, 문서화가 필요한 컨트롤러 테스트에서 문서화를 진행하는 메서드를 호출해서 문서화하는 것으로 테스트 코드를 바꿨다. 덕분에 불필요한 테스트를 10개 이상 없앨 수 있었다.

내일 목표

레벨 3를 진행하면서, 레벨 2에서 배운 스프링 관련 내용이나 MVC 패턴에 관련된 내용은 잘 적용하고 있는 것 같지만, 정작 레벨 1에서 배운 객체 지향이나 도메인과 관련된 부분은 잘 적용하고 있지 않다는 생각이 들었다. 그래서 최대한 도메인을 풍부하게 리팩토링을 하는 것이 어떻겠냐는 의견을 냈고, 그에 따라 내일은 서비스 레이어에 퍼져 있는 비즈니스 로직들을 최대한 도메인 레이어로 옮겨서 처리하는 리팩토링을 내가 리딩해서 진행할 예정이다. 내일은 칼퇴를 해야 하는데… 과연 시간 내에 끝낼 수 있을지가 걱정이긴 하다.