스타트업은 하루를 걸러 수도 없는 결정 사항들이 정해지고 수정하기가 반복된다.
소규모의 인원이라면 대화만으로 충분히 커버되는 영역이다. 하지만 조직이 성장함에 따라 커뮤니케이션 오류가 발생하게 되고, 이런 오류가 누적되다 보면 제품에 악영향을 미치게 된다.
오일나우 팀도 서비스가 성장하고 각 팀원들의 역할 및 이해관계가 복잡해짐에 따라 새로운 프로세스 도입에 대한 논의가 오갔다.
이를 위해 타 회사의 프로세스들을 분석하던 도중 “OKR”에 대해 알게 되었다.
OKR 이란?
OKR은 “구글이 일하는 방법”, “조직 성장을 위한 목표 설정 프레임워크” 등 다양한 수식어가 붙어 있는 널리 알려진 철학이자 프레임워크이다.
“Objectives and Key Results”
위키피디아에서는 OKR을 “목표와 그 목표에 대한 결과를 정의하고 추적하기 위한 프레임워크” 라고 설명한다.
즉 목표(Objective)를 선정하고, 그에 맞는 핵심 결과 지표(Key Results)들을 정의하여 팀의 업무 성과를 높여주는 도구이다.
OKR을 설정하는데 몇 가지 숙지할 사항들이 있다.
목표(O)를 정할 땐 정량적인 내용이 아니라 비전을 포함하는 내용으로 팀원들이 공감할 수 있도록 작성해야 함.
핵심 결과 지표(KR)는 측정 가능 해야 하며, 달성하기 쉽지 않은 어려운 목표로 설정. (단, 불가능한 것은 안 됨)
이외에도 이 도구를 설명하는 많은 내용들이 있지만 생략하도록 하겠다.
이 글에서는 OKR에 대한 방법론적 정의 보다, 하나의 스타트업이 이를 활용하는 과정에서 어떤 일이 있었고, 어떤 성과를 냈는지 회고하는 데 초점을 맞추었다.
OKR 도입하기
그럼 오일나우 팀은 왜 OKR을 도입하기로 하였을까? OKR이 논의된 시점, 아래와 같은 문제점들이 발견 되었다.
팀 내에서 프로젝트의 비전이 명확하지 않음.
프로젝트 결과에 대한 측정 및 회고 시스템 부재.
1. 팀 내에서 프로젝트의 비전이 명확하지 않음
오일나우 팀의 일부 멤버는 리모트 환경에서 근무한다. 주간 회의를 진행하긴 하지만 제품 개발팀과 주로 기획 문서(구현 기능 위주의 문서)를 가지고 커뮤니케이션하다 보니 프로젝트의 비전이 공유되긴 쉽지 않았다.
또한 프로젝트가 끝나고 난 후 결과를 분석하는 과정에서도 문제가 발견되었다. 프로젝트(X)의 결과를 분석하다 보면 처음 가설(A)과 다른 결과(B)가 나타날 때가 있다. 목표 및 가설에 대해 명확하게 정의하지 않고(구두로 내용 공유) 프로젝트를 수행하다 보니 (A) 가설에서 (B) 결과가 도출된 원인은 온데간데없고, 단순히 “이 프로젝트(X)를 수행한 결과는 (B)다” 라는 식의 해석만 남게 되었다.
비전을 정하고 가설을 세운 뒤 이를 명확하게 공유할 수 있는 도구가 필요했다.
2. 프로젝트 결과에 대한 측정 및 회고 시스템 부재
기존에는 프로젝트 결과에 대한 판단 기준 자체가 모호했다. 기능 위주의 기획이 중심이다 보니 분석 가능한 정량적인 수치 설정에는 한계가 있었다. (이 시점에서는 페이지 뷰 단위의 유저 lifecycle 분석이 주를 이루었다)
이러다 보니 프로젝트 결과는 모호하게 마무리되었고, 회고할 기준이 명확하지 않다보니 회고가 제대로 이루어지지 않았다.
정량적인 측정 및 회고 시스템을 OKR 도입하여 잡아나가기로 하였다.
소규모 스타트업의 특성으로 인해 OKR 적용 대상을 팀 단위가 아닌 프로젝트 단위로 축소 시키고 팀 문화에 맞게 변형시켰다.
때마침 오일나우는 유저들이 거주하는 동네를 기반으로, 서로 의사소통할 수 있는 “커뮤니티 서비스”를 기획 중이었고 해당 프로젝트에 OKR을 적용하기로 했다.
이웃들과 동네에 대한 이야기를 나눌 수 있는 커뮤니티
기본적인 게시판 기능(글쓰기, 수정하기, 삭제하기, 읽기) 제공
글을 쓰기 위해 별도의 가입 시스템(닉네임 및 활동 지역 설정) 도입.
목표: 신규 커뮤니티 서비스를 통해 앱내 유저 리텐션 증가
KR 1) 온보딩 페이지에서 “커뮤니티 시작하기 버튼” 클릭율 80% 달성
KR 2) 커뮤니티 가입한 유저가 일주일내 커뮤니티에 재방문하는 비율 80% 달성
KR 3) 전체 오일나우 유저 중 커뮤니티 가입률 30% 달성
프로젝트를 마친 후
기획, 개발 및 실험 결과 측정까지 총 3달하고도 2주가 걸렸다. (이 시기에 여러가지 일들로 프로젝트 기간이 많이 늘어졌다..)
OKR 측정 결과는 다음과 같다.
KR 1) 온보딩 페이지에서 “커뮤니티 시작하기 버튼” 클릭율 80% 달성
커뮤니티 페이지 총 접속자 : 9,080 명
시작하기 버튼 클릭 유저 : 1,242 명
결과 달성률 : 36%
KR 2) 커뮤니티 가입한 유저가 일주일내 커뮤니티에 재방문하는 비율 80% 달성]
0~7 일 안에 재 접속률 : 87.5%
0~2 일 구간 : 88.1%
3~7 일 구간 : 7.6%
결과 달성률 : 100%
KR 3) 전체 유저 중 커뮤니티 가입률 30% 달성
최종 가입자 : 813 명
결과 달성률 : 2.6 %
우선 OKR 도입을 통해 위에서 언급한 두 번째 문제(프로젝트 결과에 대한 측정 및 회고 시스템 부재)는 어느 정도 해결되었다.
정확한 지표 설정 및 측정으로 인해 개선할 문제점을 명확하게 도출했으며 피드백을 통해 팀원 간의 의견을 공유했다.
일례로 KR 2)의 경우 수치를 분석하여 다음과 같은 새로운 가설을 세웠다.
“온보딩 페이지에서 가입률을 끌어올릴게 아니라 아예 없애, 가입에 대한 장벽을 줄이면 어떨까?”
그 결과 전체 커뮤니티 가입률은 이전과 비교하여 무려 18.6%나 상승했다.
그러나 첫 번째 문제(팀 내에서 프로젝트의 비전이 명확하지 않음)는 해결했다고 보기 어려웠다. 비전은 팀원들의 공감을 끌어내긴 부족했고, 핵심 결과 지표는 부자연스러웠다.
우리가 정한 목표는 비전이 아닌 단순한 핵심 결과 지표의 요약이었으며, 심지어 결과 지표 안에 자연스레 목표까지 집어넣는 오류를 범하게 되었다. (KR 3)
왜 목표와 핵심 결과 지표가 매끄럽지 못하고 부자연스러울까?
오일나우 팀은 원인을 찾기 위해 목표에 대한 정의를 다시 해보기로 한다. 오일나우 서비스의 목표는 아래와 같다.
“운전자가 가지고 있는, 운전에 대한 고민을 줄여주자”
프로젝트는 고객의 문제를 해결하기 위함이었지만 우리가 세운 목표는 단순히 팀의 성과 결과에 포커싱하여 설정되었다.
문제점을 인식하고 난 뒤 오일나우 팀은 목표의 정의를 우리 입장에서 설정하는 것이 아닌, 아래와 같이 바꿔보기로 결정했다.
“고객의 입장에서 고객의 문제를 해결하고 그로 인해 고객이 얻게 되는 가치로 서술해보자”
그리하여 커뮤니티 프로젝트의 목표는 다음과 같이 재 정의 될 수 있었고, 명확한 목표 아래 핵심 결과 지표 역시 자연스럽게 바뀌게 되었다.
“운전하면서 겪고 있는 문제들에 대해 이웃끼리 이야기 나눌 수 있는 공간을 제공하자”
현재 운영중인 커뮤니티 화면
마치며
오일나우 팀은 OKR 도입을 통해 다음과 같은 성과를 이루어냈다.
프로젝트의 명확한 목표 설정 및 비전 공유.
프로젝트 종료 후 지표를 통한 객관적 평가.
팀원 간의 피드백 문화.
OKR의 특징은 업무의 방향이 Bottom Up으로 향한다는 점이었다. (Key Result 들을 달성하게 된다면 자연스레 목표를 달성하게 된다)
이를 프로젝트에 녹여내자 팀뿐만 아니라 각자 개인 역시 업무를 수행할 때 훨씬 더 목표를 명료하게 설정하고 집중할 수 있었다.
또한 지표를 통한 평가를 통해 명확한 판단 기준을 제공하여 프로젝트에 대한 회고가 이루어지는 데도 많은 도움이 되었다.
프로젝트 회고란
무엇보다도 OKR 도입하면서 “고객 관점의 문제 해결 사고방식”이라는 큰 교훈을 얻었고 자연스럽게 팀 문화로 자리 잡아가고 있다.
현재 오일나우 팀은 OKR을 응용하여 아래와 같은 시나리오로 사용하고 있다.
오일나우 팀 프로젝트 진행 시나리오
고객의 입장에서 고객이 가진 문제 해결을 목표(O)로 설정하고, 이를 측정하기 위한 핵심 결과 지표(KR)를 세운 뒤 프로젝트를 기획.
프로젝트가 끝나면 핵심 결과 지표를 측정하여 얼마나 고객의 문제가 해결되었는지 분석.
분석 후 팀원들과 의견을 공유하고 프로젝트에 대한 서로간의 피드백을 교환.
피드백을 기반으로 목표 달성에 가까워지기 위한 새로운 실험을 기획.
OKR은 팀의 비전을 정하고 성과를 측정할 수 있는 좋은 프레임워크다. 하지만 OKR 외에도 매년 새로운 도구들이 사람들 입에 오르내리고 있다.
이때 유의 해야 할 것은 프레임워크 도입의 여부가 아니다. 프레임워크는 말 그대로 하나의 도구일 뿐이고 그 자체가 본질이 될 수 없다.
프레임워크를 도입하는 명확한 이유와 도입으로 인한 어떤 기대 가치가 있을지 설정한 후, 피드백의 반복을 통해 개선 시켜나가며 문화로써 자리 잡게 하는 것이 중요하다고 생각한다.
가입하기
