개념 증명 (Proof of Concept, POC) 유감

Jun Hwang

가성비라는 이름의 모호성

화폐경제 내에서 경제주체인 우리는 날 마다 구매의사결정을 합니다. 가정에서의 개인 소비재 구매로부터 직장에서의 대리인으로서 하는 기업의 소부장과 서비스 등 생산재 구매에 이르기 까지 예외가 없습니다. 이 때, 우리는 '가성비'로 대표되는 유무형의 제품 간 비교절차를 거치게 됩니다. 가격 대비 성능 또는, 비용 대비 효과라는 이 '명검 (the rule of thumb)'은 현대인의 인지체계에 부지불식 간에 확실히 자리잡고 있어서 깔끔한 의사결정을 돕는 것으로 생각하지만, 그것의 헛점은 의외로 쉽게 간과되는 듯 보입니다.

IT 업계에서 어떤 제품이나 솔루션을 구매할 때는 해당 제품이 구매 주체인 기업의 니즈에 부합하는 지를 사전에 검증하게 되는데, 그러한 절차를 '개념 증명'이라고 부릅니다.

이 글에서는 IT 산업 구매의사결정에서 '가성비'에 대한 모호성을 제거하고 조금이라도 나은 선택을 위하여 어떤 의사소통이 필요한 지를 생각해 보려 합니다.

전자상거래 사이트나 대형 마트의 제품 가격표는 단위당 가격을 표시하고 있습니다. 마트의 육류 가격표는 소비자가 어느 제품의 가격이 낮은 지를 비교하기 쉽게 도와주는 중요한 정보입니다. 육류의 경우에 100g 당 가격이 중요한 정보인 것은 맞지만 현명한 소비자는 원산지도 비교하지 않을까요? 올리브 오일은 100ml 당 가격으로 표시됩니다. 이 경우라면 우리는 제품이 엑스트라 버진인지, 콜드 프레스드 인지를 비교합니다. 이처럼, 숫자로 표시되는 가격 정보는 중요한 정량적 (quantitative) 데이터로서, 다른 연관 데이터는 제품의 성격을 규정하는 정성적 (qualitative) 정보로서 의사결정의 핵심 포인트가 됩니다.
그런데, 와인은 어떤가요? 액체임에 틀림 없지만, 어디에도 100ml 당 가격을 표시하지 않습니다. 대신에, 그 와인의 주재료인 포도의 종류 및 원산지, 바디, 맛, 숙성 방법 등등 아주 세세한 정성적 정보를 표시하고 있습니다.

IT 제품과 서비스의 구매절차

SaaS (Software as a Service)가 등장한 이래, 클라우드는 지난 10 여년 에 걸쳐 소프트웨어의 생태계과 유통 구조를 완전히 바꿔 놓았습니다. 제품과 솔루션은, 이제 더 이상 인쇄된 매뉴얼과 함께 패키지 된 상태로 제공되지 않습니다. 대신에, 해당 제품이나 솔루션을 제작사의 웹사이트로부터 다운로드 받고 라이선스 키를 메일로 전달 받는 형식이 대부분입니다. 공산품과 마찬가지로 가격 정보는 벤더를 통하여 쉽게 알 수 있지만, 그 제품의 정성적 (qualitative)인 정보를 얻기는 꽤나 까다롭습니다. 해외 제품인 경우 언어 접근성 등의 여러 원인이 있겠으나, 가장 큰 이유는 제품이나 솔루션이 제공하는 너무도 다양한 기능 때문입니다. 게다가, 그런 제품과 솔루션이 이제는 '정물'이 아니기 때문입니다.

SaaS의 등장 이전에는 표시된 가격으로 해당 제품의 패키지를 구매하고 나면 해당 제품은 버그 수정을 제외하고는 거의 납품상태 그대로 생명주기를 끝냈던 반면에, 이제는 구독 (subscription) 방식으로 최초 구매 후 매 1년을 기준으로 새로운 상태의 제품을 구매하게 되는 것입니다. 그 뿐 아니라, 좀 더 들여다 보면, 실제로 해당 제품이나 솔루션은 구매된 그 날부터 더 이상 같은 제품이 아닙니다. 소프트웨어 제작사는 끊임없이 기능을 추가하고 개선하면서 중단없이 제품을 바꾸고 있으며, 이는 소프트웨어가 무형의 자산이라는 특성 때문에 태생적으로 유형의 제품과는 다른 영역에 속하는 때문입니다.

