필사 모드: 엔지니어의 조직 정치력 완전 가이드: 권력·Pfeffer·Political Capital·Alliance·Stakeholder·Lencioni·Promotion까지 (2025~2026)

> "Politics is the art of getting things done in a world of competing interests and scarce resources." — Jeffrey Pfeffer

"정치"라는 단어에 엔지니어는 본능적으로 거부감을 느낀다. 그러나 Staff+ 엔지니어·테크리드·아키텍트로 갈수록 **기술 실력만으로는 아무것도 못 바꾼다**. 좋은 아이디어가 조직을 통과하려면 "정치력"이 필수다.

문제는 단어의 오염이다. 우리는 "정치"를 "조작·모사"와 동의어로 썼다. 실제 조직 정치는 **사람·이해관계·맥락을 읽고 움직이는 공학**이다.

이 글은 Jeffrey Pfeffer의 Stanford 고전 강의, Patrick Lencioni의 조직 심리, 실리콘밸리 Staff+의 암묵 지식을 엮어 엔지니어가 **선한 정치력**을 시스템으로 구축하도록 돕는다.

1. 조직 정치의 재정의

1.1 Bad Politics vs. Good Politics

| Bad Politics | Good Politics |

|---|---|

| 제로섬, 본인 이득 | 포지티브섬, 조직 이득 |

| 뒤에서 모함 | 공개 논쟁 |

| 정보 독점 | 정보 공유 |

| 관계 악용 | 관계 투자 |

| 단기 승리 | 장기 신뢰 |

| "나" 중심 | "우리" 중심 |

**두 정치의 기법은 같다.** 차이는 **의도·방향·지속성**이다. Good Politics는 선한 일을 **실제로 일어나게 만드는** 기술이다.

1.2 왜 엔지니어는 정치력 약한가

- **기술 = 진리** 신념: 좋은 아이디어는 스스로 이길 것이라 믿음.

- **개인주의:** 혼자 잘하면 된다.

- **Honest 과신:** "나는 정직하니까 충분" — 정치 기법을 도덕적으로 거부.

- **Signal 경시:** 내용만 중요, 포장은 경시.

- **권력 회피:** 권력을 원하는 것을 부끄러워함.

결과: **좋은 아이디어가 계속 거절당하는 경험**을 반복.

1.3 정치력 없이 일어나는 일

- 당신의 Proposal이 무시됨.

- 옆 팀의 열등한 제안이 채택됨.

- 승진에서 누락.

- 예산 배정 탈락.

- Reorg 때 불리한 위치.

- 본인의 성과가 다른 사람 공로로.

2. Pfeffer의 "Power" — 7가지 법칙

2.1 Jeffrey Pfeffer 소개

Stanford GSB 교수, "Power: Why Some People Have It — and Others Don't" 저자. 실리콘밸리 리더십의 필독서.

Pfeffer의 기본 주장: **"세상은 공정하지 않다. 능력만으로 성공하지 않는다. 정치는 스킬이고, 스킬은 배울 수 있다."**

2.2 Power의 7가지 자질

1. **Ambition (야망):** 권력을 원하는 것을 숨기지 말라.

2. **Energy:** 지속적 에너지, 장시간 집중력.

3. **Focus:** 한 가지에 과도하게 집중, 다른 것 희생.

4. **Self-Knowledge:** 본인의 강점·약점·트리거.

5. **Confidence:** 자신 있게 보여라 (실제와 별개).

6. **Empathy with Others:** 남이 원하는 것을 읽는 능력.

7. **Capacity to Tolerate Conflict:** 갈등을 버틸 수 있음.

2.3 Power의 7가지 전술

1. **Get Out of Your Own Way:** 자기 태도·자존심 극복.

2. **Break the Rules:** 관습보다 가치 창출.

3. **Look the Part:** Signal·Presentation 중요.

4. **Make a Powerful Impression:** 첫인상·언어 관리.

5. **Build a Reputation:** 특정 강점으로 알려지기.

6. **Build Networks:** Weak Tie 네트워크.

7. **Manage Your Brand:** 지속 관리.

2.4 엔지니어 적용

엔지니어가 자주 무시하는 것:

- **Signal (3번·4번):** "내용만 중요" 편향. 좋은 Presentation은 내용의 2배 효과.

