# 협업은 쓸모없다 > Clean Markdown view of GeekNews topic #24312. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24312](https://news.hada.io/topic?id=24312) - GeekNews Markdown: [https://news.hada.io/topic/24312.md](https://news.hada.io/topic/24312.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-12T11:33:44+09:00 - Updated: 2025-11-12T11:33:44+09:00 - Original source: [newsletter.posthog.com](https://newsletter.posthog.com/p/collaboration-sucks) - Points: 48 - Comments: 12 ## Summary 스타트업의 생산성을 갉아먹는 건 종종 **‘협업’ 그 자체**일지도 모릅니다. PostHog는 “**당신이 드라이버다**”라는 원칙 아래, 불필요한 피드백 루프와 **‘let’s discuss’ 문화**를 과감히 줄이고 **즉시 실행과 명확한 책임**을 우선시 한다고 하는데요. 협업 과잉은 선의에서 비롯되지만 결국 속도를 늦추고 오너십을 흐리게 만든다는 통찰이 인상적입니다. 빠른 실험과 자율을 중시하는 팀이라면, 이 글이 ‘좋은 협업’의 기준을 다시 생각하게 만들 것입니다. ## Topic Body - **“혼자 가면 빠르고, 함께 가면 멀리 간다”** 는 격언은 스타트업을 망하게 할 수 있음 - 효율적인 협업은 운전 중 내비게이션 도움 수준이어야 하지만, 대부분의 회사는 **지나친 피드백과 역할 분산**으로 속도 저하를 겪음 - PostHog는 **“당신이 드라이버다(You're the Driver)”** 라는 가치 아래, **자율과 높은 오너십**을 강조하고 **불필요한 협업을 최소화**함 - 협업 과잉의 원인은 **도움이 되고 싶은 마음, 포괄적 문화, 불분명한 피드백 요청, ‘let’s discuss’ 남발, 책임 회피** 등으로 분석 - 해결책은 **즉시 배포를 우선**, **책임자 명확화**, **필요한 사람에게만 피드백 요청**, **출시 후 피드백**, **불필요한 협업 즉시 차단**이라는 실천적 접근 --- ### 협업의 함정 - **"빨리 가려면 혼자, 멀리 가려면 함께"** 라는 말은 회사를 서서히 죽임 - 이는 **과도한 협업을 정당화하는 함정** - 유용한 협업은 **운전 중 방향 안내나 주변 정보 제공** 수준임 - 하지만 대부분의 조직은 **운전대를 돌려가며 잡는 식의 비효율적 협업**에 빠짐 - **적절한 피드백은 목적지에 빠르게 도달하게 하지만, 과도한 피드백은 속도를 늦추고 원하는 곳에 도달하지 못할 위험에 빠지게 함** ### 피드백의 역설 : 피드백을 잘한다는 것은 언제 주지 말아야 할지 아는 것 - PostHog도 성장과 함께 **가치를 더하지 않거나 투입 시간 대비 가치가 너무 적은 협업**이 증가 - 최근 전사 회의에서 "협업은 나쁘다"를 주제로 다룸 - **"당신이 드라이버다(You're the driver)"** 는 PostHog의 핵심 가치: "뛰어난 인재를 고용하고 방해하지 않음" - 데드라인 없음, 최소한의 조율, 매니저가 지시하지 않음 - 그 대가로 **극도로 높은 주인의식과 혼자서 많은 일을 해낼 능력** 요구 - 마케터가 코드 배포, 영업 담당자가 백업 없이 기술 질문 답변, 프로덕트 엔지니어가 전체 스택에서 작업 - 거의 항상 당신보다 더 잘하는 사람이 있어 협업하고 싶은 유혹이 있지만, **협업은 드라이버가 속도를 늦추고 배경, 맥락, 생각을 설명하도록 강제** - 이러한 경향은 몇 가지 주요 표현으로 나타남 - "X가 어떻게 생각하는지 궁금해" - "Y의 의견을 듣고 싶어" - "Z와 함께 작업해야 해" - 이는 **때때로 가치 있는 통찰로 이어지지만, 항상 드라이버의 속도를 늦춤** - 드라이버의 동기, 자신감, 효율성을 침식하고 결국 출시량 감소로 이어짐 ### 협업이 나쁘다면 왜 사람들은 그것을 하는가 - **모두가 원인 제공자** - **사람들은 도움이 되고 싶어함**: 누군가 슬랙에 진행 중인 작업을 올리면, 피드백 문화 때문에 다른 사람들이 피드백을 줘야 한다고 느낌 - 반대로 **특정인에게 피드백을 요청하는 것이 포괄적이지 않다고 느껴져** 요청하지 않음 (실제로는 도움이 될 텐데도) - **어떤 피드백이 필요한지 충분히 구체적이지 않음**: 협업이 끼어들 여지를 만듦. 특정 기능 구축에 대한 논의가 전체 제품 로드맵 재평가로 확대될 수 있음 - 누군가 좋은 아이디어를 내면 **"그것을 해라"가 아니라 "논의하자"가 기본 반응** - 증거로 슬랙에 "let's discuss" 가 수없이 남발 - 이는 실행 대신 논의로 전환됨 - 사람들은 너무 바빠서 실행할 수 없거나 귀찮아서 **그냥 이야기하고 싶어함** - PR → 이슈/RFC → 슬랙(현재 대부분 여기) → "논의하자"로 이동 - **누가 주인인지 명확하지 않음** (또는 아무도 논의 중인 것을 소유하고 싶어하지 않음) - 짜증나지만 때로는 **한 사람이 처음부터 끝까지 충분히 높은 품질로 Shipping 할 수 없고**, 그냥 Shipping하고 반복할 수 없는 경우도 있음 - 깨진 코드는 고칠 수 있지만 **뉴스레터는 재발송할 수 없음** ### 협업을 무너뜨리는 방법 (그리고 더 빠르고 멀리 가는 방법) - 협업을 적으로 간주한다면, 어떻게 물리칠 것인가 - **기본은 실행 우선**: Pull request > Issue > Slack 메시지 - 협업이 과도할 때는 “**너가 운전자야, 결정해**” 라고 명확히 선 긋기 - 피드백은 **누구에게 구체적으로 무엇을 원하는지 태그**하고, 그냥 공허하게 던지지 말 것 - 출시 전 리뷰보다 **출시 후(다음 반복 전) 피드백 제공 선호**: 사전 피드백은 유사 승인 프로세스로 변할 수 있음 - 리더는 피드백을 자제하고 **‘그냥 해보라(you can just do stuff)’는 태도** 유지 - 각자는 **‘정보를 가진 선장(informed captain)’** 으로서 - 피드백을 들을 수는 있으나 **결정은 본인이 내림** ### 결론 - 모든 협업을 뿌리 뽑을 수는 없으며, 일부 협업은 유용함(이 뉴스레터를 Ian과 Andy가 편집함) - 하지만 **기본적으로 협업을 줄이려는 노력**이 필요 - **적극적으로 협업을 줄이려 하지 않으면, 기본적으로 너무 많이 협업하고 있을 가능성**이 큼 - 협업은 본질적으로 속도를 늦추기 때문에, **적게 협업할수록 더 멀리, 더 빠르게 갈 수 있음** * (거품은 너무 협력적이어서) 탄산수를 싫어하는 Charles Cook이 작성함 ## Comments ### Comment 46286 - Author: shakespeares - Created: 2025-11-13T14:26:28+09:00 - Points: 1 같이 일하는게 맞습니다. 그 사람이 부재(사망, 병환, 휴가)하면 클라이언트 대응을 안하나요? ### Comment 46281 - Author: carnoxen - Created: 2025-11-13T13:33:13+09:00 - Points: 1 저는 너무나도 영세한 기업에 다니고 있어 근무자가 저 혼자에요. 그래서 혼자 유지보수하고 혼자 개발하는데.... 너무 오랫동안 이 상태라 사람하고 같이 일하고 싶다는 기분도 들어요. 혼자 일하는 것은 너무 외로워요... ### Comment 46271 - Author: jjpark78 - Created: 2025-11-13T10:54:32+09:00 - Points: 1 어그로가 너무 강한 글이네요. 글쓴이의 개성이 너무 두드러져서 다른 사람들과 잘 어울리지 못하는게 아닌지? 하나의 기능을 만드는데 디자이너, 기획, 프로젝트 매니저, 프론트, 백엔드, QA등등의 롤이 반드시 필요하기 마련인데 ### Comment 46270 - Author: coremaker - Created: 2025-11-13T10:42:06+09:00 - Points: 1 본인이 인식하는 문제를 드러내기 위해 과도한 주장을 하는 것으로 보입니다. 협업은 아고라 같은 방식으로 진행되는 것을 의미하는게 아닐텐데요. 다만, ‘let’s discuss’ 남발, 책임 회피 이 두가지 요소는 문제가 확실히 있습니다. 하지만 대부분 인사이트 있는 리더나 담당자가 존재하지 않아 발생하는 경우가 많습니다. 이런 것을 위해서 연구하거나, 사람을 키우거나, 채용을 하거나, 솔루션을 사는 것인데 말이죠. 말을 잘 듣는 구성원으로만 팀을 만들어버리면 더 촉발되기도 하죠. 이건 협업 이나 혼자 일하는 것이 만드는 문제는 아닌 것 같습니다. ### Comment 46247 - Author: xguru - Created: 2025-11-12T17:30:59+09:00 - Points: 1 Posthog 는 항상 이런식으로 강한 워딩의 글을 쓴다는 걸 참고해서 보세요. 너무 어조가 강하다 보니 약간 주제를 지나쳐 엇나가는 듯한 글이 종종 보입니다. (탄산수가 얼마나 좋은데!!!) ### Comment 46367 - Author: t7vonn - Created: 2025-11-16T12:06:22+09:00 - Points: 2 - Parent comment: 46247 - Depth: 1 탄산수 그거 하이볼 발사대 아닌가요 크흠 ### Comment 46233 - Author: neo - Created: 2025-11-12T11:33:45+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45892394) - 협업이 일어날 때마다 “사람이 너무 많음, X가 **드라이버**니까 네가 결정해”라고 말하라는 조언이 있었음 하지만 관리자가 “네가 결정해”라고 해놓고 회의에는 안 오고, 나중에 “내가 했으면 다르게 했을 것”이라며 수정하라고 하면 직원들이 떠나게 됨 - 내가 **Apple**을 떠난 이유 중 하나가 이런 일이었음 매니저의 매니저가 늘 이런 식으로 말했는데, 내가 PR을 올리면 결국 전면 **리디자인**을 요구했음 결국 어떤 프로젝트든 처음부터 다시 써야 한다는 걸 알기에 일 자체가 두려워졌음 - 더 나쁜 결과도 있음 상사가 너무 자주 판단을 뒤집으면 팀원들이 일부러 모든 결정을 상사에게 떠넘기게 됨 결국 상사는 스스로의 **통제 욕구**에 질식하게 됨 - 이 조언은 “출시 후 피드백을 주라”는 원칙과 충돌하는 것 같음 하지만 “관리자가 지시하지 말라”는 맥락에서는 일관성이 있음 - 예전 직장에서 “what about…”이라는 말이 **트리거 단어**가 되었음 끝없는 픽셀 조정, 레이아웃 수정, 전면 스택 리워크 제안이 이어졌기 때문임 - “직원 잃는 좋은 방법이네”라는 말에 농담처럼 “좋은 방법이라니, 메모해야겠음”이라 반응함 - 문제의 핵심은 협업이 아니라 **의사결정 구조**라고 생각함 피드백은 학습의 기회지만, 최종 결정을 누가 내리는지가 불분명하면 속도가 느려짐 빠른 결정을 위해서는 **결정권자**를 명확히 하고, 대부분의 결정은 되돌릴 수 있다는 인식을 가져야 함 - 이게 핵심 통찰임 협업이 줄면 배우는 기회도 줄어듦 결정권자는 명확히 지정되어야 하지만, 피드백을 경청해야 함 또한 **되돌릴 수 있는 결정**은 빠르게 내리는 게 좋음 협업이 속도를 늦춘다고 하지만, 사실 그 과정에서 품질이 올라감 - 피드백이 진심에서 나온다면 좋지만, 일부 회사에서는 피드백이 **권력 게임**이 됨 일부는 반대를 위한 반대를 하며, 결국 아이디어의 **소유권**을 빼앗으려 함 - 비기술적인 사람이 최종 결정을 맡는 경우, 회의가 많아질수록 “위원회식 설계”로 흐름 최종 결정자가 명확해도 의견이 약하면 결국 다수의 합의로 흘러감 - PR 리뷰를 개인 취향으로 **하이재킹**하는 동료도 있었음 “변경 요청”을 걸면 모두가 그걸 따라야 했고, 결국 코드 품질이 나빠짐 좋은 사람을 뽑고 **결정권을 위임**하는 게 훨씬 낫다고 생각함 - 좋은 리더는 직접 결정하기보다 **자율적 결정의 수를 늘리는 사람**임 방향성, 우선순위, 프레임워크를 제시해 팀이 스스로 판단할 수 있게 해야 함 - 글쓴이의 **탄산수 혐오**에는 동의하지 않지만, 협업 문제를 공개적으로 다루는 건 반가움 여러 회사에서 코드 리뷰 중 **사소한 스타일 지적** 때문에 실제 구현보다 3배의 시간을 쓴 적이 있음 “그게 마음에 안 들면 직접 고치고 알려줘라”는 입장임 [관련 영상](https://www.youtube.com/shorts/DjvVN4Vp_r0)도 공유함 - 포매터를 빌드 파이프라인에 넣으면 스타일 문제는 자동으로 해결됨 코드 리뷰 단계에서 다루기엔 너무 늦음 - 대부분 회사는 자동 포매터를 쓰기 때문에, 이런 문제는 주로 **이름짓기나 코드 구조** 수준임 주변 코드 스타일에 맞추지 않는 사람이 문제임 - PR에서 사소한 부분을 트집 잡는 건 협업이 아님 **린터**나 문화로 해결해야 함 - “무엇이 사소한 지적이고, 무엇이 필수적인 코드 청결 유지인지”는 결국 팀이 정해야 함 - 기능은 자산이 아니라 **부채**임 협업 없이 혼자 만든 기능은 유지보수 시 큰 리스크가 됨 내가 없을 때 시스템이 터지면, 협업의 부재가 문제로 드러남 - 글쓴이는 행동 편향을 강조하지만, 협업을 배제하면 **사일로와 과신**이 생김 “나는 X를 하려 함, 강한 반대 있나요?” 식으로 묻는 **슬랙 문화**가 효과적이었음 - 이 접근의 힘은 “예/아니오”로 답할 수 있게 **프레이밍**한 데 있음 그래서 일이 실제로 진행됨 - 예전에 **GitHub** 관련 책을 쓰며 인터뷰했는데, 일부 팀은 코드 작성 전 **빈 PR**을 올려 설계 승인을 받았음 이는 진행 중 협업이 아니라 **계획 단계 협업**임 좋은 글쓰기와 커뮤니케이션이 있다면 협업은 빠르고 효과적임 AI 시대에는 이런 능력이 더 중요해질 것임 - 나이가 들수록 “결과보다 **가시성**이 중요하다”는 걸 깨달음 회의와 공유가 없으면 공로가 보이지 않음 문제를 예방하면 아무도 모름, 그래서 일부러 “문제가 생기게 두는” 문화도 있음 - 우리 팀도 중요한 변경에는 사전 회의를 했는데, 덕분에 **시간 낭비를 크게 줄였음** - 사실 이런 방식은 **SCRUM**의 기원과 비슷함 - 하지만 나는 코드를 실제로 써봐야 구조가 보이는 타입임 계획만으로는 구현을 상상하기 어려움 - 결국 그건 **디자인 문서**와 다를 바 없음 - 글의 마지막 문장처럼 “좋은 협업은 존재함” 제목은 클릭베이트지만, **PostHog**가 원래 이런 스타일로 유명함 - 클릭베이트조차 **빠르게 쓴 용감한 드라이버**의 산물이라 농담함 - 익숙한 개념을 새롭게 포장하는 건 유용함 “협업”이라는 밈을 비판적으로 보게 만듦 - 문제의 본질은 **위원회식 설계**임 - 이 글은 잘못된 사고 실험임 문제는 협업이 아니라 **결정권 부재**임 한 명이 명확히 결정해야 하고, 그 권한을 아래로 내릴수록 속도가 빨라짐 - 동의함. 결정권자가 없으면 모든 게 멈춤 이런 글은 언어를 왜곡해 필요한 개념을 **무가치하게 만드는 독성**이 있음 - 하지만 결정만의 문제는 아님 누군가 막히면 바로 “Bob에게 물어봐”라고 하는 문화도 문제임 단기적으로는 빠르지만, 장기적으로는 **학습 기회 상실**과 **업무 과부하**를 초래함 - 나는 동료들이 내 일에 관심을 갖는 걸 좋아함 “네가 알아서 해”는 사실상 “난 관심 없어”라는 뜻임 문제는 협업이 아니라 **비효율적 협업**임 - 글은 일부러 **핫테이크**로 쓰였지만, 3~4명 이상이 모이는 회의는 대부분 시간 낭비임 PR은 구체적인 산출물이 있어 논의가 명확해짐 - 협업은 두 명일 때 가장 잘 작동한다고 느낌 두 사람은 코드베이스를 함께 이해하고 서로의 PR을 검토할 수 있음 하지만 세 명 이상이 되면 **조합적 복잡성**이 폭발함 그래서 나는 프로젝트를 **2인 팀 구조**로 설계하고 싶음 - 이건 사실상 **Amazon의 Two-Pizza Team** 개념임 [참고 링크](https://martinfowler.com/bliki/TwoPizzaTeam.html) - 글의 비유처럼, **F1 레이싱**은 극단적으로 협업적인 스포츠임 드라이버는 경기 내내 코치와 교신함 소프트웨어에서 이런 사례가 있을까 궁금함 - **페어 프로그래밍**이 그 예시임 - 혹은 **크로스펑셔널 팀** - 또는 **GitHub Copilot** ### Comment 46299 - Author: slowandsnow - Created: 2025-11-14T00:23:32+09:00 - Points: 6 댓글들 이상하네요. 글 요약 보면 혼자 일 하라, 팀원이 필요없다가 아니라 팀원 간의 과도한 협업을 줄이자는 거 같은데 ### Comment 46346 - Author: t7vonn - Created: 2025-11-15T10:34:30+09:00 - Points: 1 - Parent comment: 46299 - Depth: 1 동의합니다 ### Comment 46391 - Author: guarder - Created: 2025-11-17T09:25:49+09:00 - Points: 3 - Parent comment: 46299 - Depth: 1 어그로 끄는 제목과 정독하지 않은 독자가 결합된 결과 같네요 ### Comment 46360 - Author: ndrgrd - Created: 2025-11-16T05:40:05+09:00 - Points: 2 - Parent comment: 46299 - Depth: 1 이런 글 뿐만 아니라 유튜브조차 제목만 보고 댓글다는 사람들 많더라구요. ### Comment 46328 - Author: joone - Created: 2025-11-14T16:38:59+09:00 - Points: 2 어떤 새로운 일을 시작하다 보면 너무 안전하게 가려고, 과도하게 주변에 리뷰를 요청할 수 있습니다. 사실 주변 사람이나 팀은 해당 내용을 잘 몰라서 좋은 피드백을 주기도 힘들 수도 있죠. 결국 일단 뭔가 만들어서, 비록 잘못된 방향일지라도, 그 다음에 구체적인 피드백을 받고 다시 작업해도 전체적으로 시간을 절약할 수 있다는 이야기 같습니다.