작은 팀의 OKR — 우리는 안 쓴다

한 번은 제대로 해봤다 — 그리고 7주 만에 그만뒀다

올해 초 slecs가 제안했다. "분기 목표를 OKR로 잡아보자." Google이 내부 도입 이후 생산성이 폭발적으로 올랐다는 사례는 이미 잘 알려져 있고, Intel의 Andy Grove가 1970년대에 만든 이 프레임워크는 지금도 수많은 스타트업에서 살아있다. Objective를 세우고 Key Result를 측정 가능하게 정의하면 팀의 방향이 선명해질 것 같았다. 우리라고 못 쓸 이유가 없었다.

그래서 실제로 해봤다. Objective를 잡았고, KR을 수치화했고, Notion 페이지에 담았다. 7주가 지났다. 그리고 조용히 접었다. OKR이 나쁜 도구여서가 아니다. 결제·정산·자동화를 직접 운영하는 세 명짜리 팀에 구조적으로 맞지 않았기 때문이다. 이 글은 그 7주의 기록이고, 우리가 대신 무엇을 쓰게 됐는지에 대한 이야기다.

결제·정산 현장에서 OKR이 특히 위험한 이유

일반적인 팀의 OKR 실패담은 많다. "목표를 너무 높게 잡았다", "KR은 달성했는데 실질적인 성과가 없었다" 같은 이야기들. 그런데 결제·정산·자동화를 운영하는 팀에는 구조적으로 더 심각한 문제가 있다. 이 도메인의 핵심 작업들은 정량화 자체가 어렵고, 잘못 붙인 지표는 단순한 방향 착오를 넘어 실제 운영 리스크가 된다.

