개발 외주를 맡기기 전에 알아야 할 LLM의 5가지 한계

한줄 요약

AI 기능 개발을 외주로 맡기기 전, LLM의 구조적 한계를 모르면 돈도 시간도 낭비된다.

앱 개발 외주나 웹 개발 외주를 진행할 때 "AI 기능 넣어주세요"라는 요청이 부쩍 늘었다. 그런데 막상 개발이 끝나고 나서야 "왜 우리 회사 정책은 모르죠?", "왜 답이 매번 다르죠?", "왜 이렇게 비용이 많이 나오죠?" 같은 질문이 쏟아진다. 이런 문제 대부분은 LLM을 어떻게 써야 하는지에 대한 기본 이해가 없을 때 발생한다. 개발사가 설명해야 할 책임도 있지만, 의뢰하는 쪽도 최소한의 판단 기준은 갖고 있어야 한다.

AI 기능 개발 전에 왜 LLM 구조를 알아야 하나

LLM은 다음에 올 단어를 확률적으로 예측하는 방식으로 동작한다. 마법처럼 "이해하고" 대답하는 게 아니다. 이 차이를 모르면, 외주 개발사와 대화할 때 요구사항 자체가 틀리게 된다. "AI가 우리 고객 데이터를 학습해서 맞춤 답변을 주면 되잖아요"라는 식의 요청이 대표적이다. 이건 기술적으로 전혀 다른 이야기다.

토큰 단위 과금 — 한국어 서비스는 예상보다 비싸다

LLM은 문장을 통째로 처리하지 않는다. 의미 단위보다 작게 쪼갠 "토큰"이라는 단위로 처리하고, 비용도 이 단위로 청구된다. 문제는 한국어가 영어에 비해 같은 내용을 표현하는 데 토큰을 더 많이 소비한다는 점이다. 단순하게 말하면, 같은 기능을 만들어도 한국어 서비스가 영어 서비스보다 API 비용이 더 나온다.

앱 개발 외주를 의뢰할 때 "GPT 붙이면 얼마예요?"라고 물었을 때, 개발사가 글로벌 사례 기준으로 견적을 내면 실제 운영비와 차이가 날 수 있다. 한국어 기반 서비스인지, 대화 길이가 얼마나 되는지에 따라 월 운영비가 몇 배씩 달라진다는 점을 초반 기획 단계에서 짚어야 한다.

컨텍스트 한계 — AI는 대화를 "기억"하지 않는다

LLM에는 장기 기억이 없다. 대화 창 안에서 주고받은 내용만 참고할 수 있고, 그 범위를 넘어가면 앞서 한 이야기는 없는 것처럼 처리된다. "저번에 말씀드렸던 건데요"가 AI에게 통하지 않는 이유다.

그러면 "우리 앱은 사용자 이력을 기반으로 맞춤 상담을 해줬으면 해요"라는 요구사항은 어떻게 구현하나. AI가 알아서 기억하는 게 아니라, 사용자 정보를 데이터베이스에 저장해 두고 매 대화마다 AI에게 "이 사람은 이런 이력을 가진 고객입니다"라고 전달하는 구조를 따로 설계해야 한다. 이게 빠진 채로 개발이 진행되면, 완성된 제품이 사용자 이력을 전혀 반영하지 못한다.

RAG 없이 회사 정보를 아는 AI는 없다

LLM은 인터넷에 공개된 정보로 학습한 모델이다. 우리 회사 서비스 약관, 환불 정책, 내부 매뉴얼 같은 내용은 모른다. 그런데도 그냥 GPT를 붙이면, AI는 "일반적으로 이런 경우엔 이렇습니다"라는 식으로 그럴듯한 답을 만들어낸다. 사용자는 그게 회사 공식 답변인 줄 안다. 이게 AI 챗봇 관련 분쟁의 상당수를 만드는 구조다.

이 문제를 해결하는 방법이 RAG(검색 증강 생성)다. 사용자가 질문하면 회사 문서에서 관련 내용을 먼저 검색하고, 그 내용을 AI에게 건네주면서 "이 자료를 기반으로 답해줘"라고 지시하는 방식이다. 고객 응대 챗봇, 내부 문서 검색, FAQ 자동 응답 — 이런 기능을 개발한다면 RAG 구조가 필요한지를 반드시 짚어야 한다. 개발 외주 의뢰 시 "RAG는 들어가나요?"라고 물어보는 것 자체가 의미 있는 기준점이 된다.

Temperature와 일관성 — 용도에 따라 설정이 달라야 한다

AI가 매번 다른 답을 내놓는 건 버그가 아니다. Temperature라는 설정값으로 조절 가능한, 의도된 확률적 특성이다. 값을 낮추면 답이 일관되고 예측 가능해지고, 높이면 다양하고 창의적인 결과가 나온다.

고객 상담 챗봇처럼 같은 질문에 항상 같은 수준의 답이 나와야 하는 기능과, 마케팅 문구를 여러 개 생성하는 기능은 설정이 달라야 한다. 이걸 기본값으로 두고 개발하면 결과물의 품질이 용도에 맞지 않을 수 있다. 어떤 기능을 만드는지에 따라 이 설정을 명시적으로 요구사항에 담아야 한다.

에이전트 — AI가 직접 행동하면 책임 설계도 달라진다

최근 외주 개발 요청 중 눈에 띄게 늘어난 것이 "AI가 직접 뭔가를 해줬으면 해요"라는 형태다. 메일을 쓰는 게 아니라 직접 보내거나, 일정을 제안하는 게 아니라 직접 등록하거나. 이런 구조를 에이전트라고 부른다. LLM에게 외부 시스템을 직접 건드릴 수 있는 권한을 주는 방식이다.

기능이 강력해지는 만큼 책임 설계도 함께 커진다. AI가 실수로 잘못된 주문을 처리하거나, 삭제하면 안 되는 데이터를 지운다면 어떻게 되나. 사람이 개입하는 확인 단계를 어디에 둘 것인지, 되돌릴 수 없는 행동에는 어떤 제한을 걸 것인지 — 이런 설계가 기획 단계에서 빠지면 나중에 사고로 이어진다. 에이전트 기반 기능을 포함한 개발 외주를 진행할 때는 "오작동 시 어떻게 되는가"를 반드시 사전에 정의해야 한다.