✍️ 필사 모드: 엔지니어의 조직 정치력 완전 가이드: 권력·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

두 정치의 기법은 같다. 차이는 의도·방향·지속성이다. 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 상황별 선택

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부의 하이라이트, 다음 글에서 이어진다.