왜 시중은행은 카카오뱅크처럼 못하는가?

이전 글에서 카뱅 신드롬과 차세대 프로젝트란 소제목으로  아래와 같은 내용을 다룬 바 있다.

SNS를 통해 접하는 지인들 소식이나 한국 뉴스를 보면 인터넷 전문은행인 카카오뱅크 이야기가 큰 화제다. 내 또래 소프트웨어 개발자에겐 짜릿한 현상이다. 15년, 20년씩 개발을 좋아해 이 일을 해왔던 이들에겐 도리어 긴 부조리속에서 기대했던 (당연한) 일이 벌어진 것이다. 반면에 소프트웨어 개발을 잘 모르는 대다수 사람들이 이해하기는 매우 어려운 일이 아닐까 싶다. 모은행장이 카뱅처럼 하자고 목소리를 높였다고 하는데, 그 방법을 (아주) 조금이라도 알고 있을까? 모른다면 (아마 모른다는 사실을 모를 수도 있지만) 결과를 빨리 내려하고 조급해하기 보다는 일단 알아가는 과정에 초점을 맞춰야 한다. 안그러면 결과를 내기는 커녕 평생 모르고 인생을 끝낼 수도 있다

여전히 대다수 사람들은 카뱅 현상에 대해 본질을 빠뜨린채 자신이 오해한 바를 여기저기 전파하는 듯하다. 가령, 카뱅에서 쓴 기술 자체에 큰 무게를 두어 사실을 이야기 하는 것도 핵심을 빗나가기 쉽다. 기술 자체가 답이라면, 큰 돈을 들어 상용 솔루션을 도입한 은행들이 앞서 가야 하는 것 아닌가? 기술이 아니라 기술자에 답이 있다. 그 기사를 찾아보려고 검색을 하다가 찾지 못하고 다른 기사를 발견했다. 잘 쓰인듯한 기사( “카뱅의 성공 비결? ‘어떻게‘ 아니라 ‘왜’부터 물었다” )지만, 역시 아주 중요한 사실 하나는 다루지 않았다. 김치찌게 끌이는 레시피를 이야기하면서 정작 김치는 다루지 않고 있다. 김치찌게에 참치나 돼지고기를 넣으면 맛있다고 말한다고 해서 틀린 말은 아니다. 다만, 기술자를 빼고 카뱅과 기존 은행을 비교하는 일은 김치를 빼고 김치찌게 끓이는 방법을 논하는 것이다.

은행은 그동안 무엇을 바꾸어왔는가?

왜 시중은행은 카카오뱅크처럼 못하는가? 결론은 단순하다. 외주 개발에 의존하는 은행 IT 운영방식으로는 절대로 카뱅처럼 할 수 없다. 시중은행이 쉽게 할 수 있는 일은 카뱅 앱을 그대로 따라하는 일회성 모방 정도에 지나지 않는다. 그 다음엔 무엇을 할 수 있는가? 이러한 질문에서 출발한 처절한 성찰과 용기있는 행동없이는 아무 것도 바꿀 수 없다.

은행 창구에서 하는 서비스와 모바일 앱으로 하는 서비스는 본질적으로 다르다. 잠시 생각해보자. 은행에 가면 우리는 고개 숙여 맞이하는 사람을 만난다. 그리고, 어디로 가야 하나 두리번 거리다 보면 키오스크가 눈에 띄기도 하고, 원하는 업무를 안내를 해주는 직원을 만나기도 한다. 줄이 길어지는 것을 피하기 위해 요즘은 번호표 발급이 일반화 되어 있고, 대기 중에 앉아서 쉴 수 있는 쇼파와 지루함을 달래주는 TV나 잡지같은 볼거리가 비치되어 있다.  그런데 이 모든 일은 모바일 앱으로 은행을 이용하는 사람에게는 아무 상관없는 지루한 이야기일 뿐이다. 허나 기존 은행 업무에만 익숙한 베테랑이 모바일 앱 만드는 일에 대해 감나라 배나라 한다면 어떤 결과물이 나올 것인가? 오랫동안 은행 창구는 꾸준히 줄어 왔고, 모바일 앱 사용자는 늘고 있다. 넘쳐 나는 베터랑들이 '감나라 배나라'를 안한다면, 그들이 할 수 있는 새로운 일은 무엇이 있는가? 문제는 이런 심각한 질문 속에서 발견해야 한다.

굴뚝회사가 디지털화 하는데 수많은 영감을 주는 '유저'라는 책이 있다. 그 책 265쪽 내용을 보면, 미국에서도 있었던 이 문제(?)에 대한 명쾌한 힌트를 얻을 수 있다.

커티스^[1]가 그 결과물을 올리자마자, 아메리칸 항공에서 일하는 사용자 경험 전문 디자이너는 이렇게 대답했다. "저희 홈페이지 운영팀은 200명이 넘는 직원들로 이루어져 있으며, 이들은 품질 보증, 제품 기획, 경영 분석, 프로그램 개발, 사이트 운영, 프로젝트 기획, 사용자 경험 등 다양한 분야에 걸쳐 활동하고 있습니다. 아주 많은 사람들이 사이트 관리에 참여하고 있고, 웹 사이트에서 콘텐츠와 기능을 제공하는 방법과 관련해 많은 사람들이 이해관계로 얽혀 있습니다." <중략> 결국 아메리칸 항공은 그 솔직한 디자이너를 해고했다.

