플랫폼이 바뀔 때마다,
새 영역을 제품으로 만들어 왔습니다.

AI 검색 과제를 맡은 팀 기획자가 첫 주에 시안 세 장을 들고 왔습니다. 국내외 AI 검색 화면을 서른 장 넘게 모아, 대화형 입력창과 맨 위의 AI 답변 카드, 추천 질문 세 개를 그린 시안이었습니다. 화면은 잘 그렸고, 요즘 서비스들과 견줘도 손색이 없었습니다.

저는 시안을 넘기기 전에 하나만 물었습니다. "지금 우리 검색에서 사람들이 못 찾는 게 정확히 뭐예요?" 답이 나오지 않았습니다. 추천 질문도 "사람들이 많이 물을 것 같은" 것으로 고른 상태였습니다. 남의 화면은 서른 장이나 봤는데, 우리 검색창에서 사람들이 무엇을 찾다가 실패했는지는 아직 아무도 보지 않았던 겁니다. 시안은 잠시 덮고 돌려보냈습니다. 대신 숙제를 하나 줬습니다. 결과가 0건이었던 질문 스무 개를 골라, 하나씩 직접 검색해 보고 왜 안 나왔는지 옆에 적어 오라고요.

"결과 없음" 스무 줄이 보여 준 것

다음 날 돌아온 표에는 검색창 모양 때문에 못 찾은 질문이 하나도 없었습니다. 대부분은 답이 적힌 자료가 검색 대상에 없었습니다. 영상 안의 장면을 찾는 질문, 팬들만 쓰는 줄임말로 묻는 질문, 여러 나라 말이 섞인 질문, 검색 대상에서 빠진 도움말을 찾는 질문이었습니다. 그 시안을 그대로 개발했다면, AI도 읽을 게 없으니 몇 달 뒤 새 화면에서 똑같은 "결과 없음"을 다시 봤을 겁니다.

질문 종류마다 답하는 방식을 따로

스무 줄을 원인별로 함께 묶고 나니 첫 작업은 화면이 아니라 자료가 됐습니다. 영상 자막을 시점과 함께 검색 대상에 넣고, 줄임말 목록을 검색 기록에서 직접 모으고, 빠진 도움말을 다시 넣었습니다. AI 답변 카드의 자리도 크게 줄었습니다. 모든 질문에 AI를 부르면 비용과 응답 시간만 늘어납니다. 안내 질문은 원문 하나면 충분하고, 민감한 질문은 AI가 보안 절차를 지어낼 위험이 있어 원문으로 보냈습니다.

시안 세 장 중에 살아남은 건 입력창 하나였습니다. 버린 게 아니라 순서가 바뀐 겁니다. 시안 앞에 표 한 장이 생겼고, 그 표에서 정한 답의 모양이 화면의 칸을 정했습니다.

시안을 돌려보낼 때는 "다시 해 오세요"가 아니라 무엇을 먼저 봐야 하는지를 건넵니다. 이 과제 뒤로 팀의 AI 기능 기획서는 시안이 아니라 못 찾은 질문 스무 개로 시작합니다.

AI 답변을 "질문 → AI → 답"이라는 화살표 하나로 그리면, 이상한 답이 나왔을 때 고칠 곳도 하나뿐입니다. 회의실에서는 누구는 프롬프트를, 누구는 검색 순위를, 누구는 모델 교체를 이야기하게 됩니다. 그래서 기획서 첫 장부터 답이 만들어지는 길을 다섯 단계로 나눴습니다. ① 질문을 이해하고, ② 자료를 찾고, ③ 그중 근거로 쓸 글을 고르고, ④ 답을 쓰고, ⑤ 문장마다 출처를 달며 검사하는 단계입니다. 그리고 단계마다 막을 것, 더할 것, 담당, 남길 기록을 정했습니다.

시범 운영에서 바로 쓸모가 있었다

시범 운영 중에 이상한 답들이 모였을 때, 단계별 기록을 열어 보니 원인이 서로 다른 곳에 있다는 게 바로 보였습니다. 바뀐 공지와 예전 글을 한 답에 섞어 없는 일정을 만든 답은 ③단계에 날짜 기준이 없어서였습니다. 홍보성 글이 근거로 올라온 답은 ②단계 순위 문제였습니다. 출처 번호는 붙었는데 그 글에 그런 말이 없던 답은 ④·⑤단계 문제였습니다. 화면에서는 모두 똑같이 "AI가 이상한 답을 했다"로 보였습니다.

