7 min read

Results Chain: 진짜 가치를 만들어내는 단계적 목표 설정의 기술

여러분은 요즘 집중하는 프로젝트가 있으신가요? 그 프로젝트는 어떤 Impact와 Outcome을 위한 것인가요?

제가 몇 년 전부터 목표 설정을 할 때 유용하게 써먹고 있는 Results Chain이라는 사고 모형을 소개합니다. 목표를 '내가 영향력을 행사할 수 있는 정도'에 따라 여러 층위로 나누고 연결하는 것인데요. 이 모형이 제 머릿속에 잘 박혀있다보니 코칭, 주니어와 1:1, 프로젝트 설계, 교육 설계 등 제가 하는 거의 모든 활동에서 큰 도움을 주고 있습니다.

그림으로 표현하면 대략 다음과 같습니다. 도널드 커크패트릭의 4단계 훈련 평가 모형(반응 - 학습 - 행동 - 결과)과도 유사한 면이 있습니다.

이 모형에서 아래에 있을수록 내가 직접적인 통제를 하기 수월하고, 따라서 측정하기도 쉽고, 행동하기도 쉽습니다. 그러나 그 행동을 하면 뭐가 좋아지냐? 라는 질문에는 대답하기 궁색해지죠. 반대로 위에 있을수록 외부 변수(시장 상황, 경쟁사 등)가 더 많이 개입하기 때문에 내 행동과 결과 사이의 인과관계가 흐려집니다. 즉 '내 기여분'을 주장하기는 어렵지만, 나와 내 조직이 궁극적으로 원하는 바에는 더 가까워집니다.

현실에서는 이 모형을 양방향으로 활용할 수 있습니다. 같은 목표에 대해 이쪽으로도 생각해보고 저쪽으로도 생각해보는 것입니다. 한 방향으로만 움직이는 게 아니고 계속 왔다갔다하는 게 중요합니다.

Input부터 올라가기

어떤 행동을 해야겠다, 하고 싶다는 목표 또는 욕구가 생겼다고 가정해봅시다. 예를 들어 '코딩 시간을 더 늘려야겠다' 같은 거죠. 이 목표를 달성하기 위한 행동은 뭘까요? '매일 퇴근 후 1시간씩 야근하며 개인 시간을 확보해 코딩한다' 같은 걸 생각할 수 있겠네요.

이렇게 목표와 행동계획을 세우는 건 쉽습니다. 하지만 '하기 쉬운' 행동이 꼭 유의미한 것은 아닙니다. 내가 애초에 코딩 시간을 왜 늘리고 싶었을까? 코딩 시간을 늘림으로써 어떤 결과가 생기길 기대하는가? 같은 질문을 던져보면서 그 다음으로 나아가는 게 필요합니다.

이를 제품 개발팀의 목적과 연결하면 '더 많은 기능을 배포한다', '제품의 매출을 올린다' 같은 상위 목표가 생길 수 있습니다. 이렇게 연결해보면 그 연결고리(가설)에 대한 건강한 의심을 던지고, 변주해보는 것도 가능해집니다. 예를 들어:

  • 의심하기: '제품의 매출을 올리려면 더 많은 기능을 배포해야 한다'는 가설이 참이라고 생각할 만한 근거가 뭐지? '더 많은 기능을 배포하려면 나의 코딩 시간을 늘려야 한다'는 가설이 참이라고 생각할 만한 근거는 뭐지?
  • 변주하기: 내가 코딩 시간을 늘리는 것 외에 더 많은 기능을 배포하는 데 도움이 되는 행동은 뭐가 있을까? 오히려 코딩 시간을 줄이면서도 더 많은 기능을 배포할 수도 있지 않을까? 심지어, 배포하는 기능을 줄이는데도 매출은 더 오르는 상황을 만들 순 없을까?

참고로 무엇이 Impact이고 무엇이 Outcome이냐는 프로젝트의 크기와 성격에 따라 다릅니다. 위 그림에서는 주체를 '제품 개발팀'으로 보고 최종 Impact를 '매출'로 두었지만, 회사 입장에서 보면 매출이 Outcome, 또는 Output 수준으로까지 내려올 수 있습니다.

Impact부터 내려오기

13년 전, 대학 창업동아리에서의 활동으로 '30년 계획'을 세운 적이 있습니다. 그로부터 많은 시간이 흘렀고, 계획의 디테일한 부분까지 매일같이 기억하며 살고 있진 않지만, 최상위 목표였던 이 문장 하나만큼은 줄곧 마음속 깊이 새겨져 있었습니다.

'내가 있었기 때문에 이 세상이 조금이나마 더 나아졌다'는 말을 스스로 자신있게 할 수 있는 사람이 된다

이를 위한 행동 계획 중 하나가 '만 55세가 되기 전에 자서전을 완성하고, 그 자서전에 이 문장을 쓴다'였고요. 이를 위해 '교육'과 '글쓰기' 역량 향상에 집중한다... 같은 게 이어졌었죠.

저는 개인이 가진 인생의 꿈이든, 기업이 가진 미션이든 간에, 그 원대한 목표와 현실 사이를 쪼개서 잇다 보면 성공 가능성이 높아진다고 믿습니다.

  • Impact: 거시적 목표가 무엇인가?
  • Outcome: 어떤 성과가 생기면 그 목표가 달성됐다고 할 수 있는가?
  • Output: 어떤 산출물이 생기면 그 성과를 만들어냈음을 확인할 수 있는가?
  • Input: 어떤 자원을 투입하여, 어떤 행동을 하면 그 산출물이 만들어질까?
  • Action Item: 그래서, 오늘과 이번주에 누구와 함께 구체적으로 무엇을 해볼까?

맺으며

서두에 언급했듯 저는 이 모형을 제 삶의 굉장히 여러 군데서 활용하고 있습니다. 예전에 썼던 Jobs-to-be-done + 5 Whys 로 제품 본질 파고들기 (feat. 문라이트) 글은 제품의 방향성을 설계할 때 'Input부터 올라가기'를 해봤던 것이었고요. 코르카 AX 컨설턴트의 Job Description과 OKR을 작성할 때, 교육 및 행사를 설계할 때는 'Impact로부터 내려오기'를 사용합니다. (JD와 교육 설계에 대한 글도 조만간 하나씩 풀어보겠습니다.)

참고로 저는 이 사고 모형을 국제 비영리단체 INTRACMonitoring and Evaluation Planning Series의 한 글을 통해 최초로 인식하게 됐습니다. 그 글에서는 OECD DAC(개발도상국에 대한 정부개발원조를 논의하고 조정하는 기구)가 이 개념을 최초로 고안했다고 하더군요. 그걸 존중해 그림에도 출처를 표시해놨습니다.

INTRAC의 글을 읽으며 OECD의 국가 단위 프로젝트라면 이런 단계들을 구분하는 게 반드시 필요했겠다는 생각이 들더군요. 하지만 우리라고 OECD급 프로젝트를 못할 이유는 없죠. 😀

여러분은 요즘 집중하는 프로젝트가 있으신가요? 혹시 Output만을 목표로 달리고 있지는 않으신가요? 잠시 멈춰서, 그 프로젝트가 만들어내야 할 진짜 변화(Outcome)가 무엇인지 공유해주세요.