"클라이언트 정산 만족도 향상"이라는 Objective에 KR을 붙이면 어떤 모습이 될까. 흔히 등장하는 형태는 이렇다: "정산 오류 건수 분기 내 50% 감소", "클라이언트 응답 시간 48시간 → 24시간 이내". 숫자로 보면 합리적이다. 그런데 실제 운영에서 이 지표는 빠르게 왜곡된다. 정산 오류 건수를 줄이는 가장 빠른 방법은 경계선 케이스를 "오류"로 분류하지 않거나, 클라이언트 요청을 선제적으로 제한해 건수 자체를 줄이는 것이다. 둘 다 실제 정산 품질과 무관하고 지표만 개선된다. 이것이 굿하트의 법칙(Goodhart's Law)이다: 측정 지표가 목표가 되는 순간, 그것은 좋은 지표이기를 멈춘다.

자동화 커버리지 KR도 같은 함정이다. "자동화 비율 60% → 80%"는 그럴듯해 보인다. 그런데 달성하기 쉬운 단순 반복 작업만 골라 수치를 올리면 KR은 달성된다. 정작 자동화가 절실한 예외 처리, 실패 복구 플로우, 엣지 케이스 핸들링은 그대로다. 숫자는 올라갔는데 실제 운영 부담은 변하지 않는 상황이 만들어진다. 결제·정산 도메인에서 잘못된 OKR은 단순한 비효율이 아니다. 잘못된 방향으로의 집중이고, 그게 실제 장애나 클라이언트 이슈로 이어질 수 있다.

7주 동안 실제로 일어난 일: 오버헤드의 진짜 비용

우리가 OKR을 운영한 7주 동안 무슨 일이 있었는지 구체적으로 기록한다. 첫 3주는 Objective 정의와 KR 협의에 생각보다 많은 시간이 들었다. 세 명이 각자 Objective를 제안하고, KR을 조율하고, 측정 기준을 합의하는 과정이었다. 우리 팀의 실제 작업 시간이 주 평균 90-100시간 정도일 때, OKR 운영 자체에만 주 4-5시간이 소요됐다. 7주 전체로 합산하면 세 명 기준 약 40-50시간이 OKR 운영 — 미팅, 문서화, 분기 리뷰 준비 — 에 들어갔다.

4-7주차에는 더 결정적인 변화가 생겼다. KR을 달성하기 위해 행동 자체가 달라지기 시작했다. 특히 "응답 시간 단축" KR에서 두드러졌다. 클라이언트 요청이 오면 일단 빠르게 답장하고 나서 실제 작업을 하는 패턴이 생겼다. 응답 시간 지표는 좋아졌다. 그러나 슬랙·이메일 사이의 문맥 전환이 늘어나면서 실제 작업 집중 시간이 줄었다. 이건 수치화하기 어렵지만 세 명 모두 체감했다. 측정 가능한 KR을 달성하기 위해 측정하기 어려운 실제 집중력이 희생되는 구조였다. 7주차, 분기 리뷰 준비를 시작했을 때 "이 시간에 실제 작업을 했으면 더 나았겠다"는 생각이 셋에게 동시에 들었다. 40-50시간의 기회비용은 우리 팀 기준으로 자동화 파이프라인 하나를 완성하거나 신규 클라이언트 온보딩 하나를 추가로 처리할 수 있는 분량이었다. 도구의 오버헤드가 도구의 효익을 넘어선 것이다.

우리가 실제로 쓰는 것: 월간 세 가지 리스트

지금 구조는 훨씬 단순하다. 매달 첫날, 셋이서 한 시간 얘기한다. 안건은 세 가지뿐이다.

이번 달에 뭘 끝낼까. 완료 기준이 명확한 작업만 넣는다. "정산 자동화 파이프라인 1단계 완성", "클라이언트 A 온보딩 완료"처럼 Done/Not Done으로 판단 가능한 것. KR처럼 퍼센트를 붙이지 않는다. 완료됐냐 아니냐만 본다.

이번 달에 뭘 시작할까. 방향성을 잡는 작업이 여기 들어간다. 완료가 목표가 아니라 "시작했는지"가 기준이다. 새 자동화 범위 조사, 새 클라이언트 요구사항 파악, 기술 부채 항목 정리 같은 것들.

이번 달에 뭘 안 할까. 이 항목이 가장 중요하다. 하지 않을 것을 명시적으로 적는다. "직접 요청이 없는 한 신규 제안서 작업 없음", "이 달은 레거시 코드 리팩토링 없음"처럼. 이걸 빠뜨리면 "다 중요해 보이는 것들"이 계속 밀려 들어온다. 선택은 포기를 전제로 한다. 안 할 것을 정해야 할 것이 살아남는다.

Notion 페이지 하나에 텍스트로 남긴다. 달이 끝나면 확인한다. 됐으면 다음 달로. 못 했으면 이유를 짚고 다음 달 리스트에 반영한다. 한 달에 한 시간. 이게 전부다. 이 구조가 OKR보다 실제로 작동하는 이유는 단순하다. 세 명이 이미 같은 맥락을 공유하고 있어서다. 같은 슬랙 채널에서 대화하고, 같은 클라이언트 이슈를 보고, 같은 장애를 함께 처리한다. OKR이 해결하려는 "정렬 비용" 자체가 우리에게는 이미 존재하지 않는다.

팀 크기와 방법론: 언제 OKR이 맞고 언제 맞지 않는가

OKR이 나쁜 방법론이 아니다. 맥락이 다른 것이다. OKR이 해결하는 근본 문제는 "큰 조직에서 서로 다른 맥락을 가진 사람들이 같은 방향을 보게 만드는 비용"이다. 수십 명이 각자 다른 우선순위로 움직이면 방향이 흩어진다. 이걸 Objective와 Key Result로 명문화해서 정렬하는 것이 OKR의 핵심 가치다.

반대로 말하면, 팀원 모두가 이미 같은 맥락을 가지고 있으면 OKR의 존재 이유가 사라진다. 정렬 비용이 없는데 정렬 도구를 쓰면 도구의 오버헤드만 남는다. 세 명짜리 팀에서 OKR을 쓰는 것은 두 사람이 마주보고 앉아 있는데 화상 회의를 여는 것과 비슷하다. 실용적인 기준을 제안하면 이렇다: 팀이 10명을 넘거나, 서로 다른 시간대에서 비동기로 일하거나, 각자가 완전히 다른 도메인을 맡아 일상적인 맥락 공유가 일어나지 않는다면 OKR 같은 명시적 정렬 구조가 필요하다. 그 이하 규모에서는 정렬 비용이 작업 비용을 초과할 가능성이 높다. 더 나쁜 경우는, 잘못된 KR이 실제 운영 방향을 비트는 것이다. 장애 대응, 예외 케이스 처리, 클라이언트 이슈 해결 — 이것들은 KR에 담기 어렵지만 팀의 실제 가치를 만드는 작업이다. 도구는 문제를 해결하기 위해 있다. 도구를 쓰기 위해 문제를 만들면 안 된다.

바로 써먹을 수 있는 시사점

먼저 "정렬 문제가 실제로 존재하는가"를 물어라. 팀원들이 이미 매일 같은 채널에서 대화하고 같은 이슈를 보고 있다면, OKR이 해결하려는 문제가 아직 없는 것이다. 없는 문제의 해결책을 도입할 필요가 없다. OKR 도입을 고민하기 전에 이 질문 하나만 먼저 해봐라.

KR을 붙이기 전에 "이 숫자가 어떻게 왜곡될 수 있는가"를 먼저 검토하라. 특히 결제·정산·자동화처럼 예외 케이스가 많은 도메인에서는, 지표가 팀을 엉뚱한 방향으로 최적화하게 만들 수 있다. "오류 건수 50% 감소"라는 KR이 실제 정산 품질을 올리는지, 아니면 오류 분류 기준을 느슨하게 만드는지를 먼저 따져봐라.

월간 세 가지 리스트를 한 달만 써봐라. "끝낼 것 / 시작할 것 / 안 할 것" 세 항목만, 텍스트로, 한 달 후 확인. OKR보다 훨씬 작은 구조지만 우리 팀에서는 실제로 지켜지고 있다. 특히 "안 할 것" 항목을 빠뜨리지 마라. 이 항목이 없으면 리스트는 그냥 할 일 목록이고, 있으면 의사결정 도구가 된다.

방법론 도입 전에 오버헤드를 실제 비용으로 계산해봐라. 팀원 수 × 주당 소요 시간 × 운영 주수 = 기회비용. 우리 경우 7주 동안 세 명 합산 40-50시간이 들었다. 그 시간에 실제로 뭘 만들 수 있었는지를 계산하고 나면, 방법론의 오버헤드가 추상적인 이야기가 아니라 구체적인 선택이 된다. 우리는 당분간 월간 세 가지 리스트로 간다. 팀이 커지거나 비동기 협업이 필요해질 때, 그때 다시 OKR을 꺼낼 것이다.

— by slecs