[번역] 시니어 개발자들은 왜 잘못된 프로젝트를 말리지 않을까?

원저자의 허락 하에 원문 <Why Senior Engineers Let Bad Projects Fail>을 한국어로 번역한 글입니다. 번역본에 원저자의 개입은 없으며 일부 오역 및 의역이 존재할 수 있습니다.

제가 주니어 개발자였을 때 제 선배 개발자는 같이 있을 때 이런 불만을 털어놓곤 했습니다. 다른 팀의 프로젝트를 가리키며 “그 프로젝트는 잘 안 될 것 같아. 잘못된 문제를 풀고 있어.”라는 식의 불만이었습니다. 저는 '선배는 그렇게 잘 알고 있으면서 왜 그 팀에 가서 말하지 않는 걸까?'라고만 생각했습니다. 말하지 않는 게 선배의 영향력을 낭비하는 것처럼 느껴졌습니다.

지난 주, 멘티에게 "옆 팀 프로젝트는 초기 설계를 잘못해서 결국 방향을 바꿀 수밖에 없을 것 같다"고 설명하자 멘티는 저에게 "그럼 그냥 그 팀에 의견을 말하면 되지 않나요?"라고 물었습니다. 예전에 제가 가졌던 의문을 다른 사람에게 똑같이 듣자 기분이 이상했습니다. 그때부터 여러 생각이 맴돌았는데, 그동안 제 생각에 변화가 있었다는 걸 깨달았습니다.

커리어를 거치며, 옳은 것과 효과적인 것은 다르다는 걸 알게 되었기 때문입니다.

규모가 큰 회사에서, "잘못된 프로젝트"를 보고 의견을 내는 건 좋습니다. 하지만 적당히 말해야 합니다. 개발 경력이 쌓이면서, 애초에 들을 생각이 없는 사람과 논쟁하는 건 무의미하며, 그럴 땐 조언은 아껴 두는 편이 낫다는 것을 배웠습니다.

잘못된 프로젝트란?

이 글에서 가리키는 "잘못된 프로젝트"란 여러 의미를 포괄합니다.

• UX 관점에서: 제품을 불필요하게 복잡하게 만들거나, 존재하지 않는 문제를 풀거나, 이미 자리 잡은 워크플로를 망치는 프로젝트
• 기술 관점에서: 너무 복잡하게 설계되거나, 라이브러리 선택이 잘못되었거나, 성능이 나쁜 아키텍처를 고수하는 프로젝트
• 정치적 관점에서: 유행하는 키워드를 지나치게 쫓거나, 승진·성과를 위한 명분으로 만드는 프로젝트

한 가지 짚고 넘어가야 할 것은, 프로젝트가 "잘못되었다" 라는 것은 생명주기 상 많은 구간에서 매우 주관적이라는 점입니다. 소프트웨어 엔지니어링은 대부분 트레이드오프의 연속입니다. 완벽하지는 않지만 당시에 가지고 있던 정보 내에서 최선으로 보이는 결정을 내리게 됩니다. 과거의 선택이 옳았는지는 의견이 갈리는 경우가 많고, 그게 명확해지는 건 훨씬 나중의 일입니다. 제품이 출시된 후 몇 년이 지나서일 수도 있습니다.

다만 시니어로 올라갈수록 소프트웨어 프로젝트에 대한 감각이 생기고, 그 결과 프로젝트 중 일부만 봐도 "이건 말이 안 된다"고 느끼는 순간이 옵니다. 그런 직감이 들기 시작하면, "프로젝트가 잘못되었다"는 신호로 받아 들입니다. 즉, 모두가 나쁘다고 인정하기 전에 먼저 알아챌 수 있는 그런 프로젝트를 말합니다.

저의 경험을 하나 들어보면, 몇 년 전 구글에서 있었던 일이 기억에 남습니다. 사내 발표회에서 "판도를 바꿀" 프로젝트 하나가 큰 주목을 받았습니다. 두 개의 매우 큰 조직이 겹치는 프로젝트였습니다. 기술적으로 놀랍고 세련됐고, 어려운 문제들에 대한 기발한 아이디어가 가득했습니다.

