리: 자기 소개를 부탁 드립니다.
정용수(이하 정): 삼쩜삼 CPO 정용수입니다. 삼성전자에서 개발자 생활을 9년 했고요. HW를 개발하다가 SW로 넘어와서 삼성 앱스토어 등을 개발했습니다. 속해있던 사업부가 폐지된 후 LG전자로 가서 비슷한 일을 했습니다. 팀장까지 갔는데, 여기도 사업부가 없어져서(…) 쿠팡의 ‘테크니컬 프로그램 매니저’로 잠시 있다 관뒀습니다.
리: 왜 관두셨습니까?
정: 애가 셋인데, 와이프가 애 보라고 했습니다.
리: ……
정: 마침 놀면 뭐하나 싶어 세무사와 회계사 공부를 하자… 2년 반 동안 애를 보며 자격증 공부를 했습니다. 결과적으로 1점 차로 떨어졌지만, 처음부터 세무회계 스타트업을 만들기 위해 공부한 거라 별로 아쉽지는 않습니다.
리: 세무 스타트업은 왜 만들려고 한 겁니까?
정: 와이프가 증권사를 다니는데, 저 가계부 너무 잘 쓴다고 칭찬해서, 가계부 프로그램을 만들었는데… 그게 완성도가 엄청 높았습니다. 그래서 와이프가 아예 이런 쪽으로 나가라… 그래서 창업하려다 자비스를 알게 돼, 삼쩜삼의 CPO로 일하게 된 거죠.
리: 병석님은 어쩌다가 삼쩜삼에서 일하게 됐나요?
김병석 백엔드 엔지니어(이하 김): 대학교를 졸업하고 SI 회사 창업을 했습니다. KT 연구소하고도 일하고, KBS하고도 일하고… 참 K와 연관이 깊네요. 그렇게 7년 정도 일하다 회사를 접게 됐습니다.
리: 대기업과 그렇게 일할 정도면 기술 좋은 SI회사 같은데, 왜 접으시고…
김: 원래는 2010년 즈음 유행하던 쿠폰 서비스를 하려 했는데, 어느 순간 대기업과 SI만 하고 있더라고요. 그러면서도 자기 서비스를 하고 싶은데, 이미 너무 대기업과 깊이 관여돼 있는 거예요. 어차피 우리가 하고 싶은 일을 할 수 없다면, 다들 흩어지자… 다행히 기술력이 좋은 분들이라 다들 잘 취업하고 창업자들이 마지막에 나갔죠.
리: 그리고 자비스앤빌런스로…
김: 네. 이제 합류한지 4년이 넘었습니다. 처음에는 자비스 백엔드를 맡았고, 지금은 삼쩜삼 개발에 매진 중입니다.
끊임 없는 가설과 실험 끝에 탄생한 삼쩜삼
리: 그나저나 삼쩜삼은 어떻게 탄생하게 된 겁니까.
정: 자비스는 항상 여러 파일럿 프로그램이 돌고 있고, 그 중 하나가 삼쩜삼이었어요. 연말정산 끝나는 게 2월인데, 5월 종소세 있으니 거기 맞춰서 후다닥 만들자… 그렇게 작년 5월 삼쩜삼을 시작하게 됐죠. 그때 대표님께서는 ‘이번이 마지막이다’는 심정이긴 했어요.
김: 자비스는 몇 년 동안 계속 그런 실험을 해왔어요. MVP를 만들어가며, 최소한의 리소스로 고객이 원하는 걸 찾는 과정이었던 거죠. 삼쩜삼도 원래 ‘돈받자’라는 서비스가 시작이에요. B2B 서비스는 망했지만 “개인용은 안하나요?”라는 문의가 들어오며 기획된 거예요.
리: 희한한 실험 아이디어들은 누가 내나요?
정: 누가 했다고 할 게 없는 게… 구글 폼 만들어서 광고 돌리며, 사람들 니즈를 수시로 파악합니다. 이걸 가지고 회사 임직원들이 사내외에서 수시로 이야기해요.
김: 삼쩜삼의 시작도, 한 동료가 이게 된다고 강하게 주장하는 거예요. 물론 지금 컨셉하고는 좀 많이 달랐는데, 그래도 테스트 정도는 해보자… 이런 생각이 회사에 정착돼 있어요.
리: 될 것 같았나요?
정: 기회는 있을 것 같았어요. 저도 세무사 공부할 때 이 부분을 배웠거든요. 그 두꺼운 책들에서 딱 1줄 나와요. 3.3% 원천징수한다, 끝이예요. 세법이나 시험에서는 크게 중요한 부분이 아닌거죠. 다른 세무 서비스에서도 언급이 없었어요. 반대로 모두가 무시하니까 시장이 있지 않을까 싶은… 3.3% 원천징수 되는 국민들이 엄청나게 많다는 것도, 서비스를 만들면서 알게 되었어요.
상황에 따라 유연하게, 가장 적합한 언어를 선택
리: 삼쩜삼은 어떤 언어로 구성돼 있나요?
김: 백엔드는 자바에 스프링 프레임워크 중 스프링 부트를 기반으로 돌아갑니다.
리: 스프링… 중에서 스프링 부트는 뭐죠? 이걸 쓴 이유는?
김: 스프링은 굉장히 오래전부터 사용된 프레임워크예요. 스프링부트는 스프링을 간편하게 기본 설정들이 입력되어 있어 쉽고 빠르게 시작하게 해줍니다.
리: 뭔가 너무 모범적으로 언어를 쓰는 느낌인데요.
김: 그렇죠. 개발에는 안정성이 필요하니까요. 테스트 때는 달라요. 삼쩜삼도 파일럿 단계 때는 PHP 기반 라라벨로 개발했거든요.
리: 음? 요즘 PHP 잘 안 쓰지 않아요?
김: 네. 그런데 테스트할 때는 라라벨이 굉장히 빨라요. 삼쩜삼이 정식 서비스로 되며, 안정성과 범용성이 더 중요해졌고, 자연스럽게 자바 스프링으로 넘어가게 된 거죠. 자바가 좀 딱딱해 보이지만 그만큼 정형화돼 있기에 협업이 편합니다. 또한 누구 한 사람이 다른 팀으로 오가도, 기존 아키텍처와 코드를 빠르게 이해할 수 있기에, 꼬일 일이 별로 없습니다. 반면, 라라벨 같은 모두가 익숙하지 않은 언어는 오해가 생기기 쉽지요.
리: 요즘 핫한 파이썬은 안 쓰나요?
정: 파이썬이 핫한 이유는 AI 쪽에 쓰기 좋은 언어이기 때문입니다. 삼쩜삼과 자비스 역시, 인공지능 관련된 부분이 있는데 이 부분은 파이썬으로 개발되어 있습니다.
리: 프론트엔드는 어떤가요?
김: 프론트엔드는 Vue.js를 사용하고요. 최근에는 React로 바꾸는 중입니다. Vue.js 프레임워크로 구성된 걸 걷어내고, 순수 javascript와 typescript로 구성된 애들만 React로 옮기는 중이지요.
리: 그러면 처음에 Vue.js로 개발한 이유는 무엇인지요?
김: 실용적인 이유입니다. Vue.js, React, Angular… 모두 컴포넌트 단위로 개발을 하기 쉽죠. 저희는 파일럿 프로그램을 보통 1~2명의 개발자가 만듭니다. 그러다 보니, 그 사람들이 가장 잘 쓰는 언어로 빠르게 개발하게 된 거죠. 지금 React로 넘어가는 건, 아무래도 React 쪽이 라이브러리가 더 풍부하기에 확장성을 고려한 거죠. 서비스가 커지는 단계에서의 프레임 전환입니다.
여러 분야를 볼 수 있되, 자신만의 전문성을 키워나가는 개발팀
리: 삼쩜삼은 몇 분이 시작한 거죠?
김: 정CPO님이 기획과 플로우를 맡았고, 제가 프론트와 백엔드 양쪽 모두를 개발했어요. 디자이너 분이 퍼블리싱을 Vue.js 코드로 화면 위주의 작업을 해주셨고, 제가 그 외 데이터 바인딩, 로직 등을 작업했습니다. 생각해보니 Vue.js를 쓴 건, 디자이너 분과 협업을 쉽게하려고 한 면도 있어요. Vue.js는 html, css, javascript 만 알아도, 접근하기가 상대적으로 편하거든요. 이렇게 서로의 상황 따라 언어를 조율합니다.
리: 그래도 디자이너가 프론트엔드도 짜고… 이 회사는 전반적으로 멀티가 많나요?
김: 어느 정도 수준이 된 개발자는, 대개 자기 전문 분야를 정하긴 하죠. 근데 삼쩜삼 시니어 개발자들은 대개 풀스택이긴 합니다. 예전에는 프론트엔드와 백엔드를 모두 다뤄야 했던 시기라… 10년 이상 된 시니어 개발자들이 많다 보니, 젊은 개발자분들도 자연히 양쪽 모두를 습득하고는 해요. 요즘 자바스크립트는 프론트엔드, 백엔드를 딱 가르기 힘들기도 하니까요. 프론트하던 분들이 node.js 금방 배우기도 하고…
리: 그런데 왜 삼쩜삼은 node.js 안 씁니까?
김: 저희는 업무에서 백엔드, 프론트엔드를 딱 나누는 편입니다. 회사에서는 한 분야에 집중하는 게 더 좋은 프로덕을 만들 수 있다고 봐요. 물론 양쪽 모두 조금씩이라도 공부를 권합니다. 그래야 서로의 의견을 더 깊게 고민해줄 수 있으니까요.
리: CPO님도 개발 언어를 정하는데 관여하나요?
정: 거의 하지 않습니다. 저도 개발자 출신인지라, 개발자분들 의견을 전적으로 존중합니다. 어차피 언어는 사업을 도와주는 도구이니까요. 그리고 설계를 잘 해두면 여러 언어를 써도 되는 시대이고요. 개인적으로는 MSA(MicroService Architecture), 즉 모듈 단위로 개발하고 서로 통신을 잘 맞추는 쪽을 선호합니다. 제가 쿠팡 있을 때도 여러 언어를 썼어요. 서로 통신만 잘 되면, 내부가 뭘로 개발하는지는 별로 안 중요하다는 거죠.
책임을 묻지 않고 능동적으로 개발하는 문화
리: 백엔드, 프론트엔드… 몇 년 정도 연차가 들어오면 좋겠습니까?
정: 솔직히 연차는 별로 중요하지 않습니다. 그보다는 우리와 합이 잘 맞는 분이 중요하겠죠.
리: 합이 잘 맞는다?
정: 자비스에 온지 1년이 좀 넘어 느낀 게, 다들 자기주도적으로 업무를 진행해요. 그러면서 팀원들과 원활하게 소통하고 즐겁게 협업하는?
리: 뭔가 일반적인 개발자와 굉장히 다른 특성인데요?
정: 그런데 여기 와서 그렇게 되는 측면도 있습니다. 보통 개발자는 기획자가 만들어달라는 기능 구현하고 끝인 경우가 많잖아요? 그런데 자비스에서는 우리가 어제 개발한 기능이 어떤 성과를 내고 있는지 다음 날 바로 확인할 수 있습니다. 그러다 보면, 자연히 고객의 만족에 집착하게 됩니다. 그때부터는 어떻게 뭘 더 잘할까, 서로 이야기를 나누게 되지요.
리: 그런데 사실 그 말인즉… 잘못되면 개발자 책임처럼 될 수도 있지 않습니까?
정: 그렇지는 않습니다. 마찬가지로 기획자 책임도 아니고요. 우리 회사는 책임을 묻는 문화는 없습니다. 그냥 수동적인 사람이 안 맞달까… 반대로 능동적으로 개발하려면, 한없이 마음껏 개발할 수 있는 곳이기도 해요. 애초에 관리 개념도 별로 없습니다. 누가 업무를 잘하네 못하네, 이런 걸 따지지 않고, 하고 싶은 일에 논리만 뚜렷하다면, 그 업무를 지지하는 편입니다.
리: 관리가 없다고요? 님 CPO잖음?
정: 외부 시선으로는 그렇긴 한데, 저도 개발팀원들도 전혀 그렇게 생각하지 않습니다. 솔직히 저도 하루 절반은 쿼리 따며 데이터 분석하는데 시간 보내고… 아직까지 자동화되지 않은 부분들은 손으로 하고… 말이 CPO지, 오히려 노가다에 가깝습니다.
리: 그러면 삼쩜삼 팀 구조는 어떻게 되나요? CPO와 PM 기획단 하에 백엔드팀, 프론트엔드팀이 있는 건가요?
정: 음… 기획팀이 있긴 한데… 제가 혼자 다 하다가 PM이 4분 더 붙었어요. 그런데 일방적으로 개발해달라고 문서를 내리기보다는, 개발팀과 이야기하며 우리가 구현하고자 하는 것을 상세히 정의하고, 개발팀이 개발해준 결과물이 잘 되었는지 소상히 확인하고… 관리보다는 지원에 가까운 것 같아요. 검증하는 QA까지도 저희가 처리하고 있고요.
리: 뭐, 표현 문제이지, 아무튼 관리는 관리 아닙니까…
정: 그렇죠. 체크를 하는데 관리를 안한다면 말이 안 되고… 저희는 이렇게 생각해요. PM도 뭔가를 놓치잖아요. 그러면 개발자가 PM에게 이거 빠졌다고, 속도 안 나온다고, 이야기를 해요. 개발자도 역으로 PM을 관리하는 구조인 거죠. 최대한 ‘하나의 팀’으로 서로를 인식하게 하려 노력합니다.
리: 하나의 팀으로 인식하기 위한 노력이 있다면?
정: 일단 대표님께서 가장 중요하게 생각하는 포인트 중 하나가 ‘오버 커뮤니케이션’입니다. 저 사람이 이거 알까 모를까, 이런 생각하지 말고 무조건 말하란 거예요. 제가 이직 많이 했는데, 지금껏 있던 모든 회사 중에서 제일 시끄러워요. 슬랙도 시끄럽고 사무실도 시끄럽고… 꼭 일이 아니라도, 팀을 넘어 일상적으로 스몰 토크가 끊이지 않아요. 그래서 딱히 ‘개발팀’이라기보다 같은 프로덕을 만드는 ‘삼쩜삼 팀’이란 인식이 강해요.
리: 신기한 회사로군요…
정: 서로 잘 엮이고 더 많이 소통하기 위해 자잘한 노력이 많아요. 예로 저희는 jira를 쓰지 않습니다. 아무래도 개발자가 아닌 분들은 어려워할 수 있으니까요. 대신 모두가 쉽게 소통하며 상황을 파악할 수 있도록 trello를 사용하지요. 그렇다고 문서화에 소홀하지는 않습니다. 아카이브가 필요하면 구글 문서로 다 저장해두고, 코드는 git으로 관리하고 있어요. 최근에는 노션을 조금씩 테스트 중입니다.
금융과 개발을 연결하며, 제품 성장을 직접 맛볼 수 있는 개발팀
리: 좋습니다. 본격적으로… 이 회사에 개발자가 와야 할 이유가 뭘까요?
정: 현재 세무 영역을 기술을 통해 본격적으로 해결하려는 회사는 거의 없어요. 앞으로 토스나 은행 등 금융권에서 이 영역으로 넘어오려 할 텐데, 세무회계 관련 도메인 지식을 가지고 있는 건 향후 큰 경험이 될 겁니다.
김: 삼쩜삼은 이미 100만 명 가까이 가입하고 사용하는 서비스입니다. 조회는 150만명 이상이 했고요. 이게 특정 기간에 엄청나게 트래픽이 튑니다. 예로 종소세와 관련된 5월이 그렇지요. 이렇게 트래픽이 팍 튀는 경험을 할 수 있는 회사는 많지 않을 겁니다.
리: 대형 커머스에서 일하면, 트래픽 경험은 일상적이지 않나요?
정: 저도 쿠팡의 테크니컬 매니저로 일했지만, 사실 큰 회사에서는 항상 부분만 보게 돼요. 대용량 트래픽 처리 기술 자체는 늘겠지만, 전체 서비스의 큰 관점은 익힐 수 없습니다. 이게 스타트업의 매력이라 생각하고요.
김: 이야기드렸듯, 여기서는 개발자가 어제 개발한 결과, 고객의 반응을 오늘 실시간으로 볼 수 있습니다. 개발자들끼리 대시보드를 만들고, 뭘 배포했더니 반응률이 떨어졌네… 이런 이야기를 해요. 이러다 보니 서비스에 애착도 생기고, 개발자로서는 되게 좋은 경험인 것 같아요.
리: 요즘 개발자 꼬시려고 학습환경 자랑도 많이들 하던데…
정: 복지요? 일단 뭐 배운다고 하면 매월 10만원까지 지원이 됩니다. 더 달라고 하면 또 더 줍니다… 전 그것보다 아까 이야기한 오버 커뮤니케이션, 그 자체가 학습이라고 봐요. 회의 끝나자마자 실시간으로 슬랙에 구구절절 느낀점 쓰고 그래요. 그러면서도 불문율처럼 ‘이건 절대 못해요’ 같은 말을 안 해요. 그러니까 부담 없이 서로 의견을 끊임없이 내놓는 거죠.
김: 우리끼리는 ‘싱크’라고 많이 해요. 서로가 서로를 동기화하는 거죠. 그래서 데일리미팅도 매일 합니다. 무겁게 가져가기보다 서로 뭐하는지 공유하며, 서로 도울 게 있는지 확인하는 정도로 합니다. 15명이 모여서 10분 안에 끝나는 미팅이에요. 최근에는 한 분이 “S사 회고 방식 괜찮은 거 같으니 도입해보자!”라는 의견을 내서 회고도 배워나가고 있습니다.
리: 그래서 개발자는 몇 명이나 뽑습니까?
정: 지금 백엔드 4명, 프론트가 3명인데, 이 2배 정도는 뽑을 생각입니다.
김: 이 7명 중 경력 10년 차 넘는 개발자만 4명이에요. 주니어분들이 오면 정말 빠르게 성장할 수 있을 겁니다.
리: 그나저나 개발 방법론은 뭘 쓰죠? 데일리미팅 이야기하는 거 보니 스크럼?
정: 기본적으로 스크럼 방법론을 지향합니다. 규칙에 얽매이기보다는 고객 상황 따라 유연하게 적용해요. 스프린트 따라 2주 단위로 개발하는 게 기본이지만, 짧게는 주 3회를 돌린 적도 있을 만큼, 배포에 자율성이 높습니다.
김: 그냥 회사 전반적으로 자율성이 많이 높아요. 자율출퇴근제에, 재택환경 개선을 위해 인당 50만원씩 지급합니다.
리: 회사 돈 많네요…
정: 제가 입사한 작년만 해도 힘들다고 징징대던 회사였는데, 올해 1월 매출만 25억을 냈습니다. 그 절반 정도가 영업이익이었고요. 최근에 65억원 투자도 받았죠.
김: B2B, B2C 소프트웨어를 동시에 경험하면서, 재무구조까지 건전한 스타트업을 맛보기는 쉽지 않을 겁니다. 경쟁사가 거의 없고 다 후발주자인지라, 쉽게 무너지지도 않을 거고요.
리: 감사합니다. 마지막으로 한 마디 부탁 드립니다.
정: 세상에 없던 서비스, 사람들을 감동시키는 서비스를 만들어 보는 것은 개발자라면 누구나 한 번쯤 꿈꿔본 적이 있을거예요. 우리 회사는 그런 꿈을 실현하기 위하기 가장 적합한 회사가 아닐까 생각해요.
김: 폭발적으로 성장하는 서비스를 경험하고 싶은 개발자라면 지금 바로 함께하면 좋을 것 같습니다. 좋은 경험하면서 함께 즐겁게 서비스를 만들었으면 좋겠습니다.