- **Reputation (5번):** "뭐든 잘한다"보다 "X에 대해서는 그 사람"이 훨씬 강력.

- **Brand (7번):** 지속적으로 같은 주제 글·Talk로 내가 누구인지 환기.

3. Political Capital — 축적·지출·보충

3.1 Political Capital의 정의

**조직에서 내 요청·아이디어를 통과시키는 Reserve.** 돈과 같이:

- 축적 (저축).

- 지출 (사용).

- 보충 (재투자).

3.2 축적 방법 10가지

1. **Deliver:** 약속한 것을 약속 시간에.

2. **Above and Beyond:** 본인 역할 이상 기여.

3. **Help Others:** 동료 문제 해결 도움.

4. **Smart Compliments:** 구체적 칭찬 (Public).

5. **Advocacy:** 다른 사람 장점 홍보.

6. **Institutional Knowledge:** 조직 역사·맥락 지식.

7. **Network:** 다른 부서 관계.

8. **Brand:** 전문 영역 Reputation.

9. **Good Citizenship:** 팀·조직 기여.

10. **Presence:** 중요한 자리에 있음.

3.3 지출 상황

- Proposal 통과.

- Budget 확보.

- 인력 충원.

- 다른 팀 협업 요청.

- 큰 프로젝트 Lead.

- 승진 요청.

- Reorg 유리한 포지션.

**원칙:** 지출은 의도적으로, 신중하게. 작은 일에 낭비 금물.

3.4 지출 후 보충

Capital 쓴 후 즉시 다음 축적 시작. Loan 상환 후 신용 회복과 유사.

3.5 Capital 고갈 신호

- 아이디어가 무시됨.

- Meeting Invite 탈락.

- Reorg에서 밀림.

- 승진 미뤄짐.

이럴 때 **Pause**하고 Capital 재축적. 계속 밀어붙이면 신뢰 붕괴.

4. Stakeholder Mapping

4.1 Stakeholder 2x2 (Power × Interest)

Power Low Power High

Interest High [Keep [Manage

Informed] Closely]

Interest Low [Monitor] [Keep

Satisfied]

- **Manage Closely:** VP·핵심 의사결정자. 정기 1:1, 선제적 공유.

- **Keep Satisfied:** 관심 없지만 영향력 큰 분 — 놀라지 않게.

- **Keep Informed:** 관심 많지만 영향력 작은 분 — 소통 유지.

- **Monitor:** 주변부, 큰 변화 시에만.

4.2 엔지니어 Proposal 전 Stakeholder 체크

1. 이 결정의 최종 책임자는?

2. 결정에 영향을 주는 사람 3~5명?

3. 각자의 Context·우려·목표?

4. 지금 각자와 내 관계 Capital은?

5. 사전에 동의 확보할 순서는?

4.3 Coalition Building

큰 변화는 **혼자 안 된다**. 지지자 3~5명 사전 확보:

- **Champion:** 당신의 아이디어 열정적 지지.

- **Supporter:** 동의하지만 적극 아님.

- **Neutral:** 설득 가능.

- **Skeptic:** 설득해야.

- **Blocker:** 우회 or Bypass.

4.4 1:1 Pre-meeting의 기술

공식 발표 전 핵심 Stakeholder와 **개별 1:1**:

- 본인 생각 Draft 공유 (최종 아님).

- 상대의 우려·입력 구함.

- Feedback 반영 약속.

- Endorsement 부드럽게 유도.

공식 회의에서 놀라는 사람 최소화 = 정치적 충돌 최소화.

5. Lencioni의 5 Dysfunctions of a Team

5.1 5층 피라미드 (아래부터)

1. **Absence of Trust:** Vulnerability 공유 불가.

2. **Fear of Conflict:** 가짜 조화, 진짜 문제 회피.

3. **Lack of Commitment:** 결정 후에도 적극 실행 안 함.

4. **Avoidance of Accountability:** 서로 책임 요구 안 함.

5. **Inattention to Results:** 개인 or 부서 이익 > 팀 목표.

5.2 엔지니어 조직에서 흔한 Dysfunction

- **Conflict Avoidance:** "문제 있지만 얘기 안 함" 문화.

- **Lack of Commitment:** 회의에서 합의, 나와서 각자 다른 방향.

- **Accountability 회피:** "내 담당 아님" 핑계.

