협업은 쓸모없다

• “혼자 가면 빠르고, 함께 가면 멀리 간다” 는 격언은 스타트업을 망하게 할 수 있음
• 효율적인 협업은 운전 중 내비게이션 도움 수준이어야 하지만, 대부분의 회사는 지나친 피드백과 역할 분산으로 속도 저하를 겪음
• 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이 작성함

[joone]

어떤 새로운 일을 시작하다 보면 너무 안전하게 가려고, 과도하게 주변에 리뷰를 요청할 수 있습니다. 사실 주변 사람이나 팀은 해당 내용을 잘 몰라서 좋은 피드백을 주기도 힘들 수도 있죠. 결국 일단 뭔가 만들어서, 비록 잘못된 방향일지라도, 그 다음에 구체적인 피드백을 받고 다시 작업해도 전체적으로 시간을 절약할 수 있다는 이야기 같습니다.

[shakespeares]

같이 일하는게 맞습니다.
그 사람이 부재(사망, 병환, 휴가)하면 클라이언트 대응을 안하나요?

[carnoxen]

저는 너무나도 영세한 기업에 다니고 있어 근무자가 저 혼자에요. 그래서 혼자 유지보수하고 혼자 개발하는데.... 너무 오랫동안 이 상태라 사람하고 같이 일하고 싶다는 기분도 들어요. 혼자 일하는 것은 너무 외로워요...

[jjpark78]

어그로가 너무 강한 글이네요.
글쓴이의 개성이 너무 두드러져서 다른 사람들과 잘 어울리지 못하는게 아닌지?

하나의 기능을 만드는데
디자이너, 기획, 프로젝트 매니저, 프론트, 백엔드, QA등등의 롤이 반드시 필요하기 마련인데

[coremaker]

본인이 인식하는 문제를 드러내기 위해 과도한 주장을 하는 것으로 보입니다.
협업은 아고라 같은 방식으로 진행되는 것을 의미하는게 아닐텐데요.

다만, ‘let’s discuss’ 남발, 책임 회피 이 두가지 요소는 문제가 확실히 있습니다.
하지만 대부분 인사이트 있는 리더나 담당자가 존재하지 않아 발생하는 경우가 많습니다.

이런 것을 위해서 연구하거나, 사람을 키우거나, 채용을 하거나, 솔루션을 사는 것인데 말이죠.
말을 잘 듣는 구성원으로만 팀을 만들어버리면 더 촉발되기도 하죠.
이건 협업 이나 혼자 일하는 것이 만드는 문제는 아닌 것 같습니다.

[xguru]

Posthog 는 항상 이런식으로 강한 워딩의 글을 쓴다는 걸 참고해서 보세요.
너무 어조가 강하다 보니 약간 주제를 지나쳐 엇나가는 듯한 글이 종종 보입니다.
(탄산수가 얼마나 좋은데!!!)

[t7vonn]

탄산수 그거 하이볼 발사대 아닌가요 크흠

[GN⁺]

Hacker News 의견

• 협업이 일어날 때마다 “사람이 너무 많음, X가 드라이버니까 네가 결정해”라고 말하라는 조언이 있었음
  하지만 관리자가 “네가 결정해”라고 해놓고 회의에는 안 오고, 나중에 “내가 했으면 다르게 했을 것”이라며 수정하라고 하면 직원들이 떠나게 됨

  • 내가 Apple을 떠난 이유 중 하나가 이런 일이었음
    매니저의 매니저가 늘 이런 식으로 말했는데, 내가 PR을 올리면 결국 전면 리디자인을 요구했음
    결국 어떤 프로젝트든 처음부터 다시 써야 한다는 걸 알기에 일 자체가 두려워졌음
  • 더 나쁜 결과도 있음
    상사가 너무 자주 판단을 뒤집으면 팀원들이 일부러 모든 결정을 상사에게 떠넘기게 됨
    결국 상사는 스스로의 통제 욕구에 질식하게 됨
  • 이 조언은 “출시 후 피드백을 주라”는 원칙과 충돌하는 것 같음
    하지만 “관리자가 지시하지 말라”는 맥락에서는 일관성이 있음
  • 예전 직장에서 “what about…”이라는 말이 트리거 단어가 되었음
    끝없는 픽셀 조정, 레이아웃 수정, 전면 스택 리워크 제안이 이어졌기 때문임
  • “직원 잃는 좋은 방법이네”라는 말에 농담처럼 “좋은 방법이라니, 메모해야겠음”이라 반응함

