# 왜 시니어 엔지니어들은 나쁜 프로젝트를 그냥 두는가 > Clean Markdown view of GeekNews topic #25884. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25884](https://news.hada.io/topic?id=25884) - GeekNews Markdown: [https://news.hada.io/topic/25884.md](https://news.hada.io/topic/25884.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-17T05:32:59+09:00 - Updated: 2026-01-17T05:32:59+09:00 - Original source: [lalitm.com](https://lalitm.com/post/why-senior-engineers-let-bad-projects-fail/) - Points: 23 - Comments: 1 ## Summary 시니어 엔지니어는 모든 **‘나쁜 프로젝트’** 를 막기보다, **영향력을 전략적으로 사용**해 개입 시점을 선택합니다. 영향력은 **은행 계좌처럼 축적되고 인출되는 자산**으로, 사소한 반대에 낭비하면 중요한 순간에 설득력을 잃게 됩니다. 결국 옳음을 증명하기보다 **효과적으로 행동**하는 것이 조직 내 **지속 가능한 리더십**의 핵심입니다. ## Topic Body - **시니어 엔지니어는 ‘옳음’보다 ‘효과적 행동’을 중시**, 모든 잘못된 프로젝트를 막으려 하지 않음 - **‘나쁜 프로젝트’** 는 기술적·정치적·UX적 문제를 포함하며, 종종 주관적 판단에 따라 달라짐 - **영향력은 은행 계좌처럼 관리해야 하며**, 자주 반대하면 신뢰를 잃고 ‘정치적 파산’ 상태에 빠질 수 있음 - 개입 여부는 **프로젝트의 거리, 팀 영향, 회사 전체 피해 규모**에 따라 결정 - 모든 문제를 해결하려 하기보다 **전략적으로 개입 시점을 선택하고, 나머지는 관찰과 대비로 대응**해야 함 --- ### 나쁜 프로젝트의 정의와 사례 - ‘나쁜 프로젝트’는 **불필요한 문제 해결, 복잡한 설계, 정치적 동기** 등 다양한 형태로 나타남 - UX 측면에서는 존재하지 않는 문제를 해결하거나 기존 흐름을 깨뜨리는 경우 - 기술적으로는 **과도한 복잡성, 잘못된 라이브러리 선택, 비효율적 아키텍처** - 정치적으로는 **승진이나 유행 추종을 위한 프로젝트** - 프로젝트의 좋고 나쁨은 **시간이 지나야 드러나는 주관적 판단**이며, 초기에는 명확하지 않음 - Google에서의 사례로, **플랫폼 팀이 핵심 사용자 흐름을 다른 팀에 넘기려 한 프로젝트**가 정치적 이유로 실패 - 기술적으로는 훌륭했지만, **조직 간 권한 문제**로 2년 후 폐기됨 - “정치와 문제 정의의 정확성은 기술적 완성도만큼 중요함”이라는 교훈 제시 ### 모든 나쁜 프로젝트를 막을 수 없는 이유 - 소프트웨어 기업은 **‘빠른 실행’ 편향**이 강해, 우려 제기는 속도를 늦추는 행위로 인식됨 - 따라서 **큰 문제로 인식되지 않으면 무시될 가능성 높음** - 반복적인 반대는 **‘부정적 인물’로 낙인**찍히며, 예방한 실패는 인정받지 못함 - 반대는 **타인의 승진이나 고위 임원의 프로젝트**에 영향을 줄 수 있어 정치적 위험 존재 - **한 명의 엔지니어가 감당할 수 있는 주의력은 한정적**이며, 모든 문제에 개입하면 냉소적으로 변함 ### 영향력을 ‘은행 계좌’처럼 관리 - 영향력은 **성과와 협업으로 축적되는 자산**이며, 반대할 때마다 인출됨 - **$5 체크:** 코드 리뷰 수준의 사소한 지적 - **$500 체크:** 아키텍처 결정이나 일정에 대한 반박 - **$50,000 체크:** 임원급 프로젝트 중단 시도 - 사소한 문제에 반복적으로 개입하면 **큰 사안에 대응할 여력 상실** - 영향력이 고갈되면 **회의 초대 제외, 의견 무시 등 ‘정치적 파산’** 상태로 전락 ### 개입 시점 판단 기준 - **전문성 검증:** 자신의 판단이 충분히 근거 있는지 확인 - **발언의 한계 인식:** 의견 제시는 ‘명령’이 아니라 ‘관점 공유’임 - 세 가지 판단 요소 - **근접성(Proximity):** 자신의 팀과 가까울수록 개입 비용이 낮음 - **팀 영향(Team Impact):** 실패 시 팀에 직접적 피해가 예상되면 개입 가치 높음 - **회사 규모(Company Scale):** 실패가 조직 전체에 미치는 영향이 크면 개입 필요 ### 나쁜 프로젝트에 대한 대응 방식 - **직접 개입:** 프로젝트 중단을 요구하거나 강한 우려 문서를 제출 - 확신과 리스크 감수 필요 - **부분 개입:** 설계 방향을 조정하거나 더 나은 해결책으로 유도 - 협력적 태도로 접근 시 **‘도움 주는 사람’으로 인식** 가능 - **비개입:** 정치적 관성이나 영향력 한계로 개입 가치가 낮을 때 - 팀이 관련 있다면 **의존도 축소나 대안 구축 등 대비책 마련** - 관련 없을 경우 **조용히 관찰하며 내부적으로만 의견 공유** - **팀 관리:** 구성원에게 현실을 솔직히 공유하되, 불필요한 정치적 세부사항은 배제 ### 결론 - **“옳음과 효과성은 다르다”** 는 인식이 핵심 - 대기업에서는 **논리보다 정치와 맥락이 작동**하며, 모든 잘못을 바로잡을 수 없음 - **영향력과 신뢰를 전략적으로 사용**해 실제 변화를 만들 수 있는 순간에 집중해야 함 - 나머지 경우에는 **동료와 공유하고, 대비하며, 관찰을 통해 학습** - 완벽히 해결하지 못하더라도, **이 접근이 지속 가능한 방식**임 ## Comments ### Comment 49364 - Author: neo - Created: 2026-01-17T05:32:59+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46640366) - 예전에 한 매니저가 “가끔은 사람을 **실패하게 놔둬야 한다**”고 말했던 게 떠오름 어떤 사람들을 계속 떠받치는 데 너무 많은 에너지가 들었음. 언젠가는 스스로 헤엄치길 바랐지만, 때로는 그 노력이 더 나은 곳에 쓰이는 게 맞았음 내 참여 없이 진행된 프로젝트가 있었는데, 내 지식 없이는 절대 성공할 수 없었음. 그 팀은 너무 형편없어서 질문을 일처럼 섞어가며 일했음 게다가 경영진이 내 팀을 깎아내리고 그들을 칭찬한다는 걸 알게 되었을 때 정말 **모욕감**을 느꼈음. 그들의 구현은 끔찍했음 - 나는 “가끔은 **매니저를 실패하게 놔둬야 한다**”고 자주 말함 어떤 매니저들은 자신의 아이디어가 안 통한다고 말하는 걸 싫어함. 반박하면 실패의 원인으로 몰림 그래서 나는 일을 진행하되, 그들에게 자주 상황을 공유함. 그래야 그들이 예상된 실패를 직접 보게 되고, 나를 실패와 분리시켜줌 - 경영진이 실패하면 서로를 탓하지 않음. 대신 **컨설턴트**를 불러 시니어 엔지니어를 해고함 - “사람은 스스로 데이터를 모아야 한다”는 말을 들은 적 있음. 결국 직접 부딪혀봐야 배움 - 사람의 실패와 프로젝트의 실패는 다르다고 생각함 개인의 실패는 비용이 적고 교육적임. 오히려 그들의 접근이 통할 때도 있어 조직이 새로운 **지식 자산**을 얻기도 함 - 사람을 스스로 배우게 두는 건 위험한 일임. 그들이 자기 인식을 갖고 있는지, 내 지원에 기대고 있지 않은지 믿어야 함 실패하고 배우지 못할 수도 있음. 하지만 최선을 다했다면 **양심의 평안**은 가질 수 있음 - 프로젝트의 “나쁨”은 대부분의 생애주기 동안 **주관적**임 외부인이 프로젝트를 반대하며 중단시키려 한 적이 있었는데, 끝내 출시해 성공하자 그들의 신뢰가 무너졌음 평판을 어디에 쓸지 신중해야 함 - 나도 비슷한 일을 겪었음. 협업을 위한 조직에서 이렇게 노골적인 **이기심**을 본 건 처음이었음 세상은 항상 햇살과 무지개로 가득하지 않다는 걸 알지만, 그때는 정말 실망스러웠음 - “내 원숭이 아님, 내 서커스 아님”이라는 말처럼, 내 책임이 아닌 일엔 관여하지 않음 아키텍트로 일할 때도 내 영역이 아닌 UI나 비즈니스 로직엔 **불필요한 조언**을 하지 않았음 상위 매니저가 결정한 일엔 그냥 따름. 컨설턴트로 일하면서도 같은 원칙을 지킴 내 전문 분야에서만 조심스럽게 개입함. 그것도 **C-suite의 승인**이 있을 때만 함 - 이 조언은 중소기업엔 꽤 적절함. 하지만 대기업에선 프로젝트에 반대 의견을 내는 게 거의 의미 없음 성공하면 바보처럼 보이고, 실패해도 기억되지 않음 진짜 **ROI**는 실패 후 해결책을 제시할 때 생김. 사람들은 “문제 해결사”를 좋아함 예전에 자동화된 E2E 테스트를 제안했다가 거절당했는데, 나중에 문제가 터지자 그 프레임워크를 꺼내와 **영웅 취급**을 받았음 - 회사에서 위로 올라갈수록 남의 잘못에 책임을 져야 하고 보상은 적음 차라리 **하위 직급**에서 스트레스 없이 사는 게 현명하다고 느낌 - 스타트업은 몇 명의 엔지니어가 “이건 말도 안 돼”라고 말하면 재앙을 막을 수 있음 반면 대기업은 **정치** 때문에 수년과 수백만 달러를 낭비함 - “문제를 무시하면 안 된다”는 입장임 도울 수 있는 위치라면 조용히라도 **다른 접근법**을 제안해야 함. 굳이 감정적으로 대응할 필요는 없음 - “도울 수 있는 위치”라는 조건이 핵심임 작은 조직에선 좋은 아이디어가 쉽게 반영되지만, 큰 조직에선 **정치적 리스크**가 훨씬 큼 실제로 도울 확률보다 평판을 잃을 확률이 더 높음. 그래서 싸움을 고르는 게 중요함 - 작은 조직에선 초기에 개입하는 게 의무일 수도 있음 하지만 큰 조직에서 이미 진행 중인 프로젝트를 바꾸려면 **막대한 시간과 에너지**가 듦 - “나쁜 프로젝트를 그냥 두라”는 표현은 오해의 소지가 있음 사실 우리는 그 프로젝트를 통제할 수 없을 때가 많음. “다른 팀이 왜 그렇게 하는지 모른다”가 더 정확한 제목임 - 나도 실패가 예상되면 문서로 의견을 남기고 끝냄 **프로페셔널리즘**이란 말해야 할 때 말하는 것임. 하지만 경험상 바뀌는 일은 거의 없음 - 알고 있다면 말하되, 그 후엔 **감정적 부담**을 지지 않음. 조언을 무시당했다면 그건 내 문제가 아님 - 지금 실제로 이런 상황을 보고 있음 사업주가 비용과 속도 때문에 **로우코드 플랫폼**을 선택했는데, 결국 거대한 해킹 수준의 커스터마이징이 필요해짐 내 팀은 TypeScript로 하루에도 여러 번 배포하지만, 그 팀은 한 달에 한 번 배포하며 curl로 이상한 짓을 하고 있음 - 이 조언은 빅테크의 **정치적 현실**에선 훌륭하지만, 결국 기업적 평화주의 같음 다른 환경에서는 돈과 동기를 태워버릴 여유가 없음 (그래도 Lalit은 복잡한 조직 역학을 짧은 글에 잘 담음) - 나는 빅테크에서 일해본 적 없지만, 작은 조직에서도 같은 현상을 봄 계속 트집 잡는 사람은 결국 **부정적인 사람**으로 낙인찍힘 결국 중요한 순간을 위해 **에너지를 아껴두라**는 게 핵심 조언임. 모든 문제가 회사의 존망을 좌우하진 않음 - **평화주의**는 무행동이 아님. 오히려 가장 적극적이고 효과적인 정치적 행동임 - 엔지니어는 정치적으로 나쁜 프로젝트를 “실패하게 놔둘” 권한이 없음 그건 **경영진의 책임**임. 엔지니어는 기술적 조언만 하면 됨 다만 이런 역학을 이해해야 커리어에 영향받지 않음 제품팀과 플랫폼팀의 **영역 다툼**은 명확한 리더십의 부재 때문임 이런 일이 왜 자주 일어나는지 궁금하다면, [Google 관련 글](https://news.ycombinator.com/item?id=46488819)을 참고할 만함 - 이런 사고방식은 대형 조직, 특히 **정부 기관**에서 흔함 비용은 다른 부서가 부담하고, 관리 인원 수로 권력을 측정하는 구조임 이런 **조직적 괴사**를 막으려면 리더가 명확한 측정과 예방 체계를 세워야 함 - 인간은 본능적으로 긍정적인 사람을 좋아하고 부정적인 사람을 싫어함 **정치적 자본**을 무시한다고 사라지지 않음 - 좋은 비유임 리더십과 신뢰를 쌓으면 “당신이 틀렸다”고 말할 수 있는 **공간**이 생김 하지만 리더가 항상 엔지니어를 믿지 않는 이유는, 때로는 **엔지니어가 틀리기 때문**임 엔지니어는 결함을 찾는 데 뛰어나지만, 비즈니스 맥락을 이해하는 데는 약함 그래서 “멍청해 보이는 아이디어”라도 맥락을 이해한 뒤 판단해야 함 진짜로 죽여야 할 아이디어와 그냥 결함이 있는 아이디어를 구분할 수 있을 때, 조직 내 **신뢰**를 얻게 됨