좋은 OKR과 나쁜 OKR
ALLO에서 검토하기 쉬운 목표, 핵심결과, 핵심업무를 실제 예시와 함께 작성합니다.
좋은 OKR은 검토가 쉽습니다
좋은 OKR은 문장이 매끄러운 OKR이 아닙니다. 리뷰 자리에서 "이게 무슨 뜻이었죠?"라고 다시 묻지 않아도 되는 OKR입니다. 좋은 OKR은 방향, 측정, 실행을 각각 제자리에 둡니다.
나쁜 OKR이 무너지는 방식은 대개 비슷합니다. 목표가 모호하고, 핵심결과는 사실 할 일이며, 핵심업무는 실행 내용 대신 지표를 되풀이합니다. 어떤 숫자가 움직여야 하는지 아무도 모르니 체크인은 형식적인 보고로 끝납니다.
계획 회의 전, OKR을 가져온 직후, 또는 OKR 주기에 항목은 많은데 검토하기 어려울 때 이 문서를 참고하세요.
지원 범위
| 항목 | 내용 |
|---|---|
| 사용 가능 플랜 | 목표관리(OKRs)가 켜진 워크스페이스와 플랜 |
| 지원 환경 | 웹 앱, 데스크톱 앱 |
| 참고하면 좋은 사람 | 목표, 핵심결과, 핵심업무, 체크인을 작성하거나 가져오거나 검토하거나 정리하는 모든 사람 |
| 함께 읽으면 좋은 문서 | 목표관리(OKRs) 이해하기, 목표 만들기, 핵심결과 추가하기, 핵심업무 만들기 |
요약
| 구성 | 좋은 예 | 나쁜 예 |
|---|---|---|
| 목표 | 무엇이 달라져야 하는지 말합니다. | 할 일, 부서 이름, 막연한 바람을 적습니다. |
| 핵심결과 | 목표가 이뤄지고 있는지 측정합니다. | 해야 할 일을 적거나, 아무도 업데이트할 수 없는 숫자를 씁니다. |
| 핵심업무 | 실제 일이 진행되는 캔버스를 엽니다. | 핵심결과를 되풀이하거나 막연한 메모에 그칩니다. |
| 체크인 | 무엇이 바뀌었고, 무엇이 막혔고, 다음에 무엇을 할지 설명합니다. | 근거 없이 정상이라고만 적습니다. |
| 스냅샷 | 특정 시점의 리뷰 상태를 남깁니다. | 정기 체크인을 대신합니다. |
규칙 하나만 기억한다면 이것입니다. 목표는 방향을 정하고, 핵심결과는 성과를 측정하며, 핵심업무는 그 일을 담는 연결된 캔버스입니다.
좋은 예와 나쁜 예
| 아쉬운 OKR | 더 나은 OKR | 더 나은 이유 |
|---|---|---|
목표: 마케팅 개선 | 목표: 영업팀과 고객이 추가 설명 없이 전할 수 있을 만큼 3분기 출시 메시지를 명확하게 만들기 | 이루려는 변화와 대상을 함께 밝힙니다. |
핵심결과: 랜딩 페이지 오픈 | 핵심결과: 3분기 말까지 출시 페이지를 통한 유효 데모 신청을 월 120건에서 180건으로 늘리기 | 할 일이 아니라 성과를 측정합니다. |
핵심업무: 리서치하기 | 핵심업무: 영업 통화 12건을 바탕으로 고객 반론 정리 캔버스를 만들고 7월 12일까지 영업팀과 검토하기 | 캔버스에 담을 수 있는 구체적인 일을 설명합니다. |
체크인: 괜찮아 보임 | 체크인: 42%입니다. 법무 검토로 최종 페이지가 3일 늦어졌고, 수정 문구는 금요일까지 나옵니다. | 숫자와 리스크를 함께 설명합니다. |
방향이 분명한 목표 쓰기
목표는 정성적이고 기억하기 쉬워야 합니다. 동시에 어떤 일이 이 목표 아래에 들어가야 하는지 판단할 수 있을 만큼 구체적이어야 합니다.
좋은 목표는 이런 특징이 있습니다.
- 무언가를 더 쉽게, 명확하게, 빠르게, 안전하게, 안정적으로, 쓸모 있게 만듭니다.
- 나아져야 할 고객, 팀, 업무 흐름을 밝힙니다.
- 측정값을 제목에 억지로 넣지 않습니다.
- 앞으로 할 수 있는 일을 모두 나열하지 않습니다.
| 아쉬운 목표 | 더 나은 목표 |
|---|---|
도움말 센터 업데이트 | 관리자와 외부 검토자가 워크스페이스 접근 방식을 쉽게 이해하도록 만들기 |
온보딩 개선 | 새 멤버가 고객 지원 없이 첫 캔버스를 제대로 활용하도록 돕기 |
AI 기능 출시 | 팀이 이미 일하는 캔버스 안에서 AI로 만드는 기능이 실제로 도움이 되게 하기 |
결제 문제 해결 | 관리자가 워크스페이스 플랜, 저장 공간, AI 크레딧 비용을 예측할 수 있게 하기 |
좋은 목표는 계획 회의가 끝난 뒤에도 뜻이 통해야 합니다. 제목을 이해하는 데 한 문단의 설명이 필요하다면 제목을 다시 쓰세요.
할 일을 목표로 쓰지 않기
할 일 형태의 목표는 검토를 어렵게 만듭니다. 나아진 것이 없어도 일만 끝나면 "완료"가 되기 때문입니다.
| 할 일 형태의 목표 | 이렇게 나누세요 |
|---|---|
문서 20개 게시 | 목표: 고객 지원팀이 고객에게 답변 문서를 바로 안내할 수 있을 만큼 도움말을 갖추기. 핵심결과: 워크스페이스, 공유, 결제, AI Studio 분야의 검토 완료 문서 20개 게시. |
온보딩 체크리스트 만들기 | 목표: 새 워크스페이스 관리자가 고객 지원 없이 팀을 설정할 수 있게 하기. 핵심업무: 온보딩 체크리스트 캔버스 만들기. |
오래된 파일 옮기기 | 목표: 계약 갱신 전에 워크스페이스 저장 공간 부족 위험 줄이기. 핵심결과: 저장 공간 사용량을 할당량의 80% 미만으로 낮추기. |
만들기, 게시, 이전, 다시 쓰기, 점검, 인터뷰, 적용으로 시작하는 문구는 대개 핵심업무입니다. 늘리기, 줄이기, 높이기, 낮추기, 달성하기, 단축하기로 시작한다면 핵심결과일 가능성이 높습니다.
확인할 수 있는 핵심결과 쓰기
핵심결과에는 숫자로 측정할 단위, 현재값, 목표값이 분명해야 합니다. 개수, 백분율, 금액, 시간이나 사용자 지정 단위를 사용하세요. 품질 기준도 측정할 수 있는 형태로 적습니다.
| 아쉬운 핵심결과 | 더 나은 핵심결과 |
|---|---|
고객 지원 품질 개선 | OKR 주기가 끝날 때까지 접근 권한 관련 문의를 30% 줄이기 |
결제 안내를 더 명확하게 | 라이선스, 저장 공간, AI 크레딧 관련 결제 문의를 월 40건에서 20건으로 줄이기 |
더 빠른 출시 | 출시 검토 기간을 영업일 10일에서 5일로 단축하기 |
교육 기관 온보딩 개선 | 초대받은 교사의 90%가 7일 안에 첫 공유 캔버스를 열게 하기 |
목표값이 완벽할 필요는 없지만, 검토할 수 있어야 합니다. OKR 주기 동안 아무도 값을 업데이트할 수 없다면 그 핵심결과는 짐작에 그칩니다.
알맞은 단위 고르기
| 측정할 대상 | 좋은 단위 예시 | 주의할 점 |
|---|---|---|
| 도입 | 초대된 사용자, 활성화된 워크스페이스, 열린 캔버스, 다시 찾은 팀 | 실제로 쓸모 있는 일이 일어났는지 보여 주지 못하는 겉보기 숫자 |
| 품질 | 고객 문의, 오류율, 검토 반려율, 만족도 점수 | 평가 방법 없이 주관적으로 적은 표현 |
| 속도 | 시간, 일, 영업일, 검토 소요 기간 | 한 핵심결과 안에서 달력 기준 일수와 영업일을 섞는 것 |
| 범위 | 게시한 문서, 정리한 업무 흐름, 인터뷰한 고객, 검토한 템플릿 | 목표를 달성했는지 확인하지 않고 산출물 수만 세는 것 |
| 매출 또는 비용 | 월 비용, 추가 매출, 회수한 미수금, 절감한 외주 비용 | 통화와 기간이 분명해야 합니다. |
| 정해진 결과 하나의 완료 여부 | 숫자, 시작값 0, 목표값 1 | 완료 기준을 미리 합의하고, 완료되면 체크인으로 숫자를 기록합니다. |
팀이 이해하는 단위라면 사용자 지정 단위를 써도 됩니다. 항목처럼 모호한 단위 대신 고객 인터뷰, 검토한 캔버스, 영업일처럼 적으세요.
위 예시는 무엇을 측정할지 설명한 것이며, 단위 메뉴에 따로 있는 선택지가 아닙니다. ALLO 핵심결과에는 마일스톤 단위나 체크박스로 완료하는 방식이 없습니다. 사용자 지정 단위를 써도 측정 대상은 숫자입니다. 간단한 할 일은 캔버스 체크리스트로 관리하고, 선택할 수 있는 단위는 핵심결과 추가하기에서 확인하세요.
실행할 일은 핵심업무에 담기
목표관리에서 핵심업무는 OKR과 연결되어 실제 일이 진행되는 캔버스입니다. 검토자가 열었을 때 계획, 배경, 결정 사항, 파일, 작업, 지원되는 경우 하위 작업, 검토 자료를 확인할 수 있을 만큼 구체적이어야 합니다.
| 핵심결과 | 좋은 핵심업무 |
|---|---|
초대 관련 문의를 30% 줄이기 | 초대 문제 해결 문서와 외부 협업자 문서 다시 쓰기 |
첫 캔버스 활성화율을 45%에서 65%로 높이기 | 예시와 체크리스트를 담은 첫 캔버스 온보딩 캔버스 만들기 |
출시 검토 기간을 10일에서 5일로 단축하기 | 담당자, 마감일, 승인 단계를 넣은 출시 검토 템플릿 만들기 |
핵심업무를 또 하나의 지표로 쓰지 마세요. 성과가 움직였는지는 핵심결과가 보여 주고, 핵심업무는 그 성과를 움직이기 위한 일을 담습니다.
잘 짜인 OKR 예시
OKR 주기: 2026년 3분기 고객 지원 품질
목표: 고객이 지원팀 답변을 기다리지 않고 계정과 권한 문제를 해결할 수 있게 하기.
핵심결과 1: 접근 권한 관련 문의를 30% 줄이기.
핵심결과 2: 워크스페이스 역할, 공유, 비활성화된 접근, 초대, 결제 담당 범위에 대한 검토 완료 도움말 문서 게시하기.
핵심업무: 연결된 캔버스에서 고객 문의 사례와 검토 메모를 바탕으로 워크스페이스 접근 문서 다시 쓰기.
체크인: 핵심결과 1은 18% 감소했습니다. 워크스페이스 역할 문서와 공유 문서는 게시했습니다. 초대 문제 해결 문서는 검토 중이고, 비활성화된 접근 복구 문서에는 아직 스크린샷이 없습니다.
목표가 방향을 설명하고, 핵심결과로 검토할 수 있고, 핵심업무가 일할 캔버스를 제공하고, 체크인이 최근 상황을 알려 주기 때문에 잘 작동하는 예시입니다.
흔히 보이는 나쁜 OKR
| 유형 | 생기는 문제 | 개선 방법 |
|---|---|---|
| 목표가 부서 이름입니다 | 검토자가 무엇이 달라져야 하는지 알 수 없습니다. | 그 부서가 만들려는 변화로 다시 씁니다. |
| 핵심결과가 모두 할 일입니다 | 성과를 증명하지 못해도 일만 끝내면 완료됩니다. | 할 일 형태의 항목은 핵심업무로 옮깁니다. |
| 핵심결과에 단위가 없습니다 | 체크인이 의견 공유에 그칩니다. | 숫자 단위와 측정할 수 있는 목표값을 정합니다. |
| 목표값을 업데이트할 수 없습니다 | 데이터를 챙기는 사람이 없어 진행이 멈춥니다. | 담당자가 OKR 주기 중에 확인할 수 있는 지표를 고릅니다. |
| 목표 하나에 핵심결과가 너무 많습니다 | 검토가 산만해지고 초점이 흐려집니다. | 목표를 나누거나, 성공을 증명하는 지표만 남깁니다. |
| 핵심업무 하나에 서로 관계없는 일이 섞여 있습니다 | 캔버스가 이것저것 쌓아 두는 곳이 됩니다. | 맡은 사람, 일정, 검토 절차가 다른 일은 핵심업무를 따로 만듭니다. |
체크인에 정상만 적혀 있습니다 | 스냅샷을 봐도 무슨 일이 있었는지 알 수 없습니다. | 근거, 막힌 점, 다음 조치, 날짜와 관련된 상황을 함께 적습니다. |
가져온 OKR 정리하기
AI로 OKR 가져오기를 쓰면 계획 메모를 OKR 주기, 목표, 핵심결과, 핵심업무 초안으로 바꿀 수 있습니다. 그래도 저장하기 전에 구조를 직접 검토해야 합니다.
가져온 내용에서 다음을 확인하세요.
- 핵심결과로 들어간 할 일
- 목표로 바꿔야 할 넓은 문장
- 핵심결과를 되풀이하기만 하는 핵심업무 제목
- 빠진 단위
- 정리되지 않은 원본 메모 때문에 중복된 목표
- 항목 제목이 되면 안 되는 담당자 메모나 회의 메모
초안이 대체로 맞다면 저장하기 전에 해당 줄을 수정하세요. 구조부터 잘못됐다면 취소하고 원본 텍스트를 먼저 정리하세요.
트리 뷰로 구조 확인하기
트리 뷰는 OKR 주기에 여러 단계로 이어지는 OKR이 있을 때 유용합니다. 계층을 지도처럼 보여 주므로 목표와 핵심결과가 누구나 이해할 수 있게 이어지는지 확인할 수 있습니다.
트리 뷰에서 다음을 확인하세요.
- 하위 목표가 정말 상위 목표를 뒷받침하는지
- 핵심결과가 자신이 측정하는 목표 아래에 있는지
- 드래그한 항목이 제자리에 놓였는지
- 계층이 검토에 도움이 되는지, 아니면 모양만 갖췄는지
계층으로 일을 감추지 마세요. 실행 세부 내용이라면 핵심업무 캔버스에 담으세요.
체크인에는 경과가 남아야 합니다
좋은 체크인은 숫자만 바꾸지 않습니다. 지난 리뷰 이후 무엇이 바뀌었는지, 무엇이 막혔는지, 다음에 무엇을 할지 설명합니다.
| 아쉬운 체크인 | 더 나은 체크인 |
|---|---|
계속 진행 중 | 35%입니다. 고객 인터뷰는 끝났고, 녹화본 2건을 아직 검토해야 해서 정리 캔버스가 늦어지고 있습니다. |
정상 | 60%입니다. 고객 지원팀이 템플릿을 쓰기 시작했습니다. 다음 리스크는 교육 기관 고객이 통화 없이 템플릿을 활용할 수 있는지입니다. |
막힘 | 공개 요금 안내 문구의 법무 승인이 나지 않아 멈춰 있습니다. 담당자가 화요일에 다시 확인하고, 검토가 끝나면 핵심업무 캔버스를 업데이트합니다. |
스냅샷의 쓸모는 그 안에 담긴 체크인의 질에 달려 있습니다. 체크인이 모두 모호하면 스냅샷에도 모호한 내용만 남습니다.
문제가 생겼을 때
핵심결과가 모두 할 일처럼 보이면 할 일 형태의 항목을 핵심업무로 옮기고, 핵심결과는 측정할 수 있는 성과로 다시 쓰세요.
목표를 달성했는지 팀 의견이 갈린다면 목표가 너무 모호하거나 핵심결과가 올바른 성과를 증명하지 못하고 있을 가능성이 높습니다.
핵심결과를 업데이트할 수 없다면 다음 체크인 전에 단위를 바꾸거나, 데이터를 챙길 사람을 분명히 정하세요.
OKR 주기에 항목이 너무 많다면 트리 뷰에서 중복된 계층을 찾고, 팀 정책에 따라 합치거나 오래된 항목을 보관하세요.
일이 어디서 진행되는지 계속 질문이 나온다면 핵심업무를 추가하거나 이름을 바꿔, 중요한 일마다 연결된 캔버스가 분명히 보이게 하세요.