Series C StartUp(시리즈 C 스타트업)

이번 회사에서는 면접 자리에서 연봉협상을 통해 헨드헌터와 이야기 했던 연봉 보다 낮춰진 체로 입사하게 되어 떨떠름 했지만 그래도 기존 연봉보다는 20% 넘게 올렸기 때문에 그걸 위안 삼기로 했습니다.

2019년 10월부터 2022년 9월까지 거의 3년을 근무한 회사의 경험입니다.

입사일

처음 출근 하기 전 영어 이름을 정해야 했습니다. 이번에도 이전에 정한 익숙한 이름 알렉스로 정했습니다.

출근해 보니 정해져 있는 자리가 있었습니다. 그리고 OT가 시작됐다. OT는 다른 스타트업과 비교해 독특하게 개발과 상관없는 모든 부서의 장들이 직접 부서 업무에 대해 소개해줬습니다. (알고 보니 개발과 굉장히 밀접한 부서들이었습니다.)

OT를 거치면서 부서장 분들이 직급과 상관없이 서로 편하게 말할 수 있는 분위기인 것을 강조해 좋은 인상을 받았습니다.

내가 속해 있던 개발팀은 CTO인 브라이언과 내 또래의 프론트엔드 개발자 휴버트가 있었고 샘이라는 개발자는 신사업팀으로 따로 팀이 있는 상황이었습니다. 개발자가 3명인데다가 말도 잘 통해 보이고 나이대도 비슷해 든든했습니다.

자기 일만 제대로 한다면 쉬는 시간도 자유롭고 영어이름을 쓰며 높은 직급에도 격의없이 서비스에 대해 논의하고 개발자에 대해 존중해주는 수평적인 분위기가 보였고 회사에 대한 기대가 생기는 첫 날이었습니다.

회사의 과거 이야기

OT가 끝나고 휴버트는 프론트엔드 소스를 공유했습니다. 본인이 맡고 있는 프론트엔드부터 같이 해보자고 해서 본격적인 업무를 시작하게 됩니다. 소스를 보니 typescript, react로 구성된 웹이었고 회사의 앱은 react-native에 웹뷰를 띄워 거의 모든 동작은 웹뷰에서 이뤄지게 만들어져 있었습니다.

react-native 소스도 받았지만 수정을 안 한지가 거의 6개월이 지난 상태였습니다. 그리고 react-native로 앱 스토어에 배포한 경험이 있는 사람도 회사에 없었습니다. 알고 보니 내가 들어오기 1달 전 제이드라는 개발자가 앱을 맡고 있다가 인수인계 없이 퇴사를 했다고 합니다.

점심 식사를 하면서 회사의 과거 이야기를 듣게 됐습니다. 사실 회사에는 개발자 숫자가 거의 15명이 될 정도로 개발인원이 많았었는데 투자 유치 및 개발 산출물의 반응이 좋지 않아 적자에 허덕였고 그 때 퇴사 권유를 받아 대부분 퇴사하게 되고 개발자 샘과 보험 데이터 기획자 에릭이 남게 되었다고 합니다.

그렇게 남게 된 샘은 조금씩 작은 개발 관련 일처리를 하다가 회사에 투자 유치가 되서 에릭과 함께 보닥이라는 서비스를 만들기로 했고 그 서비스를 만들기 위해 개발자들을 채용하게 됐습니다. 그 때 뽑은 인원이 휴버트와 제이드였고 휴버트는 프론트엔드, 제이드는 앱 및 서버 구성, 샘은 백엔드를 담당해 훌륭한 합을 보여줬다고 합니다.

에릭과 개발팀들은 열심히 목적을 향해 나갔고 앱을 출시하고 유지보수하며 잘 운영해 회사의 캐시카우가 되었습니다. 그런데 앱이 성공적으로 출시되고 회사가 안정된 돈이 들어오게 되면서 다른 투자들을 더 받기 위해 새로운 시도들이 계속 요구됐는데 이 과정에서 샘과 경영진 간 마찰이 많았다고 합니다.

샘은 개발자 입장, 경영진은 투자를 받기 위한 입장이기 때문에 마찰이 있을 수 있었지만 경영진이 샘을 컨트롤하기 힘들어졌다 생각해 추후 더 큰 개발팀이 되면 뽑으려 했던 CTO를 급하게 고용했다고 합니다. CTO는 나를 면접 봤던 브라이언이었고 브라이언은 경영진이 원하는 바를 빠르게 도입할 수 있는 체계를 만들기 위해 현재 개발된 내용들을 모두 단순화하기 위해 다 갈아치울 거라고 말했습니다.

