시니어 엔지니어가 나쁜 프로젝트가 실패하도록 내버려 두는 이유

이 글은 시니어 엔지니어가 좋지 않다고 판단하는 프로젝트에 대해 섣불리 개입하지 않고, 전략적으로 접근하는 이유를 설명합니다. 옳다고 해서 무조건 말하는 것이 아니라, 영향력을 현명하게 사용하여 효과적인 결과를 만들고, 팀과 회사에 미칠 파급력을 고려하여 언제, 어떻게 개입할지 결정하는 것이 중요하다고 강조합니다.

1. 옳음과 효과적임의 차이

주니어 엔지니어 시절에는 시니어 매니저가 특정 프로젝트의 문제점을 알고 있으면서도 왜 직접 나서서 말하지 않는지 궁금해했습니다. 하지만 시간이 흐르고 본인이 시니어 엔지니어가 되면서, 멘티로부터 똑같은 질문을 받게 되었고, "옳은 것과 효과적인 것은 다르다"는 점을 깨달았다고 합니다. 대기업에서는 '나쁜 프로젝트'에 대해 목소리를 내는 것이 좋지만, 너무 과하면 오히려 역효과가 날 수 있습니다. 때로는 듣지 않는 사람들과 논쟁하는 것보다 조언을 아끼는 것이 시니어의 지혜로운 선택이기도 합니다.

2. '나쁜 프로젝트'란 무엇인가?

저자가 말하는 '나쁜 프로젝트'는 다음과 같이 다양한 형태로 나타납니다.

UX (사용자 경험) 측면: 제품을 복잡하게 만들거나, 존재하지 않는 문제를 해결하려 하거나, 기존 작업 흐름을 방해하는 경우
기술적인 측면: 지나치게 복잡한 설계, 잘못된 라이브러리 사용, 성능이 떨어지는 아키텍처
정치적인 측면: 유행에 휩쓸리거나, 주로 승진을 정당화하기 위해 존재하는 프로젝트

프로젝트의 생애 주기 동안 '나쁘다'는 판단은 매우 주관적일 수 있습니다. 소프트웨어 엔지니어링은 주어진 정보로 최선의 결정을 내리는 트레이드오프 게임이기 때문이죠. 하지만 시니어가 될수록 프로젝트에 대한 '감각'이 생기면서, 직감적으로 "이건 말이 안 돼"라고 느끼는 순간이 오는데, 이것이 바로 모두가 명백하게 알기 전에 '나쁜 프로젝트'를 미리 알아채는 신호라고 합니다.

저자는 Google에서 겪었던 경험을 이야기하며, 기술적으로는 훌륭했지만 정치적으로 실패가 예견된 프로젝트를 예시로 들었습니다. 이 프로젝트는 두 거대 조직의 교차점에 있었고, 기술적으로는 매우 정교하고 영리한 아이디어로 가득했지만, 실제로는 한 플랫폼 팀이 핵심 제품 팀에게 주요 사용자 흐름에 대한 통제권을 포기하라고 요구하는 구조였습니다. 저자는 당시 리더에게 "이 프로젝트는 성공할 가망이 없죠?"라고 속삭였고, 리더는 "응"이라고 답했습니다. 모두 기술적으로는 옳은 움직임이었지만, 어떤 리더나 PM도 핵심적인 소유권을 다른 팀에 넘겨주려 하지 않을 것이라는 정치적 현실을 알고 있었던 것이죠. 이 프로젝트는 거의 2년 동안 조용히 진행되다 결국 "전략적 전환"이라는 이메일과 함께 자원이 재할당되고 코드가 삭제되는 운명을 맞았습니다. 저자는 이때 정치적 문제와 올바른 문제 해결이 기술적 아름다움만큼이나 중요하다는 것을 깨달았다고 합니다.

3. 모든 프로젝트를 막을 수 없는 이유

'나쁜 프로젝트'를 알아채고 전문성을 공유하고 싶을 때, 처음에는 직접 나서서 문제를 지적하려는 유혹을 느낄 수 있습니다. 하지만 저자는 직접 개입하는 데에는 여러 가지 대가가 따른다는 것을 깨달았다고 합니다.

