LLM이 꼭 필요한 기술처럼 느껴질 때, 그 느낌을 검증하는 방법
제품 기획 회의에서 "AI를 넣어야 하지 않나요?"라는 말이 나오는 방식을 생각해보면, 보통은 질문이 아니라 확인 요청이다. 경쟁사가 GPT 기반 기능을 출시했거나, 임원이 데모를 보고 왔거나, 채용 공고에 LLM이 들어가야 한다는 압박이 있다. 그 자리에서 "정말 필요한가요?"라고 되묻기가 어렵다.
하지만 요구사항 단계에서 이 질문을 건너뛰면, 나중에 훨씬 비싼 대가를 치른다. 기술이 먼저 결정되고 문제가 뒤따라가는 구조가 되기 때문이다.
"다들 쓰니까"는 기술 선택 근거가 될 수 없다
LLM 도입 논의에서 가장 흔한 오해는 이 기술이 어떤 문제에도 자연스럽게 들어맞는다는 전제다. 언어를 다루고, 텍스트를 생성하고, 질문에 답할 수 있다는 사실이 "우리 제품에도 필요하다"는 결론으로 너무 빨리 이어진다.
현실은 다르다. LLM은 특정 조건에서 잘 작동하는 도구다. 입력이 비정형이고 예외가 많으며 맥락 해석이 필요한 상황, 규칙 기반 시스템으로는 커버하기 어려운 변수가 많은 상황에서 강점을 보인다. 반대로 입력과 출력이 명확하게 정의되고, 결과의 일관성이 중요하고, 오답의 비용이 높은 상황에서는 단순한 분류 모델이나 검색 알고리즘, 규칙 엔진이 더 안정적이고 저렴하게 문제를 해결한다.
"우리가 해결하려는 것이 언어 문제인가, 아니면 언어처럼 보이는 다른 문제인가"를 먼저 구분해야 한다.
문제를 정의하기 전에 기술을 고르면 생기는 일
요구사항 단계에서 LLM을 전제로 설계를 시작하면, 팀은 도구의 특성에 맞춰 문제를 재정의하게 된다. 원래 풀려던 문제가 아니라 LLM이 잘할 수 있는 문제를 풀게 되는 것이다. 이 과정은 대부분 눈에 띄지 않는다.
예를 들어, 고객 문의를 분류하고 담당자에게 배정하는 시스템을 만들려고 했다면, 이 문제는 레이블이 달린 과거 데이터만 충분하면 간단한 분류 모델로 해결할 수 있다. 그러나 LLM을 전제로 시작하면 팀은 프롬프트 설계, 출력 파싱, 환각 방지 로직, API 비용 관리 등 원래 문제와 거리가 먼 작업에 시간을 쓰게 된다. 완성된 시스템은 더 복잡하고, 더 비싸고, 더 예측하기 어렵다.
이런 방향 전환이 일어났다는 조기 신호가 있다. 팀이 "LLM이 이 케이스를 어떻게 처리하게 할까"를 논의하기 시작할 때, 원래라면 "이 케이스를 어떻게 처리할까"를 논의해야 한다. 주어가 기술이 되는 순간, 설계의 주도권이 팀에서 도구로 넘어간다.
대체 기술 검토를 먼저 하는 것이 LLM 도입을 막는 게 아니다
LLM 대신 다른 기술을 검토하자고 하면 "AI에 부정적인 입장"으로 읽히기 쉽다. 하지만 이 검토의 목적은 LLM을 막는 것이 아니라, 선택의 근거를 확인하는 것이다.
검토 순서는 단순하다. 먼저 문제를 행동 단위로 정의한다. 사용자가 무엇을 하려는지, 시스템이 어떤 출력을 내야 하는지를 구체적으로 쓴다. 그다음 그 출력을 만드는 데 필요한 판단이 얼마나 복잡한지를 따진다. 규칙으로 쓸 수 있는가, 아니면 맥락마다 달라지는가. 마지막으로 그 복잡성을 감당하는 데 필요한 유연성이 LLM 수준인지, 아니면 더 좁은 도구로도 충분한지를 본다.
이 과정에서 LLM이 유일한 선택지로 남으면, 그때 LLM을 선택하면 된다. 그 근거가 있으면 내부에서 반론이 나와도 방어할 수 있고, 설계 결정도 일관성을 유지할 수 있다.
LLM이 실제로 적합한 조건과 그렇지 않은 조건
모든 도구에는 잘 작동하는 범위가 있다. LLM도 마찬가지다. 다음은 편집 분석으로, 특정 수치나 보장이 아니라 일반적인 판단 기준으로 봐야 한다.
LLM이 강점을 보이는 조건: 입력 형식이 매우 다양하고 사전에 정의하기 어려울 때. 사용자가 자유롭게 입력한 텍스트를 구조화된 응답으로 바꿔야 할 때. 언어의 뉘앙스나 맥락이 결과에 영향을 미칠 때. 규칙으로 명시하기 어려운 판단이 반복적으로 필요할 때.
다른 방식이 더 적합한 조건: 입력과 출력의 형식이 미리 정의되어 있을 때. 결과의 일관성과 감사 가능성이 요구될 때. 오답이 바로 사용자 피해나 규정 위반으로 이어질 때. 처리량이 많고 단가를 낮춰야 할 때. 기존 데이터에 레이블이 붙어 있고 분류 범위가 좁을 때.
후자의 조건에서는 키워드 매칭, 결정 트리, 간단한 분류 모델, 또는 검색 인덱스가 더 빠르고 예측 가능하게 문제를 해결한다. 이 사실이 불편하게 느껴진다면, 그건 기술 선택이 이미 결론부터 나온 상태라는 신호일 수 있다.
요구사항 단계에서 확인해야 할 질문들
LLM 도입을 검토하는 팀이 요구사항 단계에서 명확히 해두어야 할 질문들이다. 이 질문에 답하기 어려우면, 기술 선택을 논의하기 전에 문제 정의부터 다시 해야 한다.
첫째, 이 기능이 해결하려는 사용자의 행동 문제를 한 문장으로 쓸 수 있는가. "AI 챗봇을 만든다"가 아니라 "사용자가 지원 문서를 찾지 못해서 이탈한다"처럼 행동과 결과로 쓸 수 있어야 한다.
둘째, 그 문제를 LLM 없이 해결하면 어떤 한계가 생기는가. 한계를 말할 수 없다면, LLM이 필요한 이유도 말할 수 없다.
셋째, 이 기능의 출력이 틀렸을 때 사용자나 사업에 어떤 일이 벌어지는가. LLM은 확률적 시스템이다. 오답이 허용 가능한 범위인지, 아니면 오답을 원천 차단해야 하는지에 따라 설계 방향이 달라진다.
넷째, 운영 비용을 어떤 지표로 관리할 것인가. 토큰 단가, 응답 지연, 오류율 중 어떤 기준이 이 제품에서 가장 중요한가.
이 네 가지 질문에 답이 없으면, 기술 선택보다 앞서 해야 할 일이 남아 있다는 뜻이다.
