제품에 AI를 도입할 때, '기능'보다 중요한 것은 '맥락'입니다: Calibre 사태를 보며

안녕하세요. 풀링포레스트 Product Manager 최PM입니다.

최근 전자책 관리 소프트웨어의 대명사인 캘리버(Calibre)의 업데이트 소식을 접하고, PM으로서 깊은 생각에 잠겼습니다. 10년 넘게 전자책을 관리해 온 든든한 도구였던 캘리버가 버전 8.16.0에서 'Discuss with AI'라는 기능을 탑재하며 사용자들의 거센 반발에 직면했기 때문입니다. 오늘은 이 사건을 통해 우리가 제품에 신기술을 도입할 때 범하기 쉬운 실수와, 기술 이전에 고민해야 할 '사용자 경험의 맥락'에 대해 이야기해보고자 합니다.

단순한 기능 추가가 불러온 파장

사건의 발단은 단순했습니다. 캘리버 개발팀은 Google Gemini API나 로컬 LLM(Ollama 등)을 연동하여 책 내용을 요약하거나 문법을 교정하고, 다음에 읽을 책을 추천받을 수 있는 기능을 추가했습니다. 개발자 관점에서 보면 이는 매우 자연스러운 진화입니다. 텍스트 데이터가 풍부한 전자책 플랫폼에 LLM을 붙여 가치를 더하겠다는 논리는 흠잡을 데가 없어 보입니다.

하지만 사용자들의 반응은 차가움을 넘어 격렬했습니다. 포럼에서는 "내 서재에 AI가 들어오는 것이 불쾌하다", "저작권 침해 논란이 있는 기술을 사용하도록 유도한다"는 비판이 쏟아졌습니다. 급기야 AI 기능을 제거한 'arcalibre' 같은 포크(Fork) 프로젝트가 등장하기 시작했습니다.

유지관리자인 Kovid Goyal은 "기능은 기본적으로 꺼져 있고, API 키를 넣지 않으면 아무 작동도 하지 않는다. 싫으면 안 쓰면 그만"이라는 입장을 고수했습니다. 논리적으로는 완벽한 말입니다. 코드는 비활성화되어 있고, 리소스도 잡아먹지 않으니까요. 하지만 PM의 관점에서 볼 때, 이 대응은 사용자가 느끼는 '감정적 침해'를 간과한 아쉬운 결정이었습니다.

'Opt-in'이 만능 방패는 아닙니다

우리는 흔히 새로운 기능을 추가할 때 "설정에서 끌 수 있게 만들면 문제없겠지"라고 생각합니다. 저 역시 과거에 트래픽을 늘리기 위해 다소 공격적인 추천 알고리즘을 도입하면서 "싫은 사람은 끄면 된다"고 안일하게 판단했던 적이 있습니다. 하지만 사용자는 메뉴 한 구석에 자리 잡은 그 기능의 존재 자체만으로도 스트레스를 받습니다.

캘리버의 경우, 기능의 이름이 'Discuss(토론)'였다는 점도 불을 지폈습니다. LLM에 쿼리를 날리는 행위를 '토론'이라고 명명함으로써, 도구를 의인화하고 사용자가 원치 않는 '대화 상대'를 강제로 배정받은 듯한 느낌을 주었습니다. 게다가 View 메뉴에 떡하니 자리 잡은 항목은, 비록 작동하지 않더라도 사용자의 시각적 경험을 방해하는 요소가 되었습니다.

결국 "사용하지 않을 권리"를 보장하는 것만으로는 부족합니다. "보지 않을 권리", 즉 나의 작업 공간이 내가 원하지 않는 기술적 맥락으로 오염되지 않기를 바라는 사용자의 마음을 읽어야 했습니다.

기술적 완성도와 가치의 문제

더 뼈아픈 지점은 이 기능의 실제 효용성입니다. 원문 기사에 따르면, 실제로 GitHub AI나 Ollama를 연동해 사용해 본 경험은 그리 인상적이지 않았다고 합니다. 설정 과정은 복잡했고(API 토큰 발급, 로컬 서버 구동 등), 막상 돌아온 답변은 책을 읽지 않은 AI가 뱉어내는 피상적인 텍스트에 불과했습니다.

제품 관리자로서 우리는 항상 자문해야 합니다. "이 기능이 정말 사용자에게 'Wow' 모먼트를 주는가?" 준비되지 않은 AI 기능을 트렌드에 편승해 서둘러 탑재하는 것은, 오히려 제품 전체의 신뢰도를 떨어뜨리는 결과를 낳습니다. 사용자는 복잡한 설정을 거쳐 기능을 켰는데, 결과물이 엉성하다면 "이 제품이 이제 본질을 잃고 곁가지에만 신경 쓰는구나"라고 실망하게 됩니다.

우리가 가져야 할 태도

이번 사태는 풀링포레스트 팀에게도 시사하는 바가 큽니다. 우리 역시 서비스 곳곳에 AI를 도입하고 있고, 그 과정에서 효율성과 사용자 경험 사이의 균형을 고민하고 있기 때문입니다. 제가 생각하는 올바른 접근법은 다음과 같습니다.

"AI 기능이 추가되었습니다"라고 자랑하기보다, "이제 복잡한 요약 업무를 더 빠르게 처리할 수 있습니다"와 같이 사용자가 얻을 이득에 집중해야 합니다. 그리고 그 기능은 사용자의 워크플로우를 방해하지 않는 선에서 조용히, 필요할 때만 드러나야 합니다.

모든 사용자가 얼리어답터는 아닙니다. 누군가에게는 익숙한 도구의 안정성이 신기술보다 훨씬 중요합니다. UI에 새로운 버튼을 추가하는 것은 그들의 앞마당에 깃발을 꽂는 것과 같습니다. 충분한 설득과 부드러운 온보딩 과정이 선행되어야 합니다.

AI는 도구일 뿐입니다. 제품의 본질적인 가치(캘리버의 경우 전자책 관리와 뷰어 기능)가 훼손되거나, AI 기능의 퀄리티가 낮다면 도입을 늦추는 용기도 필요합니다.

기술은 빠르게 발전하지만, 그 기술을 받아들이는 사용자의 마음은 그렇게 빠르지 않습니다. 우리는 그 간극을 메우는 역할을 해야 합니다. 코드로 구현 가능한 것과 사용자가 받아들일 수 있는 것 사이에서, 현명한 줄타기를 하는 여러분이 되시기를 바랍니다. 저도 오늘 팀원들과 함께 우리가 준비 중인 기능이 사용자의 '어떤 문제'를 해결하는지, 혹시 '우리만의 기술 자랑'은 아닌지 다시 한번 점검해 봐야겠습니다.