잘못된 네이밍

지난번에 개발 과정에서 잘못된 용어를 사용해 예상보다 훨씬 더 거대한 기능으로 오인받은 나머지 잘못된 우선순위를 부여받는 상황에 개입하는 통역 역할을 소개한 적이 있습니다. 이번에는 잘못된 네이밍을 그대로 놔둔 사례 하나를 소개하겠습니다.

한 프로젝트에서 모든 기능을 미친듯이 개발하고 있었습니다. 개발이 어떤 방식으로 진행되는지 이전에 양산형에서 이야기했습니다. 마일스톤 진행에 따른 회고 없이 이미 거의 확정된 기능을 미친듯이 찍어냈습니다. 대강 게임처럼 보이는 주요 기능이 완성되고 스티브잡스의 첫 아이폰처럼 메뉴를 잘못 건드리면 오동작하기는 했지만 숙련된 개발자들의 손에서 게임이 돌아가는 것처럼 보이는 상태에 접어들었습니다.

이 무렵 슬슬 상점 기능을 추가할 때가 왔습니다. 이전 프로젝트에서 상점을 게임의 나머지 부분과 비슷한 엑셀 데이터 기반으로 개발했다가 상품을 추가하거나 수정할 때마다 패치를 통해야 했고 이때마다 서비스를 일시적으로 중단해야 했습니다. 특히 상품을 추가할 때는 '재접속하면 상품을 이용할 수 있다'고 안내해 서비스를 유지할 수 있었지만 잘못된 상품을 수정하거나 삭제할 때는 모든 고객들의 접속을 중단시켜 반드시 패치를 다운로드하도록 해야 했습니다. 이 때마다 극심한 이탈이 일어났습니다만 개선할 수가 없었습니다. 이런 문제를 해결하기 위해 최소한 상점 데이터라도 서비스 중단 없이 그때그때 다운로드하도록 개발해야 한다는 공감대가 만들어져 있었습니다. 당연해보이는 기능에 공감대가 필요했던 이유는 처음에 이야기한 대로 개발팀은 이미 최대 속도로 모든 기능을 미친듯이 개발하고 있었기 때문에 미래의 서비스에는 유용하겠지만 당장의 일정을 더 줄여 새로운 기능을 추가하자는 요구는 개발팀이 받아들이기 어려웠습니다.

개발팀 밖에서는 상점을 실시간으로 업데이트하는 기능이 너무나도 당연했기 때문에 개발팀의 의지나 상태와 관계없이 개발일정에 실시간 상점 업데이트 기능이 다음 마일스톤 계획에 추가됐습니다. 그런데 이 작업의 네이밍이 좀 이상했습니다. 이 상점개발 태스크 이름은 'CDN 기반의 상점기능'이었습니다.

어떤 기술이나 기능이 시장에서 성숙하기 전에 종종 기술 이름을 상품 이름이나 의사소통에 직접 사용하는 사례들이 있습니다. 가령 물체를 3차원으로 인식하는 카메라의 정확한 용도를 설명할 수 없는 상태로 고객들에게 판매하기 위해 스마트폰 사양표에 'ToF 카메라 채용'이라고 적는 것이 대표적입니다. 'IoT'가 정확히 뭐 하는 기능인지 고객에게 설명할 수 없기 때문에 이 용어를 상품명에 직접 사용합니다. '5G' 네트워크가 정확히 고객에게 어떤 이익을 주는지 설명할 수 없기 때문에 '초시대'같은 모호한 의미로 광고합니다. 'OTT'가 뭔지 고객에게 설명할 수 없으므로 '특정 통신사의 OTT 서비스'같은 표현을 고객에게 뻔뻔하게 내놓습니다. 시장이 성숙하며 기능의 정확한 용도를 설명할 수 있게 되면 그때서야 고객이 이해할 수 있는 제품 이름이 나타나고 이제서야 돈을 내고 사용할만한 상품이 나타납니다. 기술 이름이 제품 이름에 나타나는 이유는 아직 제품을 광고하는 사람들 스스로가 이 제품이 정확히 뭔지 정의하지 못했기 때문입니다. 'CDN 상점'도 마찬가지입니다.

