라인 증권 프로젝트 회고

한국에서는 크게 알려지지 않았지만 2019년에 라인 증권 서비스를 일본을 대상으로 공개했다. 라인에서 근무한 시간은 길지 않지만 운 좋게 파이낸셜 개발실에 소속되어 정보 벤더(블룸버그, 로이터등과 같은 회사)들과 내부시스템의 연동, 가격 결정 시스템 등 나름 핵심적인 업무들을 1년간 수행했다. 배운 것들을 정리해두려고 했지만, 국제이사에 이직까지 겹쳐서 하루 이틀 미루다가 더 늦기 전에 이곳에 옮겨 본다.

라인 증권에 대해서

2020년 상반기, 코로나바이러스로 실물 경제는 어려워지는데 젊은 사람들은 부동산 시장에서 놓친 기회를 만회해보려고 주식 투자를 늘리고 있다. 일본의 증권 업계도 일본인들의 장롱 속에 된 현금을 어떻게든 주식 시장으로  가지고 오고 싶어 한다. 그러기 위해서 일본 증권 업계가 해결해야 하는 문제들은 수도 없이 많지만, 그중에 라인 증권이 해결하고자 하는 문제는 다음과 같았다.

소액으로 투자가 가능

최근 주식을 시작한 사람들은 잘 모르겠지만 몇 년 전 까지만 해도 코스피는 10주 단위로만 거래가 가능했다. 예를 들어 액면 분할 전의 삼성전자를 사기 위해서는 1,000,000~ * 10, 적어도 천만 원 이상의 현금이 필요했다. (2015년 코스피는 증시 활성화를 위해 1주 단위 거래를 허용했다, 관련기사) 반면 닛케이의 거래 단위는 무려 100주. 닌텐도 주식이 한 주에 4만엔 정도 하니 닌텐도에 투자하기 위해선 400만 엔이 필요하다. 그래서인지 일본에서 주식에 투자하는 사람들은 여유돈을 몇억 씩 굴릴 수 있는 부자의 이미지가 강하다. 일본의 2, 30 대의 사회 초년생들이 주식을 할 수 있을 턱이 없다. 라인 증권은 이를 파고들어 젊은 사람들이 소액 투자가 가능하도록 하는 걸 목표로 했다.

편리한 UI

내가 UI/UX의 전문가는 아니지만 적어도 초심자를 대상으로는 라쿠텐(楽天)이나 다이와(大和)보다는 로빈후드가 제공하는 UI/UX가 몇 배는 사용하기 쉬워 보인다. 라인 증권은 기존 일본 증권사보다 사용하기 쉬운 UI와 손쉬운 거래 플로우를 제공하려고 했다.

로빈 후드

결과적으로 첫 번째 두 번째 모두 장외거래(Over The Counter)를 도입해 시스템을 밑바닥 부터 개발함으로서 해결이 가능했다. 일반적인 주식 거래는 증권 거래소를 통해 이뤄지고 거래 당사자들은 중개 수수료만 증권사에 지불하는 구조다. 장외 거래를 사용해 라인이 미리 선정한 주식들을 보유하고 고객들은 거래소를 통해 타인과 거래하는 대신 라인과 거래를 하게 되는데 그렇게 해서 100주 단위가 아니라 1주 단위 거래는 물론 정규 거래 시간을 지나서 야간에도 거래가 가능해지며 사자/팔자 주문의 흐름도 단순해진다.  더불어 라인도 주식을 보유하고 거래하는 리스크를 지니기 때문에 일반 거래소를 통한 거래 보다는 수수료가 더 붙는다. 이 수수료를 붙인 가격을 상황에 맞게 다양하게 계산해 리얼타임으로 가격을 생성하는 것으로  일본 거래소가 가지는 여러 가지 제약으로부터 풀려나는 것이 가능하다.

