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

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

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

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

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

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

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

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

개입 시점 판단 기준

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

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

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

결론

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