3.1. 개입의 비용

행동 편향과 속도 중시: 소프트웨어 회사들은 행동 편향이 강하고, 속도와 출시를 매우 중요하게 생각합니다. 우려는 프로젝트의 속도를 늦추기 때문에, 당신의 우려가 '출시 추진력'을 압도할 만큼 크지 않다면 무시될 가능성이 큽니다.
'부정적인 사람'으로 낙인: 한두 번은 '품질을 지키는 사람'으로 인식될 수 있지만, 너무 자주 문제를 지적하면 '계속 문제만 일으키는 부정적인 사람'으로 비칠 수 있습니다. 예방한 재난에 대해서는 거의 인정받지 못하며, 아무 일도 일어나지 않았기에 사람들은 금방 잊어버립니다.
인간관계 악화: 반대할 때마다 누군가의 승진이나 VP(부사장)의 '애완 프로젝트'에 해를 끼칠 위험이 있습니다. 이는 인맥을 끊고 '적'을 만들 수 있는 위험이 따릅니다.
정신적 소모: 세상에는 당신의 전문 지식이 도움이 될 수 있는 수많은 프로젝트와 엔지니어들이 있습니다. 모든 나쁜 아이디어를 막으려다 보면 지나치게 냉소적이 될 수 있으며, 이는 좋은 상태가 아닙니다.

4. 영향력을 은행 계좌처럼 관리하기

모든 나쁜 프로젝트를 막을 수 없다면 어떻게 해야 할까요? 전략적으로 접근해야 합니다. 당신의 영향력을 은행 계좌처럼 생각하고 관리해야 합니다. 매달 일을 잘하고, 사람들을 돕고, 성공적인 프로젝트를 완료하면서 '영향력'이라는 예금을 쌓아가는 것이죠.

그리고 중요할 때, 이 영향력을 '인출'할 준비가 되어 있어야 합니다. 뭔가에 반대하거나 우려를 제기할 때마다 잔고에서 수표를 발행하는 것과 같습니다. 하지만 모든 수표의 크기가 같지는 않습니다:

5달러짜리 수표: 코드 리뷰에서의 사소한 지적. 저렴하고 매일 발생하는 비용입니다.
500달러짜리 수표: 아키텍처 결정에 이의를 제기하거나 기한에 반대하는 것. 어느 정도의 저축이 필요합니다.
5만 달러짜리 수표: VP의 애완 프로젝트를 막으려는 시도. 엄청난 지출이며, 몇 년에 한 번 정도만 감당할 수 있을 것입니다.

만약 사소한 비효율성마다 5달러짜리 수표를 계속 쓴다면, 정말 중요한 재앙을 막기 위해 큰 수표를 발행해야 할 때 잔고가 비어 있을 것입니다. 잔고가 부족해지면 '정치적 파산'에 이르게 됩니다. 사람들은 당신을 회의에 초대하지 않고, 의견을 묻지 않으며, 당신을 피해 일하기 시작할 것입니다. 파산 상태가 되면 영향력은 0이 되고, 이는 당신의 영향력 행사 능력뿐만 아니라 일을 처리하는 능력 자체에도 해를 끼칩니다.

5. 언제 영향력을 사용해야 하는가?

모든 일에 개입할 수 없다는 것을 받아들였다면, 언제 개입하는 것이 현명한지 파악해야 합니다.

5.1. 겸손하게 전문성 평가하기

가장 먼저 해야 할 일은 겸손하게 자신이 판단할 전문 지식이 있는지 평가하는 것입니다. 시니어는 종종 많은 의견을 가지고 있지만, 그 의견이 항상 정보에 기반한 것은 아닙니다. 예를 들어, 프론트엔드 경험이 있더라도 깊은 전문 지식이 없다면 깊은 조언을 할 자격이 없다고 판단하는 것이 중요합니다.

5.2. 관점의 한계를 인정하기

