Results Chain: 우리가 한 일과 세상의 변화 사이를 잇는 다리

대표 이미지는 AI로 제작한 설명용 개념 이미지입니다.

“우리가 만든 게 정말 의미 있는 변화로 이어졌나?” 일하다 보면 늘 부딪히는 질문이다. 기능 하나를 출시했을 때, 그게 출시됐다는 사실과 그게 세상을 바꿨다는 사실 사이에는 사실 꽤 먼 거리가 있다. 그 거리를 단계로 끊어서 보게 해주는 틀이 Results Chain(결과 사슬) 이다.

원래는 국제개발·비영리 분야의 성과 측정(M&E, Monitoring & Evaluation)에서 쓰는 프레임워크다. 이 글은 INTRAC의 자료(Outputs, Outcomes and Impact, Nigel Simister, 2015 — OECD DAC 정의를 바탕으로 함)를 읽고 내 식대로 정리한 것이다. 분야는 다르지만, “활동과 궁극적 변화 사이를 단계로 나눈다”는 발상은 프로덕트 일에도 그대로 옮겨 쓸 수 있었다.

Results Chain의 다섯 단계

Results Chain은 우리가 투입한 자원이 최종적인 변화에 이르기까지를 다섯 단계로 끊는다. Inputs → Activities → Outputs → Outcomes → Impact. 아래로 갈수록 “우리가 통제하기 쉬운 것”에서 “우리 손을 떠난 변화”로 옮겨간다.

단계	뜻	한 줄 요약
Inputs (투입)	사용한 돈·사람·자원	무엇을 넣었나
Activities (활동)	투입을 동원해 하는 일	무엇을 했나
Outputs (산출)	활동의 결과로 나온 산물·서비스	무엇을 내놓았나
Outcomes (성과)	산출이 불러온 단기·중기 변화	무엇이 달라지기 시작했나
Impact (영향)	장기적으로 남는 의미 있는 변화	결국 삶이 어떻게 바뀌었나

흐름은 이렇다. 투입(Inputs)으로 활동(Activities)을 하고, 활동이 산출물(Outputs)을 만들고, 산출물이 변화(Outcomes)를 일으키기 시작하고, 그 변화가 쌓여 마침내 영향(Impact)에 기여한다.

예시로 따라가기

원문의 예시는 농부에게 씨앗을 나눠주는 사업이다.

Inputs — 씨앗, 운송비, 인건비
Activities — 현장에 가서 씨앗을 배포하고 농부 교육을 진행
Outputs — 배포된 씨앗, 교육받은 사람 수
Outcomes — 농부가 씨앗을 심고, 작물로 자라고, 수확해서 먹거나 판다
Impact — 장기적으로 농부와 가족의 생활 수준이 나아진다

이걸 더 일상적인 예로 옮기면 훨씬 와닿는다. 운동을 시작하는 것으로 보자.

Inputs — 운동화, 헬스장 등록비, 매주 빼두는 시간, 운동 앱
Activities — 주 3회 헬스장에 가서 정해진 루틴을 한다
Outputs — 다녀온 운동 세션 수, 소화한 운동량
Outcomes — 체력이 붙고, 계단 오를 때 덜 숨차고, 잠을 더 잘 자고, 컨디션이 좋아진다
Impact — 장기적으로 건강한 생활 습관이 자리 잡고, 삶의 질이 높아진다

두 예시 모두 핵심은 같다. “헬스장에 다녀왔다(Output)”는 절대 “건강해졌다(Impact)”와 같은 말이 아니다. 그 사이에는 몸이 실제로 적응하고 컨디션이 달라지는 여러 단계(Outcomes)가 있고, 그게 빠지면 — 출석 도장은 찍었는데 정작 아무것도 안 바뀌는 일이 벌어진다. 출석 횟수(Output)만 세고 만족하면, 정작 보고 싶었던 변화는 놓치기 쉽다.

AI 도입은 특히 Output에서 멈추기 쉽다

이 함정이 가장 자주 보이는 곳이 바로 AI 도입이다. “챗봇을 붙였다”, “GPT를 연동했다”, “회의록 자동 요약을 깔았다” — 이건 전부 Output이다. 그런데 많은 도입이 딱 여기서 끝난다. 정작 일이 빨라졌는지, 품질이 올랐는지(Outcome) 는 아무도 안 본다. 도구를 켰다는 사실과 팀이 더 잘 일하게 됐다는 사실은 전혀 다른 단계인데도 말이다.

