이 글은 대부분 Wispr AI로 머릿속에 떠오르는 대로 받아쓰기한 글입니다.

원격 회사를 운영하기로 하면서 스스로 정한 기본 원칙이 하나 있다. 사무실 임대료로 쓸 돈을 아껴 분기에 한 번에서 많게는 세 번 정도 직접 만나러 가는 데 쓰자는 것이다. 우리는 막 세인트루이스에서 첫 번째 전사 오프사이트(그러니까 3명이 모인 오프사이트)를 마쳤다. 기간은 고작 2.5일이었지만 꽤 생산적이었다고 느꼈고, 다음에도 반복하고 싶었던 것들과 다른 사람들에게도 추천하고 싶은 것들을 적어두려 한다.

모든 시간에 할 일을 정하기

화이트보드에 가장 먼저 한 일은 리트리트 기간의 모든 시간을 시간 단위로 나누고 오프사이트 동안 달성하고 싶은 것들을 모두 적은 것이었다(기본적으로 타임 블로킹인데, 그룹 단위로 한 것뿐이다). 또 오프사이트에서 다루고 싶은 주제에 대해 모두가 의견을 낼 수 있도록 해서, 각자 원하는 것을 얻었다는 느낌을 받고 돌아갈 수 있게 했다.

이런 방식의 고전적인 문제는 과소 추정 오류가 누적된다는 것이다. 한 시간 걸릴 줄 알았던 논의가 세 시간이 걸리기도 하는데, 이는 지극히 자연스러운 일이다. 하루 끝에 계획되지 않은 연장 시간을 위한 여백(일명 물음표 시간)을 남겨두면 이를 완화할 수 있다. 우리는 아직 초기 단계라 다음에 소개할 각 세션마다 사전 준비를 따로 하지는 않았다. 규모가 더 큰 오프사이트에서는 세션 전에 하루 이틀을 들여 논의할 주제에 대한 충분한 컨텍스트를 공유하는 경우를 봤다.

재무 리뷰

우리 멤버들을 합치면 4~5개의 리모트 회사에서 오프사이트를 경험했지만, 그 기간에 전체 재무 리뷰를 하는 회사는 거의 보지 못했다. 아마 모든 재무 상황(개개인의 연봉 포함)을 공개하는 것에 대한 보수적인 태도와, 고객과 SKU가 많을 때 회계가 복잡해지는 어려움이 섞여 있기 때문일 것이다. 우리는 현재 연봉이 투명하게 공개되어 있고 자금 출처나 고객·매출 구조도 꽤 단순해서 이런 문제가 없다.

이 미팅의 기본 목표는 회사의 모든 사람이 돈이 어디에 있는지, 어디서 들어와 어디로 나가는지, 그리고 앞으로 어디서 더 벌 수 있을지를 알고 돌아가게 하는 것이다. 이는 특히 직원들에게 런웨이와 비즈니스의 근본적인 지속 가능성에 대한 안정감을 준다.

우리에게는 구조가 워낙 단순해서 머릿속에서 바로 그려낼 수 있었고, 15분이면 충분했다.

고객 리뷰

우리가 누구를 위해 만들고 있는지를 더 잘 이해할수록 제품과 엔지니어링 우선순위도 더 명확해진다. 솔직히 이 부분은 우리도 아직 알아가는 중이라 어떤 조언을 해야 할지 잘 모르겠다. 다만 고객 중심과 고객 집착이야말로 회사를 성장시키는 올바른 방식이며, 최소한 회사를 정직하게 유지하는 길이라고 강하게 믿는다는 점은 분명하다. 기술 중심이나 연구 중심, 혹은 ‘바이브’ 중심 같은 다른 접근법과는 대조적으로 말이다.

아키텍처 워크스루

