▲

나쁜 프로젝트를 왜 시니어 엔지니어들은 그냥 두는가

 (lalitm.com)
1P by GN⁺ 7시간전 | ★ favorite | 댓글 1개
  • 시니어 엔지니어는 ‘옳음’보다 ‘효과적 행동’을 중시, 모든 잘못된 프로젝트를 막으려 하지 않음
  • ‘나쁜 프로젝트’ 는 기술적·정치적·UX적 문제를 포함하며, 종종 주관적 판단에 따라 달라짐
  • 영향력은 은행 계좌처럼 관리해야 하며, 자주 반대하면 신뢰를 잃고 ‘정치적 파산’ 상태에 빠질 수 있음
  • 개입 여부는 프로젝트의 거리, 팀 영향, 회사 전체 피해 규모에 따라 결정
  • 모든 문제를 해결하려 하기보다 전략적으로 개입 시점을 선택하고, 나머지는 관찰과 대비로 대응

나쁜 프로젝트의 정의와 사례

  • ‘나쁜 프로젝트’는 불필요한 문제 해결, 복잡한 설계, 정치적 동기 등 다양한 형태로 나타남
    • UX 측면에서는 존재하지 않는 문제를 해결하거나 기존 흐름을 깨뜨리는 경우
    • 기술적으로는 과도한 복잡성, 잘못된 라이브러리 선택, 비효율적 아키텍처
    • 정치적으로는 승진이나 유행 추종을 위한 프로젝트
  • 프로젝트의 좋고 나쁨은 시간이 지나야 드러나는 주관적 판단이며, 초기에는 명확하지 않음
  • Google에서의 사례로, 플랫폼 팀이 핵심 사용자 흐름을 다른 팀에 넘기려 한 프로젝트가 정치적 이유로 실패
    • 기술적으로는 훌륭했지만, 조직 간 권한 문제로 2년 후 폐기됨
    • “정치와 문제 정의의 정확성은 기술적 완성도만큼 중요함”이라는 교훈 제시

모든 나쁜 프로젝트를 막을 수 없는 이유

  • 소프트웨어 기업은 ‘빠른 실행’ 편향이 강해, 우려 제기는 속도를 늦추는 행위로 인식됨
    • 따라서 큰 문제로 인식되지 않으면 무시될 가능성 높음
  • 반복적인 반대는 ‘부정적 인물’로 낙인찍히며, 예방한 실패는 인정받지 못함
  • 반대는 타인의 승진이나 고위 임원의 프로젝트에 영향을 줄 수 있어 정치적 위험 존재
  • 한 명의 엔지니어가 감당할 수 있는 주의력은 한정적이며, 모든 문제에 개입하면 냉소적으로 변함

영향력을 ‘은행 계좌’처럼 관리

  • 영향력은 성과와 협업으로 축적되는 자산이며, 반대할 때마다 인출됨
    • $5 체크: 코드 리뷰 수준의 사소한 지적
    • $500 체크: 아키텍처 결정이나 일정에 대한 반박
    • $50,000 체크: 임원급 프로젝트 중단 시도
  • 사소한 문제에 반복적으로 개입하면 큰 사안에 대응할 여력 상실
  • 영향력이 고갈되면 회의 초대 제외, 의견 무시 등 ‘정치적 파산’ 상태로 전락

개입 시점 판단 기준

  • 전문성 검증: 자신의 판단이 충분히 근거 있는지 확인
  • 발언의 한계 인식: 의견 제시는 ‘명령’이 아니라 ‘관점 공유’임
  • 세 가지 판단 요소
    • 근접성(Proximity): 자신의 팀과 가까울수록 개입 비용이 낮음
    • 팀 영향(Team Impact): 실패 시 팀에 직접적 피해가 예상되면 개입 가치 높음
    • 회사 규모(Company Scale): 실패가 조직 전체에 미치는 영향이 크면 개입 필요

나쁜 프로젝트에 대한 대응 방식

  • 직접 개입: 프로젝트 중단을 요구하거나 강한 우려 문서를 제출
    • 확신과 리스크 감수 필요
  • 부분 개입: 설계 방향을 조정하거나 더 나은 해결책으로 유도
    • 협력적 태도로 접근 시 ‘도움 주는 사람’으로 인식 가능
  • 비개입: 정치적 관성이나 영향력 한계로 개입 가치가 낮을 때
    • 팀이 관련 있다면 의존도 축소나 대안 구축 등 대비책 마련
    • 관련 없을 경우 조용히 관찰하며 내부적으로만 의견 공유
  • 팀 관리: 구성원에게 현실을 솔직히 공유하되, 불필요한 정치적 세부사항은 배제