단계마다 막을 것과 더할 것

이 표 덕분에 이상한 답이 들어오면 첫 질문은 "누가 잘못했나"가 아니라 "몇 번 단계인가"였습니다. 찾아온 자료 목록만 열어 봐도 어디 문제인지 보였고, 해당 단계의 담당에게 바로 넘길 수 있었습니다. 그리고 이 표를 채우는 일 자체가 기획이었습니다. 어떤 질문에 AI 답을 붙이지 않을지, 멤버십 전용 글을 어디까지 근거로 쓸지, 예전 글과 최신 글이 다를 때 무엇을 믿을지는 개발이 아니라 서비스 정책입니다. 특히 공개 범위 규칙은 화면에 보이지 않지만 가장 먼저 정해야 할 결정이었습니다. 비공개 글이 한 번이라도 답에 섞이면, 글을 쓴 팬도 검색한 팬도 서비스를 다시 믿기 어렵기 때문입니다.

AI 답변 기획에서 화면은 마지막 단계의 결과일 뿐입니다. 화면 앞의 다섯 단계에서 무엇을 막고 더할지를 기획이 정하지 않으면, 서비스 정책이 코드 속에 묻힙니다.

출시 뒤 남은 숙제는 품질 확인이었습니다. 여러 나라에서 매일 들어오는 질문을 사람이 다 읽을 수는 없으니, 팀은 다른 AI가 답변을 읽고 통과와 실패를 매기게 했습니다. 담당 기획자가 채점 AI에 넣은 지시는 "질문에 정확하고 도움 되게 답했는지 평가해 줘" 한 줄이었습니다.

새로 공개된 콘텐츠만 무더기로 실패

어느 날 실패 목록이 평소보다 길다는 보고가 올라왔습니다. 거의 다 그 주에 새로 공개된 콘텐츠에 대한 질문이었고, 팀은 답변 AI가 고장 난 줄 알았습니다. 저는 프롬프트를 고치기 전에 실패한 답변을 우리 데이터와 한 줄씩 대조해 보자고 했습니다. 답은 맞았습니다. 채점 AI가 "존재하지 않는 정보를 지어냈다"며 실패를 준 것이었습니다. 학습이 끝난 뒤에 나온 콘텐츠를 채점하는 쪽이 몰랐던 겁니다.

채점 기준도 우리 기준과 달랐습니다. 다루지 않는 질문에 "여기서는 답하기 어려워요, 대신 이곳에서 확인해 보세요"라고 안내하면 우리는 잘한 답으로 봤지만, 채점 AI는 답하지 않았다며 실패를 줬습니다. 채점 AI는 우리 기획 정책을 모르는 채로 심판을 보고 있었습니다.

기획 기준을 채점 규칙으로

"정확하고 도움 되게"라는 막연한 지시를 버리고, 담당 기획자와 함께 답변 기획 때 정한 정책을 한 줄씩 판정 문장으로 옮겼습니다.

그리고 팀의 주간 루틴을 하나 만들었습니다. 매주 자동 채점 결과 중 일부를 사람이 다시 채점하고, AI와 사람의 판정이 갈린 문항만 따로 모았습니다. 갈린 이유가 규칙의 빈칸인지 가르고, 규칙을 고치면 날짜와 함께 버전을 붙였습니다. 리포트에는 어떤 버전으로 채점했는지 적었습니다. 그래야 통과율이 바뀌었을 때 답변이 좋아진 건지 채점 규칙이 바뀐 건지 구분됩니다. 갈린 문항이 늘 채점 AI의 잘못도 아니었습니다. 사람이 놓친 오류를 AI가 잡은 적도 있었습니다.

채점 규칙을 쓰는 사람은 기획자여야 합니다. 무엇이 좋은 답인지 정한 사람이 그 기준을 심판에게 넘겨줘야 합니다. 정책이 바뀌면 채점 규칙도 같이 바뀌어야 합니다.

AI 검색을 운영하면 프롬프트를 고칠 일이 계속 생깁니다. 어느 날 특정 유형의 검색이 자꾸 엉뚱한 결과를 냈고, 담당 기획자가 원인에 정확히 맞는 한 줄을 프롬프트에 넣었습니다. 틀렸던 검색어 열두 개가 모두 맞았고, 그날 반영됐습니다.

일주일 뒤, 조용히 망가진 세 종류의 검색

