▲

빅테크 회사에서 '일을 끝냈다(Done)'는 것의 진짜 의미

 (seangoedecke.com)
35P by GN⁺ 2일전 | ★ favorite | 댓글 6개
  • 빅테크에서 진짜로 일을 끝낸다는 것은 무한히 개선 가능한 시스템 속에서 회사가 만족하는 상태까지 마무리 짓고, 떠나는 것을 의미함
  • 유능하지만 주도성이 부족한 엔지니어는 계속해서 사소한 개선만 반복하며 진짜 성과를 놓치게 됨
  • 의사결정자에게 눈에 띄는, 명확한 결과물을 전달해야 "일을 한 것"으로 인정받을 수 있음
  • 자신이 하는 일이 상위 관리자에게 읽히고 평가될 수 있는 형태인지 항상 점검해야 함
  • 모든 일을 정리할 수는 없으며, 일정 시점에선 "승리를 선언하고 떠나는 능력"이 핵심 역량이 됨

'일'은 완결될 수 없는 속성을 가짐

  • 수학 문제나 과제와 달리, 현실 세계의 일은 무한히 개선이 가능한 열린 시스템임
  • 서비스 개발은 나무를 심는 일처럼, 이후에도 계속 관리가 필요한 과정임

덫에 빠진 유능한 엔지니어

  • 스스로 모든 일을 감당하며 작고 연속적인 개선만 반복하는 엔지니어는 성과를 내고 있다고 느끼지만
  • 상위 관리자 입장에서는 "회사의 가시적 가치 창출"이 없다고 판단됨
  • 결과적으로 성과 없는 바쁜 사람처럼 오해받을 수 있음

‘끝낸다’는 것의 실제 의미

  • 회사(의사결정자)가 만족하는 지점까지 이르게 하고, 다음으로 넘어가는 것
  • 계속 리팩터링하거나 사소한 개선을 반복하는 대신, 명확한 성과 리스트를 만들어야 함
  • “끝났음”을 선언하고 다음 일로 넘어가는 결단력이 중요함

일의 ‘가독성’ 확보

  • 관리자가 이미 알고 있거나 요청한 프로젝트, 큰 사고 관련 대응은 가독성이 높음
  • 기본적으로 대부분의 기술 작업은 관리자에게는 판단하기 어려운 기술적 잡음에 불과함
  • 따라서, 성과를 눈에 보이는 형태로 만들거나 금전적 효과를 강조하는 등, 읽히도록 조율해야 함

‘끝낸다’는 사회적 개념

  • 철학적으로는 '끝냈다'라는 개념도 사회적 구성물이지만, 현실에서는 매우 실질적인 힘을 가짐
  • 이를 무시하면 평가받지 못하고, 궁극적으로 해고당할 수도 있음

요약

  • 일하고 있다고 해서 끝낸 것은 아님
  • 대부분의 일은 끝날 수 없고, 계속 이어질 수 있음
  • 정원사가 아니라 성과 중심의 전술가가 되어야 함
  • "끝냈다"의 기준은 회사/관리자의 만족
  • "승리 선언 → 떠나기 → 다음 일로"가 핵심 전략
▲
aer0700 2일전  [-]

승리 선언을 할 수 있을 만한 일을 고르는 것도 중요한 기술인 듯 합니다.

답변달기
▲
elbanic 19시간전  [-]

범위를 제한하는 것을 스코핑이라고 합니다. 승리할 수 있도록 스코핑을 잘 하는 것이 능력이죠.

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

한신 vs 소하

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

