설계가 끝났는데, 일은 안 끝납니다
지난 편에서 네 구간을 지나왔습니다. 고객 요청을 분석하고, 학습목표를 규칙으로 옮기고, 자료를 모으고, 교안을 만들었습니다. 종이 위에서는 완성입니다.
그런데 이 과정에는 시뮬레이션 웹앱이 필요했습니다. 각 팀이 의사결정을 입력하면 결과가 자동으로 나오고, 팀별 디브리핑까지 만들어 주는 도구요. 설계대로 만들면 되는 일이었습니다.
가장 오래 걸린 곳이 여기였습니다.
만드는 건 빨랐습니다. 하루면 형태가 나왔습니다.
돌려 보고, 고치고, 다시 돌려 보는 것이 오래 걸렸습니다. 그리고 이 구간에는 «몇 번 하면 끝난다»가 없습니다.
앞의 네 구간은 한 방향으로 흘렀습니다. 이 구간은 다릅니다. 제자리를 돕니다. 이것을 지난 편에서 «루프»라고 불렀습니다. 오늘은 이 루프를 다룹니다.
이 자료는 개발 자료가 아닙니다. 코드는 나오지 않습니다. 교육담당자가 «무언가를 만들어 써야 하는 상황» — 시뮬레이션이든, 설문 양식이든, 사내 학습 사이트든 — 에서 어떻게 돌리고 언제 멈출지를 다룹니다.
무엇을 만들어야 했나
앞 편의 설계는 이랬습니다. 3시간 · 3라운드 · 팀별 의사결정 · 협업하지 않으면 성과가 안 나는 구조. 이걸 종이와 엑셀로 돌릴 수도 있습니다. 실제로 많은 시뮬레이션이 그렇게 합니다.
그런데 그러면 강사 한 사람이 감당이 안 됩니다. 여러 팀의 입력을 받아 계산하고, 팀마다 다른 피드백을 주고, 그걸 3라운드 반복해야 하니까요. 계산하는 동안 교육이 멈춥니다.
| 웹앱이 맡은 일 | 없으면 어떻게 되나 |
|---|---|
| 팀별 의사결정 입력 | 강사가 돌아다니며 받아 적습니다. 오기가 납니다 |
| 결과 자동 산출 | 엑셀로 계산하는 동안 전원이 기다립니다 |
| 팀별 맞춤 디브리핑 | 강사가 팀마다 다른 조언을 즉석에서 만들어야 합니다. 이게 불가능해서 대개 «공통 설명»으로 때웁니다 |
시뮬레이션의 학습은 «왜 그 결과가 나왔는가»를 깨닫는 순간에 일어납니다. 그런데 팀마다 다른 선택을 했으니 깨달을 지점도 팀마다 다릅니다.
사람이 하려면 강사 네 명이 붙어야 합니다. 도구가 하면 모든 팀이 동시에 자기에게 맞는 피드백을 받습니다. 이 도구는 «편하려고»가 아니라 «그 학습을 가능하게 하려고» 만든 것입니다.
여기서 잠깐. 「나는 코딩을 못 하는데」라고 생각하실 수 있습니다. 이 웹앱도 코드를 직접 쓴 것이 아니라 AI에게 만들게 한 것입니다. 요즘은 설계만 정확하면 형태가 나옵니다. 문제는 만드는 게 아니라 «제대로 되었는지 확인하는 것»입니다 — 그게 오늘의 주제입니다.
돌려 봤더니 — 문제는 세 가지 종류였습니다
첫 판이 나왔습니다. 혼자 앉아서 3라운드를 처음부터 끝까지 돌려 봤습니다. 문제가 쏟아졌습니다. 그런데 쏟아진 문제들이 같은 종류가 아니었습니다. 이걸 구분하는 것이 루프 관리의 시작입니다.
| 종류 | 어떤 모습인가 | 어디를 고쳐야 하나 | |
|---|---|---|---|
| ① | 고장 | 숫자가 안 맞는다. 버튼을 눌러도 반응이 없다. 결과가 비어 있다 | 도구를 고칩니다. 가장 쉽습니다 |
| ② | 불편 | 입력이 헷갈린다. 어디를 눌러야 할지 모르겠다. 결과를 봐도 뭘 봐야 할지 모른다 | 도구를 고칩니다. 다만 «내가 아니라 처음 쓰는 사람» 기준으로 |
| ③ | 설계 오류 | 다 잘 돌아간다. 그런데 협업을 안 해도 이길 수 있다 | 도구가 아니라 «규칙»을 고쳐야 합니다 — 앞 구간으로 돌아갑니다 |
①②번은 눈에 보입니다. 누구나 찾습니다.
③번은 «잘 돌아가기 때문에» 안 보입니다. 계산도 맞고 화면도 멀쩡합니다. 그런데 실제로 돌려 보면 참가자가 설계자가 의도하지 않은 길을 찾아냅니다.
이 사례에서 실제로 그랬습니다. 한 팀이 정보를 공유하지 않고도 높은 점수를 내는 경로가 있었습니다. 그러면 「협업해야 이긴다」는 이 교육의 전제가 무너집니다. 교육이 성립하지 않습니다.
이때 도구를 고치면 안 됩니다. 구간 ②의 «규칙»으로 돌아가야 합니다.
| 발견한 문제 | 돌아갈 구간 | 고칠 것 |
|---|---|---|
| 숫자가 안 맞는다 | 제자리 (도구) | 계산 부분 |
| 입력이 헷갈린다 | 제자리 (도구) | 화면 구성·안내 문구 |
| 숫자가 현실과 동떨어진다 | 구간 ③ 자료수집 | 변수 값·근거 |
| 협업 안 해도 이긴다 | 구간 ② 설계 | 점수 구조·정보 배분 |
| 3라운드로는 시간이 모자란다 | 구간 ② 설계 | 라운드 구성·시간 배분 |
| 참가자가 무엇을 하는 건지 모른다 | 구간 ④ 교안 | 규칙 설명 슬라이드 |
이 표를 만드는 것 자체가 루프 관리입니다. 문제가 나올 때마다 «이건 어느 구간의 문제인가»를 먼저 묻는 습관이 없으면, 도구만 계속 고치다가 영원히 안 끝납니다. 원인이 앞에 있는데 뒤를 고치고 있으니까요.
제가 만든 교육용 도구를 테스트했더니 문제가 여러 개 나왔습니다. 어디를 고쳐야 하는지 분류해 주세요. [이 도구의 목적] (예: 팀 간 협업을 체험하게 하는 3라운드 시뮬레이션) [설계 원칙] (앞 단계에서 정한 원칙을 붙여넣기) [발견한 문제들] 1. 2. 3. 각 문제를 아래 세 가지로 분류해 주세요. A. 고장 — 도구가 설계대로 작동하지 않음 B. 불편 — 작동은 하는데 쓰기 어려움 C. 설계 오류 — 잘 작동하는데 «목적이 달성되지 않음» 그리고 각각에 대해 - 어느 단계로 돌아가야 하는지 (도구 제자리 / 자료·수치 / 설계 원칙 / 교안) - 고치는 데 드는 노력 (작음·보통·큼) - 안 고치고 진행했을 때 생기는 일 을 표로 정리해 주세요. C로 분류된 것이 있으면 «이것부터»라고 표시해 주세요. C는 뒤로 미루면 전부 다시 하게 됩니다.
내가 만든 것을 내가 테스트하면, ③번이 안 보입니다
혼자 돌려 보면 고장과 불편은 찾습니다. 그런데 설계 오류는 거의 못 찾습니다. 이유는 간단합니다 — 나는 의도대로 움직이기 때문입니다.
내가 「협업하라」고 설계했으니 나는 협업하면서 테스트합니다. 협업 안 하는 길이 있는지 찾아볼 생각을 안 합니다. 참가자는 다릅니다. 참가자는 이기려고 합니다. 설계자가 생각 못 한 길을 기어코 찾아냅니다.
실제 참가자를 미리 부를 수는 없습니다. 이 사례에서는 사내 교육팀과 지인 강사들로 한 판을 돌렸습니다. 인원이 안 맞으면 한 사람이 두 팀 역할을 해도 됩니다. 중요한 건 «설계자가 아닌 사람이 이기려고 해 보는 것»입니다.
그리고 이렇게 부탁하십시오 — 「규칙의 허점을 찾아 주세요. 정당하게 이기지 말고, 편법으로 이겨 보세요.」 이 한마디가 3단계의 전부입니다.
제가 설계한 교육용 시뮬레이션의 «허점»을 찾아 주세요. 참가자 입장에서, 제 의도를 무시하고 «어떻게든 이기는 방법»을 찾아 주십시오. [학습목표] (예: 팀 간 협업 없이는 좋은 성과가 안 나온다는 것을 체험) [규칙과 점수 구조] (구간 ②·③에서 만든 것을 붙여넣기) 아래를 해 주세요. 1. 이 규칙에서 «학습목표를 달성하지 않고도 이기는 경로»가 있는지 찾아 주세요. 있다면 구체적으로 어떻게 하는 것인지 2. 참가자가 «규칙을 잘못 이해할 수 있는 지점» 3. 한 팀이 초반에 크게 앞서면 나머지가 포기해 버릴 위험이 있는지, 있다면 어느 지점인지 4. 시간이 부족해질 가능성이 큰 구간 찾은 허점마다 «어떻게 막을 수 있는지»를 두 가지씩 제안해 주세요. 단, 규칙을 복잡하게 만드는 방법은 빼 주세요. 참가자가 이해 못 하면 의미가 없습니다.
[발견된 경로] 한 팀이 초반에 설비 투자를 몰아서 하면 다른 팀의 정보 없이도 2라운드까지 앞설 수 있습니다. → 그 팀은 «협업할 이유»를 못 느끼게 됩니다. [막는 방법 두 가지] 1. 2라운드에 «단독으로는 해결 못 하는 변수»를 넣는다 (예: 다른 팀이 가진 정보가 있어야 판단 가능한 선택지) 2. 점수를 팀 합산이 아니라 «전체 목표 달성 여부»와 연동한다 — 한 팀만 잘해서는 전체가 목표에 못 미치게 [규칙을 복잡하게 만들지 않는 쪽] 2번을 권합니다. 규칙이 하나 늘지 않고, 점수 계산식만 바뀝니다.
이 프롬프트는 도구를 만들기 «전»에 써도 됩니다. 오히려 그게 낫습니다. 규칙 단계에서 허점을 잡으면 도구를 다시 만들 일이 없으니까요. 루프를 앞으로 당기는 것 — 이게 시간을 가장 많이 아끼는 방법입니다.
몇 바퀴 돌 것인가 — 미리 정해 두십시오
루프의 가장 큰 위험은 «조금만 더 고치면 나아질 것 같은» 느낌입니다. 실제로 조금씩 나아집니다. 그래서 멈추기가 어렵습니다. 그러다 교육 날짜가 다가옵니다.
| 정해 둘 것 | 이 사례에서는 |
|---|---|
| 몇 바퀴 | 세 바퀴. 1차 혼자 / 2차 동료 / 3차 리허설. 각 바퀴에서 나온 것만 고칩니다 |
| 바퀴마다 며칠 | 고치는 데 이틀을 넘기지 않기. 넘어가면 그건 «고치기»가 아니라 «다시 만들기»입니다 |
| 언제까지 | 교육 일주일 전에는 손을 뗍니다. 남은 일주일은 교안·리허설·인쇄입니다 |
| 넘어가면 | 기능을 줄입니다. 일정을 늘리지 않습니다 |
루프가 안 끝날 때 대부분은 일정을 미룹니다. 그런데 교육 날짜는 못 미룹니다. 그러면 줄여야 하는 건 «기능»입니다.
이 사례에서도 처음 설계에 있던 기능 몇 개를 덜어 냈습니다. 예쁜 그래프, 실시간 순위표 같은 것들이었습니다. 학습에 꼭 필요한 것이 아니었기 때문입니다. 그 판단 기준이 있어야 덜어 낼 수 있습니다.
언제 멈춰도 되는가 — 종료 조건
「완벽해지면 멈춘다」는 조건이 될 수 없습니다. 완벽해지지 않으니까요. 이렇게 정하십시오.
| 이것이 되면 멈춥니다 | |
|---|---|
| 1 | 처음 쓰는 사람이 설명 없이 한 라운드를 끝낼 수 있다 |
| 2 | 학습목표를 비껴가는 «이기는 길»이 없다 — 허점 찾기에서 새로 안 나온다 |
| 3 | 정해진 시간 안에 전 라운드가 끝난다 (여유 10분 포함) |
| 4 | 중간에 멈춰도 강사가 수동으로 이어 갈 수 있다 |
| 5 | 남은 문제가 «있으면 좋은 것»뿐이다 — «없으면 안 되는 것»이 아니다 |
4번을 꼭 넣으십시오. 도구는 현장에서 멈춥니다. 와이파이가 끊기고, 노트북이 꺼집니다. «도구 없이도 진행 가능한 경로»가 진행안에 있어야 합니다. 이걸 준비해 두면 도구를 덜 완벽하게 만들어도 됩니다 — 역설적으로 루프가 빨리 끝납니다.
교육용 도구를 만들고 있는데 «언제 멈춰야 할지» 판단하려 합니다. [도구의 목적] [교육 예정일] [지금까지 테스트한 횟수와 내용] [현재 남아 있는 문제 목록] 1. 2. 3. 아래를 해 주세요. 1. 남은 문제를 «없으면 안 되는 것»과 «있으면 좋은 것»으로 나눠 주세요. 판단 기준도 함께 밝혀 주세요 2. «없으면 안 되는 것»만 고치는 데 얼마나 걸릴지 가늠해 주세요 3. 교육 일주일 전까지 끝나지 않는다면 «무엇을 덜어 낼 수 있는지» 제안해 주세요 — 학습목표에 영향이 적은 것부터 4. 도구가 현장에서 멈췄을 때 강사가 수동으로 진행할 수 있는 «대체 경로»를 만들어 주세요 3번과 4번을 특히 신경 써 주세요. 일정을 늘리는 방법은 제안하지 마십시오. 날짜는 고정입니다.
루프를 돌면서 «기록»을 남기면, 그게 다음 과정의 설계도가 됩니다
루프는 지칩니다. 그래서 대부분 기록을 안 남깁니다. 고치고, 또 고치고, 끝나면 잊습니다. 그런데 여기서 나온 기록이 가장 값어치 있는 자산입니다.
왜냐하면 이 기록은 «설계할 때는 몰랐던 것»의 목록이기 때문입니다. 다음에 비슷한 걸 만들 때 같은 실수를 안 하게 해 줍니다.
위 기록을 한 번만 정리하면 이런 목록이 됩니다. 다음에 도구를 만들 때 처음부터 확인할 것들입니다.
· 결과 화면에 «무엇을 보라»는 안내가 있는가
· 규칙 설명 없이 시작할 수 있는가, 없다면 교안에 반영했는가
· 입력 확인 단계가 있는가
· 학습목표를 비껴가는 경로가 없는가
· 시간이 초과될 여지가 있는가
· 도구 없이 진행할 대체 경로가 있는가
도구를 만들고 테스트하는 과정에서 나온 문제들을 «다음에 쓸 체크리스트»로 정리해 주세요. [이번에 만든 것] [테스트하며 발견한 문제들 — 순서 없이 적어도 됩니다] 아래를 해 주세요. 1. 문제들을 «다음에도 또 생길 만한 것»과 «이번에만 해당하는 것»으로 나눠 주세요 2. «또 생길 만한 것»을 체크리스트 문장으로 바꿔 주세요 — 「~했는가?」 형태의 질문으로 — 만들기 «전»에 확인할 것과 «후»에 확인할 것을 나눠서 3. 이번에 «되돌아가야 했던» 지점이 있었다면, 그것을 앞 단계에서 미리 막으려면 무엇을 확인했어야 하는지 알려 주세요 3번이 가장 중요합니다. 되돌아가는 일을 줄이는 것이 시간을 가장 많이 아낍니다.
오늘의 요약
| 기억하실 것 | |
|---|---|
| 루프란 | 끝이 안에 들어 있지 않은 구간. 밖에서 정해 주지 않으면 무한히 돕니다 |
| 문제는 세 종류 | 고장 · 불편 · 설계 오류. 앞의 둘은 도구를 고치고, 셋째는 앞 구간으로 돌아갑니다 |
| 혼자 테스트의 한계 | 나는 의도대로 움직이므로 설계 오류를 못 찾습니다. 「편법으로 이겨 보세요」라고 부탁하십시오 |
| 멈추는 법 | «완벽해지면»이 아니라 종료 조건 5개. 일정이 아니라 기능을 줄입니다 |
| 남는 것 | 도구보다 «다음에 쓸 체크리스트»가 더 값어치 있습니다 |
루프를 줄이는 가장 좋은 방법은 «루프를 앞으로 당기는 것»입니다.
만들고 나서 허점을 찾지 마시고, 규칙 단계에서 찾으십시오. 종이 위에서 고치는 건 하루면 되지만, 만들어 놓고 고치면 일주일이 갑니다.
다음 편 예고 — 심화 03
도구가 완성됐고 교안도 나왔습니다. 이제 실제로 여러 차수를 운영합니다. 차수마다 나오는 피드백을 어떻게 모으고, 무엇을 고치고, 어떻게 «다음 과정의 재료»로 되돌려 놓는가 — 바퀴가 한 바퀴 도는 마지막 구간, 운영과 자산화가 «심화 03»의 주제입니다.
이어서 보시면 좋은 자료
«심화 01» — AI 워크플로우 ① 요구분석에서 교안까지 · 이 편의 앞 이야기
«연결 01» — AI는 어떻게 내 도구를 쓰는가 · 도구를 붙이는 구조
«응용 07» — AI 에이전트 · 만드는 일을 통째로 맡기기
«기본 05» — AI가 쓴 티 안 나게 쓰는 법 · 검증하는 습관