주간 품질 리뷰에서 "원하는 결과가 아니에요" 피드백이 평소보다 많이 쌓인 묶음이 보였습니다. 고친 유형과 조금이라도 닿아 있던 다른 세 종류의 검색이 일주일 동안 망가져 있었습니다. 최신 소식이 필요한 검색에서는 예전 글이 위로 올라왔고, 다른 의도의 검색이 고친 유형으로 끌려갔습니다. 프롬프트의 문장에는 칸막이가 없어서, 한 줄이 그 유형에만 작동하지 않고 닿아 있는 모든 검색의 판단을 바꿉니다. 전체 지표는 거의 그대로였습니다. 한쪽이 좋아진 만큼 다른 쪽이 나빠졌고, 여러 나라 검색이 섞여 있어 더 티가 나지 않았습니다.

고칠 때마다 집 전체 불을 켠다

누구의 실수가 아니라 확인하는 절차가 없었던 문제였습니다. 그래서 팀의 프롬프트 수정 절차를 이렇게 정했습니다.

• 프롬프트를 덮어쓰지 않고 번호를 붙여 새 버전으로 저장합니다.
• 모든 검색 유형을 여러 언어로 덮는 시험 검색어 모음을 자동으로 돌립니다. 모음은 그동안 틀렸던 검색어가 아니라 실제 검색 기록에서 유형별·언어별로 고르게 뽑습니다.
• 검색어마다 이전 버전과 새 버전의 통과 여부를 나란히 봅니다.
• 나빠진 검색어가 하나라도 있으면, 좋아진 게 많아도 반영을 보류하고 원인부터 찾습니다.

그 한 줄은 적용 범위를 좁혀 다시 넣었고, 전체를 돌려 나빠진 검색어가 없는 걸 확인한 뒤 반영했습니다.

속도를 고칠 때도 같았다

답이 느리다는 지적에 팀이 답을 짧게, AI의 생각 단계를 얕게 줄인 적이 있습니다. 답은 확실히 빨라졌고 기다리다 지나가는 검색도 줄었습니다. 저는 지표가 좋아진 다음 날 실제 답변 기록을 같이 읽어 보자고 했습니다. 조건이 붙은 안내일수록 사실이 바뀌어 있었습니다. "가능, 단 이런 경우는 불가"가 "불가"로만 나가는 식이었습니다. 틀린 답이 오히려 빠르고 단호해 보여서, 속도 지표로는 좋은 사례로 잡혔습니다.

그래서 무엇을 포기하고 무엇을 지킬지 팀과 선을 다시 그었습니다. 목표 응답 시간을 숫자로 먼저 정하고, 틀리면 사용자가 손해를 보는 답의 목록을 만들고, 조건이 붙은 질문을 일부러 많이 넣은 시험 질문으로 전후를 비교합니다. 빨라져도 사실이 바뀐 답이 하나라도 나오면 반영하지 않습니다.

AI 서비스에서 고친 다음에 볼 것은 "고친 문제가 풀렸나"가 아니라 "다른 문제가 생겼나"입니다. 무엇을 포기해도 되는지는 회의가 아니라 시험 질문이 판정합니다.

여러 법인과 파트너가 함께 쓰는 커머스 어드민에서 권한 개편 요청이 들어왔습니다. "파트너마다 자기 스토어 매출만 봐야 하고, 물류 담당은 출고와 재고만 봐야 한다." 팀 기획자가 가져온 기획서는 문제를 정확히 짚었지만, 해법은 메뉴마다 "보기·수정·다운로드" 체크박스를 다는 화면이었습니다. 체크박스가 마흔 개쯤 됐습니다.

리뷰에서 하나를 물었습니다. "이 담당자가 매출 화면에서 전체 기간 다운로드를 누르면, 서버는 어느 스토어 데이터를 보내요?" 데이터는 상위 계정 하나 기준으로 열려 있었습니다. 화면만 가리고 데이터는 다 열려 있는 구조였습니다.

체크박스로 경계를 그리면 생기는 일

• 데이터는 화면으로만 나가지 않습니다. 다운로드, 검색 결과, 알림 메일, 외부 시스템 연동은 조회하는 계정의 범위를 그대로 따라갑니다. 확인해 보니 다운로드와 월말 리포트 메일은 화면 권한을 전혀 보지 않고 있었습니다.
• 현실의 역할은 스토어 하나에 딱 맞지 않습니다. 여러 스토어를 합쳐 봐야 하는 파트너, 특정 카테고리만 맡은 본사 담당, 창고를 옮긴 물류 담당, 판매를 종료했지만 지난 반품은 처리해야 하는 파트너가 있었습니다.
• 체크박스를 누를 사람이 우리 운영팀이었습니다. 파트너가 늘수록 운영 공수도 그대로 늘어나는 구조였습니다.