전체 코드베이스를 ChatGPT에 넣고 주요 섹션들을 박스와 화살표로 연결한 Mermaid 다이어그램을 만들어 달라고 한다. 그걸 Excalidraw로 옮긴 뒤 입맛에 맞게 다듬고 색을 입혀 대략적으로 말이 되게 만든다. 그리고 전사 구성원에게 그것을 처음부터 끝까지 설명한다.

기본 원칙은 이렇다. 다음에 무엇을 할지에 대해서는 누구나 의견을 낼 자격이 있지만, 오늘 무엇이 존재하는지에 대한 기본적인 사실은 모두가 공유해야 한다.

이 연습이 왜 중요한지에 대해 질문을 받았다. 가령 규모가 큰 회사라면 CEO는 기술 팀을 블랙박스처럼 여기고 구현 세부사항에 크게 신경 쓰지 않아도 된다고 볼 수도 있다. 팀 규모를 차치하더라도, 나는 엔지니어링 팀에 직접 속하지 않은 사람들도 아키텍처를 이해하는 것이 여전히 중요하다고 생각한다. 그래야 지금까지 내려진 기술적 베팅을 제대로 평가할 수 있고 말도 안 되는 기능 요청을 하지 않게 되며, 가능하다면 시스템 설계를 기능으로 제품화할 수 있는 아이디어를 능동적으로 발굴할 수 있기 때문이다.

물론 기술 창업자로서 나는 이 기회를 빌려 내가 평소에 갖고 있던 의견들을 끼워 넣기도 했는데, 이는 다음 논의로 이어진다...

원칙 회의

오프사이트는 일상에서 의도적으로 벗어나 ‘비즈니스 안에서 일하는 것’이 아니라 ‘비즈니스를 위해 일하는’ 시간으로 유용하다. 이 개념은 Richard Gerber의 책 E-Myth Revisited에서 가져온 것인데, 사실 나는 이 책을 읽어보지는 않았지만 주변에서 하도 많이 이야기하는 걸 들어 마치 읽은 것처럼 느껴진다. 그래서 이 미팅은 우리가 어떻게 일하는지, 그리고 앞으로 어떻게 일하고 싶은지에 대한, 말 그대로 HOW에 대한 회의다.

첫 창업자인 내게 이 미팅은 내가 항상 일하고 싶었던 회사를 만드는 데 가장 레버리지가 높은 자리라는 점에서 매우 신선하게 느껴졌다. 내가 가장 강하게 믿는 원칙들을 공개적으로 표현하고 그에 대해 책임을 지며 성공 습관을 복리로 쌓아갈 수 있기 때문이다. 달리 말하면, 내가 믿는 업무 문화를 말로 선언해 현실로 만들 수 있고 팀원들은 이에 대해 이견을 내거나 대체로 동의하며 함께 갈 수 있다.

원칙 회의에 가장 큰 영향을 준 것은 아마존 리더십 원칙과 레이 달리오의 책 『원칙』일 것이다. 레이의 최상위 원칙은 ‘고통 + 성찰 = 발전’이다. 아마존에는 제프 베조스가 만든 14가지 리더십 원칙이 있는데, 각각 강한 신념들을 담고 있다. 나는 원칙의 간결함에 가치가 있다고 생각한다. 그래서 원칙의 단어 하나하나가 무게를 갖도록 해야 한다. 원칙이 너무 많으면 기억할 수도 없고 지키지 않아도 쉽게 변명하게 된다. 우리는 결국 5가지 원칙을 만들었는데, 회사 인원보다도 많은 숫자라 아마 한두 개는 많았을 것이다. 물론 가장 어려운 일은 그럴듯한 추가 제안을 거절하는 것이다.

핵심이지만 결론나지 않은 원칙 논쟁

현재 AI에 대해 내가 가장 강하게 믿는 원칙은 ‘제품이 프로세스를 이끌고, 프로세스가 플랫폼을 이끈다’는 것이다. 다시 말해, 우리는 고객에게 가장 좋은 제품이 무엇인지에 대해 제1원칙부터 사고하고, 그것이 소프트웨어와 사람의 노동이 섞인 형태이든 무엇을 동원하든 최고의 제품을 만들기 위해 필요한 모든 것을 할 것이다. 그 다음 사람의 노동을 프로세스로 체계화하고, 가능한 한 마지막 단계에서 그 프로세스를 소프트웨어로 표현하고, 코드화하고, 일반화하려 시도할 것이다.

