급해도 요구사항은 꼭 확인하기

 

 

최근 일정에 엄청 쫒기면서 하는 프로젝트가 있다. 그러다 보니 빠르게 빠르게 뭔가를 하다 보면서 많이 타협을 보았는데, (+실험이라는 것도 컸다) 다시 생각해 보니 아쉬운 점들이 몇가지 있는 것 같아 생각을 정리해 보아야겠다.

 

요구사항은 꼭 분석하자

이번 요구사항 중에, 이러이러한 상품들이 있고, 저러저러한 가격들이 있어요. 이런 엑셀 형태의 자료가 있었다. 가격들에는 정가, 1차 할인 가격, 2차 할인 가격이 적혀져 있었는데 너무 당연하게 가격의 크기가 정가 > 1차 할인가 > 2차 할인가 라고 생각했고, (실제로도 엑셀 상단에 있는 데이터들은 그런 꼴이었다. 스크롤을 많이 내리기 전까진) 그대로 API 설계하고, 코드도 작성했다.

 

그러나 웬걸, 버그가 계속해서 터졌다. 다시 보니 정가와 1차 할인가가 같은 경우도 있었고, 1차 할인가와 2차 할인가가 같은 경우도 있었고, 1차 할인가와 2차 할인가가 같은 경우도 있었고, 가격이 누락된 경우도 있었고, 가격 표현이 다른 경우도 있었고, Null을 뜻하는 기호가 다른 경우도 있었고, 엑셀 가격을 터미널 파이썬에서 정리했는데, 이 과정에서 값이 바뀌기도 했다. (이건 정말 이유를 모르겠다. Ctrl + C한 상태에서 터미널에 Ctrl + V 하면 붙여넣기를 누를 때마다 값이 바뀐다.) 심지어는 엑셀에 있는 가격이 db와 다른 경우도 있었다.

 

지금 다시 보니 뭐가 많긴 했다...

 

아무튼 느낀 점은, 데이터가 어떻게 들어오겠지~ 확신하지 말자는 점. 데이터가 너무 많으면 python으로 이리저리 굴려보면서 내 예상과 같게 데이터가 들어있는지 확인해 보는 과정을 가져도 좋은 것 같다. 그리고 받은 자료가 실제 데이터와 일치하는지 확인하는 과정을 가져도 좋을 것 같다. (ex. 상품 가격 누가 수정할 건지? 판매자 분이 수정할 건지? 아니면 마케터 분이 수정할 건지 등) 데이터 신뢰성에 대해서도 생각해 보아야 한다는 걸 이번에 처음 알았다.

어차피 지울 코드니까 테스트를 작성하지 않는다?

원래 실험 코드를 작성할 때는 거의 테스트를 작성하지 않았는데, 비즈니스 로직이 많으면 그냥 작성해야겠다는 생각이 든다. 어차피 QA 과정에서 버그가 날 것을 전제로 두고, 테스트가 든든하게 바쳐주는 아래에서 코드를 수정하면 훨씬 안정감 있고 속도감 있게 수정 내용을 반영할 수 있을 것 같다.

 

이번에 비즈니스 로직이 좀 복잡하다 보니, A 문제 발생 -> A 해결했더니 B에서 발생 -> B 해결했더니 C에서 발생 -> C 해결했더니 A에서 발생. 이런 눈물 나는 경우들이 있었다.

 

생각해 보면 피처 개발할 때는 테스트 웬만하면 다 작성하는데, 이건 실험이라 어차피 지울거니까 작성하지 않았다. 왜냐하면 테스트도 관리 대상이니까 무의미하게 많아지면 관리 비용이 많아진다고 생각했다.

 

근데 다시 생각해 보면, 실험도 지우는데 왜 테스트를 잠깐만 쓰고 지울 생각을 못했을까? 하는 생각이 든다. 사실 테스트 짜는데 그렇게 오래 걸리는 것도 아니고...

 

이런 측면에서 생각하면 코드 퀄리티도 그렇다. 한 30분 정도만 투자하면 사실 좀 더 괜찮게 (사실 많이 괜찮을 수도 있다) 나올 때도 많은데 그냥 빠르게 구현한다는 것에 눈을 가려 너무 근시안 적으로 보는 건 아닌가 싶다.

 

실험이라 지울 거더라도 한 1주 이상은 다른 사람들이 볼 수도 있는데... 차라리 일하는 시간을 좀 더 늘리더라도 잘 정리해 보도록 하자.

(+ 여담이지만, 도메인 주도 설계 첫걸음 이라는 책 서문에 너무 맘에 드는 말이 있어 적어본다. 내가 여태 들어본 표현중에 이렇게 `비즈니스 로직`이라는 말을 잘 표현한 건 본 적이 없는 것 같다.)

 

"그런데 비즈니스 로직이 뭔가요?"

"아, 비즈니스 로직은 요구사항을 구현할 때 필요한 모든 반복문과 'if-else' 문장이에요"

다른 건 타협 보더라도 최소한 API는 신경 써서 작성하자

최근 OpenAPI와 스웨거를 활용한 실전 API 설계 이런 책을 읽고 있고 스터디도 참가하고 있는데, API도 곧 서비스기 때문에 사용자가 사용할 만한 API를 만들라는 제언을 한다.

 

부끄럽지만 이번에 `이거 그냥 실험이니까 이름 대충 짓고 나중에 지우죠? ㅋ` 이런 발언을 해서 필드명을 대충 지었는데, 이것 떄문에 대혼란을 겪어서 1사람 당 적어도 3시간씩은 더 쓰게 만든 것 같다. 심지어 클라이언트가 여럿인데 배포한 사람도 있다 보니, 다시 바꾸자고 하기에도 어려웠다.

 

변수명 잘못 짓는 건 나 혼자 고생하지만 API를 잘못 설계하면 내 고객 (클라이언트들)들도 고생한다는 걸 느낀 것 같다... API 설계에 좀 더 신경 써야겠다...