Project Section - Main Project Week4 Review : 당신의 코드는 안녕하십니까?

 처음으로 부제를 붙여봤다. 그냥 몇 주차 리뷰라고만 붙이니까 무슨 내용인지 알아볼 수가 없을 것 같아서.

 

 지난 3주차 리뷰를 작성하지 못했다. 이유는 별 거 없다. 딱히 작성할 내용이 없었다. 기초적인 기능 구현을 계속해서 진행했고, 어려운 점이라면 jpql을 사용하는 부분에 있었다. 왜 jpql을 사용하게 되었는지까지의 과정은 따로 블로깅 할 수도 있겠지만, 어떻게 사용했는지에 대한 블로깅은 따로 작성하지 않겠다. 해당 내용은 다른 블로그들에서도 충분히 찾아볼 수 있는 내용에 불과하다.

 

 4주차는 서비스의 안정적인 운영에 집중하는 한 주가 되었다. 먼저, 테스트 코드를 작성하기 시작했다. 코드를 리팩토링하거나 새로운 기능을 추가할 때마다, 우리는 애플리케이션을 실행시키고 포스트맨을 통해 테스트를 진행했다. 당연히 테스트에 시간이 오래 걸릴 수밖에 없었다. 애플리케이션을 실행시키고, 포스트맨을 통해 로그인을 하고, 다시 새롭게 바디를 작성해서 기능을 테스트하는 일은 여간 귀찮은 일이 아니었다. 우리는 테스트코드의 필요성을 뼈저리게 실감했고, 테스트 코드를 작성하기 시작했다.

 

 사실 이전 글에서 TDD를 하기 위해 노력한다고 이야기했다. 실제로, 다른 개인 프로젝트를 진행하면서는 최대한 TDD를 적용해보려고 했다. 문제는, 내가 테스트 코드를 작성하는데 아직 익숙하지 않다는 것이었다. 해당 개인 프로젝트는 진행이 지지부진해졌고, 그런 상태에서 프리 프로젝트와 메인 프로젝트에 진입했다. 기능 구현을 위한 시간은 한정적이었고, 미안한 말이지만 백엔드 팀원분들의 속도는 기능 구현을 하기에도 급급했다(그럼에도 끝까지 따라와 준 점은 정말 고맙게 생각한다). 아무튼, 기능 구현을 전부 마칠 때까지 테스트 코드는 전혀 작성되지 않은 상태였다.

 

  그래서 우리는 뒤늦게나마 테스트 코드를 작성하기로 했다. 이번 프로젝트는 사실 현재까지도 미완의 상태라고 보는 것이 옳다. 짧은 기간동안 완성시켜야 했고, 그렇기에 필요하다고 생각되는 몇 가지 기능을 제외하고 개발했다. 팀원 전체도 이 프로젝트를 좀 더 디벨롭 시켜보는 것에 동의했고, 부트캠프를 수료하고 나서도 다 함께 이번 프로젝트를 가지고 여러 기능을 개발해볼 생각이다. 그리고 이를 위해, 이제라도 현재까지 구현한 기능들에 대한 테스트코드를 작성하고 앞으로 추가될 기능은 TDD방식을 최대한 적용할 것이다.

 

 그런데 테스트 코드를 작성하자니, 도대체 어떻게 테스트 코드를 작성해야 하는가? 에 대한 고민이 이어졌다. 내가 생각하는 테스트 코드를 작성하는 이유는 다음과 같다.

• 내가 A라는 값을 집어 넣으면 B라는 결과물이 잘 나오는지 확인한다.
• 내가 잘못된 값을 집어 넣으면 예외처리가 잘 되는지 확인한다.

 문제는, Mockito를 사용하며 테스트를 진행하다보니, 결과를 정해놓고 테스트를 진행하는 경우가 많아졌다는 것이다. 이래서야 내가 생각하는 테스트 코드를 작성하는 이유와 전혀 맞지 않았다. A를 넣던 C를 넣던 무조건 B가 나오는데, 이럴거면 테스트를 도대체 왜 하지? 라는 생각이 크게 들었다. 관련해서 멘토님께 여쭤보았고, 멘토님은 향로님의 블로그 글을 던져주셨다. 아직 1~5까지 모든 내용을 다 보지는 못했지만, 어떤 코드가 테스트하기 좋은가. 즉, 왜 내 코드는 테스트하기 어려운가를 생각해볼 수 있었다. 추후 리팩토링 및 테스트 코드 작성 과정에서, 위 블로그의 내용을 유념하며 리팩토링 및 테스트 코드 작성을 진행할 생각이다.

 

 다음으로는 전체 서비스에 로그를 작성하고 이를 기록하기로 했다. 프로젝트를 하며 가장 크게 불편을 느낀 부분은 '도대체 어디에서 에러가 났는지를 알 수가 없다.' 는 점이었다. QA를 진행하는 동안 에러가 발생하면, 모든 팀원이 QA를 멈추고 어느 부분에서 에러가 발생한 것인지 찾는데 급급했다. 에러가 발생한 위치를 찾기 위해 처음부터 다시 모든 기능을 수행하다보니 도저히 QA에 진전이 생길 수가 없었다.

 

 그래서 선택한 방법이 일단 모든 기능에 로그를 다는 것이었다. 특정 요청이 들어오면, 컨트롤러에서 어떤 요청이 들어왔는지를 먼저 로깅하고, 서비스 로직에서도 기능이 정상적으로 수행될 때마다 어떤 기능이 수행되었는지를 로그로 출력했다. 동시에 예외를 처리하는 Advice부분에서도 단순히 클라이언트 측에 에러를 담은 body를 전달하는 것에서 에러 로그를 출력하게끔 수정했다. 덕분에 QA를 진행하는 동안 어느 부분에서 문제가 생겼는지를 더 빠르게 판단할 수 있게 되었고, QA에 가속이 붙었으며, 이후 코드를 수정하고 에러를 잡는데 도움이 되는 결과로 이어졌다.

 

 단순히 로그를 작성하는 것에 그치지 않고, 발생한 모든 로그를 저장하기로 했다. 지금은 6명 전원이 QA에 붙어서 발생한 에러를 공유할 수 있었지만, 만일 이게 큰 프로젝트라고 한다면 매일매일 발생한 에러를 다른 팀원들과 공유할 수 있는 새로운 수단이 필요할 것이다. 어떤 수단을 선택하던 에러 로그를 저장해놓는 것은 반드시 필요하다. 저장된 로그가 없는데, 뭘 바탕으로 에러 내역을 공유하겠는가. 로그를 저장하는 방법은 생각보다 간단했고, 저장된 로그를 통해 과거에는 어떤 에러들이 발생했었는지, 어떤 부분을 수정하기로 했었는지를 파악할 수 있어 이후 과정을 처리하는데 훨씬 수월하게 진행할 수 있었다.