하지만 발표회에 앉아 있던 저는 리드 개발자에게 고개를 돌려 속삭였습니다. "이 프로젝트 성공할 가능성 없죠?" 그는 저를 보더니 "그렇지."라고 대답했습니다. 저희 둘은 발표 즉시 문제를 파악했습니다. 프로젝트는 플랫폼 팀이 플래그십 제품 팀에게 핵심 사용자 플로우에 대한 통제권을 내줄 것을 전제로 설계되어 있었습니다. 기술적으로는 맞는 방향이었지만, 어떤 리드나 PM도 그만큼 핵심적인 것을 다른 팀에 넘기지 않는다는 게 문제였습니다. 정치적인 관점에서 이 프로젝트는 현실에서 이루어질 수 없었습니다.

프로젝트는 거의 2년 동안 조용히 진행됐습니다. 출시가 가까워질 때마다 "아직 준비가 안 됐다"며 미뤄졌고, 시간이 지나며 이야기는 줄다가, 결국 예상했던 "전략적 프로젝트 방향 수정" 메일이 도착했습니다. 인력은 재분배되고 코드는 삭제됐습니다. 회사는 "그 과정에서 많은 것을 배웠다"고 했지만, 저는 처음부터 실패가 정해진 것처럼 느꼈습니다. 기술적 완성도만큼 정치와 올바른 문제 정의가 중요하다는 걸 그 프로젝트에서 다시 한번 배웠습니다.

왜 말리면 안 될까?

"잘못된 프로젝트"가 보이기 시작하고, 어느정도 스스로에게 전문성이 있다고 느꼈을 때, 저는 프로젝트를 지적하고 싶은 유혹을 느꼈습니다. 해당 팀에 연락해 "이건 말이 안 됩니다"라고 말하고, 이유를 설명하는 방식으로요. 팩트와 논리로 설득하려 했습니다.

그리고 저는 실제로 그렇게 했습니다. 하지만 곧, 이런 행동에는 제가 생각지 못한 비용이 크다는 걸 깨달았습니다.

일단, 소프트웨어 회사는 행동을 우선시하는 경향이 있습니다. 속도와 출시를 매우 중요하게 봅니다. 우려를 제기하면, 당연히 프로젝트의 속도가 늦어지고 예정에 없던 검토가 들어갑니다. 그래서 "빨리 배포하려는 분위기"를 넘어설 만큼 큰 이유가 없다면, 말을 해도 의미 있는 변화가 나올 가능성은 거의 없습니다. 오히려 무시당할 가능성이 큽니다.

이와 관련하여, 팀이 우려를 진지하게 받아들이는 편이라 해도 자주 하면 안 됩니다. 한두 번일 땐 "품질"을 지키는 개발자로 보일 수 있지만, 너무 자주 하면 "부정적인 사람"으로 보입니다. 문제를 해결하는 사람이 아니라 문제를 만드는 사람으로 보이게 됩니다. 재앙을 막아내도 공은 거의 돌아오지 않습니다. 아무 일도 일어나지 않았기 때문에 사람들은 금방 잊어버립니다.

또한, 반대할 때마다 누군가의 등급 평가나 높은 사람이 아끼는 프로젝트를 건드릴 수 있다는 문제가 있습니다. 관계를 망치고 "적"을 만들 위험이 있습니다. 대기업에서 자기와 의견이 다른 사람들은 당연히 어느정도 생기기 마련이지만, 그 수가 너무 많아지면 본업에도 영향을 미치기 시작합니다.

마지막으로 심리적 영향도 있습니다. 전문성이 도움이 될 수 있는 영역에서 일하는 엔지니어는 수백 명인데, 당신은 한 명입니다. 개인의 집중력 양은 한계가 있는데, 대기업에서 잘못된 아이디어를 만들어 내는 건 너무 다양합니다. 경험상, 이런 것들을 막는 데 너무 깊이 관여하면 냉소적인 개발자가 되기 쉽고 여러분에게 전혀 좋지 않습니다.

영향력을 은행 계좌처럼

프로젝트가 잘못되었다고 해서 다 막을 수 없다면 어떻게 해야 할까요? 전략적으로 접근해야 합니다. 모든 것을 고치려 하기보다, 본인의 영향력을 은행 계좌처럼 바라보는 관점을 가지면 좋습니다. 성실히 개발하고, 동료를 돕고, 성공적인 프로젝트를 출시하며, 전반적으로 조직 내의 마찰을 최소화하다보면, 매달 일정량의 "영향력"이 여러분의 계좌에 입금됩니다.

