리더십

OKR을 도입한 조직에서 리더는 흔히 “목표를 더 명확히 쓰라”고 말한다. 그러나 OKR이 실제로 흔들리는 지점은 문장보다 운영이다. 구성원은 Objective를 적을 수 있고 Key Result도 숫자로 만들 수 있다. 문제는 그 목표를 위해 무엇을 포기할지, 충돌이 생기면 누가 조정할지, 진행 상황이 나빠졌을 때 어떤 결정을 내릴지가 정해지지 않을 때 발생한다.

OKR에서 리더의 역할은 독려자가 아니다. 리더는 우선순위를 좁히고, 자원 충돌을 조정하며, 팀 사이의 의존성을 드러내고, 체크인 회의를 의사결정의 장으로 바꾸는 사람이다. 이 역할을 하지 않으면 OKR은 구성원에게 더 많은 목표를 요구하는 문서가 된다.

리더가 먼저 정해야 할 것은 목표보다 ‘하지 않을 일’이다

Google OKR playbook은 잘 운영된 OKR이 팀에게 무엇이 중요한지, 무엇을 최적화해야 하는지, 일상 업무에서 어떤 tradeoff를 해야 하는지 분명히 해준다고 설명한다. 이 문장은 OKR 운영에서 리더의 첫 번째 책임을 보여준다. 목표를 더 많이 쓰게 하는 것이 아니라, 이번 기간에 무엇을 선택하고 무엇을 내려놓을지 정하는 일이다.

Atlassian도 OKR 설정에서 1~3개의 Objective와 Objective당 3~5개의 Key Result를 제안한다. 숫자의 의미는 단순한 작성 규칙이 아니다. 목표 수를 줄이지 않으면 우선순위가 생기지 않는다. 모든 목표가 중요하다고 말하는 조직에서는 실제로 중요한 목표가 없다.

리더가 해야 할 질문은 “이 목표도 넣을까”가 아니라 “이 목표를 넣으면 무엇을 빼야 하는가”다. OKR 회의에서 삭제되는 목표가 없다면 아직 전략 대화가 끝나지 않은 것이다. 구성원은 리더가 승인한 목표 목록이 아니라, 리더가 포기하기로 한 일의 목록을 보고 우선순위를 이해한다.

OKR 체크인은 보고 회의가 아니라 충돌 해결 회의다

Atlassian은 OKR을 매월 score, analyze, summarize하라고 제안한다. 또 정기적이고 가시적인 진행 점검이 책임감과 추진력을 강화한다고 설명한다. 하지만 많은 조직에서 체크인은 보고 회의로 바뀐다. 각 팀이 진행률을 말하고, 리더는 더 열심히 하자고 정리한다. 이 방식으로는 OKR이 운영 리듬이 되기 어렵다.

Google playbook은 committed OKR을 달성할 수 없다고 판단되면 팀이 즉시 escalate해야 한다고 말한다. 더 중요한 대목은 escalation의 목적이다. 우선순위 이견, 시간·인력·자원 부족, 목표 자체의 이견이 생겼을 때 경영진이 선택지를 만들고 충돌을 해결하도록 하기 위한 절차라는 설명이다.

따라서 OKR 체크인에서 리더가 물어야 할 질문은 진행률 숫자가 아니다. “어떤 장애가 목표 달성을 막고 있는가.” “다른 팀의 의존성이 풀리지 않았는가.” “자원이 부족한가, 아니면 목표의 우선순위가 낮아진 것인가.” “지금 조정하지 않으면 다음 달에 어떤 손실이 커지는가.” 이런 질문이 없으면 체크인은 보고서 낭독으로 끝난다.

예를 들어 제품 출시 OKR이 지연될 때 리더가 “진행률을 다음 달까지 80%로 올리라”고만 말하면 체크인은 독려 회의가 된다. 반면 “법무 검토가 병목인지, 개발 인력이 병목인지, 영업 요구사항이 과도하게 늘어난 것인지”를 나누고 그 자리에서 우선순위를 조정하면 체크인은 운영 회의가 된다. OKR 리더십은 구성원에게 압박을 주는 기술이 아니라 충돌을 의사결정으로 바꾸는 기술이다.

Cross-team OKR에서 리더십은 협업 구호가 아니라 책임 설계다

