AI 기능을 단순히 ‘붙이는’ 것과 실서비스 흐름에 ‘연결하는’ 것은 다른 작업입니다. 데모는 됐는데 실제 운영으로 이어지지 않는 이유는 모델이 부족해서가 아니라, 그 모델이 들어갈 자리를 준비하지 않은 채 기능부터 붙였기 때문인 경우가 많습니다.
최근 몇 년간 가장 많이 본 시나리오는 이렇습니다. 모델 API를 연결해 데모를 만들고, 시연이 잘 되니 그대로 출시 일정을 잡습니다. 그런데 막상 실서비스에 올리면 답변 품질이 들쭉날쭉하고, 외부 시스템과의 연결은 매번 사람이 손으로 메우고, 문제가 생겨도 어디서 어떻게 잘못됐는지 추적이 안 됩니다. 결국 “AI 기능이 안 붙는다”가 아니라 “붙였는데 운영이 안 된다”는 문제로 바뀝니다.
원인은 거의 같습니다. AI 모델을 점으로만 본 것입니다. 모델 호출은 한 점이지만, 실제 제품 안에서 그 점은 입력을 받기 전 단계, 결과를 검증하는 단계, 운영팀이 들여다볼 수 있는 단계와 연결되어 있어야 합니다. 그 자리를 만들지 않은 채 점만 찍으면 데모에서 멈춥니다.
SL:IT은 AI 기능이 들어갈 자리를 네 단계로 봅니다. 모델 선택보다 먼저 이 네 자리가 명확해야 합니다.
이 네 자리가 비어 있으면 모델 성능이 아무리 좋아져도 운영 시점에 같은 문제가 반복됩니다. 반대로 네 자리만 비워둔 상태로 시작해도, 모델은 나중에 더 적합한 것으로 갈아끼울 수 있습니다.
AI 모델은 6개월 단위로 바뀝니다. 어제 좋다고 했던 조합이 내일 더 나은 조합으로 교체되는 게 일상입니다. 그래서 제품 구조를 모델에 종속시키지 않는 것이 중요합니다. 호출 계층을 한 곳에 모아두고, 모델 식별자를 설정 값으로만 다루면 모델 교체가 ‘설정 변경’ 수준으로 떨어집니다.
반면 프롬프트와 모델 호출이 비즈니스 로직 곳곳에 박혀 있으면, 모델 한 번 바꾸려고 코드 수십 군데를 손봐야 합니다. 단기에는 빨라 보여도 6개월쯤 지나면 “다시 짜는 게 빠르겠다”는 결론에 도달합니다.
| 입력 | 데모는 정제된 예시. 실서비스는 정제되지 않은 사용자 발화·문서·이미지가 섞여 들어옴 |
|---|---|
| 모델 호출 | 데모는 단일 모델. 실서비스는 비용·속도·신뢰성에 따라 모델을 분기해야 함 |
| 실패 처리 | 데모는 잘 되는 케이스만. 실서비스는 모델이 실패하거나 외부 API가 죽었을 때의 흐름이 필요 |
| 로그 | 데모는 콘솔. 실서비스는 호출 단위 감사 로그와 비용 집계가 필요 |
| 접근 권한 | 데모는 1인. 실서비스는 운영팀·고객지원·관리자가 각자의 화면이 필요 |
실서비스에서는 한 모델에게 통째로 일을 맡기는 대신 역할을 쪼갭니다. 분류하는 모델, 답변하는 모델, 검증하는 모델, 요약하는 모델은 같은 공급자라도 각각 다른 프롬프트와 다른 모델 등급으로 부르는 편이 더 안정적이고 비용 효율도 좋습니다.
역할을 쪼개면 부수적으로 디버깅이 쉬워집니다. “답이 이상하다”가 아니라 “분류 단계에서 잘못 분기됐다”거나 “검증 단계에서 통과시키지 말았어야 했다”처럼 문제 지점이 좁아집니다.
AI 기능이 붙은 제품에서 가장 중요한 건 화려한 모델이 아니라 호출 한 건 한 건의 흔적입니다. 어떤 입력을 받았고, 어떤 모델을 어떤 비용으로 호출했고, 결과가 어땠고, 사용자에게 무엇이 전달됐는지가 남아 있어야 합니다.
이 흔적이 있으면 비용 폭주를 탐지할 수 있고, 품질이 떨어진 구간을 사후에 재현할 수 있고, 모델 교체 후 A/B 비교가 가능합니다. 흔적이 없으면 사고가 났을 때 “원인을 모르겠다”에서 멈춥니다.
SL:IT은 AI 프로젝트를 시작할 때 모델 선택보다 위 네 자리를 먼저 잡습니다. 멀티 모델 호출 계층, 역할이 분리된 에이전트 흐름, 외부 시스템 연동 어댑터, 호출 단위 감사 로그를 같은 제품 안에서 연결합니다. 그래서 모델이 바뀌어도, 운영팀이 바뀌어도, 트래픽이 바뀌어도 제품이 그대로 굴러갑니다.
“AI 기능 하나 붙여주세요”는 자주 듣는 요청이지만, 실제로는 그 한 기능이 들어가서 제품 안에서 작동하려면 적어도 네 군데가 같이 움직여야 합니다. 처음부터 그 네 자리를 같이 정리하는 편이, 데모 이후 다시 갈아엎는 비용보다 거의 항상 쌉니다.
