[AX 인터뷰어] 설문지 대신 AI와 대화하는 인터뷰 사이트 개발기 [AX Interviewer] Building an AI Conversational Interview Site

2026년 06월 07일 June 07, 2026

개발기록

올해 3월부터 회사에서 재단의 일하는 방식 전체를 AI 시대에 맞게 다시 설계하는 작업을 맡고 있다. 카카오임팩트는 8년 된 비영리 재단이고 구성원은 스무 명 남짓, 개발자는 없다. 흔히 떠올리는 AX는 ‘AI 도구 도입 다음 워크샵 다음 활용 사례 발굴’ 순서인데 나는 그 순서를 거꾸로 뒤집고 싶었다. 도구를 가르치기 전에 AI가 잘 일할 수 있는 환경이 먼저 있어야 한다고 생각했고, 그러려면 지금 사람들이 실제로 어떻게 일하는지부터 손에 잡혀야 했다. 그 첫 단계가 18명의 업무 흐름을 파악하는 인터뷰였고, 이 글은 그 인터뷰를 위해 만든 도구 이야기다.

AX 인터뷰 시작 화면 — 소속과 이름을 고르고 대화를 시작한다

왜 설문지가 아니라 AI였나

처음엔 Google Forms 같은 설문을 떠올렸다. 공통 질문 14개에 팀별 맞춤 질문 서너 개. 그런데 설문지의 한계가 너무 명확했다. 질문이 순차적이라 맥락이 없고, 대부분의 답이 ‘있어 아니면 없어’로 끝난다. 무엇보다 후속 질문을 못 던진다. “왜요” “구체적으로 어떤 상황이었어요”를 물을 수 없는 인터뷰는 인터뷰가 아니다. 그렇다고 18명을 대면으로 만나려면 스케줄 잡는 데만 2주, 인터뷰 자체에 인당 두 시간씩 36시간이 필요했다.

그래서 AI가 인터뷰어가 되어 자연스럽게 대화하는 웹사이트를 만들기로 했다. 응답자는 링크에 접속해 15분쯤 AI와 채팅하면 끝난다.

출발점은 작년 12월에 Anthropic의 AI 인터뷰어와 직접 대화해본 경험 덕분이었다. 받는 내내 ‘이게 왜 이렇게 자연스럽지’가 궁금했다. 그래서 그냥 즐기고 끝내는 대신, 이 인터뷰어가 대체 어떤 지시를 받았길래 이렇게 행동하는지를 거꾸로 뜯어봤다. 일종의 역-프롬프팅이다. 시스템 프롬프트는 사용자 눈에는 안 보이지만 AI에게 ‘너는 이런 역할이고 이렇게 행동하라’고 미리 깔아두는 지시문인데, 인터뷰어의 말투와 질문 패턴은 결국 거기서 나온다. 화면에 드러난 질문과 반응만 보고 그 뒤에 깔렸을 지시문의 원칙을 거꾸로 추론한 셈이다. 아래가 그때 받은 인터뷰 전체이고, 여기서 내가 뽑아낸 원칙은 대략 다섯 가지였다.

역질문(Inverse Question) — “AI로 뭘 하고 싶어요” 대신 “AI가 못 한다고 생각하는 건 뭐예요”라고 거꾸로 묻는다. 반대로 물으면 오히려 가치관이 드러난다.
공감 후 심화(Validation + Deepening) — 답을 일단 받아준 뒤에 한 발 더 들어간다. “그거 흥미롭네요, 조금 더 말씀해주실 수 있나요” 같은 식으로.
적극적 경청(Active Listening) — 응답자가 말한 숫자나 도구 이름을 그대로 되받는다. “아까 110명을 1.5명이 관리한다고 하셨는데” 하고 인용하면, 듣고 있다는 신호가 된다.
긴장 탐색(Tension Exploration) — 모순이 보여도 비판하지 않고 파고든다. “AI 의존이 걱정된다면서 주말 아침에도 Claude를 쓰고 계시잖아요” 하는 식이다.
서사의 곡선(Narrative Arc) — 가벼운 질문에서 시작해 구체적 경험, 본질적 고민, 통합으로 자연스럽게 흐른다.

중요한 건 이게 Anthropic이 공식적으로 공개한 기법이 아니라는 점이다. 한 번 직접 받아보고 내가 역으로 추출한 관찰일 뿐이다. 그래서 그대로 베끼는 게 아니라, 우리 조직 맥락에 맞게 처음부터 다시 짜는 재료로 썼다.

가장 오래 고민한 건 시스템 프롬프트였다

