Hacker News 의견들

• 내가 30년 넘게 이 일을 하면서 본 건, “마감일(date)”이 항상 결과물보다 중요하게 여겨진다는 점임
  실제로는 그 날짜를 맞추는 게 거의 불가능하지만, 조직은 여전히 그걸 유일한 지표로 삼음
  소프트웨어 개발이 본질적으로 예측 불가능한 활동이라는 점은 거의 고려되지 않음
  애자일 선언문이 처음 나왔을 때는 희망이 있었지만, 곧 “각 단계가 얼마나 걸릴지 정확히 말하라”는 관리 방식으로 변질되었음

  • 내 경험상 진짜 핵심은 날짜보다 예산임
    조금 늦는 건 용서받지만, 돈을 더 달라고 하면 영원히 미움받음
    애자일은 좋은 Product Owner가 적절한 예산과 의사결정 권한을 확보했을 때만 잘 작동함
  • “날짜가 항상 더 중요하다”는 말에서 착안해 Date-bound delivery라는 새 방법론을 생각해봤음
    팀은 기간 내에 가능한 만큼만 납품하고, 마감이 다가올수록 기능을 줄여감
    결과물의 내용보다 납품 자체를 보장하는 방식임
    만약 날짜가 그렇게 중요하다면, 이런 접근도 시도해볼 만하지 않겠음?
  • Spolsky의 인용을 확장하자면 “누군가 대신 청바지 값을 내준다면 얘기가 달라짐”임
    작은 조직일수록 진짜 이해관계자가 존재하지만, 큰 조직에서는 성과와 커리어가 분리되어 있음
    나는 하드웨어 쪽에서 일하며, 내 연말 목표를 “내가 직접 작성한 코드로 시연 가능한 상태”로 정의함
  • 요즘 LLM들도 인간처럼 견적을 부풀려 말함
    “몇 주 걸린다”고 하더니 실제로는 30초 만에 구현함

• 글쓴이가 너무 강하게 말한 것 같음
  아마 협업이 엉망인 팀에서 일한 트라우마가 있을지도 모르겠음
  하지만 잘 운영되는 팀은 분명 존재하고, 집단이 개인보다 더 큰 성과를 낼 수 있음
  피라미드나 Linux 커널, AWS도 혼자 만든 게 아님

  • 나도 예전엔 고성능 팀에서 일했지만 지금은 혼자 일함
    팀이 커질수록 커뮤니케이션 오버헤드가 커지고, 그중 상당수는 관리층의 가시성 욕구 때문임
    좋은 팀은 내부적으로 잘 소통하지만, 관리층도 일정 수준의 가시성이 필요함
    결국 좋은 팀 + 좋은 관리자 조합이 필수임
  • 글의 핵심은 “협업이 이데올로기가 되어 책임감이 사라졌다”는 부분이라고 봄
    대부분의 조직은 협업을 잘하지 못하면서, 그 실패를 협업이라는 말로 덮음
    다만 “작은 팀만이 일한다”는 주장엔 과도한 면이 있음
    피라미드 건설 같은 사례는 현대적 의미의 협업이라기보단 엄격한 지시 체계에 가까움
  • 글쓴이의 시각이 너무 냉소적임
    아폴로 컴퓨터 프로그램은 작은 팀이 만들었지만, 달에 가기 위해선 훨씬 더 많은 협력이 필요했음
    협업이 실제로 효과적이라는 증거는 너무 많음
  • 집단성과 개인성과는 선형적이지 않음
    혼자서는 Assassin’s Creed 같은 대작을 못 만들고, 위원회로는 Stardew Valley 같은 게임을 못 만듦
    서로 다른 종류의 역량임
  • Linux 커널은 실제로 개인별 책임 구분이 명확함

• 나도 글쓴이의 경험에 공감함
  스타트업에서 해고된 뒤 대기업으로 옮겼는데, 처음엔 팀워크가 잘 맞아 성과가 좋았음
  그런데 Agile 코치가 등장해 “협업”을 명분으로 자신의 의제를 밀어붙이기 시작함
  8개월 동안 쓸모없는 워크숍과 권한 다툼이 이어졌고, 결국 유능한 팀이 무기력한 팀에 끌려다님
  무능한 사람을 해고하지 않는 문화가 문제임
  진짜 협업은 서로의 자존심을 내려놓고 경청하며 일할 때 가능함

