사내 정치의 SLA, 그리고 단방향 트랜잭션

 

사내 정치는 거창한 게 아니었다. 부서 간 사람 간 알력다툼, 상하관계의 무게. 그것이 전부였다. 우리 조직에서 개발부서는 기획부서보다 항상 우위에 있었다. 그들이 Infrastructure였고, 우리는 Application일 뿐. 그들이 없으면 서비스가 안 되지만, 우리가 없어도 개발은 된다. 이것이 조직의 기본 SLA였고, 그 SLA에는 Reciprocity가 없었다.

 

늦게 입사한 개발자가 있었다. 신입이었지만, 아쉬울 땐 메신저로 물어봤다. "이거 어떻게 해요?" 나는 알려줬다. 가르쳐줬다. 그게 쌓이면 그도 나를 도와줄 것이라고 기대했다. 하지만 오판이었다. 내가 아쉬울 때 그에게 물어보면, 대답은 항상 같았다. "저희 실장님한테 물어보세요." 이게 바로 Escalation Path의 단방향 설정이었다. 그는 나에게는 할 수 있는데까지 하고, 자신에게는 권위를 방패로 삼았다.

 

나는 그에게 호의(好意)를 보였고, 그는 나에게 원론(原理)을 줬다. 이건 Transaction이 아니라 Unilateral Transfer였다. 내가 준 건 Knowledge Sharing이었고, 내가 받은 건 Deflection이었다. 그리고 그 관계는 계속됐다. 나는 그의 Onboarding을 도왔고, 그는 나의 Blocker를 해결하지 않았다. 이게 바로 Personal SLA의 위반. 하지만, 그 SLA는 문서화된 적이 없었으니 Breach of Contract도 없었다.

 

결국 그들은 이직했다. 더 좋은 조건에, 더 큰 회사로. 그리고 나는 남았다. 결과적으로 이용만 당한 셈이었다. 하지만 돌이켜보면, 그건 Utilization이 아니라 Misalignment of Incentive였다. 그들의 목표는 '빠른 습득과 빠른 이직'이었고, 나의 목표는 '관계의 장기투자'였다. 시간축(Time Horizon)이 다른 두 개의 전략이 만났을 때, 발생하는 건 시간차 역갭이었다.

 

사주로 치면, 이건 '일천(日千)'과 '월파(月破)'의 관계였다. 매일 만나지만 틀어지는 관계. 아니, 서비스 기획 용어로는 Data Silo였다. 나는 나의 지식을 그에게 개방(Open API)했지만, 그는 자신의 지식을 나에게 폐쇄(Closed API)했다. 그리고 그는 나를 거쳐서(Orchestration) 지식을 습득한 뒤, Direct Connection으로 이직했다. 나는 Middleware였고, 그는 Client였다.

교훈: 조직에서 관계도 상품화(Commoditization)된다. 호의는 공짜가 아니고, 원론은 비용이다. 누군가에게 가르쳐줄 때는, 그 대가가 명확해야 한다. 동료에게 가르친다면, "다음에 내가 물어볼 때 도와줘"라는 계약을 미리 해야 한다. 그렇지 않으면, 그 관계는 Single Point of Failure가 되어, 그가 떠날 때  붕괴된다.