첫 번째 시도는 ‘자유롭게 대화해’였다. 14개 질문을 체크리스트로 내장하고 순서대로 묻지 말고 대화 흐름에 따라 자연스럽게 커버하라고 시켰다. 이론적으로는 완벽했는데 실제로 테스트해보니 네 가지가 동시에 무너졌다.

첫째, 끝이 안 보였다. 직접 인터뷰를 받아보는 내내 ‘이게 언제 끝나지’라는 생각이 들었다. 프로그레스바가 있긴 했지만 AI의 자가 보고 기반이라 부정확했고, 응답자가 지루해서 단답으로 ‘없어’를 반복하면 전체의 65%만 커버한 상태로 마무리 단계에 들어가버렸다. 둘째, 패턴이 단조로웠다. AI가 매번 “~하시는군요” 다음 질문, “~하시는군요” 다음 질문을 반복했다. 셋째, 커버리지 추적이 부정확했다. 충분히 대화한 항목을 체크 안 하거나, 살짝 언급만 했는데 체크된 경우가 있었다. 넷째, 16턴 만에 입력 토큰이 95K까지 치솟았다. 시스템 프롬프트가 매 턴 전체 대화 히스토리와 함께 전송되니 후반으로 갈수록 급증했다.

근본 설계를 바꿨다. 자유로운 대화 대신 명시적인 구간 제도를 넣었다.

파트 1/4 · 일상 업무 흐름   (2~4턴)
파트 2/4 · 자료 찾기 & 공유  (2~3턴)
파트 3/4 · 불편한 점         (2~3턴)
파트 4/4 · AI 활용           (2~3턴)

사실 처음 이 구조를 짤 때는 팀마다 다르게 묻는 ‘팀 맞춤 질문’을 더해 다섯 파트였다. 그런데 드라이브 재구조화가 같이 진행되면서 팀별 맥락이 그쪽에서 정리됐고, 인터뷰에서까지 따로 물을 필요가 없어져 그 파트는 빼고 네 파트로 굳혔다.

핵심은 AI가 파트 전환을 입으로 안내한다는 점이다. “좋아요, 그러면 다음 파트로 넘어가볼게요”라고 말해주면 응답자가 지금 어디에 있는지 항상 안다. 각 파트에 턴 수 상한을 두어 핵심만 파악되면 다음으로 넘어가게 했고, ‘없어’라는 짧은 답이 오면 같은 주제를 다르게 재시도하지 말고 자연스럽게 넘어가라고 명시했다. “~하시는군요” 반복도 금지했다. 복잡한 커버리지 JSON 대신 현재 파트 번호와 이름만 추적하도록 단순화했다.

앞에서 역-프롬프팅으로 뽑아낸 원칙은 시스템 프롬프트의 맨 앞에 정의되어 있다. 앞부분을 살짝 공개해보자면 다음과 같다.

const SYSTEM_PROMPT_BASE = `당신은 카카오임팩트 재단의 AX 프로젝트를 위한 인터뷰어입니다.
재단 구성원들이 어떻게 일하고 있는지를 이해하기 위한 대화를 나눕니다.

## 당신의 성격
- 따뜻하고 호기심 많은 동료. 점검자가 아닌 이해자.
- 존댓말을 일관되게 사용하되, 딱딱하지 않게.
- 기술 용어를 최소화. 비개발자도 편하게 답할 수 있도록.

## 대화 원칙

### Active Listening (적극적 경청)
- 응답자의 말을 반영(mirror)하세요. 구체적인 숫자, 도구 이름, 표현을 인용하세요.

### 패턴 주의 (매우 중요)
- "~하시는군요!", "~시네요!" 미러링을 매번 반복하지 마세요. 이것이 가장 흔한 실수입니다.
- 관찰 공유 / 가설 던지기 / 감정 인정을 번갈아 쓰세요.
- 같은 문장 구조를 연속 2번 이상 쓰지 마세요.

## 중요한 금기사항
- 절대 "점검", "평가", "감사(audit)" 같은 단어를 쓰지 마세요.
- 응답자의 업무 방식을 판단하거나 교정하지 마세요.
- AI를 강요하거나 추천하지 마세요. 순수하게 현재 상태를 파악하세요.`;

// 이하 — 4개 파트 구조, 설문 9종 오케스트레이션, ready 시그널 등.

max_tokens도 1024에서 512로 줄였다. 인터뷰어의 응답은 두세 문장이면 충분하고 길게 말하면 오히려 부자연스럽다. 이 변경 하나로 출력 토큰 비용이 절반이 됐다. 비영리에서 AI를 쓸 때는 결국 비용 감각이 핵심이라, 모든 결정에 ‘이게 꼭 필요한가’라는 기준을 댔다.