일반적인 증권회사의 시스템들이 한국 일본 모두 어느 정도 패키지화가 많이 되어 있어서 계좌 부분을 제외하고는 벤더의 기존 코드를 빠르게 재사용해 개발하는 것이 가능한데 이렇게 새로운 거래 방법을 도입하면 되면 추가적인 개발이 굉장히 많이 필요하다는 점이다. 라인이 이런 모델을 택하게 되면서 사실 개발 난이도도 높아지고 프로젝트가 실패할 가능성도 높아지게 된 것이다. 다음은 추가 개발이 필요했던 내용이다.

  • 라인 증권이 제시하는 팔자/주문 가격 생성
  • 라인이 손해를 보지 않게 하기 위해 다양한 거래 검증 로직 구축 (자세한 내용은 영업비밀)
  • 라인이 주식을 보유할 수 있도록 재고 관리 및 구매 시스템 구축
  • 등등등..

라인 증권의 아키텍쳐 방향성

나는 지금도 그렇지만 절대적으로 이 정도 규모의 새로운 프로젝트는 MSA로 가야 하며 2~3명으로 나누어진 도메인 팀끼리는 API로 대화하며 도메인 개발을 진행하길 원했다.  내가 경험한 모노리스 서비스는 git 커맨드 조차도 쉽게 실행되지 않고 로컬에서 서버를 구동하기 위해선 8기가 이상의 메모리가 필요했으며 제일 중요하게는 배포가 제한적으로 일어날 수밖에 없다는 단점이 있었기 때문에 나름대로 계속 MSA를 주장했다.

그러다 결국은 나와 한두 명의 개발자 vs 나머지 개발자들의 구도가 되었고 어떻게 보면 굉장히 소외감을 느낄 수도 있는 상황이었다. 하지만 결과적으로는 다른 팀보다 훨씬 적은 인원으로 6개월 동안 3개 정도의 서브 시스템을 구현하는 데 성공했다. 단순 곁다리 시스템이 아니라 가격 생성/검증부터 외부 정보 벤더 연결 등 핵심적인 부분이었으며  내가 생각하기에 프로젝트 비용 중에 가장 가성비가 잘 나왔던 영역이라고 생각한다. 오히려 인원이 적어서 멤버들끼리 지식 공유가 잘되었고 의견 충돌도 훨씬 적었던 것 같다. 물론 우리 팀의 개발자들은 모두 한국, 중국, 한국계 캐나다인 등 이었고 나머지 전부는 일본인 팀이었다.  나는 최대한 문서작업을 줄이고 비즈니스 로직은 코드로 표현하는 이상적인 환경을 원했기 때문에 문서 작성을 게을리했지만, 일본인으로 구성된 팀은 문서화를 정말 철저히 했으며 나도 그에 따르기를 원했다. 그래서 프로젝트의 후반에는 많은 시간을 문서작성에 사용한 것 같다.

라인 증권 개발언어

개발 언어는 스프링 기반의 자바를 주로 사용했는데 나는 WebFlux의 도입을 적극적으로 이끌었던 반면 일본인 팀은 사용이유에 대해서 잘 이해하지 못했고 본인들이 기존에 사용해서 익숙한 Spring Web을 사용하길 원했다. 기술 선택에 있어서 익숙함이 그것을 선택하는 유일한 이유가 되어서는 안된다고 생각했고 다른 팀원들이 따라와 주길 바랬는데 사실 그들도 시니어였기 때문에 몇번 충돌이 일어났었다. 프로젝트 진행시에 가끔 본질적인 업무가 아닌 부가적이라고 생각하는 부분에서 시간을 더 잡아먹거나 해결되지 않아서 답답함을 느끼거나 짜증을 내곤한다. 그 당시에는 팀 내 커뮤니케이션을 부가적인 업무라고 생각해 설득에 소홀했던 것 같다. 지금 와서 생각해보면 과연 우선순위가 떨어지는 문제였을까?  팀내에 다수의 사람이 이해하지 못한 상황에서 WebFlux를 그대로 사용했던 결정은 옳았던 걸까? 성공적으로 출시는 가능했지만, 다시 개발하게 된다면 그 부분은 조금 고쳐보고 싶다. 개발자는 코드만 보겠다는 자기 암시에 빠지기 쉬운데 경력이 10년이 넘어가면서부터 팀 내의 소통이야말로 높은 수준의 코드작성 만큼 우선순위를 높게 두어야 할 문제임을 느낀다.