사실 이 이름은 기술적으로 기능이 어떻게 동작하는지 잘 설명하고 있습니다. 게임을 시작할 때 데이터 버전을 비교해 패치를 받기는 하지만 게임이 실행되는 도중 적당한 시점마다 상점 데이터가 변경되었는지 확인해 고객이 인식하지 못하는 시점에 상점 데이터를 업데이트 해놓는 겁니다. 이 과정에 '당연히' CDN이라는 기술을 사용해 업데이트 확인 및 데이터 다운로드 속도를 감소시킵니다. 하지만 이 기능의 핵심은 서버와 네트워크 기술이 아니라 상점 데이터를 게임의 나머지 부분과 비슷한 엑셀 데이터 기반으로 작성한 패치를 게임 실행 시점에 한 번 다운로드하는 대신 게임 진행 중에 확인해 게임 진행 중에 여러 번 다운로드하는 겁니다. 그 결과로 잘못된 상품을 수정하거나 삭제하면 상점에 이미 진입해 있는 고객은 결제단계에서 구입에 실패하고 상점 밖에 나갔다 돌아오면 수정된 상품을 구입할 수 있어야 합니다. 사실 이 태스크 이름은 이름을 작성한 사람이 기능을 제대로 이해하지 못했기 때문에 기능에 사용되는 기술 이름을 붙여놓은 결과입니다.

당연히 개발팀에서 이 태스크는 적절한 우선순위를 받지 못했습니다. 데이터 다운로드에 사용할 서버와 네트워크 기술은 개발팀 입장에서 와닿지 않는 너무 먼 이야기였습니다. 이 태스크 이름을 보는 순간 대다수의 비즈니스로직 레이어를 담당하는 엔지니어들은 자신과는 먼 이야기라고 생각해버렸고 백엔드를 담당하는 엔지니어들 역시 자신들이 어디까지 개발해야 하는지 이해하지 못했습니다. 개발은 태스크 이름 중에서 우리들이 이해하는 유일한 단어인 '상점'까지만 이루어졌고 '상점'을 제외한 나머지 부분은 무시됐습니다. 모두들 나머지 부분인 'CDN'은 '거 일단 상점 개발하고 나중에 하자'며 간단히 넘어갔고 게임에 상점 기능이 나타나기 시작하자 상점 이외의 부분은 잊혀졌습니다. 결국 이 상태로 서비스를 시작했고 이번에도 급한 업데이트로 잘못 올라간 상품을 긴급히 수정하기 위해 서버로부터 모든 고객을 내쫓기를 반복했고 이미 구입한 고객들의 DB를 검색해 수정해야만 했으며 심하면 피크타임에 긴급점검을 남발했습니다.

이 사례의 교훈은 앞에서 이야기한 통역의 역할이 없거나 실패하면 이전의 실패로부터 교훈을 얻었지만 이 교훈이 다음 업무에 전혀 반영되지 않을 수 있다는 것입니다. 제품이나 기능 이름은 항상 그의 본질과 용도, 동작을 설명할 수 있어야 합니다. 개발팀이 기능을 좀 더 심각하게 받아들이도록 하기 위해 기능 이름은 이 기능을 구현할 때 개발팀이 얻게 되는 이익을 설명하는 것도 좋습니다. 기능 이름에 고객들을 내쫓지 않고서도, 긴급점검을 걸어 우리들 뿐만 아니라 퍼블리셔쪽 스탭들을 긴장상태로 대기시고 점검 프로세스를 실행하기 위한 온갖 귀찮은 커뮤니케이션 없이도 실수를 몇 분 안으로 바로잡을 수 있다는 내용의 일부라도 포함되어 있었더라면 개발팀이 이 기능을 그렇게까지 무시하지 않았을 것입니다.

항상 태스크 이름은 기능을 잘 설명하고 기능을 구현할 때 개발팀이 얻을 이익을 설명할 수 있어야 합니다. 제품이나 태스크 이름에 기술 이름이 튀어나왔다면 뭔가 잘못된 신호이며 그대로 놔두면 잘못된 결과를 얻게 됩니다.