그리고 정말 중요한 순간에는 영향력을 "출금할" 준비가 되어 있어야 합니다. 무언가를 막거나 우려를 제기할 때마다, 그 사안이 아무리 사소하더라도 본인의 잔고에서 수표를 끊는 것과 같습니다. 다만 항상 같은 금액인 건 아닙니다. 사안에 따라 금액이 다릅니다.

• 5,000₩ 수표: 코드 리뷰로 사소하게 지적하기, 부담이 적고 일상적으로 발생하는 지출
• 500,000₩ 수표: 아키텍처 결정을 문제 삼거나 일정에 대해 반대 의견을 내기, 어느 정도의 잔고가 필요함
• 50,000,000₩ 수표: 임원이 "아끼는 프로젝트”를 없애려는 정도의 시도, 엄청난 지출로 몇 년에 한 번 정도만 감당할 수 있을지도 모름

문제는 눈에 보이는 모든 작은 비효율에 대해 매번 5천 원씩 쓰기 시작할 때 발생합니다. 사소한 일마다 계속 "안 된다"고 말하면, 진짜 재앙을 막기 위해 큰 수표를 써야 할 때 계좌는 이미 텅 비어 있습니다.

만약 "잔고를 초과해" 버리면, 곧바로 정치적 파산 상태에 돌입합니다. 사람들은 더 이상 회의에 당신을 부르지 않고, 의견을 묻지 않으며, 사실상 당신을 무시하며 일을 진행하기 시작합니다. 일단 파산하면 영향력은 제로가 되며, 조직에 영향을 미칠 능력뿐 아니라 본인이 일을 추진하고 성과를 내는 능력에도 악영향을 끼치게 됩니다.

영향력을 써야 하는 순간

이제 우리는 모든 일에 의견을 낼 수 없다는 사실을 알게 됐습니다. 그렇다면 언제 의견을 내는 게 좋을지 판단해야 합니다.

가장 먼저 해야 할 일은 겸손의 자세를 갖고, 자신이 실제로 판단을 내릴 만한 전문성을 갖추고 있는지 평가하는 것입니다. 시니어가 되면 의견이 많아지기 마련이지만, 그 의견이 항상 근거가 있는 건 아닙니다. 예를 들어 저는 프런트엔드 경험이 어느 정도는 있지만, 깊이 있는 조언을 할 만큼 전문적이라고 생각하진 않습니다. "그럭저럭 해낼 수 있는 수준"이지, 장기간 책임지고 다루면서 쌓인 깊은 전문성은 아니기 때문입니다. 좋은 판단에는 충분한 정보가 필요하다는 점을 간과하기 쉽습니다. 만약 본인이 이런 상황이라면, 의견을 가진 관찰자의 역할 정도의 선에서 멈추는 편이 낫습니다.

또한 "내 말이 곧 답이다"라는 착각에서 반드시 벗어나야 합니다. 여러분이 하는 일은 명령을 내리는 것이 아니라, 하나의 관점을 제시하여 리스크를 공유하는 것입니다. 따라서 어떤 팀이 당신의 우려를 듣고도 그대로 진행하기로 결정한다면, 그 또한 받아들여야 합니다. 우리는 엔지니어일뿐, 권한을 행사할 수 있는 CEO가 아닙니다.

이런 전제를 바탕으로, 저는 의견을 낼지 말지 결정할 때 다음 세 가지 요소를 주로 고려합니다.

1. 이 프로젝트가 우리 팀과 얼마나 가까운가?
2. 이 프로젝트가 잘못되었을 때 우리 팀에 미치는 영향은 어느 정도인가?
3. 이 프로젝트가 잘못되었을 때 회사 전체에 미치는 영향은 어느 정도인가?

근접성

프로젝트가 내 영역에 가까울수록, 무언가를 지적하는 데 드는 "비용"은 낮아집니다. 우리 팀 내부의 일이라면 신뢰 관계가 높기 때문에 비용이 거의 0에 가깝고, 간단한 대화만으로도 해결되는 경우가 많습니다. 하지만 더 넓은 조직 단위로 넘어가면 비용이 올라갑니다. 사회적 자본을 사용해야 하고, 때로는 본인의 평판을 걸어야 할 수도 있습니다. 조직 바깥의 프로젝트라면 비용은 대개 감당하기 어려울 정도로 커집니다. 영향력을 행사할 수단도 없고, 보고 체계도 다르며, 이를 막으려면 엄청난 규모의 "출금"이 필요하기 때문입니다.