경계부터 종이에 그리다

데이터는 스토어와 창고마다 서버에서 경계를 긋고, 각 계정은 연결된 범위만 꺼낼 수 있게 했습니다. 파트너 안의 최상위 권한자를 한 명 정하고, 그 아래 권한은 파트너가 스스로 관리하게 했습니다. 체크박스 화면은 남았지만, 경계를 정하는 곳이 아니라 정해진 경계 안을 다듬는 곳이 됐습니다.

권한 기획서의 첫 장은 역할 그림과 "최상위 권한자는 누구인가" 한 줄입니다. 운영팀이 직접 권한을 눌러 주는 구조는 파트너가 늘수록 무너집니다.

반품 수거 예약 기획서를 리뷰하던 날의 이야기입니다. 고객이 수거 시간을 직접 고르고, 상품 사진으로 반품 가능 여부를 미리 안내받는 기능이었습니다. 문제 정의는 좋았습니다. 시스템이 정한 날짜에 집에 없어 수거가 실패하고 다시 잡는 일이 잦다는 고객 문의 분석이 붙어 있었습니다.

리뷰 전에 팀 기획자에게 셀프 리뷰 체크리스트를 먼저 대 보게 했습니다. 다시 읽으면 쓴 대로 읽히지만, 정해진 질문에 대 보면 빈 곳이 보이기 때문입니다. 세 군데가 걸렸습니다.

• 예외와 운영. 기사가 도착했는데 상품이 없거나, 수거 10분 전에 취소하거나, 공동현관에 못 들어가는 경우가 없었습니다. 기사가 단말에서 "수거 실패"를 누르면 고객에게 다시 잡기 버튼이 바로 가도록 고쳤습니다. 상담원이 전화로 하나하나 다시 잡던 일을 고객이 스스로 하게 됐습니다.
• 숫자. "시간을 직접 고른 고객은 수거 실패가 적다"에 비교 대상이 없었습니다. 시범 지역과 아닌 지역을 나란히 놓고, 4주치라 "가설"이라고 표시했습니다. 차이는 생각보다 작았지만 방향이 맞아 그대로 썼습니다.
• 문장. "수거 완료", "반품 완료", "검수 대기"가 섞여 있었습니다. 고객은 "반품 완료" 알림을 받고 바로 환불되는 줄 알 수 있었습니다. 상태 이름을 하나로 정하고 알림에 환불 예정일을 넣었습니다.

같은 체크리스트를 AI에게도 줘 봤습니다. 처음에는 모든 항목을 칭찬했습니다. 문제가 없는 항목은 쓰지 말고, 문제마다 원문을 인용하고, 고칠 방법과 결정권자가 물을 아픈 질문 두 개를 쓰게 하자 하나를 더 찾았습니다. "AI가 반품된다고 안내했는데 판매자 검수에서 거절되면, 누가 책임지나요?"

셀프 리뷰로 바뀐 건 표 하나와 문장 몇 줄이었지만, 리뷰 시간은 오타 대신 "AI 안내가 틀렸을 때의 책임" 하나에 쓰였습니다. 리뷰는 시험이 아니라 상의하는 자리여야 합니다.

B^DISCOVER의 첫 화면은 단순했습니다. 커다란 빈 입력창 하나와 "그리기" 버튼 하나. 무엇이든 그릴 수 있으니 무엇이든 쓰게 두자는 것이 팀의 판단이었고, 내부 시연 반응도 아주 좋았습니다. 그런데 시연에 참여한 사람들은 이 기술을 만든 사람들이었습니다. 무엇을 어떻게 써야 그림이 잘 나오는지 이미 알고 있었습니다.

어디서 깨졌나

출시 뒤 반응은 극과 극이었습니다. 어떤 사람들은 하루에도 수십 장을 만들었고, 훨씬 많은 사람이 한두 번 써 보고 돌아오지 않았습니다. 떠난 사람들의 입력은 대부분 한두 단어였고, 결과도 흐릿했습니다. 아무것도 쓰지 않고 나간 사람도 많았습니다. 빈 칸은 만드는 사람에게는 자유지만, 처음 온 사람에게는 숙제였습니다.

