비즈니스 문제부터 실제로 출시 가능한 LLM까지의 5단계

제가 지켜본 대부분의 LLM 프로젝트가 실패한 것은 모델 때문이 아니었습니다. 그들은 누군가가 모델을 먼저 선택했기 때문에 실패했습니다.

그것이 바로 전체적인 병리 현상입니다. 팀은 벤치마크 테이블을 읽고, 모델을 결정하고, 그 후에야 그것에 맞춰진 문제를 찾으려고 합니다. 6주가 지난 후에는 아무도 가격을 매기거나 평가하거나 지원팀에 넘겨줄 수 없는 데모만 남게 됩니다. 작업 자체는 실제였지만, 순서가 잘못된 것입니다.

이러한 상황을 피하는 순서가 있으며, 복잡하지 않습니다: 이해 (understand), 준비 (prepare), 선택 (select), 맞춤화 (customize), 생산화 (productionize). 다섯 단계입니다. 모델 선택은 맨 앞에 있는 것이 아니라 중간에 위치하며, 그 지점에 도달할 무렵에는 결정이 대부분 내려져 있습니다.

1. 이해 (Understand)

무엇보다 먼저, 비즈니스가 실제로 무엇을 원하는지 그리고 그것을 어떻게 알 수 있을지를 문서로 작성해야 합니다.

여기서 팀들이 보통 건너뛰는 두 가지가 있습니다.

모델 지표와 비즈니스 지표를 분리하세요. 모델 중심의 지표는 노트북에서 출력되는 것들입니다: 정확도 (accuracy), F1, 퍼플렉서시 (perplexity), BLEU, 정답 일치율 (exact match). 반면, 비즈니스 중심의 지표는 디렉터가 신경 쓰는 것입니다: 회피된 티켓 수 (tickets deflected), 분석가당 절약 시간 (hours saved per analyst), 인간 개입 없이 처리된 인보이스 수, 세션당 수익 (revenue per session). 이들은 같은 숫자가 아니며 항상 함께 움직이지도 않습니다. 저는 분류기(classifier)가 F1 점수를 4점 올렸지만, 실제로는 사람이 처리할 필요가 없었던 클래스에서만 상승했기 때문에 회피된 티켓 수는 줄어드는 것을 본 적이 있습니다.

둘 다 고려하세요. 모델 지표는 개발 과정 중 방향을 잡는 데 사용됩니다. 비즈니스 지표는 그것을 구축할 가치가 있었는지 결정하는 기준입니다.

무엇이든 약속하기 전에 데이터를 살펴보세요. 양, 질, 형식입니다. 레이블링된 예제 2,000개는 20개와는 다른 프로젝트이며, 스캔된 PDF 폴더는 깨끗한 데이터베이스 내보내기(database export)와는 다른 프로젝트입니다. 만약 레이블이 가이드라인 없이 2년 동안 세 명의 다른 사람에게서 나왔다면, 먼저 레이블링 프로젝트를 하고 그 후에 LLM 프로젝트를 해야 합니다.

그다음은 비기능적 요구사항(non-functionals)인데, 여기에 가장 정직한 제약 조건들이 숨어 있습니다:

• 호출당 비용(Cost per call) 및 일일 호출량(calls per day). 1/10센트는 하루에 4만 번 실행될 때까지는 아무것도 아닙니다.
• 지연 시간(Latency). 사용자가 기다리는 무언가는 밤새 실행되는 것과는 다르게 작동합니다.
• 규모(Scale). 평균이 아닌 최대 동시성(Peak concurrency)입니다.
• 데이터 상주 및 개인 정보 보호(Data residency and privacy). 이 항목은 전체 공급업체를 조용히 제거할 수 있으므로, 60일째가 아니라 첫날에 알아내야 합니다.
• 예산 및 일정(Budget and timeline). 구축 비용과 운영 비용 모두이며, 이는 별도의 예산이고 종종 별도의 소유자가 있습니다.

이 섹션을 채울 수 없다면, 어떤 것도 평가할 준비가 되지 않은 것입니다. 여전히 탐색(discovery)을 하고 있는 것이고, 그것은 괜찮습니다. 그냥 그렇게 부르세요.

2. 준비하기 (Prepare)

이제 여러분은 찾아보게 되고, 가장 먼저 살펴봐야 할 것은 LLM이 정말 필요한지 여부입니다.

기존 및 비(非)LLM 솔루션을 조사합니다. 정규 표현식(regular expression), 조회 테이블(lookup table), 표 형식 특징에 대한 그래디언트 부스팅 트리(gradient-boosted tree over tabular features), 이미 라이선스를 보유한 공급업체 제품 등입니다. 이것은 LLM에 대한 비관론이 아닙니다. 여러분에게는 기준선(baseline)이 필요하며, 지루한 기준선이야말로 프로젝트 전체에서 가장 유용한 객체입니다. 그것은 오늘날

