2025년, 우리는 왜 AI와 '스무고개' 게임을 하고 있는가

안녕하세요. 풀링포레스트에서 CEO 겸 PM을 맡고 있는 김형철입니다.

2025년의 끝자락에서 한 해를 돌아보며, 문득 고전 게임 하나가 떠올랐습니다. 바로 '조크(Zork)' 같은 텍스트 어드벤처 게임입니다. 화려한 그래픽 없이 오직 텍스트로만 상황이 묘사되고, 플레이어는 명령어를 입력해 게임을 진행해야 했죠. "고블린을 때려(Hit Goblin)"라고 입력하면 "고블린이 피했습니다"라고 뜨고, "칼로 찔러(Stab Goblin)"라고 입력해야 비로소 공격이 성공하는 식입니다. 플레이어는 게임이 이해하는 '정답 단어'를 찾기 위해 끊임없이 추측하고 실패해야 했습니다.

솔직히 말해, 지난 1년간 우리가 AI 챗봇을 다루던 방식이 이 고전 게임과 소름 끼치도록 닮아있다는 생각을 지울 수 없습니다. 우리는 이것을 '프롬프트 엔지니어링'이라고 불렀지만, 실상은 AI가 알아듣는 말을 찾기 위한 지루한 '스무고개'였을지도 모릅니다. 오늘은 최근 화제가 된 'PromptQuest(프롬프트 퀘스트)'라는 개념을 빌려, AI 도입 과정에서 우리가 겪는 혼란과 이를 대하는 PM의 자세에 대해 이야기해보려 합니다.

생산성 도구인가, 눈치 게임인가

최근 팀 내부에서 업무 효율화를 위해 Copilot을 적극적으로 도입하려 시도했던 적이 있습니다. 목표는 단순했습니다. "웹상의 특정 데이터를 수집해 다운로드 가능한 스프레드시트로 정리해달라"는 것이었죠. 하지만 결과는 당혹스러웠습니다.

첫 시도에서 AI는 스프레드시트 대신, 스프레드시트를 만들 수 있다고 주장하는 Python 스크립트 코드를 뱉어냈습니다. 며칠 뒤 동일한 프롬프트를 입력했을 때는 또 다른 형식의 결과물을 내놓았습니다. 심지어 마이크로소프트(MS)가 예고 없이 모델을 업데이트하거나 백엔드 로직을 변경할 때마다, 어제까지 잘 작동하던 프롬프트가 오늘은 엉뚱한 대답을 내놓는 현상을 목격했습니다.

마치 어드벤처 게임에서 "문을 열어(Open Door)"가 어제는 통했다가 오늘은 "문이 잠겨 있습니다"로 바뀌는 것과 같았습니다. 우리는 업무를 자동화하려다 되려 AI의 비위를 맞추고 정답 문법을 찾아내는 데 더 많은 시간을 쏟게 되었습니다.

이 과정에서 뼈저리게 느낀 점은, 현재의 AI 챗봇 경험이 '불확실성(Stochasticity)'을 내포하고 있다는 것입니다. 우리는 소프트웨어가 항상 입력값(Input)에 대해 동일한 출력값(Output)을 낼 것이라 기대하지만, LLM(거대언어모델)은 확률에 기반하여 답을 생성합니다. 이것이 창의적인 글쓰기에는 도움이 될지 몰라도, 정해진 규격의 업무를 처리해야 하는 비즈니스 현장에서는 심각한 '비용'으로 작용합니다.

보이지 않는 업데이트의 공포

더 큰 문제는 플랫폼의 투명성 부재입니다. 기사에서도 지적했듯, Copilot과 같은 서비스는 UI의 변화 없이 내부 모델만 슬쩍 갈아끼우곤 합니다. 사용자는 아무것도 변하지 않았다고 생각하지만, 실제로는 엔진이 바뀐 자동차를 운전하는 셈입니다.

제가 겪은 최악의 사례는 AI에게 "작업 진행 상황을 보여달라"고 요청했을 때였습니다. AI는 시각적인 UI 요소(Progress Bar)를 띄우는 대신, 텍스트 기호로 [||||||...] 같은 모양을 그려서 텍스트로 출력했습니다. 웃어넘길 수도 있는 해프닝이지만, 실무자 입장에서는 막막함이 앞섭니다. 도구의 일관성을 신뢰할 수 없게 되면, 그 도구를 사용하는 인간은 끊임없이 검증(Verification)을 해야 하기 때문입니다.

결국 '생산성 향상'이라는 명목하에, 우리는 AI가 뱉어낸 결과물이 맞는지 확인하고, 틀렸다면 다시 "고블린을 찔러"를 "고블린을 베어"로 바꿔 입력해보는 'PromptQuest' 게임을 강제로 플레이하고 있는 것입니다.

게임을 끝내고 시스템을 구축하려면

그렇다면 PM으로서, 그리고 비즈니스 리더로서 우리는 이 상황을 어떻게 타개해야 할까요? 단순히 "AI는 아직 멀었어"라고 배척하기엔 기술의 잠재력이 너무나 큽니다. 저는 다음과 같은 원칙을 세우고 팀에 적용하기 시작했습니다.

• 결과물의 규격화 (Standardization): 자연어로 "잘 정리해줘"라고 부탁하는 것을 멈췄습니다. 대신 JSON 스키마나 마크다운 테이블처럼 명확한 출력 형식을 프롬프트에 강제하고, One-shot 또는 Few-shot 예시를 반드시 포함시켰습니다. AI가 '눈치'로 때려맞히게 하지 말고, '예시'를 통해 정답의 범위를 좁혀야 합니다.

• 버전 관리와 회귀 테스트 (Regression Testing): 프롬프트도 코드처럼 관리해야 합니다. 주요 업무에 사용하는 프롬프트는 깃(Git)으로 버전을 관리하고, 모델이 업데이트될 때마다 동일한 프롬프트가 여전히 유효한 결과값을 내는지 테스트하는 절차를 도입했습니다. AI 플랫폼의 잠수함 패치(Silent Patch)에 당하지 않으려면 우리만의 검증 세트가 필요합니다.

• 휴먼 인 더 루프 (Human-in-the-loop)의 재정의: AI에게 완벽한 자동화를 기대하는 것을 멈췄습니다. 대신, AI가 초안을 잡고 인간이 이를 확정하는 프로세스를 워크플로우의 기본값으로 설정했습니다. AI는 '실행자'가 아니라 '제안자'의 역할에 머물 때 가장 리스크가 적습니다.

2026년을 준비하며

2025년은 어쩌면 AI라는 기술이 '신기한 장난감'에서 '까다로운 동료'로 넘어가는 과도기였을지도 모릅니다. 우리는 이 동료가 때로는 헛소리를 하고, 때로는 시키지 않은 일을 한다는 것을 알게 되었습니다.

'PromptQuest'는 분명 피곤한 게임입니다. 하지만 이 게임의 규칙을 파악하고, 불확실성을 통제 가능한 시스템 안으로 가두는 것이야말로 우리 PM들이 해야 할 역할입니다. "고블린을 어떻게 때릴까" 고민하는 단계를 넘어, 고블린을 잡는 자동화된 함정을 설계하는 단계로 나아가야 합니다.

기술은 여전히 불안정하지만, 그 불안정함 속에서 규칙을 찾아내는 것이 우리의 일이니까요. 막연한 환상보다는 냉철한 데이터와 검증으로, 다가올 새해에는 AI와의 '스무고개' 횟수를 줄여나가시길 응원합니다.