데모는 항상 작동합니다. 그것이 문제입니다.

제가 운영해 온 모든 AI 프로젝트에는 결승선처럼 느껴지지만 실제로는 결승선이 아닌 순간이 있습니다. 회의실의 누군가가 데모가 작동하는 것을 보고, 답변이 깔끔하게 돌아오는 것을 보면 분위기는 "좋아요, 언제 출시할 수 있나요?"로 바뀝니다. 저는 그 순간을 대비하는 법을 배웠습니다. 왜냐하면 한 번 작동하는 데모와 사람들이 매일 의존할 수 있는 기능 사이의 간극이 실제 프로젝트의 대부분이 존재하는 곳이기 때문입니다.

수치도 이러한 느낌을 뒷받침합니다. 어떤 연구를 읽느냐에 따라 다르지만, AI 파일럿(Pilot)의 80%에서 90% 사이가 프로덕션(Production) 단계에 도달하지 못합니다. 그 이유는 모델 때문인 경우가 거의 없습니다. 모델은 보통 제대로 작동하는 부분입니다. 프로젝트를 지연시키는 것은 모델 주변의 모든 것입니다. 즉, 큐레이션된 데모 세트보다 프로덕션 환경에서 더 지저분한 데이터, 아무도 범위를 정하지 않았던 도구들과의 통합, 그리고 출시 6주 후에 답변이 드리프트(Drift)될 때 누가 책임을 질 것인가에 대한 문제입니다.

따라서 클라이언트가 마법을 기대할 때, 제 역할은 그들의 기대를 꺾는 것이 아닙니다. 정직한 곳에 결승선을 다시 그리는 것입니다.

기대치가 "그냥 알아서 한다"일 때의 범위 설정 (Scoping)

가장 까다로운 대화는 코드를 작성하기 전인 초기 단계에 발생합니다. 클라이언트가 경쟁사가 한 것을 보았거나, 주말 동안 ChatGPT가 자신을 위해 해준 일을 설명할 때 말이죠. 그것은 실제적인 참조 지점이며 저는 그것을 무시하지 않습니다. 하지만 주말 동안의 프롬프트(Prompt)와 프로덕션 기능은 완전히 다른 동물이며, 그 차이가 거의 모든 작업량입니다.

마법을 약속하는 대신 제가 하는 일은 다음과 같습니다. 저는 화려하지 않은 목록들을 구체적으로 제시합니다. 데이터는 어디에서 오며, 누가 그것을 깨끗하게 유지하는가? 모델이 확신을 가지고 틀렸을 때는 어떤 일이 발생하는가? 에지 케이스(Edge cases)는 누가, 얼마나 자주 검토하는가? 이 중 어느 것도 데모에는 나타나지 않습니다. 이 모든 것은 프로덕션 3주 차에 나타납니다. 범위 설정(Scoping) 단계에서 이를 테이블 위에 올려두는 것은 비관주의가 아닙니다. 그것이 견적(Estimate)에 의미를 부여하는 유일한 방법입니다.

LLM 정확도는 숫자가 아니라 범위입니다

이것은 제가 가장 자주 재설정하는 기대치입니다. 전통적인 소프트웨어는 결정론적 (Deterministic)입니다. 동일한 입력을 주면 동일한 출력을 얻으며, "완료 (done)"라는 것은 손으로 가리킬 수 있는 실체입니다. LLM은 그렇지 않습니다. 동일한 질문에 대해 약간씩 다른 답변이 돌아올 수 있으며, "정확함 (correct)"은 문맥 (Context)에 따라 달라집니다. 실제 운영 환경에서의 환각 (Hallucination) 비율은 도메인에 따라 극심하게 차이 납니다. 일반적인 어시스턴트라면 괜찮을 수 있습니다. 하지만 법률이나 의료 콘텐츠를 다루는 모든 것은 훨씬 더 높은 위험을 수반하며, 사용자에게 전달되기 전에 강력한 가드레일 (Guardrails)이 필요합니다.

저는 "AI가 정확할 것입니다"라는 말을 그만두었습니다. 대신 이렇게 말합니다. 우리가 목표로 하는 정확도 범위 (Accuracy band)는 이 정도이고, 이를 어떻게 측정할 것이며, 그 범위를 벗어나는 사례들에 대해서는 어떻게 대응할 것인지 말입니다. 인간의 검토 단계, 신뢰도 임계값 (Confidence threshold), 폴백 (Fallback) 전략 같은 것들 말이죠. 고객들은 바닥이 없는 약속보다는 알려진 실패 모드 (Failure mode)를 마주하는 것을 훨씬 더 편안하게 느낍니다. 큰 화를 입는 팀들은 자신이 지킬 수 없는 숫자를 팔아치운 팀들입니다.

예산이 실제로 투입되는 곳

또 다른 기대치의 격차는 비용이며, 이는 초기에는 보이지 않기 때문에 매우 잔혹합니다. 개념 증명 (Proof of Concept, POC)은 저렴합니다. 예산의 아주 작은 부분만을 차지하며 모두를 낙관적으로 만듭니다. 그러다 실제 운영 (Production) 단계에 들어서면 아무도 세부 항목을 나누지 않았던 청구서가 등장합니다. 모니터링 (Monitoring), 롤백 계획 (Rollback plan), 행동이 드리프트 (Drift)될 때의 재학습 (Retraining), 곤란한 시간에 시스템이 고장 났을 때의 사고 대응 (Incident response) 같은 것들 말입니다. 저는 실제 운영 비용이 POC에서 제안했던 것보다 훨씬 높게 책정되는 것을 여러 번 보았습니다. 신뢰를 손상시키는 것은 숫자 그 자체가 아니라 바로 그 '놀라움'입니다.

그래서 저는 제안서가 덜 흥미로워 보일지라도, 첫 견적 단계에서부터 지루한 부분들에 대한 비용을 공개적으로 책정합니다. 시스템을 유지하는 비용을 누락한 POC는 프로젝트의 축소판이 아닙니다. 그것은 아예 다른 프로젝트입니다.

이제 "완료"란 무엇을 의미하는가

일반적인 기능의 경우, '완료(done)'란 QA(Quality Assurance)를 통과하고 배포(ship)되었을 때를 의미합니다. 하지만 AI 기능의 경우, 저는 제가 옆에서 지켜보지 않아도 안정적으로 작동하는 시점을 '완료'로 간주합니다. 즉, 모니터링이 이루어지고, 담당자가 있으며, 답변이 잘못되었을 때의 명확한 대응 경로가 존재하며, 사용자들이 해당 기능이 할 수 있는 것과 할 수 없는 것을 이해하고 있는 상태를 의미합니다. 데모는 아이디어가 가능하다는 것을 증명했습니다. '완료'는 우리가 그것과 함께 살아갈 수 있음을 증명합니다.

이것은 Shanti Infosoft에서 제가 가장 신경 쓰는 인도(delivery)의 단계입니다. 왜냐하면 출시의 흥분이 가라앉은 후, 고객들이 매일 체감하는 부분이 바로 이 단계이기 때문입니다. 데모는 미팅을 성사시키지만, 신뢰할 수 있는 버전은 계약 갱신(renewal)을 이끌어냅니다. 제 업무의 핵심은 우리가 이 두 가지를 혼동하지 않도록 하고, 고객 또한 혼동하지 않도록 보장하는 것입니다.

데모는 항상 작동합니다. 그것을 끝이 아니라 힘든 과정의 시작으로 간주하십시오. 그러면 프로젝트의 나머지 과정이 훨씬 더 정직해질 것입니다.