Google playbook은 중요한 프로젝트가 여러 그룹의 기여를 필요로 할 때 cross-team OKR이 적합하다고 설명한다. 이때 materially participate해야 하는 모든 그룹이 OKR에 포함되어야 하며, 각 그룹의 기여가 각 그룹의 OKR에 명시적으로 나타나야 한다고 말한다.

이 원칙은 한국 기업의 부서 간 협업에서도 중요하다. 많은 조직이 “협업 강화”를 목표로 쓰지만, 실제로는 어느 부서가 어떤 산출물을 언제까지 제공해야 하는지 분명하지 않다. 마케팅, 영업, 제품, 인사, 데이터 조직이 함께 움직여야 하는 목표라면 각 조직의 OKR에 서로의 책임이 드러나야 한다. 그렇지 않으면 공동 목표는 아무도 끝까지 책임지지 않는 목표가 된다.

리더는 cross-team OKR을 선언하는 사람이 아니라 연결 구조를 설계하는 사람이다. 회의체를 만들고 끝나는 것이 아니라, 의존성 목록을 공개하고, 병목이 생겼을 때 누구에게 escalate할지 정하고, 공동 목표의 성공 기준을 같은 언어로 맞춰야 한다. 협업은 좋은 태도만으로 작동하지 않는다. 협업에는 책임선과 조정권한이 필요하다.

Committed와 Aspirational을 구분하지 않으면 리더가 잘못된 신호를 보낸다

Google playbook은 committed OKR과 aspirational OKR을 구분한다. committed OKR은 달성을 약속한 목표이며 기대 점수는 1.0이다. 달성하지 못하면 설명과 사후 검토가 필요하다. 반면 aspirational OKR은 더 높은 도전과 혁신을 자극하는 목표다. 같은 달성률이라도 해석 방식이 달라야 한다.

리더가 이 구분을 하지 않으면 구성원은 혼란스러운 신호를 받는다. 도전 목표를 내라고 하면서 낮은 달성률을 질책하면 다음 분기에는 안전한 목표만 올라온다. 반대로 약속 목표의 미달성을 “도전했으니 괜찮다”고만 처리하면 실행 책임이 약해진다. 두 종류의 목표를 같은 표정으로 다루는 리더는 OKR의 언어를 흐리게 만든다.

리더는 목표를 승인할 때부터 유형을 분명히 해야 한다. 이 목표는 반드시 달성해야 하는 약속인가, 아니면 조직을 더 멀리 밀어붙이는 도전인가. 약속 목표라면 자원과 우선순위를 보장해야 한다. 도전 목표라면 실패 가능성을 허용하되, 무엇을 학습할지 정해야 한다. 구분이 있어야 구성원도 목표를 정직하게 설정한다.

HR은 리더에게 OKR 양식보다 운영 질문을 제공해야 한다

OKR 교육이 실패하는 이유 중 하나는 양식 교육에 머무르기 때문이다. Objective는 어떻게 쓰고, Key Result는 몇 개가 적당한지 알려주는 것만으로는 충분하지 않다. 리더가 실제 회의에서 어떤 질문을 던지고, 어떤 결정을 내려야 하는지까지 연결되어야 한다.

HR은 리더에게 최소한 네 가지 운영 질문을 제공할 수 있다. 첫째, 이번 분기에 포기할 일은 무엇인가. 둘째, 이 OKR이 실패한다면 가장 가능성 높은 병목은 어디인가. 셋째, 다른 팀의 기여가 필요한 부분은 각 팀의 OKR에 명시되어 있는가. 넷째, 이 목표는 committed인가 aspirational인가. 이 질문이 회의에서 반복될 때 OKR은 문서가 아니라 운영 언어가 된다.

OKR 리더십은 카리스마나 독려의 문제가 아니다. 우선순위를 좁히고, 불편한 tradeoff를 공개하고, 충돌을 제때 끌어올리고, 팀 간 책임을 설계하는 관리 역량의 문제다. 구성원은 목표를 듣고 움직이지 않는다. 리더가 무엇을 선택하고 무엇을 조정하는지를 보고 움직인다. OKR이 성과관리 운영체계가 되려면 리더의 역할도 목표 관리자가 아니라 실행 구조를 설계하는 사람으로 바뀌어야 한다.