브라이언은 처음에 앱의 규모만 보고 혼자 모두 새로 만들어도 2~3개월이면 될 듯이 말했고 경영진은 이것을 믿어주고 힘을 실어줬습니다. 하지만 샘은 이런 브라이언의 태도를 가만 볼 수 없었고 브라이언의 원하는 바를 해주지 않았고 여전히 강경한 입장을 고수하고 있었습니다. 그렇게 샘과 틀어진 브라이언은 남은 2명과 샘을 이간질하고 샘을 팀에서 추방해 샘과의 대화를 통제하기 시작했습니다.

하지만 3명은 이미 개발 합을 맞추며 깊은 관계였고 이 모든 것은 3명 모두의 반감을 사게 됩니다. 브라이언은 애초에 CTO로 입사할 때부터 실무를 하려 한 게 아니었기 때문에 개발자들의 도움이 필요했는데 그나마 말을 좀 들어주던 제이드와 휴버트에게 일을 시켰지만 브라이언이 급하게 설계한 데이터베이스와 백엔드는 아주 많이 수정이 필요했고 이에 2명 또한 지쳐갔습니다.

브라이언은 3명 모두의 신임을 잃었기 때문에 경영진에게는 3명이 돕지 않아 문제가 된다며 그들 탓을 계속 반복 했지만 일정 압박을 받았고, 이 때부터 회사에서 자유롭게 사용하던 개발자들의 연차까지 반려시키기 시작했습니다. 이로 인해 제이드는 사적으로 안 좋은 상황에 처하게 됐고 그로 인해 바로 퇴사하게 됐다고 들었습니다.

그래서 회사에서 사용중인 서비스들의 계정 관련 정보들, 배포 프로세스, 앱 배포 등을 아는 사람이 없는 상황이었습니다. 생각보다 심각한 상황이었습니다. 배포체계에 갑자기 문제가 생긴 상태에서 급하게 서비스에 이슈가 생긴다면 그걸 고치기 위해 전체 프로세스를 새로 만들어야 할 수도 있었습니다.

브라이언은 저와 샘과의 대화를 지속적으로 막았습니다. 브라이언 때문에 신사업팀으로 배정돼 업무에서 배제된 샘이 사실은 회사의 모든 백엔드 내용을 알고 있는데 대화를 할 수도 없고 불편하고 난감한 상황이었습니다.

퇴사 레이스

입사했을 때부터 샘은 퇴사 일정이 잡혀 있었습니다. 업무를 배제시키고 경영진 또한 CTO에게 힘을 실어주고 있으니 샘도 회사에 있을 이유가 없어 보였습니다. 하지만 샘에게 배우고 싶어 회사에 남아있었던 휴버트는 샘이 나가면 나가겠다고 했습니다. (샘은 개발 능력이 아주 뛰어난 개발자였습니다.)

CTO는 해내겠다고 한 일정보다 6개월이 더 걸려서도 일을 해내지 못했고 게다가 모든 팀원들이 퇴사 의지를 밝혀 찰스에 의해 결국 강제 퇴사를 당하게 됐습니다. CTO가 퇴사 당했지만 회사에 질려버린 샘도 거의 비슷한 시일에 일정대로 퇴사했고 휴버트는 간단하게 웹뷰에 대한 배포 방법을 알려준 뒤 샘의 소개로 다른 회사에 추천되어 이직을 성공하게 됩니다.

퇴사하기 전 샘과 휴버트는 경영진에게도 많은 상황 어필들을 했으나 모든 것들이 소용이 없었다고 생각해 회사에 실망을 한 상태였기 때문에 마음을 돌리 수도 없었습니다. 그렇게 결국 다시 개발팀에 혼자 남게 됐는데 그래도 에릭이 이전 개발에 대한 히스토리를 알고 있어 옆에서 많은 도움을 줬고 유지보수에 많은 도움이 됐습니다.

유지보수

프론트엔드

react, typescript로 구성된 서비스는 대부분 웹뷰를 통해 독특하게 구성되어 있었습니다. 프론트엔드에서 api를 사용하기 위해서는 백엔드 개발 시 같이 배포하는 api용 타입 라이브러리를 npm에 배포하고 이것을 프론트엔드에서 업그레이드해 사용하는 패턴을 취하고 있어 양 쪽의 오류를 덜 수도 있었지만 혼자 있는 상황에서 많은 일을 빠르게 개발할 때 불편한 족쇄 중 하나였습니다.