솔루션 우선 無전략은 청산해야 할 적폐

전통적인 굴뚝 기업에서 꽤 오랜시간 IT 기획은 Best Practices란 미명하에 유행을 쫓는 일에 편중되어 있었다. CBD, SAP, ITA, ITSM, SOA(Web Services), CMMI, MDM, ... 이름도 다 열거하기 어려운 외산 솔루션이나 방법론은 도입 자체가 목적이 되곤 했다. 이런 접근을 솔루션 우선 無전략이라 할 수 있는데, 전략이 없는 모방이기에 100% 실패한다. 외부에서 도입한 솔루션을 우선시 하기 때문에 조직 내부에 있는 문제가 쉽게 가려진다. 솔루션 회사는 돈을 벌지만 정작 고객(갑)은 원하는 결과를 얻지 못한다. 하지만, 주변을 보면 다들 그러고 있기에 판단 착오를 범한 사람들이 자위하기도 쉽다. 얼마전까지 그런 자위는 큰 위험이 아니었을지도 모른다. 그러나, 네이버나 카카오같은 회사들이 그간 쌓은 IT서비스 노하우로 기존 공룡들이 하고 있던 서비스의 대안을 만들어 낸다면 이야기는 달라진다.

카뱅 신드롬에도 불구하고, 은행들의 행태는 크게 달라지지 않았다. 얼마전에 발견한 기사 하나만 봐도 쉽게 확인할 수 있다. 여전히 기존 은행들은 큰 돈을 들여서 솔루션을 도입한다. 이번에는 빅데이터 플랫폼 구축이다. 무언가 상당히 의미있는 일로 포장 혹은 착각하고 있는 듯하다다. 하지만, 결과는 과거에 다른 솔루션 도입과 큰 차이가 없을 것이다. 이런 시행착오가 계속해서 일어나는 이유중에는 이미 굳건히 자리잡은 시장의 생태계가 있다. 쉽게 말해 수많은 기존 업체들의 먹고 사는 문제가 얽혀 있어 단단한 관행이 만들어져 있다. 앞서 소개한 아메리칸 항공 이야기는 남 이야기가 아니다.

보지 않던 데이터를 보는 것이 먼저

은행에 속한 몸도 아닌터에 남얘기로 비판만 하는 일은 찜찜하기 짝이 없어서 생산적인 마무리를 해보자. 너무나도 당연한 이야기지만, 데이터 플랫폼 구축에서 솔루션 도입이 먼저는 아니다. 물론, 데이터를 쉽게 보려면 솔루션이 있으면 편하긴 하다. 그러나, 그런 솔루션조차 초기에는 오픈소스로도 충분하다. 굳이 돈을 쓰지면, 선수급 기술자 한 두명의 도움이 필요할 뿐이다.

그리고 나서는 과학적으로 데이터를 읽고 시장을 파악하고 다시 대응하는 긴 여정이 기다릴 뿐이다. 우리 서비스에서 시장과 고객 이해를 위해 더 수집할 수 있는 데이터는 무엇이 있는가? 웹을 이용하는 경우 우리는 서버에서 생성할 수 있는 접근 로그를 의미 있게 보고 있는가?  이런 질문으로부터 시작하면 된다.

동료의 서비스 발표회에서 데이터 페더레이션을 설명한 부분

지난 금요일 우리가 개발하는 서비스를 백화점 CIO 모임에서 발표했다. 동료인 발표자가 우리의 데이터 활용을 설명하며 무차별 수집(无差别收集)이란 표현을 고안했는데 너무 훌륭한 표현이라 여기 공유한다.

위 그림에서 원통 아이콘은 데이터베이스 유형을 의미한다. 우리는 모듈^[2]마다 데이터베이스를 갖는데, 개발 당시 판단에 따라 MySQL, MongoDB, MS-SQL 등이 쓰이고 있다. 또한, 접근 로그는 웹 서버에서 표준화한 형식으로 쌓여서 Kafka를 통해 입수하고 있다. 실제 데이터를 담고 있는 솔루션이 무엇이든, 스키마가 틀리고 심지어는 MongoDB처럼 스키마가 없더라도 일괄 수집하도록 한 것을, 그녀는 무차별 수집(无差别收集)이라고 표현했다.

이런 작명 능력은 회사를 혁신하려는 신념에 찬 노력과 부단한 서비스 개선 활동이 있었기에 가능한 일이다. 베스트 프랙티스와 요즘 뜨는 솔루션과 같은 키워드를 띄워놓고, 프로그램 작성을 해본 일도 없는 사람들이 모여서 치밀하게 계획세운다고 할 수 있는 일이 이니다.

주석

[1] 2009년 5월 18일, 사용자 인터페이스 디자인 전문가 더스틴 커티스는 아메리칸 항공에 공개 서한을 보내면서 그 사이트(AA.com)를 자발적으로 다시 설계했다. "얼마 전에 저는 귀사 홈페이지에서 예약을 하면서 끔찍한 일을 겪었습니다. 너무 기분이 상해서 다시는 이용하지 않겠다고 결심할 정도였죠."

[2] 우리는 REST API를 제공하는 웹 서비스를 모듈이라 부른다. 서비스라는 말이 기획단계에서와 개발자들 사이에서 각각 다른 의미로 혼용되는 탓에 가급적 사용자 인식상의 서비스가 아닌 개발자의 마이크로 서비스에 대해서는 모듈이란 표현을 쓰기로 했다.