함께 그리고 가볍게 하는 소프트웨어 설계의 즐거움

어느날 2층 사무실로 들어오는데 친한 두 개발자가 열띤 이야기를 하고 있었다. 흥미 있어 보여 안그래도 끼여들려는 찰나에 그들도 마침 내 의견을 물었다. 벽에 붙은 화이트보드에 아래 그림과 같은 것을 이제 막 쓰면서 새로 개발에 참여한 개발자 김형준님이 기존 개발자 장재휴님에게 JSON 형식 데이터 필드의 현재 뜻을 묻다가 '모호한 용어'에 함께 개선하고 있는 상황이었다. J는 현재 상황과 함께 본인이 신뢰하는 다른 곳에서 쓰는 표현을 두 개 컬럼으로 구분하여 파란색으로 썼다.

열띤 분위기가 나를 쉽게 몰입하게 했고, 유심히 듣다가 평소 관심있던 부분만 의견을 내놓았다. 배운게 도둑질(?)이라고 UML 표기를 썼다.  위 그림 우측 상단 클래스도를 그리면 설명했는데 글로 쓰면 다음과 같다.

• Price라는 객채(혹은 개념)를 두자. 추상적인 개념이고 실체(구체적인 객체 혹은 JSON 필드명)는  ListPrice와 SalePrice로 '정가'와 '판매가'로 구분해서 사용하자.(UML 상속 활용)
• SalePrice는 discount(할인액)을 포함하며, SalePrice 없는 discount는 존재할 수 없다. (UML의 composition 관계에 해당)
• 상품의 SalePrice를 만드는 행위인 Offer를 통해 SalePrice와 discount는 만들어지고 수정된다.

두 개발자가 UML에 능통한지 어떤지는 모르지만, 그리면서 위와 같이 설명했기에 쉽게 이해했다. 그리고, 자신들의 의견을 말했다. 우리 셋은 모두 공감하고 상쾌한 기분으로 마무리를 했다. 내 입장에서는 고작 5~10분을 투자하고, 개발에 작은 기여나마 할 수 있었고 공감 과정에서 얻은 기쁨은 놀라울 정도였다. 놀라운 상쾌함의 가장 큰 이유는 아마도 열렬히 일하는 이들과 함께 하는 과정에서 비롯된 것이라 믿는다. 그리고 두번째는 자연스러운 흐름(flow)속에서 적기에 딱 필요한 만큼만 하는 가벼운(lean) 설계 행위였기 때문이다. (개발도 하기 전에 억지로 짜내기 하는 식의 설계와 대비하면 쉽게 이해할 수 있다.)

이 경험으로는 즐거움이 부족했는지, 김형준님과 나는 메신저로 또 다른 업무 용어 개선에 대해 협업을 시도했다. 아래 채팅 전에 적립금에 대한 용어로 points를 쓰기로 정했는데, 추가하고 사용하는 함수(메소드) 명으로 어떤 것이 적합한지 논의가 약간 미흡했었다.

포인트 추가와 쓰기에 적합한 용어

대화의 배경은 K가 '네이티브가 옆에 있으면 바로 물어서 해결할텐데...'라며 관성적 영어 작명을 피하려는 노력을 하기에 내가 꿩 대신 닭(?)으로 나선 상황이었다. 네이티브 대신 믿을만한 사전(위키피디아)을 찾아본 것인데 추가 하나 더 얻었다. points를 현금 대신 쓰게 하는 경우도 있지만, 일반적인 상품이 아닌 증정품으로 바꿔주는 경우에는 다른 단어가 적합할 수도 있다는 포착이다. 아직 그 단계로 코드가 발전하지 않아 확언할 수는 없지만, 만일 의미를 정확히 하려는 노력(일종의 integrity 확보)없이 그냥 포인트 차감 정도로 SQL Update 성격만 표현하려고 했다면 if/else 스파게티 도입을 위한 진입점을 '보다 쉽게' 주었을지도 모른다. (포인트 사용에 대한 아래 채팅의 구체적인 업무 로직 설명은 생략합니다.)