Hacker News

Doing Everyone Else's Job

남의 일까지 대신하기 — 조직을 실제로 굴러가게 만드는 사람들

Yosef Kreinin이 조직에서 '남이 해야 할 일을 대신 해주는 것'의 가치를 논합니다. Intel이 Microsoft 컴파일러에 자사 CPU 지원을 직접 추가했던 사례처럼, 상대의 일을 대신 해주는 행위는 자선이 아니라 자기 이익을 위한 전략이며, 조직의 목표는 결국 이런 일을 하는 소수 덕분에 달성된다고 주장합니다. 다만 사내 구축이나 부서별 자체 구현처럼 headcount를 늘리기 위한 유사 행위는 다른 문제라고 구분합니다.

본문

저자 Yosef Kreinin은 '남의 일을 할 수 있다는 것'이 매우 유용하다는 주장으로 글을 시작합니다. 그들이 어떻게 일하고 무엇을 필요로 하는지 배울 수 있고, 무엇보다 그들이 해주지 않을 일이 필요해졌을 때 직접 해버릴 수 있기 때문입니다.

자선이 아니라 전략 — Intel과 Microsoft의 사례

만든 것을 정작 사용자가 써주지 않는다면, 직접 그들의 시스템에 통합하면 됩니다. Intel이 첫 32비트 CPU를 만들었을 때 자사 직원을 보내 Microsoft의 컴파일러에 해당 CPU 지원을 추가하게 했던 사례가 대표적입니다. 저자는 그 Intel 팀 출신 인물을 직접 만난 적이 있다고 밝힙니다. 많은 사람이 남의 시스템에서 일하는 것을 '직장에서 부르지도 않은 자선'이라며 거부감을 갖지만, Intel이 Microsoft의 일을 해준 것은 어려운 Microsoft를 돕기 위해서가 아니라 Microsoft의 성공에서 이익을 얻기 위해서였다고 반박합니다.

관리자가 실제로 아무것도 관리하지 않는 경우에도 방법은 있습니다. 그의 팀원들에게 가서 '관리'라고 부르지도 않고 공을 가로채지도 않으면서 사실상 관리하면 됩니다. 계층에서 내려오는 명령만 따라야 한다고 배운 사람도 많지만, 그렇게 배우지 않은 '느린 학습자'들이 남아 있고 대부분의 관리자가 그들을 벌주는 데 실패하기 때문에 함께 일할 사람을 찾을 수 있다는 것입니다.

일정 조율보다 패치가 빠르다

사용하는 소프트웨어에 기능이 필요하다면, 상대방의 '고성능 Scaled Agile 계획 프로세스'에 작업을 잡아달라고 부탁하는 것보다 패치를 받아들이도록 설득하는 편이 훨씬 쉽습니다. 이번 분기와 다음 분기 계획은 이미 확정됐고, 다다음 분기 우선순위 논의는 몇 주 뒤에나 가능하다는 식의 계획 프로세스를 풍자합니다. 다만 최근에는 잘 다듬은 패치도 언뜻 보면 임의의 LLM 출력과 구분이 안 돼서 머지가 어려워졌다며, 서로 알게 되면 해결될 문제라고 덧붙입니다.

저자는 20%의 사람이 80%의 일을 한다는 통념을 넘어, 그 일이 궁극적 목표를 달성하는 것은 '남이 해야 할 일을 대신 하는 5% 미만의 사람' 덕분이라고 주장합니다. 그들이 못 하는 이유는 조직의 관점에서는 모두 합법적이지만, 그런 합법적 이유가 누적되면 조직 전체가 죽는다는 것입니다. 이런 일을 하는 사람은 조직이 이를 필요로 할 만큼 나쁘면서도 결국 감사할 줄 아는 경우 — 대부분의 조직 — 보상을 받으며, 조직이 실제로 어떻게 굴러가는지 이해하는 소수가 된다는 간접 보상도 있습니다. 저자는 오히려 '내 일과 너무 멀고 지루하다'는 이유로 손대지 않았던 영역들을 후회한다고 고백합니다. '누군가 알아서 하겠지'라고 생각했다가 예방 가능한 문제에 빠져 허우적댈 때는 지루할 겨를이 없지만 이미 늦을 수 있다는 것입니다.

하지만 이렇게는 아니다 — headcount를 늘리는 유사 행위

시니어들에게 매력적으로 보이지만 실제로는 나쁘게 작동할 수 있는 두 가지가 있습니다. 이들은 자선처럼 보여 거부당하는 게 아니라 headcount를 늘려주기 때문에 오히려 사랑받습니다. 첫째는 사내 구축(in-house) 대 구매입니다. 어떤 조직은 '표준이 좋으니까', 혹은 사람을 뽑는 것보다 돈 쓰는 게 쉬워서 외부 제품을 과도하게 사고, 다른 조직은 비용 승인은 불가능하지만 headcount 늘리기는 쉬워서 과도하게 자체 구축을 합니다. buy vs build는 조직의 구조적 문제와 벤더의 결함, 시장 상황을 정직하게 저울질해야 하는 케이스별 어려운 결정입니다. 둘째는 전사 공통 서비스를 중앙화하는 대신 부서마다 자체적으로 구현하는 경우입니다. 부서 관리자는 자기 산하가 아닌 조직에 의존하는 것을 두려워하고, 그 위의 관리자는 중앙 서비스 부서가 정말 실패한 것인지 다른 부서의 핑계인지를 판단할 필요가 없어지기 때문에 선호됩니다.

Dan Luu의 코멘트 — 창업자의 채용 문제

원고를 검토한 Dan Luu는 '창업자가 채용할 사람의 일을 직접 해봤다면 더 잘 채용한다'는 이야기를 떠올렸다고 전합니다. 그의 성공한 재창업자 친구는 직접 해본 일은 채용이 훨씬 쉽다고 말했으며, 신뢰할 수 있는 사람에게 맡기는 방법도 있지만 사람들은 믿을 사람을 고르는 데 틀리는 경우가 더 많다고 덧붙였습니다. 저자는 팀 단위에서는 통하지만, 팀이 수백 명으로 커지거나 독립 회사가 되면 자신이 도저히 할 수 없는 일을 하는 사람을 관리하는 능력이 병목이 될 것이라고 정리합니다.

Hacker News 반응

  • @proc0 — 같은 월급 받고 일만 더 하라는 소리다. 좋은 아이디어네.
  • @TeMPOraL — 모두를 위해서 말이죠. (죽은 사람들 빼고요.) — Portal의 Aperture Science 슬로건을 빗댄 냉소입니다.
  • @distortionfield — 이런 '라이프해크' 류 조언이 결국 다 이 얘기로 귀결된다는 게 웃깁니다.
  • @proc0 — '남을 위해'를 붙여야 정확하다. 그 경우 그냥 협상을 못 하는 것이고, 특히 소프트웨어 업계에서 회사가 개인보다 협상력이 훨씬 강하다는 게 문제다.
  • @perelin — 무료로 시간을 더 쓰고 퇴근해야 할 때 퇴근하지 않는 경우에만 해당되는 이야기다.

원문: yosefk.com / 번역·요약: Trawling