팀에 미치는 영향

때로는 다른 조직의 결정이 우리 팀 업무에 큰 영향을 미치기도 합니다. 예를 들어 제가 담당하는 성능 툴인 Perfetto*는 구글 전반에서 사용되므로, 어떤 팀이 매우 복잡한 통합 작업에 대해 우리 팀에 승인을 요청하는 경우가 있습니다. 이 상황은 전형적인 리스크를 가집니다. 일이 잘되면 그 팀이 공을 가져가지만, 잘못될 경우에는 우리 팀이 원인 제공을 하지 않았음에도 문제를 해결해야 합니다. 이런 경우엔 의견을 내는 게 우리 팀을 보호하는 행위이므로 돌아오는 보상이 매우 큽니다.

*역자주: Perfetto는 시스템 프로파일링을 위한 오픈소스 플랫폼으로 구글의 주도 하에 개발되고 있습니다.

회사에 미치는 피해 규모

마지막으로 고려해야 할 것은 피해 범위입니다. 어떤 프로젝트는 실패하더라도 그 프로젝트 하나만 무너집니다. 하지만 어떤 프로젝트는 핵심 시스템과 긴밀히 연결되어 있어, 광범위한 피해를 유발하거나 수년간 지속되는 기술 부채를 만들어 냅니다. 이런 프로젝트는 장기적인 시스템의 건강을 해치는 치명적인 요인이 될 수 있습니다.

잘못된 프로젝트를 어떻게 대할 것인가?

말을 언제 꺼내는지만 중요한 게 아니라 어떻게 꺼내는지도 중요합니다. 상황에 따라 할 수 있는 행동의 폭은 꽤 넓습니다.

개입할 때

가장 극단적인 방법은 "이건 하면 안 됩니다"라고 직접 말하고 프로젝트를 중단시키려는 것입니다. 이는 거의 항상 리더에게 먼저 보고하고, 해당 프로젝트를 소유한 팀의 리더에게도 공식적으로 문제를 제기하는 절차를 밟아야 합니다. 따라서 본인이 옳다는 확신뿐 아니라, 이 프로젝트가 실제로 해롭고 위험하다는 점에 대해서도 강한 확신이 있어야 합니다. 어떤 경우에는 이렇게 하는 게 맞습니다. 특히 말하지 않았을 때의 대가가 우리 프로젝트나 팀의 존재 자체를 위협할 때는 더욱 그렇습니다.

이보다 약간 더 부드럽지만 여전히 위험한 방법도 있습니다. 공식적인 문제 제기 대신 해당 팀에 직접 우려를 표하는 것입니다. 보통 팀과의 미팅이나 강한 어조의 "우려" 또는 "반론"을 적은 문서로 이뤄집니다. 충분히 강하게 말함으로써 이 방법은 프로젝트를 수행하려는 팀 스스로 "이 프로젝트는 위험할 수 있다"고 결론 내리게끔 하는 것을 목적으로 합니다.

그보다 더 작은 개입이 있습니다. 즉, 전체적으로는 타당해 보이지만 접근 방식이 잘못된 상황에서, 일을 올바른 방향으로 살짝 유도하는 것입니다. 저는 Perfetto에서 이런 경우를 자주 봅니다. 어떤 팀이 Perfetto를 복잡하게 활용하겠다는 설계 문서를 보내오는데, 저는 그 방식이 결국 그 팀을 괴롭힐 것이라는 걸 알고 있습니다. 그래서 그들과 마주 앉아 문제를 파악하고, 더 나은 해결책으로 유도합니다. 이 과정은 한 시간 정도의 시간이 들지만, 결과적으로는 그 팀이 몇 달을 낭비하는 것을 막습니다. 그리고 일이 잘 풀리면, 팀의 속도를 다소 늦췄지만, 방해꾼이 아니라 도와주는 사람으로 인식될 수도 있습니다.

개입하지 않을 때

때로는 직접적으로 액션을 취하기에는 가성비가 좋지 않다고 생각되는 경우가 있습니다. 정치적 흐름이 너무 강하게 굳어져 있거나, 영향력을 쓸 만큼 중요하지 않을 수도 있습니다. 이 시점에서 어떻게 행동할지는, 그 일이 우리 팀과 얼마나 관련이 있는지에 따라 달라집니다.

