프롤로그. 개발자, 회사를 만들다

프로젝트가 끝난 직후의 사무실은 묘한 공기를 품는다. 달리던 관성이 아직 남아 있는데 발밑에는 달릴 길이 없는, 그 특유의 부유감. 은행정보 플랫폼이라는 이름의 프로젝트를 마무리한 뒤가 그랬다. 수십 개 조직이 파편적으로 관리하던 데이터를 하나의 플랫폼으로 통합하고, SDK를 설계해서 연동 공수를 줄이고, 티셔츠까지 만들어 입고 다니며 전사에 보급했다. 제대로 작동하고 있었다. 다음 프로젝트들이 줄 서 있었고, 어떤 것은 흥미로운 기술 과제를 품고 있었다. 떠나야 할 이유가 딱히 보이지 않는 상황이었다.

그런데 그 사이, 이상한 감각이 자라고 있었다. 플랫폼이 잘 돌아갈수록 드는 생각이 있었다. 이것은 수십 개 조직이 각자 풀고 있던 같은 문제를 한곳에서 풀었기에 가능한 것이다. 그렇다면 조직이라는 구조 자체를 다르게 만들면 어떤 일이 벌어질까. 플랫폼을 만드는 것이 아니라, 플랫폼이 필요 없는 팀을 만들면. 처음부터 모든 맥락이 공유되고, 분업의 경계에서 유실되는 것이 없는 규모의 팀이라면.

물론 그것은 막연한 상상이었다. 퇴사를 결심하게 된 계기는 좀 더 구체적이었고, 한 사람의 끈질김에서 비롯되었다.

1시간의 결정

디스콰이엇이라는 플랫폼에서 메시지가 하나 왔다. 공동창업 제안이었다. 당시에는 일주일에 몇 통씩 비슷한 메시지가 도착하던 시기였기에, 대수롭지 않게 넘겼다. 그런데 며칠 뒤 링크드인으로 같은 사람이 다시 찾아왔다. 자료를 정리해서 보내며 이야기를 이어가려는 모습이 보통의 콜드메일과는 달랐다. 자료를 읽기 시작했다.

공감 가는 내용이 많았다. 기업이 매일 반복하는 비효율을 기술로 풀겠다는 방향, 작은 팀으로 빠르게 움직이겠다는 구상. 궁금한 점들을 메시지로 주고받다가, 마침 가까운 곳에 계신다기에 오프라인에서 만났다.

만난 지 1시간 만에 말이 나왔다. "같이 하시죠."

돌이켜보면 그것은 사업 계획에 대한 확신이 아니었다. 시장 규모를 계산한 것도, 수익 모델을 검증한 것도 아니었다. 이 사람과 함께라면 불확실한 것들 앞에서 도망치지 않을 수 있겠다는 감각이었다. 나중에야 그것을 관계에 대한 직관이라고 이해하게 되었지만, 그 순간에는 그저 몸이 먼저 반응한 것에 가까웠다. 자리에서 일어나 곧장 팀장님에게 퇴사 의사를 전했다.

만드는 것에서 함께 만드는 것으로

두 사람이 시작한 팀의 첫 번째 일은 코딩이 아니었다. 노코드 도구로 랜딩 페이지를 만들었다. "이런 기능이 곧 출시됩니다. 지금 신청하면 무료입니다." 단순한 문장이었다. 그런데 200곳이 넘는 기업이 신청했다.

숫자에 놀라기보다 먼저 한 것은 전화였다. 신청한 기업들을 하나씩 인터뷰했다. 한 달 동안 그들이 실제로 겪고 있는 문제에 파고들었다. 랜딩 페이지에 적었던 기능이 정말로 그들의 문제를 푸는 것인지, 아니면 우리가 상상한 문제일 뿐인지를 확인해야 했다. 그 과정에서 MVP의 윤곽이 잡혔고, 본격 개발에 들어갔다.

MVP는 정말로 기능에만 충실한 것이었다. 입력란과 버튼의 나열. 하지만 고객들이 쓰기 시작했고, 피드백이 쏟아졌다. 속도를 위해 포기했던 확장성이 발목을 잡았다. 기능 하나를 추가할 때마다 기존 구조가 흔들렸다. 결국 전면 리뉴얼이라는 결단을 내렸다. 작동하고 있는 제품을 처음부터 다시 짓는 일. 두 사람이 감당하기에는 벅찬 규모의 결정이었다.

그때부터 채용이 현실이 되었다. 프로덕트 디자이너를 먼저 모셨다. 혼자서 제품의 방향과 형태를 모두 결정하던 구조가 한계에 달했기 때문이다. 백엔드 개발자, 프론트엔드 개발자가 합류했다. 두 명이었던 팀이 다섯 명이 되었다.

다섯이라는 숫자는 작아 보인다. 하지만 그 전환의 무게는 숫자가 말해주지 않는다. 두 사람일 때는 모든 결정이 대화 한 번으로 끝났다. 머릿속에 있는 맥락이 서로에게 거의 그대로 공유되어 있었다. 세 번째 사람이 들어오는 순간, 그 자명함이 사라졌다. 내가 당연하다고 생각하는 것을 상대도 당연하게 여기리라는 전제가 더 이상 성립하지 않았다. 왜 이 기능을 먼저 만드는지, 왜 이 고객의 요구를 거절하는지, 왜 이 방식으로 코드를 짜는지 -- 설명해야 할 것들이 갑자기 불어났다.

"만드는 것"의 문제가 "함께 만드는 것"의 문제로 바뀌는 순간이었다. 코드의 문제가 아니라 사람의 문제, 구현의 문제가 아니라 조직의 문제가 눈앞에 놓였다. 그리고 솔직히, 그때의 나에게는 그것을 풀 준비가 되어 있지 않았다.

이 책이 답하려는 질문

개발자가 회사를 만든다는 것은 코드를 짜는 것과 전혀 다른 종류의 문제를 푸는 일이었다. 아키텍처를 설계하는 대신 채용 기준을 세웠고, 코드 리뷰를 하는 대신 피드백의 방식을 고민했다. 버그를 고치는 대신 사람들 사이의 기대치 불일치를 조율했다. 그리고 이 모든 것을 소수의 인원으로 해내야 했다.

작은 팀은 선택이었다. 큰 조직에서 겪었던 것들 -- 부서 사이에 떠도는 애매한 책임, 중간 관리자를 거치며 왜곡되는 정보, 누구도 전체를 보지 못하는 구조 -- 을 반복하고 싶지 않았다. 하지만 작은 팀을 유지하겠다는 결심만으로 문제가 풀리지는 않았다. 작은 팀이기에 부딪히는 문제들이 따로 있었다. 한 사람의 빈자리가 전체를 흔드는 무게, 명시적 프로세스 없이도 굴러가야 하는 일상, 친밀함이 만드는 침묵의 함정.

이 책은 그 여정에서 배운 것들의 기록이다.

작은 팀을 유지하면서 어떻게 큰 일을 해낼 수 있는가. 적은 인원으로 빠르게 움직이되, 방향을 잃지 않으려면 무엇이 필요한가. 이 질문에 대한 완결된 답을 가지고 있다고 말하기는 어렵다. 다만 시행착오 속에서 발견한 몇 가지 원칙이 있고, 그 원칙들이 실제로 작동하는 것을 확인한 경험이 있다.

그것들을 하나씩 펼쳐보려 한다. 왜 굳이 작은 팀이어야 했는지부터.