이는 플랫폼을 우선시하는 내가 봐 온 다른 스타트업들과는 정반대에 있다. 예를 들어 모든 것을 할 수 있는 오픈소스 제품이나 클라우드 제품을 먼저 만들고 나서 고객과 유스케이스를 찾아 나서는 방식이다.

내 일반적인 감각으로는 AI 분야에서 가장 성공한 리더들은 마법 같거나 프론티어적인 경험을 담아낸 제품을 만들었고, 사람들은 사실 그 밑단의 API에 접근하는 것에는 별 관심이 없다는 것이다. 그저 최종 결과에만 관심이 있을 뿐이다.

나중에 그 경험을 뒷받침하는 오픈소스 제품이나 API 플랫폼을 내놓게 되면, 사용자들은 제품의 브랜드에 이끌려 플랫폼도 함께 채택하게 된다. 마치 Amazon.com이 나중에 출시된 Amazon Web Services에 일종의 보증을 부여했던 것과 비슷하다. 물론 이 규칙에도 예외는 있다. Character AI처럼 제품을 우선시하면서도 최고의 제품이더라도 반드시 승리하지 못하고 제품이나 플랫폼 중 어느 쪽도 성공적으로 수익화하지 못하는 경우도 있다. 반대로 뚜렷한 주관을 가진 대표 제품 없이도 비교적 성공한 플랫폼도 있는데, Together AI나 Braintrust, Fireworks 같은 경우가 그렇다.

다만 제품을 고객보다 앞에 두면 고객 중심이 아니라 제품 중심이 될 수 있는 빌미를 줄 수 있다는 점이 걱정된다. 그리고 그 점이 현재 이 원칙에서 내가 발견한 결함이다.

더 단순한 원칙

내가 제안해서 약간의 논쟁 끝에 결국 받아들여진 더 쉬운 원칙은 매일 코드를 배포한다는 것이었다. 이는 이론적·사업 전략적 원칙이라기보다는 행동 원칙이지만, 모멘텀을 유지한다는 측면에서 마음에 든다.

여기에 동기를 부여한 이야기는 냇 프리드먼이 GitHub CEO를 맡았을 때의 일이다. 보통 새로 부임한 CEO들은 움직임을 만들기 전에 고위 경영진과 함께 3~6개월간의 경청 투어를 한다. 대신 냇은 ‘앞으로 100일 동안 100가지를 배포하고, 그 과정에서 장애물을 발견하자’고 말했다. 그렇게 실행하면서 회사가 어떻게 작동하는지를 배우겠다는 것이었다.

물론 작은 회사에서는 그다지 논쟁적이지 않은 말이지만, 코드에 가깝다는 것은 곧 제품에 가깝다는 것이고 그 헌신이 우리가 빠르게 움직이는 데 도움이 되었다고 생각한다. 스타트업에서 스타트업답다는 것은 빠르게 움직이고 새로운 기술과 고객 요구에 신속하게 대응한다는 의미다.

이 원칙은 글 서두에서 언급한 타임 블로킹 계획에도 직접 반영됐다. 우리는 오프사이트 기간 매일 코딩할 시간을 남겨두었고, 이는 이런 메타 작업을 하는 동안 일이 멈출 수 있다는 우려를 해소해주었다.

버스 팩터 온보딩

다시 말하지만, 이 회의는 아마 아주 작은(smol) 회사에서 가장 유용하다. 이 미팅의 목표는 가장 잘 아는 사람이 나머지 사람들에게 전체 시스템 운영 방법, 권한과 관리자 로그인 확보, 시스템 관리에 대한 이해를 처음부터 끝까지 설명하는 것이다. 이렇게 해두면 누군가 휴가를 가더라도 다른 사람이 그 자리에서 바로 이어서 할 수 있다. 누군가 부재중이더라도 다른 사람이 시간이 좀 더 걸리더라도 시스템을 다시 살려낼 수 있다.

