▲

협업은 쓸모없다

 (newsletter.posthog.com)
33P by GN⁺ 3일전 | ★ favorite | 댓글 8개
  • “혼자 가면 빠르고, 함께 가면 멀리 간다” 는 격언은 스타트업을 망하게 할 수 있음
  • 효율적인 협업은 운전 중 내비게이션 도움 수준이어야 하지만, 대부분의 회사는 지나친 피드백과 역할 분산으로 속도 저하를 겪음
  • 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 13시간전  [-]

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

답변달기
▲
slowandsnow 1일전  [-]

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

답변달기
▲
shakespeares 2일전  [-]

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

답변달기
▲
carnoxen 2일전  [-]

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

답변달기
▲
jjpark78 2일전  [-]

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

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

답변달기
▲
coremaker 2일전  [-]

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

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

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

답변달기
▲
xguru 3일전  [-]

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

답변달기
▲
GN⁺ 3일전  [-]
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
답변달기