HBR 구독에서 일상 활용으로
HBR 기사 <신제품 이름 짓는 가장 좋은 방법> 중에서 브랜드 개발회사 렉시콘 설립자이자 40년 동안 이 일을 해온 데이비스 플라섹의 인터뷰가 인상 깊었다. 참고로 '펜티엄', '블랙베리', '애저Azure' 등의 이름이 그들의 작품이었다.
주로 프로그래밍 작명 수준에서만 진지했던[1] 내게 사람들의 상상력을 자극할 기회를 찾아야 한다는 말은 놀라웠다. 이것이 정말 특별한 제품임을 알게 하라는 것이다. 이는 언어의 쓰임에 대해 깊이 이해하고 이름을 지을 때도 대상물의 쓰임과 말하고 듣는 이의 상황이나 심상을 고려할 필요성을 일깨워 주었다.
깊은 인상을 준 문구가 하나 더 있다.
지배적인 경쟁자를 상대하고 있지 않은지 고려할 필요가 있습니다. 우리가 마이크로소프트와 함께 이 회사의 클라우드 제품 이름을 정할 때 위험성이 낮아 보이는 솔루션은 '마이크로소프트 클라우드 서비스Microsoft Clous Services'였습니다. 하지만 마이크로소프트는 AWS로 잘 알려진 아마존 웹 서비스와 경쟁하고 있습니다. <중략> AWS에 애저를 모방자로 묘사하하는 것이 MCS를 모방자라고 칭하는 것보다 훨씬 더 어려웠습니다.
그렇다. 이름을 잘못 지으면 아류가 될 수 있다.
우리 회사도 올해 제품을 출시할 수 있지만, 이름을 고민할 단계는 아니다. 전혀 다른 맥락이지만 그간 작명에 대해 썼던 글들이 있음을 떠올렸다.[2] 제목에 '작명'이 들어간 글을 찾아보니 세 개의 글이 있었다.
그룹웨어 결재 기능으로 보이는 동료의 작명 검토를 하다가...
<흔한 프로그래머의 작명에 대한 사뭇 진지한 이야기>에서는 '작명에 대한 갈등'을 유효하게 활용하는 관점이 눈에 띄었다. 드러커의 표현을 빌어서 내가 받은 영감을 표현해 보자. 참여자 혹은 이해관계자 각각이 각자의 관점이나 입장으로 나뉘어 있는 상태라면, 그들이 개인 그 자체로 있는 상태다. 그런데 만일 경영자가 조직에 생명력을 불어넣는다면 그들은 빛나는 생산요소가 될 수 있다.
그렇게 만들어진 응집력은 조직력일 수도 있고, 생산력이 될 수도 있다. 마치 내가 예전에 그린 노트의 입체 도형이 바로 경영이 작동한 결과를 표현한 듯 보인다. 갈등을 화합으로 바꾸는 과정에서 도리어 생산력을 만들 수 있다는 사실을 당시에는 몰랐다. 기록을 남기고 곱씹어 보니 좋다. 진화하는 기분이 든다.[3]
<그룹웨어 결재 기능으로 보이는 동료의 작명 검토를 하다가...>에서는 이름을 따라 지식을 검색해 보니 국가 간 서로 다르게 형성된 시장 체계를 확인하는 장면이었습니다. 그러고 나서 내가 원하는 니즈를 견고하게 정의된 듯 보이는 기능 지도 위에 대응시켜 본 그림이 눈에 띄었습니다. [4]
네임스페이스라는 개념이 있습니다.
In computing, a namespace is a set of signs (names) that are used to identify and refer to objects of various kinds. A namespace ensures that all of a given set of objects have unique names so that they can be easily identified.
프로그래밍에서 특정 이름이 식별되는 공간(혹은 범위)을 지칭하는 말인데, 저는 이 말을 응용(혹은 확장)해서 생각할 수 있습니다. 우리는 일상 대화에서 공간을 한정 짓지 않고 말을 합니다. 그렇게 하면 당연히 컴퓨터의 세계에서처럼 정교한 소통이 되지 않습니다.
이와 관련해서 보편적으로 전달률을 높이기 위한 방법을 담은 것이 <성공적 대화를 돕는 그림>이고, 보다 전문적인 영역(domain)의 지식을 담는 방법이 BoundedContext라는 개념에 들어 있습니다. 나는 위 그림을 다시 보면서 산업계에서 그린 지식의 지도와 내가 하고 싶은 것을 매핑시키면서 '개념이 거하는 공간'이라는 사유를 했습니다.
나도 모르는 사이에 할 정도로 진지하게 작명에 대해 고민하며 살던 태도가 쌓였다는 느낌이 들어 제 글 검색을 했습니다. <축적의 시간>을 키워드로요. '작명에 대한 고민이 없는 사회'라는 소제목이 있습니다. 그렇군요! 유레카!
자산을 만들 때 작명은 너무나도 중요합니다. 그것은 경계를 만드는 일과 같기도 합니다. 정체성을 가진 개체들의 규정하고 다른 개체와의 관계를 규정하는 일에서 아주 중요한 위치를 차지합니다. 그리고 이들이 거할 공간이 바로 '개념이 거하는 공간'에서 '개체 군집이 거하는 공간'으로 바뀌게 됩니다. 작명 과정에서 그것이 만들어지는 것이죠. 주니어 개발자 시절 JCP의 느린 절차에 대해 이제야 이해하는 기분이 듭니다.
HBR 기사 문구 하나가 제 과거 기록에서 엄청난 생각 덩어리를 꺼내 주는군요! 사랑합니다. HBR. :)
그리고, <베터 어드민의 아기 발걸음 그리고 작명>편을 보니 작명은 이름만 구분해서 딱 정하는 일이 아니었네요. 묻따풀 하듯이 풀어가는 과정에서 갈래가 나뉘고 응집력을 주어야 할 부분에 경계를 만들어 가는 과정에서 특정 순간에 대한 포착이구나 생각했습니다.
나만을 위한 글이 되어 버렸습니다. 설계에 푹 빠져 사는 분이 아니라면 맥락을 쫓아오기 힘든 글이 되어 버렸습니다만 이걸 다시 해설할 자신은 없네요. 결론적으로 제품 영역에서 작명 전문가의 내용이 담긴 문장 때문에 제가 갖고 있던 소프트웨어 설계의 노하우가 발견되는 장면을 기록을 남긴 것입니다.
[1] 투입 시간을 기준으로는 그렇지만, 첫 아이 이름을 결혼도 하기 전에 지어둔 것은 예외적인 사례다.
[2] 전혀 다른 맥락을 연결해 보는 시도는 나에게는 일종의 습관이다.
[3] 아이들이 포켓몬에 빠져 있는 영향이 나에게도 침투한다. :)
[4] 아내가 반말로 썼다가 존재로 썼다가 하냐고 지적하는데, 그냥 그때그때 쓰고 싶은 대로 써오고 있습니다. 그런데, 요즘IT 기고를 계기로 이제 가급적 존댓말로 통일하려고 합니다. 가급적이요.
10. 좋은 후원자가 되는 법 활용
12. 전략과 원칙의 의미와 활용
14. 현명한 업무 설계를 돕기
15. 비허가형 기업 만들어가기