MBC PD수첩 1512화의 '다정한 AI' 가설을 검증할 실험 앱을 만들고 현장 실험과 인터뷰를 붙였다. 글로 푼 가설은 설명을 남기고 손으로 써본 도구는 반응을 남기며, 방송 재료는 후자에서 나왔다. 가설 검증 앱을 만든다면 측정 항목과 통제 조건을 먼저 고정하고, 기능은 덜어내는 쪽으로 간다.
의뢰 설명을 듣는 자리에서 먼저 정해진 것은 주제가 아니라 산출물의 형태였다. 9월 3일 개발기 원문에 적었듯, MBC 시사교양 프로그램 PD수첩 제작진이 확인하고 싶어 한 가설은 문헌을 뒤져 답이 나오는 종류가 아니었다. 사람 손에 도구를 쥐여 주고 써 보게 해야 드러나는 가설이었고, 그래서 이 프로젝트의 첫 산출물은 보고서가 아니라 동작하는 앱이 됐다.
문서와 도구는 남기는 증거가 다르다. 주장을 문장으로 정리하면 읽는 사람에게 설명이 전달되고 거기서 끝난다. 같은 주장을 사람이 직접 조작하는 화면으로 옮기면, 참여자가 기획자의 예상을 벗어나 움직이는 순간이 생기고 그 움직임은 데이터로 남는다. 인터뷰도 같은 이유로 갈린다. 도구를 겪은 다음에 나오는 답과 설명을 듣고 나오는 답은 방송에서 같은 비중으로 쓸 수 없고, 제작진에게 필요한 것은 앞쪽이었다.
기업 교육 현장에서 우리가 반복하는 경고가 있다. AI가 준 답을 검증 없이 받아들이지 말라는 것이다. 이번 일은 그 경고를 뒤집어 본 작업이었다. AI를 잘 쓰는 법 대신, AI가 사람의 판단을 어느 지점에서 어떻게 밀어내는지를 참여자가 직접 겪고 시청자가 보게 만드는 도구가 필요했다. 어디서 잘못 쓰이는지 모르면 잘 쓰는 법도 가르칠 수 없으니, 교육에서 말로만 하던 경고의 근거를 직접 제작한 셈이다.
측정 항목을 정하는 단계가 코드를 쓰는 단계보다 길었다
| 항목 | 내용 |
|---|---|
| 의뢰 | MBC 시사교양 프로그램 PD수첩 |
| 방영 | 2026년 6월 23일, PD수첩 1512화 「AI, 이토록 다정한 배신자」 |
| 방식 | 실험용 앱 개발 + 현장 실험 + 인터뷰 |
| 대상 | 방송 제작진, 실험 참여자 |
일은 실험 설계, 앱 개발, 실험과 인터뷰 순으로 흘러갔고, 시간이 가장 많이 들어간 곳은 맨 앞이었다. 실험 설계에서 정한 것은 두 가지다. 어떤 값을 잴 것인가, 그리고 재는 동안 무엇을 고정해 둘 것인가.
이 두 가지가 흐릿한 상태로 구현에 들어가면, 실험이 끝난 뒤 데이터는 쌓여 있어도 그 데이터로 무엇을 말할 수 있는지 알 수 없게 된다. 구현이 시작되기 전인 이 단계에 시간을 가장 많이 쓴 이유가 그것이다. 제목의 "코딩보다 측정 설계"는 이 시간 배분을 가리킨다.
기능은 측정 항목에 붙는 것만 남겼다
개발 단계의 기준은 하나였다. 측정에 쓰이지 않는 기능은 아무리 그럴듯해도 넣지 않고, 그 최소 구성으로 서둘러 배포한다. 만드는 동안 떠오르는 추가 아이디어는 대부분 "있으면 좋은" 편의 기능이었다. 문제는 그런 요소 하나가 참여자의 행동 자체를 바꿔 놓고, 바뀐 행동이 결과에 섞이면 해석이 흐려진다는 점이다. 그래서 이 프로젝트에서 어려웠던 판단은 무엇을 만들 것인가보다 무엇을 만들지 않을 것인가였다.
실험 자체는 참여자가 앱을 쓰는 동안 데이터를 모으고, 끝난 뒤 인터뷰로 이어지는 구성이었다. 인터뷰가 맡은 몫은 수치로 표현되지 않는 부분이다. 데이터와 인터뷰 둘 중 하나만으로는 방송에 쓸 재료가 되지 않았다.
편성일이 요구사항 정의서를 대신했다
일반 개발 프로젝트와 갈라지는 지점은 마감의 성격이다. 방송에는 편성일이 있다. 편성일이 정해져 있다는 것은, 기획 확정과 앱 배포 사이의 간격을 얼마나 좁히느냐가 곧 이 작업의 성패라는 뜻이었다.
그 간격은 요구사항을 문서로 완결한 다음 구현에 들어가는 순서로는 좁혀지지 않는다. 그래서 순서를 뒤집었다. 일단 만들어 띄우고, 써 보면서 맞는지 확인하고, 틀리면 그 자리에서 고쳤다. AI 도구를 붙인 개발이 효과를 내는 지점도 바로 이 간격이다. 머릿속 아이디어가 참여자가 실제로 쓸 수 있는 화면이 되기까지 걸리는 시간을 줄이는 것, 이 작업에서 AI 도구의 역할은 그것이었다.
결과는 6월 23일 PD수첩 1512화로 방송됐다. 이 회차가 다룬 것은 사용자의 편만 들어 주는 AI가 사람의 판단을 어디까지 밀어내는가였다. 방송에 나온 사례 중에는 AI가 무조건 지지해 준 판단을 근거로 무리한 선택을 한 경우가 있었고, 그 변화가 일어나는 데 걸린 기간은 몇 달이 채 되지 않았다. AI 캐릭터 서비스와 청소년의 접촉 문제도 같은 회차에 들어갔다. 이 가운데 우리 몫은 두 가지를 참여자가 몸으로 겪게 하는 앱이었다. AI가 사용자에게 맞춰 주는 방식, 그리고 그 맞춤이 사용자의 판단에 미치는 영향이다. 촬영 뒷이야기는 인터뷰 비하인드 브이로그에 있다.
가져갈 것
가설 검증용 프로토타입을 외부에 맡기거나 내부에서 만들기 전에, 이 프로젝트에서 확인된 조건을 자기 조직에 대입해 본다.
- 무엇을 잴지와 무엇을 고정할지를 개발 착수 전에 정의했는가? 이 단계가 가장 길어도 된다.
- 앱의 기능 하나하나가 측정 항목에 대응하는가? 대응하지 않는 "있으면 좋은" 기능은 뺐는가?
- 숫자로 잡히지 않는 부분을 채울 인터뷰를 실험과 한 묶음으로 계획했는가?
- 기획 확정부터 배포까지의 마감이 편성일처럼 날짜로 박혀 있는가?
- 요구사항 문서를 완결한 뒤 구현하는 대신, 띄우고 써 보며 고치는 주기로 진행할 수 있는가?
안 되는 경우
- 측정 대상을 먼저 정의할 수 없는 주제. 측정이 흐릿한 채로 개발하면 쌓인 데이터를 해석할 수 없고, 앱은 검증 도구가 아니라 시연물이 된다.
- 편성 마감 같은 외부 시한이 없는 프로젝트. 띄우고 고치는 방식은 방송 마감이라는 조건에서 택한 것이고, 원문은 마감이 느슨하거나 요구사항이 처음부터 고정된 경우를 다루지 않는다.
- 원문이 밝히지 않은 것: 실험 참여자 수, 앱의 기술 스택과 사용한 AI 개발 도구명, 기획 확정에서 배포까지 걸린 일수, 측정 지표와 실험 결과 수치. 실험이 방송에 어떻게 쓰였는지는 VOD로 확인해야 한다.
조직 안에 "이럴 것이다"로 굳어 있는 주장이 하나 있다면, 이번 주에는 그 주장을 뒷받침할 보고서를 쓰는 대신 사람이 눌러볼 수 있는 화면 하나를 먼저 만들어 반응을 받아 본다. 이 프로젝트에서 조녁컴퍼니가 한 일도 강의가 아니라 가설을 소프트웨어로 옮겨 사용 데이터로 확인하는 쪽이었다. 사업영역 →