예비군 훈련, SLASH, 테스트 문제

예비군.. 내년이 마지막이다..!

 

오늘은 예비군 훈련을 다녀왔다. 평소보다 여유롭게 6시 반에 기상하여 준비했다.(사실 그냥 더 자고싶어서 잤다..) 예비군은 진짜 조기퇴소 각이였는데.. 우리 분대가 90점,100점 받은 과목이, 평가항목에서 제외 + 분대원의 시험지 백지 + 사격 0발의 콤비로 만기 퇴소했다.. 중간 대기 시간에는 토스의 컨퍼런스인 SLASH Server 세션을 중간에 잠깐 볼 수 있었는데, 진짜 계속 보고싶을만큼 재밌었다. 다시보기로 볼 수 있으니, 꼭 다 챙겨봐야겠다.

---

토스 컨퍼런스, SLASH

 

컨퍼런스는 기업을 막론하고 정말 재밌는 것 같다. 내가 관심있는 주제가 아니더라도 흥미롭다. 다른 분야의 고민과 문제를 알 수 있고, 무엇보다 문제 해결을 위한 과정을 들어볼 수 있어서 재밌다.(물론 진짜 자랑만 하는 컨퍼런스도 있었다..) 토스의 컨퍼런스는 재밌는 주제가 많았다. 배포관련, 아키텍처관련, 언어관련, 인프라관련 등등(그냥 다 관심이 있던 부분같다.) 재밌어보이는게 너무 많았다. 그래서 바로 신청하고서, 굿즈도 받았는데 하필 이날이 예비군을 가는 날이었다. 그래도 다행이었던 것은 중간 시작 전, 다시보기가 제공된다는 사실을 알고 맘편히 예비군 훈련을 받을 수 있었다.

 

 

중간 쉬는시간마다 내용을 보았는데, 그 중 기억에 남는 부분을 캡쳐했다.

 

토스에서는 로깅과 알림에 대하여 관심이 많은 것 같았다. 최근 채용공고에 보면 "서버를 개발하다보면 빠질 수 없는 모니터링과 알림 어떻게 하셨나요? 불편한 점은 없었나요? 관련됨 경험이 있으면 기술해 주세요" 항목을 볼 수 있었는데, 이를 보고 나는 "맞지, 모니터링과 알림 너무 중요하지" 하는 생각을 했던 기억이 난다. 얼마전, 알림 시스템을 설계하는 부분을 책에서 읽었었는데 생각보다 알림 시스템이 생각해볼 것이 많은 부분을 고려해야한다는것을 알게되었다. 그래서 더 토스에서는 어떻게 해당 부분을 어떻게 할까 궁금했었는데, 중간에 볼 때 이런 내용이 있어서 더 보고싶어졌던 것 같다. (빨리 내일 보고싶다!)

 

지난 회사 프로젝트에서 로깅과 모니터링 및 알림의 필요성에 대해서 많이 스스로 깨달을 수 있었다. 다만, 일반적인 로깅의 사용과는 다소 다른(?) 사용 용도에 따라, 로깅을 100% 제대로 활용하지 못했었다.(로그 파일은 그저 용량만 차지하는 파일에 불과했다. 가끔 로그 확인하는 것외에는.. 진짜 로그파일을 주기적으로 확인을 하지도 않았다. 어떤 경고성 로그가 발생해도 몰랐다. 보질 않으니깐..) 사실 로깅을 이렇게 사용하다보니, 모니터링도 형식상에 불과했다고 생각한다. 그나마 알림은 hook을 활용하여, 나름 활용했다고 이야기 할 수 있을 것 같다.

 

---

테스트 문제

 

MemberApplicationService 를 테스트 하면서 문제가 발생했다. 사실 예비군을 다녀오고, 오늘은 운동을 다녀오는 날이라서, 책상에 오래 앉아 있을거란 생각을 못했는데 이 문제 덕분에 보다 많은 시간을 책상에서 보낼 수 있었다.

 

문제의 테스트.. 테스트에서는 for debug 부분이 모두 출력이 되었지만, memberState 가 올바르지 않은 상태라는 에러를 뱉었다.