WebFlux를 사용하길 원한 이유는 실시간 가격변동이 푸시 서비스를 통해 이루어지는데  푸시 서비스를 대상으로 리액티브 프로그래밍을 사용하면 동시성 제어가 더 쉬워지고 가독성 좋은 코드를 작성할 수 있다고 생각했기 때문이다. 구현한 코드를 CompletableFutre 등과 같이 Java가 제공하는 비동기 기능만을 가지고 작성했다면 훨씬 이해하기 힘들고 테스트하기도 힘들었을 것이다. 실제 WebFlux의 많은 예제가 증권 거래 시스템을 다루고 있는 점은  기술셋과 도메인이 그만큼 잘 맞는다는 방증이다. 더불어 증권은 특정 시점이 되면 돌아가야 하는 배치 작업이 많았기 때문에 WebFlux를 사용해 작업을 겹치지 않는 부분 작업으로 분리해 동시성을 높일 수 있었다.

라인 증권 개발/배포 인프라

인프라의 경우 클라우드는 전혀 고려하지 못했고 레디스, 엘라스틱 서치, 카프라, MySQL등 을 다양하게 사용했다. 금융 서비스라서 외부에 뭔가 안정적인 느낌을 주기위해서 MySQL을 사용했을 뿐 계좌 시스템을 제외한 증권 서비스는 레디스, 엘라스틱 서치만 가지고도 안정적으로 운용하는 것이 가능하다고 본다. 라인은 자체적으로 아주 대용량의 레디스 클러스터를 운용하고 있어서 노하우도 풍부하고 Lettuce 가 제공하는 리액티브 연동도 아주 마음에 들었다. 하지만 그만큼 잘 운영하기 위해서는 여러 번의 시행착오가 필요했으며 이곳에 사례들을 열거하지 않겠지만 증권 조직 자체에서 SPOF가 될 수 있는 부분을 찾아 이중화하고 에러가 발생해도 쉽게 복구할 수 있도록 시스템을 구성하자는 분위기가 있었기 때문에 많은 좋은 사례들을 발견할 수 있었다.

많은 일본인 개발자들은 쿠버네티스나 도커등을 적극적으로 활용하기를 원했지만 나는 배포가 자주 일어날 수 없는 금융 환경에서 해당 시스템들을 굳이 도입해야 할 이유가 없다고 생각했다. 배포를 위해서는 각 사업부서의 허가를 받는 시스템이 있었는데 배포해야 할 내용을 쫙 늘어놓고 사업 부서에서 배포하는 목적과 리스크 등을 평가하는 방식이었다. 사업 부서의 의견은 중요하고 피드백 루프에 포함되는 것이 필수적이지만 전체적인 배포에 관련한 프로세스는 굉장히 쓸모없는 절차라는 생각이 들었다. 왜냐하면 사업 에서 각 배포의 리스크를 이해하기 쉽지 않기 때문이었다. 결국 시스템의 완결성을 책임지는 조직은 개발팀인데 라인 내부에서는 PM, QA, 개발조직으로 권한을 나눠주는, 내가 보기엔 이상적이지 않은 암묵적인 규칙이 존재했으며 특히 증권 에서는 노무라 출신의 사업 조직까지 겹쳐지며 더욱 혼란스러운 구조가 되었다. (사실 이런 삼권분립과 유사한 이상한 구조는 일본과 한국으로 나눠진 라인 내부의 사정도 기인하는 것 같다)

기타외부 요인

노무라 증권 사람들하고 일해본 것은 굉장히 재미있는 경험이었다. 노무라 증권은 일본 내에서는 최고의 직장으로 꼽히며 직원들도 엘리트라는 인식이 있지만, 역시 오래된 회사답게 웹 서비스 관련해서는 굉장히 뒤쳐져 있었다. 하지만 주식 관련 업무에 관해선 정말 노련하고 능숙한 사람들이 많았으며 기술 부분 쪽 사람과는 다르게 뭔가 시원시원 하기도하고 일본인 답지 않게 의견을 바로바로 개진하는 점도 좋았다. 다만 내가 원하는 서비스 개발 방향과 맞지 않는 의견들을 자주 이야기해 내 매니저는 노무라 사람들로 부터 불만을 들어야 했지만 다행히 끝까지 나를 신뢰해 주었기에 때문에 나와 팀원들은 개발에 집중해 프로젝트를 무사히 마무리할 수 있었다.