또한, 당신이 말하는 것이 곧 진실이 아니라는 사실을 받아들여야 합니다. 당신은 특정 관점에 대한 인식을 높이는 것일 뿐, 명령을 내리는 것이 아닙니다. 따라서 어떤 팀이 당신의 우려를 듣지 않고 계속 진행하더라도, 그것을 받아들이고 다음으로 넘어가야 합니다. 결국 당신은 엔지니어이지, 모든 것을 지시할 권한을 가진 CEO가 아니기 때문이죠.

이러한 점들을 고려하여, 저자는 언제 발언할지 결정하는 세 가지 주요 요소를 제시합니다:

프로젝트가 내 팀과 얼마나 가까운가?
- 프로젝트가 당신의 팀 내부에 있다면 비용은 거의 0입니다. 높은 신뢰가 바탕이 되기 때문에 빠른 대화로 해결될 수 있습니다.
- 더 넓은 조직 내에 있다면 사회적 자본과 명성을 걸어야 하므로 비용이 증가합니다.
- 당신의 조직 밖에 있다면 비용은 종종 감당하기 어렵습니다. 영향력이 거의 없고, 보고 체계가 다르며, 프로젝트를 막으려면 엄청난 영향력을 소모해야 합니다.
문제가 발생했을 때 내 팀에 얼마나 큰 영향을 미치는가?
- 다른 조직의 프로젝트가 당신 팀의 작업에 심각한 영향을 미칠 때입니다. 예를 들어, 저자가 작업하는 성능 툴인 Perfetto의 경우, 다른 팀이 복잡한 통합을 요청했을 때 문제가 생기면 당신의 리더십이 책임을 물을 수 있습니다. 이런 경우, 팀을 보호하기 위해 발언하는 것은 매우 중요합니다.
문제가 발생했을 때 회사 전체에 얼마나 큰 문제가 될 것인가?
- 어떤 프로젝트는 독립적이어서 실패하더라도 자체적인 문제로 끝납니다. 하지만 어떤 프로젝트는 핵심 시스템과 너무 얽혀 있어서 실패하면 광범위한 피해를 주거나 몇 년 동안 지속될 기술 부채를 만들 수 있습니다. 이런 프로젝트는 회사 전체의 장기적인 건강에 치명적일 수 있습니다.

6. 나쁜 프로젝트에 대처하는 방법

의견을 제시하는 '때'뿐만 아니라 '방법'도 중요합니다. 상황에 따라 다양한 조치를 취할 수 있습니다.

6.1. 개입할 때

직접적인 중단 요청 (최후의 수단): "이것은 하지 말아야 합니다"라고 직접적으로 말하며 프로젝트를 중단시키려고 시도하는 것입니다. 이는 거의 항상 당신의 리더와 해당 팀의 리더에게까지 확대를 의미하며, 당신이 옳다는 확신과 이 프로젝트가 실제로 해로울 것이라는 강한 신념이 필요합니다. 하지만 당신의 프로젝트나 팀의 존립에 위협이 될 수 있는 경우에는 올바른 행동입니다.
팀에 우려 제기 (위험하지만 부드러운 접근): 직접적인 에스컬레이션 대신, 팀과 회의를 하거나 강한 어조의 '우려' 또는 '반박' 문서를 통해 우려를 제기하는 방식입니다. 목표는 팀 스스로 이 프로젝트가 좋은 생각이 아닐 수도 있다고 결론 내리도록 충분히 강하게 이야기하는 것입니다.
올바른 방향으로 미세 조정 (적은 비용, 높은 ROI): 고수준에서는 합리적이지만 실행 방식이 잘못된 프로젝트에 적합합니다. 예를 들어, Perfetto 팀이 복잡한 사용 방식을 제안할 때, 저자는 팀과 함께 앉아 실제 문제를 이해하고 더 나은 해결책으로 안내합니다. 이는 한 시간의 비용으로 몇 달의 시간을 절약해 주며, 심지어 방해꾼이 아닌 조력자로 인식될 수도 있습니다.