AI 회의록 요약 도구를 팀에 들였다고 해보자. RC로 끊으면 이렇게 된다.

Inputs — 구독료, 세팅에 들인 시간, 연동할 캘린더·녹음 환경
Activities — 툴을 회의 시스템에 연동하고, 요약 프롬프트를 팀에 맞게 다듬는다
Outputs — 회의마다 자동으로 생성되는 요약본
Outcomes — 회의 후 정리 시간이 줄고, 결정사항 누락이 줄고, 불참자도 빠르게 따라잡는다
Impact — 팀의 의사결정 속도와 문서화 문화가 개선된다

여기서도 “요약본이 나온다(Output)”와 “팀이 더 잘 일한다(Outcome)”는 다르다. 요약본이 매일 쏟아져도 아무도 안 읽으면 Outcome은 0이다. AI 도입을 평가할 때 이 사슬을 대보면, 우리가 자랑하던 게 사실은 Output 자랑이었는지, 진짜 변화(Outcome)까지 닿았는지가 드러난다.

한 가지 중요한 구분: 목표는 예측되고, 결과는 실현된다

원문에 인상적인 문장이 있다. “Objectives are predicted, results are realised.” 목표(Objectives)는 우리가 미리 예측해 세우는 것이고, 결과(Results)는 실제로 실현되어 나타나는 것이라는 구분이다.

그래서 ‘Results(결과)’라는 말은 Output·Outcome·Impact를 통틀어 가리킨다. 계획 단계에서 “이렇게 되길 바란다”고 그리는 게 목표라면, 그게 실제로 어떻게 펼쳐졌는지가 결과다. 둘을 구분해두면, 회고할 때 “우리가 바란 것”과 “실제로 일어난 것”을 헷갈리지 않게 된다.

실전에서 헷갈리는 세 지점

이론은 깔끔하지만 현장에선 경계가 흐릿하다. 원문은 자주 겹치는 세 곳을 짚는데, 이게 이 프레임워크에서 가장 실용적인 부분이라고 느꼈다.

① 활동(Activity) vs 산출(Output) — ‘우물을 판다’는 행위는 활동이지만, ‘파인 우물’은 산출물이다. 행위와 그 행위의 결과물이 붙어 있어 헷갈린다. 프로덕트로 치면 ‘화면을 디자인한다'(활동) vs ‘출시된 화면'(산출). 산출 지표가 자꾸 활동처럼 쓰여서 비판받는 일이 흔하다.

② 산출(Output) vs 성과(Outcome) — 더 미묘하다. 교육을 제공한 것은 산출이지만, 교육으로 지식이 늘어난 것은 성과로 볼 수도, 산출로 볼 수도 있다. OECD 정의조차 “산출이 성과에 관련된 변화를 포함할 수 있다”고 모호하게 열어둔다. 정답은 없고, 케이스별로 판단해야 한다.

③ 성과(Outcome) vs 영향(Impact) — 거의 판단의 문제다. 어디까지를 ‘장기적·근본적 변화’로 볼지는 정의에 따라 달라진다. 제도·정책의 변화까지 Impact로 보는 정의도 있고, 개인·가구의 삶의 변화로 좁히는 정의도 있다.

원문 저자의 해법이 마음에 들었다. 복잡하게 다투지 말고 이렇게 단순화하자는 것이다 — Output은 우리가 통제할 수 있는 범위에서 내놓은 산물, Impact는 사람들의 삶에 남은 지속적·의미 있는 변화, 그리고 Outcome은 그 사이의 모든 것. 경계를 칼같이 긋기보다 양 끝을 정의하고 가운데를 넓게 두는 방식이다.

M&E의 방향: 어디서 출발할 것인가

마지막으로, 변화를 추적할 때 어느 단계에서 출발하느냐에 따라 세 가지 접근이 있다.