Zoom을 켜고 화면을 공유한 뒤 녹화해 두는 것을 추천한다. 그러면 나중에 다시 참고할 수 있는 깔끔한 녹화본이 남는다. 이런 녹화본만으로 런북을 자동으로 생성해주는 AI 제품들도 있지만, 아직 직접 써보지 않아서 특정 제품을 추천할 수는 없다.

브레인스토밍

일상적인 업무 과정에서는 무엇을 할지, 무엇을 할 수 있을지에 대한 아이디어가 많이 오간다. 핵심 제품 관점에서든 제품 확장이나 우리가 시도해보고 싶은 다른 실험 관점에서든 마찬가지다. 이 미팅은 사람들이 브레인스토밍을 하고 창의적인 에너지를 한데 모을 공간을 제공하지만, 아쉽게도 발산에서 수렴으로 전환하기가 매우 어렵다.

우선순위 정하기를 위한 별도 미팅을 잡는 것을 추천한다. 우리도 오프사이트 마지막에 수렴하는 자리를 그렇게 마련했다.

우선순위 정하기

궁극적으로 우선순위를 정하는 것은 창업자·CEO·프로덕트 매니저의 몫이므로 완전히 민주적인 과정은 아니다. 우리가 하고 싶은 모든 일을 보드에 펼쳐 놓고, 그 모든 것을 할 시간은 절대 없을 것임을 인정하며 따라서 어려운 결정을 내려야 한다는 점을 생각해보는 것은 유용하다.

Linear나 JIRA 스타일의 평가를 포함해 많은 우선순위 체계에서 내가 느끼는 문제는 우선순위가 시간에 따라 변할 수 있다는 사실을 반영하지 못한다는 것이다. 평점 시스템이나 아이젠하워 매트릭스 스타일의 평가 시스템은 작은 쉬운 단계들을 통해 정보를 얻는 과정에서의 실험 가치나 전쟁의 안개를 담아내지 못한다. 나는 아이디어의 ‘쉬움’과 ‘잠재력’에 기반한 2개 숫자 평가 시스템을 써보자고 제안했고, 각각 1부터 10까지 매기기로 했다. 그런 다음 각 점수 범위의 경계를 정하려 했다(즉, 쉬움 척도에서 1과 10이 각각 무엇을 의미하는지, 잠재력 척도에서 1과 10이 각각 무엇을 의미하는지에 대한 기준을 만드는 것이다).

그런 다음 이 점수들을 곱하거나 더해서 우리가 추진하고 싶은 아이디어들의 순위를 매기는 점수 체계로 활용하려 했다. 우리는 쉬움 척도에 익숙하지 않았다...

모두가 쉬움 척도에서 가장 어려움을 겪었는데, ‘E’를 노력(effort)으로 해석했기 때문이다. 우리는 더 높은 숫자가 더 좋은 것을 의미하길 원했지만, 동시에 낮은 곳에 매달린 열매만 고르지는 않는다는 점도 인정하고 싶었다. 우리는 보상이 클 것으로 기대되는 쉬운 일들과, 장기적으로 보상이 클 것으로 기대되는 어려운 일들을 섞어서 고르고 싶다.

친목 활동

대부분의 사람들은 오글거리는 팀 빌딩 활동을 지겨워한다. 솔직히 우리는 함께 식사하고 Blueberry Hill에 들른 것 외에는 별다른 친목 활동을 하지 않았다. 세인트루이스에 간다면 꼭 가보길 강력히 추천한다. 이 정도면 괜찮다고 생각하지만, 우리 같은 작은 팀에 더 잘 맞는 친목 아이디어가 있다면 언제든 환영이다.