사업부분과 가장 대표적인 의견 차이는 정보 벤더 선택시에 있었는데, 나는 당연히 해외 벤더들을 선호했다. 그 이유는 모든 문서가 영어로 잘 되어있고, 높은 수준의 SDK를 보유했으며 회사 자체의 기술력도 훨씬 높은 축에 속했기 때문이다. 그러나 일본 쪽에서는 일본 출신의 벤더들을 선호했고 나를 설득시키기 위해서 굉장히 노력했는데, 나는 일본 회사는 API가 잘 정리되어 있지 않고 개발환경조차 존재하지 않고 심지어 API 문서를 요구하면 사전 두께로 프린트해서 보내주는 회사였다.  나는 일본 벤더를 선택하면 프로젝트 일정이 늦어질 것이다 라고 이야기 했다. 다행히도 나의 반 허풍은 먹혀서 내가 원하는 외국계 벤더가 될 수 있었지만, 릴리즈하고 나서도 집요하게 벤더 교체에 대한 요구를 지속 했다. 사업쪽에서는 벤더의 서포트 조직이 외국에 있는 사실을 엄청나게 못미더워 했고 벤더 쪽에서 개발자 입장에서 이해할 수 있는 작은 실수라고 발견하면 엄청나게 쏘아붙이기 일쑤였는데 보는 내가 안타까워질 정도였다.

해당 정보 벤더 사하고 일하게 되면서 정말 몇억을 줘야 써볼 수 있는 여러 가지 시스템들을 다뤄 보았으며 나름 재미있었다. 장의 움직임을 그대로 재현할 수 있는 도구, 전 세계 모든 회사의 기업 평가 정보를 제공하는 시스템등 관련 업무를 하지 않으면 존재자체를 모를 도구들이 있었으며 그쪽 분야에서 또다른 사업 기회가 있지 않을까 생각도 들었다.

마무리

이것으로 대충 정리를 마친다. 사실 라인에 입사하고 2년도 안 돼서 뛰쳐나오긴 했지만,  매니저의 배려와 운이 적절하게 맞아떨어져서 정말 재미있는 시스템 개발을 해볼 수 있었다.  (1년만에  증권 시스템을 개발하고 출시하는 경험은 흔치 않다)  아쉬운 점으로는 군 생활을 전역 후에 돌아보는 것과 유사하게 프로젝트에 대한 기억이 좋은 추억 위주로 남아서 가끔 팀원들에게 조금 더 협조적으로 둥글둥글하게 대할걸 하는 아쉬움이 든다.  인생 선배들이 자주 하는 조언중에 “Don’t burn your bridges”가 마음에 와닿는데, 회사내에서는 티격태격 주도권을 위해 다투지만 결국 이직하고 나면 같은 업계 사람일 뿐이다. 채용 기준이 무엇 이냐는 질문을 받았을 때 “인상”이라고 대답했던 매니져의 말을 당시에는 농담으로 받아들였지만, 업계 20년 이상의 경력에서 나오는 6감, 직관력등 그 능력을 이제는 인정해 줄만 하다. 내가 부족한 언어 능력으로 인해 독불장군처럼 고집을 굽히지 않았을 때 철저히 위임하고 맡겨준 그 판단이 맞았다. 한국,일본,미국, 호주등 다양한 곳에서 개발을 했지만 개인적으로는 라인 증권을 개발할 때 일적으로는 제일 재미있었다. 일본의 개발 문화와 비교해 보면 아이러니하다고 생각하는데 사용하는 기술셋들의 화려함이 아니라 본인이 스스로 느끼는 프로젝트 기여도 몰입도 등이 만족도에 큰 영향을 미치는 것 같다.  사실 네이버, 카카오 같은 조직에서도 새로운 서비스를 개발하고 출시하고 성장하는 모습을 처음 부터 보는 사람들은 몇 안되고 그럴 수 있는 사람들은 굉장히 운이 좋은 축에 속한다. 나는 라인 증권에서 느낄 수 있는 익숙함을 뒤로하고 아예 도메인이 바뀌어 버렸지만 가끔은 그곳에서 집중하면서 개발했던 시절이 그립다.