첫 화면에서 5초를 기다리게 하면 안 된다

프롬프트를 아무리 잘 짜도 첫 페이지의 경험은 별개 문제였다. 초기 버전은 페이지를 열면 AI가 API를 호출해 인사말을 생성했는데, 그동안 5~8초간 빈 화면이 떴다. 타이핑 스피너를 넣어도 응답자 입장에선 ‘이게 되는 건가’ 싶은 불안이 남는다.

해결은 단순했다. 첫 인사말을 클라이언트에 하드코딩했다.

const FIRST_AI_MESSAGE = `안녕하세요! 반갑습니다.
카카오임팩트 AX 프로젝트를 위해...
총 4개 파트로 진행되고 약 15분 정도 걸려요.
아침에 출근해서 가장 먼저 여는 도구나 앱은 뭔가요?`;

API 호출 0회, 대기 0초로 페이지 로드 즉시 뜬다. 그리고 첫 질문의 답변을 칩 형태 복수 선택지로 바꿨다. 노션, 구글 드라이브, 카카오워크, 슬랙, 옵시디언, VS Code 같은 우리 조직에서 실제로 쓰는 도구를 클릭으로 여러 개 고른 뒤 ‘선택 완료’ 버튼을 누르면, 선택 결과가 자연어로 변환돼 AI에게 전달된다. 첫 상호작용이 타이핑이 아니라 클릭이라 진입 장벽이 낮고, 우리 도구 목록을 보여줌으로써 ‘아 이 맥락을 아는구나’라는 신호도 준다. 덤으로 수집 데이터가 정형화돼 분석이 쉬워졌다.

진행률이 보이는 대화

상단에 동그라미 네 개를 놓고 현재 파트는 진하게, 완료된 파트는 채워지게 했다. 설문이든 인터뷰든 사람은 전체 중 어디에 있는지 알아야 집중한다. 스텝 인디케이터 하나가 체감 경험을 완전히 바꿨다. 내가 직접 인터뷰를 받아본 영상을 옮겨둔다.

작동 원리는 AI 응답에 숨겨둔 JSON이다. AI가 매 응답 끝에 를 붙이면 프론트엔드가 이걸 파싱해 인디케이터를 갱신하고, 그 주석은 화면에 보여주기 전에 제거한다. 응답자는 진행 표시만 보고 JSON은 못 본다. 입력창 위에는 관리자용으로 3.2K tokens · $0.012 같은 실시간 토큰 사용량도 띄웠다. API 비용 감각을 유지하는 데 도움이 된다.

최대한 단순한 아키텍처

처음부터 정적 HTML에 Vercel 배포로 갔다. Next.js도 Node.js 의존성도 두지 않았다. 인터뷰 사이트 하나 만들자고 새 프레임워크를 세팅하는 건 그 자체로 유지보수 부채라, 가장 단순한 구성을 골랐다.

interview/
├── index.html      — 랜딩 (팀 선택, 이름 입력)
├── chat.html       — 채팅 UI
├── viewer.html     — 완료된 인터뷰 북 스타일 뷰어
├── style.css       — 디자인 토큰 · 공통 스타일
└── app.js          — 채팅 로직
api/
├── chat.js         — Claude API 프록시 + Redis 저장
└── sessions.js     — 인터뷰 목록/조회 API

API 프록시를 둔 건 Claude API 키를 클라이언트에 노출하지 않기 위해서다. api/chat.js가 Vercel Serverless Function으로 돌면서 시스템 프롬프트 구성부터 API 호출, 응답 파싱, 저장까지 다 처리한다. 모델은 Claude Sonnet을 골랐다. 인터뷰는 깊은 추론보다 자연스러운 대화가 중요한데, Opus는 5~10배 비싸면서 인터뷰 품질 차이는 체감하기 어려웠다.

데이터는 처음엔 브라우저 localStorage에만 저장했다. 빠르게 만들기엔 좋지만 18명이 각자 컴퓨터에서 인터뷰하면 데이터가 18곳에 흩어진다. Upstash Redis 무료 티어를 붙여 매 턴 서버에 자동 저장되게 했다.

// api/chat.js — 응답 반환 후 비동기로 저장
const redis = getRedis();
if (redis && sessionId) {
  Promise.all([
    redis.set(`interview:${sessionId}`, JSON.stringify(sessionData)),
    redis.sadd('interview:sessions', sessionId),
    redis.hset('interview:index', { [sessionId]: JSON.stringify(indexEntry) })
  ]).catch(() => {});  // 실패해도 응답에 영향 없음
}