게다가 소스를 보면 react-router, redux, react 기본 기능인 state 관리, UI컴포넌트 등을 모두 JS로 직접 만들어 사용했는데 설정 방식도, 기능도, 성능도 모두 좋지 않았습니다. 하지만 혼자 남은 상황에서 패턴을 모두 변경하고 새로 개발하기엔 버거웠기 때문에 패턴에 맞춰 개발했습니다. 독립적으로 변경할 수 있는 부분들만 다른 개발자들도 좀 더 익숙한 형태로 변경해 나갔습니다.

앱

react-native, typescript로 구성된 앱은 앱에서 구동되는 광고용, 비지니스용 트랙킹 라이브러리들, 딥링크들을 사용하기 위해 구성되어 있고 앱의 가장 주요 기능 중 하나인 신정원 회원가입, 로그인, 스크랩핑을 위해 필요했습니다.

나머지는 웹뷰에서 구현되어 있기 때문에 사실 앱 UI는 아무것도 없는 빈 껍떼기에 불과한 상황이었습니다. 하지만 이 시점부터 react-native는 빠르게 업그레이드 되고 앱스토어, 플레이스토어의 정책 변경과 웹뷰가 많은 앱에 대한 심사가 까다로워지는 등 이슈들은 계속 생겨났습니다.

앱에 익숙하지 않고 스토어에 배포까지 해 본 적은 없어서 좀 더 앱에 익숙해지기 위해 열공하고 이슈도 해결해 나갔습니다. 직접 토이 프로젝트 앱도 스토어에 배포해 보고 테스트도 하면서 조금씩 앱에 대해 익숙해져 갔습니다.

메인 Api

메인 Api는 모두가 퇴사하고 나서 유지보수를 하면서 처음 보게 됐습니다. 회사의 모든 언어 스택이 typescript로 알고 있었는데 사실은 아니었습니다. 깃허브를 열심히 뒤져보며 찾게 된 실 구동중인 소스는 php laravel로 구성된 백엔드였습니다.

php는 아예 처음 들어본 상황인데, 유지보수는 급했고 소스를 열심히 읽어가며 무작정 Larabel의 패턴을 익혀 패턴에 맞춰 개발했습니다. 배포 방법은 에릭에게 질문하고 readme에 적힌 내용을 토대로 테스트하며 결국 배포할 수 있게 됐습니다.

php로 로컬 환경을 구성하는 법도 모르던 상황에서 빠르게 유지보수를 해야 했기 때문에 당시에는 빨리 고치고 테스트 환경에 배포해 테스트 앱에서 확인한 후 실 서비스에 바로 반영 했습니다. 지금 생각해 보면 얼마나 불편하고 무서운 행동이었는지, 당시에 고객이 많지 않아 실수했을 때 얼마나 다행이었는지 모릅니다.

엔진

메인 Api는 개발 문서에 적힌 ERD상에 있는 데이터베이스에 있는 내용들을 가져와 보여주거나 상담신청에 대한 플래너 배정 정도를 담당하고 있었습니다.

사실 이 앱의 핵심은 엔진에 있었는데 엔진은 typescript, expressjs로 구성됐습니다. 앱, 웹, 엔진에 공통적으로 보이는 데이터 구조를 만들거나 다루는데 사용하는 라이브러리가 보였습니다. 알고 보니 퇴사한 샘의 개인 npm repository에 있는 라이브러리였습니다.

샘의 개발 구성 방식은 MS사에서 개발하는 방식을 따랐다고 하고 C++ 개발자 출신이라 전형적인 Typscript 개발과 다르게 굉장히 체계적이고 작은 기능에도 규모가 컸습니다. 사용 방법이나 코멘트들도 적혀 있지 않아 아주 많은 것을 상속 받으며 정의되어 있는 기능들이 어떤 기능인지를 찾는데 많은 고생이 필요했습니다.

샘의 개인 라이브러리드들은 모든 소스에서 속속들이 사용하고 있어서 걷어내려면 마치 앱을 새로 만드는 듯한 정성이 필요했습니다.

엔진은 보험 데이터를 통해 도출된 머신러닝 데이터와 고객의 보험 데이터 간의 수식을 통해 점수를 산출하는 진단과 수 많은 보험 데이터들 간 조합 알고리즘을 통해 도출되는 최적의 보험 상품 조합을 도출하는 추천 기능을 가지고 있었습니다.

