기반 모델(Foundation Model)이 강력해진 덕분에, 작동하는 데모를 만드는 것은 놀라울 정도로 간단해졌습니다. API를 호출하고, 프롬프트(Prompt)를 작성하면 그럴싸한 출력이 돌아오기까지 몇 시간도 걸리지 않습니다.

문제는 그 이후입니다. 데모가 작동하는 것과 실제 서비스(Production)에서 계속 사용되는 것 사이에는 상상보다 훨씬 큰 거리가 있습니다. 그리고 그 거리의 대부분은 구현이 아니라 만들기 전의 의사결정에 의해 결정됩니다.

이 기사에서는 AI 시스템을 만들기 시작하기 전에 결정해 두는 것이 좋은 것들을 5가지로 정리합니다. Chip Huyen의 『AI 엔지니어링 (AI Engineering)』 (O'Reilly Japan)의 계획에 관한 장을 바탕으로, 실무적인 관점에서 다시 정리한 것입니다.

1. 왜 만드는가

가장 먼저 물어야 할 것은 "무엇을 만드는가"가 아니라 "왜 만드는가"입니다.

AI는 무엇에든 사용할 수 있을 것처럼 보이지만, 모든 애플리케이션에 필요한 것은 아닙니다. 오히려 AI를 도입하면 비결정론적인 출력(Non-deterministic output), 추론 비용(Inference cost), 평가의 어려움과 같은 부채를 동시에 떠안게 됩니다. 그것을 감수할 만한 이유가 있는지 먼저 확인할 필요가 있습니다.

『AI 엔지니어링』에서는 AI 프로덕트를 만드는 동기를 크게 3가지로 정리하고 있습니다.

① AI가 자사 비즈니스의 존망에 직결되는 위협이 되는 경우

경쟁상의 필요성에서 오는 것입니다. 방치하면 사업 자체가 위험해질 수 있다는 판단입니다.

② 경쟁사가 먼저 채택했을 경우의 수익·생산성 향상 기회 손실

기회 손실에서 오는 것입니다. 현재 운영(Operation)에 들어가는 비용을 AI로 절감할 수 있다는 전망이 있는 경우입니다.

③ 혁명적인 기술의 영향을 이해하기 위한 탐색적인 투자

현시점에서는 불확실성이 높더라도, 영향 범위를 파악하기 위해 투자해 둔다는 판단입니다.

여기서 주의해야 할 점은 ③은 정당한 동기이지만, ①②와는 성질이 다르다는 것입니다.

①과 ②에는 측정 가능한 근거가 있습니다. 경쟁사가 어떻게 움직이는지, 현재 공수가 몇 시간인지와 같은 것입니다. 반면 ③은 탐색 그 자체가 목적이므로, 성공의 정의가 모호한 채로 진행되기 쉽다는 구조적인 약점을 가지고 있습니다.

따라서 ③으로 시작한다면, 탐색임을 자각한 상태에서 학습 목표와 철수 기준을 미리 결정해 두어야 합니다. "무엇을 알 수 있다면 성공인가", "어디까지 해보고 모른다면 멈출 것인가". 이를 결정하지 않고 시작하면, 후술할 "어디서 멈출 것인가"의 판단을 내릴 수 없게 되어 끝없이 다듬기만 하게 됩니다.

③이 위험한 것이 아닙니다. ③을 ①②인 것처럼 실행하는 것이 위험한 것입니다.

만들기 시작하기 전에 자신들의 동기가 무엇인지 언어화해 두는 것. 그것만으로도 이후의 판단이 훨씬 수월해집니다.

2. AI에게 어떤 역할을 맡길 것인가

다음에 결정할 것은 시스템 안에서 AI가 담당할 역할입니다. 같은 "AI를 사용한 기능"이라도 역할에 따라 요구되는 품질이 완전히 다릅니다.

『AI 엔지니어링』에서는 4가지 축으로 정리되어 있습니다.

사람이 개입하는가, 완전히 자동화하는가

태스크를 완전히 자동화할 것인지, 아니면 인간이 중간에 들어갈 것인지(Human-in-the-loop).

이는 정밀도 요구사항과 직결됩니다. 인간이 확인하는 워크플로우(Workflow)라면 AI의 출력은 "초안"이면 충분합니다. 완전히 자동화한다면 오류가 그대로 외부로 나가는 것을 전제로 설계해야 합니다.

같은 정밀도의 모델이라도 이 축의 어느 쪽에 두느냐에 따라 실용성이 결정됩니다.

핵심인가, 보완인가

해당 기능에 있어 AI가 핵심인지, 아니면 보조인지.

예를 들어 생체 인증에서의 인식 처리는 핵심입니다. 그것이 없다면 기능 자체가 성립하지 않습니다. 반면 문장 작성 시의 제안(Suggest)은 보완적입니다. 틀리더라도 사용자는 무시하고 직접 쓰면 됩니다.

핵심에 가까워질수록 높은 정확성과 신뢰성이 요구됩니다. 보완적인 기능이라면 70점이라도 가치가 있지만, 핵심 기능이 70점이라면 제품으로서 성립하지 않습니다. 이 부분을 오판하면 필요한 정밀도를 과소평가한 채 개발을 진행하게 됩니다.

리액티브(Reactive)인가, 프로액티브(Proactive)인가

사용자의 조작에 반응하여 움직이는가, 시스템이 기회를 판단하여 스스로 움직이는가.

챗봇은 리액티브합니다. 사용자가 말을 걸었을 때만 응답합니다. 반면 지도 앱이 "이 앞은 정체 중입니다"라고 알림을 보내는 것은 프로액티브합니다. 사용자는 아무것도 요청하지 않았습니다.

이 차이는 품질 요구사항에 직결됩니다.

리액티브 (Reactive) 기능은 사용자가 자신의 의지로 호출하는 것이므로, 다소 정밀도가 낮더라도 "사용하지 않으면 그만"으로 끝날 수 있습니다. 하지만 프로액티브 (Proactive) 기능은 실패했을 때의 비용이 급격히 상승합니다. 요청하지도 않았는데 끼어들어서, 심지어 빗나간 제안을 한다면——이는 "정밀도가 낮다"가 아니라 "강요하는 것 같다" 혹은 "번거롭다"라고 받아들여집니다.

그리고 한 번 그렇게 인식되면, 나중에 정밀도를 높이더라도 신뢰는 돌아오지 않습니다. 사용자는 이미 읽지 않게 되었기 때문입니다.

프로액티브 기능을 만든다면, 커버리지 (Coverage)보다 정밀도 (Precision)를 우선해야 합니다. 탐지할 수 있는 범위를 넓히기보다, 내놓는 지적을 줄이더라도 적중률을 높이는 편이 낫습니다. 자동 리뷰나 자동 제안 종류가 잘 풀리지 않는 경우는 대개 이 부분을 반대로 하고 있습니다.

동적인가, 정적인가

사용자의 피드백을 받아 지속적으로 업데이트되는지, 아니면 정기적인 배치 (Batch) 업데이트에 그치는지의 문제입니다.

동적으로 만든다면 피드백을 수집하는 메커니즘과 이를 반영하는 파이프라인 (Pipeline)이 필요합니다. 이는 구현 비용뿐만 아니라 운영 비용에도 영향을 미치므로, 정말 필요한지 여부를 처음에 판단해 두어야 합니다.

3. 무엇이 경쟁 우위가 되는가

『AI 엔지니어링 (AI Engineering)』에서는 방어 가능성 (Defensibility)이라는 관점이 제시됩니다. 요컨대 경쟁 우위에 관한 이야기입니다.

당신이 쉽게 만들 수 있는 것은 경쟁사에게도 진입 장벽이 낮다는 뜻입니다.

기반 모델 (Foundation Model) 위에 애플리케이션을 구축한다는 것은, 뒤집어 말하면 누구나 같은 모델을 사용할 수 있다는 의미입니다. API를 호출하여 요약을 반환하는 도구에는 기술적인 진입 장벽이 거의 없습니다.

그렇다면 무엇이 우위가 될까요? 해당 도서에서는 세 가지를 꼽고 있습니다.

실무적으로 중요한 것은, 많은 LLM 애플리케이션에서 우위는 테크놀로지가 아니라 데이터와 디스트리뷰션에 있다는 점입니다.

같은 모델을 사용하더라도 자사의 업무 데이터로 문맥 (Context)을 제공할 수 있다면, 그것은 타사가 흉내 낼 수 없습니다. 이미 사용자가 매일 열고 있는 도구 안에 통합할 수 있다면, 단독으로 뛰어난 프로덕트보다 강력합니다.

기획을 평가할 때, "이것이 기술적으로 재미있는가"가 아니라 "이것이 데이터나 디스트리뷰션 중 하나에 기반하고 있는가"로 보면 판단이 흔들리지 않습니다.

4. 어떻게 측정하는가

이 부분이 가장 건너뛰기 쉽고, 가장 후회하게 되는 부분입니다.

만들기 시작하기 전에, 측정 가능한 기대치를 정합니다. 해당 도서에서는 고객 지원 챗봇을 예로 들어 다음과 같은 지표들을 제시합니다.

• 자동화하고 싶은 메시지의 비율
• 실제로 처리 가능해지는 메시지 수
• 도입을 통해 향상되는 응답 정밀도
• 절감할 수 있는 인적 공수 (Man-hour)

그리고 지표는 네 가지 종류로 나누어 생각합니다.

품질 지표 (Quality Metrics) — 출력이 얼마나 정확한가. 정답률, 인간의 평가와의 일치율 등

레이턴시 지표 (Latency Metrics) — 응답까지의 시간. 경험과 직결됨

비용 지표 (Cost Metrics) — 1 요청당 토큰 비용. LLM에서는 이것이 그대로 손익에 반영됨

기타 — 채택률, 유지율 등 프로덕트 고유의 것

여기서 중요한 것은, 착수 전에 현재 값을 측정해 두는 것입니다.

개선 후의 숫자만 있다면, 그것이 좋은 것인지 나쁜 것인지 아무도 알 수 없습니다. "정밀도 85%"는 원래 60%였다면 성과이지만, 원래 90%였다면 퇴보입니다. 그리고 일단 만들기 시작하면 착수 전의 상태는 더 이상 측정할 수 없습니다.

30분이라도 좋으니 대략이라도 먼저 측정해 두세요. 이것을 하느냐 안 하느냐에 따라 나중에 말할 수 있는 내용이 완전히 달라집니다.

5. 어디서 멈출 것인가

마지막으로, 가장 간과되는 논점입니다.

기반 모델이 우수하기 때문에 그럴듯하게 작동하는 데모는 짧은 시간에 만들 수 있습니다. 하지만 초기의 데모가 좋았다고 해서 몇 달 뒤에도 좋은 결과물이 나온다는 보장은 없습니다.

해당 도서에서는 이 "라스트 마일 (Last Mile)"의 어려움에 대해 인상적인 사례를 들고 있습니다.

UltraChat 논문에서는 채팅 언어 모델의 "final one mile (마지막 1마일)"을 언급하며 다음과 같이 기술하고 있습니다.

0에서 60까지 가는 여정은 쉽지만, 60에서 100으로 나아가는 것은 매우 어려워집니다.

（0에서 60으로 가는 길은 간단하지만, 60에서 100으로 나아가는 것은 극도로 어려워진다）

더 구체적인 숫자로 LinkedIn의 사례가 있습니다.

팀은 우리가 제공하고자 했던 기본 경험의 80%를 첫 한 달 만에 달성했으며, 그 후 전체 경험의 95% 완성을 넘어서기 위해 추가로 4개월을 소비했습니다.

（목표로 했던 기본 경험의 80%에는 첫 1개월 만에 도달했지만, 그 후 전체 경험의 95%를 초과하기 위해 추가로 4개월을 소비했다）

해당 기사에서는 이어서, 환각 (Hallucination)의 탐지와 억제의 어려움을 과소평가했다는 점과, 품질 점수가 초기에 급상승한 후 곧바로 정체되었다는 점을 언급하고 있습니다.

그리고 다음 문장이 이 현상의 까다로움을 잘 나타냅니다.

초기 속도가 "거의 다 왔다"라는 잘못된 느낌을 만들어냈고, 이후 매 1%의 이득을 얻을 때마다 개선 속도가 현저히 느려지면서 그것이 의욕을 꺾는 요소가 되었습니다.

（초기 속도가 "거의 다 왔다"라는 잘못된 감각을 만들어냈고, 이후 1%마다 개선 속도가 크게 떨어짐에 따라 그것이 사기를 저하시키는 요인이 되었다）

해당 기사의 다른 부분에서는 이 구조가 더 단적으로 설명되어 있습니다.

그것은 80/20 법칙을 따랐습니다. 80%까지는 빨랐지만, 마지막 20%가 우리 작업의 대부분을 차지했습니다.

（80/20 법칙을 따랐다. 80%까지는 빨랐지만, 마지막 20%에 작업의 대부분을 쏟아부었다）

즉, AI 제품 개발의 공수는 완성도에 대해 선형적이지 않습니다. 후반부로 갈수록 동일한 1%를 올리는 비용이 급증합니다. 그리고 까다롭게도, 초반의 속도가 "거의 다 왔다"라는 잘못된 전망을 만듭니다.

여기서 도출되는 실무적인 결론은 두 가지가 있습니다.

하나는, 어디서 멈출지를 미리 결정해 두는 것입니다.

"만족할 때까지"라는 기준으로 진행하면 영원히 끝나지 않습니다. 95%가 필요한 기능인지, 80% 수준에서 출시해도 되는 기능인지 결정해야 합니다. 이는 두 번째로 언급한 "필수적인가 보완적인가"의 판단과 연결됩니다. 보완적인 기능에 95%를 요구하는 것은 비용 사용 측면에서 잘못된 것입니다.

또 다른 하나는, 멈출 시점을 판단하기 위해서는 측정이 필요하다는 것입니다.

"아직 부족한 것 같다"라는 느낌만으로 진행하다 보면, 현재가 60인지 90인지 알 수 없습니다. 알 수 없기 때문에 앞으로 얼마나 더 걸릴지도 예측할 수 없습니다. 결과적으로 제품을 영원히 내놓지 못하거나, 반대로 불충분한 상태로 내놓게 됩니다.

"왠지 모르게 부족하다"의 정체는, 대부분 현재 위치를 숫자로 파악하지 못하고 있는 것입니다.

그리고 해당 저서는 또 다른 중요한 사실을 적고 있습니다. 평가 결과, 필요한 리소스가 예상되는 리턴을 상회한다고 판단된다면, 그 제품을 단념하는 것도 올바른 판단이라는 것입니다.

끝까지 만드는 것만이 성공은 아닙니다. 빠르게 손절하는 것 또한 측정이 있어야 비로소 가능한 판단입니다.

요약

만들기 시작하기 전의 체크리스트로 정리하면 다음과 같습니다.

왜 만드는가— ①존망이 걸린 위협 ②기회 손실 ③탐색적 투자. ③의 경우 학습 목표와 철수 기준을 먼저 결정할 것
AI의 역할은 무엇인가— 사람이 개입하는가/자동화, 핵심/보완, 반응적(Reactive)/주도적(Proactive), 동적/정적. 주도적이라면 커버리지보다 정밀도(Precision)
우위는 어디에 있는가— 기술이 아니라, 데이터나 배포(Distribution)에 기반하고 있는가
무엇을 어떻게 측정할 것인가— 품질, 레이턴시(Latency), 비용 등. 착수 전에 현재 값을 측정할 것
어디서 멈출 것인가— 목표 수준을 미리 결정할 것. 60→100의 비용은 0→60과 완전히 다름

이 모든 것은 구현에 관한 이야기가 아닙니다. 하지만 구현을 시작한 후에는 결정하기 어려운 것들뿐입니다.

데모를 쉽게 만들 수 있는 시대이기 때문에, 만들기 전에 멈춰 서서 고민하는 시간의 가치가 더욱 높아지고 있다는 것이 이 책을 읽으며 느낀 점이었습니다.

참고

• Chip Huyen, 『AI 엔지니어링 — 기반 모델을 이용한 AI 애플리케이션 개발의 기초와 실전』 오라이リー・ジャパン, 2025년
• Musings on Building a Generative AI Product — LinkedIn Engineering Blog, 2024
• Lessons from LinkedIn's generative AI application development — CIO Dive
• Ding et al., Enhancing Chat Language Models by Scaling High-quality Instructional Conversations — arXiv:2305.14233, EMNLP 2023

Discussion