일이 되게 만드는 마법, RACI와 의사결정 가이드라인
by Meme • 2025.06.011
쑥쑥찰칵 OKR "재"도입기
우린 핸들이 고장난 8톤 트럭, 방향을 잡아야 할 때 - 쑥쑥찰칵 OKR "재"도입기 - 1편
OKR 워크숍 준비부터 실행까지, 우리만의 방식 찾기 -쑥쑥찰칵 OKR "재"도입기 - 2편
1~2편을 건너 3편에 도달 했다. 지금도 OKR 관련한 운영 이슈들이 계속해서 떠오르고 있는데, 팀원 모두가 함께 힘을 합쳐 정리하고 만들어가는 중이다.
OKR은 대표 혼자 만드는 것이 아니라 팀원과 함께 만드는 것이고, 한번 만들어졌다고 끝이 아니라 계속 살피면서 업데이트 해야 하는 것이다.
오늘은 2편 말미에 소개했던 RACI. 실제로 목표를 달성하기 위해 실행 계획을 세우고 실무들이 일을 할 때 정말 중요한 개념을 소개해보려고 한다.
RACI는 무엇인가요? 인도 음료 아닌가요..?
처음 RACI라는 용어를 들었을 때 내가 좋아하는 인도 요거트 음료 라씨가 떠올랐다. (그래서 까먹지 않는다)
우리 같은 작은 조직에 이런거까지 해야 하나.. 싶어서 처음엔 알고도 도입 하지 않았지만 이번에 OKR을 도입하면서 같이 적극적으로 도입했고, 그 결과 지금 커뮤니케이션을 할 때 가장 큰 도움이 된 것 중 하나가 바로 이 RACI 차트다.
RACI는 다음과 같은 4가지 역할을 명확히 정의하는 도구다:
•
R = Responsible (실무 담당자): 해당 업무를 직접 수행하는 사람
•
A = Accountable (최종 책임자): 업무의 최종 책임자. 최종 의사결정을 내리고 결과에 대해 책임을 진다. (반드시 단 한 명!)
•
C = Consulted (사전 협의/자문 대상): 업무 진행 전에 의견을 구하거나 정보를 제공받아야 하는 사람들
•
I = Informed (사후 공유 대상): 업무 진행 상황이나 완료 결과에 대해 사후에 정보를 받아야 하는 사람들
출처: infoDiagram
RACI의 샘플을 보면 한눈에 해당 Task가 몇명의 인력으로 어떻게 구성되어있는지 알 수 있다. 이런식으로 각 Task 별로 어떤 사람들이 필요한지를 정리 한다. 특히 R의 경우에는 실무를 진행할 때 예상되는 여러 전문영역을 정리하고 R로 들어오는 사람들이 어떤 역할을 할 지도 명확하게 하는 것이 좋다. (개발자가 필요한지, 디자이너/마케터가 필요한지 등등을 미리 예측하고 배치하는 형태)
간단해 보이지만, 이 네 가지 역할을 명확히 하는 것만으로도 "이거 누구한테 물어봐야 하지?", "이 결정은 누가 내리는 거지?" 하는 수많은 혼란과 시간 낭비를 줄여준다.
각 Initiatives 마다 RACI 배치하기:역할이 명확할 때, 자율성은 빛을 발한다
우리는 2분기 OKR을 설정할 때, 각 KR마다 하나의 핵심 Initiative를 두고 실행하기로 했다.
그리고 각 Initiative마다 RACI를 명확히 배치했다.
예를 들어, "국내 신규 가입 부모의 첫 가족 초대 완료율을 n%에서 n%로 향상시킨다"는 KR이 있었다면:
•
A (Accountable, 최종 책임자): UX 디자이너 B님. 이 Initiative의 성공이라는 결과에 대한 최종 의사결정과 책임을 진다.
•
R (Responsible, 실무 담당자): iOS 개발자 C님, Android 개발자 W님, 기획자 S님. 각자의 전문 분야에서 실제 업무를 수행하고 결과물을 만들어낸다
•
C (Consulted, 사전 협의): CTO님. 기술적 제약사항이나 방향성에 대해 사전 조언을 구한다.
•
I (Informed, 사후 공유): 운영 및 CS 담당 J님. 진행 상황과 결과를 공유받아 고객 응대에 활용한다.
이렇게 역할과 책임자를 명확히 하고 시작하니, 모두가 자신이 무엇을 해야 하고 누구와 소통해야 하는지 알게 되어 업무 효율이 눈에 띄게 좋아졌다. 특히 "A"가 명확해지니, 모두가 "저 분에게 최종 확인을 받으면 되는구나!" 하고 안심하고 자신의 "R" 역할에 집중할 수 있었다.
쑥쑥찰칵에서는 누구나 'A'가 될 수 있다
여기서 가장 중요한 점은, 저희 예시의 "A"였던 UX 디자이너 B님이 고정된 '팀장'이 아니라는 것입니다. 팀장이 없는 수평적인 우리 팀에서는, 누구나 주도적으로 해결하고 싶은 문제를 발견하고 그 해결을 책임지겠다는 의지만 있다면 "A"에 도전할 수 있는 분위기를 만들었습니다.
저는 우리 모든 팀원들이 본인의 전문 분야에 대한 지식뿐만 아니라, 하나의 프로젝트를 처음부터 끝까지 이끌어가는 리딩 능력을 갖춰야 한다고 생각합니다. 단순히 주어진 일을 수동적으로 하는 것과, 직접 문제를 정의하고, 해결책을 만들고, 고객의 반응을 보고, 다시 문제를 정의하는 이 완전한 사이클을 경험하는 것은 개인과 회사에 전혀 다른 차원의 임팩트와 성장을 가져다줄 것으로 확신합니다.
AI 시대, '문제 해결 능력'이 최고의 커리어
특히 지금과 같이 AI가 많은 단순 업무를 대신해 줄 수 있는 환경에서는, 우리에게 더욱 중요해지는 것이 바로 '생각하는 능력', '문제를 정의하는 능력', 그리고 '올바른 질문을 하는 능력'이다.
쑥쑥찰칵에서 "A"의 역할을 경험한다는 것은, 바로 이 대체 불가능한 역량들을 압축적으로 훈련하는 과정이다. 프로젝트를 성공적으로 리딩하는 경험을 통해 얻은 이 능력들은, 비단 쑥쑥찰칵 안에서뿐만 아니라 우리 팀원들이 앞으로 어떤 커리어를 쌓아가든 어디에서도 인정받을 수 있는 최고의 자산이 될 것이라고 믿고있다.
A와 R의 권한과 책임
어디까지 제가 결정할 수 있나요?
팀원들이 가장 많이 물어본 질문이었다. "제가 A인데, 어디까지 혼자 결정해도 되나요?" 이 질문에 대한 우리의 답은 의사결정 레벨링이었다.
우리는 의사결정을 4단계로 나누었다:
•
Level 1: 팀원 스스로 의사결정 (일상적인 실행 방법, 세부 일정 조정 등)
•
Level 2: 팀 내 결정 후 대표에게 공유 (주요 방향성 변경, 예산 사용 등)
•
Level 3: 대표와 협의 후 팀에서 실행 (전략적 방향 전환, 다른 팀에 영향을 주는 결정 등)
•
Level 4: 코파운더/대표가 팀에 공유 후 피드백 수렴 (회사 전체 방향성, 채용, 투자 등)
A 담당자는 Level 1과 2에서는 자율적으로 결정할 수 있고, Level 3 이상에서는 반드시 상위 의사결정권자와 협의해야 한다는 명확한 가이드라인을 만들었다.
정렬된 자율에 대한 이야기
"자율성"이라는 말을 들으면 "내 마음대로 할 수 있다"고 생각하기 쉽다. 하지만 우리가 추구한 건 "정렬된 자율성(Aligned Autonomy)"이었다.
이는 "회사의 목표(Objective와 KR)에 정렬된 상태에서, 그 목표를 달성하기 위한 '방법'을 주도적으로 찾아 실행할 수 있는 자유"를 의미한다. 즉, What(무엇을)과 Why(왜)는 명확히 정해져 있고, How(어떻게)에 대한 자율성을 주는 것이다. 예를 들어, "가족 초대율 n% 달성"이라는 What과 "nn만 사용자 달성을 위해"라는 Why가 명확하다면, 그것을 달성하기 위한 구체적인 방법(온보딩 개선, 인센티브 제공, UX 개선 등)은 A 담당자가 자율적으로 실험하고 결정할 수 있다는 뜻이다.
이렇게 하니까 팀원들의 주인의식이 확연히 높아졌다. "시키는 일을 하는" 수동적인 자세에서 "목표 달성을 위해 최선의 방법을 찾는" 능동적인 자세로 바뀌었다.
A의 결정에 대한 코칭/피드백에 대한 이야기
A"가 세운 계획이라도, 그것이 KR 달성에 최선의 길이 아니라고 판단되면 동료나 리더는 데이터와 논리를 바탕으로 피드백을 줄 수 있어야 한다. 여기서 중요한 것은 "데이터"와 "논리"다.
감으로 그 의견에 대해 반대의견을 제시하는 것은 옳지 않다. 우리는 누가 맞는지 가리는 사람들이 아니다. "더 나은 방향을 찾고 함께 부동의 목적지에 빠르게 갈 수 있도록 협력하는 사람들"이다. "A"는 그 피드백을 '나에 대한 공격 혹은 내 방향성에 대한 개입'이 아닌 '목표 달성을 위한 도움과 코칭'으로 받아들이려는 자세가 필요하다. 또한 리더나 동료들은 깊게 먼저 고민한 A를 인정하고 "데이터"와 명확한 "논리"로 설득 하려는 자세가 필요하다. 이 과정이 꼭 있어야만, 실행 계획과 방향성은 더 단단해질수 있다.
저는 R이면서도 A이기도 해요.중복된 역할 분담에 대해서, 어떻게 조정해야 할까?
우리 팀의 현실이기도 했다.
14명이라는 규모에서 대부분의 팀원들이 특정 KR의 A이면서 동시에 다른 KR의 R 역할을 맡고 있었다. 처음엔 정말 헷갈렸다.
예를 들어, 개발자 한 분이 "가족 초대율 개선" KR의 A를 맡으면서 동시에 "구독자 전환율 개선" KR의 R도 맡고 있었다. 이때 시간 배분을 어떻게 해야 할지, 우선순위는 어떻게 정해야 할지 고민이 많았다. 이럴 때 길을 잃지 않고 효과적으로 기여하기 위한 쑥쑥찰칵의 약속은 다음과 같다.
1. '모자 바꿔쓰기(Hat Switching)'를 의식적으로 연습해야 한다.
가장 중요한 것은 '현재 내가 어떤 모자를 쓰고 있는가?'를 스스로 명확히 인지하고, 그 역할에 맞는 책임과 행동을 하는 것이다.
"A 모자"를 썼을 때: 당신은 해당 KR 달성의 지휘자로, 전체적인 그림을 보고, 목표 달성을 위한 전략을 고민하며, 다른 R 담당자들이 최고의 역량을 발휘하도록 돕고, 최종 결과에 책임을 지는 사람이다. 주로 "우리가 이 KR을 달성하기 위해 무엇이 필요한가?"를 질문하고 논의를 이끌어야 한다.
"R 모자"를 썼을 때: 당신은 특정 Initiative를 성공시켜야 하는 전문가이자 실행가이다. 맡은 업무의 진행 상황과 문제점을 투명하게 공유하고, 자신의 전문성을 바탕으로 최선의 결과물을 만들어내며, 해당 KR의 A 담당자와 긴밀하게 협력한다. 회의에서는 주로 "제가 맡은 이 부분을 성공시키기 위해 이런 시도를 하고 있고, 이런 도움이 필요합니다."를 이야기 해야 한다.
회의에 들어가기 전, 또는 새로운 업무를 시작하기 전에 "나는 지금 이 자리에서 어떤 모자를 써야 할까?"라고 스스로에게 질문하는 것만으로도 역할에 대한 혼란을 크게 줄일 수 있다.
2. 우선순위는 '나의 KR'이 아닌 '회사의 Objective' 관점에서 판단해야 한다.
A 역할과 R 역할의 업무가 동시에 주어져 시간이 부족할 때, 무조건 내가 A인 일이 우선일까? 정답은 '아니오'다.
이때의 판단 기준은 단 하나, "어떤 일을 먼저 하는 것이 이번 분기 회사 전체의 Objective 달성에 더 큰 영향을 미칠까?" 입니다.
3. 투명한 소통으로 기대치를 조율해야 한다.
우선순위 충돌이나 업무량 과부하가 예상될 때 가장 나쁜 것은 혼자 끙끙 앓는 것. 이는 결국 두 가지 일 모두의 결과물 품질을 떨어뜨릴 수 있습니다.
먼저 공유하고, 팀원들이 1차 조율 해보고 그래도 안된다면 "노란불"을 켜고 대표에게 도움을 요청하면 된다. 대표가 존재하는 이유이기도 하다.
결론적으로, 여러 역할을 맡는다는 것은 우리 팀에 꼭 필요한 다재다능한 인재라는 증거다. ① 내가 쓴 모자를 명확히 인지하고, ② 회사 전체 목표 관점에서 우선순위를 판단하며, ③ 동료들과 투명하게 소통하고 조율하는 것. 이 세 가지를 기억한다면, 우리는 역할의 혼란 속에서도 더 큰 시너지를 만들어내며 함께 성장할 수 있다고 판단한다.
나의 KR달성 보다모두의 부동의 목적지 달성을 위해서!
OKR을 처음 도입 했을 때 팀별 사일로를 경계했기 때문인데 OKR을 도입하고 나서도 "내가 담당하는 KR"이라는게 생기면 다시 사일로 현상이 벌어질 수 있다. (그러므로 더더욱 KR의 달성과 평가를 동일한 선상에서 두면 안된다. 이렇게 되면 무조건 다시 사일로가 생긴다. 이 이야기는 평가 이야기를 할 때 다시 하도록 한다)
항상 우선순위를 다르게 가져가야 하는 것은 "나의 KR이 아닌 우리의 부동의 목적지"이다. 우리의 모든 분기 OKR은 결국 부동의 목적지와 연결되어 있다. 내 KR만 달성한다고 그 목적지에 도달할 수 있을까? 절대 아니다. 우리가 모두 함께 그 목적지를 향해 나아갈 때만 달성할 수 있다.
실제로 우리는 다음과 같은 마인드셋을 가지기 위해 계속해서 리마인드 하고 있다.
•
연결된 시각: 나의 KR 달성이 다른 팀의 KR에 어떤 영향을 주는지 항상 생각한다
•
기여의 확장: A로서 내 KR을 책임지는 것도 중요하지만, R로서 다른 KR에 기여하는 것도 매우 중요하다
•
목표 달성 우선: 지금 동료에 대한 "배려"보다 목표 달성을 위한 "기여"가 더 중요하다
예를 들어, "지금 이 말을 해도 되나? 지금 내가 이 일을 해도 되나? A가 안 시켰는데 내가 나서도 되나?" 같은 생각들이 부동의 목적지 달성에 도움이 될까? 절대 아니다. 목표 달성을 위해서라면 적극적으로 나서고 기여하는 게 훨씬 중요하다.
OKR을 계속해서 만드는 것이기 때문에.. 지금도 우리 팀에는 다양한 이슈들이 존재하고 수정하고 변경하고 있는 중이다. 앞으로 두 부분에 대해서 조금 더 정리 해보려고 한다. 나의 이렇게 소소한 정리들이 누군가에겐 도움이 되길 바라며..!
•
4편: 노란불/빨간불은 언제 켜야 하는가?
•
5편: OKR와 연계하여 만들 수 있는 성과/ 평가 기준과 1on1을 통해 피드포워드하기