Output에서 위로 — 내놓은 산출물에서 시작해 성과·영향으로 거슬러 올라간다. 인과관계(기여)를 따지기 쉽고 산출물의 품질을 보기 좋지만, 조직 전체의 누적 효과는 잘 안 보인다. (로그프레임 방식이 대개 이쪽)
Outcome을 직접 — 사람들의 변화를 직접 측정하고, 뒤로(원인) 앞으로(영향) 연결을 추적한다. 더 어렵지만 진짜 변화가 일어났는지 더 잘 보인다.
Impact에서 거꾸로 — 장기 변화를 먼저 측정하고 무엇이 기여했는지 되짚는다. 가장 어렵고, 개별 프로젝트의 품질 판단엔 약하지만, 큰 그림의 변화를 보기엔 좋다.

이상적으론 셋 다 해서 교차검증(triangulate)하는 게 best지만, 그건 자원이 많이 든다. 현실에선 대부분 1번에서 시작한다.

직접 적용해보기: 프롬프트로 써먹기

Results Chain은 AI에게 “우리가 한 일을 단계별로 정렬시키는” 지시어로 쓸 수 있다. 기획이나 회고를 던지면 AI가 뒤섞어 말하기 쉬운데, 이 사슬을 강제하면 어디까지가 우리 산출이고 어디부터가 진짜 변화인지 정리된다. 바로 복붙해서 쓸 수 있는 세 가지 레시피를 정리해뒀다.

레시피 1 — 기획을 RC로 분해 + 빈틈 점검

아래 프로젝트를 Results Chain(Inputs → Activities → Outputs → Outcomes → Impact) 다섯 단계로 정리해줘.
- 각 단계가 무엇인지 한 줄씩
- 특히 Output(우리가 통제 가능한 산출물)과 Outcome(그로 인한 실제 변화)을 헷갈리지 않게 구분할 것
- 단계 사이에 '이게 정말 다음 단계로 이어질까?'라는 빈틈(가정)이 있으면 짚어줘

[프로젝트 설명 붙여넣기]

마지막 줄, 단계 사이의 ‘빈틈(가정)’을 짚으라는 게 핵심이다. Output이 저절로 Outcome이 되지 않는다는 게 이 프레임워크의 진짜 교훈이라, AI에게 그 연결고리의 위험을 미리 찾게 하면 기획의 허점이 드러난다.

레시피 2 — 지표가 Output인지 Outcome인지 판정

아래는 우리가 추적 중인 지표 목록이야. 각 지표가 Output(우리가 내놓은 산출물·활동량)인지, Outcome(그로 인해 실제로 달라진 변화)인지 판정해줘.
- 판정 근거를 한 줄씩
- 관점에 따라 둘 다 될 수 있는 지표는 그렇다고 표시하고, 어떤 관점에서 무엇이 되는지 적어줘

[지표 목록 붙여넣기]

“가입자 수, 기능 사용 횟수” 같은 게 사실 Output인데 성과처럼 보고되는 경우가 많아서, 이 판정만 시켜봐도 우리가 활동량을 성과로 착각하고 있었는지 바로 드러난다.

레시피 3 — Outcome이 비어 있는 곳 진단

아래 프로젝트(또는 OKR/지표 세트)를 보고, Output은 잔뜩 있는데 그에 대응하는 Outcome이 비어 있는 지점을 찾아줘.
- 'OO는 만들었지만, 그로 인한 변화는 무엇으로 확인하지?' 형식으로 빈 곳을 지적
- 그 Outcome을 확인하려면 어떤 신호·지표를 보면 좋을지도 제안

[내용 붙여넣기]

이건 진단형이다. 우리가 만들기(Output)에만 몰두하고 변화(Outcome)를 안 보고 있는 사각지대를 AI가 짚어주게 하는 용도다.

정리하며

Results Chain을 배우고 가장 크게 바뀐 건, “했다”에서 멈추지 않게 됐다는 점이다. 헬스장에 다녀온 것도, 화면을 출시한 것도 Output일 뿐이고, 그게 실제 변화(Outcome)를 거쳐 오래 남는 변화(Impact)에 닿기까지는 여러 단계가 더 남아 있다. 그 사이의 빈틈을 의식하는 것 — 그게 이 사슬이 주는 가장 실용적인 시선이었다.

기억할 한 가지: 우리가 통제할 수 있는 건 대개 Output까지다. 그 뒤의 변화는 설계하되, 저절로 따라온다고 가정하지 말 것.

2026년 6월 7일 우주체 네이버 블로그에 작성한 글을 옮겼습니다. 참고 자료: INTRAC · Output, Outcomes and Impact (Nigel Simister, 2015).