앱의 가장 중요한 기능 2가지를 담고 있는 회사의 코어 자산이었습니다. 엔진 소스는 백엔드랑은 비교도 안되게 복잡하게 구성되어 있었고 엔진 기능 관련 api를 제공하는 서버와 코어 기능이 담긴 라이브러리, 그리고 보험 데이터를 조작하고 관리하는 펙토리 기능 이렇게 3가지 소스가 나눠져 있었는데 제대로 이해하기까지 3개월 정도 시간을 쏟았던 기억이 납니다.

클라우드

클라우드 구성은 AWS에 2계정으로 관리되고 있었습니다. 첫 번째 계정은 메인 api와 웹뷰, 데이터베이스 서버 등이 구성되어 있었고 두 번째 계정은 엔진이 구성되어 있었습니다. 구성된 상태는 ELB에 ACM을 연결해 ssl을 연결했고 EC2들이 ELB에 연결되어 있었습니다.

EC2에서 서버는 http로 동작해도 ELB에 연결되기 때문에 따로 https 설정을 할 필요는 없었습니다. 도메인은 이미 구매되어 있어서 route53 서비스를 통해 연결되어 있었습니다.

AWS의 서버구성 방식은 간단히 구성되어 있었고 걱정했던 것보다 조작하거나 구성하기 쉬웠습니다. 엔진의 경우 Api를 통해 업데이트하도록 설계되어 특정 패스로 api 요청하면 워커들을 하나씩 업데이트 해가며 코드 레벨에서 blue-green(무중단 배포)이 실행됐습니다. 덕분에 배포 시 편하게 api 요청만 하면 끝이었습니다.

하지만 메인 api와 웹뷰의 배포 방법은 굉장히 불편했습니다. 프론트엔드 소스의 개발을 마무리 한 후 라이브러리로 빌드해 npm에 배포한 뒤 이를 Laravel 백엔드에서 설치해 폴더별로 path를 지정하여 웹에 포팅했습니다.

그렇게 백엔드 소스와 한 몸으로 만든 뒤 사설 깃랩 서버에 올리고 깃랩 내에 설정해둔 대로 로컬에서 명령을 날리면 vagrant와 virtualbox가 실행되면서 이미지를 만들고 이 이미지를 운영중인 서버로 설치해 배포되게 됩니다. 과정을 알아내는 것도 힘든 과정이었지만 오류도 잦았고 해결을 위해 많은 시간을 소비했던 기억이 납니다.

지금 생각해 보면 Docker와 ECR을 활용했다면 보다 빠르고 효율적으로 관리하면서 고생을 덜 수 있었을텐데 그 때의 나에게 돌아가 알려주고 싶습니다.

문서 작성

회사에 개발자로서 혼자 남아 있는 상태에서 경영진은 개발 산출물들에 대한 정보를 지속적으로 나에게 요구하고 있었습니다. 이미 퇴사한 개발자들이 정상적으로 뒀는지 염려가 많이 됐던 모양입니다.

개발 소스들과 많은 서비스 계정들, erd, 클라우드 구성 등이 대부분 문서로 되어 있지 않았고 제대로 되어 있지 않은 것들이 많았습니다. 이전에 남겨놓은 문서들은 대부분 경영진에게 그럴싸하게 보이기 위해 브라이언이 만들었던 as is, to be 문서 였고 심지어 틀린 내용도 수두룩했습니다.

유지보수를 하기에도 어차피 한번 정리가 필요했기 때문에 이왕 정리하는 김에 제대로 해서 다음 개발자들도 적응하기 좋도록 체계적으로 정리하고 싶어졌습니다. erd 구성부터 백엔드로직, api 문서 등 개발에 대한 정리를 시작했고 문서화해 나갔습니다. 소스와 구성들을 보면서 사용 중인 계정들을 더 알게 되고 사용 중인 계정과 패스워드들을 문서에 작성해 경영진들과 에릭에게 공유했습니다.

그리고 찰스가 이해하기 좋도록 클라우드 구성, 서비스 플로우, 배포 프로세스 등을 도식화 해 설명했고 이를 활용해 경영진들에게 현재의 산출물들의 체계를 제대로 알릴 수 있었습니다.

이후로도 정리하는 습관이 생겨 이슈 사항에 대한 리포트하는 법부터 설계 시작 단계부터 마무리까지의 과정들까지 정리했습니다. 이 정리들은 추후에 많은 공통 이슈들을 해결할 때 자주 찾아보며 사용하게 됐습니다.