그렇다면 벤치마크, 리더보드, 그리고 아레나(arena)가 있다 — 건강한 의심을 품으면서 말이다. 공개된 벤치마크는 오염되어 있고, 리더보드는 표류하며, 아레나는 채팅창에서 인간이 선호하는 것을 측정할 뿐인데, 이는 구매 주문서에서 항목별 라인 아이템을 추출하는 것과는 아무 관련이 없을 수 있다. 이들을 후보군을 추리는 데 사용하라. 결정을 내릴 때는 절대 사용하지 마라. 중요한 점수는 당신의 후보들이 당신의 데이터에서 얻는 점수이며, 지금 바로 그것을 구축할 것이다.**

데이터를 큐레이션하라: 정리하고, 전처리하고, 분할하라. 프롬프팅만 하는 프로젝트에서도 별도로 보관된 평가 세트(held-out evaluation set)가 필요하다. 특히 프롬프팅만 하는 프로젝트에서는 더욱 그러한데, 왜냐하면 프롬프트 반복 작업은 당신이 계속 바라보는 예시들로 과적합(overfits)되기 때문이다. 지금 테스트 세트를 고정하고, 그것에 대한 의견을 갖기 전에, 그리고 마지막까지는 절대 보지 마라.

당신의 실제 엣지 케이스(edge cases)를 다루는 신중하게 선택된 백 개의 예시가 열 번의 스크래핑된 행보다 낫다. 이상한 것들을 의도적으로 가져와라: 빈 입력, 잘못된 언어, 자신의 전체 이메일 스레드를 붙여넣은 고객, 벨기에 지사에서만 사용하는 형식이 잘못된 숫자 형식 같은 것들.

3. 선택(Select)

이것은 모두가 프로젝트의 전부라고 생각하는 단계이며, 이제는 거의 기계적이다.

당신의 후보군을 가져와라. 방금 고정한 평가 세트에 대해 실행해 보라. 지루한 기준선(baseline)과 비교하라. 비록 질 것이 확실하더라도 저렴하고 작은 모델도 포함시켜라 — 그것은 충분히 자주 이기기 때문에 20분을 들일 가치가 있고, 만약 진다면 더 많은 투자를 할 수 있는 방어 가능한 이유를 얻게 된다.

유지할 가치가 있는 두 가지 습관:

모든 실행을 기록하라. 모델 버전, 프롬프트 버전, 매개변수(parameters), 비용, 지연 시간(latency), 실제 출력물까지. 3주 후 누군가 왜 이것을 선택했는지 물어볼 것이고,

단일 모델을 습관적으로 선택하지 마십시오. 라우팅(Routing)은 합법적인 설계 방식입니다. 작고 빠른 모델이 쉬운 80%의 사례를 처리하고, 더 큰 모델이 나머지 부분을 담당하게 하는 식입니다. 비용이 급격히 떨어지며, 어쨌든 라우팅을 하려면 신뢰도 신호가 필요합니다.

만약 파인튜닝(fine-tuning)을 한다면, 이곳에서 훈련하고 검증하는 곳입니다. 그렇지 않다면, 이곳에서 '파인튜닝이 필요하지 않다'고 결론 내리는 것이며, 이는 실제 결과이고 입 밖에 낼 가치가 있습니다.

4. 커스터마이징(Customize)

네 가지 레버가 있으며, 이들은 동등하지 않습니다. 세 개는 추론 시간(inference time)에 작용하고, 하나는 학습 시간(training time)에 작용합니다.

**프롬프팅(Prompting)**은 항상 첫 번째입니다. 변경할 수 있는 가장 저렴한 것이고 테스트하기 가장 빠릅니다. 퓨샷 예시(Few-shot examples), 명시적인 출력 스키마(explicit output schema), 역할과 제약 조건에 대한 명확한 설명 등이 있습니다. 팀들은 일상적으로 이것을 건너뛰고 파인튜닝으로 넘어가다가, 결국 더 나은 프롬프트가 무료로 격차의 대부분을 메웠다는 것을 발견합니다.

**RAG(Retrieval-Augmented Generation)**는

**파인튜닝(Fine-tuning)**은 모델의 가중치(weights)를 변경하는 유일한 방법이며, 추론 시간(inference time)이 아닌 학습 시간(training time)에 발생하는 유일한 과정입니다. 일관된 톤, 엄격한 출력 형식, 특정 도메인의 어휘와 관습 등 '형식'을 갖추는 데 적합합니다. 하지만 사실 정보(facts)를 다루기에는 부적절한데, 왜냐하면 인덱스 업데이트가 몇 초 만에 같은 작업을 수행할 수 있기 때문에 사실을 업데이트하기 위해 재학습하는 것은 터무니없기 때문입니다. 또한 이 과정은 모델의 라이프사이클 전체(버전 관리, 재학습, 드리프트, 저장)를 사용자가 소유하게 만듭니다. 이것이 파인튜닝을 피해야 할 이유는 아닙니다. 오히려 앞선 세 가지 방법만으로는 충분하지 않다는 것을 확신할 수 있는 이유가 됩니다.

