영록이 홈페이지

Title: 파인코드 근황 | edited by

Youngrok Pak at 4 years, 9 months ago.

파인코드는 2년여 전 세금 신고 API 서비스를 만들기 위해 출범했다. 투자를 받고 시작할 수 있으며 수요가 확보되어 있다는 점 때문에 앞뒤 재보지 않고 시작했다. 하지만, 세상에 안전한 비즈니스 따윈 없다. 2년 전의 나는 정말로 너무나 안일했다.
처음 1년 간은 개발에 집중했다. 세금 신고 엔진을 만든다는 건 쉬운 일이 아니었다. 한국 공공 IT의 특성에서 나오는 어려움도 만만치 않았고, 세금 계산 자체의 복잡도도 상상을 초월했다. 우리가 투자 받은 돈은 2억이었는데, 2억으로 할 수 있는 일은 확실히 아니라고 생각한다. 만약 2년 전으로 돌아간다면, 10억 이하의 초기 투자로는 시작하지 않을 것 같다. 그래도, 갖가지 기술적 난관을 뚫어내면서 제법 성취를 이루었다. 원천세는 50여개 사업자의 데이터 2년치가 검증을 통과했고, 부가가치세는 20여개의 1년치가 검증을 통과했다. 단순히 검증을 통과한 게 아니라, 그 과정에서 오히려 사람의 실수도 무수히 많이 잡아냈다. 특별히 에러 감지 로직이 있다거나 그런 건 아니고, 우리는 그냥 공식대로만 계산할 뿐인데, 사람은 거기서 실수한 게 많았다. 나름 이제 팔 수 있겠다는 자신감이 생겼다. 솔직히 1년 만에 개발자 두 명이서 여기까지 해낼 수 있는 건 지구상에 우리 팀 뿐이라고 생각한다. 시장의 많은 세금신고 엔진을 보유한 업체들 대부분이 법인세와 종합소득세는 서비스하지 못하고 세무사에게 맡기는 현실인만큼, 우리도 이 정도면 서비스를 시작할 수 있을 것 같았다.
그래서 그 다음 1년은 개발을 병행하면서 파는데 좀더 집중했다. 하지만, 생각보다 파는 건 쉽지 않았다. 일단 클라이언트의 개발자가 우리 API를 연동하는 게 난이도가 매우 높았다. 외부 API를 사용하는 이유는 복잡성을 외부로 넘기고 손쉽게 연동해서 사용자 가치를 만들어내려고 하는 것인데, 우리 API를 쓰려면 20여개의 API를 갖가지 상황에서 호출해야 했다. 이것은 그 API를 호출할 데이터를 준비하는 것도 쉽지 않다는 뜻이기도 하다. 고객에게서 입력 받아야 할 UI도 복잡하고, 스크래핑해야 할 데이터도 많다. 예를 들어, 사업자 고객이 직접 이용할 수 있는 UI를 포함한 세금신고 서비스를 만든다고 할 경우 적게 잡으면 50억 정도 들 것으로 예상되는데, 우리 API를 이용하면 20억 정도 줄일 수 있는 정도다. 그러니까 API로 핵심 엔진을 쓸 수 있어도 여전히 복잡한 비즈니스인 것이다.
그래서, 우리는 API를 팔 때 항상 우리가 직접 연동 개발을 하는 방안을 같이 제시했다. 연동 개발하는 비용은 실비로 정산 받고 연동이 완료된 이후부터 API 이용료를 받는 모델이다. 이걸로 영업 협상은 제법 여러 군데 되었다. 하지만, 이게 수익이 크게 나는 시장이 아니다보니 클라이언트는 가격에 민감했고, 우리 입장에서도 가격을 낮추면 개발비 회수조차 안될 정도여서 접점이 잘 안 나왔다. 그 결과로 1년간 시도한 영업은 줄줄이 실패로 돌아갔다. 가격만이 문제는 아니었다. 엔진의 품질도 클라이언트의 기대만큼 충분히 높지 않았다. 우리는 태생적으로 높은 신뢰도의 세금 신고 엔진을 만들 수 있는 상황이 아니다. 세금 신고 엔진을 제대로 만들기 위해서는 세무사가 필요하고, 풍부한 세무 데이터도 필요하고, 충분한 베타 테스트를 거쳐서 지속적으로 보완해가는 과정도 필요하다. 우리는 이 세 가지가 다 없었다. 시작할 때는 이 세 가지 모두 공급 받을 수 있을 거라고 여겼지만, 결과적으로 그렇지 않았다. 
1년여의 개발, 그리고 1년여의 영업 실패를 겪고 우리는 이 문제를 좀더 진지하게 검토해보기 시작했다. 가격 문제는 사실 품질이 확실하다면 별로 중요하지 않았을 것 같다. 모순은 품질에 대한 기대치에 있었다. 품질에 두 가치 측면이 있는데, 하나는 커버리지다. 세금은 수많은 예외상황이 있기 때문에 이런 것들을 얼마나 커버하는지도 중요한데, 우리는 80:20 법칙에 따라 20%를 구현하고 80%의 사업자를 커버하는 것을 목표로 했다. 여기까지는 별 문제 없었다. 클라이언트들도 100% 커버리지가 얼마나 어려운지에 대해서는 대충이나마 이해하는 것 같았다. 그러나, 품질의 다른 측면, 그 80%의 사업자를 신뢰도 높게 커버할 수 있는가는 문제가 있었다. 우리 엔진의 검증은 실제 사용자가 붙어서 API를 호출하고 그걸로 신고를 돌리고 하면서 검증된 게 아니다. 그냥 데이터를 밀어넣고 나오는 output을 더존 스마트 A에서 나온 모범 답안과 비교해서 검증한 것이다. 그러니까, 엔진과 별개로 API 문서화가 충실한지, API 입력값 오류 검사는 잘 되는지, 사업자 고객의 특정 상황에 어떤 API를 호출해야 하는지 등등에 대한 준비가 충분히 되어 있지 않았다. 이런 것들은 우리가 선제적으로 준비하는데 한계가 있을 수 밖에 없고, 서로 합의된 가운데 필드 테스트를 진행하면서 보완해나갈 수 밖에 없다. 하지만, 이런 보완 작업을 같이 할 의향이 있는 업체는 없었다. 그러니까, 우리 제품을 팔려면 엔진 품질 뿐 아니라 API 품질도 높아야 하는데, 품질을 높이려면 필드 테스트가 필요하고, 필드 테스트를 하려면 우리 제품을 팔아야 한다. 닭이 먼저냐 달걀이 먼저냐의 상황에 처한 것이다.
2년의 삽질을 거쳐서 이 결론에 도달했다는 사실이 좀 아쉽다. 아무래도 내가 미리 전략적으로 고민하고 일을 시작하는 타입이 아니라, 일단 시작하고 생각하는 타입이다보니 일어난 일인 것 같다. 이런 건 사실 2년 전에 충분히 깨달을 수 있는 일이었다. 이제는 자금이 떨어져서 개발자도 한 명을 권고휴직(?) 상태로 하고 다시 두 명이서 할 수 밖에 없는 상황이 되었다.
아무튼, 깨달음을 얻고 나서 바로 우리는 피벗을 했다. 필드 테스트를 같이 할 클라이언트를 확보할 수 없다면 우리가 직접 필드 테스트를 하자는 발상이었다. 그리고 B2C에서 우리의 가치를 증명해야 B2B에도 잘 팔 수 있을 거라고 생각했다. 우리가 삽질하는 2년간 경쟁자들이 많이 나타났는데, 우리는 경쟁자들을 벤치마크하면서 우리 엔진을 직접 사업자 고객에게 서비스할 방법을 찾기 시작했다. 여기서 걸림돌은 스크래핑이었다. 경쟁자들은 모두 공인인증서만 등록하면 세금신고에 필요한 데이터를 모두 스크래핑해서 자동으로 신고서를 만들어줄 수 있었는데, 이 스크래핑은 다들 스크래핑 전문 업체의 서비스를 이용하고 있었다. 근데, 그 가격이 설치비 2천만원에 월 이용료 100~300만원 뭐 이런 식이었다. 안타깝게도 우리에게는 그 설치비가 회사 운영 2~3개월치 자금이었기 때문에 쉽게 쓸 수 없었다. 좋은 관계에 있는 몇몇 업체에 공짜, 혹은 저가로 쓸 방법을 찾아보았지만 여의치 않았고, 그래서 그냥 직접 개발하기로 결정했다.
이게 가능했던 이유는 우리가 피벗을 시작한 게 작년 12월이었고, 첫번째 서비스할 타겟이 올해 1월의 부가가치세 신고였기 때문이다. 부가세 신고는 홈택스에서 제공하는 데이터만으로 대부분 커버가 가능해서, 우리는 홈택스만 스크래핑하면 되었다. 종합소득세나 법인세를 하려면 은행도 스크래핑해야 하므로 부담이 훨씬 커지지만, 홈택스는 그럭저럭 가능했기에 모험을 해볼 수 있었다. 우리 팀원의 놀라운 리버싱 능력 덕분에 생각보다 빨리 스크래핑이 개발되었고 1월 신고 직전에 런칭에 성공했다. 하지만 우리가 원하는 수준의 완성도를 갖추지는 못한 상태였고, 광고비에 투입할 예산도 턱없이 부족해서 충분한 실험이 되지는 못했다.
이렇게 피벗 이후 첫번째 미션은 별다른 성과를 거두지 못했다. 첫 미션의 문제점은 우리가 제공하는 게 세금 신고 밖에 없었기 때문에 세금 신고 기간인 1월을 지나고 나면 고객을 유인할 방법이 없다는 것이었다. 실제로 딱 세금신고만 좁게 목표로 해서 서비스하는 경쟁사도 있고 꽤 괜찮은 반응을 얻고 있긴 하지만, 우리는 좀더 빠르게 사용자의 피드백을 받기를 원했다. 그래서, 세금 신고 이외에도 고객에게 실제로 가치를 줄 수 있는 기능을 제공하고 싶었다. 사실 우리가 피벗을 하면서 첫번째 미션으로 세금 신고 서비스를 선택한 것은 우리가 2년간 만들어온 엔진에 대한 매몰비용에 집착했기 때문이 아닐까 하는 생각도 들었다. 엔진을 잘 활용할 방법을 찾는 게 아니라, 좀더 본질적으로, 세금이라는 분야에서 사용자에게 확실하게 줄 수 있는 가치가 무엇인지를 먼저 찾고, 그 가치를 구현하는데 엔진을 활용하는 방향으로 접근했어야 하지 않나 싶다. 그래서, 이제는 엔진과 상관 없는 사용자 가치를 찾기 시작했다.
그래서 두번째로 설정한 미션은 세금 납부를 도와주는 것이다. 안타깝게도 자동 납부까지 구현하는 것은 한국 IT의 특성상 쉽지 않았지만, 납부를 조금 쉽게 해주고, 납부해야 할 내역을 챙겨주는 것은 할 수 있었다. 키즈노트가 시작한 알림장의 가치를 캐시노트가 카드매출 분야에서 이어받았다면 우리는 세금신고납부에서 그 가치를 이어가는 것이다. 우리가 2년간 개발한 세금신고 엔진은 세무사의 존재와 많이 충돌하는 것이어서 세무사가 있는 사업자에게는 우리를 어필할 방법이 없었지만, 세무사가 있어도 세금 납부를 꼼꼼하게 챙겨주는 존재는 필요하다. 세무사가 신고를 하고 나면 보통 메일로 납부서를 전달해주는데, 그게 아니라 그냥 앱을 열면 신고된 내역이 쭉 보이고, 납부한 것들은 체크되어 있고 납부 안한 것들은 납부 안내가 나오고 쉽게 납부할 수 있다면 좋겠다고 생각했다. 환급신청을 하면 환급이 확정되었는지, 환급이 정말 되어서 통장에 들어왔는지도 확인해주면 좋겠다. 이런 생각으로 세금알림장 컨셉으로 개발을 했고, 어제 런칭이 되었다. 저번에는 세금 신고 기능에서 작더라도 매출을 발생시켜보자는 생각이었는데, 이번에는 그냥 무료로 제공하고 우리의 생각대로 진짜 사용자 가치를 주는지를 확인하려고 하는 중이다. 여전히 광고비에 쓸 돈이 턱없이 부족하지만, 여기에도 창의성을 발휘해보려고 한다.
피벗한지 이제 3개월 정도 지나고 있는데, 이번 3개월 동안 그 이전의 2년보다 훨씬 많은 것을 해낸 느낌이다. 2년 동안 우리가 돌파한 난관도 엄청난 것들이지만, 정말 돌파할 필요가 있는 난관이었는지 확인해가면서 한 것이 아니었다. 지금은 코드 한 줄 한 줄 짤 때마다 이게 사용자에게 정말 필요한 것인지 자문해가면서 한다. 이래야 스타트업이지.
안타까운 것은 이제 자금이 떨어졌다는 것이다. 비트코인 팔아서 몇 달치 자금을 마련하려고 했는데, 비트코인 가격이 1180만원이던 시점에 1200만원으로 매도를 걸어놨는데 망할 코로나 때문에 그 뒤로 폭락해서 거래는 체결되지 않았다. 20만원 더 벌자고 몇 백만원을 날린 셈. 그냥 현재가에 팔 걸.
여튼, 어려움은 많지만 이제야 진짜 스타트업을 시작해서 뭔가 전보다 개발하는 보람이 있다.

Edited Time	Editor
2020-03-13 09:11:52.220583+00:00	Youngrok Pak
2020-03-13 09:08:23.997005+00:00	Youngrok Pak

Page history of 파인코드 근황