사용자가 제품을 대화형으로 사용하지 않는 이유

제가 지금 다루는 AI 작업의 대부분은 새로운 AI 제품이 아닙니다. 이미 유료 고객이 있고, 수년간 구축된 스키마가 있는 기존 제품이며, 소유주가 경쟁사보다 먼저 'AI를 추가하라'는 지시를 받은 경우입니다. 때로는 이사회에서, 때로는 영업팀에서, 때로는 갱신 통화 중의 한 고객으로부터 이러한 요구가 나옵니다.

초안은 거의 항상 같습니다. 제품에 대한 질문에 답하는 오른쪽 하단 모서리의 채팅 비서입니다. 시연할 때는 매우 멋지게 작동합니다. 하지만 몇 주 안에 사용량이 급락하는데, 아무도 대화를 나누기 위해 그 제품을 열어보지 않았기 때문입니다. 사람들은 작업을 완료하기 위해 그것을 여는 것이었습니다.

엔지니어로서 제가 흥미롭다고 느끼는 부분은 모델 자체가 이 전체 과정에서 가장 쉬운 부분이라는 것입니다. 진정한 작업은 주변의 지루한 레이어에 있습니다. 어떤 데이터가 입력되는지, 누구의 권한으로 실행되는지, 출력물이 화면 어디에 표시되는지, 그리고 모델이 잘못되거나 작동하지 않을 때 무슨 일이 발생하는지 말입니다. 이 글은 바로 그것에 관한 것입니다.

모델이 아닌 작업에서 시작하라

'AI를 어디에 사용할 수 있을까?'라는 질문은 틀린 질문입니다. 유용한 질문은 다음과 같습니다. 사용자들이 이미 이 제품에서 반복적으로 수행하는, 느리거나 지루하거나 오류가 발생하기 쉬운 작업은 무엇인가?

계속해서 작동하는 후보들은 공통된 형태를 가지고 있습니다:

• 사용자가 조치하기 전에 읽어야 하는 긴 내용을 요약: 스레드, 기록 내역, 녹음 파일 등.
• 어지러운 내용에서 구조화된 필드를 채우기: 업로드된 파일, 이메일, 메모 등을 이미 가지고 있는 양식에 매핑하는 작업.
• 답변이나 보고서의 초안 작성: 사람이 편집하고 승인할 수 있도록 하는 것.
• 들어오는 항목을 올바른 대기열이나 카테고리로 분류 및 라우팅하기.
• 찾는 것 찾기: 키워드뿐만 아니라 의도를 이해하는 검색 기능.

이 모든 경우에 오늘 측정할 수 있는 기존 워크플로우가 존재합니다. 이것이 기준선(baseline)을 제공하며, 기준선만이 그 기능이 어떤 변화를 가져왔는지 알 수 있는 유일한 방법입니다.

저의 앱인 LectureNotes AI가 그 좋은 예시입니다. 이 앱은 애초부터 AI를 탑재했음에도 불구하고 말이죠. 아무도 모델과 채팅하고 싶어서 강의 녹음을 하지 않습니다. 그들은 공부할 수 있는 노트를 원합니다. 전사(transcript), 핵심 요약(key takeaways), 그리고 구조화된 개요는 모두 단 하나의 목적을 위해 존재하며, 그 어떤 것도 채팅창은 아닙니다. (제가 이 앱이 가르쳐준 것에 대해 따로 글을 썼습니다.)

추정치에는 아무도 넣지 않은 데이터 작업

성숙한 제품들은 데이터를 모델에게 건네주기 위해서가 아니라, 인간에게 보여주기 위해 만들어졌습니다. 이 간극이 대부분의 개발 시간이 투입되는 곳입니다.

컨텍스트를 조립하는 것은 평범한 엔지니어링이며, 이것이 가장 많은 부분을 차지합니다.