신규 프로젝트

1년 치 요구사항

기존에 있던 개발자들과 CTO 간의 다툼으로 경영진들과 마켓팅 부서에서는 하고 싶은 일들이 넘쳐났지만 진행하지 못했던 수 많은 일들을 진행하고 싶어했습니다. 작은 일들은 유지보수를 하며 조금씩 요구사항들에 맞게 수정했지만 추가 기능들에 대해 요구가 계속 많아졌고 결국 프로젝트가 되어 돌아왔습니다.

그렇게 버겁게 유지보수를 하면서 프로젝트들을 시작하게 됐습니다. 회사는 기본적으로 인슈어테크 회사이고 결국 목적은 상담을 많이 유도해서 고객 계약을 따내는 것인데, 설계사분들은 모두 자영업이고 회사가 아닌 개인적으로 아는 고객들이 많았는데 이들의 상담과 계약 건도 앱과 연동해 진행하길 원했습니다.

그렇게 플래너분들의 개인 고객들을 연결해 플래너 개인 고객들에 대한 기능을 넣어주기 위한 앱 내, 관리자 앱의 기능을 추가해 주는 것이 필요했습니다.

또 필요한 기능으로 청구 기능이 있었는데, 당시에 청구는 실손 관련 간편 청구만 구현 가능했고 대부분의 인슈어 테크앱에서 이미 구현해 놓은 기능이었습니다. 우리도 기본적인 청구 기능을 구현하겠지만 늦게 출시하는 만큼 다른 앱들과는 다른 포인트가 필요했습니다.

연구 끝에 청구하려는 내용에 해당하는 청구 관련 분쟁조정사례를 보여 주고 청구 시 참조할 수 있도록 해주는 간편한 청구에 심화적인 내용을 정보로 주어 조금 어려운 청구 기능의 경우 플래너들이 직접 청구를 돕거나 이것을 기회로 보험 상담을 진행할 수 있게 하는 기능이었습니다.

에릭과 함께 기획이 끝났고 앱과 웹, 백엔드에 적용해야 할 아이템들을 검토해 기간을 산출했고 이를 통해 계획을 세워 프로젝트의 가닥이 잡혔습니다.

이 외에도 앱 내 게시판, 공지 기능 추가와 에디터 적용 등 많은 기능 추가들이 있었지만 회사의 개발자는 혼자였기 때문에 업무 배정, 협의에 대한 시간 소요 없이 빠르게 처리할 수 있어 모든 일들이 빠르게 테스트까지 마무리 되고 앱 심사까지 성공적으로 런칭할 수 있었습니다.

신규 엔진 개발

회사에서 가장 중요한 코어 기능을 엔진 서버에 구현해 뒀는데 핵심 기능으로 보험 진단과 추천이 있었습니다. 하지만 기존에 만들어 놓은 엔진은 백엔드와 너무 의존적인 관계여서 독립적으로 서비스할 수 없었습니다.

불필요한 동작, 재동작들이 너무 많아 성능이 좋지 않았고 이로 인해 보험 진단 한번에 1분이 넘는 시간이 걸릴 때도 있었습니다. 심지어 ERD를 공유하면 복잡한 DB 구조로 인해 신규 인력들이 적응하는데 이것이 허들이 될 정도였습니다. 게다가 구조 상 모두 엮여 동작해 엔진을 조금 수정하면 서비스 전체에 영향을 끼칠 정도였습니다.

여러 불만들이 취합되어 결국 새로운 엔진을 만들게 결정이 됩니다. 보험에 대해 잘 알지 못했던 당시에 나는 보험을 진단하는 과정에 대해 온전히 이해하지 않고 코드상으로만 이해하고 있었습니다. 다행히 동료 중 에릭이라는 보험 설계사 출신 데이터 기획자 분이 있어 같이 엔진을 설계해 나갈 수 있었습니다.

우선 서비스에서 쌓여 있던 수 많은 진단 정보와 신용정보원 데이터 등을 취합했고 그 데이터들을 가공해 데이터 포맷과 피쳐들을 일원화했습니다. 데이터를 분석하면서 플래너들, 에릭과 상의해 보험의 여러 특성들을 도출했고 이를 통해 5가지 특성을 이용해 점수화하자는 기획이 섰습니다. 수동과 자동을 섞어가며 플래너 분들과 함께 데이터를 라벨링하기 시작했습니다.