아마존 웹서비스가 정물이 아니라는 데에 다른 의견이 없을 것입니다. 마찬가지로, Tyk (타이크) APIM도 실제로 생물로서 진화하는 것이며, 단지 릴리즈 될 때의 버전 넘버로 대표되는 일련의 스냅샷을 가지는 것 일 뿐, 고객들은 Tyk를 언제든지 인터넷을 통하여 새로운 버전으로 업데이드 할 수 있습니다. 구매할 시점의 아반테가 언제든지, 구매한 라이선스가 만기 도래하기 전에, 제네시스로 바뀔 수 있다는 것을 유념하십시오.

인식의 전환

변화는 '선형 (linear)' 이라는 말로 대표 됩니다. 어떤 변화가 기존의 틀을 벗어 날 때 우리는 그것을 '이동 (shift)'라고 추상화 합니다. 이동을 넘어 전체 판이 뒤바뀔 때 '패러다임 변화 (paradigm shift)'라고 합니다. Jeff Bezos의 AWS는 인식의 대전환을 요구해 왔고, 더 이상 우리는 클라우드 서비스를 고정된 대상으로 생각하지 않습니다. 이제는 아마존 뿐 아니라, 아무리 작은 스타트 업의 작은 제품, 솔루션, 서비스들이 모두 'API'라고 하는 작은 생명체의 집합이라고 생각해야 할 때 입니다.

아르고 퍼시픽 (Argo Pacific) 은 Tky의 설립 초기부터 같은 숨을 쉬면서 변화를 수용하며 고객과 함께 리듬을 조율하고 있습니다.

변화된 패러다임에서의 POC

AWS에서 엄청난 규모의 새로운 서비스를 시도 때도 없이 론칭하는 것이 이제는 그리 놀랍지 않은 일이 되었습니다. Tyk Technologies 사도 APIM을 개선하고 확장시키는 일에 관해서는 뒤지지 않습니다.

여러분들은 어떻게 와인을 고르시나요?

어떤 맛과 향의 와인을 찾고 계시는지, 구매자인 여러분들을 빼고 나면 누가 알 수 있을까요?
시장에 API Gateway를 제공하는 개발사는 몇 되지 않습니다. 하지만, 미세한 구성 (configuration)을 통해 서비스 될 수 있는 API 게이트웨이의 조합은 어쩌면 와인의 종류 만큼 다양해 질 수 있습니다. 때문에, API 게이트웨이를 선정하는 작업은 정교해야 합니다.

제가 굳이 와인을 예로 든 이유는; 첫째, 와인에 대한 자신의 취향을 자신 보다 잘 아는 사람은 없다고 생각하기 때문입니다. 심지어, 최애하던 와인이 엊그제 곁들인 음식과 살짝 안맞던 그런 경험까지 더해지는 경우라면, 숫제, 우리는 소믈리에가 필요한 지경에 이릅니다. 둘째, 바로 이 첫 번째 이유 때문에, 솔루션 제공자와의 지속적인 소통이 너무도 중요한 때문입니다.

앞에서 언급한 것처럼, Tyk는 지속적으로 무한변신 중 입니다. 단언컨대, 분기 마다 새로운 제품이 릴리즈 되며 새로운 기능과 향상된 퍼포먼스를 탑재하고 있습니다. 이런 변화는 하루가 다르게 바뀌는 기술표준의 진화를 수용하기 위한 Tyk사의 노력의 반영입니다. 진화되고 정제된 기능들을 고객사의 요구사항에 반영시키기 위해서는 제품 도입의 초기단계에서부터 유기적인 커뮤니케이션이 필수입니다.
여러분들의 취향을 상담하여 주십시오. APIM에 대하여 훨씬 더 정교한 접근법을 제시하여 드리겠습니다.

유감, The

아시는 분은 이미 아실테지만; 시스템의 고도화나 개편을 위한 프로젝트에서 현재 상황 (As-Is)과 니즈를 모르고는 제대로 된 해결책을 제시하는 것이 어렵습니다. 하지만, 그간의 경험을 비추어 볼 때 중재자로서의 역할은 녹녹치 않았는데, 주된 이유는 As-Is를 알려 주지 않기 때문입니다. 정보 보안의 관점에서 저간의 사정을 짐작은 하지만, 태부족인 정보와 정보공유에 대한 소극적인 접근은 컨설팅에 아주 큰 걸림돌이 되었습니다. 때로는, 이러한 정보의 비대칭성이 조직 내부의 일부 이해당사자의 정보 독점을 초래하여 조직 내에서 대리인 비용을 발생시킴으로써 효율적인 시스템 개편을 방해하는 요소로 작동됩니다.

새로운 프로젝트의 착수 시에 귀사의 통점 (Pain Points)과 To-Be 요구사항을, 그리고 도입을 검토하기 위한 개념 증명 (POC)의 요구사항을 공유할 수 있어야 문제점을 해결할 수 있습니다.