저는 팀과 함께 질문을 바꿨습니다. "AI가 무엇을 그릴 수 있나"가 아니라 "사람들이 이미 하려는 일 중에 그림이 필요한 일은 무엇인가"로요.

네 단계로 옮긴 자리

단계마다 사람들이 어디서 막히는지 보고 다음 단계에서 풀었습니다. 2단계 선택지는 팀 기획자가 잘 쓰는 사람들의 긴 입력을 주제, 화풍, 빛, 구도 같은 조각으로 나눠 만들었습니다. 잘 쓰는 사람이 머릿속에서 하던 조합을 화면이 대신 해 주는 셈입니다. 4단계는 팀이 3단계 사용자 중에 얼굴 대신 물건 사진을 올리는 사람들을 발견하면서 찾았습니다. 새 상품을 올릴 때마다 배경을 바꿔 찍어야 하는 판매자들이었습니다. 매일 쓸 이유가 있는 자리였습니다.

모델은 처음과 거의 같았는데, 입력창이 사라질수록 쓰는 사람이 늘었습니다. AI가 나아진 게 아니라 AI를 둔 자리가 나아진 것입니다. 사용자는 AI를 쓰러 오지 않고, 하려던 일을 끝내러 옵니다.

새 모델이 잘 끊기 시작하자 팀은 데모 영상을 만들었고, 회의실에서 박수가 나왔습니다. 끊어 읽기는 오래 검증된 공부법이니 효과는 따라올 거라는 분위기였습니다. 출시 문서를 검토하며 제가 팀에 물었습니다. "잘 끊는 건 알겠어요. 그래서 이걸 쓴 사람의 독해 실력이 오르나요?"

바로 답할 수 있는 사람이 없었습니다. 우리가 증명한 건 "AI가 잘 끊는다"였지, "AI가 끊어 준 문장으로 공부하면 실력이 는다"가 아니었습니다. 게다가 공부법을 검증한 연구는 선생님이 수업에서 끊어 줄 때의 이야기였습니다. 빗금이 미리 다 그어져 있으면 학습자가 스스로 끊는 연습을 덜 할 수도 있습니다.

실험 설계

출시를 미루고 비교 실험부터 설계하자고 했습니다.

• 고등학생 학습자를 대상으로 사전 시험을 봤습니다.
• 점수와 문항별 응답 패턴으로 군집분석을 해서 실력이 같은 사람끼리 짝을 짓고, 두 그룹으로 나눴습니다. 두 그룹이 처음부터 같다는 건 분산분석으로 확인했습니다.
• 한 그룹은 끊어 읽기로, 다른 그룹은 일반 텍스트로 2주 동안 공부했습니다. 학습 시간은 모두에게 같게 주고 초과 학습은 막았습니다.
• 끝난 뒤 같은 수준의 시험을 다시 보고, 점수 자체가 아니라 얼마나 올랐는지를 비교했습니다.

결과

• 참여자의 3분의 1이 사후 시험을 보지 않았거나 학습 기록이 없어 빠졌습니다.
• 남은 사람 전체로 두 그룹을 비교하면 유의확률 0.226. 차이가 없었습니다.
• 사전 실력이 같은 짝만 남기자, 끊어 읽기 그룹은 공부 전후 점수 차이가 유의했고(유의확률 0.020) 일반 텍스트 그룹은 그렇지 않았습니다.
• 하지만 두 그룹 사이의 차이는 증명하지 못했습니다. 참고한 논문만큼 점수가 오르지 않았고, 2주는 짧았고, 스스로 앱을 켜야 하는 환경이었습니다.
• 학습 시간과 점수 변화 사이에는 상관이 없었습니다. 끊어 읽기 그룹은 더 적은 시간을 쓰고도 점수가 더 올랐습니다.

보고서의 결론은 "효과가 있다"가 아니었습니다. 확인한 것, 확인하지 못한 것과 그 이유, 그리고 다음 가설인 "학습 효율"을 나란히 적었습니다.

AI의 증명은 두 겹입니다. 기술이 되는가, 그리고 써 보면 좋아지는가. 데모는 첫 번째만 보여 줍니다. 두 번째는 써 본 사람의 결과로만 알 수 있고, 그 결과가 기대와 달라도 그대로 적어야 다음 일이 생깁니다.