라벨링 된 데이터를 통해 머신러닝 모델을 만들고 계속된 검증과 성능을 높이기 위한 작업을 진행했습니다. 결국 정확도 높고 원하는 결과를 도출하는 모델을 만들어 낼 수 있었습니다. 그렇게 엔진 코어 기능 중 하나인 진단 기능을 완성했고 그 외 추가적인 요구사항들인 관련 집계 기능, 차트 데이터 등을 완성해 가며 보험 진단을 마무리 했습니다.

보험 추천은 보험의 여러 특성들을 토대로 최적의 보험 패캐지를 찾아내는데 집중했습니다. 현재 판매중인 보험사들의 상품 정보를 모아서 그 데이터를 통해 고객인 원하는 보장 및 보장금액을 가진 최저가의 보험 패키지를 만들기 위해 bin packing 등의 알고리즘을 도입해 일반적인 방식으로는 감당할 수 없는 경우의 수를 쪼개 프로그램으로 감당할 수 있게 만들었습니다.

그렇게 보험 상품의 조합으로 고객의 요구 사항에 맞는 보험 패키지를 최저가로 찾아주는 보험 추천 기능을 완성했고 그 외에 원하는 보험사로 추천을 받는 기능, 신뢰도 있는 보험사로 추천받는 기능 등의 커스텀 동작들을 붙여 또 하나의 코어 기능을 완성했습니다.

보험 진단과 추천은 기존 성능 대비 40배 가량 성능이 빨라졌고 백엔드와의 의존성이 제거되어 독립 동작할 수 있어 나중에 BtoB 서비스로 보험 솔루션 SaaS의 개발 기반이 됩니다.

Bussiness To Bussiness

앱이 성장하고 회사가 더 조금씩 알려지면서 보험 진단, 보험 추천 등의 기능을 인슈어 테크 회사들이 도입하고 싶어했습니다. 보험사들과 도입을 위한 회의를 진행하고 보험사에 맞는 내부망 서버 구성과 엔진의 커스터마이징 등 많은 부분을 협의해 나갔습니다.

처음 도입한 보험사는 보안을 이유로 내부망에 설치해 운영하고 싶어했습니다. 나중에 실제 이유는 서비스가 내부에 설치되어 있으면 이를 분석해 보험사 내에 자산화하고 싶은 이유였던 것을 알게 됐습니다. 그래서 그런지 유지보수 계약도 하지 않았습니다.

하지만 설치형 엔진은 기술 유출을 막기 위해 난독화, 암호화를 이중으로 하고 이것을 바이너리 파일로 제공했기 때문에 보험사에서 코드를 하나도 확인할 수 없어 결국 자산화는 실패하고 보인들의 입맛으로 커스터마이징하는 것도 할 수 없어 결국 유지보수 계약도 하게 됩니다.

시간이 많이 흐른 뒤에는 신용정보원 개편이나 여러 보험적 이슈들에 대해 직접 가서 설치해야 하기 때문에 빠른 대응을 할 수 없었기에 SaaS 형태의 엔진으로 계약을 변경해 건당 사용 요금을 받는 방식으로 변경해 사용하게 됩니다.

첫 도입한 회사에서 정상적으로 엔진이 운영되면서 타 회사들에도 신뢰가 생겼는지 여러 보험사들과 협의를 거쳐 진행했고 한번에 3개의 보험사와 계약을 하는 등 빠르게 발전해 갔습니다. 각 보험사들마다 요구사항에 맞는 새로운 서비스들(약관 조회서비스, 약관 분석 서비스 등...)을 요청해 요청한 내용들도 바로 개발해 제공했고 그렇게 BtoB 아이템들을 늘려나갈 수 있었습니다.

마이데이터

어느 날 국가에서 데이터를 개방한다는 발표가 있었고 마이데이터를 통해 기존의 신용정보원 크롤링 데이터를 좀 더 체계화 된 데이터로 받을 수 있는 기대감이 생겼습니다. 얼마 안 지나서 경영진은 마이데이터를 해야 인슈어 테크 회사로서 살아남을 수 있다고 이건 숙명적 과정이라는 결론을 내렸습니다.

마이데이터에 통과되기 위해 공기업 격인 코스콤 클라우드로의 클라우드 구성 이전과 여러 보안 사항들, 그리고 옮기는 김에 하자고 하는 것들이 많아졌습니다.

당시에는 개발자가 3명이었는데 1명은 입사한지 1개월이 됐고 프론트엔드 개발자였는데 html, css만 다둘 줄 아는 분이어서 react를 공부하고 있었고 진행 인원에서 제외되게 됩니다. 1명 더 있던 CTO와 일을 진행하게 됩니다.

