Velog
시니어 개발자들은 왜 잘못된 프로젝트를 말리지 않을까?
시니어는 실패를 예측해도 조용히 둔다. 옳은 것과 효과적인 것은 다르다는 통찰과 영향력을 은행 계좌처럼 관리하는 전략을 다룬다.
핵심 요약
시니어가 잘못된 프로젝트를 보고도 말리지 않는 이유는 무관심이 아니라 전략적 선택이다. 저자는 영향력을 은행 계좌에 비유한다. 사소한 지적에도 잔고가 소모되며, 잔고가 바닥나면 정치적 파산 상태가 되어 조직이 더 이상 의견을 묻지 않는다. 개입 여부는 세 가지 축으로 판단한다: 근접성(proximity), 팀에 미치는 영향, 회사 전체 피해 규모. 개입하지 않을 때도 손 놓는 게 아니라 의존도 축소, 추상화 계층, 핵심 아이디어 흡수 같은 그림자 대비책을 준비한다. 핵심 통찰은 "옳은 것과 효과적인 것은 다르다".
이 글을 영향력(credibility)은 유한한 자본이라는 프레임으로 읽으세요. 잘못된 프로젝트를 막는 것은 옳지만, 매번 개입하면 계좌는 파산합니다. 질문은 "이게 틀렸나?"가 아니라 "지금 출금할 가치가 있는가?"입니다. 시니어십은 전지적 기술 판단이 아니라 근접성 × 팀 영향 × 조직 피해를 저울질하는 정치적·경제적 의사결정입니다.
면접에서 "동료가 잘못된 방향으로 갈 때 어떻게 하느냐"는 단골 질문입니다. 평범한 답변은 **"즉시 피드백합니다"**지만, 시니어 레벨은 다음을 구분할 줄 알아야 합니다.
- 모든 문제에 개입하면
부정적인 사람으로 낙인찍혀 정작 중요한 순간에 목소리를 잃는다 옳은 판단과효과적인 판단은 다르며, 둘 중 하나를 고를 줄 아는 게 협업 성숙도다- 개입하지 않는 선택도 전략적 행동이다 — 대비책 마련, 추상화 계층, 핵심 아이디어 흡수
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
영향력 = 은행 계좌
모든 반대 의견은 잔고에서 수표를 끊는 행위다. 저자는 세 가지 규모를 제시한다.
| 수표 규모 | 행동 예시 | 빈도 |
|---|---|---|
| 5,000원 | 코드 리뷰 사소한 지적 | 일상 |
| 500,000원 | 아키텍처/일정 반대 | 가끔 |
| 50,000,000원 | 임원이 아끼는 프로젝트 중단 | 몇 년에 한 번 |
성실한 개발, 동료 지원, 성공적 출시는 매달 입금이 된다. 잔고 없이 출금하면 정치적 파산 — 회의 초대가 끊기고 의견을 묻지 않는다.
모든 작은 비효율에 5,000원짜리 수표를 남발하는 것. 정작 재앙을 막아야 할 때 잔고는 비어 있다. "품질 지키는 개발자"가 어느 순간 "부정적인 사람"으로 라벨이 바뀐다.
옳음 vs 효과성
주니어는 논리적으로 옳으면 받아들여진다고 믿는다. 시니어는 회사가 그렇게 움직이지 않음을 안다.
- 들을 생각이 없는 사람과 논쟁하는 건 신뢰만 소모
- 재앙을 막아도 공은 돌아오지 않음 — 아무 일도 없었기 때문에 기억되지 않음
- 반대할 때마다 누군가의 평가나
아끼는 프로젝트(pet project)를 건드림 → 적을 만듦
"6개월 뒤에는 아무도 내 말이 맞았다는 걸 기억하지 않는다. 그저 프로젝트를 막으려 했던 사람으로 기억할 뿐."
팩트와 논리로 설득하면 이긴다고 가정하는 것. 소프트웨어 회사는 행동과 속도를 우선시하므로, 우려 제기는 프로젝트를 느리게 만드는 행위로 해석된다.
개입 결정 3축
개입 여부는 세 가지 질문으로 판단한다.
- 근접성: 우리 팀에 얼마나 가까운가? 팀 내부면 비용 ≈ 0, 조직 바깥이면 비용 ≈ 감당 불가
- 팀 영향: 실패 시 우리 팀이 뒷수습해야 하는가? (예: 우리 플랫폼에 의존하는 경우)
- 회사 피해: 단일 프로젝트 실패인가, 수년간 지속될 기술 부채인가?
| 조건 | 개입? | 방법 |
|---|---|---|
| 팀 내부, 가까움 | O | 1:1 대화 |
| 조직 겹침, 우리 팀 피해 예상 | O | 강한 우려 문서 |
| 조직 바깥, 단일 실패 | X | 거리두기 |
| 조직 바깥, 핵심 시스템 위협 | O | 리더 경유 공식 제기 |
전문성 검증을 건너뛰는 것. 저자는 "프론트엔드는 어느 정도 하지만 깊이 있는 조언을 할 만큼은 아니다"라고 자기 평가한다. 그럭저럭 수준의 의견을 전문가 의견처럼 내면 신뢰만 깎인다.
개입하지 않을 때의 시니어십
개입하지 않기로 결정했다고 손 놓는 게 아니다. 시니어는 조용한 대비책을 마련한다.
- 해당 프로젝트에 대한 의존도 축소
- 프로젝트가 사라져도 버틸 수 있는 추상화 계층 삽입
- 잘못된 프로젝트 속의 좋은 아이디어의 핵심만 뽑아 내 프로젝트에 자연스럽게 흡수
- 팀에게는 회사 공식 입장을 앵무새처럼 따라하지 말고 확인된 사실은 솔직히 공유 (단, 정치적 뒷이야기는 금지)
이것이 **"방해꾼이 아니라 도와주는 사람"**으로 보이는 방법이다.
팀원들에게 회사 공식 입장을 그대로 전달하며 문제 없는 척 포장하는 것. 다른 시니어들도 같은 문제를 보고 있기 때문에 신뢰가 한 번에 무너진다.
읽는 순서
- 1이론
글을 읽으며 영향력 계좌, 근접성, 옳음 vs 효과성 세 키워드의 정의를 각각 1문장으로 적어보세요. 저자가 든 구글 사례(플랫폼 팀 vs 플래그십 팀)가 왜
정치적으로 불가능했는지 자기 말로 설명할 수 있어야 합니다. - 2적용
최근 1년간 자신이 동료/타 팀에 이의 제기한 사례 3가지를 떠올려 각각
5,000원 / 500,000원 / 5,000만원수표 중 어디에 해당하는지 분류해보세요. 과도하게 소액 지출을 하고 있지는 않은지 점검합니다. - 3실무
지금 팀 안팎에서 진행 중인 프로젝트 하나를 골라 근접성 × 팀 영향 × 조직 피해 3축으로 평가지를 만들어 보세요. 개입 결정이라면
방식(1:1 / 문서 / 공식 제기)까지, 비개입이라면추상화 계층 / 의존도 축소 / 아이디어 흡수중 어떤 대비책을 세울지 적어봅니다. - 4설명
멘티 또는 동료에게 **"옳은 것과 효과적인 것은 왜 다른가"**를 5분 안에 설명해보세요. 저자의 구글 사례와 영향력 계좌 비유를 포함해야 하며, "그럼 항상 침묵하라는 말인가?"라는 반박에
개입 3축으로 반론할 수 있는지 확인합니다.
면접 연결 질문
[감점 답변] "즉시 1:1로 피드백합니다" 같은 단일 해법. 언제/왜/어떻게의 판단 기준이 없다. [좋은 답변] 세 가지 축으로 판단한다고 답하세요.
근접성: 내 팀이면 비용이 낮으니 바로 대화, 조직 바깥이면 신중피해 규모: 사용자 경험·기술 부채 중 어디에 어떤 영향인가전문성 자기평가: 내 의견이그럭저럭 수준인지깊은 경험인지
트레이드오프로 **"매번 반대하면 정작 중요할 때 목소리를 잃는다"**는 영향력 계좌 논리를 언급하면 시니어 관점이 드러난다.
[감점 답변] "때와 장소를 가려야죠" 같은 동어반복. [좋은 답변] 구체적 메커니즘을 드세요.
- 기술적으로 옳은 아키텍처라도 조직 구조가 허락하지 않으면 실패 (저자의 구글 사례: 플랫폼 팀이 플래그십 팀에 통제권을 내주어야 하는 설계 → 정치적으로 불가능)
- 논리 승리 ≠ 결정권 획득. 회사는
행동과 속도를 우선시하므로 우려 제기는 속도 저하로 해석됨 - 재앙을 막아도 "아무 일도 없었으므로" 공이 돌아오지 않음
옳음의 비용이 효과성의 이익을 넘어서는 임계점을 설명하면 훌륭합니다.
[감점 답변] 비유만 반복. [좋은 답변] 입출금 메커니즘을 구체화하세요.
- 입금: 성실한 개발, 동료 지원, 성공적 출시, 조직 마찰 최소화
- 출금 규모: 코드 리뷰 지적(소) / 아키텍처 반대(중) / 임원 프로젝트 중단(대)
- 파산 증상: 회의 초대 중단, 의견 요청 중단, 사실상 무시
실무 적용으로는 **"사소한 비효율 대부분은 넘기고, 우리 팀 피해가 예상되거나 장기 기술 부채를 만들 때만 큰 수표를 쓴다"**는 원칙을 제시하세요. 신입 때와 시니어 때 잔고 규모가 다르다는 점도 덧붙이면 좋습니다.
자기 점검
"시니어가 게으르거나 비겁해서"라고 오해하는 것. 실제로는 영향력의 유한성과 개인 에너지의 한계 때문이다. 대기업에는 잘못된 아이디어가 너무 많아서 모두 막으려 하면 냉소적인 개발자가 되기 쉽다.
"개입 안 함 = 무시"로 생각하는 것. 시니어는 조용히 기술적 완충장치(추상화 계층, 의존도 축소)를 심어두고, 잘못된 프로젝트 속의 좋은 아이디어만 흡수해 자기 프로젝트를 강화한다.