"팀장님, 저 아키텍처대로 가면 배포할 때마다 장애 날 게 뻔한데 왜 가만히 계세요?"
입사 2년 차, 패기 넘치는 후배가 제 자리로 찾아와 따지듯 물었습니다. 모니터 너머로 보이는 그의 눈빛에는 정의감과 답답함이 섞여 있었습니다. 10년 전의 저를 보는 것 같더군요. 그때의 저도 그랬습니다. 기술적으로 말이 안 되는 결정, 정치적인 이유로 강행되는 일정, 비즈니스 로직을 무시한 채 최신 기술 스택만 욱여넣는 '이력서 주도 개발(RDD)' 현장을 보며 분노했었으니까요.
하지만 저는 그 후배에게 씁쓸한 미소를 지으며 "일단 지켜보자"라고만 답했습니다. 비겁해 보였을 겁니다. 하지만 그건 비겁함이 아니라, 숱한 프로젝트를 말아먹으며 체득한 생존 본능이자 '영향력'이라는 자산을 관리하는 방식이었습니다.
우리는 흔히 엔지니어링이 논리와 팩트의 싸움이라고 착각합니다. 코드는 거짓말을 하지 않으니까요. 하지만 프로젝트는 코드가 아니라 사람이 합니다. 그리고 사람이 모인 곳에는 반드시 '정치'와 '편향'이 존재합니다.
제가 주니어 시절, SI 프로젝트에서 고객사의 무리한 요구사항에 대해 매번 "안 됩니다", "기술적으로 불가능합니다"를 입에 달고 살았습니다. 논리적으로 제가 옳았습니다. 하지만 결과는 참담했습니다. 저는 '매사 부정적인 개발자', '협조가 안 되는 인력'으로 낙인찍혔고, 정작 보안 이슈로 DB가 털릴 뻔한 결정적인 순간에 제 목소리는 힘을 잃었습니다. 아무도 제 경고를 진지하게 듣지 않았기 때문입니다.
그때 깨달았습니다. 조직 내에서 '옳은 말'을 하는 것과 '효과적인 변화'를 이끌어내는 것은 완전히 다른 차원의 문제라는 것을요.
소프트웨어 회사, 특히 성장 속도를 중요시하는 조직은 태생적으로 '행동 편향(Action Bias)'을 가지고 있습니다. 일단 만들고, 배포하고, 터지면 고치는 것을 미덕으로 여깁니다. 이런 흐름 속에서 리스크를 지적하는 행위는 속도에 제동을 거는 '방해 공작'으로 간주되기 십상입니다.
여기서 시니어 개발자가 갖춰야 할 가장 중요한 덕목은 '침묵의 타이밍'을 아는 것입니다. 모든 잘못된 프로젝트를 막아설 수는 없습니다. UX가 조금 복잡해지거나, 오버 엔지니어링 된 라이브러리를 쓰는 정도의 문제는 그냥 두는 게 나을 때도 있습니다. 그런 사소한 문제 하나하나에 반대 의견을 내는 것은, 마치 은행 계좌에서 돈을 인출하는 것과 같습니다.
저는 이것을 '영향력 계좌(Influence Bank Account)'라고 부릅니다.
우리가 코드를 작성하고, 동료를 돕고, 안정적으로 서비스를 운영할 때마다 이 계좌에는 조금씩 신뢰라는 잔고가 쌓입니다. 반대로 누군가의 의견에 반대하거나 프로젝트를 중단시키려 할 때는 막대한 비용이 인출됩니다.
- 코드 리뷰에서 변수명이나 컨벤션을 지적하는 건 5달러짜리 지출입니다.
- 아키텍처 설계의 문제점을 지적하며 일정을 늦추는 건 500달러쯤 됩니다.
- 임원급이 밀고 있는 야심 찬 프로젝트(Pet Project)를 엎으려 드는 건 50,000달러짜리 수표를 발행하는 일입니다.
문제는 대부분의 엔지니어가 5달러짜리 싸구려 지출에 자신의 잔고를 탕진한다는 점입니다. 사소한 비효율에 매번 "아니요"를 외치다 보면, 정작 회사의 존폐가 걸린 치명적인 아키텍처 결함이나 보안 홀을 발견했을 때 사용할 잔고가 바닥나 있습니다. '정치적 파산' 상태가 되는 것이죠. 이때는 아무리 올바른 소리를 해도 조직은 당신을 투명 인간 취급합니다.
몇 년 전, 거대 테크 기업들이 주도하는 '마이크로서비스(MSA) 대유행'에 휩쓸려 멀쩡한 모놀리식 서버를 쪼개겠다고 덤벼든 프로젝트가 있었습니다. 기술적으로는 멋져 보였지만, 트래픽 규모나 팀의 운영 역량을 봤을 때 그것은 재앙이 예견된 일이었습니다.
하지만 저는 침묵했습니다. 그 프로젝트는 당시 본부장의 승진이 걸린 핵심 과제였고, 팀원들은 쿠버네티스를 써보고 싶어 안달이 나 있었으니까요. 제가 거기서 "이건 실패할 겁니다"라고 말해봤자, 돌아오는 건 냉소와 배제뿐이었을 겁니다. 대신 저는 제 팀이 맡은 백엔드 영역에서 그 파편화된 서비스들이 호출될 때 발생할 레이턴시와 데이터 정합성 문제를 방어하는 코드를 짜는 데 집중했습니다.
결국 그 프로젝트는 어떻게 되었을까요? 2년 뒤, "전략적 피벗"이라는 허울 좋은 명분 아래 조용히 종료되었습니다. 수십억의 매몰 비용이 발생했지만, 회사는 "많은 것을 배웠다"며 자위하더군요.
가슴 아픈 일입니다. 하지만 제가 그때 온몸으로 그 프로젝트를 막아섰다면, 과연 성공했을까요? 아니요. 저만 화상을 입고 튕겨 나갔을 겁니다.
후배님, 당신의 기술적 식견이 틀린 게 아닙니다. 저 아키텍처는 분명 문제가 있고, 언젠가 기술 부채라는 이자를 쳐서 우리를 괴롭힐 겁니다. 하지만 지금 당신의 영향력 계좌 잔고를 확인해 보세요. 지금 이 문제와 싸울 만큼 충분한 자산이 쌓여 있습니까?
시니어 개발자가 된다는 건, 코드를 잘 짜는 것을 넘어 '어떤 싸움에 참전할지'를 결정하는 일입니다. 세상의 모든 버그를 잡을 수 없듯, 세상의 모든 실패한 프로젝트를 막을 수도 없습니다. 때로는 눈앞의 불길을 보면서도, 더 큰 산불을 막기 위해 소방수를 아끼는 냉정함이 필요합니다.
우리는 신이 아닙니다. 그저 한정된 리소스와 영향력을 가진, 월급 받는 기술자일 뿐입니다. 부디 당신의 소중한 열정을 이길 수 없는 싸움에 소모하지 마십시오. 진짜 위기가 닥쳤을 때, 단 한 번의 결정적인 "No"를 외치기 위해 지금은 묵묵히 칼을 갈아두는 것이 더 현명할지도 모릅니다.