CTO는 프론트엔드 개발자였고 node 외에 언어를 다뤄 본적이 없었습니다. 그래서 당시 백엔드 소스만 php로 되어 있는 것을 눈에 가시로 여겼기 때문에 이것을 typescript로 변경하자고 제안했습니다. (CTO는 입사 후 3개월 동안 ERD도 개발 문서도 그 어떤 것도 제대로 보지 않고 원 페이지 웹싸이트를 새로 개발하며 자랑을 하던 분이었습니다.)

달갑지는 않았습니다. CTO는 현재의 구성을 전혀 고려하지도 않고 단순히 기술 스택만 이야기하며 이걸로 바꾸자가 전부였기 때문입니다. 심지어 백엔드만 변경하기로 했는데 추가 기능, 성능 향상이 있는 것도 아니고 언어만 바꿀 이유가 있나 싶었습니다.

하지만 CTO가 경영진과의 소통 참구를 본인을 통해서만 하도록 막았기 때문에 경영진을 설득해 본인이 원하는 스택으로 내가 개발해 줘야 하는 마이그레이션이 시작됐습니다.

서버의 코드들을 꼼꼼히 읽어 나가면서 기능들 간의 연결 관계와 의미들을 파악하고 필요한 기능을 구현하기 위한 서비스들과 앱과 웹에서 사용할 api 로직들을 설계할 수 있었습니다.

새로 구현된 api들과 프론트엔드, 앱 간에 연결을 한번 더 검토하고 효율적인 방향을 모색해 프론트엔드/앱과 백엔드를 양방향으로 수정해 나갔습니다. 그렇게 개발 소스를 수정하는 동안 CTO는 클라우드 구성을 했었는데 마이그레이션 개발과 DB 마이그레이션이 2개월만에 완료 됐지만 4개월 동안 클라우드 구성만 했고 2개월 간은 클라우드 구성 마저 지원해야 했습니다.

마이데이터 보안 구성을 위한 회의에서 CTO는 자신이 보안이 아주 높은 중국계 코인 회사에서 일 했었다며 자신의 의견을 계속 관철하고 구성을 주도 했는데 CTO의 말대로 구성을 완료하고 마이데이터 심사에서 여러 번 떨어지면서 실제 마이데이터 사업자를 취득하는데 기간만으로만 1년 정도 걸렸습니다.

마이그레이션

마이데이터를 위해 코스콤으로 망을 이동이 끝나자 앱의 UI를 개선을 진행하자는 의견이 점점 커져 갔습니다. 이에 CTO는 앱 소스만 변경하지 말고 이참에 기존 레거시들을 모두 버리고 새로 만들기를 원했습니다.

이미 코스콤을 위해 마이그레이션 비슷한 경험을 해 봤기 때문에 마이그레이션 하기 위해서 해야 할 것들을 리스팅했습니다. 우선 기존의 ERD구성과 각 api 별 로직들과 영향관계들을 파악하고 프론트엔드에서의 데이터 흐름을 우선적으로 파악한 뒤 신규 ERD 구성과 api 로직들을 설계하고 웹, 앱에서 어떻게 보여줄지에 따라 backend를 수정 개발하는 것이 필요하다고 제안했습니다.

하지만 CTO는 기존 레거시를 6개월 동안 보지 않았기 때문에 레거시와 상관없이 db 마이그레이션 계획도 없이 기획자분과 함께 새로운 앱을 구성하기로 마음 먹고 그렇게 그냥 시작이 됐습니다.

더 많은 설득을 하고 싶었지만 당시 신규 엔진을 연구하며 개발하고 있었기 때문에 여유도 없고 계속 말해도 듣지를 않으니 관여하기가 참 난감한 상황이었습니다. 3개월 뒤 서비스 개발의 진도는 프론트엔드, 앱만 완료되어 가고 있었고 데이터베이스와 백엔드는 기획도 설계도 되어 있지 않았다.

그렇게 무계획으로 시작된 프로젝트는 3개월이라는 CTO의 근자감 일정 안에 끝나지 않았고, CTO의 주도 하에 개발자 3명이 같이 붙어 강행된 개발이 언제 끝날지 모르는 상황이었습니다. 그런 가운데 투자자들에게 신규 앱 런칭을 3개월 뒤로 공표한 비지니스 담당자들은 난감함에 점점 개발쪽에 압박이 높아져 갔습니다.

