창업을 했다면 지금 속도는 항상 느리다.
페이스북(지금의 메타)을 만든 마크 주커버그는 회사의 모토를 이렇게 정한다.
Move Fast and Break Things
(빠르게 움직여라 무언가를 깨뜨릴 정도로)
이는 두 가지 의미를 내포한다. 첫 번째는 엄청나게 빠르게 실행해야 한다는 것이고 둘째는 빠른 실행으로 기존 산업의 무언가를 깨버릴 정도로 임팩트를 만들어내야 한다는 뜻이다.
스타트업에서 하나의 공식처럼 자리 잡은 린 스타트업이나 에자일 또한 빠른 실행과 함께 무수히 많은 실험과 학습의 루프를 "빠르게" 돌아야 함을 강조한다. 그런데 "빠르게"가 뭔지 어떻게 하면 빨라지는지 이야기하지 않는다. 그저 빠르게 빨리만 이야기할 뿐이다. 어쩌면 한국인은 린스타트업의 정신이 유전자에 내장되어 있는 걸지도 모르겠다.
스타트업 업계에서 성경구절처럼 전해지는 이 메시지는 와전되어서 빨리 뭔가를 하는 거 자체가 해결책인 것처럼 여기거나 네가 엄청난 능력으로 쉬지 않고 부지런하게 해야 빨리 할 수 있다는 식으로 잘못 전해지기도 한다.
내가 부지런해야 되는 건 줄 알았다
나 또한 이 메시지를 무려 1년 동안 잘 못 이해했다. 사실 저번 주까지도 잘 못 이해하고 있었다. 나는 빠르게 일이 진행되고 처리되어야 하지만 계속 계획보다 일정이 늘어지는 것이 내가 능력이 부족하거나 내가 게을러서 혹은 내가 시간을 많이 투입을 하지 않아서 그렇다고 생각했다.
그렇게 며칠을 밤을 새워서 작업한 적도 있었고 루틴을 정해놓고 루틴에 맞게 생활하면서 업무를 한 적도 있었지만 이 속도가 절대적으로 빨라지지가 않았다. 그런데 문제가 생긴다. 나는 1인 기업 대표였고, 혼자 하나의 회사가 처리해야 하는 모든 일을 처리해야 했다. 심지어 AI 기술을 익히기 위해 스터디 모임과 연구 모임을 이끌고 있었고, 마케팅과 인간을 이해하기 위해 모두의 연구소에서 마케팅 관련 풀잎스쿨을 참여하면서 행동경제학 풀잎스쿨 퍼실이를 동시에 하였다. 나에게 하루는 너무나 짧았고 일주일은 너무나 빠르게 지나갔다.
나는 이런 여러 가지 업무를 요일별로 쪼개서 관리하였다. 일주일 중에 스터디를 준비하는데 무려 이틀을 꼬박 소요했다. 그리고 주말 중 하루는 스터디와 풀잎스쿨을 하는 데 사용하였고 하루는 청소 빨래 등 집안일을 하고 독서와 휴식을 하는 데 사용하였다. 그렇게 되면 실질적으로 남은 일수는 3~4일 밖에 되지 않는다. 그리고 이중에 마케팅을 하기 위한 시간을 반으로 쪼개면 실질적으로 서비스를 개발하는데 일주일에 이틀밖에 사용하지 못했다.
심지어는 그 개발에 투입하는 시간 안에서도 뭔가 모르게 그다지 속도가 나지 않았다. 개발마저도 풀스택으로 해야 하는 나로서는 정말 미치는 일이었다. 기능 하나를 만들면 혹은 UI를 구현하면 하루가 끝났다. 이런 속도로는 도무지 계획대로 서비스를 릴리즈할 수가 없었다.
이런 모든 빠르게 될 수가 없는 원인이 나의 실력이 부족하고 프로그래밍 속도가 느린 탓이라고 생각했다. 하지만 사실 이것보다 더 근본적인 문제가 도처에 놓여 있었다. 사실 그런 원인을 정확하게 분석할 생각조차 하지 않았지만 호리에 다카후미의 <다동력>이라는 책을 읽고 난 후 모든 생각이 바뀌게 되었고 내가 빠르게 하지 못하는 이유를 분석할 수 있게 되었다.
직원으로서의 "빠르게"와 사업가로서의 빠르게는 다르다.
내가 직원으로서 일할 때 주어진 업무를 마감까지 끝내지 못하면 오로지 나의 문제와 나의 책임이었다. 나의 능력 문제일 수도 있고, 근태 문제일 수도 있었다. 그저 열심히 해야 했고, 그저 어떻게든 실력을 올려 빠르게 처리해야 했다.
창업한 지 1년이나 됐지만 아직도 빠르게의 의미를 직원으로서의 빠르게의 의미로 받아들이고 있었다. 하지만 1인 기업의 특성상 점점 물리적으로 불가능한 시간 앞에 더 이상 내 능력의 최대치로 성실하게 일을 하는 것만으로는 빠르게 할 수가 없었다.
그 이후 <가진돈은 몽땅 써라>와 <다동력>을 읽고 나서 그리고 여러 가지 1인 기업에 대한 정보들을 접하고 나서 빠르게의 정의 자체가 바뀌게 된다. 이제는 내가 생각하는 빠르게의 정의는 다음과 같다. 병렬로 실행하며, 이미 만들어진 것들을 최대한 활용하고, 완벽보다는 완료를 신경 쓰며, 가장 중요한 것에만 온 집중을 다 하는 것이다. 결국 내가 성실하게 빠르게만 하는 게 아니라 일의 양 자체를 효율적으로 현저히 줄여서 빠를 수밖에 없게 만드는 것이 핵심이었다.
해야 할 일과 나만 할 수 있는 일
비즈니스를 계속 이어나가면서 해야 할 일들을 적어나갔다. 기획, 서비스 개발, 디자인, 영업, 마케팅, 브랜딩, 인재영입, 회계, 세무 등을 적었다. 그리고 그중에서 꼭 내가 하지 않아도 되는 일과 내가 하면 느리거나 퀄리티가 안 좋은 일들을 날렸다. 짬짬이 시간이 많이 소요되는 회계와 세무는 당연히 날아갔고, 디자인도 내가 할 수 없는 것이었고 공부를 하자니 효율이 떨어지는 작업이었다. 여기서 스스로 놀라운 것은 서비스 개발마저 지워졌다는 것이다. 내가 프로그래머 출신이었음에도 불구하고 꼭 내가 아니라도 개발을 할 수 있는 사람은 많았다.
그렇게 1인 기업 대표로서 오로지 나만 할 수 있는 일은 기획과 영업, 마케팅, 브랜딩이었다. 여기에 사실상 온 신경을 쏟아 넣어야 했다. 그리고 서비스 개발도 일단은 다시 넣게 되었다. 생각해보니 지금부터 아주 빠르게 서비스를 개발할 텐데 그 빠른 속도에 맞춰주는 외주인력은 없었다. 개발을 하는 팀원을 영입하기 전까지는 이것마저 나만 할 수 있는 것이었다.
결국 두 개의 축을 해야 했다. 만드는 것과 팔아오는 것 심플하게 이 두 가지였다. 그리고 어떻게 하면 이 두 가지의 일의 작업량을 줄일 수 있는지를 고민하게 되었다. 만드는 관점에서는 극단적인 생산성 향상을 고민하게 되었고 팔아오는 쪽에서는 적은 작업량으로 효과가 좋은 방법을 고민하게 되었다.
어떻게든 비동기식으로 병렬로 실행
비동기식과 병렬 메커니즘은 프로그래머라면 다 아는 개념인데 간단하게 설명하자면 동기식은 어떤 작업이 끝날 때까지 기다렸다가 그다음 작업을 이어받아서 다음 작업을 수행하는 방식이다. 반면 비동기식은 어떤 작업이 끝나는 것과 상관없이 다른 작업을 수행하는 방식이다. 그리고 병렬 처리는 같은 시간에 서로 다른 일들을 한꺼번에 처리하는 것이다. 여기서 동시성의 차이는 동시성은 한 명 이상이 특정 시간대에 여러 가지 일을 같이 처리하는 것이라면 병렬은 두 명 이상이 각자의 일을 맡아서 동일 시간에 동시에 처리하는 것이다. 당연히 비동기식, 병렬 처리는 어떤 작업이 딜레이 될 때 기다릴 필요도 한 명이 모든 것을 다 잘할 필요도 없다.
그래서 병렬 처리는 당연히 혼자서는 불가능하다. 앞서 말했듯 이 비동기식과 병렬 처리를 잘 수행하기 위해서는 당연히 같이 일하는 사람이 있어야 한다. 이게 바로 내가 팀원을 찾는 이유 중에 하나이다. 그렇게 나 개인이 수행하는 작업의 양을 N분의 1로 현저하게 줄일 필요가 있다. 그러면 사업을 할 때 작업을 처리하는 속도는 N배 빨라지게 된다. 혼자 부지런하게 한다고 하더라도 업무 시간이 배로 늘어나지는 않는다. 하지만 병렬 처리를 해줄 수 있는 사람이 있다면 가능해진다.
그렇게 나는 같이 일을 할 사람들을 계속 찾아 나서고 있다. 그런데 지금은 팀원이 없기 때문에 모든 것을 다 혼자 해야 한다고 생각했다. 이것을 내부 팀원이 아니라 외주로 돌릴 생각을 못했던 것이다. 생각을 못했다기 보단 외주로 돌리자니 나가는 비용이 너무나 걱정됐다. 지금까지 나는 오래 버터기 위해서는 비용을 줄여야만 한다고 생각했고 그 때문에 오로지 일을 할 수 있는 사람은 나 밖에 없었다.
그런데 그것은 바보 같은 생각이었다. 호리에몽의 <가진 돈은 몽땅 써라>를 읽고 나서 이런 생각은 180도 바뀌었다. 오래 버틸 수 있다고 생각했던 것은 일을 처리하지 못해 지지부진하게 오래 끄는 것과 다를 바 없었고 이는 아끼는 비용보다 수익을 내지 못하는 기회비용이 훨씬 컸다. 또한 비용을 줄인다는 것 자체가 리스크 테이킹을 전혀 하지 않고 결국 아주 천천히 가라앉는 배에 올라타 있는 것과 다를 바 없었고 장기적으로는 가장 리스크가 큰 선택이었다.
그래서 팀원이 없는 1인 기업의 대표인 나는 많은 일들을 시간을 벌기 위해서 돈을 쓰면서 외주로 돌려야 한다. 당연히 해당 외주를 관리하는 프로세스도 만들어 내야 한다. 그렇게 내 일을 병렬 처리로 바꾸어야 하기에 나는 일의 우선순위를 정하고 오로지 나만 할 수 있는 일들을 정한 것이다. 그리고 그 외에 일들을 전부 외주로 돌릴 예정이다. 심지어는 빨래와 청소 같은 집안일도 전부 아웃소싱을 할까 생각 중이다. 일주일에 몇만 원으로 하루 반나절을 벌 수 있다면 합리적인 거래 같이 느껴졌다. 그렇게 나는 시간을 벌기 위해 그리고 병렬로 일을 처리하기 위해 돈을 투자하고 업무 프로세스를 구축하려고 계획 중이다.
바퀴는 다시 만들지 말고 있는 걸로
IT업계에서 널리 사용하는 말이 있다. 바퀴를 재발명하지 말라는 것이다. 업계 관계자가 아닌 사람들이 오해하고 있는 것이 있는데 개발자들이 코드를 바닥부터 짜올린다고 생각하는 것이다. 물론 바닥부터 짜 올리는 사람들도 있다. 이런 것을 흔히 날코딩이라고 한다.
나도 꽤 날코딩을 많이 했었다. 다른 개발자들이 java-spring, node.js-next.js, python-django 등의 웹 프레임워크를 사용할 때, 나는 Go를 이용하고 echo를 최소한으로 사용하면서 서버를 개발하였고, 다른 개발자들이 리엑트나 vue 하물며 JQuery정도를 쓰면서 개발할 때 나는 바닐라 js를 사용해서 날코딩을 많이 했었다. 결론적으로 이게 아주 큰 패착이었다.
솔직히 말하면 그런 마음도 있었다. 프로그래머로써 내가 소스코드의 거의 모든 부분을 통제해야 한다고 생각했고 그러기 위해서는 모든 코드의 동작 방식을 전부 이해할 수 있어야 한다고 생각했다. 그래서 모든 소스코드를 이해하고 통제하기 위해 프레임워크 사용을 최소화하고 날코딩을 했다.
그리고 부끄럽게도 그게 실력이 있는 것이라고 착각하기도 했다. 그러면서 다른 개발자들은 내부가 어떻게 작동하는지도 모르고 프레임워크 떡칠을 한다고 비난하기도 했었다. 사실 지금 와서 생각해보면 일종의 열등감이었고 나는 우월감을 느끼고 싶었을 것이다. 나는 다른 개발자들이 봤을 때 프로덕트의 동작원리를 전부 깨우친 사람 같이 보이길 원했던 것 같다. 그리고 다른 사람들이 나의 소스코드를 까보고 나서 사실은 내 실력이 별거 아니라고 생각할 것 같아서 더 있어 보이게 코드를 짜내려 갔다. 다 적고 나니까 이때까지 참 등신 같은 생각을 하고 있었다는 생각이 든다.
그러다 후리에 다카후미의 <다동력>을 읽고 나서 그 생각이 완전히 바뀐다. 다동력에서 호리에몽은 바퀴를 재발명하지 말라는 이야기를 한다. 이것은 비단 개발의 문제뿐만 아니라 해당 비즈니스 모든 업무 전 영역에서 만들어져 있는 것을 활용하라는 의미였다. 개발과 디자인은 프레임워크와 탬플릿, 심지어는 일부 기능은 채널톡이나 볼트 같은 이미 개발이 되어있는 솔루션이나 클라우드 SaaS 등을 최대한 활용하며, 기획은 프로토타이핑 툴을 회계는 회계솔루션 또는 그냥 깔끔하게 아웃소싱을 하고, 마케팅은 마케팅 도구를 최대한 활용해서 싱대적으로 덜 중요한 것은 시간 아깝게 직접 하려고 하지 말라는 것이다.
어차피 완벽하게는 못해
그래서 다동력을 본 이후 개발에서의 최고의 우선순위는 생산성, 정확하게는 일이 적은 쪽으로 선택하는 것이고 비교적 안정성이나 확장성, 재사용성, 가독성 같은 흔히 개발자들이 말하는 "우아한 코드"같은 상상 속의 유니콘 같은 것은 포기하기로 했다.
정말 오래 걸렸지만 결국 나는 완벽하게 뭔가를 할 수 없음을 받아들일 수밖에 없었다. 심지어는 내가 어떻게든 완벽을 추구하면서 해도 나는 완벽한 사람도 아니었고, 내 일에는 수많은 허점이 많았다. 그리고 완벽을 추구하며 작업시간을 늘리고 늘려도 그 늘린 만큼의 퀄리티 향상이 선형으로 나타나지도 않았다.
그래서 힘을 빼고 완벽보다는 엉성하더라도 심지어는 완성이 되어있지 않더라도 빠르게 시장에 전달하고 피드백을 받을 방법들을 구상하고 있다. 그 시작으로 여기 브런치에 글을 쓰는 것도 좀 힘을 빼고 쓰려고 한다. 한주에 글을 하나씩 발행하고 있는데 다른 사람들이 본다고 의식하니까 너무 잘 써야 한다는 강박에 사로잡혀서 계속 미루게 되거나 하나의 글을 쓰는데 시간이 너무 오래 걸리는 것 같다. 그래서 내 생각을 그냥 말로 죽 주절거리고 그러면서 주요 키워드만 기록해서 구조 잡고 제한된 글자 수 내에서 제한된 시간 내에 쓰는 걸 훈련하고자 한다. 글 쓰는 거 너무 어렵다.
그리고 내가 아무리 해도 완벽하게 안된다는 것을 받아들이면 내가 아니면 안 된다는 생각도 깨버릴 수 있다. 완벽을 추구하면 다른 팀원이나 외주인력이 작업한 것에 만족하기가 힘들고 아 그냥 내가 해버리고 말지 라는 생각이 드는데 어차피 내가 해도 이 정도 나오겠다 생각하고 팀원이랑 외주인력의 능력을 어떻게 끌어올릴지만 고만하면 오히려 생산성이 좋아지겠다고 생각한다.
마치며
지금까지 이런 것들을 몸으로 직접 부딪히면서 배우고 깨닫기 위해 지난 1년을 방황한 게 아닐까 하는 생각을 한다. 지금까지 너무 헤맨 거 같다. 이제 작년과 같은 실수를 하지 않기 위해 이런 개념들을 실행하면서 월간 윤성국이라는 프로젝트를 시작하려고 준비하고 있다. 목표는 PMF를 찾을 때까지 한 달에 하나의 서비스를 시장에 오픈하고 시장의 반응을 파악하는 것이다. 지금까지 생각만 하고 불가능할 것이라 생각하고 실행을 못하고 있었는데 지금은 내 일의 양을 최대한 줄인다면 가능하겠다는 생각이 든다. 조만간 월간 윤성국이라는 프로젝트의 구체적인 로드맵 구상을 끝낸 후에 소개할까 한다.
