<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[테오 책 RSS Feed]]></title><description><![CDATA[스타트업 CTO가 쓰는 제품 엔지니어링, Agentic AI 논문 리뷰, 조직·성장 에세이, 작은 팀의 기술에 대한 블로그. 오랫동안 제품을 만들어온 엔지니어의 기록.]]></description><link>https://dataportal.kr</link><generator>GatsbyJS</generator><lastBuildDate>Thu, 04 Jun 2026 05:22:11 GMT</lastBuildDate><item><title><![CDATA[프롤로그. 개발자, 회사를 만들다]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-00-prologue/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-00-prologue/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;프로젝트가 끝난 직후의 사무실은 묘한 공기를 품는다. 달리던 관성이 아직 남아 있는데 발밑에는 달릴 길이 없는, 그 특유의 부유감. 은행정보 플랫폼이라는 이름의 프로젝트를 마무리한 뒤가 그랬다. 수십 개 조직이 파편적으로 관리하던 데이터를 하나의 플랫폼으로 통합하고, SDK를 설계해서 연동 공수를 줄이고, 티셔츠까지 만들어 입고 다니며 전사에 보급했다. 제대로 작동하고 있었다. 다음 프로젝트들이 줄 서 있었고, 어떤 것은 흥미로운 기술 과제를 품고 있었다. 떠나야 할 이유가 딱히 보이지 않는 상황이었다.&lt;/p&gt;
&lt;p&gt;그런데 그 사이, 이상한 감각이 자라고 있었다. 플랫폼이 잘 돌아갈수록 드는 생각이 있었다. 이것은 수십 개 조직이 각자 풀고 있던 같은 문제를 한곳에서 풀었기에 가능한 것이다. 그렇다면 조직이라는 구조 자체를 다르게 만들면 어떤 일이 벌어질까. 플랫폼을 만드는 것이 아니라, 플랫폼이 필요 없는 팀을 만들면. 처음부터 모든 맥락이 공유되고, 분업의 경계에서 유실되는 것이 없는 규모의 팀이라면.&lt;/p&gt;
&lt;p&gt;물론 그것은 막연한 상상이었다. 퇴사를 결심하게 된 계기는 좀 더 구체적이었고, 한 사람의 끈질김에서 비롯되었다.&lt;/p&gt;
&lt;h2&gt;1시간의 결정&lt;/h2&gt;
&lt;p&gt;디스콰이엇이라는 플랫폼에서 메시지가 하나 왔다. 공동창업 제안이었다. 당시에는 일주일에 몇 통씩 비슷한 메시지가 도착하던 시기였기에, 대수롭지 않게 넘겼다. 그런데 며칠 뒤 링크드인으로 같은 사람이 다시 찾아왔다. 자료를 정리해서 보내며 이야기를 이어가려는 모습이 보통의 콜드메일과는 달랐다. 자료를 읽기 시작했다.&lt;/p&gt;
&lt;p&gt;공감 가는 내용이 많았다. 기업이 매일 반복하는 비효율을 기술로 풀겠다는 방향, 작은 팀으로 빠르게 움직이겠다는 구상. 궁금한 점들을 메시지로 주고받다가, 마침 가까운 곳에 계신다기에 오프라인에서 만났다.&lt;/p&gt;
&lt;p&gt;만난 지 1시간 만에 말이 나왔다. &quot;같이 하시죠.&quot;&lt;/p&gt;
&lt;p&gt;돌이켜보면 그것은 사업 계획에 대한 확신이 아니었다. 시장 규모를 계산한 것도, 수익 모델을 검증한 것도 아니었다. 이 사람과 함께라면 불확실한 것들 앞에서 도망치지 않을 수 있겠다는 감각이었다. 나중에야 그것을 관계에 대한 직관이라고 이해하게 되었지만, 그 순간에는 그저 몸이 먼저 반응한 것에 가까웠다. 자리에서 일어나 곧장 팀장님에게 퇴사 의사를 전했다.&lt;/p&gt;
&lt;h2&gt;만드는 것에서 함께 만드는 것으로&lt;/h2&gt;
&lt;p&gt;두 사람이 시작한 팀의 첫 번째 일은 코딩이 아니었다. 노코드 도구로 랜딩 페이지를 만들었다. &quot;이런 기능이 곧 출시됩니다. 지금 신청하면 무료입니다.&quot; 단순한 문장이었다. 그런데 200곳이 넘는 기업이 신청했다.&lt;/p&gt;
&lt;p&gt;숫자에 놀라기보다 먼저 한 것은 전화였다. 신청한 기업들을 하나씩 인터뷰했다. 한 달 동안 그들이 실제로 겪고 있는 문제에 파고들었다. 랜딩 페이지에 적었던 기능이 정말로 그들의 문제를 푸는 것인지, 아니면 우리가 상상한 문제일 뿐인지를 확인해야 했다. 그 과정에서 MVP의 윤곽이 잡혔고, 본격 개발에 들어갔다.&lt;/p&gt;
&lt;p&gt;MVP는 정말로 기능에만 충실한 것이었다. 입력란과 버튼의 나열. 하지만 고객들이 쓰기 시작했고, 피드백이 쏟아졌다. 속도를 위해 포기했던 확장성이 발목을 잡았다. 기능 하나를 추가할 때마다 기존 구조가 흔들렸다. 결국 전면 리뉴얼이라는 결단을 내렸다. 작동하고 있는 제품을 처음부터 다시 짓는 일. 두 사람이 감당하기에는 벅찬 규모의 결정이었다.&lt;/p&gt;
&lt;p&gt;그때부터 채용이 현실이 되었다. 프로덕트 디자이너를 먼저 모셨다. 혼자서 제품의 방향과 형태를 모두 결정하던 구조가 한계에 달했기 때문이다. 백엔드 개발자, 프론트엔드 개발자가 합류했다. 두 명이었던 팀이 다섯 명이 되었다.&lt;/p&gt;
&lt;p&gt;다섯이라는 숫자는 작아 보인다. 하지만 그 전환의 무게는 숫자가 말해주지 않는다. 두 사람일 때는 모든 결정이 대화 한 번으로 끝났다. 머릿속에 있는 맥락이 서로에게 거의 그대로 공유되어 있었다. 세 번째 사람이 들어오는 순간, 그 자명함이 사라졌다. 내가 당연하다고 생각하는 것을 상대도 당연하게 여기리라는 전제가 더 이상 성립하지 않았다. 왜 이 기능을 먼저 만드는지, 왜 이 고객의 요구를 거절하는지, 왜 이 방식으로 코드를 짜는지 -- 설명해야 할 것들이 갑자기 불어났다.&lt;/p&gt;
&lt;p&gt;&quot;만드는 것&quot;의 문제가 &quot;함께 만드는 것&quot;의 문제로 바뀌는 순간이었다. 코드의 문제가 아니라 사람의 문제, 구현의 문제가 아니라 조직의 문제가 눈앞에 놓였다. 그리고 솔직히, 그때의 나에게는 그것을 풀 준비가 되어 있지 않았다.&lt;/p&gt;
&lt;h2&gt;이 책이 답하려는 질문&lt;/h2&gt;
&lt;p&gt;개발자가 회사를 만든다는 것은 코드를 짜는 것과 전혀 다른 종류의 문제를 푸는 일이었다. 아키텍처를 설계하는 대신 채용 기준을 세웠고, 코드 리뷰를 하는 대신 피드백의 방식을 고민했다. 버그를 고치는 대신 사람들 사이의 기대치 불일치를 조율했다. 그리고 이 모든 것을 소수의 인원으로 해내야 했다.&lt;/p&gt;
&lt;p&gt;작은 팀은 선택이었다. 큰 조직에서 겪었던 것들 -- 부서 사이에 떠도는 애매한 책임, 중간 관리자를 거치며 왜곡되는 정보, 누구도 전체를 보지 못하는 구조 -- 을 반복하고 싶지 않았다. 하지만 작은 팀을 유지하겠다는 결심만으로 문제가 풀리지는 않았다. 작은 팀이기에 부딪히는 문제들이 따로 있었다. 한 사람의 빈자리가 전체를 흔드는 무게, 명시적 프로세스 없이도 굴러가야 하는 일상, 친밀함이 만드는 침묵의 함정.&lt;/p&gt;
&lt;p&gt;이 책은 그 여정에서 배운 것들의 기록이다.&lt;/p&gt;
&lt;p&gt;작은 팀을 유지하면서 어떻게 큰 일을 해낼 수 있는가. 적은 인원으로 빠르게 움직이되, 방향을 잃지 않으려면 무엇이 필요한가. 이 질문에 대한 완결된 답을 가지고 있다고 말하기는 어렵다. 다만 시행착오 속에서 발견한 몇 가지 원칙이 있고, 그 원칙들이 실제로 작동하는 것을 확인한 경험이 있다.&lt;/p&gt;
&lt;p&gt;그것들을 하나씩 펼쳐보려 한다. 왜 굳이 작은 팀이어야 했는지부터.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[왜 작은 팀인가]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-01-why-small-teams/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-01-why-small-teams/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;스타트업의 가장 큰 강점이 무엇이냐고 물으면, 대부분의 사람들은 &quot;빠른 의사결정&quot;이라고 답한다. 맞는 말이다. 적어도 처음에는. 세 명이 머리를 맞대면 점심시간 안에 제품의 방향이 바뀔 수 있고, 오후에 바로 실행에 옮길 수 있다. 그런데 그 팀이 열 명이 되고, 서른 명이 되고, 쉰 명이 되면 어떤 일이 벌어질까?&lt;/p&gt;
&lt;p&gt;자동차의 바퀴를 생각해보자. 네 개의 바퀴는 자동차를 움직이기에 충분하다. 그런데 바퀴를 여덟 개로 늘리면 두 배로 빨라질까? 열여섯 개로 늘리면? 오히려 바퀴들 사이의 마찰이 생기고, 방향을 틀 때마다 더 많은 에너지가 소모되며, 어느 순간부터는 바퀴가 서로를 방해하기 시작한다. 조직도 마찬가지다. 인원이 늘어난다고 해서 속도가 비례하여 빨라지지 않는다. 오히려 역방향으로 작용하는 힘이 생긴다.&lt;/p&gt;
&lt;p&gt;프롤로그에서 나는 왜 큰 조직을 떠나 작은 팀을 만들었는지를 이야기했다. 이 챕터에서는 그 선택의 이면에 있는 구조적 이유를 들여다보려 한다. 작은 팀을 유지하겠다는 결심이 단순한 취향이 아니라 전략이 될 수 있는 이유, 그리고 조직이 커지면서 잃어버리게 되는 것들에 대한 이야기다.&lt;/p&gt;
&lt;h2&gt;커진 조직에서 벌어지는 일&lt;/h2&gt;
&lt;p&gt;세 명이 함께 시작한 팀이 쉰 명, 백 명으로 불어나는 과정은 겉으로 보기에 성공의 징표다. 투자를 받고, 사람을 뽑고, 부서를 나누고, 각자의 역할을 명확히 정의한다. 조직도에 깔끔한 선이 그어지고, 누가 무엇을 담당하는지가 분명해진다. 합리적인 과정처럼 보인다.&lt;/p&gt;
&lt;p&gt;그런데 바로 이 &quot;명확한 업무 분장&quot;이 예상하지 못한 부작용을 낳는다. 역할이 나뉘는 순간, 역할의 경계에 있는 애매한 일들이 생긴다. 그 일은 누구의 것인가? 아무도 선뜻 손을 들지 않는다. 내 일이 아니니까. 이것이 부서 이기주의의 씨앗이다.&lt;/p&gt;
&lt;p&gt;나는 조직이 커지는 과정을 여러 번 가까이서 지켜보았다. 그때마다 반복적으로 나타나는 풍경이 있었다. 복도에서, 회의실에서, 슬랙 채널에서 이런 말들이 떠돌기 시작하는 것이다. &quot;우리 제품은 왜 이렇게 장애가 잦지?&quot; &quot;1년 전 고객 컴플레인이 왜 아직도 미해결이야?&quot; &quot;개발팀은 도대체 뭘 하고 있는 거야?&quot;&lt;/p&gt;
&lt;p&gt;이 질문들의 공통점은 모두 다른 팀을 향해 있다는 것이다. 각자는 자기 부서의 성과를 위해 열심히 일하고 있다고 믿지만, 그 열심히 일하는 방향이 회사 전체의 방향과 어긋나기 시작한다. 토론이라는 이름 아래 서로에게 책임을 전가하고, 부서 단위로 성과를 극대화하려는 문화가 자리잡는다. 결국 제품의 품질은 떨어지고, 고객 만족도는 하락하며, 성장은 정체된다. 인원을 늘린 것이 성장을 위한 투자였는데, 그 투자가 오히려 성장을 갉아먹는 역설적 상황이 벌어지는 것이다.&lt;/p&gt;
&lt;p&gt;여기에 더해, 커뮤니케이션 레이어가 추가될수록 정보는 왜곡된다. 세 명이 한 방에서 일할 때는 모든 맥락이 공유되었다. 누가 무슨 일을 하고 있는지, 어디서 막혔는지, 어떤 고객이 뭘 원하는지가 공기처럼 자연스럽게 흘렀다. 그런데 팀이 커지면 정보는 중간 관리자를 거치고, 회의록으로 정리되고, 주간 보고서로 압축된다. 그 과정에서 뉘앙스는 사라지고, 의도는 변질되며, 현장의 온도는 숫자로 환원된다. 원래의 문제가 경영진에게 도달할 때쯤이면, 이미 전혀 다른 문제가 되어 있는 경우도 드물지 않다.&lt;/p&gt;
&lt;h2&gt;작은 팀이라는 전략&lt;/h2&gt;
&lt;p&gt;돌이켜보면, 내가 가장 즐겁게 일했던 시기는 크게 노력하지 않아도 모든 구성원이 무슨 일을 하고 있는지 눈에 보이는 규모일 때였다. 대략 스무 명 안팎. 그 정도 규모에서는 회사 전체가 어떻게 돌아가는지 한눈에 들어온다. 내가 하는 일이 회사에 어떤 영향을 미치는지가 명확히 보인다. 그 &quot;보인다&quot;는 감각이 사라지는 순간, 일하는 방식이 근본적으로 달라진다.&lt;/p&gt;
&lt;p&gt;큰 조직에서 일할 때는 회사 전체를 보는 것이 물리적으로 불가능하다. 자연스럽게 시야가 내가 속한 부서의 업무로 좁아진다. 그것은 개인의 의지와 관계없는 구조적 한계다. 반면 작은 팀에서는 전체를 보는 것이 기본값이다. 모든 구성원이 회사의 전체 그림 속에서 자신의 역할을 인식하고, 다른 사람의 일과 자기 일이 어떻게 연결되는지를 체감한다.&lt;/p&gt;
&lt;p&gt;작은 팀을 유지하겠다는 것은 성장을 포기하겠다는 뜻이 아니다. 그것은 성장의 방식을 다르게 정의하겠다는 선언이다.&lt;/p&gt;
&lt;p&gt;스타트업의 전통적 성장 공식은 단순했다. 제품-시장 적합성을 찾으면 투자를 받고, 사람을 뽑고, 규모를 키우고, 다시 투자를 받는 순환. 이 루프는 빠르게 돌수록 좋다고 여겨졌다. 하지만 그 과정에서 조직은 비대해지고, 사업 방향을 전환하기가 점점 어려워진다. 특정 역할을 위해 채용한 사람들을 새로운 방향에 재배치하는 일은 생각보다 훨씬 큰 뚝심과 고통을 수반한다. 매출이 나고 있는 사업을 접고 새로운 것을 시작하겠다는 결정은 조직이 클수록 내리기 어렵다.&lt;/p&gt;
&lt;p&gt;작은 팀은 이 문제에서 훨씬 자유롭다. 인원이 적으면 의사소통 비용이 낮고, 조직을 플랫하게 유지할 수 있으며, 방향 전환이 필요할 때 빠르게 움직일 수 있다. 인재밀도를 높이면서 규모를 억제하는 전략은, 변화의 속도가 빨라지는 세상에서 구조적 이점으로 작용한다.&lt;/p&gt;
&lt;p&gt;여기에 하나의 시대적 흐름이 이 전략을 더욱 유효하게 만들고 있다. 생성형 AI의 등장으로 한 사람이 수행할 수 있는 일의 범위가 급격히 넓어지고 있다는 점이다. 예전에는 열 명이 해야 했던 일을 세 명이 해낼 수 있는 시대가 오고 있다. 이 변화는 작은 팀이 감당할 수 있는 일의 크기를 근본적으로 바꾸어 놓는다. 몸집을 불려 리스크를 키우는 대신, 적은 인원으로 더 큰 임팩트를 만드는 것이 가능해진 것이다. 이 주제는 이 책의 후반부에서 더 깊이 다루게 될 것이다.&lt;/p&gt;
&lt;p&gt;폴 자비스Paul Jarvis는 『Company of One』에서 작은 규모를 유지함으로써 &quot;성장을 위한 성장&quot;이 만들어내는 문제들을 피할 수 있다고 주장한다. 그의 논지에 공감하지만, 나는 한 발 더 나아가고 싶다. 작은 팀을 유지하는 것은 문제를 &quot;피하는&quot; 전략이 아니라, 더 건강하고 오래 지속될 수 있는 성장을 &quot;선택하는&quot; 전략이다. 볼타에서 우리가 작은 팀을 고집하는 이유가 바로 여기에 있다. 불필요한 커뮤니케이션 비용을 줄이고, 효율적으로 일하며, 작은 팀만이 가질 수 있는 강점을 극대화하는 것. 그것이 우리가 정의한 성장의 모습이다.&lt;/p&gt;
&lt;h2&gt;작은 것은 쉽지 않다&lt;/h2&gt;
&lt;p&gt;하지만 여기서 한 가지 고백해야 할 것이 있다.&lt;/p&gt;
&lt;p&gt;작은 팀이 좋다는 말은 쉽다. 그런데 작은 팀을 &quot;제대로 작동시키는 것&quot;은 완전히 다른 문제다. 큰 조직은 시스템으로 비효율을 흡수할 수 있다. 누군가가 빠져도 조직은 돌아간다. 프로세스가 사람을 대체한다. 하지만 작은 팀에서는 한 사람 한 사람의 무게가 크다. 누군가의 부재가 전체에 즉각적인 영향을 미친다. 그래서 작은 팀은 더 정교한 운영 기술을 필요로 한다.&lt;/p&gt;
&lt;p&gt;적은 인원으로 큰 일을 해내려면, 누구와 함께할 것인지를 더 신중하게 결정해야 한다. 리더가 부서의 대리인이 아니라 조직 전체의 리더로 서야 한다. 팀 전체가 같은 방향을 바라보게 만드는 명료함이 있어야 한다. 불편한 말을 할 수 있는 문화가 필요하고, 과정에서 공정함을 느낄 수 있는 시스템이 있어야 한다. 무엇을 할 것인지와 어떻게 할 것인지를 분리할 줄 알아야 하며, 번아웃에 빠지지 않으면서 성과를 만들어내는 방법을 찾아야 한다.&lt;/p&gt;
&lt;p&gt;작은 팀이라는 전제 위에 이 모든 것을 쌓아야 비로소 그 팀은 작동한다.&lt;/p&gt;
&lt;p&gt;그렇다면 작은 팀에서 &quot;함께 일한다&quot;는 것은 정확히 어떤 의미일까? 규모의 문제를 넘어, 관계의 밀도라는 다른 차원의 이야기가 필요하다.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[같이 일한다는 것]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-02-working-together/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-02-working-together/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;카페였다. 테이블 위에 아메리카노 두 잔, 그 사이에 노트북 한 대. 아직 이름도 정하지 못한 서비스의 데이터베이스 구조를 냅킨에 끄적이고 있었다. 상대방이 고개를 들어 말했다. &quot;이거 진짜로 해볼까?&quot; 나는 고개를 끄덕였다. 그 순간에는 몰랐다. 그 한마디가 단순한 프로젝트 제안이 아니라, 서로의 시간과 삶의 궤도를 하나로 엮는 일이었다는 것을.&lt;/p&gt;
&lt;p&gt;같이 일하자는 말은 가볍게 나온다. 술자리에서, 카페에서, 때로는 메신저의 한 줄로. 하지만 그 말이 실행되는 순간, 무게가 완전히 달라진다. 함께 출근하고, 함께 야근하고, 함께 실패를 맞는다. 앞 챕터에서 작은 팀이라는 구조적 선택에 대해 이야기했다. 큰 조직의 관성을 벗어나 빠르게 움직일 수 있는 단위. 하지만 그 구조 안에 어떤 사람들이 있는가, 그리고 그 사람들 사이에 어떤 관계가 형성되는가는 전혀 다른 차원의 문제다.&lt;/p&gt;
&lt;h2&gt;같은 불확실성 안에 서는 것&lt;/h2&gt;
&lt;p&gt;같이 일한다는 것은 같은 공간에 앉는 것이 아니다. 같은 불확실성 안에 서는 것이다.&lt;/p&gt;
&lt;p&gt;초기 스타트업에는 확실한 것이 아무것도 없다. 시장이 존재하는지도, 만들고 있는 제품이 맞는 방향인지도, 다음 달 급여를 줄 수 있는지도 모른다. 이 불확실성은 혼자 감당하면 공포가 되지만, 옆에 같은 것을 바라보는 사람이 있으면 모험이 된다. 공포와 모험의 차이는 능력의 차이가 아니라 관계의 차이다.&lt;/p&gt;
&lt;p&gt;회사의 가치를 이야기할 때 존속가치라는 개념이 있다. 회사가 계속 운영될 때의 가치. 그리고 그 반대편에 청산가치가 있다. 문을 닫았을 때 남는 자산의 합. 초기 스타트업에서는 이 둘의 차이가 거의 없다. 사무실 보증금, 중고 모니터 몇 대, 반쯤 완성된 코드 — 청산하면 남는 것이 없다. 그런데 어떤 팀은 이 간극을 벌린다. 같은 자원, 같은 시장 조건에서도 존속가치가 청산가치를 압도하는 팀이 있다. 그 차이를 만드는 것은 기술력도, 사업 모델의 참신함도 아니다. 함께하는 사람들이 만들어내는 관계의 밀도다.&lt;/p&gt;
&lt;p&gt;투자자들이 초기 팀에 돈을 거는 이유를 생각해본다. 슬라이드 덱에 적힌 TAM 수치나 비즈니스 모델이 결정적이라고 믿는 사람은 드물다. 그들이 실제로 보는 것은 &quot;이 사람들이 함께라면 뭔가 해낼 것&quot;이라는 믿음이 들게 하는 무엇, 즉 창업팀 사이의 관계의 질이다. 아이디어는 바뀔 수 있고, 시장은 변할 수 있다. 하지만 위기가 왔을 때 흩어지지 않고 함께 방향을 틀 수 있는 팀인가 — 이것은 쉽게 바뀌지 않는다.&lt;/p&gt;
&lt;p&gt;위기가 오면 사람의 본질이 드러난다고 흔히 말하지만, 더 정확하게는 관계의 본질이 드러난다. 같은 방향을 바라보고 있었는지, 아니면 그저 같은 자리에 앉아 있었을 뿐인지가 분명해지는 순간. 그 순간을 버틸 수 있는 것은 계약서가 아니라 함께 쌓아온 신뢰다.&lt;/p&gt;
&lt;h2&gt;일상의 태도가 제도를 이긴다&lt;/h2&gt;
&lt;p&gt;관계의 밀도는 거창한 선언이 아니라 일상의 작은 태도에서 만들어진다.&lt;/p&gt;
&lt;p&gt;복지라는 단어를 들으면 떠오르는 이미지가 있다. 실리콘밸리 캠퍼스의 무제한 간식바, 사내 세탁 서비스, 로비를 돌아다니는 반려견. 하지만 복지의 본질은 혜택의 목록이 아니다. 복지는 조직이 구성원에게 보내는 신호다. &quot;당신은 단순한 노동력이 아닙니다. 당신의 삶 전체를 존중합니다.&quot; 무제한 간식이 아니라 아플 때 눈치 보지 않고 쉴 수 있다는 확신, 최신 장비가 아니라 의견을 말해도 불이익이 없다는 안전감. 그것이 진짜 복지다.&lt;/p&gt;
&lt;p&gt;50인 이하의 스타트업에 전속 요리사를 둘 수는 없다. 하지만 옆자리 동료의 컨디션을 물어볼 수는 있다. 누군가 힘들어 보일 때 먼저 &quot;괜찮아?&quot;라고 묻는 것. 실수가 발생했을 때 범인을 찾는 대신 원인을 함께 분석하는 것. 야근이 당연한 것이 아니라 예외라는 사실을 서로 인정하는 것. 이런 작은 태도들이 켜켜이 쌓여서, 사람이 조직을 신뢰하게 되는 토양을 만든다.&lt;/p&gt;
&lt;p&gt;작은 팀에서는 이런 일상의 태도가 제도보다 강력하다. 100페이지짜리 인사 규정보다, 대표가 팀원의 감기약을 사다놓는 행위가 더 큰 메시지를 보낸다. 관계의 밀도란 결국, 서로를 숫자가 아닌 사람으로 대하느냐의 문제이기 때문이다.&lt;/p&gt;
&lt;h2&gt;우리다움이라는 기준점&lt;/h2&gt;
&lt;p&gt;관계의 밀도가 쌓이면 팀 안에 독특한 것이 생겨난다. &quot;우리는 어떤 팀인가&quot;에 대한 공유된 감각. 이것을 나는 &quot;우리다움&quot;이라고 부른다.&lt;/p&gt;
&lt;p&gt;회의실에서 흔히 벌어지는 장면을 떠올려보자. 리더가 새 프로젝트의 기획안을 화면에 띄운다. &quot;의견 있으면 편하게 말해주세요.&quot; 침묵이 흐른다. 결국 &quot;그럼 이대로 진행하겠습니다&quot;라는 말로 회의가 끝난다. 복도에 나서야 두어 사람이 소곤거린다. &quot;솔직히 그 방향 좀 아닌 것 같지 않아?&quot;&lt;/p&gt;
&lt;p&gt;의견이 없어서 침묵한 것이 아니다. 부족한 것은 아이디어가 아니라 확신이다. &quot;이걸 말해도 될까?&quot; &quot;이 수준의 의견을 꺼내도 괜찮을까?&quot; &quot;내가 틀리더라도 이 팀에서는 괜찮을까?&quot; 이 확신의 부재가 입을 닫게 만든다. 그리고 이 확신은 개인의 성격이나 용기와는 거의 관계가 없다. 아무리 대담한 사람이라도 낯선 팀의 첫 회의에서는 말을 아끼게 되고, 내성적인 사람도 안전하다고 느끼는 팀에서는 놀라울 만큼 날카로운 의견을 낸다.&lt;/p&gt;
&lt;p&gt;&quot;우리다움&quot;이 바로 이 확신의 원천이 된다. &quot;우리 팀은 일단 빠르게 해보는 팀&quot;이라는 공유된 감각이 있으면, &quot;이건 너무 오래 고민하고 있는 거 아닌가?&quot;라는 말이 자연스럽게 나올 수 있다. &quot;우리는 데이터 없이는 결정하지 않는 팀&quot;이라는 정체성이 있으면, &quot;이 결정에는 근거가 부족한 것 같다&quot;는 지적이 공격이 아니라 정상적인 점검이 된다. 발언의 근거가 개인의 판단이 아니라 팀의 합의된 정체성 위에 놓이기 때문이다.&lt;/p&gt;
&lt;p&gt;이 &quot;우리다움&quot;은 선언문이나 슬로건으로 만들어지지 않는다. 팀이 함께 일하면서 자연스럽게 축적한 패턴, 반복된 선택, 공유된 기억에서 형성된다. 그리고 이것을 의식적으로 강화하는 방법이 하나 있다. 과거에 누군가가 했던 발언을 되짚어주는 것이다. &quot;지난번에 수진이 말했던 것 있잖아, 사용자 인터뷰를 먼저 하자고 했던 거. 그때 그 방향으로 갔더니 결과적으로 맞았어.&quot; 이 한마디가 만드는 효과는 단순한 칭찬을 넘어선다. 수진의 발언이 팀의 역사에 기록되고, &quot;내가 했던 말이 기억되고 있다&quot;는 감각이 다음 발언의 동기가 된다. 팀 전체에는 &quot;발언은 흘러가는 것이 아니라 축적되는 것&quot;이라는 메시지가 퍼진다.&lt;/p&gt;
&lt;p&gt;결국 좋은 팀을 만드는 사람은 자기가 가장 뛰어난 아이디어를 내는 사람이 아니라, 다른 사람의 아이디어에서 가치 있는 조각을 발견하고 이름을 붙여주는 사람이다. 불완전한 생각이 꺼내지고, 그 위에 다른 생각이 얹히고, 혼자서는 도달할 수 없었던 방향이 만들어지는 순환. 이 순환의 시작은 화려한 인사이트가 아니라 팀원의 서툰 한마디를 주워 올리는 행위에 있다.&lt;/p&gt;
&lt;h2&gt;남는 것&lt;/h2&gt;
&lt;p&gt;왜 이 사람들과 함께 일하는가. 능력 때문인가, 비전 때문인가. 물론 둘 다 중요하다. 하지만 솔직하게 답하자면, 이 사람들 곁에서 나도 좀 더 나은 사람이 되는 것 같아서다. 함께 있을 때 더 용감해지고, 더 솔직해지고, 더 끈기 있어지는 관계. 그런 관계가 &quot;같이 일한다는 것&quot;의 본질이 아닐까.&lt;/p&gt;
&lt;p&gt;사업이 잘될 수도 있고, 안 될 수도 있다. 서비스가 성공할 수도, 실패할 수도 있다. 하지만 함께 일하며 서로를 대했던 방식은 남는다. 어쩌면 그것이 우리가 만든 가장 중요한 것이다.&lt;/p&gt;
&lt;p&gt;이 관계의 무게를 알게 되면, 자연스럽게 다음 질문이 떠오른다. 그렇다면 누구와 함께할 것인가. 관계의 본질을 이해한 사람에게, 새로운 사람을 팀에 들이는 일은 단순한 채용이 아니라 관계를 시작하는 결정이 된다.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[누구와 함께할 것인가]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-03-who-to-work-with/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-03-who-to-work-with/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;같이 일한다는 것의 무게를 알게 되면, 다음 질문은 자연스럽게 따라온다. 그렇다면 누구와 함께해야 하는가.&lt;/p&gt;
&lt;p&gt;창업 초기, 두 사람이 카페에서 서비스 구조를 그리던 시절에는 이 질문이 그리 복잡하지 않았다. 서로의 부족함을 채울 수 있는 사람, 같은 방향을 보고 있는 사람이면 충분했다. 그러나 제품이 시장에 나가고 고객이 생기기 시작하면, 두 사람만으로는 감당할 수 없는 영역이 나타난다. 그때 비로소 채용이라는 단어가 현실이 된다.&lt;/p&gt;
&lt;p&gt;작은 팀에서 채용은 빈자리를 메우는 일이 아니다. 팀의 밀도를 재조정하는 일이다. 다섯 명이 일하는 조직에서 한 사람은 전체의 20퍼센트다. 그 한 사람이 어떤 사고방식을 가졌는지, 어떤 강점을 지녔는지, 팀에 어떤 자극을 줄 수 있는지에 따라 조직 전체의 색깔이 바뀐다. 대기업에서 채용이 인력 수급의 문제라면, 작은 팀에서 채용은 정체성의 문제다.&lt;/p&gt;
&lt;h2&gt;3500 대 3&lt;/h2&gt;
&lt;p&gt;2023년, 볼타는 처음으로 본격적인 채용을 시작했다. 여러 플랫폼에 공고를 올렸고, 약 3500명이 지원했다. 모 채용 플랫폼에서 인기순 1위를 2주 연속 유지하기도 했다. 그리고 최종적으로 세 사람을 모셨다.&lt;/p&gt;
&lt;p&gt;3500 대 3이라는 숫자가 자랑이 아니다. 이 숫자는 경쟁률이 아니라, 작은 팀에서 한 사람을 선택하는 일이 얼마나 무거운 결정인지를 보여준다. 수천 명의 이력서를 읽고, 과제를 검토하고, 인터뷰를 진행하면서 깨달은 것이 있다. 채용에서 가장 중요한 것은 뛰어난 사람을 찾는 것이 아니라, 이 팀에 맞는 사람을 찾는 것이다. 그리고 그 기준을 명확히 갖고 있지 않으면, 수천 명의 이력서 앞에서 길을 잃는다.&lt;/p&gt;
&lt;p&gt;불합격을 안내드린 분들에게 500자에서 1000자에 이르는 피드백을 보냈다. 시간이 많아서가 아니었다. 지원해주신 분들의 시간을 존중하는 것이 채용의 첫 번째 원칙이라고 생각했기 때문이다. 채용은 합격자만을 위한 과정이 아니다. 불합격자에게 어떤 태도를 보이느냐가, 그 조직이 사람을 어떻게 대하는지를 드러낸다.&lt;/p&gt;
&lt;h2&gt;같이 일해본 사람을 모시지 않는다는 것&lt;/h2&gt;
&lt;p&gt;첫 번째 채용 원칙은 의외의 것이었다. 같이 일해본 적 있는 사람을 풀타임으로 모시지 않는다는 원칙.&lt;/p&gt;
&lt;p&gt;대부분의 창업자는 정반대의 선택을 한다. 검증된 사람, 손발이 맞는 사람, 따로 설명하지 않아도 서로의 생각을 아는 사람을 데려온다. 합리적인 판단처럼 보인다. 초기 속도가 중요한 스타트업에서 커뮤니케이션 비용을 줄이는 것은 분명한 이점이다.&lt;/p&gt;
&lt;p&gt;그러나 이 이점 뒤에는 세 가지 그림자가 있다.&lt;/p&gt;
&lt;p&gt;첫째, 조직의 개성이 사라진다. 비슷한 경험을 공유한 사람끼리는 서로에게 새로운 자극을 주기 어렵다. 같은 회사에서 같은 방식으로 일했던 사람들이 모이면, 그 조직은 이전 조직의 복제품이 될 위험이 있다. 작은 팀이 가져야 할 가장 큰 무기는 다양한 시각인데, 그 무기를 스스로 내려놓는 셈이다.&lt;/p&gt;
&lt;p&gt;둘째, 건강하게 싸우기 어렵다. 제품을 만들다 보면 의견이 충돌하는 순간이 반드시 온다. 그때 이미 쌓인 친분은 오히려 족쇄가 된다. 관계가 틀어질까 두렵고, 나쁜 사람으로 기억되는 게 싫어서 갈등을 피한다. 표면적으로는 화목한 팀이지만, 속으로는 중요한 논쟁을 회피하는 팀. 그런 팀은 결정적인 순간에 최선의 판단을 내리지 못한다.&lt;/p&gt;
&lt;p&gt;셋째, 보이지 않는 벽이 생긴다. 눈빛만으로 서로의 생각을 읽는 관계는 두 사람 사이에서는 효율적이다. 하지만 팀에 새로운 사람이 합류하면 이야기가 달라진다. 설명 없이 통하는 두 사람과, 그 맥락을 알 수 없는 나머지 사이에 의도하지 않은 파벌이 만들어진다. 팀이 커질수록 이 벽은 두꺼워지고, 결국 조직 전체의 커뮤니케이션을 병들게 한다.&lt;/p&gt;
&lt;p&gt;이 원칙은 친한 사람과 일하지 말라는 뜻이 아니다. 친분에 기대어 채용의 본질을 건너뛰지 말자는 뜻이다. 작은 팀에서 한 사람의 합류는 기존의 균형을 깨뜨리는 일이다. 그 균형을 깨뜨릴 때, 더 나은 균형으로 재편되어야 한다. 익숙함은 안정감을 주지만, 작은 팀에 필요한 것은 안정감이 아니라 긴장감이다.&lt;/p&gt;
&lt;h2&gt;인재밀도를 높이는 기준들&lt;/h2&gt;
&lt;p&gt;그렇다면 어떤 사람을 모셔야 하는가. 수천 건의 이력서를 검토하고 수십 번의 인터뷰를 진행하면서, 채용의 기준은 점점 구체화되었다.&lt;/p&gt;
&lt;p&gt;가장 먼저 확인한 것은 팀과의 적합성이었다. 그러나 단순히 &quot;분위기에 잘 어울리는 사람&quot;이라는 뜻이 아니다. 팀 Fit이라는 말에는 더 깊은 의미가 있었다. 기존 팀원들과 잘 맞으면서도, 동시에 기존 팀에 없는 캐릭터를 가진 사람. 합류했을 때 기존 팀원들이 새롭게 배울 수 있는 무언가가 분명한 사람. 조화와 자극, 이 두 가지를 동시에 충족시키는 사람을 찾는 것이 핵심이었다.&lt;/p&gt;
&lt;p&gt;세 사람을 모시는 과정에서 이 기준은 구체적인 판단으로 이어졌다. 제품 리뉴얼을 앞두고 가장 먼저 모신 프로덕트 디자이너는 이전 환경에서의 강점이 명확하면서도, 완전히 새로운 환경에서 도전하겠다는 확신이 뚜렷한 사람이었다. 백엔드 엔지니어는 아직 대학에 재학 중이었지만, 경력자들도 어려워하는 인터뷰를 훌륭히 통과했고, 무엇보다 신선한 시각과 열정으로 제품에 새로운 의견을 던질 수 있는 사람이었다. 프론트엔드 엔지니어는 한정된 시간 안에서 일을 효율적으로 해내는 능력이 인터뷰 과정에서부터 드러난, 모든 팀원에게 귀감이 될 수 있는 사람이었다.&lt;/p&gt;
&lt;p&gt;세 사람의 공통점이 있었다. 양적 확장이 가능하다는 것. 기존 팀원이 하는 일을 당연히 소화하면서도, 새로운 영역으로 확장하는 데 기여할 수 있는 사람이라는 판단이 있었다. 작은 팀에서는 한 사람이 하나의 역할만 수행하는 것이 사치다. 자신의 전문 영역을 깊이 파면서도, 필요하면 경계를 넘나들 수 있는 사람이어야 한다.&lt;/p&gt;
&lt;p&gt;채용 프로세스 자체도 진화했다. 초기에는 이력서, 사전 과제, 온사이트 인터뷰로 이어지는 전통적인 방식을 따랐다. 짧으면 2주, 길면 한 달. 그런데 온사이트까지 왔는데도 가장 중요하게 보는 부분에서 아쉬움을 느끼는 경우가 반복됐다. 후보자도 회사도 많은 시간을 투자한 뒤에 불합격을 통보받는 상황. 이것은 제품 개발에서 말하는 Fast Fail의 부재와 같은 문제였다.&lt;/p&gt;
&lt;p&gt;그래서 30분 남짓의 사전 인터뷰를 도입했다. 이력서만으로는 알 수 없는, 팀이 가장 중요하게 여기는 가치관과 태도를 초기에 확인하기 위해서다. 제품 개발에서 빠르게 검증하고 빠르게 방향을 잡는 것이 중요하듯, 채용에서도 서로의 시간을 낭비하지 않는 것이 예의이자 효율이었다. 사업적 임팩트를 주도적으로 만들고 싶은 사람인지, 안정보다 혁신에 가치를 두는 사람인지, 뛰어난 동료에게서 자극받는 사람인지. 이런 질문에 대한 답은 긴 과제가 아니라 짧은 대화에서 더 정직하게 드러난다.&lt;/p&gt;
&lt;h2&gt;서로 다른 시간을 가진 사람들&lt;/h2&gt;
&lt;p&gt;좋은 사람을 모시면 끝일까. 그렇지 않다. 채용 이후에는 또 다른 긴장이 기다린다.&lt;/p&gt;
&lt;p&gt;스타트업이 성장하면 피할 수 없는 순간이 있다. 처음부터 함께한 사람들과 새로 합류한 사람들 사이의 미묘한 갈등. &quot;우리가 처음부터 여기 있었는데&quot;라는 감정과, &quot;지금 중요한 건 현재의 역량 아닌가&quot;라는 논리가 부딪힌다. 어느 쪽이 옳다고 말하기 어렵다. 둘 다 진실이기 때문이다.&lt;/p&gt;
&lt;p&gt;함께 시작한 사람들의 기여를 기억하는 것은 중요하다. 아무것도 없던 시절에 불확실성을 함께 감내한 사람들이다. 하지만 그 기여가 특권이 되는 순간, 조직은 병든다. 과거의 공로가 현재의 면책으로 작동하면, 새로 합류한 사람은 아무리 뛰어나도 보이지 않는 천장을 느끼게 된다. 반대로, 새로운 사람의 역량만을 기준으로 삼으면 초기 멤버들은 자신이 소모품이었다는 감정을 갖게 된다.&lt;/p&gt;
&lt;p&gt;이 균형을 잡는 데 정답은 없다. 다만 태도는 있다. 기여를 기억하되 특권으로 만들지 않는 것. 역량을 존중하되 맥락을 무시하지 않는 것. 그리고 무엇보다, 팀 안에서 서로 다른 시간을 가진 사람들이 같은 현재를 만들어가고 있다는 사실을 모두가 인식하는 것.&lt;/p&gt;
&lt;p&gt;채용은 팀에 사람을 더하는 산술이 아니다. 팀의 밀도를 재조정하는 화학이다. 한 사람이 합류하면 기존의 관계, 역할, 무게중심이 모두 변한다. 그 변화를 두려워하지 않되, 가볍게 여기지도 않는 것. 3500명 중 세 사람을 선택한 그 무게가, 선택 이후에도 계속된다는 것을 아는 것. 그것이 작은 팀의 채용이 가진 진짜 의미가 아닐까.&lt;/p&gt;
&lt;p&gt;좋은 사람들을 모셨다면, 이제 다음 질문이 찾아온다. 그 사람들이 함께 리더십팀을 구성할 때, 무엇이 가장 중요한가.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[리더는 부서의 대사가 아니다]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-04-leader-not-ambassador/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-04-leader-not-ambassador/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;좋은 사람들을 모았다. 인재밀도를 지키기 위해 채용 기준을 세우고, 함께 일해본 적 없는 사람에게까지 손을 뻗었다. 이제 그 사람들이 리더로서 한 테이블에 앉는다. 그런데 막상 테이블에 둘러앉으면, 기대했던 것과는 다른 광경이 펼쳐진다.&lt;/p&gt;
&lt;p&gt;엔지니어링 리드가 먼저 입을 연다. &quot;개발팀 입장에서 말씀드리면, 이번 일정은 현실적으로 어렵습니다.&quot; 프로덕트 리드가 바로 받는다. &quot;PM 조직에서는 이 기능이 이번 분기에 반드시 나가야 한다고 보고 있습니다.&quot; 디자인 리드가 끼어든다. &quot;디자인팀 관점에서는 품질을 더 가져가고 싶은데요.&quot;&lt;/p&gt;
&lt;p&gt;대화는 정중하다. 분위기도 나쁘지 않다. 그런데 한 시간이 지나 회의실을 나서면, 결정된 것은 거의 없다. 각자 자기 팀의 이익을 조금씩 양보해서 타협안을 만들었지만, 누구도 만족하지 못했고, 조직 전체에 가장 좋은 결정이 무엇인지는 논의조차 되지 않았다. 이 미팅은 도대체 무엇이었을까.&lt;/p&gt;
&lt;h2&gt;대사의 함정&lt;/h2&gt;
&lt;p&gt;이 장면을 가만히 들여다보면, 익숙한 구조가 보인다. UN 총회다. 각국의 대사들이 자국의 이익을 대표하여 발언하고, 양보는 최소화하며, 자국에 유리한 결과를 이끌어내는 것이 유능한 대사의 조건인 그 자리. 리더십 미팅이 UN 총회와 닮았다면, 그 안에 앉아 있는 사람들은 리더가 아니라 대사로 행동하고 있다는 뜻이다.&lt;/p&gt;
&lt;p&gt;대사에게 &quot;당신 나라 이익을 포기하고 전체를 위해 양보하라&quot;고 말하면, 그는 어이없어할 것이다. 자국의 이익을 극대화하는 것이 대사의 존재 이유이기 때문이다. 문제는, 많은 리더십팀이 정확히 이 구조로 작동한다는 점이다. 엔지니어링 리드는 개발팀의 대사, 프로덕트 리드는 PM 조직의 대사, 디자인 리드는 디자인팀의 대사. 미팅의 결과는 각 부서 이익의 교집합이지, 조직 전체를 위한 최선의 결정이 아니다.&lt;/p&gt;
&lt;p&gt;여기서 근본적인 질문이 생긴다. 리더십팀에 앉아 있는 사람들의 정체성은 무엇인가. 그들은 부서의 대사인가, 조직의 리더인가.&lt;/p&gt;
&lt;p&gt;내가 직접 리더십팀을 운영하면서 확신하게 된 것이 하나 있다. 리더십팀에서 나의 첫 번째 팀은 내가 이끄는 팀이 아니라, 내가 속한 리더십팀 그 자체라는 것이다. 이것은 자기 팀을 소홀히 하라는 뜻이 아니다. 리더십팀에서 내린 결정이 조직 전체에 가장 좋은 결정이 되어야, 결국 내 팀도 더 나은 환경에서 일할 수 있다는 의미다. 대사는 자국에 불리한 결정에 반대하지만, 리더는 자기 부서에 불리하더라도 조직 전체에 좋은 결정이면 기꺼이 지지한다. 이 차이가 UN 총회와 리더십팀을 갈라놓는다.&lt;/p&gt;
&lt;h2&gt;하나의 팀, 하나의 점수&lt;/h2&gt;
&lt;p&gt;축구 경기를 떠올려 보자. 한 미드필더가 경기 후 인터뷰에서 말한다. &quot;저는 오늘 패스 성공률 94%를 기록했습니다. 제 역할은 충분히 했다고 생각합니다.&quot; 그런데 팀은 0대 3으로 졌다. 이 미드필더는 좋은 경기를 한 것인가.&lt;/p&gt;
&lt;p&gt;축구에서는 답이 자명하다. 개인 기록이 아무리 좋아도 팀이 지면 의미가 없다. 이긴 팀의 벤치 선수도 이긴 것이고, 진 팀의 MVP도 진 것이다. 모든 선수가 같은 점수를 받는다.&lt;/p&gt;
&lt;p&gt;조직도 다르지 않다. 엔지니어링팀이 모든 기술 지표를 달성했지만 회사 전체가 분기 목표를 놓쳤다면, 엔지니어링 리드도 실패한 것이다. 마케팅팀이 캠페인 성과를 초과 달성했지만 제품이 제때 나가지 못해 매출이 빠졌다면, 마케팅 리드도 그 결과에서 자유롭지 않다. &quot;내 팀은 잘했는데 왜 나까지 실패인가&quot;라는 반문이 나올 수 있다. 그러나 바로 그 불공정함을 받아들이는 것이 리더십팀의 구성원이 된다는 것의 의미다.&lt;/p&gt;
&lt;p&gt;내 부서의 성과가 좋으면서 회사 전체가 흔들린다면, 그것은 내가 리더십팀의 일원으로서 충분히 기여하지 못했다는 신호이기도 하다. 다른 부서의 병목을 함께 풀었어야 했고, 자원 배분에 대해 더 적극적으로 목소리를 냈어야 했다.&lt;/p&gt;
&lt;p&gt;하나의 팀, 하나의 점수를 받아들이면 리더십 미팅의 풍경이 달라진다. &quot;우리 팀 입장에서는&quot;이라는 말 대신 &quot;회사 전체로 볼 때&quot;라는 말이 나오기 시작한다. 다른 부서의 문제가 남의 일이 아니게 된다. 자원이 부족한 팀을 돕는 것이 내 부서의 이익을 줄이는 것이 아니라 모두의 점수를 올리는 행위가 된다.&lt;/p&gt;
&lt;p&gt;그런데 왜 이것이 말처럼 쉽지 않을까. 세 가지 저항이 있다.&lt;/p&gt;
&lt;p&gt;첫째, 정체성의 문제다. &quot;나는 엔지니어링 리드다&quot;라는 문장에서 정체성은 엔지니어링에 놓인다. 매일 함께 일하는 사람은 개발팀 동료들이고, 리더십 미팅은 일주일에 한두 번이다. 소속감은 자연스럽게 부서 쪽으로 기운다.&lt;/p&gt;
&lt;p&gt;둘째, 팀원들의 시선이다. 리더가 리더십 미팅에서 돌아오면 팀원들은 묻는다. &quot;우리한테 유리한 결과가 나왔나요?&quot; &quot;사실 회사 전체를 위해 우리가 양보하기로 했다&quot;고 말하면 실망하는 표정이 돌아올 수 있다. 이 순간의 두려움이 크다. 부서 밖에서는 조직의 리더로 행동했는데, 부서 안에서 배신자 취급을 받을까 걱정하는 것이다.&lt;/p&gt;
&lt;p&gt;셋째, 단기 성과의 유혹이다. 리더십 미팅에서 부서 이익을 최대한 지키면, 부서로 돌아가서 &quot;승리&quot;를 보고할 수 있다. 단기적으로는 팀의 사기가 올라간다. 그러나 이 승리가 쌓이면, 리더십팀은 점점 더 UN 총회로 변질된다.&lt;/p&gt;
&lt;p&gt;하지만 대부분의 팀원들이 정말로 원하는 것은 &quot;우리 편만 드는 리더&quot;가 아니다. 그들이 원하는 것은 &quot;회사가 잘 되게 만드는 리더&quot;다. 조직이 잘 되어야 팀도 잘 되고, 팀이 잘 되어야 개인도 잘 된다는 것을 합리적인 사람이라면 이해한다. 다만, 그 결정의 배경을 투명하게 설명해야 한다. &quot;그냥 결정됐다&quot;가 아니라, 왜 이 결정이 조직 전체에 가장 좋은지, 우리 팀에는 어떤 영향이 있고 장기적으로 어떤 이점이 있는지를 말해야 한다.&lt;/p&gt;
&lt;h2&gt;문제 해결형 리더의 세 축&lt;/h2&gt;
&lt;p&gt;리더십팀에서 대사의 자리를 내려놓았다면, 그 자리에 무엇을 채워야 하는가. 나는 제럴드 와인버그의 MOI 모델을 접한 뒤, 이 질문에 대한 하나의 프레임워크를 얻었다. 변화를 만들어내려면 세 가지가 필요하다.&lt;/p&gt;
&lt;p&gt;동기부여(Motivation)는 사람들이 움직이도록 만드는 힘이다. 위협이나 보상만을 말하는 것이 아니라, 왜 이 일이 중요한지를 스스로 느끼게 하는 것까지 포함한다. 조직화(Organization)는 아이디어가 실현될 수 있는 구조를 만드는 것이다. 아무리 좋은 아이디어가 있어도 실행할 수 있는 체계가 없으면 공허하다. 아이디어(Idea)는 씨앗이다. 문제를 새로운 각도에서 보게 하는 관점, 해결책의 실마리가 되는 발상이다.&lt;/p&gt;
&lt;p&gt;세 가지 중 하나라도 빠지면 변화는 일어나지 않는다. 반대로 말하면, 변화를 저지하고 싶다면 셋 중 하나만 무너뜨리면 된다. 의욕을 꺾거나, 협력 체계를 무너뜨리거나, 아이디어의 흐름을 막으면 조직은 멈춘다. 이 사실을 인지하는 것 자체가 리더에게는 중요한 자각이다.&lt;/p&gt;
&lt;p&gt;이 모델을 실제 개발 조직에 적용하면, 문제 해결형 리더가 집중해야 할 세 가지 축이 드러난다.&lt;/p&gt;
&lt;p&gt;첫째, 문제를 이해하는 것이다. 성공과 실패가 사소한 문제 정의의 차이에 달려 있는 경우가 많다. 논쟁이 길어지는 이유의 대부분은 해결 방법의 차이가 아니라 문제에 대한 이해가 다르기 때문이다. 문제 해결형 리더는 논쟁의 근원이 문제 정의에 있는지, 해결 방법에 있는지를 구분할 줄 안다. 그리고 팀원들이 고객의 문제를 직접 이해하도록 끊임없이 권장한다. 복잡한 문제를 처음부터 제대로 이해하는 경우는 거의 없지만, 이해하고 있다고 착각하는 경우는 많다. 그 착각이 재앙으로 가는 가장 확실한 길이다.&lt;/p&gt;
&lt;p&gt;둘째, 아이디어의 흐름을 관리하는 것이다. 아이디어가 너무 적으면 해결책을 얻을 수 없고, 너무 많으면 혼란이 온다. 여기서 핵심적인 행동 두 가지가 있다. 하나는 팀 동료의 아이디어를 즉각 비판하지 않는 것이다. 아이디어를 테스트하는 것과 즉각 비판하는 것은 전혀 다른 문제다. &quot;그건 안 될 거야&quot;라는 말은 아이디어를 검증하는 것이 아니라 아이디어의 흐름 자체를 끊어버린다. 다른 하나는 시간의 압박에 굴복하지 않고 사람들의 아이디어에 귀 기울이는 시간을 갖는 것이다. 시간이 부족하면 대부분의 아이디어를 제대로 이해하기도 전에 포기하게 된다. 단기적으로는 시간을 절약하는 것처럼 보이지만, 자신의 아이디어가 부당하게 버려졌다고 느끼는 사람은 열의를 잃는다. 역설적으로, 모든 아이디어에 귀 기울이는 팀이 결과적으로 더 빠르게 전진한다.&lt;/p&gt;
&lt;p&gt;셋째, 품질을 유지하는 것이다. &quot;열심히 하면 된다&quot;는 목표가 없는 상태에서의 자기 위안에 불과하다. 문제 해결형 리더는 프로젝트를 진행하면서 끊임없이 품질을 측정하고, 때로는 한 걸음 물러나서 전체를 조망한다. 특히 중요한 것은 프로젝트가 가망이 없다는 것을 알아차렸을 때, 다른 사람들이 더 많은 노력을 쏟기 전에 그 사실을 받아들이도록 설득하는 용기다.&lt;/p&gt;
&lt;p&gt;이 세 축은 서로 독립적이지 않다. 문제를 깊이 이해해야 좋은 아이디어가 나오고, 아이디어의 흐름이 건강해야 품질 높은 결과물이 만들어지며, 품질에 대한 명확한 기준이 있어야 문제를 올바르게 정의할 수 있다. 리더는 이 세 축 사이를 끊임없이 오가며 팀이 앞으로 나아가도록 돕는 사람이다.&lt;/p&gt;
&lt;h2&gt;변화를 만들어내는 모든 사람&lt;/h2&gt;
&lt;p&gt;리더십 미팅에서 주어를 바꾸는 것부터 시작할 수 있다. &quot;개발팀 입장에서는&quot;을 &quot;회사 전체로 볼 때&quot;로 바꿔 보는 것이다. 단순한 언어의 변화지만, 이 전환이 사고의 프레임을 바꾼다. &quot;개발팀 입장에서는 일정이 부족합니다&quot;는 부서의 어려움을 호소하는 것이고, &quot;회사 전체로 볼 때 이 일정에서 가장 큰 리스크는 품질입니다&quot;는 조직의 의사결정에 기여하는 것이다.&lt;/p&gt;
&lt;p&gt;다른 부서의 문제에 먼저 나서는 것도 연습이 된다. 마케팅팀이 어려움을 겪고 있을 때 &quot;그건 마케팅 이슈니까&quot;라고 넘기는 대신 &quot;우리 팀에서 도울 수 있는 부분이 있을까&quot;라고 묻는다. 이것은 선의만의 문제가 아니다. 마케팅의 문제가 해결되지 않으면 회사 전체의 점수가 내려가고, 그것은 곧 내 점수이기도 하다.&lt;/p&gt;
&lt;p&gt;그리고 결정이 내려진 후에는 그것을 진심으로 지지해야 한다. 리더십 미팅에서 충분히 토론한 뒤 결정이 내려지면, 설령 내가 원래 다른 의견이었더라도 부서로 돌아가서 그 결정을 적극적으로 지지해야 한다. &quot;나는 반대했는데 그렇게 결정됐다&quot;라고 말하는 순간, 리더십팀의 결정은 힘을 잃는다. 팀원들은 리더십팀이 하나의 팀이 아니라 각자 따로 노는 집단이라고 느끼게 된다.&lt;/p&gt;
&lt;p&gt;이 모든 연습의 밑바닥에는 하나의 자각이 깔려 있다. 리더는 조직에서 임명된 사람만을 의미하지 않는다. 변화를 만들어내는 모든 사람이 리더다. 직급이 주어지기 전에도 문제를 이해하고, 동료의 아이디어에 귀 기울이고, 품질에 대해 타협하지 않는 사람은 이미 리더로서 행동하고 있는 것이다.&lt;/p&gt;
&lt;p&gt;리더십팀이 하나의 팀으로 작동하기 시작하면, 자연스럽게 다음 질문이 떠오른다. 그렇다면 이 팀이 합의해야 할 것은 무엇인가. 리더들이 대사의 자리를 내려놓고 조직의 리더로 섰다면, 그다음으로 필요한 것은 모두가 같은 답을 할 수 있는 명료함이다.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[미션보다 명료함]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-05-clarity-over-mission/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-05-clarity-over-mission/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;리더들이 부서의 대사가 아니라 조직의 리더로 서기 시작했다고 하자. 회의실에서 &quot;우리 팀 입장에서는&quot;이라는 말 대신 &quot;회사 전체로 볼 때&quot;라는 말이 나오기 시작했다. 좋은 출발이다. 하지만 곧 다음 질문이 찾아온다. 조직의 리더로 사고하겠다는 마음은 먹었는데, 도대체 무엇에 대해 함께 사고해야 하는가? 그 &quot;무엇&quot;이 불분명하면, 아무리 훌륭한 태도도 방향 없이 떠돈다.&lt;/p&gt;
&lt;p&gt;많은 조직이 이 문제를 미션 선언문으로 해결하려 한다. 그리고 대부분 실패한다.&lt;/p&gt;
&lt;h2&gt;로비에 걸린 문장&lt;/h2&gt;
&lt;p&gt;어느 회사의 로비에서 액자를 본 적이 있다. 깔끔한 프레임 안에 정성스러운 서체로 인쇄된 한 문장이 있었다. 고객에게 최고의 가치를 제공하고, 세계적인 혁신을 통해 모든 이해관계자가 함께 성장하는 기업이 되겠다는 내용이었다. 읽는 데 10초가 걸렸다. 다 읽은 뒤에도 이 회사가 무엇을 하는 회사인지 알 수 없었다. 그 앞을 지나는 직원들 중 발걸음을 멈추고 그 문장을 읽는 사람은 아무도 없었다. 읽었다 해도 달라질 것은 없었을 테지만.&lt;/p&gt;
&lt;p&gt;재미있는 사실이 하나 있다. 미국 드라마 &amp;#x3C;더 오피스&gt;에 등장하는 허구의 제지 회사 던더 미플린에는 이런 미션 선언문이 있다. &quot;고품질의 제품과 서비스를 통해 고객의 삶에 가치를 더하며, 직원들과 장기적인 유대 관계를 구축하여 자부심을 갖고 안정적으로 업무에 임할 수 있게 한다.&quot; 기업 문화를 풍자하기 위해 코미디 작가들이 만든 문장이다. 그런데 이 문장을 실제 기업 로비에 걸어놓으면, 아무도 가짜라고 눈치채지 못할 것이다.&lt;/p&gt;
&lt;p&gt;이것은 특정 기업의 문제가 아니다. 미션 선언문이라는 형식 자체가, 진짜로 의미 있는 말을 담기 어려운 구조를 가지고 있다는 뜻이다.&lt;/p&gt;
&lt;h2&gt;한 문장이라는 함정&lt;/h2&gt;
&lt;p&gt;미션 선언문은 왜 실패하는가. 근본적인 원인은 욕심이다.&lt;/p&gt;
&lt;p&gt;하나의 문장 안에 너무 많은 것을 담으려 한다. 영감을 주면서 동시에 정보를 전달하고, 동기를 부여하면서 시장 포지셔닝까지 규정하려 한다. 그 결과 어떤 것도 제대로 해내지 못하는 문장이 탄생한다. &quot;고객에게 최고의 만족을 제공하며...&quot; — 이 세상에 고객에게 최고의 만족을 제공하지 않겠다고 선언하는 기업이 어디 있겠는가. 이런 문장은 아무것도 규정하지 못한다. 경쟁사와의 차별점도, 지금 우리가 무엇에 집중해야 하는지도 말해주지 않는다.&lt;/p&gt;
&lt;p&gt;만드는 과정도 문제다. 경영진이 모여 각자의 바람을 한 문장에 우겨넣는다. 마케팅 담당은 고객 가치를 넣고 싶어하고, 재무 담당은 주주 가치를 넣고 싶어하고, 인사 담당은 직원 성장을 넣고 싶어한다. 그렇게 모두의 소망이 담긴 장문의 선언문이 나온다. 누구도 반대하지 않지만, 누구에게도 영감을 주지 못하는 문장. 이 문장을 회사 로비에 걸고, 티셔츠에 인쇄하고, 연례 보고서 첫 페이지에 넣는다. 그리고 다음 날부터 아무도 신경 쓰지 않는다.&lt;/p&gt;
&lt;p&gt;더 본질적인 문제가 있다. 미션 선언문은 태생적으로 대화를 끝내기 위한 도구다. &quot;자, 이 문장에 합의했으니 넘어갑시다.&quot; 하지만 조직의 명료함은 대화를 끝내는 것이 아니라, 충분히 깊은 대화를 나누는 과정에서 만들어진다. 리더들 사이에 생각의 차이가 조금이라도 남아 있으면, 그 차이는 조직 아래로 내려갈수록 증폭된다. 리더 간의 미묘한 불일치가 부서 간의 끝없는 논쟁이 되고, 구성원들은 일관된 메시지를 받지 못해 각자의 방향으로 흩어진다.&lt;/p&gt;
&lt;p&gt;멋진 한 문장이 아니라, 다른 무엇이 필요했다.&lt;/p&gt;
&lt;h2&gt;다섯 명의 리더, 다섯 개의 답&lt;/h2&gt;
&lt;p&gt;리더십 미팅에서 한 가지 질문을 던진 적이 있다.&lt;/p&gt;
&lt;p&gt;&quot;우리 조직에서 지금 가장 중요한 것이 뭔가요?&quot;&lt;/p&gt;
&lt;p&gt;간단한 질문이었다. 그런데 다섯 명의 리더에게서 다섯 개의 다른 답이 나왔다. 한 명은 채용이라 했고, 한 명은 기술 부채 해소라 했고, 한 명은 신규 기능 출시, 한 명은 고객 이탈 방지, 한 명은 팀 문화 개선이라 했다. 다섯 개의 답 모두 틀린 것은 아니었다. 하지만 다섯 개가 동시에 &quot;가장 중요한 것&quot;일 수는 없었다.&lt;/p&gt;
&lt;p&gt;그 순간 깨달은 것이 있었다. 이 조직에는 전략도 있고, 유능한 사람도 있고, 열정도 있다. 하지만 명료함이 없었다. 그리고 명료함이 없는 조직에서는, 모두가 열심히 일하면서도 같은 방향으로 가고 있지 않다.&lt;/p&gt;
&lt;p&gt;패트릭 렌시오니는 조직의 건강을 위해 리더십팀이 반드시 합의해야 할 여섯 가지 질문을 제시한다. 우리는 왜 존재하는가. 우리는 어떻게 행동하는가. 우리는 무엇을 하는가. 우리는 어떻게 성공할 것인가. 현재 가장 중요한 것은 무엇인가. 누가 무엇을 해야 하는가. 이 질문들을 처음 접하면 너무 기본적이라는 생각이 든다. 이걸 모르는 리더십팀이 어디 있겠는가. 하지만 핵심은 &quot;아는 것&quot;이 아니다. 핵심은 &quot;모두가 같은 답을 할 수 있는가&quot;이다.&lt;/p&gt;
&lt;p&gt;각자 머릿속에 답이 있는 것과, 리더 전원이 동일한 답을 명료하게 말할 수 있는 것은 전혀 다른 상태다. 전자는 개인의 확신이고, 후자는 조직의 명료함이다. 대부분의 조직은 전자에 머물러 있다.&lt;/p&gt;
&lt;h2&gt;여섯 개의 문, 하나의 복도&lt;/h2&gt;
&lt;p&gt;이 여섯 가지 질문을 하나의 복도에 있는 여섯 개의 문이라고 생각해보자.&lt;/p&gt;
&lt;p&gt;&quot;우리는 왜 존재하는가&quot;는 가장 안쪽의 문이다. 돈을 버는 것 너머, 이 조직이 세상에 존재해야 하는 이유. 이 문이 닫혀 있으면 나머지 문들을 열어봐야 의미가 없다. &quot;우리는 어떻게 행동하는가&quot;는 문화의 문이다. &quot;혁신적이고 고객 중심적이며&quot;라는 범용 표현이 아니라, 경쟁사와 구별되는 우리만의 행동 방식. &quot;우리는 무엇을 하는가&quot;는 가장 단순해 보이지만 의외로 합의가 어려운 문이다. 조직이 하는 일을 한 문장으로 설명할 수 있는가. 부서마다 다른 설명을 하고 있지는 않은가.&lt;/p&gt;
&lt;p&gt;그런데 이 여섯 개의 문 중에서, 내 경험상 가장 격렬한 논쟁이 벌어지는 문이 있다. &quot;현재 가장 중요한 것은 무엇인가&quot;라는 집중의 문이다. 중요한 것은 항상 여러 개다. 그중 하나만 고르라는 것은 나머지를 포기하라는 것처럼 느껴진다. 채용도 중요하고 기술 부채도 중요하고 신규 기능도 중요하다. 하지만 모든 것이 중요하면, 아무것도 중요하지 않은 것과 같다. 앞서 다섯 명의 리더에게서 다섯 개의 답이 나왔던 것도 바로 이 문 앞에서였다.&lt;/p&gt;
&lt;p&gt;&quot;우리는 어떻게 성공할 것인가&quot;는 전략의 문이다. 같은 산업의 경쟁사들 사이에서, 우리가 의식적으로 선택한 차별화 포인트. 그리고 &quot;누가 무엇을 해야 하는가&quot;는 실행의 문이다. 앞의 다섯 가지 답이 아무리 명료해도, 구체적인 역할과 책임이 정해지지 않으면 아무 일도 일어나지 않는다.&lt;/p&gt;
&lt;p&gt;여섯 개의 문 중 하나라도 닫혀 있으면, 복도 전체가 어두워진다. 한 가지 질문에 대해서라도 리더들 사이에 생각의 차이가 존재하면, 그 불일치는 조직 전체의 명료함을 잠식한다.&lt;/p&gt;
&lt;h2&gt;왜 답하지 못하는가&lt;/h2&gt;
&lt;p&gt;이 질문들에 답하지 못하는 이유는 리더들의 능력이 부족해서가 아니다. 모든 리더십팀은 이 질문들에 답할 수 있을 만큼의 정보와 경험을 이미 가지고 있다. 문제는 다른 곳에 있다.&lt;/p&gt;
&lt;p&gt;첫째, 진짜 대화가 부족하다. 여섯 가지 질문에 답하려면, 리더들이 서로의 생각을 솔직하게 꺼내고 부딪힐 수 있어야 한다. 하지만 많은 리더십팀에서는 의견이 다를 때 &quot;서로 다른 의견을 갖기로 합의&quot;하고 넘어간다. 그것이 성숙한 태도라고 생각하면서. 그러나 이 &quot;합의된 불일치&quot;는 조직 아래로 내려갈수록 혼란이 되어 돌아온다. 한 리더가 &quot;속도&quot;를 강조하고 다른 리더가 &quot;품질&quot;을 강조하면, 그 아래의 구성원들은 어느 쪽을 따라야 할지 알 수 없다.&lt;/p&gt;
&lt;p&gt;둘째, 마케팅적 접근의 유혹이 있다. 이 질문들에 답할 때, 리더들은 쉽게 그럴듯한 문구를 만들려 한다. 외부에 보여주기 좋은 인상적인 한 줄. 하지만 이 질문들의 답은 마케팅 카피가 아니다. 리더 전원이 진심으로 동의하고, 일상의 의사결정에서 반복적으로 활용할 수 있는 명료한 합의여야 한다.&lt;/p&gt;
&lt;p&gt;셋째, 시간이 필요하다. 이 답들은 한 번의 워크숍으로 완성되지 않는다. 며칠이 아니라 몇 주간의 대화가 필요할 수 있다. 답이 나온 후에도 시간을 두고 다시 검토하며, 전원이 충분히 이해하고 동의하는지 확인해야 한다. 리더들은 바쁘다. 그래서 이 과정을 단축하려는 유혹에 빠진다. 하지만 합의의 깊이를 단축하면, 나중에 실행의 혼란으로 그 시간을 몇 배로 치르게 된다.&lt;/p&gt;
&lt;h2&gt;정확함보다 헌신&lt;/h2&gt;
&lt;p&gt;이 질문들에 대해 가장 흔한 오해가 있다. &quot;완벽한 답을 찾아야 한다&quot;는 생각이다.&lt;/p&gt;
&lt;p&gt;하지만 실제로는 다르다. 80%의 정확도를 가진 답에 리더 전원이 100% 헌신하는 것이, 100%의 정확도를 가진 답에 절반만 동의하는 것보다 훨씬 강력하다. 조직에서 실행력은 답의 완벽함이 아니라 합의의 깊이에서 나오기 때문이다. 모든 리더가 같은 메시지를 자기 팀에 전달하고, 같은 기준으로 의사결정을 하고, 같은 우선순위로 자원을 배분할 때 비로소 조직은 하나의 방향으로 움직인다.&lt;/p&gt;
&lt;p&gt;완벽한 전략을 세우는 데 석 달을 쓰고도 리더들 사이에 해석의 차이가 남아 있다면, 그 전략은 이미 실패한 것이다. 반대로, 다소 거칠더라도 리더 전원이 &quot;이것이 지금 우리의 답&quot;이라고 같은 목소리를 낼 수 있다면, 조직은 놀라울 만큼 빠르게 정렬된다.&lt;/p&gt;
&lt;p&gt;이것은 내가 직접 겪으면서 확인한 것이기도 하다. 우리 팀에서 이 질문들을 처음 다뤘을 때, 나는 완벽한 답을 만들려고 했다. 누구도 반박할 수 없는, 논리적으로 빈틈없는 답. 하지만 정작 중요한 것은 그 답이 얼마나 정교한가가 아니라, 모두가 그 답을 자기 것으로 받아들이는가였다. 회의실을 나서는 순간 &quot;글쎄, 나는 좀 다르게 생각하는데&quot;라고 속으로 중얼거리는 사람이 한 명이라도 있다면, 그 합의는 합의가 아니다.&lt;/p&gt;
&lt;h2&gt;액자를 바꿀 것인가, 대화를 바꿀 것인가&lt;/h2&gt;
&lt;p&gt;많은 조직이 명료함의 부재를 느낄 때 가장 먼저 하는 일은, 새로운 미션 선언문을 만드는 것이다. 더 멋진 단어를 고르고, 더 세련된 문장을 다듬어서, 더 예쁜 액자에 넣는다. 하지만 로비의 액자를 아무리 바꿔도, 리더들의 대화가 바뀌지 않으면 조직의 명료함은 달라지지 않는다.&lt;/p&gt;
&lt;p&gt;필요한 것은 새로운 선언문이 아니라 새로운 대화다. 리더들이 같은 방에 앉아서, 불편하더라도 서로의 생각 차이를 드러내고, 그 차이를 좁혀가는 과정. 완벽한 한 문장보다, 리더 모두가 같은 말을 할 수 있는 상태가 훨씬 강력하다. 미션 선언문은 벽에 걸기 위한 것이지만, 진짜 명료함은 사람들의 머릿속에 새겨지는 것이다.&lt;/p&gt;
&lt;p&gt;그런데 여기서 한 가지 질문이 남는다. 리더들이 여섯 가지 질문에 합의했다고 하자. 같은 답을 말할 수 있는 상태가 되었다고 하자. 그 합의는 어떻게 유지되는가? 시간이 지나면 해석이 벌어지고, 상황이 바뀌면 우선순위가 흔들린다. 합의가 흐트러지는 순간을 누가, 어떻게 포착하는가? 명료함을 만드는 것만큼이나, 명료함을 지키는 것에도 용기가 필요하다. 동료에게 불편한 말을 건넬 수 있는 용기 말이다.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[불편한 말이 팀을 살린다]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-06-uncomfortable-truth/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-06-uncomfortable-truth/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;리더 미팅이 끝난 직후의 복도는 묘한 공기를 품는다. 회의실에서 꺼내지 못한 말들이 사람들의 발걸음 사이에 떠돈다. 어느 날, 한 리더가 지난주에 약속한 일을 끝내지 못한 채 미팅에 들어왔다. 참석한 리더 전원이 그 사실을 알고 있었다. 그러나 아무도 입을 열지 않았다. 시선이 자연스럽게 한 곳으로 향했다. 나였다. 결국 내가 그 이야기를 꺼냈고, 미팅이 끝난 뒤 몇몇이 다가와 말했다. &quot;말씀하시길 잘했어요. 저도 신경 쓰이긴 했거든요.&quot;&lt;/p&gt;
&lt;p&gt;그 말에 안도하기보다 질문이 남았다. 신경이 쓰였다면 왜 직접 이야기하지 않았을까. 이것은 그 리더의 소심함도, 나의 리더십도 아닌, 팀이 책임을 다루는 방식의 문제였다.&lt;/p&gt;
&lt;p&gt;앞선 챕터에서 여섯 가지 질문에 대해 리더 전원이 같은 답을 만들어내는 과정을 이야기했다. 명료함에 합의하는 것은 시작이다. 합의는 잉크가 마르는 순간부터 흐려지기 시작한다. 그것을 붙잡아두려면, 누군가 흐려짐을 발견한 순간 말을 건넬 수 있어야 한다. 문제는 그 &apos;누군가&apos;가 언제나 같은 사람이라는 데 있었다.&lt;/p&gt;
&lt;h2&gt;감독만 외치는 팀&lt;/h2&gt;
&lt;p&gt;축구 경기장에는 두 종류의 팀이 있다. 감독만 터치라인에서 소리를 지르는 팀과, 선수들끼리 서로 외치고 끌어당기는 팀이다. 감독은 경기장 바깥에 서 있다. 선수 열한 명의 움직임을 전부 볼 수 없고, 피치 위의 미세한 흐름까지 읽지 못한다. 상대 수비를 놓친 동료에게 &quot;뒤를 봐!&quot;라고 소리치는 것은 옆에서 함께 뛰는 선수만 할 수 있는 일이다.&lt;/p&gt;
&lt;p&gt;조직에서도 마찬가지다. 모든 지적이 한 사람 -- 대개 CEO나 CTO -- 에게 집중되면, 그 사람이 아무리 부지런해도 구조적으로 한계에 부딪힌다. 한 사람이 모든 리더의 약속 이행을 추적하고, 미달을 짚고, 개선을 요구하는 것은 물리적으로 불가능하다. 설령 가능하더라도 그것이 만드는 것은 &apos;동료 간의 약속&apos;이 아니라 &apos;상하 관계의 감시&apos;다. 감독 혼자 외치는 팀에서는 선수들이 감독의 눈치를 살피지, 서로의 플레이를 살피지 않는다.&lt;/p&gt;
&lt;p&gt;반대로 동료 리더들이 서로의 약속 이행을 확인하고, 미달이 보이면 직접 이야기하는 팀에서는 책임의 무게가 분산된다. 네 명의 동료가 함께 이야기하는 압박은 한 사람의 지적보다 훨씬 강력하면서도, 동시에 덜 위계적이다. 이것이 동료 간 상호 피드백이 가장 효과적인 책임 시스템이라고 생각하는 이유다.&lt;/p&gt;
&lt;h2&gt;침묵이 보호하는 것&lt;/h2&gt;
&lt;p&gt;그러나 대부분의 팀에서 이런 상호 피드백은 자연스럽게 일어나지 않는다. 세 가지 이유가 있다.&lt;/p&gt;
&lt;p&gt;첫째, 관계에 대한 두려움이다. 지적하면 관계가 틀어질 것 같다. 특히 리더들 사이에서 이 두려움은 강하다. 서로의 전문 영역을 존중하는 관계에서 무언가를 짚는다는 것은 상대의 역량 자체를 의심하는 것처럼 느껴진다.&lt;/p&gt;
&lt;p&gt;둘째, 역할에 대한 착각이다. &quot;그건 CEO가 할 일이지, 내가 할 일이 아니야.&quot; 이 생각에는 편안함이 있다. 불편한 역할을 윗사람에게 위임하면 나는 &apos;좋은 동료&apos;로 남을 수 있다. 그 결과 한 사람만 나쁜 역할을 떠안고, 나머지는 방관자가 된다.&lt;/p&gt;
&lt;p&gt;셋째, 가장 근본적인 문제는 지적과 갈등을 혼동하는 것이다. 동료에게 &quot;지난주에 약속한 건 어떻게 됐어?&quot;라고 묻는 것은 갈등이 아니다. 합의한 약속의 이행을 확인하는 것이다. 그러나 많은 사람들의 머릿속에서 이 질문은 갈등의 시작으로 분류된다.&lt;/p&gt;
&lt;p&gt;아이러니는 여기서 발생한다. 지적을 피하면 관계가 보존될 것 같지만, 실제로는 반대다. 회의실에서 하지 못한 말은 사라지지 않는다. 복도의 뒷담화가 되고, 슬랙 DM의 푸념이 된다. 문제는 쌓이고, 감정은 뒤틀린다. 침묵이 보호하는 것은 관계가 아니라 불편함을 피하려는 자기 자신이다.&lt;/p&gt;
&lt;h2&gt;개인의 용기에서 팀의 시스템으로&lt;/h2&gt;
&lt;p&gt;이 불편함을 &apos;용기&apos;에만 의존하면 지속되지 않는다. 용기 있는 한두 사람이 지적을 반복하다 지치면, 팀은 다시 침묵으로 돌아간다. 불편함을 시스템으로 만들어야 한다.&lt;/p&gt;
&lt;p&gt;내가 효과적이라고 느낀 방법은 의외로 단순했다. 리더들이 정기적으로 모여, 서로에게 딱 한 가지씩 이야기하는 시간을 갖는 것이다. &quot;당신이 팀에 더 기여하기 위해 한 가지 더 잘했으면 하는 것&quot;을 직접 말한다.&lt;/p&gt;
&lt;p&gt;처음 이 자리를 만들었을 때 분위기는 당연히 어색했다. 눈을 잘 마주치지 못했고, 누군가 입을 열기까지 긴 침묵이 흘렀다. 그런데 한 사람이 먼저 말을 꺼내자 흐름이 달라졌다. 첫 번째 피드백 뒤에 두 번째는 훨씬 쉬워지고, 세 번째부터는 공기 자체가 바뀌었다. 더 놀라운 것은 피드백을 받는 쪽의 반응이었다. 방어적이기보다 &quot;그게 그렇게 보였구나&quot;라며 고개를 끄덕이는 경우가 많았다.&lt;/p&gt;
&lt;p&gt;이 훈련의 본질은 피드백의 내용에 있지 않다. 서로의 행동에 대해 말하는 것이 &apos;정상적인 일&apos;이라는 경험을 만드는 데 있다. 한 번 이 경험을 하고 나면, 일상에서 동료에게 무언가를 이야기하는 문턱이 낮아진다. 완전히 편해지지는 않는다. 그러나 &quot;우리는 서로에게 이런 이야기를 하는 팀이다&quot;라는 기준이 생긴다. 기준이 세워지면, 침묵은 더 이상 예의가 아니라 회피가 된다.&lt;/p&gt;
&lt;p&gt;피드백은 근육과 같아서, 쓰지 않으면 약해진다. 일회성 이벤트가 아니라 반복 가능한 루틴이어야 하는 이유다.&lt;/p&gt;
&lt;h2&gt;연기 감지기를 설치하라&lt;/h2&gt;
&lt;p&gt;피드백을 해야 한다는 것은 이제 동의했다고 하자. 다음 질문은 &quot;무엇에 대해 피드백할 것인가&quot;다.&lt;/p&gt;
&lt;p&gt;분기 리뷰 자리에서 마주한 장면이 있다. 한 리더의 팀은 목표 매출을 달성했다. 숫자만 보면 나무랄 데가 없었다. 그런데 그 팀의 이직률은 조직 전체에서 가장 높았고, 다른 팀과의 협업 요청은 번번이 무산되었으며, 팀원들의 표정은 성과를 달성한 사람들의 것이 아니었다. 숫자는 &quot;수고했다&quot;고 말하라고 했지만, 눈에 보이는 것은 다른 이야기를 하고 있었다.&lt;/p&gt;
&lt;p&gt;이런 순간에 많은 조직이 침묵을 택한다. 숫자가 좋으니까. 측정 가능한 지표가 달성되었으니까. 우리는 측정할 수 있는 것에 끌린다. 매출, 완료 프로젝트 수, 스프린트 속도. 이런 지표는 명확하고, 논쟁의 여지가 적으며, 숫자가 나를 대신 말해준다.&lt;/p&gt;
&lt;p&gt;반면 행동은 모호하다. &quot;회의에서 다른 팀의 의견을 자주 끊는다&quot;, &quot;약속한 기한을 조용히 넘긴다&quot;, &quot;팀원들 앞에서는 동의하고 뒤에서는 다른 이야기를 한다.&quot; 이런 것들은 KPI에 잡히지 않는다. 측정할 수 없으니 피드백의 대상도 되지 않는다.&lt;/p&gt;
&lt;p&gt;건강검진을 떠올려 보면 이 문제가 선명해진다. 혈압, 혈당, 콜레스테롤 수치만 보고 &quot;건강합니다&quot;라고 말하는 의사가 있다. 수치를 본 뒤 생활습관까지 묻는 의사가 있다. 수면은 충분한지, 운동은 하는지, 스트레스는 어떻게 다루고 있는지. 수치가 정상이어도 생활습관이 나쁘면 &quot;지금은 괜찮지만, 이대로 가면 문제가 생깁니다&quot;라고 말하는 의사. 어느 쪽이 더 좋은 의사인지는 분명하다.&lt;/p&gt;
&lt;p&gt;조직에서 성과만 피드백하는 리더는 수치만 보는 의사와 같다. 숫자가 무너진 뒤에야 &quot;왜 이렇게 됐지?&quot;라고 묻는다. 그때는 이미 늦다.&lt;/p&gt;
&lt;p&gt;이것이 행동을 &apos;연기 감지기&apos;에 비유하는 이유다. 성과 지표는 화재 경보기다. 불이 나야 비로소 울린다. 행동은 연기 감지기다. 불이 나기 전, 연기가 피어오르는 단계에서 경고한다. 회의에 습관적으로 늦는 리더를 생각해보자. 5분, 10분. 대단한 문제는 아닌 것 같다. 그러나 이 행동이 반복되면 팀의 리듬이 깨진다. 다른 리더들도 시간을 덜 엄격하게 지키기 시작한다. 회의 시작이 매번 밀리고, 논의 시간이 줄어들고, 중요한 결정이 다음으로 미뤄진다. 몇 달 뒤 프로젝트가 지연되었을 때 원인을 추적하면, 뿌리는 훨씬 이전의 행동에 있었다.&lt;/p&gt;
&lt;p&gt;연기 감지기 없이 화재 경보기만 설치한 건물은, 겉으로는 안전해 보이지만 대응할 시간을 이미 잃은 건물이다. 행동을 피드백하지 않는 조직도 마찬가지다.&lt;/p&gt;
&lt;h2&gt;판단이 아닌 장면으로 말하기&lt;/h2&gt;
&lt;p&gt;행동을 이야기해야 한다는 것까지는 동의했다. 남은 문제는 &apos;어떻게&apos;다.&lt;/p&gt;
&lt;p&gt;&quot;당신의 태도가 문제입니다.&quot;&lt;/p&gt;
&lt;p&gt;이것은 피드백이 아니라 판단이다. 이 말을 들으면 누구든 방어적이 된다. 행동 피드백이 사람에 대한 공격으로 느껴지는 이유는, 대부분의 행동 피드백이 실제로 판단의 형태를 띠기 때문이다.&lt;/p&gt;
&lt;p&gt;구체적인 장면, 그 행동이 만든 영향, 그리고 기대하는 변화. 이 세 가지가 갖춰지면 피드백은 공격이 아니라 대화가 된다.&lt;/p&gt;
&lt;p&gt;&quot;지난 수요일 기획 회의에서, 마케팅팀이 제안을 설명하는 중간에 두 번 말을 끊으셨어요. 그 뒤로 마케팅팀 쪽에서 발언이 거의 없었고, 결론이 한쪽으로만 기울어진 채 끝났습니다. 다음 회의에서는 상대 팀이 설명을 마칠 때까지 기다려주시면, 더 균형 잡힌 논의가 될 것 같습니다.&quot;&lt;/p&gt;
&lt;p&gt;같은 문제를 이야기하지만, 받아들이는 사람의 경험은 전혀 다르다. 앞의 말은 사람을 재단하고, 뒤의 말은 장면을 묘사한다. 장면에서 출발하면 상대가 자기 행동을 객관적으로 돌아볼 여지가 생긴다.&lt;/p&gt;
&lt;p&gt;이 구조를 안다고 해서 곧바로 쉬워지지는 않는다. 여전히 불편하다. 그러나 적어도 &quot;어떻게 말해야 할지 모르겠다&quot;는 핑계는 사라진다. 구조가 있으면 용기의 문턱이 낮아진다.&lt;/p&gt;
&lt;h2&gt;기대라는 이름의 신뢰&lt;/h2&gt;
&lt;p&gt;불편한 말을 건네는 것의 본질을 다시 들여다보면, 거기에는 기대가 있다. 동료에게 &quot;지난번 미팅에서 약속한 자료가 아직 안 나왔다&quot;고 말하는 것은 그 사람이 더 잘할 수 있다고 믿기 때문이다. 기대가 없는 관계에서는 불편한 대화가 필요 없다. 그냥 거리를 두면 된다. 포기한 관계에서는 침묵이 가장 효율적이다.&lt;/p&gt;
&lt;p&gt;그래서 불편한 말을 건네는 것은 사실 이런 뜻이다. &quot;나는 당신이 더 나아질 수 있다고 믿는다. 그리고 이 팀이 함께 더 좋아질 수 있다고 믿는다.&quot; 불편한 피드백이 신뢰의 부재가 아니라 신뢰의 증거라는 것을 팀 전체가 이해하면, 피드백의 의미가 달라진다. 지적이 아니라 기대의 표현이 된다.&lt;/p&gt;
&lt;p&gt;물론 전제가 있다. 진심이어야 한다. 자기 불편함을 해소하기 위한 지적, 우위를 점하기 위한 지적은 기대가 아니라 공격이다. &quot;이 말을 하는 이유가 이 사람과 이 팀을 위한 것인가&quot;라는 질문에 솔직하게 답할 수 있어야 한다.&lt;/p&gt;
&lt;p&gt;동료에게 마지막으로 불편한 말을 건넨 것은 언제인가. 기억이 나지 않는다면, 지금 당신의 팀에서 책임은 과연 누구의 몫인가. 그리고 그 책임을 함께 나눈다는 것은 결국, 팀 안에서 사람들이 공정하게 대우받고 있다는 감각과 맞닿아 있다. 피드백의 &apos;무엇&apos;과 &apos;어떻게&apos;를 넘어, 그 바탕이 되는 공정함의 뿌리는 어디에 있는 것일까.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[공정함은 과정에서 온다]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-07-fairness-in-process/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-07-fairness-in-process/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;어떤 말을 해야 하는지 아는 것과, 그 말이 상대에게 닿게 하는 것은 전혀 다른 문제다. 피드백의 내용이 아무리 정확해도, 그것이 전달되는 방식과 그 밑에 깔린 구조가 신뢰를 받지 못하면 아무것도 바뀌지 않는다. 팀원이 피드백을 수용하려면, 먼저 이 조직이 나를 공정하게 대한다는 감각이 있어야 한다. 그 감각은 어디에서 오는 걸까.&lt;/p&gt;
&lt;h2&gt;연봉 협상이 끝난 뒤&lt;/h2&gt;
&lt;p&gt;연봉 협상이 끝나면 사람들은 곧장 옆자리 동료에게 눈짓을 보낸다. 직접 묻지는 않는다. 대신 표정을 읽는다. 그 미세한 시선의 교환 속에서 자기 위치를 가늠한다.&lt;/p&gt;
&lt;p&gt;흥미로운 점은, 그렇게 가늠하는 대상이 금액이 아니라 과정이라는 사실이다. 숫자는 의외로 빨리 잊힌다. 하지만 그때 들었던 — 혹은 듣지 못했던 — 말은 오래 남는다. &quot;이번에 이 정도로 결정됐어.&quot; 그 한마디가 전부였던 순간. 왜 그 숫자인지, 어떤 기준을 적용했는지, 내 성과가 어떻게 반영되었는지에 대한 설명이 아무것도 없었던 그 순간이 수년이 지나도 선명하다.&lt;/p&gt;
&lt;p&gt;돌이켜보면, 조직에서 가장 불편했던 순간은 결과가 나빴을 때가 아니었다. 결정이 내려진 뒤에야 알게 되었을 때였다. 내가 알 수 없는 어딘가에서 이미 모든 것이 정해져 있었다는 걸 깨달았을 때, 과정 자체에서 내가 존재하지 않았다는 사실이 결과보다 더 깊은 상처를 남겼다.&lt;/p&gt;
&lt;p&gt;반대의 경험도 있다. 결과가 기대에 미치지 못했는데도 괜찮았던 적이 있다. 왜 이런 결정이 내려졌는지 설명을 들었을 때. 내 의견이 반영되지 않더라도, 적어도 고려는 되었다는 것을 느꼈을 때. 그때는 결과를 받아들일 수 있었다.&lt;/p&gt;
&lt;h2&gt;사람은 과정의 공정함에 더 예민하다&lt;/h2&gt;
&lt;p&gt;예일대의 톰 타일러는 이 현상을 &apos;절차공정성&apos;이라 불렀다. 사람들은 결과의 크기보다 그 결과에 이르는 과정이 공정했는지를 더 예민하게 감지한다는 것이다. 조직이 공정하려는 자세를 보이는지, 정직한지, 기회가 주어지는지, 결정의 질적 수준은 어떤지, 오류를 바로잡을 수 있는지, 편향이 없는지. 하나하나가 거창한 제도가 아니다. 결국 핵심은 단순하다. &quot;당신은 이 결정에서 투명인간이 아닙니다&quot;라는 메시지를 조직이 보내느냐의 문제다.&lt;/p&gt;
&lt;p&gt;작은 팀이라고 해서 이것이 자동으로 해결되지는 않는다. 오히려 반대인 경우가 많다. 인원이 적으니 빠르게 결정해야 한다는 명분 아래 과정이 생략된다. 창업자의 직관이 곧 결정이 되고, 그 결정은 메시지 한 줄로 전달된다. 빠르다. 효율적이다. 하지만 거기에는 과정이 없다.&lt;/p&gt;
&lt;p&gt;타운홀 미팅이 존재하는 이유가 여기에 있다. 임원들끼리 정하고 공지하면 끝날 일을 시시콜콜 설명하고 의견을 듣는 것은 비효율적으로 보인다. 하지만 그 비효율이 신뢰를 만든다. 신뢰는 감정이 아니라 구조에 가깝다. 감정은 흔들리지만 구조는 버틴다. 좋은 리더는 매력적인 사람이 아니라, 신뢰할 수 있는 구조를 설계하는 사람이다.&lt;/p&gt;
&lt;p&gt;리더로서 결정을 내리기 전에 한 번 더 생각하는 습관이 생겼다. 이 결정을 공유하지 않아도 될 사람이 정말 없는지. 경험상, 그 범위는 내가 생각한 것보다 항상 넓다. 공정함은 정답을 찾는 문제가 아니라, 과정을 열어두려는 태도에서 시작된다.&lt;/p&gt;
&lt;h2&gt;장면이 명령을 이긴다&lt;/h2&gt;
&lt;p&gt;공정한 과정이라는 토대가 깔리면, 그 위에서 사람을 움직이는 방식도 달라져야 한다. 피드백이든, 가이드라인이든, 방향 제시든 — 핵심은 명령이 아니라 장면을 보여주는 것이다.&lt;/p&gt;
&lt;p&gt;아이에게 &quot;장난감 치워&quot;라고 말하면 십중팔구 꿈쩍도 하지 않는다. 하지만 장난감 하나를 집어 들고 &quot;이건 어디에 두면 돼?&quot;라고 물으면, 아이가 직접 와서 알려준다. &quot;이건 여기, 이건 저기.&quot; 어느새 스스로 치우고 있다. 아무도 치우라고 명령하지 않았는데.&lt;/p&gt;
&lt;p&gt;명령은 외부 동기를 만든다. 보상이 있으니까, 혼나기 싫으니까, 그냥 시키니까 하는 것. 이런 동기는 빠르게 작동하지만 감시가 사라지면 행동도 사라진다. 반면 장면은 내부 동기를 만든다. 스스로 판단하고, 자기 문제라고 느끼고, 선택했기 때문에 하는 것. 이 동기는 느리게 시작하지만 훨씬 오래 지속된다.&lt;/p&gt;
&lt;p&gt;코드 리뷰에서 이 차이가 극명하게 드러난다. &quot;이 코드는 좋지 않습니다. 수정해주세요&quot;라는 코멘트를 받으면 방어적이 된다. 하지만 &quot;이 함수가 호출되는 시점에 connection pool이 소진된 상태라면 어떻게 될까요?&quot;라는 코멘트를 받으면 생각하게 된다. 전자는 명령이고 후자는 장면이다. 후자는 상대의 머릿속에 특정 시나리오를 그려주고, 스스로 문제를 발견하게 만든다.&lt;/p&gt;
&lt;p&gt;추상적인 지시도 마찬가지다. &quot;코드 품질을 높여주세요&quot;라고 말하면 듣는 사람의 머릿속에 아무런 그림도 떠오르지 않는다. 하지만 &quot;지난주 결제 모듈 PR에서 에러 핸들링이 빠진 부분이 세 곳 있었어요&quot;라고 말하면 구체적인 장면이 떠오르고, 무엇을 해야 하는지 선명해진다. 고유명사가 가진 힘이다. 이름, 날짜, 장소, 상황 — 이런 구체성이 머릿속에 장면을 그리고, 장면이 그려지면 행동이 따라온다.&lt;/p&gt;
&lt;p&gt;실수를 다루는 방식에서도 장면의 원리는 작동한다. &quot;테스트 코드를 꼭 작성하세요&quot;라고 열 번 말하는 것보다, 안전한 범위 안에서 테스트 없이 배포했다가 장애를 경험하게 하는 것이 더 효과적이다. 다만 중요한 건, 실수 후에 &quot;그것 봐, 내가 뭐라고 했어&quot;라고 말하지 않는 것이다. 체험 직후에 필요한 것은 지적이 아니라 질문이다. &quot;어떻게 된 것 같아?&quot; &quot;다음에는 어떻게 하면 좋을까?&quot; 결론을 내 입으로 말하는 순간, 그것은 상대의 깨달음이 아니라 나의 잔소리가 된다.&lt;/p&gt;
&lt;h2&gt;존재감이 사라지는 것이 최고의 성과&lt;/h2&gt;
&lt;p&gt;명령하는 매니저는 팀이 자기 없이 움직이지 못하게 만든다. 모든 결정이 매니저를 거쳐야 하고, 모든 판단에 승인이 필요하다. 매니저의 존재감은 높아지지만 팀의 자율성은 죽는다. 장면을 만드는 매니저는 다르다. 결정을 내려주는 대신 결정에 필요한 맥락을 보여주고, 답을 알려주는 대신 답에 이르는 질문을 던진다.&lt;/p&gt;
&lt;p&gt;공정한 과정이라는 토대 위에서, 장면이라는 도구를 사용하면 팀은 자율적으로 움직이기 시작한다. 명령은 순간의 행동을 만들지만, 장면은 지속적인 판단력을 만든다. 답을 줄수록 의존이 생기고, 장면을 줄수록 자율이 생긴다. 그래서 가장 좋은 매니저는, 역설적이게도, 팀이 자기 없이도 잘 돌아가게 만드는 사람이다.&lt;/p&gt;
&lt;p&gt;사람을 다루는 기술 — 채용, 리더십, 명료함, 피드백, 공정함 — 을 이야기해왔다. 하지만 조직은 사람만으로 작동하지 않는다. 사람 사이에 일이 있고, 그 일에는 구조가 필요하다. 무엇을 할 것인가와 어떻게 할 것인가를 분리하는 기술, 그리고 빠르게 판단하는 직관을 키우는 훈련. 사람을 넘어 일의 구조로, 이야기를 이어가 보자.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[What과 How 사이에서]]></title><description><![CDATA[스프린트가 끝났다. 개발자들에게 할 일이 없다. 기획은 아직 나오지 않았고, 디자인은 리뷰 중이다. 백로그에는 "추후 논의"라는 딱지가 붙은 티켓들만 쌓여 있다. 이상한 일이었다. 팀의 실행 속도는 분명히 빨라졌다. 예전에…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-08-what-and-how/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-08-what-and-how/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;스프린트가 끝났다. 개발자들에게 할 일이 없다.&lt;/p&gt;
&lt;p&gt;기획은 아직 나오지 않았고, 디자인은 리뷰 중이다. 백로그에는 &quot;추후 논의&quot;라는 딱지가 붙은 티켓들만 쌓여 있다. 이상한 일이었다. 팀의 실행 속도는 분명히 빨라졌다. 예전에 2주가 걸리던 기능을 며칠 만에 끝낸다. 그런데 팀 전체의 체감 속도는 오히려 느려졌다. 엔지니어들은 손이 비고, PM과 디자이너는 숨이 가쁘다. 실행이 빨라졌는데 팀이 느려지는 이 역설은 대체 어디에서 오는 걸까.&lt;/p&gt;
&lt;p&gt;앞선 챕터들에서 사람을 다루는 기술 — 공정함, 피드백, 장면을 보여주는 매니지먼트 — 을 이야기했다. 사람 사이의 신뢰가 확보되었다면, 이제 질문은 자연스럽게 &quot;일&quot;로 옮겨간다. 이 팀이 무엇을, 어떤 구조로 할 것인가. 이 챕터는 그 질문에 대한 탐색이다.&lt;/p&gt;
&lt;h2&gt;How가 공짜가 되어가는 세상&lt;/h2&gt;
&lt;p&gt;지난 몇 년간 &quot;만드는 비용&quot;은 극적으로 줄었다. AI 코딩 도구, 자동화 파이프라인, 코드 생성기. 과거에 시니어 개발자 두 명이 2주를 매달려야 했던 기능을, 이제는 주니어 한 명이 3일이면 구현한다. 과장이 아니다. 실제로 수많은 팀에서 벌어지고 있는 현실이다.&lt;/p&gt;
&lt;p&gt;How — 어떻게 만들 것인가 — 의 비용이 빠르게 0에 수렴하고 있다. 구현은 점점 쉬워지고, 같은 결과물을 내는 데 필요한 사람과 시간은 줄어든다. 기술의 진보다. 분명히 축하할 일이다.&lt;/p&gt;
&lt;p&gt;그런데 한 가지 비용은 전혀 줄지 않았다. What — 무엇을 만들 것인가 — 를 결정하는 비용이다. 어떤 문제를 풀어야 하는지 파악하고, 아이디어를 구체화하고, 방향을 설정하는 데 걸리는 시간과 에너지는 여전히 그대로다. 오히려 선택지가 늘어나면서 의사결정의 무게는 더 커졌다.&lt;/p&gt;
&lt;p&gt;How는 점점 싸지는데, What은 여전히 비싸다. 이 비대칭에서 역설이 시작된다.&lt;/p&gt;
&lt;p&gt;개발자의 생산성이 높아지면 팀이 더 많은 것을 만들어야 정상이다. 하지만 현실은 그렇지 않다. 엔지니어들의 손이 빈다. 게으른 것이 아니다. 실행할 거리가 없는 것이다. What이 공급되는 속도보다 How가 소화하는 속도가 압도적으로 빨라졌기 때문이다. PM과 디자이너가 기획하고 검증하는 속도 자체가 병목이 되어버렸다.&lt;/p&gt;
&lt;p&gt;이때 기업에게는 두 가지 선택지가 놓인다.&lt;/p&gt;
&lt;p&gt;첫째, 병목 포지션을 충원한다. PM이나 디자이너를 더 뽑아서 What의 처리량을 늘린다.&lt;/p&gt;
&lt;p&gt;둘째, 개발자를 줄인다. How의 처리량을 What의 공급 속도에 맞춘다.&lt;/p&gt;
&lt;p&gt;논리적으로는 첫 번째가 맞다. 그러나 현실에서 두 번째가 압도적으로 쉽다. 적합한 PM이나 디자이너를 찾는 것은 정말 어려운 일이다. 비용의 문제가 아니라, 우리 제품과 시장을 깊이 이해하면서 동시에 문제 정의 능력을 갖춘 사람을 찾는 것 자체가 난제다. 반면 개발자를 줄이는 것은 숫자 계산만으로 결정할 수 있다.&lt;/p&gt;
&lt;p&gt;그래서 많은 기업이 구조조정을 택한다. 실행력이 높아질수록, 실행하는 사람의 자리가 위태로워지는 역설. 빨라진 실행이 느려진 팀을 만들고, 느려진 팀이 더 적은 사람을 요구한다. 지난 몇 년간 테크 업계를 뒤흔든 대규모 구조조정의 이면에는 이 구조적 원인이 자리하고 있다.&lt;/p&gt;
&lt;p&gt;How만 잘하는 사람은 대체 가능해진다. 이 문장이 불편할 수 있다. 하지만 외면해서는 안 되는 현실이다.&lt;/p&gt;
&lt;h2&gt;What에 참여하는 엔지니어&lt;/h2&gt;
&lt;p&gt;그렇다면 이 역설을 어떻게 깨뜨릴 수 있을까. 핵심은 What을 PM과 디자이너만의 영역으로 두지 않는 데 있다. 문제 파악, 아이디에이션, 방향 설정 — 이 과정에 엔지니어를 포함한 팀 전체가 참여해야 한다.&lt;/p&gt;
&lt;p&gt;볼타에서는 세 가지 방식으로 이를 실천했다.&lt;/p&gt;
&lt;p&gt;첫째, 고객 문의를 함께 본다. 고객이 어떤 문제로 문의를 넣는지, 어떤 기능을 예상과 다르게 사용하는지를 엔지니어가 직접 확인한다. 예컨대 단순 알림용으로 설계한 웹훅을 고객이 자체 자동화 파이프라인의 핵심 트리거로 활용하고 있다면 — 그것은 엔지니어가 가장 먼저, 가장 정확하게 포착할 수 있는 종류의 신호다. 코드를 만든 사람이 코드의 예상 밖 쓰임새를 가장 잘 읽는다.&lt;/p&gt;
&lt;p&gt;둘째, 벤치마크 세션을 함께 한다. 경쟁사 분석, 시장 리서치를 PM만의 업무로 두지 않는다. 팀 전체가 주기적으로 시장을 함께 들여다본다. 엔지니어의 관점에서 보이는 기술적 가능성이 전혀 다른 아이디어를 촉발하기도 한다.&lt;/p&gt;
&lt;p&gt;셋째, 프로토타이핑으로 아이디에이션에 기여한다. 피그마 목업을 기다리는 대신, 실제로 동작하는 프로토타입을 빠르게 만들어서 팀의 논의를 앞당긴다. How가 저렴해진 세상에서 프로토타입의 비용은 거의 0이다. 이미 구현 능력을 가진 사람이 아이디어 단계에서부터 손을 움직이면, 논의의 속도와 깊이가 완전히 달라진다.&lt;/p&gt;
&lt;p&gt;이것은 엔지니어에게 위협이 아니라 기회다. 과거에는 구현에 모든 시간을 쏟느라 기획에 참여할 여유가 없었다. 지금은 실행 시간이 줄어든 만큼 What에 참여할 시간이 생겼다. 줄어든 시간을 어떻게 쓸 것인가가 개인의 가치를 결정한다.&lt;/p&gt;
&lt;h2&gt;1/3 법칙: What과 How를 교차하는 운영 구조&lt;/h2&gt;
&lt;p&gt;What에 참여하는 것만으로는 부족하다. 운영 구조 자체가 바뀌어야 한다.&lt;/p&gt;
&lt;p&gt;가장 흔한 실수는 같은 문제에 대한 What과 How를 하나의 스프린트 안에서 동시에 진행하는 것이다. 이번 스프린트에 문제를 파악하면서, 동시에 그 해결책을 구현하려 한다. 이러면 반드시 블로킹이 생긴다. What이 늦어지면 How가 멈추고, How가 멈추면 엔지니어가 다시 손이 빈다. 앞에서 이야기한 역설이 스프린트 단위로 반복되는 것이다.&lt;/p&gt;
&lt;p&gt;더 큰 문제는 리스크다. What 단계에서 방향이 틀어지면, 같은 스프린트에서 이미 진행 중이던 How 작업이 통째로 소실된다. 스프린트의 상당 부분을 한순간에 잃는 셈이다.&lt;/p&gt;
&lt;p&gt;해법은 교차 운영이다. 이를 &quot;1/3 법칙&quot;이라 부른다.&lt;/p&gt;
&lt;p&gt;스프린트의 1/3은 미래의 What에 투자한다. 아직 정의되지 않은 문제를 파악하고, 싱크하고, 아이디에이션한다. 나머지 2/3는 이미 정의된 What의 How를 실행한다. 지난 스프린트에서 충분히 검증해둔 것들을 만드는 데 집중한다.&lt;/p&gt;
&lt;p&gt;흐름은 이렇다.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;S1&lt;/strong&gt;: 문제 A 파악 + 아이디에이션&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;S2&lt;/strong&gt;: 문제 A 실행 + 문제 B 파악&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;S3&lt;/strong&gt;: 문제 B 실행 + 문제 C 파악&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;이 구조의 핵심은 손실의 격리에 있다. S1에서 문제 A의 방향이 잡히지 않더라도, S1에서 실행하고 있는 것은 이전 스프린트에서 이미 검증된 다른 문제의 How다. What이 실패해도 How의 리소스가 날아가지 않는다. 반대로 How가 예상보다 빨리 끝나면, 미리 진행 중이던 What 작업 덕분에 다음 실행으로 곧바로 넘어갈 수 있다.&lt;/p&gt;
&lt;p&gt;교차 운영에는 약간의 리드 타임이 필요하다. 다음 달 초에 실행할 것의 What을 이번 달부터 시작해야 한다. 하지만 이 선행 투자가 팀 전체의 블로킹을 제거한다. 엔지니어가 손이 비는 순간이 사라지고, PM과 디자이너에게 집중되던 병목이 완화된다.&lt;/p&gt;
&lt;h2&gt;직관을 훈련하는 팀&lt;/h2&gt;
&lt;p&gt;What을 잘하려면 직관이 필요하다. 고객의 문의 한 줄을 읽었을 때 &quot;같은 문제를 겪고 있을 다른 고객사가 어디인지&quot; 바로 떠올릴 수 있는 수준. 별도의 리서치 없이도 &quot;이건 진짜 문제일 수 있겠다&quot;라는 판단이 서는 수준.&lt;/p&gt;
&lt;p&gt;이것은 타고나는 능력이 아니다. 훈련으로 만들어진다.&lt;/p&gt;
&lt;p&gt;볼타에서는 네 가지 방식으로 직관을 훈련한다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;외부 고객에 대한 이해.&lt;/strong&gt; 우리 고객이 어떤 비즈니스를 하고, 어떻게 수익을 만들고, 어떤 고민을 안고 있는지를 아는 것이다. 경조사, 신규 사업, 채용, 구조조정까지. 고객의 맥락을 깊이 알수록 문의 한 줄에서 읽어내는 것의 깊이가 달라진다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;내부 고객 — 팀원 — 에 대한 이해.&lt;/strong&gt; 같은 팀의 구성원이 어떤 강점을 가지고 있고, 어떤 영역에 도전하고 싶어하는지를 아는 것이다. 새로운 문제가 포착되었을 때 누구에게 맡길지, 어떻게 나눌지 판단하는 것도 직관이다. 사람에 대한 이해 없이는 문제를 정의해도 실행으로 연결되지 않는다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;시장에 대한 이해.&lt;/strong&gt; 경쟁사, 법령, 글로벌 트렌드. 이 맥락이 없으면 어떤 문제가 풀 만한 가치가 있는 문제인지 판단할 수 없다. 경쟁사의 과거 시행착오도 귀중한 학습 자료다. 현재의 UX나 기능을 참고하는 것이 아니라, 그들이 왜 그 선택을 했고 어디에서 어려움을 겪었는지를 읽는 것이다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;예상치 못한 사용의 관찰.&lt;/strong&gt; 우리가 A를 위해 만든 기능을 고객이 B에 쓰고 있다면, 거기에 의외의 기회가 숨어 있다. 이런 신호는 제품을 만든 사람이 가장 먼저 감지할 수 있다. 코드를 작성한 사람만이 설계 의도와 실제 사용 사이의 간극을 정확히 이해하기 때문이다.&lt;/p&gt;
&lt;p&gt;데이터를 경시하자는 이야기가 아니다. 데이터 분석은 어느 정도 규모의 팀이라면 누구나 할 수 있다. 좋은 도구가 많아졌고 방법론도 표준화되었다. 하지만 실무에서 마주하는 대부분의 상황에는 참고할 만한 정량적 데이터가 없다. 새로운 시장에 진출할 때, 경쟁사가 예상 밖의 움직임을 보일 때, 과거 데이터는 별로 도움이 되지 않는다. 데이터 없는 상황에서 판단할 수 있는 것은 오직 훈련된 직관뿐이다. 직관으로 빠르게 가설을 세우고, 데이터로 검증하며, 그 경험이 다시 직관을 더 예리하게 만드는 선순환. 그것이 What을 잘하는 팀의 기반이다.&lt;/p&gt;
&lt;p&gt;&quot;신입 PM은 없다&quot;는 표현이 있다. 직관이 쌓이는 데 시간이 걸리기 때문이다. PM이라는 직군이 아무나 할 수 없다는 뜻이 아니다. 고객과 시장과 제품에 대한 깊은 이해를 기반으로 한 직관은 하루아침에 생기지 않는다는 뜻이다. 그리고 이 말은 PM에게만 해당되지 않는다. What에 참여하려는 모든 사람 — 엔지니어든 디자이너든 — 에게 똑같이 적용된다.&lt;/p&gt;
&lt;p&gt;직관이 충분히 훈련된 팀은 탑다운으로 사고한다. &quot;이 기능을 만들면 나아지겠지?&quot;라는 바텀업이 아니라, &quot;목표를 달성하려면 어떤 문제를 풀어야 하는가?&quot;에서 출발한다. 목표에서 역산하되, How가 아닌 What과 Why에 먼저 집중한다. 실행 방법은 그다음이다. 올바른 문제를 정의하는 것이 올바른 해결책을 구현하는 것보다 언제나 앞선다.&lt;/p&gt;
&lt;h2&gt;더 잘 정의하는 팀&lt;/h2&gt;
&lt;p&gt;How가 공짜가 되어가는 흐름은 되돌릴 수 없다. 실행 비용은 앞으로도 계속 줄어들 것이고, 같은 일을 하는 데 필요한 사람은 점점 적어질 것이다.&lt;/p&gt;
&lt;p&gt;이때 살아남는 팀은 &quot;더 빨리 만드는 팀&quot;이 아니라 &quot;더 잘 정의하는 팀&quot;이다. 잘 정의하는 것은 특정 직군 한두 명의 역할이 아니라, 제품팀 전체의 역량이다. 그리고 그 역량은 개인의 직관 훈련과 팀의 운영 구조가 함께 뒷받침할 때 비로소 작동한다.&lt;/p&gt;
&lt;p&gt;줄어든 실행 시간을 위협으로 볼 수도 있고, 기회로 볼 수도 있다. 그 시간을 What에 참여하는 데 쓴다면, 이것은 모든 구성원에게 더 넓은 영역에서 기여할 수 있는 기회가 된다. 1/3 법칙으로 구조를 잡고, 직관을 훈련하여 문제 정의의 깊이를 높이고, 팀 전체가 What에 참여하는 문화를 만든다. 그것이 빨라진 실행 시대에 작은 팀이 택할 수 있는 가장 현명한 전략이다.&lt;/p&gt;
&lt;p&gt;일의 구조를 세웠다면, 그 안에서 뛰는 사람은 괜찮은 걸까. 빠르게 돌아가는 스프린트, 촘촘한 실행 주기, 끊임없는 문제 정의. 이 리듬 속에서 개인이 지치지 않으려면 무엇이 필요한가. 구조가 아무리 좋아도, 그 안의 사람이 무너지면 아무 소용이 없다.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[번아웃과 성과의 관계]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-09-burnout-and-performance/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-09-burnout-and-performance/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;일하다 보면 한 번쯤 듣게 되는 말이 있다. &quot;천천히 하세요, 그러다가 번아웃 와요.&quot; 야근하는 동료에게 건네는 이 말은 선의에서 비롯되었을 것이다. 하지만 이 충고에는 묘한 전제가 숨어 있다. 번아웃의 원인이 과로라는 전제다.&lt;/p&gt;
&lt;p&gt;정말 그럴까. 앞 챕터에서 우리는 일의 구조를 이야기했다. What과 How를 분리하고, 직관을 훈련하며, 모든 구성원이 문제 정의에 참여하는 팀의 모습을 그렸다. 그런데 구조가 아무리 정교해도, 그 안에서 일하는 개인이 소진되면 구조는 껍데기가 된다. 팀의 운영 체계를 논하는 2막의 마지막에, 개인의 에너지 문제를 다뤄야 하는 이유가 여기에 있다.&lt;/p&gt;
&lt;h2&gt;번아웃은 과로가 아니라 헛달림이다&lt;/h2&gt;
&lt;p&gt;번아웃의 진짜 원인은 과로가 아니다. 열심히 달려가는데 결실이 보이지 않는 상태, 즉 성과의 부재다. 사람은 의외로 바쁜 것 자체에는 잘 견딘다. 마감에 쫓기면서도 눈앞에서 결과물이 만들어지고 있다는 감각이 있으면, 피로는 피로로만 남는다. 하지만 매일 야근하면서도 프로젝트가 표류하거나, 내가 만든 것이 어디에도 쓰이지 않는다는 느낌이 쌓이면, 같은 업무량이라도 에너지는 급격히 고갈된다.&lt;/p&gt;
&lt;p&gt;오히려 조직이 뜨겁게 달리고 있을 때가 건강한 상태일 수 있다. 갑작스럽게 찾아오는 여유와 고요함이 불안을 만들어내는 경험을 해본 사람이라면 이 감각을 알 것이다. 열심히 스프린트를 돌다가 갑자기 할 일이 사라진 순간, 해방감보다 먼저 찾아오는 것은 &quot;이게 맞나?&quot;라는 불안이다. 그래서 번아웃의 해법은 쉬는 것이 아니다. 물론 휴식은 필요하다. 다만 휴식만으로는 근본 원인이 해소되지 않는다. 필요한 것은 자신이 기여하고 있다는 실감, 즉 성과다.&lt;/p&gt;
&lt;p&gt;여기서 한 가지 짚어야 할 것이 있다. 상대방의 맥락을 모른 채 자기 경험에 비추어 건네는 조언의 위험이다. &quot;그러다가 번아웃 와요&quot;, &quot;제가 해보니까 건강이 최고예요&quot; 같은 말은, 지금 달리고 있는 사람에게 달리지 말라고 말하는 것과 다르지 않다. 사람마다 성과를 내는 방식이 다르고, 시기에 따라 주어지는 기회는 한정적이다. 그때 해볼 수 있는 것은 그때 해봐야만 한다. 그것도 자신이 충분히 만족할 만큼.&lt;/p&gt;
&lt;h2&gt;능력 범위라는 울타리&lt;/h2&gt;
&lt;p&gt;그렇다면 성과를 내려면 어디서부터 시작해야 하는가. 답은 자신의 능력 범위를 정확히 아는 것이다.&lt;/p&gt;
&lt;p&gt;능력 범위란 시간이 지나면서 축적한 지식과 전문성의 영역을 말한다. 누구에게나 자신이 깊이 이해하는 영역과 그렇지 못한 영역이 있다. 핵심은 그 경계를 인식하고, 경계 안에서 먼저 단단해지는 것이다. 세 가지 질문으로 시작할 수 있다. 내 직무의 책임과 역할은 무엇인가. 내가 잘하는 것은 무엇인가. 내가 아는 것과 모르는 것의 경계가 어디인가.&lt;/p&gt;
&lt;p&gt;이 질문에 답할 수 있는 사람은 몇 가지 이점을 갖게 된다. 진정으로 이해하는 영역에 집중하니 성공 확률이 높아진다. 자기 판단에 확신이 생기니 의사결정이 빨라진다. 이해하지 못하는 것에 무리하게 뛰어들지 않으니 예측 불가능한 위험이 줄어든다. 그리고 기본 이해가 탄탄한 사람은 인접 영역으로의 확장도 더 빠르다. 결국 능력 범위 안에서 단단해지는 것이 확장의 전제 조건이 된다.&lt;/p&gt;
&lt;p&gt;엔지니어 조직에서 이 경계 밖으로 뛰어나가려는 충동은 흔하다. 새로운 기술 스택, 새로운 역할, 새로운 도메인. 놓치면 뒤처질 것 같은 불안, 이른바 FOMO가 능력 범위 바깥으로 성급하게 발을 내딛게 만든다. 하지만 현실에 안주하라는 이야기가 아니다. 순서의 문제다. 자신이 해야만 하는 것, 잘할 수 있는 것을 먼저 단단하게 다져야 확장이 의미를 갖는다. 기초 없이 넓히는 것은 확장이 아니라 분산이다.&lt;/p&gt;
&lt;h2&gt;권한과 책임의 지도&lt;/h2&gt;
&lt;p&gt;능력 범위를 인식했다면, 다음 단계는 자신이 조직 안에서 어떤 종류의 일을 하고 있는지를 파악하는 것이다. John Cutler가 제안한 Mandate Levels는 이를 위한 유용한 지도가 된다.&lt;/p&gt;
&lt;p&gt;Mandate Levels는 업무에서의 권한과 책임을 아홉 단계로 구분한다. 먼저 강조해야 할 것은, 이것이 상하관계나 등급을 나타내는 것이 아니라는 점이다. 일에 대한 권한의 종류를 구분한 것이다.&lt;/p&gt;
&lt;p&gt;가장 기초적인 단계에서는 정해진 스펙을 그대로 구현한다. 시키는 일을 정확히 수행하는 것이 이 단계의 핵심이며, 여기서 쌓이는 기본기가 이후 모든 단계의 발판이 된다. 중간 단계로 올라가면 고객의 특정 문제를 직접 정의하고 해결하는 영역이 열린다. 더 이상 &quot;이렇게 만들어라&quot;가 아니라 &quot;이 문제를 풀어라&quot;가 주어지는 것이다. 주어진 입출력이 아니라 문제 자체를 다루기 시작한다는 점에서 질적 전환이 일어난다. 더 나아가면 사업 성과를 개선하기 위한 레버리지 포인트를 탐색하고 실험하는 단계가 있다. 매출 개선을 위한 새로운 방법을 직접 찾아내고 검증하는 일이다. 그리고 최상위 단계에서는 회사 전체의 장기적 사업 성과를 정의하고 책임진다.&lt;/p&gt;
&lt;p&gt;실리콘밸리가 수평적이라고 할 때, 그 수평은 구성원 간의 관계를 말하는 것이지 의사결정의 구조를 말하는 것이 아니다. 어떤 조직이든 의사결정에는 층위가 존재한다. Mandate Levels가 유용한 이유는 이 층위를 투명하게 드러내기 때문이다.&lt;/p&gt;
&lt;p&gt;작은 팀에서는 한 사람이 여러 레벨에 걸쳐 일하는 경우가 많다. 오전에는 고객 문의를 분석하며 문제를 정의하고(중간 단계), 오후에는 그 문제를 해결하기 위한 기능을 직접 구현하며(기초 단계), 저녁에는 분기 전략을 논의한다(상위 단계). 이 자체가 나쁜 것은 아니다. 오히려 작은 팀의 강점이다. 다만 중요한 것은, 자신이 지금 어떤 레벨에서 일하고 있는지를 의식하는 것이다. 그래야 각 레벨에서 요구되는 판단의 기준이 달라진다는 것을 알 수 있고, 자신의 에너지를 어디에 집중해야 하는지가 보인다.&lt;/p&gt;
&lt;h2&gt;성장이 수렴하는 지점&lt;/h2&gt;
&lt;p&gt;Mandate Levels를 통해 자신의 현재 위치를 인식하면, 능력 범위와 자연스럽게 연결된다. 내가 어떤 레벨에서 일하고 있는지를 알면 그 레벨에서 요구되는 능력이 무엇인지가 보인다. 그 능력이 내 현재 능력 범위 안에 있다면 성과를 낼 수 있고, 밖에 있다면 먼저 학습이 필요하다. 이 판단이 가능해지는 것만으로도 헛달림은 줄어든다.&lt;/p&gt;
&lt;p&gt;번아웃은 결국 방향 없는 노력이 쌓일 때 찾아온다. 내가 할 수 있는 일과 해야 하는 일의 교집합을 찾고, 그 안에서 성과를 내는 경험을 축적하는 것. 이것이 번아웃을 이기는 가장 현실적인 방법이다.&lt;/p&gt;
&lt;p&gt;2막을 통해 우리는 채용에서 시작해 리더십, 명료함, 피드백, 공정함, 실행 구조를 거쳐 여기까지 왔다. 팀을 만들고, 팀을 작동시키고, 팀 안의 개인이 지치지 않는 법까지. 이 모든 기술이 하나의 질문으로 수렴한다. 개인의 성장과 팀의 성장이 같은 방향을 가리킬 때, 작은 팀은 비로소 단단해진다.&lt;/p&gt;
&lt;p&gt;그런데 단단한 팀이 만드는 결과물은 결국 제품이다. 팀 내부의 운영 원칙은 팀이 세상에 내놓는 것에도 그대로 스며든다. 2막에서 팀의 안을 들여다보았다면, 이제는 팀의 밖을 바라볼 차례다.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[제품에 철학을 담다]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-10-philosophy-in-product/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-10-philosophy-in-product/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;2막에서 우리는 팀의 내부를 들여다보았다. 누구와 함께할 것인가, 어떻게 이끌 것인가, 무엇을 명료하게 할 것인가, 어떻게 피드백하고 공정함을 세울 것인가, 일의 구조를 어떻게 짤 것인가, 그리고 그 안에서 어떻게 지치지 않을 것인가. 이 모든 질문은 결국 하나의 지점으로 수렴한다. 그래서 그 팀이 무엇을 만드는가.&lt;/p&gt;
&lt;p&gt;팀 운영의 원칙이 아무리 정교해도, 그것이 제품에 반영되지 않으면 의미가 반감된다. 조직의 철학은 슬라이드에 적히는 것이 아니라 제품을 통해 세상에 드러난다. 3막의 시작은 여기서부터다. 시야를 팀 내부에서 외부로 돌려, 우리가 만드는 것에 어떤 생각이 담기는지를 이야기하려 한다.&lt;/p&gt;
&lt;h2&gt;잘 팔면 되는 거 아닌가&lt;/h2&gt;
&lt;p&gt;B2B 사업을 하다 보면 빠지기 쉬운 함정이 있다. &quot;결국 잘 팔면 되는 거 아닌가?&quot;라는 생각이다. 영업 조직이 리드를 확보하고, 데모를 보여주고, 가격을 제안하고, 계약을 따내는 흐름. 혹은 제품이 스스로 말하게 하여, 사용자가 직접 검색하고 비교하고 체험한 뒤 결제하는 흐름. 어느 쪽이든 핵심은 같다고 생각하기 쉽다. 매출이 늘면 성장이고, 성장하면 성공이라고.&lt;/p&gt;
&lt;p&gt;그런데 여기서 한 가지를 놓치면 모든 것이 어긋난다. B2B 제품에는 구매자와 사용자가 다른 경우가 대부분이다. 구매 결정을 내리는 사람은 임원이고, 매일 그 제품 앞에 앉아 일하는 사람은 실무자다. 영업이 아무리 뛰어나도, 데모가 아무리 화려해도, 매일 그것을 쓰는 사람이 효용을 느끼지 못하면 그 계약은 다음 해에 갱신되지 않는다.&lt;/p&gt;
&lt;p&gt;어떤 방식으로 성장하든 결국 고객이 최대의 효용을 느껴야 한다. 이것은 당연한 말처럼 들리지만, 실제로 이 원칙을 지키는 것은 놀라울 만큼 어렵다.&lt;/p&gt;
&lt;p&gt;초기 스타트업에서 흔히 벌어지는 일이 있다. 큰 고객이 들어오면 그 고객의 요구사항을 맞춰준다. 다음 고객이 들어오면 또 그 고객에게 맞춘다. 이런 식으로 몇 번을 반복하면, 어느 순간 제품이 프랑켄슈타인이 되어 있다. 각 고객의 요구를 따로따로 이어붙인 결과물. 전체를 관통하는 설계 원칙은 사라지고, 누구의 문제도 깊이 있게 풀지 못하는 기형적인 무언가가 남는다. 돌이킬 수 없는 수준까지 가고 나서야 문제를 인식하는 경우도 적지 않다.&lt;/p&gt;
&lt;p&gt;볼타가 기업 금융의 비효율을 최적화하는 B2B 핀테크 SaaS를 만들어 나가면서 계속 되뇌었던 것은, 사업적 성공과 제품의 완성도가 양립할 수 있어야 한다는 믿음이었다. 고객의 요구에 끌려다니는 것이 아니라, 고객이 아직 말하지 못한 문제까지 꿰뚫는 제품을 만들겠다는 욕심. 이것은 단순한 이상론이 아니다. 새로운 기능이 추가될 때마다 사용자가 별도의 학습 없이 스스로 이해할 수 있어야 한다는 구체적인 기준으로 작동하는 원칙이다.&lt;/p&gt;
&lt;p&gt;그리고 이 원칙을 지키려면, 제품을 만드는 사람들이 가장 본능적으로 원하는 것 하나를 내려놓아야 한다.&lt;/p&gt;
&lt;h2&gt;사용자를 붙잡지 않는 용기&lt;/h2&gt;
&lt;p&gt;제품을 만드는 사람이라면 누구나 이런 욕망이 있다. 사용자가 오래 머물기를. 자주 돌아오기를. 떠나지 않기를. 사용 시간이 늘어나면 뿌듯하고, 활성 사용자 수가 올라가면 안심하고, 이탈률이 낮아지면 성공했다고 느낀다. 내가 만든 것에 사람들이 시간을 쓴다는 것은, 그것이 가치 있다는 증거처럼 보인다.&lt;/p&gt;
&lt;p&gt;하지만 이 욕망이 설계를 지배하면 이상한 일이 벌어진다. 끝없이 스크롤되는 피드. 자동으로 재생되는 다음 영상. 끊임없이 울리는 알림. 이 장치들의 목적은 하나다. 사용자를 떠나지 못하게 만드는 것. 그런데 영화가 끝났는데 극장 문을 잠그고 다음 상영을 강제하면, 그곳은 극장이 아니라 감옥이 된다. 사용자의 시간을 점유하는 것과 사용자에게 가치를 주는 것은 전혀 다른 일이다. 이 둘을 혼동하는 순간, 제품은 사용자를 위한 도구가 아니라 사용자를 소비하는 기계로 변한다.&lt;/p&gt;
&lt;p&gt;어린 시절 본 애니메이션의 마지막 회를 떠올려 본다. 모험이 끝나고 주인공이 일상으로 돌아가고, 석양이 지는 화면 위로 엔딩곡이 흐른다. 아쉽지만 동시에 충만한 그 감각. &quot;이 이야기는 여기서 끝입니다&quot;라는 신호가 지금까지의 체험을 하나의 완결된 덩어리로 만들어주었다. 끝이 있기 때문에 의미가 생겼다. 끝이 없었다면 그것은 이야기가 아니라 그냥 시간의 흐름이었을 것이다.&lt;/p&gt;
&lt;p&gt;제품도 마찬가지다. 우리가 만드는 제품은 사용자 인생의 주인공이 아니다. 조연이다. 아무리 뛰어난 서비스라도 사용자의 하루 중 극히 일부만 차지한다. 그리고 그래야 한다. 좋은 조연은 주인공의 이야기를 돕고, 자기 역할이 끝나면 무대에서 내려온다. 사용자가 할 일을 끝내면 보내줘야 한다. 할 일 관리 앱은 모든 항목이 완료되면 빈 화면을 보여주며 &quot;오늘은 끝났다&quot;고 말해야 한다. 그 빈 화면이 사용자가 자기 인생의 다음 장면으로 넘어가는 문이다.&lt;/p&gt;
&lt;p&gt;만드는 사람 입장에서 빈 화면은 무섭다. 사용자가 이탈할 수 있는 순간이기 때문이다. 그래서 빈 화면 대신 추천 콘텐츠를 넣고, 다음 목표를 제안하고, 무엇이든 하게 만들려 한다. 하지만 할 일을 다 한 사람을 억지로 붙잡는 것은, 집에 가겠다는 친구 앞에서 현관문을 막는 것과 같다. 한두 번은 괜찮을 수 있지만, 반복되면 그 집에 다시 가고 싶지 않아진다.&lt;/p&gt;
&lt;h2&gt;떠났다가 스스로 돌아오게 하는 것&lt;/h2&gt;
&lt;p&gt;멈출 수 있는 서비스에 사람들이 더 자주 돌아온다. 직관에 반하는 이야기지만, 곰곰이 생각하면 자연스러운 이치다.&lt;/p&gt;
&lt;p&gt;넷플릭스의 자동 재생을 떠올려 보자. 에피소드가 끝나면 5초 후 다음 편이 시작된다. 멈추려면 적극적으로 행동해야 한다. 리모컨을 찾아 버튼을 눌러야 한다. 그 결과 의도보다 더 오래 시청하게 되고, 플랫폼의 시청 시간 지표는 올라간다. 하지만 그 시간이 끝난 후 남는 감정은 충만함이 아니라 후회다. &quot;또 너무 오래 봤다.&quot; 이 후회가 반복되면 서비스를 여는 것 자체가 부담이 된다.&lt;/p&gt;
&lt;p&gt;반대로 좋은 책은 챕터마다 자연스러운 멈춤 지점이 있다. 한 장을 읽고 책을 덮을 수 있는 여유. 그 여유가 있기 때문에 다음 날 다시 책을 집어든다. 읽다가 멈춘 것이 아쉬움이 되고, 그 아쉬움이 내일의 동력이 된다.&lt;/p&gt;
&lt;p&gt;오래된 게임 디자인에서도 비슷한 통찰을 발견할 수 있다. 슈퍼 마리오 브라더스에는 워프 존이라는 것이 있다. 스테이지를 건너뛸 수 있는 숨겨진 통로다. 공들여 만든 스테이지를 건너뛰게 해주다니, 디자이너 입장에서는 모순적인 결정처럼 보인다. 하지만 워프 존이 있기 때문에, 플레이어는 자신이 이 게임을 통제하고 있다고 느낀다. 건너뛸 수 있지만 건너뛰지 않기로 선택하는 것. 그 선택이 체험의 질을 바꾼다. &quot;나는 이 스테이지를 하고 싶어서 하고 있다&quot;는 감각과 &quot;이 스테이지를 할 수밖에 없다&quot;는 감각은, 같은 행위를 전혀 다른 경험으로 만든다.&lt;/p&gt;
&lt;p&gt;제품에서도 똑같은 원리가 작동한다. 사용자에게 선택지가 있다는 것은 자유가 있다는 것이고, 자유가 있다는 것은 자기 의지로 참여하고 있다는 것이다. 자기 의지로 참여한 경험은 기억에 남고, 강제된 경험은 소모된다.&lt;/p&gt;
&lt;p&gt;리텐션의 진짜 의미는 여기에 있다. 사용자를 떠나지 못하게 하는 것이 아니라, 떠났다가 스스로 돌아오게 하는 것. 그러려면 먼저 떠날 수 있어야 한다. 자유를 주면 사용자가 떠날 수도 있다는 가능성을 감수하는 것은 용기가 필요한 일이다. 하지만 자유 속에서 남기로 선택한 사용자는, 붙잡혀서 머무는 사용자와는 비교할 수 없는 깊이의 관계를 맺는다.&lt;/p&gt;
&lt;h2&gt;팀의 철학이 제품이 된다&lt;/h2&gt;
&lt;p&gt;여기서 2막의 이야기가 다시 연결된다.&lt;/p&gt;
&lt;p&gt;우리는 팀을 운영하면서 구성원의 자율성을 존중하는 법을 배웠다. 채용에서 함께한 적 없는 사람을 영입하는 역발상도, 리더가 부서의 대사가 아니라 조직 전체의 리더로 서는 것도, 피드백을 시스템으로 만드는 것도, 공정함을 과정에서 세우는 것도, What과 How를 분리하여 모든 구성원이 방향 설정에 참여하게 하는 것도 — 근저에 깔린 원칙은 하나였다. 사람을 통제하지 않고, 사람이 스스로 움직이는 구조를 만드는 것.&lt;/p&gt;
&lt;p&gt;이 원칙이 제품 설계에 그대로 반영된다. 팀이 구성원에게 자율성을 주듯, 제품도 사용자에게 자유를 준다. 팀이 불필요한 회의와 보고 대신 명료한 맥락 공유를 선택하듯, 제품도 불필요한 알림과 강제 대신 깔끔한 완결을 선택한다. 팀이 구성원을 붙잡지 않고 성장할 기회를 주듯, 제품도 사용자를 붙잡지 않고 떠날 자유를 준다.&lt;/p&gt;
&lt;p&gt;작은 팀이 만드는 제품의 차별점은 기능의 수가 아니다. 기능의 수에서 경쟁하면 큰 조직을 이길 수 없다. 차별점은 태도에서 나온다. 제품의 구석구석에 배어 있는 사용자에 대한 존중. 프랑켄슈타인이 되지 않겠다는 의지. 할 일이 끝나면 깔끔하게 보내주겠다는 용기. 이런 철학은 수백 명이 분업하는 조직에서는 유지하기 어렵다. 의사결정이 분산되면 철학도 희석된다. 작은 팀이기 때문에 하나의 철학을 제품 전체에 관통시킬 수 있다.&lt;/p&gt;
&lt;p&gt;존중받았다고 느끼는 사용자만이 진심으로 돌아온다. 이것은 제품 철학인 동시에, 지금까지 이야기해 온 팀 운영 철학의 자연스러운 연장이다.&lt;/p&gt;
&lt;p&gt;그리고 이 철학을 제품에 온전히 담으려면, 적은 인원으로 깊이 있는 결정을 내릴 수 있는 구조가 필요하다. 다음 장에서는 AI 시대에 작은 팀이 그 구조적 이점을 어떻게 극대화할 수 있는지를 이야기하려 한다.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[AI 시대, 작은 팀이 유리한 이유]]></title><description><![CDATA[제품에 철학을 담으려면 깊이 있는 결정이 필요하다. 그런데 깊이 있는 결정은 회의실에 스무 명이 앉아 있을 때가 아니라, 서너 명이 같은 맥락을 공유한 채 마주 앉아 있을 때 나온다. 이 직관은 AI…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-11-ai-era-small-teams/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-11-ai-era-small-teams/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;제품에 철학을 담으려면 깊이 있는 결정이 필요하다. 그런데 깊이 있는 결정은 회의실에 스무 명이 앉아 있을 때가 아니라, 서너 명이 같은 맥락을 공유한 채 마주 앉아 있을 때 나온다. 이 직관은 AI 시대에 들어서면서 직관이 아닌 구조적 사실로 바뀌고 있다.&lt;/p&gt;
&lt;p&gt;앞 챕터에서 우리는 How의 비용이 0에 수렴하는 세상을 이야기했다. 만드는 일은 점점 싸지고, 정의하는 일만이 여전히 비싸다. 그때 우리가 집중한 것은 팀 내부의 실행 구조였다. 누가 What에 참여하고, 어떻게 스프린트를 교차 운영할 것인가. 하지만 그 논의에서 한 걸음 더 나가면, 더 근본적인 질문이 기다리고 있다.&lt;/p&gt;
&lt;p&gt;AI가 개인을 강하게 만들수록, 조직이라는 형태 자체에 어떤 변화가 일어나는가.&lt;/p&gt;
&lt;h2&gt;규모의 경제가 무너지는 지점&lt;/h2&gt;
&lt;p&gt;오랫동안 큰 조직에는 명확한 이점이 있었다. 분업, 전문화, 규모의 경제. 백 명이 모이면 한 사람이 하나의 역할만 깊이 파고들 수 있고, 그 깊이가 모여 개인으로는 불가능한 결과물을 만들어냈다. 이 공식은 제조업에서 시작되어 소프트웨어 산업에까지 그대로 이식되었다.&lt;/p&gt;
&lt;p&gt;그런데 AI가 이 공식의 전제를 흔들고 있다.&lt;/p&gt;
&lt;p&gt;첫째, 분업의 경계가 허물어지고 있다. 과거에 한 사람이 기획 리서치를 하고, 다른 사람이 프로토타입을 만들고, 또 다른 사람이 코드를 작성하던 흐름이 있었다. 세 사람이 순차적으로 해야 했던 이 과정을, 이제 한 사람이 AI 도구를 곁에 두고 하루 안에 순환시킬 수 있다. 분업이 효율적이었던 이유는 각 단계에 전문 기술이 필요했기 때문인데, AI가 그 전문 기술의 접근 비용을 극적으로 낮춘 것이다.&lt;/p&gt;
&lt;p&gt;둘째, 전문화의 의미가 바뀌고 있다. &quot;이 분야만 깊이 아는 사람&quot;의 가치가 사라지는 것은 아니다. 하지만 &quot;여러 분야를 빠르게 학습하고 연결하는 사람&quot;의 가치가 급격히 올라가고 있다. 이것은 작은 팀에서 이미 일상적으로 요구되는 역량이다. 다섯 명이 하나의 제품을 만들 때, 한 사람이 하나의 역할만 고수하는 것은 사치다. 모두가 경계를 넘나들며 일해야 한다. 그리고 AI는 그 경계 넘기를 가능하게 만드는 가장 강력한 도구다.&lt;/p&gt;
&lt;p&gt;셋째, 규모가 오히려 비용이 되는 지점이 생겼다. 큰 조직이 새로운 AI 도구를 도입하려면 어떤 과정을 거치는지 생각해보자. 보안 검토, 정책 수립, 교육 프로그램 설계, 부서 간 협의, 파일럿 프로젝트, 성과 측정. 도구 자체의 비용보다 도입 과정의 조정 비용이 몇 배 더 크다. 작은 팀은 이 모든 과정을 점심시간에 끝낼 수 있다. 누군가 좋은 도구를 발견하면 오후에 바로 써보고, 저녁에 팀 전체가 피드백을 나눈다. 다음 날 아침이면 그 도구가 팀의 일상 속에 녹아 있다.&lt;/p&gt;
&lt;p&gt;규모의 경제가 작동하려면 환경이 안정적이어야 한다. 같은 공정을 반복할수록 효율이 올라가는 구조니까. 하지만 AI로 인해 도구와 방법론이 몇 달 단위로 바뀌는 시대에, 규모는 관성이 되고 관성은 곧 둔감함이 된다.&lt;/p&gt;
&lt;h2&gt;작은 팀에서 AI가 증폭시키는 것&lt;/h2&gt;
&lt;p&gt;AI는 개인의 능력을 증폭시키는 도구다. 그런데 같은 도구라도 어떤 팀에서 쓰느냐에 따라 증폭의 크기가 전혀 다르다. 작은 팀이 가진 세 가지 고유한 강점 — 인재밀도, 의사결정 속도, 맥락 공유 — 은 AI와 만났을 때 덧셈이 아니라 곱셈으로 작동한다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;인재밀도와 AI의 곱셈.&lt;/strong&gt; 인재밀도가 높은 팀에서 AI의 효과는 극대화된다. 맥락을 깊이 이해하고, 문제의 본질을 꿰뚫고, 방향을 정확히 설정할 수 있는 사람이 AI를 활용하면 생산성이 몇 배로 뛴다. 반면 맥락 이해가 부족한 사람은 AI를 써도 방향 자체가 틀릴 수 있다. AI는 &quot;무엇을 해야 하는가&quot;를 알려주지 않는다. &quot;어떻게 해야 하는가&quot;를 빠르게 실행해줄 뿐이다. What을 정의할 수 있는 사람의 손에 쥐어진 AI만이 의미 있는 결과를 만든다. 작은 팀의 높은 인재밀도는 이 조건을 자연스럽게 충족시킨다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;의사결정 속도와 AI의 곱셈.&lt;/strong&gt; AI가 아무리 빠르게 선택지를 생성해도, 최종 결정은 여전히 사람이 한다. 의사결정 레이어가 세 단계인 조직에서는 AI가 만들어낸 옵션이 팀장에서 실장으로, 실장에서 본부장으로 올라가는 동안 시간이 흐른다. 각 단계에서 맥락이 손실되고, 원래의 의도가 희석된다. 의사결정 레이어가 하나인 조직에서는 AI가 제시한 선택지를 보고 바로 판단하고, 바로 실행에 옮긴다. AI 시대에 실행 속도의 병목은 &quot;만드는 속도&quot;가 아니라 &quot;결정하는 속도&quot;다. 그리고 결정하는 속도는 조직 구조가 결정한다.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;맥락 공유와 AI의 곱셈.&lt;/strong&gt; AI에게 정확한 결과를 얻으려면 정확한 맥락을 줘야 한다. 고객이 어떤 문제를 겪고 있는지, 시장이 어떤 방향으로 움직이고 있는지, 우리 제품의 기술적 제약이 무엇인지. 작은 팀에서는 모든 구성원이 이 맥락을 공유한다. 누구라도 AI에게 정확한 질문을 던질 수 있다. 큰 조직에서 맥락은 부서의 경계에서 끊긴다. 마케팅팀이 아는 고객 정보, 엔지니어링팀이 아는 기술적 제약, 영업팀이 아는 시장 상황 — 이것들이 한 사람의 머릿속에 모이지 않으면, AI에게 줄 수 있는 맥락도 파편적이 된다.&lt;/p&gt;
&lt;p&gt;볼타에서 이 세 가지는 매일의 일상 속에서 작동한다. 고객 문의가 들어오면 엔지니어가 직접 읽고, 그 자리에서 AI 코딩 도구를 열어 프로토타입을 만들어본다. 기획 회의에서 나온 아이디어를 오후에 바로 검증할 수 있다. 누군가 새로운 AI 리서치 도구를 발견하면 그날 오후에 팀 전체가 써보고 피드백을 나눈다. 이 모든 것이 가능한 이유는 다섯 명 모두가 같은 맥락 안에 있고, 의사결정에 별도의 승인 과정이 없으며, 각자가 자기 영역 너머의 일까지 판단할 수 있는 밀도를 갖추고 있기 때문이다. 작은 팀이 AI와 함께일 때, 규모가 열 배 큰 팀이 하는 일을 해낼 수 있다는 것은 과장이 아니라 이미 우리가 경험하고 있는 현실이다.&lt;/p&gt;
&lt;h2&gt;What을 정의하는 사람만 남는 시대&lt;/h2&gt;
&lt;p&gt;이 모든 변화가 가리키는 방향은 하나다. How가 공짜가 되어가는 세상에서, 팀의 가치는 &quot;몇 명이 있느냐&quot;가 아니라 &quot;얼마나 정확하게 What을 정의하느냐&quot;에 달려 있다.&lt;/p&gt;
&lt;p&gt;큰 조직이 사람을 많이 모아서 얻던 이점 — 전문 분업, 규모의 경제, 조직적 지식의 축적 — 은 AI가 상당 부분 대체하거나 무력화하고 있다. 반면 작은 팀이 원래 가지고 있던 강점 — 높은 인재밀도, 빠른 의사결정, 깊은 맥락 공유 — 은 AI에 의해 증폭되고 있다. 이것은 우연이 아니라 구조적 필연이다.&lt;/p&gt;
&lt;p&gt;AI 시대에 작은 팀이 유리하다는 주장은 기술 낙관론이 아니다. AI가 만능이라서가 아니라, AI라는 도구의 특성이 작은 팀의 구조와 정확히 맞물리기 때문이다. AI는 방향을 설정하지 못한다. 맥락을 이해하지 못한다. 고객의 진짜 문제가 무엇인지 판단하지 못한다. 이 모든 것은 여전히 사람의 영역이고, 그 사람들이 밀도 높게 모여 빠르게 결정하고 깊이 공유하는 구조가 작은 팀이다.&lt;/p&gt;
&lt;p&gt;작은 팀을 유지한다는 것은 성장을 포기한다는 뜻이 아니다. 오히려 AI 시대에 가장 효과적으로 성장할 수 있는 구조를 선택한다는 뜻이다. 한 사람이 할 수 있는 일의 양이 점점 커지는 세상에서, 위험하게 몸집을 불리는 것보다 의사소통 비용이 적고 플랫한 조직을 유지하는 것이 변화에 훨씬 빠르게 대응할 수 있는 전략이 된다.&lt;/p&gt;
&lt;p&gt;그렇다면 이제 질문은 이렇게 바뀐다. 작은 팀이라는 형태가 구조적 우위를 갖는다면, 그 우위를 지속 가능하게 만드는 것은 무엇인가. AI 시대의 강점을 확인했다면, 이제 그 강점이 어떤 미래로 이어지는지를 그려볼 차례다.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[작은 팀의 미래]]></title><description><![CDATA[AI…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-12-future-of-small-teams/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-12-future-of-small-teams/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;AI가 실행의 비용을 극적으로 낮추고, 한 사람이 해낼 수 있는 일의 범위가 넓어지는 시대를 우리는 이미 살고 있다. 이전 챕터에서 우리는 이 변화가 작은 팀에게 구조적 우위를 안겨준다는 것을 확인했다. 인재밀도가 높은 소수의 팀이 의사결정 속도와 방향 전환의 유연함에서 압도적 이점을 갖는다는 사실을. 그렇다면 이제 한 걸음 더 나가보자. 작은 팀이라는 선택은 지금 이 순간만을 위한 전략인가, 아니면 앞으로의 세계가 요구하는 구조인가.&lt;/p&gt;
&lt;h2&gt;성장의 공식이 바뀌고 있다&lt;/h2&gt;
&lt;p&gt;오랫동안 스타트업의 성장에는 하나의 공식이 있었다. 제품-시장 적합성을 찾고, 투자를 받고, 사람을 더 뽑는다. 그렇게 몸집을 불려서 시장을 점유한다. 이 루프를 빠르게 도는 팀이 이기는 팀이었다. PMF를 발견한 다음 날부터 채용 공고가 올라가고, 시리즈 A 이후에는 인원이 두 배, 세 배로 뛰는 것이 당연한 수순으로 여겨졌다.&lt;/p&gt;
&lt;p&gt;이 공식은 한동안 잘 작동했다. 그러나 그 안에는 누구도 크게 이야기하지 않는 비용이 숨어 있었다.&lt;/p&gt;
&lt;p&gt;첫째, 사업 방향의 경직이다. 특정 역할을 염두에 두고 채용한 사람들은, 사업의 방향이 바뀌었을 때 새로운 역할로 이동하기 어렵다. 매출이 나오는 비즈니스를 내려놓고 새로운 도전을 시작하는 것은 인원이 많을수록 더 큰 뚝심과 합의를 필요로 한다. 조직이 클수록 방향 전환은 유조선의 선회처럼 느리고 고통스러워진다.&lt;/p&gt;
&lt;p&gt;둘째, 커뮤니케이션 비용의 폭증이다. 인원이 늘면 의사결정 레이어가 추가되고, 같은 정보를 전달하는 데 필요한 경로가 기하급수적으로 증가한다. 빠른 의사결정이라는 스타트업의 핵심 강점이 인원 증가와 함께 퇴화하는 것이다. 전화기를 아무리 많이 놓아도 통화의 질이 좋아지지 않듯, 사람이 많다고 실행이 빨라지지 않는다.&lt;/p&gt;
&lt;p&gt;셋째, 인재밀도의 희석이다. 급하게 사람을 늘리면 한 사람 한 사람의 밀도가 떨어진다. 밀도가 떨어진 조직은 더 많은 관리 체계를 필요로 하고, 그 관리 체계는 다시 속도를 떨어뜨린다. 성장을 위한 채용이 오히려 성장을 방해하는 역설이 벌어진다.&lt;/p&gt;
&lt;p&gt;이 세 가지 비용은 과거에도 존재했지만, 변화의 속도가 상대적으로 느렸기 때문에 감내할 만했다. 시장이 서서히 변하는 세계에서는 방향 전환이 잦지 않았고, 커뮤니케이션 비용은 성장의 대가로 수용되었다. 그러나 지금은 다르다. AI가 산업의 지형을 몇 달 단위로 바꾸는 시대에, 이 비용들은 더 이상 감내할 수 있는 수준이 아니다.&lt;/p&gt;
&lt;h2&gt;건강한 성장의 조건&lt;/h2&gt;
&lt;p&gt;그렇다면 성장을 포기해야 하는가. 물론 아니다. 포기해야 하는 것은 성장 자체가 아니라, &quot;성장을 위한 성장&quot;이라는 관성이다. 몸집을 불리는 것이 곧 성장이라는 등식을 내려놓을 때, 비로소 다른 종류의 성장이 보인다. 건강하고 오래 갈 수 있는 성장이.&lt;/p&gt;
&lt;p&gt;이 책 전체를 관통하며 탐구해온 주제들은 사실 하나의 질문을 향해 수렴하고 있었다. 적은 인원으로 어떻게 큰 일을 해낼 수 있는가. 그 답의 조각들을 지금 한자리에 모아본다.&lt;/p&gt;
&lt;p&gt;인재밀도다. 적은 인원이지만, 한 사람 한 사람이 자기 영역에서 높은 밀도를 가진다. 채용의 기준을 타협하지 않고, 함께 일해본 적 없는 사람에게서도 가능성을 발견하는 용기. 이것이 작은 팀의 첫 번째 조건이었다.&lt;/p&gt;
&lt;p&gt;명료한 방향이다. 여섯 가지 질문에 리더 전원이 같은 답을 할 수 있는 상태. 미션 선언문이라는 액자가 아니라, 일상적 의사결정의 매 순간에 나침반처럼 작동하는 합의. 인원이 적기 때문에 이 합의가 가능하고, 이 합의가 있기 때문에 적은 인원으로도 일관된 방향으로 움직일 수 있다.&lt;/p&gt;
&lt;p&gt;자율적 피드백이다. 위에서 내려오는 평가가 아니라, 동료 간에 서로의 행동에 책임을 묻는 구조. 불편한 말을 시스템 안에 녹여냄으로써, 작은 팀이 빠지기 쉬운 침묵의 함정을 피한다. 관리자가 없어도 팀이 스스로를 교정하는 힘이 여기서 나온다.&lt;/p&gt;
&lt;p&gt;전원이 What에 참여하는 구조다. 실행만 하는 사람이 아니라 정의하는 사람들의 팀. 문제를 파악하고, 아이디어를 내고, 방향을 잡는 일에 모든 구성원이 기여한다. 실행 비용이 0에 수렴하는 시대에, 살아남는 팀은 더 빨리 만드는 팀이 아니라 더 잘 정의하는 팀이다.&lt;/p&gt;
&lt;p&gt;일상 속에서 훈련되는 직관이다. 고객을 이해하고, 시장을 읽고, 팀원의 강점을 파악하는 감각. 데이터가 없는 상황에서도 &quot;이건 풀 만한 문제&quot;라는 판단을 내릴 수 있는 역량. 이 직관은 타고나는 것이 아니라 훈련되는 것이며, 작은 팀의 모든 구성원에게 그 훈련의 기회가 열려 있다.&lt;/p&gt;
&lt;p&gt;이 모든 것이 따로 노는 개별 기술이 아니다. 높은 인재밀도가 명료한 방향을 만들고, 명료한 방향이 자율적 피드백을 가능하게 하고, 자율적 피드백이 전원의 What 참여를 이끌어내고, What 참여의 경험이 직관을 훈련한다. 하나의 톱니가 다음 톱니를 돌리는 체계. 이것이 작은 팀의 운영 체계이며, 건강한 성장의 조건이다.&lt;/p&gt;
&lt;h2&gt;앞으로의 세계가 요구하는 구조&lt;/h2&gt;
&lt;p&gt;변화의 속도는 앞으로도 계속 빨라질 것이다. 이것은 예측이 아니라, 지난 10년간의 추세가 보여주는 사실이다. AI 기술은 매 분기마다 이전 분기의 한계를 허물고, 산업의 경계는 점점 더 빠르게 재편된다.&lt;/p&gt;
&lt;p&gt;이런 시대에 큰 조직의 관성은 치명적인 약점이 된다. 수백 명의 합의를 구하고, 기존 사업의 관성을 극복하고, 새로운 방향으로 전환하는 데 걸리는 시간이 곧 기회비용이다. 반면 작은 팀의 민첩함은 이 시대가 요구하는 핵심 역량이 된다. 방향을 바꾸는 데 몇 달이 아니라 며칠이면 충분한 팀. 새로운 기술을 도입하는 데 위원회의 승인이 아니라 점심시간의 대화로 충분한 팀.&lt;/p&gt;
&lt;p&gt;폴 자비스가 《Company of One》에서 그린 그림이 있다. 성장 자체를 목적으로 삼지 않고, 더 나은 것을 목적으로 삼는 회사. 더 크게가 아니라 더 잘을 추구하는 조직. 그가 이 책을 쓸 때만 해도 이것은 하나의 철학적 선택이었다. 하지만 AI 시대에 접어든 지금, 이것은 철학이 아니라 생존 전략에 가깝다. 한 사람이 해낼 수 있는 일의 범위가 극적으로 넓어진 세상에서, 몸집을 불리는 것은 더 이상 경쟁 우위가 아니기 때문이다.&lt;/p&gt;
&lt;p&gt;볼타는 이 방향을 구체적인 운영 원칙으로 실천해왔다. 불필요한 커뮤니케이션 비용을 줄이고, 효율적으로 일하기 위해 작은 팀을 유지하며, 작은 팀의 강점을 모두 챙기기 위해 노력한다. 이것은 슬로건이 아니라 매일의 의사결정에 적용되는 기준이다. 새로운 프로젝트가 생겼을 때 사람을 더 뽑는 것이 아니라, 기존 팀의 역량 배치를 재구성한다. AI 도구가 생산성을 높여주면, 그 여유를 채용이 아니라 각 구성원의 What 참여 확대에 투자한다.&lt;/p&gt;
&lt;p&gt;이것이 성장을 거부하는 것일까. 전혀 아니다. 매출은 성장하고, 고객은 늘어나고, 해결하는 문제의 범위는 넓어진다. 다만 그 성장이 인원의 증가로 이어지는 것이 아니라, 한 사람 한 사람의 역량 확장으로 이어지는 것이다. 이것이 건강한 성장의 모습이다.&lt;/p&gt;
&lt;h2&gt;작은 팀의 기술은 큰 비전을 위한 것이다&lt;/h2&gt;
&lt;p&gt;한 가지 오해를 풀어야 한다. 작은 팀이 좋다는 말이 작은 꿈을 꾸라는 뜻은 아니다. 오히려 정반대다.&lt;/p&gt;
&lt;p&gt;큰 비전을 실현하려면 팀의 형태를 가장 효율적으로 유지해야 한다. 비전이 클수록 자원의 낭비를 허용할 여유가 없다. 커뮤니케이션 비용에 에너지를 쏟는 대신 고객의 문제에 집중해야 하고, 내부 정치에 시간을 빼앗기는 대신 시장의 변화를 읽어야 한다. 작은 팀은 이 모든 것을 가능하게 하는 구조다.&lt;/p&gt;
&lt;p&gt;잘 정의하는 것은 특정 직군 한두 명의 역할이 아니라, 제품팀 전체의 역량이다. 이 한 문장이 이 책 전체를 관통하는 메시지일지도 모른다. 무엇을 만들 것인가를 함께 고민하고, 왜 이것을 해야 하는가에 모두가 같은 답을 할 수 있고, 어떻게 해야 하는가는 각자의 전문성에 맡기되 서로의 성장을 돕는 구조. 이것이 작은 팀의 기술이며, 이 기술은 작은 꿈이 아니라 큰 비전을 실현하기 위해 존재한다.&lt;/p&gt;
&lt;p&gt;성장을 위한 성장의 시대는 저물고 있다. 그 자리에 들어서는 것은, 밀도 높은 소수가 명료한 방향 아래 자율적으로 움직이며 세상의 변화에 민첩하게 대응하는 팀의 시대다. 작은 팀의 미래는 낭만이 아니다. 앞으로의 세계가 요구하는 구조다.&lt;/p&gt;
&lt;p&gt;이 구조적 논증은 여기서 마무리된다. 그러나 모든 구조와 원칙 뒤에는 그것을 선택한 사람의 이야기가 남아 있다. 다음 장에서 우리는 선언이 아니라 다짐으로, 다시 개인적인 목소리로 돌아간다.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item><item><title><![CDATA[에필로그. 여전히 작은 팀으로]]></title><description><![CDATA[…]]></description><link>https://dataportal.kr/books/the-art-of-small-teams/ch-13-epilogue/</link><guid isPermaLink="false">https://dataportal.kr/books/the-art-of-small-teams/ch-13-epilogue/</guid><pubDate>Wed, 01 Apr 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;큰 방향은 변하지 않지만, 매주 작은 꿈들을 새롭게 세워나가고 있다.&lt;/p&gt;
&lt;p&gt;이 문장을 처음 적었을 때는 그것이 무엇을 의미하는지 스스로도 잘 몰랐다. 큰 방향이란 무엇인가. 작은 꿈이란 또 무엇인가. 그것이 매주 바뀐다면 우리는 정말로 한 방향을 향해 가고 있는 것인가. 그런데 볼타를 운영하며 몇 년을 보내고 나니, 이 문장이 우리 팀의 리듬 그 자체였다는 것을 알게 되었다. 큰 방향은 흔들리지 않되, 거기에 도달하는 경로는 매주 다시 그린다. 어제의 계획을 오늘 수정하는 것이 혼란이 아니라 학습의 증거인 팀. 그런 팀이 되고 싶었고, 조금씩 그렇게 되어가고 있다.&lt;/p&gt;
&lt;h2&gt;본질에 집중한다는 것&lt;/h2&gt;
&lt;p&gt;이 책에서 나는 여러 가지를 이야기했다. 채용에 대해, 리더십에 대해, 명료함과 피드백에 대해, 실행과 번아웃에 대해, 제품과 AI에 대해. 열두 개의 챕터에 걸쳐 각기 다른 주제를 다루었지만, 돌이켜보면 그것들은 모두 하나의 문장을 향해 수렴하고 있었다.&lt;/p&gt;
&lt;p&gt;본질에 집중한다.&lt;/p&gt;
&lt;p&gt;볼타는 전세계 재무팀의 비효율적인 시간 낭비를 줄이고, 그들이 본질에 집중하여 더 큰 가치를 만들어낼 수 있도록 돕는 회사다. 그리고 그것을 해내기 위해, 우리 자신도 본질에 집중해야 한다. 채용에서 본질은 인재밀도를 타협하지 않는 것이었고, 리더십에서 본질은 부서의 대사가 아니라 팀 전체를 보는 것이었다. 명료함의 본질은 선언문이 아니라 같은 답이었고, 피드백의 본질은 불편하더라도 말하는 것이었다. 실행의 본질은 무엇을 할 것인가를 함께 정의하는 것이었고, 성장의 본질은 몸집이 아니라 밀도였다.&lt;/p&gt;
&lt;p&gt;결국 이 책 전체가 &quot;본질에 집중한다&quot;는 한 문장의 풀이였는지도 모른다.&lt;/p&gt;
&lt;p&gt;프롤로그에서 나는 카페에서 시작된 이야기를 했다. 아메리카노 두 잔 사이에 놓인 노트북, 냅킨에 끄적인 데이터베이스 구조, &quot;같이 하시죠&quot;라는 한마디. 그때의 두 사람은 지금도 같은 팀에 있다. 팀은 조금 더 커졌지만 여전히 작다. 사무실은 바뀌었지만 한 공간에서 모든 맥락이 공유되는 밀도는 그대로다. 제품은 완전히 달라졌지만, 고객의 문제를 직접 듣고 직접 푸는 거리감은 변하지 않았다.&lt;/p&gt;
&lt;p&gt;달라진 것도 있다. 두 사람이 감당하기 벅찼던 결정들을 이제는 팀 전체가 함께 내린다. 혼자 안고 있던 불확실성을 이제는 함께 마주한다. 직관은 더 날카로워졌고, 서로에 대한 이해는 더 깊어졌다. 무엇보다, 왜 이 일을 하는가에 대한 답이 더 단단해졌다.&lt;/p&gt;
&lt;h2&gt;독자에게&lt;/h2&gt;
&lt;p&gt;이 책이 정답을 담고 있다고 생각하지 않는다. 볼타가 발견한 것들은 볼타의 맥락에서 작동한 것이지, 모든 팀에 그대로 적용될 수 있는 보편 공식은 아니다. 다만 이 여정에서 반복적으로 확인한 것이 하나 있다면, 그것은 좋은 팀은 우연히 만들어지지 않는다는 사실이다. 의식적으로 선택하고, 매일 실천하고, 불편한 순간에도 포기하지 않을 때 비로소 만들어진다.&lt;/p&gt;
&lt;p&gt;이 책을 덮으며 한 가지만 물어보고 싶다.&lt;/p&gt;
&lt;p&gt;당신은 어떤 팀에서, 어떤 방식으로 일하고 싶은가.&lt;/p&gt;
&lt;p&gt;작은 팀이든 큰 팀이든, 스타트업이든 대기업이든, 그 질문 앞에서 자신만의 답을 갖고 있는 사람은 이미 절반은 해낸 것이다. 나머지 절반은 그 답을 매일의 일상에서 실천하는 일이다. 그것이 쉽지 않다는 것을, 나도 매일 느끼고 있다.&lt;/p&gt;
&lt;p&gt;볼타는 여전히 작은 팀이다. 그리고 앞으로도 그럴 것이다. 이것은 성장의 포기가 아니다. 가장 효과적인 성장의 형태를 선택한 것이다. 규모의 선언이 아니라, 태도의 선언이다.&lt;/p&gt;
&lt;p&gt;이 책이 팀의 일하는 방식을 고민하시는 분들께 작은 도움이 되기를 바란다.&lt;/p&gt;
&lt;hr&gt;</content:encoded></item></channel></rss>