6.2. 개입하지 않을 때

때로는 직접적인 조치를 취할 투자수익률(ROI)이 없는 경우도 있습니다. 정치적 추진력이 너무 강하거나, 문제가 영향력을 소모할 만큼 작을 때입니다. 이럴 때는 당신의 팀이 얼마나 관련되어 있는지에 따라 행동이 달라집니다.

팀의 작업과 많이 겹칠 때: 미묘한 비상 계획을 세우는 것이 좋습니다. 프로젝트에 대한 의존도를 줄이거나, 프로젝트가 중단될 경우에 대비해 추상화를 구축하는 것이죠. 또한, 나쁜 프로젝트에도 좋은 아이디어의 '본질'이 담겨 있는 경우가 있습니다. 만약 당신의 업무와 관련이 있다면, 그 본질을 취해 더 나은 버전의 해결책을 당신의 프로젝트에 자연스럽게 통합하는 것도 좋은 방법입니다. 이렇게 하면 나쁜 프로젝트가 중단되더라도 사태에 대한 반응적 대응이 아닌 주도적인 대응을 할 수 있습니다.
관련이 없을 때: 가장 쉽습니다. 그냥 관여하지 마세요. 친한 동료들과 사적으로 불평하고 공감하되, 공개적으로는 현실을 받아들이고 살아가는 것입니다.

6.3. 팀을 관리하는 방법

마지막으로, 당신의 팀원들이 나쁜 프로젝트를 겪는 과정에서 팀을 잘 관리해야 합니다. 당신이 프로젝트의 결함을 볼 수 있다면, 다른 시니어 엔지니어들도 볼 수 있을 것입니다. 나쁜 프로젝트를 좋다고 가장하며 가스라이팅하거나 '회사 방침'을 따르려 하지 마세요. 신뢰를 잃게 됩니다.

대신, 불필요한 정치적 세부 사항 없이 현 상황에 대해 솔직하게 이야기해야 합니다. 그리고 이러한 제약 속에서도 최선을 다할 것이라고 팀원들에게 말해주는 것이 중요합니다.

결론

저자는 멘티에게 이렇게 말해주었습니다.

"나는 '옳은 것'과 '효과적인 것'이 다르다는 것을 배웠어. 그들에게 내 우려를 말할 수도 있겠지. 아마 듣지 않을 거야. 나는 약간의 호의를 잃을 거고. 그리고 6개월 뒤에는 내가 그 프로젝트를 예견했다는 것을 아무도 기억하지 못할 거야. 그들은 단지 내가 그들의 일을 방해하려 했던 사람이라고만 기억할 뿐이지."

경력 초반에는 좋은 아이디어가 실력만으로 이긴다고 믿고, 명확하게 설명하면 사람들이 이성적으로 생각할 것이라고 기대하게 됩니다. 하지만 대기업은 그렇게 돌아가지 않는다는 것을 받아들이는 데 꽤 오랜 시간이 걸렸다고 합니다.

그렇다고 해서 관심을 끊으라는 뜻은 아닙니다. 당신의 신뢰도를 언제 사용할지 전략적으로 선택해야 합니다. 당신이 실제로 결과를 바꿀 수 있고, 침묵하면 팀이 피해를 볼 수 있으며, 당신이 틀릴 위험은 낮지만 프로젝트가 실패할 위험은 높은 전투를 선택하세요.

그리고 나머지 모든 것에 대해서는 동료들과 불평하고, 조용히 비상 계획을 세우고, 지켜보는 것입니다. 때로는 배우는 것도 있고, 때로는 당신이 틀려서 프로젝트가 실제로 성공하기도 합니다. 그리고 때로는 상황이 어떻게 무너질지 정확히 예측했던 것에 대한 냉혹한 만족감을 느끼기도 합니다.

이 모든 것이 모든 것을 고치는 것만큼 만족스럽지는 않을 것입니다. 하지만 이것이 바로 효과적인 방법이며, 당신의 정신 건강을 지켜줄 것입니다. 😌