AI Scenario Studio · 김건호

한 줄

어려운 대화를 앞둔 관리자가 먼저 자기 예측을 잠그고, 놓친 이해관계자와 숨은 가정을 확인한 뒤, 처음의 확신이 얼마나 바뀌었는지를 돌려받는 리허설 도구입니다.

문제

22년간 인사 직위에서 본 것은, 어려운 면담이 대개 준비 부족이 아니라 검토하지 않은 조건 때문에 틀어진다는 것이었습니다. 당사자만 보고 그 뒤의 이해관계자를 못 보거나, 확인한 적 없는 전제를 사실로 놓고 대화에 들어갑니다.

기존의 AI 상담 도구는 "이렇게 말하세요"를 줍니다. 그건 준비를 대신해 주는 것이지 준비시키는 게 아닙니다. 방향을 반대로 잡았습니다.

어떻게 동작하나

예측 잠금 — 사용자가 상황을 서술하고, 결과 예측과 확신도(0~100)를 먼저 입력합니다. 이해관계자 목록을 보여주기 전에 잠급니다
이해관계자 분석 — 놓치기 쉬운 이해관계자를 찾아 제시합니다
가정 도전 — 확인된 적 없는 전제를 드러냅니다
대안 시나리오 — 사전 정의된 시나리오(현재 3종: 저성과자 면담, 고성과자 시기, 동료 갈등 책임 전가)이거나 모델이 생성하며, 생성 결과는 가드레일이 검수합니다
성찰 보고서 — 발견한 이해관계자 수와, 최초 확신과 성찰 후 확신의 차이를 돌려줍니다. 판정하지 않습니다

진행 전체는 사용한 모델·토큰·지연시간·가드레일 발견까지 실행 기록으로 남깁니다.

설계 판단

첫 대상을 신임 관리자로 정한 이유. 후보는 HR 실무자, 상담 영역, 신임 관리자 셋이었습니다. 상담은 정신건강 위기 대응 설계가 먼저 필요하고, 채용·평가는 AI 윤리·차별 이슈가 걸려 둘 다 가드레일이 무거워집니다. 신임 관리자는 22년 인사 경력과 조직심리 박사과정이 그대로 근거가 되고, 정리해 둔 논문 비평 177편 중 리더십·조직행동 계열을 시나리오의 이론 근거로 바로 쓸 수 있습니다.

예측을 먼저 잠그는 이유. 목록을 보고 나서 "나도 그렇게 생각했다"고 말하는 것은 측정이 불가능합니다. 확신도를 미리 기록해야 변화량이라는 숫자가 생깁니다. 이 도구가 사용자에게 주는 유일한 결과가 그 차이입니다.

정답을 주지 않기로 한 이유. LLM이 대화 스크립트를 주면 사용자는 그걸 외웁니다. 실제 상황은 스크립트대로 가지 않고, 그때 준비는 무너집니다. 대신 "당신이 안 본 게 여기 있다"만 보여주면 대응은 사용자가 만듭니다.

가드레일을 모델 바깥에 뒀습니다. 단정적 예측을 막는 방법은 프롬프트로 지시하는 것과 생성 결과를 코드로 검사하는 것 두 가지인데, 둘 다 하되 후자를 최종 방어선으로 삼았습니다. 검수 함수는 어떤 모델이 답했는지 모르는 순수 함수라 모델을 갈아 끼워도 통제가 그대로 남습니다. 여러 모델을 쓰는 시스템에서 신뢰성은 모델 선택이 아니라 모델 바깥 계층에서 나온다는 것이 이 프로젝트의 주장입니다. 오탐을 줄이려고 규칙을 느슨하게 하지 않았습니다. 단정을 놓치는 비용이 한 번 더 고쳐 쓰는 비용보다 큽니다.

시나리오는 코드가 아니라 데이터입니다. HR·교육 담당자가 YAML을 직접 고칠 수 있게 했습니다. 대신 로더가 구조를 강하게 검사합니다. 대안이 2개 미만이면 시나리오가 아니므로 거부하고, 면책 문구가 비면 거부하며, 한 글자짜리 별칭도 거부합니다.

측정 지표에 붙은 버그를 우선 잡았습니다. 초기 버전에서 이해관계자 매칭이 역할명의 마지막 단어를 입력 전체에서 부분 문자열로 찾다가, '6개월 뒤의 나'의 키가 '나' 한 글자가 되어 "하나도 모르겠다"만 적어도 그 이해관계자를 언급한 것으로 기록했습니다. 발견 수가 이 도구의 핵심 지표라, 이 버그는 결과 전체의 신뢰를 무너뜨리는 사안이었습니다. 줄 단위 비교와 시나리오에 명시한 별칭 방식으로 바꿨습니다. 같은 날 가드레일 테스트에서 다른 규칙에 가려 죽어 있던 규칙 하나도 찾았습니다. 다른 규칙이 잡아 주면 죽은 규칙은 보이지 않습니다.

회귀 테스트를 먼저 갖췄습니다. 전체 흐름, 이해관계자 매칭 21건, 가드레일의 정탐과 오탐(표본 8건, 오탐 0)을 검사하는 테스트 3종을 통과시켰습니다. API 키 없이도 전체 흐름이 도는 모드를 기본값으로 둬서 로직 검증과 모델 호출을 분리했습니다. 처음 저장소를 받은 사람이 흐름을 끝까지 본 뒤에 API를 붙일지 정할 수 있어야 합니다.

결과와 한계

아직 실사용자 세션 전입니다. 텍스트 프로토타입이 돌고 테스트는 통과했지만, 실제 관리자가 써 본 피드백은 없습니다. 이 도구의 가정("검토하지 않은 조건을 드러내면 준비가 나아진다")은 아직 검증되지 않았고, 다음 단계는 기능 추가가 아니라 첫 사용자 세션입니다. 첫 세션 전에 테스트 3종이 모두 통과해야 한다는 조건을 절차로 못박았습니다. 측정이 깨진 상태로 받은 피드백은 데이터가 아니기 때문입니다.

화면과 시연

영상 — 예측 잠금부터 성찰 보고서까지 한 세션 전체 (데모 시나리오로)
스크린샷 — 확신도 입력 화면
스크린샷 — 성찰 보고서 출력 (확신 변화량이 보이게)
스크린샷 — 회귀 테스트 3종 통과 결과