원문: Why Senior Engineers Let Bad Projects Fail — Lalit Maganti
주니어 엔지니어 시절, 매니저는 가끔 주간 1:1 미팅에서 나에게 속내를 털어놓곤 했다. 다른 팀이 진행 중인 프로젝트를 가리키며 이렇게 말했다. "저 프로젝트는 잘 안 될 것 같아. 잘못된 문제를 풀고 있거든." 그때 나는 의아했다. '당신은 엄청 시니어인데, 왜 직접 가서 우려를 말하지 않는 거죠?' 아무 말도 하지 않는 건 그 사람의 영향력을 낭비하는 것처럼 느껴졌다.
그래서 아이러니하게도, 나는 지난주에 동생 팀의 프로젝트가 피벗을 해야 할 것 같다고 멘티에게 설명하고 있는 자신을 발견했다. 그들이 초기에 잘못된 설계 결정을 내렸기 때문이었다. 멘티는 몇 년 전 내가 했던 것과 똑같은 질문을 했다. "왜 그냥 본인 의견을 말하지 않으세요?" 그 이후로 계속 그 생각이 머릿속을 맴돌았다. 나는 이 주제에 대한 내 입장이 세월을 거치며 많이 바뀌었다는 걸 깨달았기 때문이다.
답은 이것이다. 옳은 것과 효과적인 것은 다르다.
대기업에서 '나쁜 프로젝트'라고 생각하는 것에 대해 목소리를 내는 건 좋은 일이다. 단, 적당히. 가끔 시니어의 표식은, 들을 생각이 없는 사람과 논쟁하는 것이 가치 없다는 사실을 깨닫는 것이다. 그럴 때는 조언을 아껴두는 편이 낫다.
나쁜 프로젝트란 무엇인가
내가 말하는 '나쁜 프로젝트'는 여러 종류가 있다.
- UX 측면: 제품을 복잡하게 만들거나, 존재하지 않는 문제를 풀거나, 기존 워크플로우를 망가뜨리는 것
- 기술 측면: 지나치게 복잡한 설계, 잘못된 라이브러리 선택, 성능이 나쁜 아키텍처
- 정치적 측면: 유행을 쫓거나, 주로 승진을 정당화하기 위해 존재하는 프로젝트
중요한 점은, 프로젝트 생애주기의 상당 부분 동안 그것이 '나쁜' 프로젝트인지는 매우 주관적이라는 것이다. 소프트웨어 엔지니어링은 본질적으로 트레이드오프의 게임이며, 완벽하지는 않지만 주어진 정보로 최선의 결정을 내리는 과정이다. 올바른 선택이 내려졌는지에 대한 이견은 항상 존재할 수 있고, 그것이 명확해지는 건 한참 후의 일—프로젝트가 출시된 지 몇 년이 지난 뒤일 수도 있다.
하지만 시니어가 될수록, 소프트웨어 프로젝트에 대한 '감각'이 생기기 시작한다. 그래서 일부 프로젝트를 보면 "이건 말이 안 돼"라는 느낌이 드는 것이다. 이 직감이 바로 나에게 '나쁜 프로젝트'의 신호다. 모두에게 명백해지기 전에 미리 알아볼 수 있는 것.
내 경험 중 가장 기억에 남는 사례는 몇 년 전 구글에 있었을 때다. 두 개의 거대한 조직이 맞닿는 지점에 자리 잡은, 사내에서 '판도를 바꿀 것'이라는 고위급 프로젝트 발표가 있었다. 기술적으로는 정교하고 우아했으며, 정말 어려운 문제들에 대한 영리한 아이디어로 가득했다.
하지만 나는 발표장에 앉아 리드에게 귓속말로 이렇게 말했던 것이 선명하게 기억난다. "이 프로젝트, 성공할 가능성이 없죠?" 리드는 나를 돌아보며 한마디만 했다. "응." 우리 둘 다 문제를 즉시 알아챘다. 그 프로젝트는 전적으로, 플랫폼 팀이 핵심 플래그십 제품 팀에게 자신들의 핵심 유저 플로우 통제권을 포기하도록 요구하는 구조에 기반하고 있었다. 기술적으로는 올바른 결정이었지만, 어떤 리드나 PM도 그토록 중요한 것의 소유권을 다른 팀에게 절대 넘기지 않을 것이었다. 정치적으로, 이 프로젝트는 완전한 공상이었다.
그 프로젝트는 거의 2년 동안 조용히 굴러갔다. 출시에 가까워질 때마다 "아직 준비가 안 됐다"는 이유로 미뤄졌다. 시간이 지나면서 소식은 점점 뜸해졌고, 결국 '전략적 피벗' 이메일이 내 받은편지함에 도착했다. 리소스가 재배치되고 코드는 삭제됐다. 회사는 "이 과정에서 많은 것을 배웠다"고 했지만, 내 눈에는 처음부터 실패가 예정돼 있었던 것으로 보였다. 정치적 맥락과 올바른 문제를 푸는 것은 기술적 우아함만큼이나 중요하다.
왜 모두를 막을 수 없는가
'나쁜 프로젝트'를 알아채기 시작하고, 내가 공유할 전문성이 있다고 느꼈을 때, 나는 그것들을 지적하고 싶은 유혹을 받았다. 해당 팀에 연락해서 "이건 말이 안 돼"라고 말하고, 그 이유를 설명하는 것. 사실과 논리로 설득하는 것.
실제로 그렇게 해봤다. 하지만 이것이 얼마나 큰 비용을 수반하는지 깨닫기 전까지, 잠깐이었다.
첫째로, 소프트웨어 회사는 행동에 대한 고유한 편향이 있다. 속도와 출시를 높이 평가한다. 우려 사항은 정의상 속도를 늦추고, 사람들이 예산을 잡지 않았던 것들을 살펴봐야 함을 의미한다. 그래서 당신의 우려가 '출시를 향한 추진력'을 극복할 만큼 충분히 크지 않다면, 당신이 무언가를 말해서 의미 있는 변화가 생길 가능성은 거의 없다. 사실, 당신은 대체로 무시될 가능성이 높다.
이와 관련해서, 설령 팀이 당신의 우려를 진지하게 받아들이더라도, 너무 자주 하지 않도록 주의해야 한다. 한두 번은 '품질을 지키는 사람'으로 비칠 수 있다. 하지만 너무 자주 하면 금세 '부정적인 사람', 항상 문제를 만드는 자, 문제를 '해결'하는 자가 아닌 사람으로 인식된다. 당신이 막아낸 재앙에 대해서는 좀처럼 공을 인정받지 못한다. 아무 일도 일어나지 않았으니, 사람들은 금방 잊어버린다.
또한, 반박할 때마다 누군가의 승진 패킷이나 VP의 '아끼는 프로젝트'를 해치는 위험을 감수하게 된다. 다리를 불태우고 '적'을 만들 위험에 처한다. 대기업에서 반대하는 사람이 몇 명 있는 것은 그냥 사업하는 비용이지만, 너무 많아지면 본업에도 영향을 미치기 시작한다.
마지막으로, 심리적 영향도 있다. 당신은 혼자인데 당신의 전문성이 도움이 될 수 있는 공간에서 일하는 엔지니어는 수백 명이다. 당신의 주의력은 유한하지만, 대기업이 나쁜 아이디어를 만들어내는 능력은 무한하다. 경험에서 말하건대, 이것들을 막는 데 너무 깊이 관여하면 세상에 대해 매우 냉소적이 될 수 있다. 그리고 이건 정말 좋은 상태가 아니다.
영향력을 은행 계좌처럼 관리하라
나쁜 프로젝트를 모두 막을 수 없다면, 어떻게 해야 할까? 전략적으로 접근하는 것이다. 모든 것을 고치려 하는 대신, 당신의 영향력을 은행 계좌처럼 생각하라. 매달 일을 하고, 사람들을 돕고, 성공적인 프로젝트를 출시하고, 전반적으로 마찰이 적은 사람으로 남음으로써 일정량의 '영향력'이 들어온다.
그리고 중요한 순간에 '인출'할 준비가 돼 있어야 한다. 무언가를 막거나 우려를 제기할 때마다, 아무리 작더라도 잔액에 수표를 끊는 것이다. 하지만 수표의 크기는 같지 않다.
- 5달러짜리 수표: 코드 리뷰에서의 사소한 지적. 저렴한 일상 비용.
- 500달러짜리 수표: 아키텍처 결정에 이의를 제기하거나 일정에 반박하는 것. 어느 정도의 저축이 필요하다.
- 5만 달러짜리 수표: VP의 아끼는 프로젝트를 죽이려는 시도. 이건 엄청난 지출이다. 몇 년에 한 번밖에 감당하지 못할 수도 있다.
문제는 눈에 보이는 사소한 비효율에 5달러씩 쓰는 경우다. 작은 것들에 끊임없이 "아니요"를 말하면, 진짜 재앙을 막기 위해 큰 수표를 써야 할 때 계좌가 비어있게 된다.
'마이너스'가 되면, 당신은 정치적 파산 상태에 들어간다. 사람들은 당신을 회의에 부르지 않고, 의견을 묻지 않으며, 사실상 당신을 우회해서 일하기 시작한다. 한번 파산하면 당신의 영향력은 0으로 떨어지고, 일에 영향을 미치는 능력뿐 아니라 자기 일을 처리하는 능력도 해치기 시작한다.
언제 영향력을 쓸 것인가
모든 것에 개입할 수 없다는 것을 받아들였다면, 이제 언제 개입하는 것이 의미 있는지를 파악해야 한다.
가장 먼저 해야 할 일은 겸손해지고, 당신이 실제로 판단을 내릴 전문성이 있는지 평가하는 것이다. 시니어가 되면 의견이 많아지지만, 그것이 항상 정보에 근거한 의견은 아니다. 예를 들어, 나는 어느 정도 프론트엔드 경험이 있지만, 그것은 장기적인 소유권에서 오는 깊은 전문성이 아니라 '어느 정도 감당할 수 있는' 수준이기 때문에 깊은 조언을 줄 자격이 없다고 느낀다. 고품질의 판단에는 정보에 기반한 의견이 필요하다는 사실을 간과하기 쉽다. 이런 상황에서는 스스로를 의견이 있는 관찰자로 보고 거기서 멈추어야 한다.
또한, 당신이 무언가를 말한다고 해서 그것이 진실이 되는 것은 아니라는 사실을 내면화해야 한다. 당신은 하나의 관점에 대한 인식을 높이는 것이지, 칙령을 내리는 것이 아니다. 따라서 어떤 팀이 당신의 우려를 듣고도 자기들이 하던 것을 계속하기로 결정한다면, 그것을 받아들이고 넘어가야 한다. 결국, 당신은 그들에 대한 권한이 있는 CEO가 아니라 엔지니어이니까.
이를 바탕으로, 나는 세 가지 주요 요소를 통해 언제 말할지 결정한다.
- 프로젝트가 내 팀과 얼마나 가까운가?
- 잘못됐을 때, 우리 팀에 얼마나 큰 영향을 미치는가?
- 잘못됐을 때, 회사 전체에 얼마나 큰 문제가 될 것인가?
근접성. 프로젝트가 당신과 가까울수록, 말하는 '비용'은 낮아진다. 본인 팀 내부라면 비용은 거의 0에 가깝다. 신뢰가 높고 짧은 대화로 해결되는 경우가 많다. 더 넓은 조직 내라면 비용이 올라간다. 사회적 자본을 써야 하고 평판을 걸어야 한다. 다른 조직이라면? 비용은 대개 감당하기 어렵다. 레버리지도 없고, 보고 체계도 다르고, 막으려면 엄청난 인출이 필요하다.
팀 영향도. 때로는 다른 조직이 당신의 업무에 깊은 영향을 미치는 무언가를 한다. 예를 들어, 내가 일하는 Perfetto(성능 분석 도구)는 구글 전반에 사용자가 있기 때문에, 어떤 팀이 매우 복잡한 통합에 대해 우리의 승인을 요청하는 경우가 있다. 이건 전형적인 위험이다. 잘 되면 그들이 공을 가져가지만, 잘못되면 당신의 리더십이 당신에게 해결을 기대할 수 있다—당신이 만들지도 않은 문제를. 이런 경우에는 말을 꺼내는 것의 효용이 높다. 팀을 보호하는 일이기 때문이다.
회사 규모. 마지막으로, 폭발 반경을 고려하라. 어떤 프로젝트는 독립적이어서 실패해도 자기 자신만 쓰러진다. 다른 것들은 핵심 시스템과 너무 얽혀 있어서 실패가 광범위한 피해를 일으키거나, 수년간 지속될 기술 부채를 만들어낸다. 이런 것들은 프로젝트의 장기적 건전성에 치명적일 수 있다.
나쁜 프로젝트 앞에서 어떻게 행동할 것인가
언제 의견을 내느냐뿐만 아니라 어떻게 내느냐도 중요하다. 당신이 처한 상황에 따라 취할 수 있는 행동의 범위는 매우 넓다.
개입할 때
핵 옵션은 "이것은 해서는 안 된다"고 직접 말하며 프로젝트를 중단시키려 하는 것이다. 이것은 거의 항상 당신의 리드와 해당 팀의 리드에게 에스컬레이션하는 것을 필요로 하며, 당신이 옳다는 것과 이 프로젝트가 적극적으로 해롭다는 것에 대한 강한 확신이 있어야 한다. 하지만 때로는 이것이 옳은 일이기도 하다. 특히 말하지 않으면 당신의 프로젝트나 팀에 실존적 위협이 될 수 있는 경우라면.
이보다 약하지만 여전히 꽤 위험한 변형은, 직접 에스컬레이션 대신 팀에게 직접 우려를 제기하는 것이다. 보통 미팅이나, 강하게 쓰인 '우려' 또는 '반박' 문서의 형태로 한다. 목표는 팀 스스로가 이 프로젝트가 좋은 아이디어가 아닐 수 있다는 결론을 내릴 만큼 강한 어조로 말하는 것이다.
그보다 더 작은 개입은, 올바른 방향으로 살짝 밀어주는 것이다. 이것은 팀이 높은 수준에서는 말이 되는 무언가를 하려는데 잘못된 방식으로 접근하고 있을 때 완벽하다. Perfetto에서 자주 보게 된다. 한 팀이 나중에 문제를 일으킬 것이라는 걸 아는 복잡한 Perfetto 사용을 제안하는 설계 문서를 보낸다. 나는 그들과 자리를 잡고, 실제 문제를 이해하고, 더 나은 해결책으로 안내한다. 한 시간이 들지만 그들에게 몇 달을 절약해 준다. 잘 하면, 속도를 늦추더라도 방해자가 아닌 조력자로 여겨질 수 있다.
개입하지 않을 때
때로는 직접적인 행동을 취할 ROI가 없다고 결론 내린다. 정치적 모멘텀이 너무 강하거나, 문제가 너무 작아서 영향력을 쓸 정당성이 없을 때다. 이때 어떻게 하느냐는 팀이 얼마나 관여돼 있느냐에 달려 있다.
팀의 업무와 많이 겹친다면, 조용한 비상 계획을 세우는 것이 나을 수 있다. 의존도를 줄이거나, 그 프로젝트가 사라지더라도 대처할 수 있는 추상화를 만들어두는 것. 여기에 장기적인 수도 있다. 나쁜 프로젝트라도 보통은 좋은 아이디어의 '본질', 즉 해결하려 했던 특정 문제나 기반이 된 통찰이 있다. 그것이 당신 일과 맞는다면, 그 본질을 가져다 더 나은 버전의 해결책을 자연스럽게 자신의 프로젝트에 녹여내는 것이 좋은 생각인 경우가 많다. 그러면 나쁜 프로젝트가 중단되거나 취소되더라도 사후 대응이 아닌 사전 대응이 가능하다.
관여하지 않는 상황이라면 쉽다. 그냥 그림에서 빠져라. 친한 동료에게 속으로 불평하고, 공감해도 되지만, 공식 석상에서는 현실과 함께 살아가라.
팀을 이끌어 가기
마지막으로, 이 과정에서 본인 팀도 관리해야 한다. 당신이 프로젝트의 결함을 볼 수 있다면, 다른 시니어 엔지니어들도 아마 보고 있을 것이다. 나쁜 프로젝트가 실제로는 좋다고 가장하며 그들을 가스라이팅하거나 '회사의 입장을 대변'하려 하지 마라. 신뢰를 파괴한다.
대신, 불필요한 정치적 세부사항 없이 지금의 현실에 대해 솔직하게 말하라. 이런 제약 아래서 최선을 다하겠다고 말하라.
결론
그래서 나는 멘티에게 무슨 말을 했을까? "나는 옳은 것과 효과적인 것은 다르다는 걸 배웠어. 가서 내 우려를 말할 수는 있어. 그들은 아마 듣지 않을 거고, 나는 약간의 신뢰를 잃겠지. 그리고 6개월 후에는 아무도 내가 예측했다는 것을 기억하지 않고, 그들의 작업을 막으려 한 사람으로만 기억할 거야."
커리어 초반에는 좋은 아이디어가 실력으로 승리한다고 믿고 싶어한다. 충분히 명확하게 설명하면 사람들이 이성적으로 볼 것이라고. 대기업이 그런 식으로 돌아가지 않는다는 것을 받아들이는 데는 꽤 오랜 시간이 걸렸다.
하지만 이것이 신경 쓰는 것을 멈추라는 의미는 아니다. 언제 자신의 신뢰를 쓸지에 대해 전략적이 되라는 것이다. 실제로 결과를 바꿀 수 있는 싸움을 골라라. 침묵하면 팀이 상처받을 때, 틀려도 비용이 낮지만 프로젝트 실패의 비용이 높을 때.
그리고 나머지에 대해서는? 동료에게 불평하고, 조용히 비상 계획을 세우고, 지켜봐라. 때로는 뭔가를 배우게 된다. 때로는 당신이 틀리고 프로젝트가 실제로 잘 된다. 그리고 때로는 일이 정확히 어떻게 무너질지 예측했던 것에 대한 씁쓸한 만족감을 느끼게 된다.
이것은 모든 것을 고치는 것만큼 만족스럽지 않다. 하지만 효과가 있고, 나를 정신 건강하게 유지해 준다.
소감
이 글을 읽으면서 내내 불편했다. 좋은 의미로.
코드 리뷰에서 사소한 것 하나하나를 피드백을 주는 것이 '퀄리티에 기여하는 일'이라고 생각했다. 잘못된 방향으로 가는 것을 보면 말해야 한다고 믿었다. 그게 좋은 엔지니어의 덕목이라고.
그런데 이 글의 '영향력은 은행 계좌'라는 비유가 마음에 강하게 박혔다. 나는 지금 얼마짜리 수표를 얼마나 자주 끊고 있는걸까? 매일 5달러짜리 수표를 쓰면서, 정작 50,000달러짜리 수표가 필요한 순간에는 잔액이 바닥나 있는 것은 아닐까?
이 아티클이 말하는 핵심은 결국 우선순위에 대한 이야기다. 모든 것을 고칠 수 없다면, 고쳐야 할 것을 골라라. 그리고 그 선택의 기준은 감정이나 원칙이 아니라, '내 팀과의 거리', '팀에 미치는 영향', '회사 전체의 파급 효과'여야 한다.
프론트엔드 개발자로서 생각해보면, 이건 기술 결정에도 그대로 적용된다. 번들 사이즈가 10kb 늘어나는 것을 매번 이슈화하면서 실제 성능에 영향을 미치는 아키텍처 결정에는 침묵하고 있지는 않은지. 컴포넌트 네이밍 컨벤션으로 매번 기력을 소진하면서, 진짜 문제인 상태 관리 설계에는 발언권이 없는 상황이 되어 있지는 않은지.
'옳은 것'과 '효과적인 것'이 다르다는 문장이 쉽게 잊히지 않는다.
개발 업무 안에서, 팀 안에서, 그리고 커리어 전체에서 이 두 가지를 구분하는 연습이 필요하다는 생각이 든다.