순서는 의도적입니다. 프롬프트(Prompt) → 검색 증강 생성(Retrieval) → 에이전시 추가(Agency) → 파인튜닝(Fine-tune) 순서로 진행됩니다. 각 단계는 구축 비용과 유지 보수 비용이 더 많이 들고, 되돌리기도 더 어렵습니다.

5. 프로덕셔나이즈 (Productionize)

작동하는 노트북(notebook)과 실제로 작동하는 서비스 사이의 간극에 대부분의 시간이 소요됩니다.

모델과 다른 모든 요소 사이에 API를 정의합니다. 요청은 들어오고 구조화된 응답이 나가는, 깨끗한 경계가 있어야 나중에 모델을 건드리지 않고도 교체할 수 있습니다. 모델은 반드시 바뀔 것입니다. 더 저렴하거나 더 좋은 것이 몇 달에 한 번씩 출시되는데, 제공업체의 SDK를 세 개의 컨트롤러에 직접 연결해 놓은 팀은 이를 활용할 수 없습니다.

호스팅 및 배포를 결정합니다. 벤더 API(Vendor API), 관리형 엔드포인트(managed endpoint), 또는 자체 GPU 중 선택해야 합니다. 이는 선호도에 따른 것이 아니라, 1단계에서 정의한 비기능적 요구사항(non-functionals)을 따릅니다. 데이터 거주지(Data residency), 지연 시간 최소치(latency floor) 및 처리량(volume)이 이들 사이의 결정을 좌우합니다.

운영 표면(operational surface)을 관리합니다. 급증하는 트래픽에 대한 확장성(Scaling)과 큐잉(Queueing) 처리가 필요합니다. 제공업체는 실패할 수 있으므로 타임아웃 및 재시도 로직이 필수적입니다. 지연 시간, 오류율, 비용에 대한 모니터링을 수행하고, 특히 비용에 대한 경고가 필요합니다. 측정되는 API에 대한 재시도 루프는 값비싼 종류의 버그입니다. 프롬프트 주입(prompt injection)과 같은 보안 문제 처리, 특히 모델 출력이 실행하는 무언가에 연결되는 모든 곳에서 중요합니다. 규정 준수 및 감사 로깅(Compliance and audit logging)이 필요하며, 누가 잘못된 답변을 보고할 때 추측하는 대신 요청 자체를 찾을 수 있도록 입력과 출력을 포착하는 관찰 가능성(Observability)이 필수적입니다.

1단계의 비즈니스 지표를 대상으로 평가(evals)를 실행하세요. 이것이 바로 루프를 완성하는 과정입니다. 개발 중에 추적했던 오프라인 F1 점수가 아닙니다. 대신, 방어된 티켓 수, 절약된 시간, 처리된 송장 같은 실제 결과물이어야 합니다. 모델 지표 대시보드는 안심하게 만들지만, 프로젝트가 실제로 가치를 창출했는지에 대해서는 거의 알려주지 못합니다.

그리고 계속 측정하세요. 입력 데이터(Inputs)는 표류하고(drift), 제공업체들은 당신의 밑단에서 모델을 업데이트하며, 3월에 작동했던 것이 9월에는 조용히 성능이 저하될 수 있습니다. 재평가 일정을 잡으세요. 점검이 필요할 때를 알리는 임계값(threshold)을 설정하세요. 누군가가 우연히 알아차릴 때가 아니라, 이 임계값이 발동했을 때 모델을 재학습시키거나 미세 조정(re-tune)해야 합니다.

중요한 부분

다섯 단계를 다시 읽어보고 첫 번째 단계와 마지막 단계에 공통점이 무엇인지 주목하세요. 1단계는 비즈니스 지표를 정의합니다. 5단계가 그것을 측정합니다. 그 사이의 모든 것은 기계적인 과정일 뿐입니다.

이것이야말로 실제 핵심 역량(discipline)입니다. 전략은 실제로 모델을 선택하는 것에 관한 것이 아닙니다. 모델은 당신이 솔직하게 적어내면 제약 조건에서 벗어나려는 경향이 있습니다. 중요한 것은 비즈니스가 인지할 수 있는 용어로 성공이 무엇을 의미하는지 사전에 결정하고, 그리고 그것을 확인할 의지가 있다는 것입니다.

1단계를 건너뛰어도 무언가를 출시할 수는 있을 겁니다. 다만, 그것이 작동했는지 누구에게도 말할 수 없을 뿐입니다.