곧 라인 증권의 거래소 서비스가 오픈한다는 소식을 들었는데 매니저와 팀원들에게 노력의 열매가 모두 골고루 돌아가길 바란다.

구글과 네이버의 위기

미국과 한국에서 승승장구만 하고 있는 두 회사에게 언제 위기가 올까??개인적으로 페이스북과 아마존의 주가가 그것을 말해준다고 본다.

사용자가 웹서비스를 사용하는데는 두가지 패턴이 있다고 하자. (이커머스 ?쪽에서 널리 쓰이는 구분 법 임)

  • 목적형 ?- 뚜렷한 목적을 가지고 검색을 하는 상황.
  • 발견형 ?- 뭔가 재미있는 상품이나 기사를 발견하고 싶은 상황.

구글은 목적형에, 페이스 북은 발견형에 최적화 되있다고 했을 때 현재까지는 각자 영역에서 잘 하고 있는 모양새였다.

두 회사에게도 위기가 닥칠 수도 있다고 생각한 건 어느샌가 부터 브라우저를 통해 네이버나 구글에 접속하고 있지 않았다는 걸 느꼈을 떄다.

한국인의 경우 스마트폰을 켜서 뉴스를 볼때 습관적으로 네이버나 다음에 접속해서 뉴스를 본다. 나도 이전에는 주로 다음뉴스나 RSS 리더등을 사용해 뉴스를 소비했었다.

하지만 최근에는 뉴스는 거의 페이스북으로 소비하고 있는 것 ?같다. 언론들 사이트와 오피니언 리더들을 팔로잉 하기 시작하면 서 큐레이션 되는 뉴스가 훨씬 더 익숙해진 것이다.

정확히 필요한 정보는 구글이나 네이버를 통해서 검색하지만 돈이되는 정보는 ?1등 업체에서 하게 된 현실도 그렇다. 쇼핑은 아마존을 사용해 검색하고 , 숙박은 에어비엔비나 부킹닷컴에서 검색하고, 이동할 일이 필요하다면 우버나 테슬라의 무인 운전 기능을 사용해서 이동하면 된다. 구글이 20세기의 전화번호부처럼 바뀔 가능성도 있는 것이다.

예를들어 페이스북이 검색 결과의 수준을 높여서 목적형에 최적화된 정보들을 주는 동시에 메신져 플랫폼까지 장악한다면 구글과 대등해질 수도 있다고 본다. 마찬가지로 목적형 쇼핑에 최적화된 아마존도 다른 다양한 서비스들을 통해 목적 + 발견형 으로 나아가려고 하는 모양새이다.

역시 영원한 1등은 없다. 물론 구글하고 네이버도 이 사실을 잘 알고 있겠지만.

 

 

Small meeting /w Bom

정해진 시간을 넘겨 3시간이나 Bom 과 미팅을 했는데,

정리 해둘 겸 블로그에 정리 해놓는다.

한국 사회에 파급력 있는 사람이기 때문에 가까이서 대화를 나눴던 사람으로서 기록을 남겨놓는 것이 좋다고 판단한다.

부정적인 뉘앙스가 있을 수도 있지만 굉장히 긍정적인 경험이었다. ( 부정적이었다면 적지도 않음.)

첫인상은 절대 Good listener 는 아니라는 것,? 굉장히 열정적으로 자기 생각을 주입시킨다.

내부에서는 이런 비젼 공유하는 자리를 부흥회라고 한다. 하고싶은 이야기가 머리 밖으로 쏟아지는 것이 보일정도.

예전보다 효과가 조금 떨어지긴 했지만 여전히 CEO가 일반 직원들과 직접 이야기 한다는 것은 굉장히 고무적인 일이 아닐 수 없다.

다만 그 비젼이나 방향성들이 중간 관리자 (다른 조직보다는 확연하게 적지만 그래도 있다) 들이 공유하지 못하고 있다는 느낌.

