제품으로서의 소프트웨어, 이를 만드는 제품 사고방식
디지털 전환 선행 연구 No. 15
유명한 저자이기도 하고 제가 좋아하는 DDD 등의 기술을 업으로 삼는 Vaughn Vernon의 링크드인 글을 보고 떠오르는 생각을 써봅니다.
10년이 지나도록 변화가 없는 대기업의 전산실 문화
중국에서 돌아온 후에 가끔 국내 기업의 기술 자문을 하면서 오랜만에 대기업의 소프트웨어 배포 이슈를 듣습니다. 마치 타임머신을 타고 10 여년 전으로 돌아간 듯합니다. 10년쯤 전에 대기업 실무자들과 논의하면서 겪었던 기분이 고스란히 살아나기 때문입니다. 그런 기분을 느끼지 않았다면 이 글은 쓰지 않았겠죠.
Vaughn Vernon의 글이 눈에 들어온 이유는 enterprise DMZ 라는 단어 때문이었습니다. 저는 그게 왜 눈에 띄고, 무엇을 느낀 것인지 여러분과 느낌을 공유할 목적으로 글을 씁니다. 글의 전개 방식은 앞서 cohesion 관련 글처럼 비슷하게 하겠습니다. (papgo 번역을 빌리고 의견을 첨삭하는 식으로)
캡춰한 글의 원문을 찾으려고 갔더니 그 사이 그가 유사한 글을 썼습니다. 캡춰한 글을 기반으로 하면 답답한 현실을 토로할 가능성이 높고, 새로운 글을 기준으로 하면 희망하고 꿈꿔야 할 방향을 글로 쓸테니 캡춰한 글은 잊고 후자로 하겠습니다. :)
제품으로서의 소프트웨어
제품으로서의 소프트웨어(Software as a product)는 처음 보는 표현인데 마음에 보자마자 저를 사로 잡는 표현입니다. 소프트웨어를 제품으로 다루는 자세, 개인적으로 우리회사 베터코드가 지향하는 기본 자세이기 때문에 더 와닿지 않을 수 없네요. :)
Software as a product is an extremely important pursuit. Since much of my background is in product development (including as a kid with my grandparents) I tend to take for granted what it means.
Vaughn Vernon이 자라온 환경에는 제품을 개발하는 일을 자연스럽게 여기게 하는 배경이 있었다고 합니다. (부럽네요)
제품 사고방식이 있는 개발자와 주어진 일만 하는 개발자
Vaughn Vernon도 이분법을 활용 하네요.
When working with developers I can very quickly see those who have a product mentality and those who are still just working on tasks in a backlog; not that a backlog isn't important.
무슨 말이냐구요? papago 번역을 보고 제가 소화한 내용을 말씀드리겠습니다.
번역 결과는 ‘밀린 업무'라는 표현이 이해를 어렵게 하네요. 'tasks in a backlog'를 백로그에 있는 업무라고 이해해야 합니다. 백로그에 있는 업무가 중요하고, 백로그에 없는 업무는 중요하지 않다고 여기는 개발자가 하나의 부류입니다. (일상 표현에서는 '밀린 업무'가 어울릴 수 있는데) 여기서 이분법으로 강조한 구분은 주어진 일 혹은 누군가 시킨 일만 하는 개발자와 제품 사고방식(product mentality)이 있는 개발자의 구분입니다.
앞서 말한 대기업 개발자들, 혹은 외주 개발을 하는 개발자는 계약 구조 자체가 주어진 일을 하게 되어 있습니다. 그러한 환경적 맥락을 간단히 요약하면 아래와 같습니다.
대기업 전산실은 (제품 개발이 아니고) 다른 업무를 지원하기 위해 출발했다. 고로 고객과 사용자가 다른 부서 동료다.
대기업은 외주 개발 프로젝트를 발주하고, 외부 개발업체가 수행하기 때문에 계약에 근거해서 시킨 일을 개발해야만 한다.
시장 검증을 해보기 전에 계약 종료를 위해 이해관계 차이나 견해 차이로 옥신각신하지만, 아직 사용하기 전이라 제품 품질에 대한 고민과는 성격이 매우 다르다.
이런 맥락에서 경력을 보낸 개발자는 간단히 말해 제품 사고방식(product mentality)을 갖추기 어렵습니다.
제품 사고방식이란 무엇인가?
The quality to detail and seeing things from the user/consumer PoV shines through.
품질의 원천은 사용자 혹은 소비자의 관점(PoV는 Point of View의 약자입니다)에서 볼 때 빛을 발합니다.
제품 사고방식이 무엇인지 암시하는 표현이네요. 사용자 혹은 소비자의 관점에서 보라는 듯합니다. 제품 사고방식이 부족하면 무슨 일이 벌어지는지 단적인 예를 듭니다.
Generally those lacking a product mentality are perfectly fine with releasing bugs because they don't test for obvious limits and exceptions, and they don't cringe when a user's workflow goes down the toilet.
품질 검사 없이 그냥 내보내는 것이죠. 흔히 버그라 불리는 오류가 잔뜩 있고, 사용자가 열심히 사용한 결과가 쓰레기통에 던져져도 불편하지 않은 것이죠. 사용자와 공감하지 않는 개발자들 말입니다. (요즘 많이 나아졌지만) 공공기관이나 금융권 프로그램을 쓰다보면 느낄 수 있잖아요?
비즈니스 거래와 혈관이 동기화 되도록 하라
제품 사고방식 홍보 혹은 확산에 가장 좋은 방법을 제가 알고 있습니다. 실제로 ‘불감증(?)’ 조직을 바꿔본 경험도 있습니다.
베터코드 설립의 시작이었던 북경의념과기유한공사의 변신, 그때 당시 파트너이면서 동시에 클라이언트였던 법인장님께 제가 가장 먼저 했던 말이 이겁니다.
개발자들이 숫자를 보고 혈관이 반응하는 프로그램을 배포해야 합니다.
직원들이 실력이 없다면서 준비가 될 때까지 내부에만 배포하려는 법인장님의 사고방식에 강한 충격을 주려고, 백화점(당시 도메인은 오프라인 패션기업)에서 소비자가 가장 널리 사용하는 위챗(중국에서 한 일) 쿠폰을 발행하는 일을 첫 번째 과제로 삼자고 주장했습니다. 주장만 한 것이 아니라 두 어달 만에 실제로 그렇게 해서 배포했고, 매일 장애 로그가 떨어지고 백화점에서 오는 항의를 받으면서 조직은 빠르게 변해갔습니다. 사고방식이 실력을 키우도록 장려했습니다. (잔소리는 필요 없었죠. 물론, 고객 연락을 받는 직원과 태연한 개발자 사이의 갈등은 있었습니다.ㅠㅠ )
이 단락은 Vaughn Vernon의 이야기가 아니라 제 이야기이자 베터코드 설립 초기의 에피소드네요.
어떻게 제품사고 방식을 갖출 것인가?
자, 이제 마무리로 갑니다.
Please contact me if you have a very strong product focus and background. I want to meet you, learn from you, and especially so in how you infect others with the product -synapses virus.
이런, Vaughn Vernon의 영업 메시지네요. 그리고 말미에 유기적인 협업과 조직을 암시하는 듯한 의미심장한 시냅스 상호작용 그림을 붙여두었습니다. (papgo 번역은 생략합니다.)
영어로 연락을 못하시는 분에게는 저에게 연락주세요. 한국에는 베터코드가 그 일을 해내겠습니다. :)
아하, 참고로 저는 <소프트웨어를 모르는 대한민국 기업의 위기>란 글의 저자입니다.
지난 디지털 전환 선행 연구
9. 모던 프로젝트 관리
11. 별다꾸와 Z세대의 소비
13. 반도체특별법과 금소법의 등장
