전통 ML과 파운데이션 모델 고르기

시험 가이드 v1.1이 도메인 1에 새로 넣은 목표가 이것입니다. 생성형 AI가 나온 뒤로 「그럼 전부 파운데이션 모델로 하면 되는가」라는 물음이 실제 업무에서 자주 나왔고, 시험은 그렇지 않은 자리를 고를 수 있는지를 묻습니다. 문항은 대개 회사 상황을 서술한 뒤 「가장 알맞은 접근은」이라고 묻고, 보기에 전통 ML 쪽 하나와 파운데이션 모델 쪽 하나를 나란히 놓습니다. 저울에 올릴 추가 무엇인지 알아야 갈립니다.

두 갈래가 실제로 무엇이 다른가

전통 ML 모델은 과제 하나를 위해 우리 데이터로 처음부터 학습시킨 모델입니다. 이탈 예측 모델은 이탈만 예측하고 불량 판정 모델은 불량만 판정합니다. 파운데이션 모델(FM)은 방대한 데이터로 미리 학습되어 여러 과제에 두루 쓰이는 범용 모델이고, 우리는 대개 학습을 하지 않고 프롬프트만 바꿔 씁니다.

표의 마지막 세 줄이 시험에서 저울을 기울이는 추입니다. 위 다섯 줄은 「무엇을 할 수 있는가」이고 아래 세 줄은 「무엇을 감당해야 하는가」인데, 문항이 답을 심어 두는 자리는 거의 언제나 아래쪽입니다.

규제와 설명가능성이 저울을 기울일 때

먼저 두 낱말을 갈라 둡니다. 해석가능성(interpretability)은 모델의 구조 자체가 들여다보여서 왜 그 값이 나왔는지 바로 읽히는 성질입니다. 선형 회귀의 계수, 결정 트리의 갈림길이 그렇습니다. 설명가능성(explainability)은 안이 복잡해 그대로는 못 읽는 모델에 대해 왜 이 결과가 나왔는지 사후적으로 근거를 붙이는 것입니다. 어떤 입력 특성이 결과를 얼마나 밀었는지 계산해 보여 주는 방식이 대표적이고, AWS에서는 Amazon SageMaker Clarify가 그 자리에 있습니다.

규제 우려(regulatory concerns)가 있는 업무는 이 성질을 요구합니다. 신용 거절 사유를 고객에게 알려야 하는 대출 심사, 보험 인수, 의료 판정, 채용 심사가 그렇습니다. 감독 기관이 요구하는 것은 정확도가 높다는 사실이 아니라 개별 건마다 왜 그렇게 판정했는지이고, 여기에 더해 감사 시점에 같은 입력으로 같은 결과가 재현되어야 합니다.

전통 ML이 이런 자리에서 유리한 이유가 여기 있습니다. 특성이 몇십 개로 정해져 있고 각 특성의 기여도를 숫자로 낼 수 있으며, 학습된 모델은 같은 입력에 같은 값을 냅니다. 반면 파운데이션 모델은 자유로운 글을 내고, 설정에 따라 같은 질문에 다른 문장을 낼 수 있으며, 「소득 대비 부채 비율이 이 값을 넘어서 거절했다」 같은 감사 가능한 근거를 구조적으로 내주지 못합니다.

다만 파운데이션 모델에 근거를 붙이는 방법이 아예 없는 것은 아닙니다. 답을 만들 때 사내 문서에서 찾은 대목을 함께 제시하도록 하는 방식(그라운딩)이 그것이고, 이때 근거는 「모델이 왜 그렇게 판단했는가」가 아니라 「어느 문서를 보고 말했는가」입니다. 규제가 요구하는 것이 출처 제시라면 이것으로 충분하지만, 개별 판정의 산출 근거라면 부족합니다. 문항이 요구하는 것이 둘 중 어느 쪽인지 읽어야 하는 이유입니다.

운영 제약 — 지연·비용·인프라

지연부터 봅니다. 파운데이션 모델은 답을 토큰 하나씩 이어 내므로 응답이 길어질수록 시간이 늘어납니다. 광고 입찰이나 결제 승인처럼 밀리초 단위로 답해야 하는 자리는 전통 ML의 자리이고, 사람이 읽을 글을 내는 자리는 몇 초를 기다릴 수 있으니 파운데이션 모델의 자리입니다.

비용의 구조도 다릅니다. 파운데이션 모델을 API로 부르면 대개 주고받은 토큰 수로 요금이 매겨지므로 건수에 비례해 비용이 그대로 늘어납니다. 전통 ML은 모델을 올려 둔 인스턴스 값이 주된 비용이라 건수가 늘어도 한 인스턴스가 감당하는 만큼은 값이 그대로입니다. 그래서 하루 수백만 건을 같은 방식으로 판정하는 업무는 전통 ML이 압도적으로 쌉니다. 반대로 하루 수백 건이면 모델을 만들고 유지하는 비용이 API 요금보다 커집니다.

