상황을 떠올려보자. 어느 날 한 직원이 찾아온다. 편의상 조지라고 하자. 그는 당신의 ‘오픈 도어(직원 누구나 자유롭게 리더와 소통할 수 있는 조직 문화)’ 정책을 이용해 사무실로 들어왔다. 그런데 그 열린 문이 오히려 당신을 꼼짝 못 하게 만들었다.
조지는 단순한 잡담을 하러 온 게 아니다. 여유 시간에 비공식적으로 기술 아키텍처를 검토했고, 그 과정에서 시스템 계층과 스택에서 심각한 취약점을 여럿 발견했다.
만약 그 취약점이 인프라 운영, 애플리케이션 통합, 클라우드 서비스 담당자 책임 하에 있었다면, 이건 기회가 될 수 있었다. 조직 내 ‘경쟁자’의 실수는 늘 기회이기 때문이다. 문제는 조지가 당신의 팀원이라는 점이다. 그리고 그가 분석한 영역이 바로 나의 책임 범위에 해당돼, 지적된 취약점들이 곧장 나의 관리 문제로 이어질 수 있다.
엔지니어는 반드시 필요하지만, 그렇다고 말 잘 듣는 부품처럼 쉽게 조율되는 사람은 아니다.
상황은 더 악화된다. 최근 또 다른 기업의 대규모 데이터 유출 사고가 언론을 장식한 직후, CEO는 다중 인증이 모든 시스템에 적용돼 있는지를 물었다. 당신은 순간 당황했지만, 모든 시스템이 이미 철저히 보안 처리됐다고 자신 있게 대답했다.
그때 조지에게 다중 인증이 정확히 무엇인지 미리 물어봤어야 했다는 생각이 이제 와서 떠오른다.
이제 당신이 할 수 있는 일은 조지에게 ‘정치적 설계’의 원리를 설명하는 것이다. 그리고 그가 이 원칙을 따르기를 바랄 수밖에 없다.
정치적 설계의 원칙
당신은 조지의 꼼꼼함에 감사 인사를 건넨 뒤, 문제를 논의할 약속을 다음 주 후반으로 잡는다. 준비 시간을 벌기 위해서다.
조지는 아마도 기술 문제 해결을 위한 복구 프로그램을 함께 계획하게 될 것이라 예상할 것이다. 하지만 예상하지 못할 것은, 이 회의가 ‘정치적 설계 101’이라는 속성 강의가 될 것이라는 점이다. 당신은 조지가 거부감 없이 받아들일 수 있도록 정치적 설계를 어떻게 설명할 수 있을지를 고민하게 된다.
‘정치적 설계’라는 표현은 IT 업계에서 공식적으로 통용되는 용어는 아니다. 필자는 정치적 설계를 기술적 사실만으로는 해결할 수 없는 조직 내 문제를, 권력 관계와 이해관계자의 기대, 책임 구조 등을 전략적으로 고려해 설계하고 조율하는 리더십의 한 형태로 제안하고자 한다. 정치적 설계는 일반 공학과 마찬가지로, 현실 세계를 추상화한 몇 가지 핵심 원칙에 뿌리를 두고 있다. 그 첫 번째 원칙은 다음과 같다.
원칙 1: 상황은 항상 상대방이 바라는 대로 존재한다. 실제 사실과 듣는 사람이 믿고 싶은 내용 중 하나를 택해야 할 경우, 실제 사실은 대개 선택되지 못한다.
원칙 2: 상대방이 원하는 상황으로 문제를 바꿔서 설명할 수 없다면, 누군가의 잘못으로 바꿔야 한다. 가장 좋은 타깃은 최근 회사를 떠난 사람이다. 반론할 수 없기 때문이다. 그게 어렵다면, 정치 감각이 부족한 엔지니어처럼 반론하지 못할 사람을 찾아야 한다.
원칙 3: 문제가 무엇이든, CEO와 주요 경영진은 사실상 이미 그 문제를 인식하고 있다. 단, 그 사실을 스스로 자각하지 못하고 있을 뿐이다. ‘경영진은 그 문제를 모른다’고 말하고 싶은가? 사실은 알고 있다. 직접 인식하지 못하더라도, 결정적인 순간이 오면 차분히 설명하면 된다. 중요한 건, 자신 있게 말하는 태도다. 아마도 “기술적인 세부사항이 비즈니스 언어로 번역되는 과정에서 메시지가 흐려졌을 뿐이다”라고 설명하게 될 것이다.
사실 그 문제는 과거에 이미 설명한 적이 있다. 단지 시간이 오래 지나 기억이 흐릿해졌을 뿐이다. 당시 조직 내부에서는 그 문제를 해결할 예산이 없다는 데에 모두가 동의했고, 위험 관리 관점에서는 ‘수용’이라는 이름의 희망 섞인 전략이 최선이라고 판단했다. 결국, 그때 모두가 그렇게 하기로 합의한 것이었다.
원칙 4: 이해하기 어렵고, 해결 비용이 많이 드는 문제에 대해 경영진이 흔히 택하는 해결책은 문제를 지적한 사람에게 책임을 돌리는 것이다. 단, 그 사람이 경영진 내부 그룹에 속해 있는 경우는 예외다. 이 내부 그룹은 조직의 임원진과 그들이 신뢰하는 인물 중, 일정 수준의 친밀감과 분위기를 공유하는 사람들로 구성된다.
이럴 경우 경영진은 책임을 전가할 수 있는 다른 사람, 즉 자신을 방어할 수 없는 인물을 대신 지목한다.
원칙 5: 문제를 성공적으로 예방한 경우, 그 효과는 마치 위험이 애초에 존재하지 않았던 것처럼 보인다.
과거에 어떤 문제가 발생하지 않도록 잘 막아낸 경험이 많을수록, 듣는 사람은 이번에도 실제로는 별일 없는데 예산을 더 받기 위해 괜히 호들갑을 떠는 것이라고 여길 가능성이 커진다.
하지만 여기엔 함정이 있다. 이 원칙들을 말로 설명하는 일 자체는 그리 어렵지 않다. 필요한 건 냉소적 유머 감각과 강한 자기방어 본능 정도다.
진짜 어려운 건 따로 있다. 조지에게 정치적 설계가 비윤리적인 것이 아니라는 점을 납득시키는 일이다. 오히려 그 반대라는 걸 설명해야 한다. 이 원칙을 따르지 않는 해결책은 작동하지 않을 뿐 아니라, 아예 시도조차 되지 않는다.
조지를 얼마나 설득할 수 있느냐는 것 자체가 사실상 원칙 1의 생생한 사례라고 봐도 좋다. 조지를 설득하는 게 어렵다고 했던가? 물론 어렵다. 하지만 그보다 더 어려운 일이 남아 있다. 조지를 설득한 다음에는, 정치적 설계의 원칙과 IT 아키텍처의 원칙을 모두 충족하는 해결책을 함께 만들어야 한다.
[email protected]
Read More from This Article: 칼럼 | 조직 정치에 대처하는 IT 리더의 기술, 정치적 설계 101
Source: News