이건 Bom 과 중간관리자 모두에게 잘못이 있다고 본다.

감히 직원으로서 판단하자면,

비젼 제시와 공유라는 CEO의 가장 중요한 목표에 대해서는 A+ 를 받기 부족함이 없고

소탈하고 친화력이 있어서 대부분의 사람들한테는 호감을 주는 것 같다,

다만 다소 일방적인 면이 있고, 워낙 말을 많이 하다보니 가끔 직원들에게 허언?으로 들리는 말을 가끔 한다는 것 정도가 단점이라고 하겠다.

그렇지만 한국 어디에서도 찾아 볼 수 없는 CEO는 맞다.

  • 특정 비즈니스( local )은 우리가 아니어도 충분히 다른데서 서비스를 받을 수 있다, 품질도 우리가 퀄리티 못함. 그래서 키우지 않음.
  • 개인적으로는 셀러 페이지 만드는 것은 반대, 고객한테 정말 좋은 경험이 될 것 인가?
  • 업무 중에 자기 이름을 대고 추진력을 높이는 사례가 종종 있는데 , 구체적인 사례들 들어달라
    • 누구를 한명 찾아서 Blame 하려는 것은 아니라 프로세를 바꾸고 싶어서 그렇다
    • 회의 중에 Disagree 하고 끝나면 Commit 해야 하는데 안그런 사람이 너무 많다
    • 측근 중에도 회의 끝나고, 따로 이야기 하자고 하는 경우가 몇번 있는데, 확실하게 no라고 이야기하고 회의떄 이야기 하자고 한다.
  • 정말 우리가 없으면 고객들이 슬퍼할 것인가? 갸갸갸 인 서비스는 필요없다. 확실히 누구보다 좋아야 함
  • 복지는 식당의 위생과 같아서 고민없을 특정 수준만 넘어서면 일하면서 얻는 재미가 더 중요하다.
    • 그러나 현재 별로 재미 없어지고 있는데 그 이유는 무엇인가. ?
    • 커뮤니케이션이 적어서 Why 에 대한 이해 없이 일하기 때문에… 그렇다면 PSI 플래닝을 강화
  • 고객에게 노출되는 쪽이라 보이는 장애가 많아서 실제 업무에 집중하기가 힘듬.
    • 개발자를 많이 채용해서 실제 업무비중을 늘릴 수 있도록 하겠다. ( 리크루팅이 문제.)
  • 프라이스 라인.. 별볼일 없는 회사 였는데, 부킹 닷컴 인수 후 50조 가치가 됨
    • 부킹 닷컴은 SPC 중 Conveninece 로는 제일 가는 회사
  • 채용시에 나이 안물어 볼 것. 나이가 뭐가 중요한가? 사람이 너무 없기 때문에 나이 가려가면서 채용할 수 없음
  • One-way door, Two-way door 의사 결정에 있어서 대부분 Two-way? . 잘 안되면 다시 돌아오면 됨.
  • 개발자를 데려 오기 위해 좋은 방법이 있으면 강구해 달라, 일정 시간을 리크루팅에 쏟으면 좋아질까?
    • 개발자가 굉장히 많은 회사지만 외부적으로 공개하는게 적지만 (기술 Blog 나 컨퍼런스 스폰서등)
    • 우리는 확실히 하이테크 컴퍼니이다 (이부분은 동감) 밖에서 보이기에는 쇼핑몰 하나지만 굉장히 많은 것들을 소프트웨어로 처리함.

자동차와 달리기 경주

알파고가 이세돌을 꺾다 사람들은 재미로 자동차와 달리기 승부를 겨루거나 하지 않는다. 무한도전에서 달리는 열차와 경주하는 일은 있겠지만. 이세돌이 알파고에게 완패를 당한것을 가지고 이세돌이 인간을 대표해서 기계에게 패배한 사람같이 비춰지는 시선이 이해가 가지 않는다. 알파고의 하루가 인간의 36년 이라고 하는데, 이는 이미 인간의 감각을 넘어서는 것이다. IBM 딥블루나 왓슨의 경우 모든 경우의 수를 계산하고 최적의 수를 … 더 읽기