디테일이 아닌 수치화된 가시적 성과

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 나는 이 글의 주장에 전적으로 반대하지 않음, 하지만 빅테크와 여러 스타트업, 유니콘 기업 등 다양한 곳에서 일한 경험상 너무 실질적인 조언이라고 느껴지지 않음. 지난 10년간, 개발자들의 업무는 너무나도 전문화되어서, 의사결정자와 고객의 니즈와 동떨어져 있음. 이 현상은 Product Manager가 엔지니어와 회사 나머지 사이에 끼어듦으로써 발생함. 나는 항상 가치 있는 결과를 내고자 하지만 실제로 그렇게 하려면 끊임없는 스트레스를 감수해야 함. 내 기여는 반드시 의사결정자와 대화하는 사람의 에고를 거쳐 조정됨. 지난 5년간 유일하게 진짜 성취감을 느낀 적은 9개월간 임시 Product Manager 역할을 맡으면서였음. 그 기간에 우리 팀은 이전에 다른 팀들이 여러 번 실패했던 세 가지 프로젝트를 성공적으로 완수했음. 그 비법은 이해당사자와 실제 대화하여 니즈를 파악한 것이지, 내 방식으로 해보려던 게 아님. 그래서 나는 앞으로도 요구되는 것만 제공하고, 버그에 대해 비난은 받고, 기능에 대한 인정은 받지 못할 것임. 그나마 보수는 괜찮은 편임. 여전히 내가 제대로 기여할 수 있는 곳을 계속 찾는 중임

    • 이 “보수는 괜찮음” 부분이 유독 기억에 남음. 빅테크에서 일할 때 “정체됨” 상태도 그렇게 나쁘지 않다는 내 자신만의 견해가 있음. 예를 들어 Google이나 MS 같은 곳에서 연봉 30만 달러를 받으며 10년간 같은 지루한 프로젝트만 맡아도, 그 경력이 어디서든 인정받음. 예전의 나 같은 야심가는 이런 게 불만일 수 있지만, 그런 성향이면 더 작은 회사로 옮기려고 할 것임. 나이가 들수록 관심사가 회사보다는 가족과 친구로 옮겨감. 만약 누가 나에게 승진이 없을 거라 해도 “그게 뭐?”라고 할 것임. 나는 가족을 위해 충분히 돈을 벌고, 일과 삶의 균형도 챙김. 솔직히 회사에서 가장 좋은 부분은 월급과 그로 인해 나머지 삶이 나아지는 거임
    • Product Manager 직군이 현실에서는 이상적으로 설명되는 것과 달리 실제로는 중간에 끼어서 양쪽을 잘 대변하지 못하는 모습임을 경험함. 그 결과, 직접 제품 관리 역량을 키우게 됐는데, 그 스킬이 헛수고를 피하는 데 정말 유용함. 그래서 큰 엔지니어라면 프로덕트 매니지먼트도 필수 역량이어야 하는지 고민이 됨
    • 한 가지 더 생각해야 할 점은 지금처럼 가면 번아웃으로 가는 길을 걷고 있다는 점임
    • 커뮤니케이션이 어떤 조직에서든 최고의 스킬셋임을 깨달았음. 9개월 임시 업무만으로는 그 진가를 알기엔 충분하지 않음. 글 자체가 다른 엔지니어들과 마찬가지로 너무 짜증난 상태에서 조직의 다른 사람들보다 똑똑하다고 생각하는 것처럼 읽힘. 실제로 그렇지 않은 경우가 많고 이런 마인드셋이 협업에 나쁘게 작용함
    • 어떤 잘 작동하는 웹 애플리케이션 뒤에는 항상 정원사 같은 사람이 있음
    • 왜 Product Manager를 계속하지 않았는지 궁금함
    • 회사에 따라 정말 천차만별임. 엔지니어의 영향력이 더 큰 곳도 많음. 특히 빅테크라고 해도 고객과 분리되지 않은 사례가 존재함
    • Product Manager들을 해고해야 한다는 뜻인가?
    • Product Manager 역할, 즉 엔지니어와 회사 사이를 중재하는 일을 하며 내 기여도 역시 내 에고로 필터링된 건 사실인데, 그게 그렇게 만족스러웠다는 말로 들림… 꽤나 만족스러운 일이었겠음

  • 나는 오직 권력자를 만족시키는 것만을 성공의 기준으로 삼는 것에 근본적 이의를 품음. 우리는 우스꽝스러운 지위 구조에 묶여 있긴 하지만, Jira에서 티켓을 “완료”로 바꾸거나 컴파일러 경고를 없애는 것이 전부는 아니라고 봄. 아무도 “40년간 매번 상사만 만족시켰으니 후회 없다”고 하지 않음

    • 난 40년 중 30년을 일하고 있는데, 상사와 그 상사의 상사들을 만족시키는 것에도 확실히 가치가 있었음. 비록 냉소적 시각이 삶의 전부는 아니지만, 이 냉소적 관점을 알고 있는 건 진실에 가까워짐을 뜻함
    • 사실 “상사와 그 상사의 상사를 만족시키는 것”이 고용의 정의라는 생각임. 누군가가 시키는 걸 해주고 돈을 받는 것임

  • 전반적으로 동의하지만 한 가지 덧붙이자면, 매니저가 원하는 것을 이해하려면 회사의 비즈니스 구조를 파악해야 함. 회사가 돈을 어떻게 버는지, 뭘 가치 있다고 생각하는지 반드시 직접 파악해야 함. 회사의 가치와 일치하는 곳에서 일할 때, 보상도 높고 만족감도 큼. 고객은 물론 영업, 마케팅, 그리고 가능한 한 임원진까지 직접 만나보는 게 중요함. 내부 시스템만 맡아도 그 시스템이 어디에 가치나 보호를 주는지 아는 게 핵심임. 만약 소속 부서가 명확한 가치 창출을 못하면, 가치 있는 팀으로 이동하는 걸 고민해야 함. 회사 니즈와 어긋나는 일은 항상 큰 실수였음

    • 나는 자신을 목수로 생각해도 괜찮다고 봄. 개발은 스펙에 맞게 구현하되, 그 스펙이 말도 안 되거나 불가능할 때는 문제를 직접 지적해야 함. 비즈니스 쪽에서 자기네 일을 명확히 설명 못 한다면, 본인들도 모르는 것임. 게다가 개발자가 비즈니스까지 잘 알 필요가 꼭 있다면, 이에 대한 보상이 반드시 있어야 함. 그럴 시간에 기술적으로 더 발전할 수 있으니 기회비용도 있음
    • “매니저가 정말 비즈니스를 이해하고 배려할 거라”는 전제 자체가 성립 안 되는 경우가 많음

  • 글쓴이가 “의사결정권자에게 보여지는 결과를 내는 것이 필요하다”고 했는데, 나는 이 사람의 “비즈니스” 마인드에 공감함. 많은 개발자들이 자신의 업무가 비즈니스적 효용이 어떻게 되는지 설명할 방법을 몰라 고전함. 리팩터링도 이에 해당됨. 코드 개선이 단기적으로는 전혀 의미 없어 보일 수 있지만, 상황에 따라선 조직에 엄청난 이익을 창출함. 결국 자신의 일이 조직의 수익 혹은 절감과 연결되도록, 그리고 그걸 의사소통할 방법을 고민해야 한다는 것이 핵심임

    • 개발자들이 비즈니스 언어를 배우고, 문제를 비즈니스 인사들이 이해하고 신경 쓰는 방식으로 프레이밍해야 함. 대부분의 비즈니스 결정을 보면 결국 비용 vs 편익임. 실제로 많은 비즈니스맨들도 소프트웨어 자체를 비용 처리함. 즉, “소프트웨어가 어떻게 수익 창출의 중심 아니냐”는 개발자들의 당연한 생각과는 달리, 비즈니스는 소프트웨어 자체에 관심이 없음. 공짜로 팔 수만 있다면 모든 비용이 0이므로 마진은 무한대라는 게 비즈니스맨의 진심임. 영업은 이성보다는 분위기, 관계, 심지어 뇌물로도 성사되는 영역임. 비합리적으로 들려도 이걸 반드시 이해해야 함

  • “위 마음가짐이 많은 엔지니어들이 코드 품질, 테스트, 문서 등에 신경을 안 쓰는 이유일까?”라는 의문이 있음. 만약 높은 분의 즉시 만족만 신경 쓴다면, 누가 오랫동안 유지 가능한 코드를 쓰려 애쓸까? 규격 이상의 품질은 필요 없어도, 최소한의 투자만 해도 수십억은 절약 가능함

    • 점점 더 많은 사람들이 장인정신과 품질에 신경 쓰지 않음. “난 월급 받는 만큼만 일한다”는 목소리가 들리는 상황임. 과거엔 급여와 상관없이 일은 정성껏하는 감각이 있었는데, 그게 많이 사라진 듯함
    • 다들 각자 역할을 맡는 이유가 있음. 영화 제작 현장에서처럼 엔지니어들도 각자 목적이 다를 수 있음. 만약 엔지니어들이 열정을 살리지 못하게 막으면, 돈만 보고 움직이는 사람이 남게 됨. 리스크가 큼
    • 일부러 나쁜 코드를 쓰는 사람은 없다고 봄. 무관심이나 번아웃이 반복 보상받지 못하는 환경에서 생기면, 아무도 추가 노력을 기울이지 않음. 그리고 많은 개발자가 기본적으로 실력이 떨어지기도 함. 보험계리사만큼 고도 경쟁 직업은 아니므로, 아무 배경이나 진입할 수 있고, 애초에 유능해지기 어렵기도 함
    • 많은 Product Manager들은 오직 빠른 속도만 원함. 우리는 테스트와 문서를 원하지만, CFO들은 이런 부가 작업을 “기능이 아니니 필요 없다”며 불필요하게 여김
    • 엔지니어가 회사에 오래 붙어 있기를 전제하지 않으므로 미래 책임을 질 생각이 없음. 수시로 이직하다 보면, 전 직장에서 만든 코드의 문제를 스스로 겪은 적이 없어 실패 경험을 못하고 반복함. 나는 20년 가까이 같은 회사에 있으면서, 늘 반복되는 실수를 봐옴. 본질적 문제는 그대로 둔 채 겉만 바꾸는 변화도 지겹다고 느낌. 진짜 문제를 고치는 게 아닌 이상, 변화의 의미가 없음. 나는 진짜 문제 해결이 목적임

  • 이 현실과 문제점을 익히 경험해 왔고, 이해는 하지만 여전히 이의를 제기함. 많은 프로젝트가 시작되고, “해결 완료, done!”이란 소리와 함께 팀 해체됨. 하지만 제품에는 여전히 이슈가 남고, 기능 추가도 필요하고, 회사는 계속 변화함. 결국 관리 부실로 기술부채만 쌓임. 새로운 매니저가 와서 옛날 프로젝트를 새로 만들고 똑같은 실수를 반복함. 이 방식은 비효율적임. 에어컨 비유로 설명하면, 온도를 계속 끄고 다시 낮추는 것보다 일정하게 유지하는 게 효율적임. 실제로 내가 만든 관리툴은 경영진이 관심 없었지만, 내부 사용자는 500명이 넘을 정도로 필요했음. 유지보수에 큰 시간 투자 없이, 계속 신뢰를 유지하는 것이 중요했음. 방치하면 분산되고, 툴 신뢰성도 사라짐. 몇 분만 들여도 일관성 유지가 가능했음

    • 에어컨 비유는 사실 열역학적으로 틀림. 끈 다음 다시 낮추는 게 더 효율적임

  • 여러모로 혼합된 감정이 있음. 분명 visibility와 승진엔 이 글 말이 맞지만, 실상은 관리자에게 만족만 주라는 관리자 중심적 조언임. 그런데 명확한 방향 제시가 없고, 우선순위가 계속 바뀐다면? 의미 있는 결과를 내기도 어렵고, 관리자-부하 관계가 완전히 “예스맨” 구조가 되어버림. 이런 결과는 별로임

    • 해답은 간단함. 멍청한 상사 밑에서 일한다고 느껴지면 그냥 그만두는 것임. 고생은 일시적이지만, 결국 더 나아짐. 바보에게 내 일을 설명하느라 허송세월하는 것보다 훨씬 나음
    • 반대로, 정말 좋은 매니저와 일하면 “관리자를 만족시키기”만으로도 커리어와 결과물 모두 빨리 성장할 수 있음

  • "unagentic engineer"란, 자율성 없는 엔지니어를 의미함. 만약 엔지니어가 이런 방식으로 일한다면, 비효율적이고 심각한 문제(과도한 클라우드 비용, 보안사고, 고객 불만 등)로 이어질 수 있음. 절대 끝나지 않는 일의 예시로 보안 패치, 실수 수정, 비용 최적화, 고객 피드백 대응을 들 수 있음. 회사가 이 가치를 이해하지 못하면 이직이 답임

    • 글의 요지가 바로 이것임. 어떤 조직은 현실 중심이고 어떤 곳은 지위 중심임. 현실 중심 조직은 장기적으로 합리적이고, 지위 중심 조직은 오로지 상사 만족이 목적임. 제품 품질이나 고객 관계보다 서열이 전부임. 이런 조직이 무너질 필요는 없지만, 결국 한순간 몰락하기도 함
    • “Unagentic”는 자율성(agency)이 없는 직원을 뜻함. 스스로 주도성을 발휘하길 바라지만, 실제로는 개발자가 자신의 존재 자체가 보이지 않게 되는 함정임
    • 꼭 이렇지 않아도 되나, 임원진이 신경을 안 쓰면 기본적으로 이런 문화가 자리 잡음. 예를 들어 나는 인터페이스 디자인의 디테일에 집중하는 걸 즐김. 하지만 이런 배려가 조직에서 가치로 인정될 때만 보상받음. 많은 곳에선 관심도 안 가져줌
    • “unagentic engineer”는 자발적으로 의사결정하고 끌어가는 특성이 부족한, 그냥 흐름에 몸을 맡기는 유형을 뜻함
    • 자율적이지 않은, 즉 판단권이 적은 엔지니어를 칭함
    • “high agency”가 아닌, 즉 똑똑하고 유능해 보여도 항상 지시를 기다리고 스스로 주도하지 못하는 사람을 의미함

  • 나는 "alignment(정렬)" 같은 버즈워드를 극도로 싫어함. 그래도 본질적으로 중요한 개념인 건 맞음. 이상적으로라면 나, 매니저, 그리고 그 위의 경영진까지 무엇이 가장 중요한 일인지 합의해야 함. 만약 그렇지 못하면, 내가 소속된 조직원 입장에선 문제임. 그게 옳은 일인지, 공정한 건지는 몰라도, 우리는 그것에 맞게 살아가는 것임. 결국 위에서 시키는 대로 하는 게 우리가 돈을 받는 이유임. 극소수만이 위에 영향력을 행사할 수 있는 특권을 누림. 그게 바로 so-called "managing up"임

  • 원글이 유용하지만, 더 중요한 핵심들이 빠진 것 같음:

    • 올바른 팀에서 일하는 것이 올바른 일을 하는 것보다 더 중요함
    • 좋은 PM과 매니저가 좋은 업무보다 더 중요함
    • 좋은 보고 체계가 결과의 가치보다 더 중요함
    • 리더십 목표에 맞는 일은 실제 비즈니스 운영 지원보다 훨씬 더 평가받음
    • 직접 다 할 준비가 항상 되어있어야 하고, 대기업 정치에는 협업 비인센티브가 항상 따라다님
답변달기
▲
heal9179 2일전  [-]

이쪽 의견들이 오히려 핵심을 찌르고 있네요

답변달기