테스트 실행 시 출력은 다음과 같았다. 에러는 발생했지만, Exception을 잘 나눠둔 덕에 문제의 부분을 쉽게 찾을 수 있었다.

 

문제가 되는 부분은 다음 부분에서 문제가 발생했다. 먼저 코드에서는 가장 큰 문제는 항상 Exception을 던질 수 밖에 없다는 것이다.

나 조건문을 왜 저렇게 작성했는지.. 지금도 의문이다..

 

같은 프로퍼티를 다른조건으로 확인한다는 것이.. 무슨생각으로 내가 코드를 작성했는지 모르겠다...(정신이 나갔었나..) 근데 이 문제가 발생할 때에는 이 부분도 내가 문제라고 인식을 못했었다.(너무 피곤했던것같다..) 그래도 다행히 같이 공부하는 분들께 도움을 요청하고, 조건을 통해 다음과 같이 개선할 수 있었다.

 

개선된 코드, 유효한 상태값을 가진 리스트를 만들고 해당 변수로 조건문을 확인하여 가독성을 높였다.

 

먼저, 조건문에 여러 조건이 들어가는 것 보다 하나의 조건으로 명시 것이 어떻겠냐는 피드백에 납득하고 해당 부분을 수정했다. 처음에는 클래스 프로퍼티로 뺄까 생각했지만, 아직 해당 부분을 사용하는 곳이 이 함수 밖에 없어서 아예 밖으로 빼지는 않았다.

 

그런데 문제는 여전히 해결되지 않았다. 분명 상태값은 나오는데.. 왜 에러가 발생하는 것 일까? validateInitialUpdateMember() 내에  print 문을 통해 memberStatus를 확인해보니 null 이 나왔다.

전체적인 흐름은 다음과 같으며, 빨간색 부분은 Mapper 클래스를 의미한다.

 

전체적은 흐름을 볼 때, 나는 member 객체에서 정상적으로 memberStatus 를 가지고 있고, 해당 member 객체로 UpdateMemberCommand 객체를 만들었기 때문에, Member 에서 문제가 발생했을 것이라 생각했었다. 그리고 Member 에서 valdateUpdateMember 메서드 과정 중 하나인 validateInitialUpdateMember 메서드가 원인이라 생각했다.

 

하지만 이전 부분을 수정하고도 문제는 해결되지 않았다. 어디가 문제일까... 왜 문제가 발생했을까.. 지금생각하면 너무다도 당연하게 진짜 원인의 부분을 확인했을것같지만(어림없는소리) 당시에는 바보같이 찾지 못했다.

 

원인은 Mapper 였다! 내가 Mapper로 Membe 를 만들 때, 제대로 만들지 않았다..

 

"Member 이 제대로 생성되지 않았다." 라는 것을 지금 생각하면, Member 객체가 생성되는 부분을 다 확인 하면 되는 것이였는데, 나는 처음 부분만 확인해서 문제가 됫던 부분(Mapper)을 생각하지 못했던 것 같다.

 

감사하게도 같이 공부하는 분께서 git clone을 하고 문제가 되는 부분을 확인해주셨다..!

 

그렇다.. build()를 하면서 내가 memberStatus를 지정하는 것을 빠트렸다. 때문에 memberStatus 가 null 이었고, 올바른 상태가 아니였던 것이다. 나는 여러 다른 책과 강의를 보면서, 생성자에 매개변수가 많다면 빌더 패턴을 사용하라는 것을 알게되었다. 그리고 나는 이번 개발을하면서 빌더 패턴을 사용했다. 매개변수가 많을 때, 순서에 헷갈리지 않고, 각 매개변수를 관리하기 쉬울것이라고 생각했다. 그런데 많은것을 관리하기에는 여전히 주의가 필요하다는 사실을 깨닫게 되었다.(말하고보니 당연한 이야기인것 같다.)

 

일을 마치고 피곤할 시간(자정00시..)에도 자기 일처럼 코드를 봐주시고 도움을 주신.. 명X님.. 동X님.. 정말 감사힙니다..(하트)

 

---

 

오늘은 일도 많고, 늦게까지해서인지.. 정말 많이 피곤하지만 보람찬(?) 하루였다. 내일은 좀 더 많은 일을 할 수 있도록 부지런히 움직이자 성연아!