• 문제의 핵심은 협업이 아니라 의사결정 구조라고 생각함
  피드백은 학습의 기회지만, 최종 결정을 누가 내리는지가 불분명하면 속도가 느려짐
  빠른 결정을 위해서는 결정권자를 명확히 하고, 대부분의 결정은 되돌릴 수 있다는 인식을 가져야 함

  • 이게 핵심 통찰임
    협업이 줄면 배우는 기회도 줄어듦
    결정권자는 명확히 지정되어야 하지만, 피드백을 경청해야 함
    또한 되돌릴 수 있는 결정은 빠르게 내리는 게 좋음
    협업이 속도를 늦춘다고 하지만, 사실 그 과정에서 품질이 올라감
  • 피드백이 진심에서 나온다면 좋지만, 일부 회사에서는 피드백이 권력 게임이 됨
    일부는 반대를 위한 반대를 하며, 결국 아이디어의 소유권을 빼앗으려 함
  • 비기술적인 사람이 최종 결정을 맡는 경우, 회의가 많아질수록 “위원회식 설계”로 흐름
    최종 결정자가 명확해도 의견이 약하면 결국 다수의 합의로 흘러감
  • PR 리뷰를 개인 취향으로 하이재킹하는 동료도 있었음
    “변경 요청”을 걸면 모두가 그걸 따라야 했고, 결국 코드 품질이 나빠짐
    좋은 사람을 뽑고 결정권을 위임하는 게 훨씬 낫다고 생각함
  • 좋은 리더는 직접 결정하기보다 자율적 결정의 수를 늘리는 사람임
    방향성, 우선순위, 프레임워크를 제시해 팀이 스스로 판단할 수 있게 해야 함

• 글쓴이의 탄산수 혐오에는 동의하지 않지만, 협업 문제를 공개적으로 다루는 건 반가움
  여러 회사에서 코드 리뷰 중 사소한 스타일 지적 때문에 실제 구현보다 3배의 시간을 쓴 적이 있음
  “그게 마음에 안 들면 직접 고치고 알려줘라”는 입장임
  관련 영상도 공유함

  • 포매터를 빌드 파이프라인에 넣으면 스타일 문제는 자동으로 해결됨
    코드 리뷰 단계에서 다루기엔 너무 늦음
  • 대부분 회사는 자동 포매터를 쓰기 때문에, 이런 문제는 주로 이름짓기나 코드 구조 수준임
    주변 코드 스타일에 맞추지 않는 사람이 문제임
  • PR에서 사소한 부분을 트집 잡는 건 협업이 아님
    린터나 문화로 해결해야 함
  • “무엇이 사소한 지적이고, 무엇이 필수적인 코드 청결 유지인지”는 결국 팀이 정해야 함
  • 기능은 자산이 아니라 부채임
    협업 없이 혼자 만든 기능은 유지보수 시 큰 리스크가 됨
    내가 없을 때 시스템이 터지면, 협업의 부재가 문제로 드러남

• 글쓴이는 행동 편향을 강조하지만, 협업을 배제하면 사일로와 과신이 생김
  “나는 X를 하려 함, 강한 반대 있나요?” 식으로 묻는 슬랙 문화가 효과적이었음

  • 이 접근의 힘은 “예/아니오”로 답할 수 있게 프레이밍한 데 있음
    그래서 일이 실제로 진행됨