결론

  • “옳음과 효과성은 다르다” 는 인식이 핵심
  • 대기업에서는 논리보다 정치와 맥락이 작동하며, 모든 잘못을 바로잡을 수 없음
  • 영향력과 신뢰를 전략적으로 사용해 실제 변화를 만들 수 있는 순간에 집중해야 함
  • 나머지 경우에는 동료와 공유하고, 대비하며, 관찰을 통해 학습
  • 완벽히 해결하지 못하더라도, 이 접근이 지속 가능한 방식임
▲
GN⁺ 7시간전  [-]
Hacker News 의견들

  • 예전에 한 매니저가 “가끔은 사람을 실패하게 놔둬야 한다”고 말했던 게 떠오름
    어떤 사람들을 계속 떠받치는 데 너무 많은 에너지가 들었음. 언젠가는 스스로 헤엄치길 바랐지만, 때로는 그 노력이 더 나은 곳에 쓰이는 게 맞았음
    내 참여 없이 진행된 프로젝트가 있었는데, 내 지식 없이는 절대 성공할 수 없었음. 그 팀은 너무 형편없어서 질문을 일처럼 섞어가며 일했음
    게다가 경영진이 내 팀을 깎아내리고 그들을 칭찬한다는 걸 알게 되었을 때 정말 모욕감을 느꼈음. 그들의 구현은 끔찍했음

    • 나는 “가끔은 매니저를 실패하게 놔둬야 한다”고 자주 말함
      어떤 매니저들은 자신의 아이디어가 안 통한다고 말하는 걸 싫어함. 반박하면 실패의 원인으로 몰림
      그래서 나는 일을 진행하되, 그들에게 자주 상황을 공유함. 그래야 그들이 예상된 실패를 직접 보게 되고, 나를 실패와 분리시켜줌
    • 경영진이 실패하면 서로를 탓하지 않음. 대신 컨설턴트를 불러 시니어 엔지니어를 해고함
    • “사람은 스스로 데이터를 모아야 한다”는 말을 들은 적 있음. 결국 직접 부딪혀봐야 배움
    • 사람의 실패와 프로젝트의 실패는 다르다고 생각함
      개인의 실패는 비용이 적고 교육적임. 오히려 그들의 접근이 통할 때도 있어 조직이 새로운 지식 자산을 얻기도 함
    • 사람을 스스로 배우게 두는 건 위험한 일임. 그들이 자기 인식을 갖고 있는지, 내 지원에 기대고 있지 않은지 믿어야 함
      실패하고 배우지 못할 수도 있음. 하지만 최선을 다했다면 양심의 평안은 가질 수 있음

  • 프로젝트의 “나쁨”은 대부분의 생애주기 동안 주관적임
    외부인이 프로젝트를 반대하며 중단시키려 한 적이 있었는데, 끝내 출시해 성공하자 그들의 신뢰가 무너졌음
    평판을 어디에 쓸지 신중해야 함

    • 나도 비슷한 일을 겪었음. 협업을 위한 조직에서 이렇게 노골적인 이기심을 본 건 처음이었음
      세상은 항상 햇살과 무지개로 가득하지 않다는 걸 알지만, 그때는 정말 실망스러웠음

  • “내 원숭이 아님, 내 서커스 아님”이라는 말처럼, 내 책임이 아닌 일엔 관여하지 않음
    아키텍트로 일할 때도 내 영역이 아닌 UI나 비즈니스 로직엔 불필요한 조언을 하지 않았음
    상위 매니저가 결정한 일엔 그냥 따름. 컨설턴트로 일하면서도 같은 원칙을 지킴
    내 전문 분야에서만 조심스럽게 개입함. 그것도 C-suite의 승인이 있을 때만 함

  • 이 조언은 중소기업엔 꽤 적절함. 하지만 대기업에선 프로젝트에 반대 의견을 내는 게 거의 의미 없음
    성공하면 바보처럼 보이고, 실패해도 기억되지 않음
    진짜 ROI는 실패 후 해결책을 제시할 때 생김. 사람들은 “문제 해결사”를 좋아함
    예전에 자동화된 E2E 테스트를 제안했다가 거절당했는데, 나중에 문제가 터지자 그 프레임워크를 꺼내와 영웅 취급을 받았음

    • 회사에서 위로 올라갈수록 남의 잘못에 책임을 져야 하고 보상은 적음
      차라리 하위 직급에서 스트레스 없이 사는 게 현명하다고 느낌
    • 스타트업은 몇 명의 엔지니어가 “이건 말도 안 돼”라고 말하면 재앙을 막을 수 있음
      반면 대기업은 정치 때문에 수년과 수백만 달러를 낭비함

  • “문제를 무시하면 안 된다”는 입장임
    도울 수 있는 위치라면 조용히라도 다른 접근법을 제안해야 함. 굳이 감정적으로 대응할 필요는 없음

    • “도울 수 있는 위치”라는 조건이 핵심임
      작은 조직에선 좋은 아이디어가 쉽게 반영되지만, 큰 조직에선 정치적 리스크가 훨씬 큼
      실제로 도울 확률보다 평판을 잃을 확률이 더 높음. 그래서 싸움을 고르는 게 중요함
    • 작은 조직에선 초기에 개입하는 게 의무일 수도 있음
      하지만 큰 조직에서 이미 진행 중인 프로젝트를 바꾸려면 막대한 시간과 에너지가 듦
    • “나쁜 프로젝트를 그냥 두라”는 표현은 오해의 소지가 있음
      사실 우리는 그 프로젝트를 통제할 수 없을 때가 많음. “다른 팀이 왜 그렇게 하는지 모른다”가 더 정확한 제목임
    • 나도 실패가 예상되면 문서로 의견을 남기고 끝냄
      프로페셔널리즘이란 말해야 할 때 말하는 것임. 하지만 경험상 바뀌는 일은 거의 없음
    • 알고 있다면 말하되, 그 후엔 감정적 부담을 지지 않음. 조언을 무시당했다면 그건 내 문제가 아님

  • 지금 실제로 이런 상황을 보고 있음
    사업주가 비용과 속도 때문에 로우코드 플랫폼을 선택했는데, 결국 거대한 해킹 수준의 커스터마이징이 필요해짐
    내 팀은 TypeScript로 하루에도 여러 번 배포하지만, 그 팀은 한 달에 한 번 배포하며 curl로 이상한 짓을 하고 있음

  • 이 조언은 빅테크의 정치적 현실에선 훌륭하지만, 결국 기업적 평화주의 같음
    다른 환경에서는 돈과 동기를 태워버릴 여유가 없음
    (그래도 Lalit은 복잡한 조직 역학을 짧은 글에 잘 담음)

    • 나는 빅테크에서 일해본 적 없지만, 작은 조직에서도 같은 현상을 봄
      계속 트집 잡는 사람은 결국 부정적인 사람으로 낙인찍힘
      결국 중요한 순간을 위해 에너지를 아껴두라는 게 핵심 조언임. 모든 문제가 회사의 존망을 좌우하진 않음
    • 평화주의는 무행동이 아님. 오히려 가장 적극적이고 효과적인 정치적 행동임

  • 엔지니어는 정치적으로 나쁜 프로젝트를 “실패하게 놔둘” 권한이 없음
    그건 경영진의 책임임. 엔지니어는 기술적 조언만 하면 됨
    다만 이런 역학을 이해해야 커리어에 영향받지 않음
    제품팀과 플랫폼팀의 영역 다툼은 명확한 리더십의 부재 때문임
    이런 일이 왜 자주 일어나는지 궁금하다면, Google 관련 글을 참고할 만함

  • 이런 사고방식은 대형 조직, 특히 정부 기관에서 흔함
    비용은 다른 부서가 부담하고, 관리 인원 수로 권력을 측정하는 구조임
    이런 조직적 괴사를 막으려면 리더가 명확한 측정과 예방 체계를 세워야 함

    • 인간은 본능적으로 긍정적인 사람을 좋아하고 부정적인 사람을 싫어함
      정치적 자본을 무시한다고 사라지지 않음

  • 좋은 비유임
    리더십과 신뢰를 쌓으면 “당신이 틀렸다”고 말할 수 있는 공간이 생김
    하지만 리더가 항상 엔지니어를 믿지 않는 이유는, 때로는 엔지니어가 틀리기 때문임
    엔지니어는 결함을 찾는 데 뛰어나지만, 비즈니스 맥락을 이해하는 데는 약함
    그래서 “멍청해 보이는 아이디어”라도 맥락을 이해한 뒤 판단해야 함
    진짜로 죽여야 할 아이디어와 그냥 결함이 있는 아이디어를 구분할 수 있을 때, 조직 내 신뢰를 얻게 됨

답변달기