5.3 해법 — Lencioni 프레임

- **Trust:** Personal Histories Exercise (팀 미팅에서 본인 과거 3분 공유).

- **Conflict:** Miscue 인지, 건강한 갈등 장려.

- **Commitment:** Cascading Messaging — 결정을 명확히 팀 공유.

- **Accountability:** Team Effectiveness Exercise — 서로 개선 요구.

- **Results:** Team Scoreboard — 개인 아닌 팀 지표.

5.4 엔지니어로서 Trust 축적

- **Vulnerability 먼저:** "나 이 부분 잘 모른다"고 솔직히.

- **Credit 양도:** 본인 기여를 공로화하지 말고 팀 공로화.

- **Mistake 공개:** 실수 공유가 신뢰 생성 (심리적 안전).

- **Listen First:** 회의에서 먼저 듣기.

6. Push vs Pull 영향 전략

6.1 Push — 강한 주장

- **Direct Request:** "X를 해주세요."

- **Logical Argument:** 근거·데이터로 설득.

- **Authority:** 권한 사용.

- **Pressure:** 마감·긴급성 강조.

**적합:** 권한 있을 때, 시간 촉박할 때, 명확한 이슈.

**단점:** 저항·반발 가능.

6.2 Pull — 유인·공감

- **Inquiry:** 질문으로 상대 생각 끌어냄.

- **Vision Sharing:** 큰 그림 제시, 상대가 Join 선택.

- **Appeal to Value:** 상대 가치·목표와 연결.

- **Listening:** 상대 의견 경청 후 통합.

**적합:** 권한 없을 때, 장기 관계, 복잡한 이슈.

**장점:** 지속 가능한 동의.

6.3 상황별 선택

| 상황 | 전략 |

|---|---|

| 화재 같은 긴급 | Push |

| 장기 변화 | Pull |

| 상대 권한 ↑ | Pull |

| 상대 권한 ↓ | Push 가능 |

| 복잡한 이슈 | Pull |

| 명확한 이슈 | Push |

| 새 관계 | Pull |

| 신뢰 관계 | 혼합 |

6.4 Push·Pull Switch 실전

- 시작 Pull → Resistance 적으면 Push로 가속.

- 시작 Push → Resistance 크면 Pull로 재정렬.

경직되지 말고 유연하게.

7. 갈등 관리 — 생산적 갈등의 기술

7.1 갈등 5 유형 (Thomas-Kilmann)

1. **Competing (경쟁):** 본인 주장 강력.

2. **Accommodating (순응):** 상대 원하는 대로.

3. **Avoiding (회피):** 갈등 자체 피함.

4. **Compromising (타협):** 중간.

5. **Collaborating (협력):** Win-Win 탐색.

**엔지니어 평균 편향:** Avoiding 과다. Collaborating 부족.

7.2 Hard on Problem, Soft on People

Fisher & Ury의 "Getting to Yes" 핵심:

- **내용:** 강력하게.

- **관계:** 부드럽게.

- **구분:** 아이디어 비판 ≠ 사람 비판.

7.3 갈등 해소 5단계

1. **Listen First:** 상대 입장 완전히 이해.

2. **Reframe:** Position(입장) → Interest(이익) 전환.

3. **Explore Options:** 제3의 해법.

4. **Use Objective Criteria:** 공정한 기준.

5. **Commit:** 합의와 실행 계획.

7.4 Disagree and Commit

Amazon Leadership Principle. 토론 시 의견 충분히 나누고, 결정 후 **모두가 Commit**.

엔지니어 적용: 설계 회의에서 주장 강력히, 결정 후 뒷말 금지. Execution에 집중.

8. Promotion 정치 — Staff/Principal 승진

8.1 Promotion은 사건이 아니라 Process

- 6~18개월의 Campaign.

- 승진 시즌 전 준비 아니면 늦음.

8.2 Promotion의 3요소

1. **Scope Expansion:** 책임·영향 넓힘.

2. **Evidence:** 그걸 수행했다는 증거.

3. **Advocacy:** 본인 아닌 남이 이야기.

8.3 Campaign 18개월 플랜

**Month 1~6: Scope 확대**

- 다음 레벨 일을 지금 시작.

- Cross-team 프로젝트 Lead.

- Mentor 2~3명.

