흔한 프로그래머의 작명에 대한 사뭇 진지한 이야기
얼마 전에 있던 작명에 대한 논의를 소재로 프로그래머의 일상이고, 더러는 중요하지 않게 해치우는(?) 작명에 대해 진지한 글을 하나 써보려고 합니다. 찾아보니 과거에도 비슷한 경험을 쓴 바 있지만 이번에는 조금 다른 느낌으로 다가온 일화를 소개하고 의미를 덧붙이려고 합니다.
작명에 대한 갈등이 발생할 때
두 개발자가 서로 다른 이름 체계로 각각 코드를 만들고 있었습니다. 마이크로 서비스로 구축하다 보면 흔히 만나는 일이죠. 문제는 함께 쓰는 JSON 필드 이름을 정할 때입니다. 같은 단어를 서로 다른 의미로 받아들이게 되니 의미에 있어 충돌이 생깁니다. 대개 한쪽의 방식을 택하면, 다른 한쪽은 함수나 변수 혹은 파일 이름 상당수를 수정해야 합니다. 개발자가 여럿이면 입장이 모두 다를 수밖에 없습니다. 네 명의 관련 개발자가 어느날 저에게 도움을 청했습니다. 코드를 짜지 않으니 이해관계가 가장 적은 제가 도움이 되리라 판단한 모양입니다. 필자는 개념적으로 명료한 기준을 찾으려고 개발자들의 현재 작명 내용을 묻습니다. 현황 자체보다는 어떤 의도로 이름을 지은 것인지 이해하기 위함이죠.
필자와 오래 일한 동료가 시간을 줄이려고 화면 덤프를 뜨고, 현황을 요약한 문서를 만들어서 소통을 주도합니다.
정가와 판매가 구분
문제를 명확하게 써보기
필자는 여기서 개발자들을 잠깐 멈춰 여유를 갖고 문제를 바라보게 유도합니다. 비단 개발자만 그러한 것은 아니지만, 경험상 많은 이들이 정확하게 문제를 설명하여 서로 이견이 발생한 부분이 무엇인지 드러내는 시간을 갖지 않고, 빨리 결론에 도달하려고 합니다. 자기들이 합의에 도달하지 못했던 후보 몇 개를 알려주고 가급적 빨리 선택하길 기대하죠. 하지만, 경험으로 배우 바는 그럴 때 일수록 '무언지 문제인지' 드러내야 합니다. 이때, 좋은 방법이 산출물을 만든 사람이 다양한 이해관계자앞에서 설명하는 방식인 워크쓰루Walkthrough입니다. 제가 이견이 있는 두 개발자 사이에서 사회를 맡은 사람[1]처럼 객관적인 설명을 유도하는 질문을 합니다.
그들이 답한 논리를 재확인하며 어딘가 기록해둡니다. 기록하는 행동은 약간씩 시간을 지연시키며 일차적으로 결과만 기대하는 개발자들을 진정시킬 수도 있지만, 잘 써진 논리인 경우 계속 써먹을 수 있는 원칙principle을 낳을 수도 있어 유용합니다. 명료하게 하려고 일부러 익숙하지 않지만, 수학 개념을 꺼내서 써먹어 봅니다.[2] 아래와 같은 식으로 화이트보드에 씁니다.
수학 개념 일부를 차용
문제를 쓰고 설명하며 드러나는 쟁점
아래와 같이 동료가 색깔 구분으로 상이한 변수명을 표기한 자료 덕분에 회의는 금새 쟁점을 향해 달려갑니다. 제 질문에 대해 각자 어떤 이유로 그렇게 지었는지 설명합니다. 필자 기준으로 명료하지 않은 부분은 계속해서 질문합니다. 습관적으로 작명 했던 개발자는 멈칫하기 마련이지만, 그가 모호하게 하는 말을 필자가 명료하게 정정해주는 대가로 대부분 인내를 갖고 답을 하려고 노력합니다. 그러다보면 끝내 모호해보이던 쟁점이 수면 위로 모습을 드러냅니다.
화면에 변수명을 붙인 멀티 레이어 모델
이 경우 단순히 영어 변수의 취향 문제가 쟁점이 아니었습니다. 개발자들이 필자를 호출할 때는 마치 그런 문제인 듯한 인상을 주었지만, 100분 토론 느낌[4]으로 진행해보니 실제 문제는 장바구니Cart에 담기 전에 이미 할인을 반영한 금액 즉, 판매가SalePrice 와 정가listPrice 사이의 차액을 할인 금액 계산에 굳이 넣을 필요가 있냐는 주장이 쟁점이었습니다. 실제로 장바구니 연산에서는 구매량에 따른 추가 할인이나 특정 회원 대상의 할인, 기존에 받은 쿠폰 활용 등을 다루는 것이 주안점인데, 뻔한 판매가 할인을 계산에 넣을 필요가 없습니다. 작명 문제는 알고 보니 기존 개발자들이 오랫동안 해오던 습관에 대해 새로운 개발자가 문제 제기를 하면서 논쟁을 일으킨 상황이었습니다.
논쟁 과정으로 모두 납득하는 작명 기준이 나왔습니다. 하지만, 그것만 얻은 것은 아니었습니다. 관행처럼 행해오던 중복 로직을 제거하는 깨알같은 혁신을 얻었습니다. 조금 우아하게 말을 풀면, 새로운 개발자가 강하게 주장하니 그의 뜻을 진지하게 들었고 갈등 해소과정에서 우리 모두는 더 나은 하나가 되는 시너지를 만들었습니다.
다른 생각이 부딪힐 때가 어쩌면 조직적 창의의 순간
필자 입장에서 개발자들이 사소한 선호 혹은 영어 표현 문제이니 정해달라는 듯이 찾아왔는데, 전혀 뜻밖의 발견을 해낼 때 그들 표정이 바뀌었습니다. 정말로 통쾌한 순간이었고, 상당기간 긴장관계로 대치했던 그들의 상이한 경험과 생각을 서로 엿보는 놀라운 시간이었습니다.
한편, 필자 개인에게는 동료에게 품고 있던 선입견을 발견하여 반성하는 시간이기도 했습니다. 또한, 자기 의도를 정확히 표현하지 못하는 동료를 돕는 다른 동료의 발언을 통해 필자가 원작자의 의도를 모두가 이해할 수 있는 말로 바꾼 경험은 놀라움 그 자체였습니다. 글을 쓰면서 이러한 노력들 즉, 올바른 구현에 대한 각자의 소신을 유지하고 그러느라 생기는 갈등을 해소하는 과정에서도 팀을 유지하려고 노력할 때 나타나는 창의의 순간이 아닐까 생각해봅니다.
같은 말로 다른 관점을 표현하는 경우
이 일이 있은 후, 동료와 대화하며 아래와 같은 낙서를 했는데... 언젠가 글로 옮길 수 있는 영감이 채워지면 다음 편을 쓰겠습니다.
하나의 객체에 대해 다른 관점이 필요함을 설명한 메모
주석
[1] 이런 역할에 대해 Facilitator란 표현을 종종 쓰더군요.
[2] 한번 써먹기 시작하니 공식 쓰는 재미에 빠져 화이트보드에 수식처럼 표현해봅니다. 학교 다닐 때 수포자였던 필자도 일상에서 필요성을 찾으면 재미가 붙습니다.
LP - SP = DP[3] TDP = SUM(DPqty)
애초에는 글씨를 다 쓰기 싫어서 줄여 쓴 것인데, 쓰면서 공식처럼 코드에 주석을 달면 좋겠다 생각이 들었습니다. 그리고, 실제 구현 가능한 아이디어인지 모르겠지만 주석 말고 아예 함수로 만들어서 매개변수로 쓰면 어떨까는 생각이 들었습니다.
[3] listPrice를 LP로, salePrice를 SP 등으로 줄여 쓴 표현입니다.
[4] 물론, 100분동안 하지는 않았습니다. 사회자가 있고 쟁점을 가진 다자간 회의를 진행했다는 의미입니다.