인프라 제약은 배포 위치에서 갈립니다. 공장 설비나 매장 단말처럼 네트워크가 불안정하거나 데이터를 밖으로 내보낼 수 없는 곳에서는 작은 전통 ML 모델을 기기 안에 넣는 편이 현실적입니다. 파운데이션 모델은 자체 호스팅하려면 GPU가 필요하고, 관리형 API를 쓰려면 데이터가 서비스로 나가야 합니다.

같은 문제를 둘로 풀어 보기

고객 문의를 부서별로 분류하는 일을 예로 들면 두 길이 이렇게 갈립니다. 전통 ML로 풀면 부서 표시가 붙은 과거 문의 수만 건이 필요하고 준비에 시간이 들지만, 일단 만들고 나면 건당 값이 아주 싸고 응답이 빠릅니다. 파운데이션 모델로 풀면 부서 이름과 설명을 프롬프트에 적는 것으로 오늘 시작할 수 있고 레이블이 필요 없지만, 건당 값이 비싸고 느립니다. 레이블 데이터가 있고 갈래가 고정이며 물량이 크면 전통 ML, 데이터가 없고 빨리 시작해야 하며 갈래가 자주 바뀌면 파운데이션 모델이 답입니다.

신용 한도를 정하는 일은 앞 절의 이유로 전통 ML 쪽입니다. 사내 규정 문서를 읽고 질문에 문장으로 답하는 일은 정답 레이블을 만들 수 없고 출력이 자유로운 글이어야 하므로 파운데이션 모델 쪽이고, 근거를 대야 하니 검색을 붙여 씁니다.

둘 중 하나만 골라야 하는 것도 아닙니다. 실제 구성은 자주 둘을 이어 붙입니다. 들어온 문의를 전통 ML 분류기가 싸고 빠르게 갈래로 나눈 다음, 그중 사람이 답을 써야 하는 갈래만 파운데이션 모델에 넘겨 초안을 만들게 하는 식입니다. 대량으로 흐르는 판정은 싼 쪽이 받고 글을 만드는 일은 비싼 쪽이 받으니 비용과 품질이 함께 잡힙니다. 문항이 「비용을 억제하면서 상담원의 작성 시간을 줄이고 싶다」처럼 요구를 둘로 적어 두면 한쪽만 고르는 보기가 아니라 이렇게 나눈 보기가 답인 경우가 있습니다.

한 가지 더 짚어 둘 것은 처음 고른 답이 영원하지 않다는 점입니다. 파운데이션 모델로 시작해 두면 그 판정 결과가 그대로 쌓이는데, 그것이 몇 달 뒤에는 전통 ML을 학습시킬 레이블 데이터가 됩니다. 데이터가 없어서 파운데이션 모델을 골랐던 조건이 스스로 풀리는 셈이라, 물량이 커지는 업무에서는 시작만 파운데이션 모델로 하고 나중에 갈아타는 것이 흔한 경로입니다.

고르는 순서

문항을 만나면 위에서부터 묻습니다. 먼저 걸린 곳에서 답이 정해집니다.

1. 개별 판정의 근거를 규제 기관이나 고객에게 대야 하는가 → 전통 ML
2. 출력이 자유로운 글·이미지·코드인가 → 파운데이션 모델
3. 밀리초 지연이나 대량 건수의 건당 비용이 걸리는가 → 전통 ML
4. 레이블 붙은 우리 데이터가 충분히 있고 과제가 하나로 고정인가 → 전통 ML
5. 데이터가 없거나 과제가 여럿이고 빨리 시작해야 하는가 → 파운데이션 모델

「가장 적은 개발 노력으로 빨리」와 「대량 처리를 가장 싸게」가 서로 다른 답을 가리킨다는 점이 이 목록의 핵심입니다. 문항의 마지막 문장이 둘 중 무엇을 요구하는지 확인하고 답을 고릅니다.

연습 문제

1. 은행이 대출 심사 자동화를 검토합니다. 거절 시 사유를 고객에게 서면으로 알려야 하고 감독 기관 감사 대상입니다. 가장 알맞은 접근은?
   ① 파운데이션 모델에 심사 규정을 프롬프트로 넣고 판정하게 한다
   ② 특성 기여도를 낼 수 있는 전통 ML 모델을 학습시킨다
   ③ 파운데이션 모델로 판정하고 사유는 사람이 나중에 지어 적는다
   ④ 클러스터링으로 신청자를 묶어 무리별로 승인한다

   ②. 개별 건의 산출 근거를 대야 하고 감사 시점에 재현되어야 하는 자리입니다. ③은 실제 판정 근거가 아닌 글을 사유로 내보내는 것이라 규제 대응이 되지 않습니다.