• 예전에 GitHub 관련 책을 쓰며 인터뷰했는데, 일부 팀은 코드 작성 전 빈 PR을 올려 설계 승인을 받았음
  이는 진행 중 협업이 아니라 계획 단계 협업임
  좋은 글쓰기와 커뮤니케이션이 있다면 협업은 빠르고 효과적임
  AI 시대에는 이런 능력이 더 중요해질 것임

  • 나이가 들수록 “결과보다 가시성이 중요하다”는 걸 깨달음
    회의와 공유가 없으면 공로가 보이지 않음
    문제를 예방하면 아무도 모름, 그래서 일부러 “문제가 생기게 두는” 문화도 있음
  • 우리 팀도 중요한 변경에는 사전 회의를 했는데, 덕분에 시간 낭비를 크게 줄였음
  • 사실 이런 방식은 SCRUM의 기원과 비슷함
  • 하지만 나는 코드를 실제로 써봐야 구조가 보이는 타입임
    계획만으로는 구현을 상상하기 어려움
  • 결국 그건 디자인 문서와 다를 바 없음

• 글의 마지막 문장처럼 “좋은 협업은 존재함”
  제목은 클릭베이트지만, PostHog가 원래 이런 스타일로 유명함

  • 클릭베이트조차 빠르게 쓴 용감한 드라이버의 산물이라 농담함
  • 익숙한 개념을 새롭게 포장하는 건 유용함
    “협업”이라는 밈을 비판적으로 보게 만듦
  • 문제의 본질은 위원회식 설계임

• 이 글은 잘못된 사고 실험임
  문제는 협업이 아니라 결정권 부재임
  한 명이 명확히 결정해야 하고, 그 권한을 아래로 내릴수록 속도가 빨라짐

  • 동의함. 결정권자가 없으면 모든 게 멈춤
    이런 글은 언어를 왜곡해 필요한 개념을 무가치하게 만드는 독성이 있음
  • 하지만 결정만의 문제는 아님
    누군가 막히면 바로 “Bob에게 물어봐”라고 하는 문화도 문제임
    단기적으로는 빠르지만, 장기적으로는 학습 기회 상실과 업무 과부하를 초래함

• 나는 동료들이 내 일에 관심을 갖는 걸 좋아함
  “네가 알아서 해”는 사실상 “난 관심 없어”라는 뜻임
  문제는 협업이 아니라 비효율적 협업임

  • 글은 일부러 핫테이크로 쓰였지만, 3~4명 이상이 모이는 회의는 대부분 시간 낭비임
    PR은 구체적인 산출물이 있어 논의가 명확해짐

• 협업은 두 명일 때 가장 잘 작동한다고 느낌
  두 사람은 코드베이스를 함께 이해하고 서로의 PR을 검토할 수 있음
  하지만 세 명 이상이 되면 조합적 복잡성이 폭발함
  그래서 나는 프로젝트를 2인 팀 구조로 설계하고 싶음

  • 이건 사실상 Amazon의 Two-Pizza Team 개념임
    참고 링크

• 글의 비유처럼, F1 레이싱은 극단적으로 협업적인 스포츠임
  드라이버는 경기 내내 코치와 교신함
  소프트웨어에서 이런 사례가 있을까 궁금함

  • 페어 프로그래밍이 그 예시임
  • 혹은 크로스펑셔널 팀
  • 또는 GitHub Copilot

[slowandsnow]

댓글들 이상하네요. 글 요약 보면 혼자 일 하라, 팀원이 필요없다가 아니라 팀원 간의 과도한 협업을 줄이자는 거 같은데

[ndrgrd]

이런 글 뿐만 아니라 유튜브조차 제목만 보고 댓글다는 사람들 많더라구요.

[t7vonn]

동의합니다

[guarder]

어그로 끄는 제목과 정독하지 않은 독자가 결합된 결과 같네요