• 혼자 일하면 더 많은 일을 할 수 있지만, 문제를 잘못 정의할 위험이 큼
  협업은 다양한 관점을 통해 그걸 방지함

  • 하지만 큰 조직에서는 협업이 곧 아무 문제도 해결하지 않는 상태가 되기도 함
    일하지 않는 사람들이 오히려 일하는 사람을 방해함

• 최근 읽은 McEntire의 논문 “The Organizational Physics of Multi-Agent AI” 가 흥미로웠음
  AI 에이전트조차 인간 조직의 정치적 비효율을 그대로 재현함
  결국 조직이 나쁘면 “일에 대한 일(work about work)”만 하게 됨
  작고 책임감 있는 팀이 훨씬 즐겁지만, 재현 가능성이 낮음
  내 블로그 글 Where to Cut에서도 이 주제를 다룸

  • 나도 최근 Team Topologies를 다시 읽고 있음
    역할과 구조가 명확할 때만 오케스트레이션이 제대로 작동함을 느낌
  • 좋은 팀은 대체 불가능(fungible) 하지 않음
    사람을 바꾸거나 팀을 이동시키면 맥락 전환 비용이 생겨 팀의 응집력이 깨짐
  • 네 글이 원문보다 훨씬 명확함
    원문은 무슨 말을 하려는지 잘 모르겠었음
  • “신이 인간을 자기 형상대로 만들었다”는 구절이 훈련 데이터에 들어간 건 의도였을까, 아니면 무분별한 데이터 수집의 부산물일까 궁금함

• 성과를 내는 사람에게 인정이 주어지지 않는 문화가 조직을 좀먹음
  무게를 더 짊어지는 20%는 단지 인정받고 싶을 뿐임
  그걸 주지 않으면 회사는 빠르게 텅 비게 됨

  • 나는 인정보다 팀의 동료애와 보상이 더 중요함
    내가 뭘 하는지도 모르는 사람의 칭찬엔 관심 없음
  • 대부분의 사무직은 원래 공로가 제대로 인정되지 않는 구조로 운영됨

• 이 글은 조직을 넘어 ‘저작권과 주체성’의 사회적 의미로 확장될 수 있음
  복잡하고 고품질의 일은 결국 작은 팀이나 개인의 명확한 책임감에서 나옴
  도스토옙스키나 아폴로 컴퓨터 팀처럼 말임
  반면 “모두가 기여하지만 아무도 보상받지 않는” 협업 유토피아는 현실과 거리가 멂
  인간은 자신의 이름이 걸린 창작물에 더 강한 동기를 느낌

  • 하지만 우리는 모두 이전 세대의 성과 위에 쌓아 올리는 협업 구조 속에 있음
    복잡한 공급망 자체가 또 다른 형태의 협업임

• “80%의 병사가 총을 쏘지 않았다”는 주장이 의심스러워 찾아보니, 이미 오래전부터 반박된 자료였음
  2011년 논문에서도 그 근거가 약하다고 함

  • 병참병까지 포함했는지 혼동이 있었을 가능성이 있음
    미군의 tooth-to-tail 비율을 보면 실제 전투 인원은 4~10% 수준임
    따라서 수치 혼동이 원인일 수 있음
  • 책 On Killing은 훈련 개선으로 사격률이 90% 이상으로 올라갔다고 분석함
    하지만 그만큼 PTSD 비율도 상승했다고 함

• 글 전체가 군인 사례를 사무직 모델로 억지로 끌어온 incoherent한 시도처럼 느껴짐
  하지만 글쓴이에게 좋은 소식이 있음 — 당신도 개인 창작자가 될 수 있음
  Notch나 Stardew Valley 개발자처럼 말임
  불평 대신 직접 무언가를 만들면 됨

  • 그래도 “죽기 싫으면 적을 쏴야 하지 않나?”라는 점에서
    80%가 총을 안 쐈다는 건 여전히 흥미로운 사실임
  • 집단이 커질수록 책임감이 희석되는 현상은 이미 잘 알려진 사실임

• 글쓴이는 성과에 대한 인센티브 설계를 전혀 고려하지 않았음
  Munger의 말처럼 “인센티브를 보면 결과를 알 수 있음”
  협업의 어려움보다 중요한 건, 성과자에게 보상하고 무임승차자를 제재하는 구조를 만드는 일임

  • 하지만 현실의 기술 조직에서 가능한 인센티브는 연봉 인상이나 보너스 정도임
    그것도 많지 않음
  • 인센티브를 대규모로 정렬시키는 게 가능한가 의문임
    가능했다면 이미 우리는 유토피아에 살고 있을 것임