데이터가 어디로 이동할 수 있는지 알아야 합니다. 만약 고객이 데이터 처리 약관에 동의한 계약을 체결했다면, 그들의 기록을 모델 제공업체에 전송하는 것이 허용될 수도 있고 그렇지 않을 수도 있습니다. 구축하기 전에 반드시 확인해야 합니다. 만약 허용되지 않는다면, 작업 가능한 몇 가지 대안이 있습니다: 제로 리텐션(zero-retention) 제공업체 약관, 특정 처리 지역 지정, 자체 호스팅 모델 사용, 또는 호출 전에 민감한 필드를 제거하는 방법 등이 있습니다.

다음은 '동일 접근 계층 유지 및 조용히 실패하기(same access layer, fail quietly)' 패턴이 대략적으로 어떻게 보이는지에 대한 예시입니다. 이는 참고 자료이며 클라이언트 코드베이스에서 가져온 것은 아닙니다:

// 예시: AI 패널은 제품 자체의 접근 계층을 재사용하며
// 자신이 존재하는 페이지를 절대 차단하지 않습니다.
async function getRecordSummary(user: User, recordId: string) {
...

여기서 중요한 두 가지가 있습니다. 데이터베이스로 가는 특권 경로가 없기 때문에, AI 기능에서의 권한 버그는 검토를 통해 방지되는 것이 아니라 구조적으로 불가능합니다. 또한 느리거나 실패하는 제공업체는 화면을 멈추게 하는 대신 null을 반환해야 합니다. 이 제품은 해당 기능이 존재하기 전에도 작동했습니다. 따라서 해당 기능이 작동하지 않을 때도 계속 작동해야 합니다.

이미 작업이 이루어지는 곳에 배치하세요

배치 위치(Placement)는 누군가 AI 기능을 지속적으로 사용할지 여부를 결정하는 가장 큰 요소입니다. 효과적인 패턴은 사용자가 필요로 하는 바로 그 순간, 사용자가 현재 보고 있는 화면 내부에 출력을 넣는 것입니다:

• 방금 열어본 기록 상단에 요약 패널을 배치합니다.
• 업로드된 문서에서 미리 채워진 양식 필드를 제공하고, 확인 전까지 '제안'으로 눈에 띄게 표시합니다.
• 별도의 도구가 아닌, 기존 회신함 옆에 "초안 답장" 버튼을 만듭니다.
• 사용자가 곧 터치하려던 드롭다운 메뉴에서 이미 선택된 추천 카테고리를 보여줍니다.

이 모든 경우에 기존 워크플로우는 온전하게 유지되며 사용자는 통제권을 갖게 됩니다. AI가 틀리면, 그들은 자신의 실수처럼 고칠 수 있습니다. 만약 맞다면, 단 하나의 새로운 것도 배우지 않으면서 시간을 절약할 수 있습니다.

일반적인 채팅 비서(chat assistant)는 사람들이 실제로 어떤 질문을 하는지 알게 된 후에야 자리를 잡을 수 있습니다. 이는 거의 항상 적절한 첫 번째 기능이 아닙니다.

잘못될 것을 염두에 두고 설계하기 (Design for being wrong)

모든 AI 기능은 때때로 나쁜 출력을 생성할 것이므로, 이를 엣지 케이스(edge case)가 아니라 정상적인 코드 경로(normal code path)로 취급해야 합니다.

• 제안 사항은 제안처럼 보여야 합니다. 미리 채워진 필드는 사용자가 확인하기 전까지 시각적으로 구별되어 있어야 합니다. 아무것도 조용히 생성되어 사실 기록이 되어서는 안 됩니다.
• 되돌릴 수 없는 행동 뒤에는 인간이 있어야 합니다. 읽고 제안하는 것은 위험도가 낮습니다. 보내기, 삭제하기, 비용 지불하기 또는 다른 사람의 데이터를 변경하는 것은 규칙이 다른 별개의 제품입니다. 저는 이 부분에 대해 AI 에이전트에게 한 번에 하나의 동사(verb)로 쓰기 접근 권한 부여하기에서 깊이 다루었습니다.
• 사용자에게 원클릭 '이것은 잘못되었습니다' 기능을 제공하세요. 비용은 거의 들지 않으며, 모든 실패를 레이블링된 예시(labeled example)로 바꿉니다.

비용은 좌석 수에 비례하지 않고 사용량에 비례합니다 (Cost scales with use, not seats)

일반적인 기능들은 고객이 한 달에 한 번 사용하든 하루 종일 사용하든 비슷한 비용이 듭니다. AI 기능은 그렇지 않습니다. 모든 요약(summary)과 초안(draft)은 측정되는 호출(metered call)이며, 가장 많이 사용하는 사용자 그룹의 비용은 가장 적게 사용하는 사용자 그룹보다 훨씬 클 수 있습니다.

출시 전에 활성 사용자당 월별 현실적인 사용량을 기준으로 산술 계산을 해보세요. 만약 그 숫자가 부담스럽다면, 해결책은 아키텍처적입니다. 페이지 뷰마다 요약을 생성하는 대신 기록이 변경될 때 한 번만 생성하고, 작업에 필요한 컨텍스트(context)만 보내며, 좁은 범위의 작업은 더 작은 모델로 라우팅하세요. 저는 호출을 측정 단위처럼 다루어 AI 기능 구축하기에 대해 전체 게시물을 작성했는데, 그만큼 중요하기 때문입니다.

다른 위험한 기능처럼 출시하세요 (Ship it like any other risky feature)

1. 작은 평가 세트를 먼저 구축하세요. 자체 제품에서 나온 실제 예시 30~50개를 준비하고, 각 예시마다 좋은 결과물이 어떤 모습인지 정의합니다. 프롬프트나 모델이 변경될 때마다 이를 실행하여 개선점과 퇴보(regression)를 구분할 수 있어야 합니다.
2. 기능 플래그(feature flag) 뒤에 출시하세요: 내부 사용자에게 먼저 공개하고, 그다음 몇몇 친한 고객들에게, 마지막으로 모두에게 공개합니다.
3. 클릭 수가 아닌 작업 자체를 측정하세요. 사용자가 특정 작업을 수행하는 데 걸리는 시간이 줄었나요? 사용자들이 제안을 수용했나요, 아니면 다시 작성했나요? 한 달 후에도 여전히 사용하고 있나요? 패널을 한 번 열어보는 것은 호기심일 뿐, 실제 채택(adoption)은 아닙니다.
4. 출시 후에도 계속 관찰하세요. 제공업체들은 사용자 모르게 하위 모델들을 업데이트하며, 여러분의 데이터는 드리프트(drift)합니다.

또한 모든 모델 호출을 프롬프트를 설정에 담아둔 하나의 내부 인터페이스를 통해 라우팅하는 것이 유리합니다. 이렇게 하면 더 저렴하거나 좋은 모델을 시도할 때 코드를 다시 작성할 필요 없이 설정 변경과 평가 실행만으로 충분합니다.

제가 실제로 가장 먼저 할 일

느리고 반복되는 작업 중 하나를 고르세요. 사용자의 권한 하에 가져온 깨끗한 컨텍스트(context)를 모델에 공급하세요. 그 결과물을 사용자들이 이미 작업하는 위치에 정확히 배치하고, 실패하더라도 조용하게 처리되도록 만든 다음, 그것이 지속적으로 사용되는지 측정합니다. 사람들이 계속 사용하는 기능 하나가 한 번 시도해 본 다섯 가지 기능보다 낫습니다.

이는 Null Studio 블로그의 더 긴 가이드에서 각색된 내용이며, 그곳에서는 커미셔닝(commissioning) 측면도 다룹니다. 저는 다른 사람들이 무엇을 보았는지 궁금합니다: 혹시 모서리 채팅 비서(bottom-corner chat assistant)를 출시한 적이 있는 분이 계신가요? 그리고 그것이 실제로 지속적으로 사용되게 만든 것은 무엇이었나요? 어떤 점이 차이를 만들었을까요?