**Month 7~12: Evidence 축적**

- 임팩트 문서화.

- Promo Packet 초안.

- Skip-level 1:1 정기.

**Month 13~18: Advocacy**

- Manager에게 공식 의사 전달.

- Sponsor 확보.

- 동료 추천서 준비.

8.4 Promo Packet 구조

- **Scope:** 맡고 있는 영역·책임.

- **Impact:** 정량·정성 결과.

- **Leadership:** 멘토·Cross-team 기여.

- **Technical Depth:** 전문성 증거.

- **Level Expectations:** 다음 레벨 기대치 충족.

- **Letters:** 동료·Skip-level·Cross-team 추천.

8.5 승진 실패 시

- **1차:** 재도전 Plan 6개월.

- **2차:** Manager와 Root Cause 대화.

- **3차:** 팀·회사 이동 고려.

9. Reorg에서 살아남기

9.1 Reorg 신호 포착

- VP·Director 이탈.

- 전략 문서 변화.

- 예산 방향 변화.

- 옆 팀 Headcount 이동.

- Manager의 미묘한 언어 변화.

9.2 Reorg 사전 대응

- Cross-team 관계 구축 (Manager Skip 네트워크).

- 본인 임팩트 문서화.

- 여러 방향에 걸친 Skill·Project.

- 외부 옵션도 탐색 (시장 가치 확인).

9.3 Reorg 중

- **Panic 금지:** 감정 반응은 판단 망침.

- **정보 수집:** 사실 vs. 루머 구분.

- **선택적 공유:** 누구에게 무엇을.

- **Public Stability:** 팀에 동요 안 보이기 (리더라면).

9.4 Reorg 후

- 새 Manager와 빠른 1:1.

- 새 전략에 본인 포지션 맞춤.

- 기존 관계 유지.

- 3개월 Plan 재작성.

10. 예산·Headcount 확보

10.1 예산 정치의 기본

- 예산은 **추상적 숫자가 아니라 다른 팀에서 뺏어오는 것**.

- 나의 +1 = 다른 팀의 -1.

- 정당성·Business Case 필수.

10.2 Headcount 요청 프레임

요구: Backend 엔지니어 2명.

Rationale:

- Q2 RDS 마이그레이션 Critical Path.

- 현재 팀으로 완료 시 6개월, 2명 추가로 3개월.

- 3개월 단축 시 ARR $5M 추가 가능 (ROI 10배).

Alternative: 없음 (외부 컨설턴트는 도메인 지식 부족).

Backup Plan: 1명만 받으면 4.5개월로 2개월 단축.

ROI·Alternative·Backup 세 가지가 통과율 높임.

10.3 Sponsor 확보

- Budget 결정자와 사전 대화.

- 공식 요청 전 Informal 엔도스먼트.

- 다른 팀 Leader 지지 (연합).

10.4 Fallback

- 전부 못 받으면 반이라도.

- Contractor·Intern·파트타임 대안.

- Tool·플랫폼 자동화로 부족 인력 상쇄.

11. 엔지니어가 흔히 잊는 정치력 5

11.1 Signal > Substance (부분적으로)

- 같은 아이디어도 **누가 말하느냐**로 결과 다름.

- "Signal 없이 Substance만" 은 이상. 현실은 **Substance + Signal**.

11.2 Timing 기술

- 금요일 오후 Proposal = 월요일 잊힘.

- Budget Cycle 직전 = 내년으로 미룸.

- 위기 직후 = 확장 어려움.

- Quiet 월요일 오전 or 예산 Cycle 시작 = 이상적.

11.3 Framing 효과

- 같은 사실도 **프레임**으로 받아들임 달라짐.

- "비용 $X" vs "손실 방지 $X" — 후자가 통과율 30% ↑ (Kahneman).

- 엔지니어 번역: "이 리팩토링은 비용"이 아니라 "이 리팩토링 안 하면 손실".

11.4 Face-saving

- 상대 의견 틀리다고 공개 망신 = 평생 적.

- 조용히 데이터로·개인적으로 수정.

- 공개에서는 Face 지켜주기.

11.5 Reciprocity의 복리

- Cialdini "Influence"의 가장 강력한 원칙.

- 작은 호의를 먼저 주면, 수십 배 돌아옴.