엔진 개발을 맡고 있던 저는 일정을 맞췄지만 플랫폼 개발 쪽은 점점 시간이 지체되어 갔습니다. 도와주며 빠르게 진행하고 싶었지만 CTO가 코드를 볼 수 있는 권한을 각 부서별로 막았기 때문에 엔진 개발하는 사람은 엔진만 볼 수 있는 상황이었습니다.

그렇게 1년이 지나 앱 런칭 테스트를 진행했고 테스트 이후 2개월 뒤인 1년 2개월 만에 앱이 런칭되면서 고비를 한번 넘게 됩니다. 이 기간 동안 많은 이슈들이 발생하고 경영진과 마찰이 빚어지면서 CTO와 CTO 인맥으로 들어온 개발자들이 프로젝트 후 일을 아예 안 하면서 이상한 행동들을 하다가 얼마 지나지 않아 인수인계 없이 CTO와 함께 다 같이 퇴사했습니다.

그 후...

CTO와 CTO 인맥들이 모두 퇴사하는 동안 가장 먼저 나간 CTO 이후 새로운 CTO도 여러번 입사하고 퇴사했습니다. 비지니스 요구사항과 CTO의 억지로 막 만들어져 있고 많은 것이 소실된 현재의 상태를 제대로 고쳐나갈 사람이 등장하지 않았습니다. 하지만 시간이 지나고 현 상황을 받아들이고 같이 헤쳐나갈 새로운 개발자들이 체워졌고 점점 체계가 잡혀가면서 업무를 서로 덜어가며 발전해 나갔습니다.

초기 스타트업이었던 이 회사가 다니는 동안 220억 이상 규모의 투자를 유치해 Series C 스타트업이 됐고 이제는 상장을 준비하고 있습니다.

피플팀도 생겨서 직원들의 복지를 고민하며 늘려 가고 카페테리아까지 있어 공짜 음료도 맛 보고 재택 근무도 주 2일을 할 수 있게 분위기가 조성되기 시작했습니다. 기획팀의 숫자도 늘어나고 마켓팅, 브랜딩 등 회사가 더 성장해 나가기 시작했습니다.

나도 회사의 가치를 성장시키기 많은 문제들을 해결하고 신규 BtoB 사업들을 성공적으로 완수해 43개 보험사에서 모두 사용할 수 있는 솔루션을 SaaS로 제공하고 핵심 업무들을 도맡아 수행하며 보험에 대해 끊임없이 스터디했습니다. 신규 인력들이 들어오면서 그 동안 사내에 문서화 해 놓은 자료들을 통해 교육 자료로 사용하고 직접 교육을 하기도 하는 뿌듯한 일도 했습니다.

SaaS를 통한 서비스를 모두 총괄하고 있고 주력 앱인 보닥의 핵심인 보험 엔진 개발 또한 총괄 했습니다. 또한 신규 서비스 개발을 위해 데이터 가공, 분석, 기획 등의 작업을 진행하며 팀원들과 함께 새로운 가치를 발굴하며 새로운 서비스도 찾아나갔습니다.

이직 결심

회사의 여러 요청으로 여러 차례 CTO 포지션을 제안 받았지만 관리 보다는 엔진 개발에 좀 더 몰두하고 싶어 이를 거절했는데, 다른 오랜 연차의 CTO가 입사했습니다. 이 분은 이미 개발자가 많아 직접 개발하진 않았고 개발 상황을 경영진에게 설명하는 중간자 역활을 했는데 회사에서 가장 오래된 개발자이고 유일한 초기 맴버인 내가 눈에 가시였던 것 같습니다.

아기가 태어나면서 육아를 좀 더 도와줄 수 있도록 풀재택 근무가 필요해졌습니다. 회사에서는 최대 가능일을 저를 위해 2일로 늘려주었지만 이미 엔진과 SaaS 쪽은 풀재택으로도 일을 처리할 수 있는 상황을 어필하자 경영진 쪽에서 이를 허락해 줬습니다.

그러나 개발자들이 차별을 느낀다며 다시 거절됐고 결국 풀재택이 가능한 곳을 찾아보게 됩니다. 나중에 알게된 사실이지만 개발팀원들과 서로 편히 이야기하며 모두 아기 때문에 재택하는 것을 지지해주던 상황이었는데 CTO로부터 그런 이야기가 나오며 거절된 것을 알았습니다.

그렇게 최선을 다해 오던 회사를 나오게 됩니다.