프로젝트가 우리 팀의 업무와 크게 겹친다면, 눈에 띄지 않게 대비책을 마련하는 게 좋습니다. 예를 들어 해당 프로젝트에 대한 의존도를 줄이거나, 혹시 그 프로젝트가 사라지더라도 대응할 수 있도록 추상화 계층을 만들어두는 방식입니다. 장기적인 전략도 있습니다. 잘못된 프로젝트라고 해도, 대개는 어느 정도 “좋은 아이디어의 핵심”이 존재합니다. 즉, 해결하려던 구체적인 문제나, 그 기반이 된 통찰이 있습니다. 만약 그것이 본인의 업무와 맞닿아 있다면, 그 핵심을 가져와서 더 나은 형태로 개선한 해결책을 자신의 프로젝트에 자연스럽게 녹여내는 것이 좋은 선택지가 됩니다. 그렇게 해두면, 해당 프로젝트가 늦어지거나 중단될 때 그 여파에 끌려다니지 않고, 미리 준비된 상태로 대응할 수 있습니다.

반대로 본인이 그 일에 직접적으로 관련되어 있지 않다면, 선택은 간단합니다. 그냥 거리를 두면 됩니다. 친한 동료들과 사적으로는 불평하고 공감할 수 있겠지만, 공개적으로는 현실을 받아들이고 조용히 넘어가는 편이 낫습니다.

그 과정에서 팀을 이끌기

마지막으로, 그 과정을 거치는 동안 본인의 팀을 잘 관리해야 합니다. 여러분이 어떤 프로젝트의 문제점을 알아차릴 수 있다면, 다른 시니어 개발자들도 아마 같은 문제를 보고 있을 가능성이 큽니다. 이때 팀원들을 속이거나, "(틀린 게 뻔한) 회사의 공식 입장을 그대로 따라가며" 잘못된 프로젝트를 괜찮은 것처럼 포장하지 마세요. 그런 태도는 신뢰를 무너뜨립니다.

대신, 불필요한 정치적 뒷이야기까지 늘어놓지 않으면서도 현재 상황에서 확인한 사실은 솔직하게 공유해야 합니다. 그리고 이러한 제약 속에서도 본인이 할 수 있는 최선을 다하겠다고 팀에 말해주어야 합니다.

마무리

그렇다면 지난주, 멘티의 질문에 저는 뭐라고 답했을까요?

“제가 배운 건, 옳은 것과 효과적인 것은 다르다는 사실이에요. 물론 그 팀에 가서 우려를 이야기할 수도 있습니다. 하지만 아마 듣지 않을 거고, 저는 오히려 제 신뢰를 소모하게 될 겁니다. 그리고 6개월 뒤에는 아무도 제 말이 맞았다는 걸 기억하지 않을 거예요. 그저 프로젝트를 막으려 했던 사람 정도로 기억하겠죠.”

커리어 초반에는 좋은 인사이트를 제시하면 실력과 타당성을 갖춘 사람으로 인정받는다고 믿고 싶을 겁니다. 충분히 논리적으로 설명하면 사람들이 납득할 거라고도 생각합니다. 저 역시 회사는 그렇게 움직이지 않는다는 사실을 받아들이는 데 꽤 오랜 시간이 걸렸습니다.

그렇다고 해서 관심을 끊으라는 뜻은 아닙니다. 다만 본인의 신뢰와 영향력을 언제 사용할지 전략적으로 판단해야 한다는 의미입니다. 실제로 결과를 바꿀 수 있는 싸움, 내가 침묵하면 우리 팀이 피해를 입는 싸움, 나의 판단이 틀렸을 때의 비용보다 프로젝트가 실패했을 때의 비용이 큰 싸움을 잘 골라내야 합니다.

그렇지 않은 프로젝트라면요? 동료들에게 조용히 하소연하고, 눈에 띄지 않게 대비책을 마련하며, 지켜보면 됩니다. 때로는 배울 점도 있고, 오히려 내가 틀렸고 프로젝트는 의외로 잘 굴러갈 수도 있습니다. 그리고 또 어떤 경우에는, 일이 어떻게 망가질지 정확히 예측했던 것에 대한 씁쓸한 만족감을 느끼게 될 수도 있습니다.

물론 이런 방식은 모든 걸 직접 고쳐버리는 것만큼 통쾌하지는 않습니다. 하지만 우리에겐 현실적인 해결책이 필요하며, 무엇보다도 나 자신을 보호해야 합니다.