- 엔지니어 번역: Review 먼저, 추천 먼저, 소개 먼저.

12. 정치력 안티패턴 10

1. **"정치 안 해" 자부심:** 정치력 0은 Staff+ 불가.

2. **뒤에서 비판:** 신뢰 파괴.

3. **회의 후 재논의:** Disagree 후 Commit 깨기.

4. **Credit 혼자 차지:** 동료 소외.

5. **Skip-level 건너뛰기 (비정상적):** Manager 관계 훼손.

6. **VP만 집중:** Middle 관리자 소외.

7. **Conflict 회피만:** Lencioni 2층 Dysfunction.

8. **Capital 반복 지출:** 충전 없이 고갈.

9. **"내가 옳다" 고집:** 틀렸을 때 인정 안 함.

10. **인간을 자원으로:** 관계를 계산으로만 봄.

13. 정치력 체크리스트 12

- [ ] Bad vs Good Politics 구분 이해.

- [ ] Pfeffer Power 7 자질 자가 평가.

- [ ] 본인 Political Capital 진단.

- [ ] Stakeholder 2x2 매핑.

- [ ] Champion·Supporter 3~5명 확보.

- [ ] 1:1 Pre-meeting 습관.

- [ ] Disagree and Commit 실천.

- [ ] Push/Pull 상황별 선택.

- [ ] 갈등 5 유형 본인 기본 모드.

- [ ] Promo Campaign 6개월 선행.

- [ ] Reorg 신호 모니터링.

- [ ] 분기별 정치력 Self Review.

14. 정치력 추천 도서 10

1. **"Power" — Jeffrey Pfeffer.**

2. **"7 Rules of Power" — Jeffrey Pfeffer.**

3. **"The Five Dysfunctions of a Team" — Patrick Lencioni.**

4. **"Influence" — Robert Cialdini.**

5. **"Getting to Yes" — Fisher & Ury.**

6. **"Crucial Conversations" — Patterson et al.**

7. **"Never Split the Difference" — Chris Voss.**

8. **"Thinking, Fast and Slow" — Daniel Kahneman.**

9. **"The 48 Laws of Power" — Robert Greene (경고: Dark 쪽).**

10. **"Staff Engineer" — Will Larson.**

15. 마무리 — 정치는 피할 수 없다, 설계하라

> "Power is the great aphrodisiac." — Henry Kissinger

엔지니어에게 "정치"는 더러운 것이 아니다. 그것은 **사람과 사람 사이의 물리학**이다. 물리를 모르면 로켓을 쏠 수 없고, 정치를 모르면 좋은 아이디어를 통과시킬 수 없다.

2026년, AI가 기술적 구현을 상당 부분 자동화하면서, Staff+ 엔지니어의 가치는 점점 **조직을 움직여 좋은 일이 일어나게 하는 능력**에 있다. 이것이 바로 선한 정치력이다.

기억할 3가지:

1. **Political Capital은 돈처럼 축적·지출·보충.**

2. **Stakeholder Map을 사전에 그리고, 1:1 Pre-meeting.**

3. **Good Politics = 조직 이득 + 관계 투자 + 장기 신뢰.**

시작은 이번 주 1가지면 된다: 당신의 다음 Proposal 전, 핵심 Stakeholder 3명과 1:1 Pre-meeting을 잡아라. 공식 회의에서 놀라는 사람이 없어지는 순간, 당신의 승률은 두 배가 된다.

다음 글 예고 — "엔지니어와 예술: 코드의 美·디자인·음악·글쓰기·사진·Craft 완전 가이드"

조직 정치가 "다른 사람과 일하는 법"이라면, 예술은 "나 자신과 일하는 법"이다. 다음 글은:

- 코드의 美 — Knuth "Literate Programming", Code Poetry

- 디자인 원칙 — Dieter Rams 10, Paul Rand

- 음악과 엔지니어 뇌 — Hofstadter "Gödel, Escher, Bach"

- 글쓰기로서의 프로그래밍 — Paul Graham, Julia Evans

- 사진의 Eye 훈련 — Composition, Light, Moment

- Craft 정신 — Kelly Johnson, Richard Sennett

- AI 시대 Human Craft의 의미

기술과 예술은 분리된 두 세계가 아니다. 시리즈 2부의 하이라이트, 다음 글에서 이어진다.