• 

• 

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

라인 증권에 대해서

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

소액으로 투자가 가능

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

내가 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감, 직관력등 그 능력을 이제는 인정해 줄만 하다. 내가 부족한 언어 능력으로 인해 독불장군처럼 고집을 굽히지 않았을 때 철저히 위임하고 맡겨준 그 판단이 맞았다. 한국,일본,미국, 호주등 다양한 곳에서 개발을 했지만 개인적으로는 라인 증권을 개발할 때 일적으로는 제일 재미있었다. 일본의 개발 문화와 비교해 보면 아이러니하다고 생각하는데 사용하는 기술셋들의 화려함이 아니라 본인이 스스로 느끼는 프로젝트 기여도 몰입도 등이 만족도에 큰 영향을 미치는 것 같다.  사실 네이버, 카카오 같은 조직에서도 새로운 서비스를 개발하고 출시하고 성장하는 모습을 처음 부터 보는 사람들은 몇 안되고 그럴 수 있는 사람들은 굉장히 운이 좋은 축에 속한다. 나는 라인 증권에서 느낄 수 있는 익숙함을 뒤로하고 아예 도메인이 바뀌어 버렸지만 가끔은 그곳에서 집중하면서 개발했던 시절이 그립다.

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