2. 다음 중 파운데이션 모델보다 전통 ML이 유리해지는 조건을 둘 고르시오.
   ① 하루 400만 건을 같은 방식으로 판정해야 하고 건당 비용이 중요하다
   ② 사내 문서를 읽고 문장으로 답해야 한다
   ③ 네트워크가 닿지 않는 공장 설비 안에서 돌아야 한다
   ④ 요약·번역·분류를 한 모델로 함께 처리하고 싶다
   ⑤ 레이블 붙은 데이터가 전혀 없고 다음 주에 시작해야 한다

   ①과 ③. 대량 건수의 건당 비용과 기기 안 배포는 작은 전통 ML 모델의 자리입니다. ②④⑤는 모두 파운데이션 모델이 유리한 조건입니다.
3. 해석가능성과 설명가능성의 차이로 가장 알맞은 것은?
   ① 해석가능성은 모델 구조 자체가 읽히는 성질이고, 설명가능성은 복잡한 모델에 사후적으로 근거를 붙이는 것이다
   ② 해석가능성은 정확도가 높은 것이고, 설명가능성은 속도가 빠른 것이다
   ③ 둘은 같은 말이며 문서마다 표기만 다르다
   ④ 해석가능성은 파운데이션 모델에만, 설명가능성은 전통 ML에만 쓰는 말이다

   ①. 선형 회귀의 계수처럼 구조가 들여다보이면 해석가능성이고, 안이 복잡한 모델에 특성 기여도를 계산해 붙이는 것이 설명가능성입니다.
4. 어느 팀이 고객 문의 분류를 파운데이션 모델로 시작했습니다. 여섯 달이 지나 갈래가 여덟 개로 굳었고 하루 처리량이 60만 건으로 늘었으며 그동안 판정 결과가 모두 쌓였습니다. 지금 검토할 만한 변경은?
   ① 그대로 둔다 — 파운데이션 모델이 언제나 더 정확하다
   ② 쌓인 결과를 레이블로 써서 전통 ML 분류기를 학습시킨다
   ③ 프롬프트를 더 길게 써서 정확도를 올린다
   ④ 클러스터링으로 갈래를 다시 찾는다

   ②. 없던 레이블이 생겼고 갈래가 고정되었으며 물량이 커졌습니다. 세 조건이 모두 전통 ML 쪽으로 기울었고, 프롬프트를 늘리는 ③은 토큰이 늘어 비용을 더 올립니다.
5. 파운데이션 모델의 건당 비용이 건수에 비례해 늘어나는 이유로 가장 알맞은 것은?
   ① 모델 파일을 요청마다 새로 내려받기 때문
   ② 주고받은 토큰 수로 요금이 매겨지기 때문
   ③ 요청마다 모델을 다시 학습시키기 때문
   ④ GPU를 요청마다 새로 만들기 때문

   ②. 관리형 API를 부르는 구성에서는 대개 입력과 출력의 토큰 수가 그대로 요금이 됩니다. 학습은 요청마다 일어나지 않습니다.
6. 다음 판단을 「먼저 물어야 하는」 순서대로 배열하시오.
   (가) 밀리초 지연이나 대량 건수의 건당 비용이 걸리는지 본다
   (나) 개별 판정의 근거를 규제 기관에 대야 하는지 본다
   (다) 레이블 붙은 우리 데이터가 충분한지 본다
   (라) 출력이 자유로운 글·이미지·코드인지 본다

   (나) → (라) → (가) → (다). 규제가 걸리면 다른 조건과 상관없이 전통 ML 쪽이고, 그다음 출력의 모양이 갈래를 크게 가릅니다. 운영 제약과 데이터 보유는 그 뒤에 저울을 미세하게 기울입니다.
7. 다음 중 그라운딩으로 붙일 수 있는 근거의 성격을 옳게 말한 것은?
   ① 모델 내부에서 어떤 특성이 결과를 얼마나 밀었는지
   ② 답을 만들 때 어느 문서의 어느 대목을 보았는지
   ③ 학습에 쓴 데이터의 전체 목록
   ④ 모델의 파라미터 값

   ②. 출처를 대는 것이라 「어느 문서를 보고 말했는가」에는 답하지만 「왜 그렇게 판단했는가」에는 답하지 못합니다. 규제가 요구하는 쪽이 어느 것인지 읽어야 합니다.

일곱 문항 모두 같은 자리를 겨눕니다. 두 갈래의 성능을 견주는 문제가 아니라 감당해야 하는 제약이 무엇인지 찾는 문제입니다. 문항의 마지막 문장이 「근거를 대야 한다」·「가장 싸게」·「빨리 시작해야 한다」 중 무엇으로 끝나는지가 답을 정합니다.