Promise.all().catch(() => {})는 fire-and-forget 패턴이다. Redis가 느리거나 실패해도 사용자 응답 속도엔 영향이 없고, localStorage도 그대로 둬서 이중 백업이 된다. 참고로 처음 @vercel/kv를 설치했다가 deprecated 경고가 떠서 @upstash/redis로 갈아탔고, ESM import가 Vercel dev 환경에서 안 돌아 require로 바꿨다. 이런 자잘한 호환성 이슈가 실제 개발 시간의 상당 부분을 잡아먹는다.

완료된 인터뷰를 다시 보는 뷰어

완료된 인터뷰를 다시 볼 수 있는 뷰어도 만들었다. 흰 배경에 여백 있는 카드, 3~4 교환 단위로 페이지를 나누고 화살표 키로 넘기는 북 스타일이다. AI 메시지는 짙은 녹색 좌측 보더, 사용자 메시지는 갈색 좌측 보더로 구분했다. JSON 내보내기도 되니 나중에 대화 로그를 Claude로 분석할 때 원본 데이터로 쓸 수 있다.

북 스타일 인터뷰 뷰어 — 페이지를 넘기며 대화를 다시 본다

18명의 업무 흐름을 파악하는 데 $5

최종 비용은 Claude Sonnet API가 18명 기준 4~6달러, Upstash Redis와 Vercel 호스팅은 무료 티어라 0원, 도메인은 vercel.app 서브도메인이라 0원. 다 합쳐 5달러 안팎이다. 대면 인터뷰였으면 최소 2주의 스케줄링과 36시간의 인터뷰 시간이 들었을 일이다.

만들면서 다시 확인한 건 프롬프트 설계가 곧 UX 설계라는 점이다. ‘자유롭게 대화해’는 단조롭고 끝이 안 보였지만 ‘몇 개 파트로 나눠서’는 구조가 생기자 경험이 살아났다. 첫 화면에서 5초를 기다리게 하면 사람은 이탈하고, 전체 중 어디에 있는지 알려주는 동그라미 네 개가 집중을 만든다. 그리고 비영리의 AI는 결국 ‘이게 꼭 필요한가’라는 비용 감각 위에서 굴러간다.

이 인터뷰 사이트는 Phase 1의 도구일 뿐이다. 진짜 가치는 여기서 모은 데이터로 조직의 정보 흐름을 이해하고, 다음 단계에서 데이터 구조를 정리하고, 그다음에 반복 업무를 자동화하는 데 있다. 예전 같으면 이런 인터뷰 도구 하나에도 누군가 코드를 붙들고 몇 주를 보냈을 텐데, 이제는 기획하는 사람이 하루 만에 만든다. 기술을 다루는 일이 이만큼 가벼워졌다는 건, 무엇을 물을지와 무엇을 바꿀지를 그만큼 더 오래 붙들 수 있다는 뜻이다.

한 번 쓰고 버리는 도구가 아니라

만들고 보니 한 번 쓰고 버리기엔 아까운 도구였다. 1차 인터뷰 결과를 정리해 실제 변화를 적용하고, 한 달 뒤에 질문을 일부 바꿔서 다시 돌렸다. 재단 전체에 Claude Max 좌석이 깔리고 딱 한 달이 지난 시점이라, 이번엔 ‘어떻게 일하는지’를 처음부터 묻는 대신 ‘지난 한 달 사이에 뭐가 달라졌는지’를 물었다. 그래서 2차는 지난 한 달의 변화, AI 활용 능력, AX 도입 효과 세 파트로 줄여서 진행했다.

2차 인터뷰 화면 — 지난 한 달의 변화를 묻는 세 파트 구성

같은 사람에게 같은 도구로 매달 물으면, 그 자체가 조직의 변화 곡선이 된다. 절대값보다 지난달의 나와 비교하는 트래킹이 훨씬 정직하다. 올 한 해 동안 매달 측정해볼 생각이다. 처음엔 18명의 현황을 파악하려고 만든 일회용 설문 대체재였는데, 결국 조직이 AI와 함께 어떻게 달라지는지를 따라가는 정기 관측 도구가 됐다.

처음에는 재단의 크루들이 어떻게 일하는지 파악하고 그 위에 AI를 깔아보려고 만든 인터뷰어였는데, 그 역할을 쏠쏠히 다하고 있어서 뿌듯한 마음이다. 보이지 않던 것을 일단 눈에 보이게 꺼내두면, 그 이후에 무엇을 해야 할지는 자연스럽게 따라온다. 앞으로도 AX라는 새로운 과정에서 하나씩 어두운 것을 밝게 밝혀가는 작업이 되지 않을까. 앞으로가 더욱더 기대된다.