왜 전문화는 피할 수 없을까

만능 모델이 강해질수록 오히려 쪼개지는 이유를 작업 복잡도, 비용 구조, 모듈 아키텍처, 하드웨어, 플랫폼 경제의 흐름으로 풀어낸 해설

원문 논문 보기
'왜 전문화는 피할 수 없을까' 기사 커버 이미지

Dharma-AI 팀이 Hugging Face 블로그에 올린 글 Why Specialization Is Inevitable은 규모와 복잡도가 커질수록 AI가 전문화로 수렴할 수밖에 없다고 말합니다. 이 글은 그 주장을 작업 복잡도와 비용, 아키텍처, 하드웨어, 경제 구조의 순서로 풀어보려는 시도입니다. 원문은 제목 아래에 링크되어 있습니다.

만능이 편한데도 자꾸 쪼개지는 이유가 궁금해졌습니다

저는 이 글을 처음 봤을 때 제목이 조금 도발적으로 느껴졌습니다. 요즘 프런티어 모델이 워낙 잘하다 보니 하나의 큰 모델로 다 해결하면 되지 않느냐는 말을 자주 듣는데요. 저도 현장에서는 일단 큰 모델부터 써보고 안 되면 쪼개는 쪽이라서 전문화가 불가피하다는 말에 바로 고개가 끄덕여지지는 않았습니다. 그런데 글을 따라가다 보니 질문이 바뀌었습니다. 만능이 강해졌는데 왜 현장의 선택은 오히려 더 잘게 나뉘고 있을까요.

생각해보면 사람 조직도 비슷합니다. 창업 초기에는 한 사람이 기획과 개발과 영업을 다 맡는데, 일이 늘고 난도가 올라가면 자연스럽게 역할이 갈라집니다. 처음에는 나누는 게 비효율 같아 보여도 어느 선을 넘으면 나누지 않는 쪽이 더 비쌉니다. 이 글은 AI에서도 같은 선이 이미 넘어섰다고 말합니다. 작업이 복잡해지고 규모가 커지고 성능 요구가 올라가면 만능 하나로 버티는 비용이 감당하기 어려워진다는 것이죠.

제가 이 글에서 가장 눈이 갔던 부분은 전문화를 취향이나 유행으로 설명하지 않았다는 점입니다. 잘게 나누면 멋져 보여서가 아니라 큰 것으로 버티는 쪽이 물리적으로나 경제적으로나 점점 불리해지기 때문이라는 설명이었는데요. 그래서 오늘은 주장만 옮기지 않고 그 뒤에 깔린 조건들을 하나씩 따져보려고 합니다. 어디까지가 실제로 벌어지는 일이고 어디부터가 아직 풀리지 않은 질문인지 구분하면서요.

일이 어려워지면 만능은 어디서부터 버거워질까요

작업이 단순할 때는 만능이 편합니다. 질문이 오면 그냥 답하면 되고 따로 붙일 것도 없습니다. 그런데 작업이 복잡해지면 이야기가 달라집니다. 긴 맥락을 계속 들고 있어야 하고 도구를 순서대로 써야 하며 중간에 틀리면 되돌아와야 하는데요. 이런 일을 만능 하나에 계속 얹으면 매 요청마다 큰 몸집을 통째로 깨워야 합니다. 간단한 질문에도 무거운 준비 운동을 하는 셈이죠.

여기서 재미있는 질문이 생깁니다. 왜 큰 모델은 작은 일도 비싸게 할까요. 이유는 매번 같은 전체를 통과하기 때문입니다. 입력이 짧아도 가중치 전체가 대기하고 있어야 하고 연산 경로도 길게 잡힙니다. 그래서 작업 복잡도가 올라가면 만능의 여유가 먼저 닳습니다. 정확도를 유지하려고 더 큰 맥락을 주고 더 긴 추론을 시킬수록 한 번의 호출이 차지하는 자원이 커지니까요.

규모의 문제도 같이 옵니다. 하루에 몇 번 쓰는 실험실 데모에서는 큰 모델 한 번 돌리는 비용이 별일 아닙니다. 하지만 같은 호출이 하루에 수백만 번으로 불어나면 이야기가 완전히 바뀝니다. 단가가 조금만 높아도 월말 청구서는 감당하기 어려워지는데요. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 좋은데, 이걸 어느 예산으로 계속 돌릴까요. 정확도 그래프에서는 좋아 보이던 선택이 운영 계좌에서는 버티지 못하는 경우가 많습니다.

성능 요구가 올라가면 마지막으로 남은 여유까지 사라집니다. 답만 맞으면 되는 단계에서는 만능이 넉넉합니다. 그런데 지연 시간 제한이 붙고 처리량이 요구되고 실패율이 관리 대상이 되면 만능의 크기가 발목을 잡습니다. 매번 큰 파이프를 통과해야 하니 응답이 늦어지고 동시 요청이 쌓이면 줄이 길어지죠. 그래서 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이 글의 출발점도 같습니다. 전문화는 멋져서가 아니라 버거운 일을 감당하는 쪽이 갈라지기 때문입니다.

만능 블록이 여러 전문화 모듈로 나뉘는 모습을 그린 미니멀 일러스트
만능 블록이 여러 전문화 모듈로 나뉘는 모습을 그린 미니멀 일러스트

작은 것이 큰 것을 이기는 자리는 따로 있습니다

이 글에서 자꾸 돌아보게 되는 대목은 작은 모델에 대한 평가입니다. 작은 모델이 전반적으로 더 똑똑하다는 말이 아니라 좁은 자리에서는 큰 모델과 대등해질 수 있다는 말인데요. 이 차이는 생각보다 큽니다. 범위를 좁히면 필요한 지식도 좁아지고 출력 모양도 정해지며 평가 기준도 분명해지기 때문입니다.

예를 들어 밤사이 들어온 고객 문의를 정해진 양식으로 분류하는 일을 떠올려 보겠습니다. 답이 자유로운 에세이가 아니라 몇 가지 갈래 중 하나로 고르고 이유를 짧게 붙이는 일입니다. 이런 일은 거대한 배경지식보다 정해진 분기에서 흔들리지 않는 안정감이 더 쓸모 있습니다. 작은 모델을 그 분기에 맞춰 다듬으면 큰 모델을 매번 깨우는 것보다 빠르고 쌉니다. 정확도가 비슷해도 운영의 체감은 완전히 다르죠.

문제는 그다음입니다. 좁은 일은 호출량이 많기 때문에 한 번의 단가 차이가 작아 보여도 곱하기 호출량이 되면 큰돈이 됩니다. 지연 시간도 마찬가지인데, 사람이 기다리는 채팅창에서는 1초 안팎의 차이가 이탈로 이어지고 뒤에 파이프라인이 줄줄이 붙은 배치에서는 한 단계의 지체가 전체 마감으로 번지기 때문입니다. 그래서 작은 전문화 모델은 이 두 곳에서 점수를 법니다. 몸집이 작으니 빨리 돌고 싸게 돌며 같은 모양의 일을 반복하는 데 강한데, 저는 이 반복성이야말로 작은 모델의 진짜 무기라고 봅니다. 여러분의 일 가운데 이렇게 매일 같은 모양으로 오는 일은 얼마나 될까요.

저는 여기서 조금 멈칫했습니다. 작은 모델이 싸다는 말은 들을 때마다 고개를 끄덕이면서도 한 가지가 늘 걸렸기 때문입니다. 다듬는 데 드는 손질 값을 빼먹으면 안 되니까요. 데이터를 모으고 평가 기준을 정하고 실패 사례를 다시 가르치는 과정에는 분명 손이 갑니다. 그런데 이 글의 논리를 따라가면 그 손질 값은 한 번 들고 이후에는 매 호출마다 돌려받는 구조입니다. 호출량이 적으면 손질이 아깝고 호출량이 많으면 손질이 남는 장사라는 것이죠. 그래서 전문화의 승패는 모델 크기 대결이 아니라 호출량과 반복성 싸움에서 갈립니다. 같은 일이 계속 온다면 작은 쪽이 버티고, 매번 새로운 일이라면 큰 쪽이 버팁니다.

같은 좁은 작업을 처리하는 거대 단일 모델과 소형 전문화 모델의 대비도
같은 좁은 작업을 처리하는 거대 단일 모델과 소형 전문화 모델의 대비도

모델 안을 들여다보면 이미 분업이 시작됐습니다

겉으로는 하나의 모델처럼 보여도 속을 보면 분업이 들어 있습니다. 요즘 아키텍처가 가는 방향이 그렇습니다. 모든 입력을 같은 밀도로 처리하지 않고 일에 맞는 부품으로 보내는 것이죠. 이 글은 그 흐름을 전문화가 모델 바깥의 선택을 넘어 모델 안의 설계로 들어온 사례로 읽습니다. 저도 이 대목에서 고개를 끄덕였습니다. 바깥에서 나누느냐 안에서 나누느냐만 다를 뿐 나누는 쪽이 이긴다는 방향이 같기 때문입니다.

그렇다면 안에서는 어떻게 나눌까요. 대표적인 방식이 Mixture-of-Experts입니다. 모든 토큰을 같은 전문가가 보는 대신 라우터가 입력에 따라 어울리는 전문가 몇 곳에만 일을 맡깁니다. 전체 파라미터는 크지만 한 번의 호출에서 실제로 깨어나는 부분은 일부라서 계산량을 아낄 수 있는데요. 물론 라우팅이 공짜는 아닙니다. 어디로 보낼지 정하는 과정이 흔들리면 전문가가 골고루 크지 않고 특정 전문가에만 일이 몰릴 수 있습니다. 그래서 로드 밸런싱이나 용량 제한 같은 장치가 함께 갑니다. 나누는 일에는 나누는 값과 기름칠이 같이 붙는다는 것이죠.

검색을 붙이는 방식도 같은 맥락입니다. 모델이 모든 지식을 가중치 안에 외우게 하지 않고 필요할 때 바깥 문서에서 찾아오게 합니다. 자주 바뀌는 정보나 회사 내부 문서처럼 외워두기 어려운 것들은 조회에 맡기고 모델은 읽고 엮는 쪽에 집중하는 셈입니다. 도구를 쓰는 에이전트도 비슷합니다. 계산은 계산기에, 검색은 검색기에, 예약은 예약기에 맡기고 모델은 순서를 정하고 결과를 엮습니다. 어떤 일을 계산에 맡기고 어떤 일을 조회에 맡길지 다시 나눈 선택이죠.

(한 가지 덧붙이자면 이런 분업은 실패 모양도 바꿉니다. 예전에는 모델이 모르면 그럴듯하게 지어냈는데, 이제는 라우터가 엉뚱한 전문가로 보내거나 검색이 빈손으로 오거나 도구가 오래 걸리는 식으로 고장이 납니다. 그래서 저는 숫자 자체보다 그 뒤에 놓인 배선을 먼저 봅니다. 고장 지점이 어디로 옮겨갔는지를 알아야 고칠 곳도 보이니까요.) 이런 시선으로 보면 모듈 아키텍처는 만능의 반대말이 아닙니다. 만능의 껍데기를 유지하면서 속은 전문화로 채우는 절충입니다. 겉에서는 하나처럼 보이고 속에서는 여럿이 나눠 일하는 것이죠. 이 글은 그 절충이 늘어나는 것 자체를 전문화가 불가피해지는 증거로 봅니다.

CPU에서 GPU로 넘어간 이야기를 다시 꺼낸 이유

이 글은 하드웨어 이야기를 꺼냅니다. 처음에는 CPU가 여러 일을 두루 처리했는데 그림을 그리는 일이 늘자 GPU가 그 자리를 가져갔고, 이제는 AI 연산만을 위한 가속기가 또 갈라져 나왔다는 흐름입니다. 물리적인 효율이 기능을 가른다는 것이죠. 저는 이 비유가 마음에 들지만 여기서는 조금 조심해서 읽을 필요가 있습니다. 하드웨어의 분업이 곧바로 모델의 분업을 정당화하지는 않기 때문입니다. 그럼에도 이 비유가 힘이 있는 이유는 비용의 모양이 같기 때문입니다.

CPU는 무엇이든 합니다. 조건 분기도 잘하고 운영체제 일도 잘하는데, 이런 유연한 일은 CPU가 잘 맡기 때문입니다. 그런데 같은 전력을 쓸 때 행렬 곱을 수천 개씩 동시에 밀어내는 일에서는 GPU가 훨씬 낫습니다. 그래서 자주 반복되는 연산 모양이 정해지면 그 모양에 맞춘 쇳덩이가 결국 이깁니다. AI 가속기는 그 다음 장면입니다. 낮은 정밀도 연산과 큰 메모리 대역폭처럼 AI에서 자주 터지는 병목을 정면으로 겨냥하고 불필요한 유연성을 덜어낸 것이죠. 같은 일을 더 적은 전력과 시간에 해내니까 규모가 커질수록 안 쓸 이유가 없습니다.

그렇다면 모델도 같은 길을 갈까요. 자주 반복되고 모양이 정해진 일이라면 그 일을 위한 작은 구조가 유리하다는 점에서는 그렇습니다. 매번 만능을 깨우는 대신 좁은 일에 맞춘 작은 모델이나 전문가 모듈을 두면 같은 전기로 더 많은 호출을 감당합니다. 특히 지연 시간과 처리량이 걸린 자리에서는 이 차이가 그냥 숫자가 아니라 서비스 가능 여부로 돌아옵니다. 밤새 배치를 돌려야 하는 팀에게는 아침 마감 전에 결과가 나오느냐의 문제니까요.

반면 하드웨어와 모델에는 다른 점도 있습니다. 하드웨어는 한 번 찍으면 바꾸기 어렵지만 소프트웨어는 데이터를 바꾸고 가중치를 고치면 다음 날 모습이 달라집니다. 그래서 하드웨어의 전문화가 굳어지는 속도와 모델의 전문화가 퍼지는 속도는 다릅니다. 저는 그래서 이 대목을 교훈으로 덮지 않고 조건으로 따로 적어뒀습니다. 반복량이 많고 연산 모양이 굳어질수록 전문화의 이득이 커진다는 조건으로요. 반대로 일이 계속 바뀌면 굳힌 쪽이 깨지기 쉽습니다. 쇳덩이 이야기가 주는 것은 운명이 아니라 계산식입니다.

들어온 질문을 여러 전문가 서브네트워크로 보내는 라우터 개념도
들어온 질문을 여러 전문가 서브네트워크로 보내는 라우터 개념도

공짜가 된 능력은 아래로 가라앉습니다

이 글의 경제 이야기는 길게 보면 꽤 차갑습니다. 경쟁이 붙으면 범용 능력은 값이 떨어지고 플랫폼층으로 가라앉는다는 것인데, 저는 이 대목이 가장 현실적으로 읽혔습니다. 누구나 쓸 수 있는 요약이나 상식적인 글쓰기, 평범한 코딩 도움 같은 능력은 시간이 갈수록 공짜에 가까워지죠. 그러면 돈과 차별화는 위쪽으로 옮겨가는데, 누구의 데이터로 어떤 업무 흐름을 얼마나 매끄럽게 엮느냐의 싸움이 되기 때문이죠. 아래가 공짜가 되면 위에서는 무엇을 팔아야 할까요.

생각해보면 사람도 비슷하게 배웁니다. 엑셀을 잘 다루는 능력은 한때 몸값이었지만 이제는 기본기가 됐습니다. 대신 그 엑셀로 어떤 보고 체계를 만들고 어떤 결정을 앞당기느냐가 몸값이 됩니다. AI에서도 같은 일이 벌어지고 있습니다. 모델이 똑똑해질수록 모델 자체보다 그 모델을 업무에 박아 넣는 솜씨가 남습니다. 평가 데이터가 아니라 현장 데이터, 데모가 아니라 매일 도는 파이프라인이 갈라지는 지점이죠.

여기서 재미있는 질문이 생깁니다. 아래가 공짜가 되면 위는 자동으로 돈을 법니까. 그렇지는 않습니다. 위쪽은 위쪽대로 증명해야 합니다. 현장 데이터를 가졌다 해도 그 데이터가 계속 들어오는 구조인지, 업무 흐름을 바꿔도 사람들이 쓰는지, 실패했을 때 누가 책임지고 고치는지가 남습니다. 데이터가 있다는 말과 데이터가 돈다는 말은 다르니까요. 전문화가 값을 치르는 경우는 대개 후자입니다. 파이프라인에 박혀서 매일 돌고 매주 고쳐지는 쪽이죠.

저는 이 대목을 읽으면서 운영의 아침을 떠올렸습니다. 밤사이 공시가 늦게 도착하거나 아침에 특정 종목이 거래 정지에 걸려서 입력이 비어도 예측 라인은 멈추면 안 됩니다. 결측에 약한 모형은 구멍 앞에서 멈칫하고 결측을 메우는 전처리에 의존할 수밖에 없는데, 이 대체 로직이 바뀔 때마다 예측 역시 함께 흔들립니다. 반면 구멍을 통과하도록 만든 장치는 읽을 것은 읽고 모르는 것은 모른다고 말합니다. 그래서 전처리 과정이 자주 바뀌어도 결과가 크게 요동치지 않죠. 현장에서 돈이 되는 전문화는 대개 이런 모양입니다. 점수가 아니라 아침을 지켜주는 장치이기 때문입니다.

CPU에서 GPU와 전용 가속기로 이어지는 전문화 타임라인
CPU에서 GPU와 전용 가속기로 이어지는 전문화 타임라인

쪼개면 편해지는데 왜 또 귀찮아질까요

나누면 좋은데 나누면 귀찮아집니다. 이 글은 그 대가를 숨기지 않습니다. 전문화가 늘면 조정 부담이 생기고 서로 붙는 방식이 달라지며 평가도 어려워진다는 것이죠. 저는 이 대목이 오히려 글의 신뢰를 올려준다고 봅니다. 좋은 것만 말하는 글은 현장에서 오래 버티지 못하니까요.

조정의 귀찮음부터 보겠습니다. 전문가가 여럿이면 누가 무슨 일을 맡는지 정해야 하고 일을 넘길 때 맥락도 같이 넘겨야 합니다. 한 곳에서 틀리면 어디서 틀렸는지 찾아야 하고 고치면 다른 곳이 안 깨졌는지 다시 봐야 합니다. 사람이 셋이면 대화가 몇 갈래인지 세는 것과 비슷합니다. 둘이면 하나지만 다섯이면 열 갈래가 됩니다. 에이전트가 늘면 그 갈래가 눈에 띄게 불어나죠. 그래서 나누는 설계에는 늘 부기가 붙습니다. 라우팅 규칙, 스키마, 재시도, 타임아웃, 로그 같은 것들입니다. 이 부기를 볼 여유 없이 나누면 나중에 이자까지 내게 됩니다.

붙는 방식도 문제입니다. 각자 잘 돌아가는 부품을 가져와도 서로 말하는 방식이 다르면 현장에서 안 붙습니다. 출력 모양이 조금씩 다르고 오류를 알리는 방식이 다르며 버전이 오르면 조용히 바뀌기도 합니다. 어느 날 한 부품이 올라갔는데 전체 파이프라인이 멈추는 일이 생기는 것이죠. 버전 하나가 올라가면 파이프라인이 멈춘다는 말이 괜히 나오는 게 아닙니다. 그래서 현장에서는 붙이는 쪽에 시간을 더 씁니다. 입력과 출력의 모양을 고정하고 빈손이 왔을 때의 행동을 정하고 바뀌면 어디까지 알릴지를 미리 정합니다.

평가는 더 까다롭습니다. 전체가 하나일 때는 점수판이 하나지만 쪼개지면 점수판이 여러 개가 됩니다. 각 부품은 좋아 보이는데 엮으면 어색한 경우가 생깁니다. 라우터는 잘 고르는데 전문가가 약하거나 검색은 잘 오는데 엮는 쪽이 흘리는 식이죠. 그래서 끝에서 끝까지 도는 평가가 따로 필요합니다. 밤에 배치가 멈추지 않는지, 아침에 사람이 고치지 않고 넘어가는지 같은 것들입니다. 연구실 점수만으로는 안 보이는 것들이죠. 쪼개는 선택은 그래서 공짜 점심이 아닙니다. 버거움을 나누는 대신 귀찮음을 떠안는 거래입니다.

만능이 다시 다 가져가면 어떡할까요

여기까지 읽으면 반문이 생깁니다. 프런티어 만능이 더 커져서 전문화 자리를 다 먹어버리면 어떻게 되느냐는 것입니다. 이 글도 그 질문을 피하지 않습니다. 만능이 틈새를 집어삼키는 속도와 전문화가 자기 자리를 지키는 힘 사이의 겨룸이 남는다는 것이죠. 저는 이 대목이 글 전체에서 가장 솔직한 자리라고 봅니다. 전문화가 불가피하다는 제목을 달고도 끝을 확정하지 않기 때문입니다.

만능 쪽의 논리는 단순합니다. 다음 세대 큰 모델이 나오면 어제의 어려운 일이 오늘의 쉬운 일이 됩니다. 굳이 다듬지 않아도 웬만한 좁은 일은 그냥 됩니다. 손질할 여유가 없는 팀에게는 이게 큰 위로입니다. 데이터를 모으고 평가를 짜고 파이프라인을 고치는 대신 큰 모델을 얇게 쓰면 되니까요. 특히 일이 자주 바뀌는 곳에서는 굳힌 전문화보다 유연한 만능이 낫습니다. 어제 맞춘 분기가 오늘 바뀌면 다듬은 값이 하루아침에 날아갑니다.

그런데 전문화 쪽에도 버티는 힘이 있습니다. 현장 데이터와 업무 흐름이 그것입니다. 공개된 글로는 못 배우는 회사 안의 말투와 예외 처리, 고객별 다른 기준 같은 것들은 바깥 큰 모델이 한 번에 가져가기 어렵습니다. 게다가 전문화는 값이 쌉니다. 호출량이 많은 자리에서는 싼 쪽이 계속 돌고 비싼 쪽은 특별한 경우에만 불립니다. 만능이 똑똑해져도 매번 만능을 부르는 모양이면 청구서가 먼저 항의합니다.

그렇다면 이 흐름은 어디에서 갈릴까요. 저는 호출의 반복성과 데이터의 닫힘 정도로 갈린다고 봅니다. 같은 모양의 일이 계속 오고 그 일을 푸는 열쇠가 바깥에 없는 데이터에 있다면 전문화가 오래 갑니다. 반대로 일이 매번 새롭고 열쇠가 공개 지식에 있다면 만능이 먹습니다. 둘 사이의 경계는 고정된 게 아니라 모델 세대가 바뀔 때마다 흔들립니다. 그래서 이 질문에 한 번 답하고 끝낼 수는 없습니다. 매 분기 청구서와 실패 로그를 보면서 다시 묻는 수밖에 없죠. 이 글은 그 되물음을 남겼다는 점에서 충분히 정직합니다.

범용 플랫폼층과 상단 전문화 응용층을 쌓은 스택 다이어그램
범용 플랫폼층과 상단 전문화 응용층을 쌓은 스택 다이어그램

같은 예산을 어디에 쓸지 고르는 일이 남습니다

현장에는 예산이 정해져 있습니다. 그래서 질문은 언제나 같은 모양입니다. 큰 것 하나를 살지 작은 것 여럿을 엮을지, 외우는 쪽에 쓸지 찾는 쪽에 쓸지, 한 번에 세게 쓸지 여러 번 나눠 쓸지 말이죠. 이 글은 그 선택을 취향이 아니라 조건의 문제로 바꿔줍니다. 반복량이 많은지, 지연 제한이 빡빡한지, 데이터가 안에서 도는지 같은 것들입니다.

저희 팀의 기준으로 옮겨보면 저는 이렇게 묻습니다. 이 일은 내일도 같은 모양으로 올까요. 늦으면 사람이 떠나거나 마감이 깨질까요. 바깥 모델이 못 보는 사내 맥락이 얼마나 섞여 있을까요. 세 답이 모두 그렇다면 전문화 쪽에 손이 갑니다. 반대로 일이 매번 다르고 늦어도 괜찮으며 공개 지식으로 풀린다면 큰 모델을 얇게 쓰는 쪽이 낫습니다. 같은 돈을 어디에 두는 게 아침을 편하게 하느냐의 문제죠.

여기서 한 가지 덧붙이고 싶은 것은 측정의 순서입니다. 정확도부터 보고 비용을 나중에 보는 팀이 많은데, 순서를 바꾸면 결정이 달라집니다. 호출량과 지연 제한을 먼저 놓고 그 안에서 정확도를 고르는 것이죠. 호출량이 적으면 큰 모델이 답이고 호출량이 많으면 작은 전문화가 답인 경우가 많습니다. 숫자가 아니라 구조를 먼저 보는 습관이라고나 할까요. 저는 이 글의 경제 이야기를 그렇게 읽었습니다. 어디가 공짜가 됐고 어디에 돈을 둘지를 가리는 눈금으로요.

물론 이 눈금에도 오차가 있습니다. 손질 값과 붙이는 값을 얕보면 전문화가 비싸지고 호출량을 얕보면 만능이 비쌉니다. 그래서 처음부터 크게 짓지 않고 작은 전문화부터 붙여보면서 청구서와 실패 로그로 배우는 쪽이 안전합니다. 큰 것에서 작게 가는 것보다 작은 것에서 필요할 때만 크게 가는 쪽이 운영의 마음이 편하니까요. 이 글은 방향을 말해주지만 크기는 현장의 로그가 정해줍니다.

앞으로 무엇을 보면 될까요

남은 질문들을 모아볼 차례입니다. 이 글은 답을 닫지 않고 다음에 볼 것들을 남기는데요. 저는 그 열린 끝이 마음에 들었습니다. 전문화가 대세라는 말로 끝내지 않고 어디가 흔들리는지를 짚었기 때문입니다.

먼저 볼 것은 라우팅과 엮음의 자리입니다. 안에서 나누든 바깥에서 나누든 결국 누가 어디로 보낼지, 보내고 나서 어떻게 엮을지가 남습니다. 라우터가 흔들리면 좋은 전문가도 못 쓰고 검색이 와도 엮음이 흘리면 답이 샙니다. 그래서 다음 세대 연구는 큰 것과 작은 것의 대결보다 그 사이를 잇는 쪽에서 나올 가능성이 큽니다. 누가 봐도 멋진 모델보다 조용히 잘 붙이는 부품이 먼저 눈에 띌 때가 있죠.

다음으로 볼 것은 평가의 자리입니다. 쪼개진 시스템은 부분 점수로 안 보입니다. 끝에서 끝까지 돌려봐야 합니다. 밤새 멈추지 않는지, 입력이 비어도 아침에 답이 나오는지, 버전이 올라도 파이프라인이 서는지 같은 것들입니다. 연구실 점수와 운영 점수가 다른 말을 할 때가 많은데, 전문화가 늘수록 그 간격이 더 벌어집니다. 저는 그래서 앞으로의 글은 점수보다 로그를 더 보여줬으면 합니다. 무엇이 몇 점 올랐는지보다 무엇이 몇 번 안 깨졌는지를요.

마지막으로 볼 것은 데이터가 도는 구조입니다. 전문화의 방파제는 한 번 모은 데이터가 아니라 계속 들어오는 데이터입니다. 현장에서 쓰이고 고쳐지고 다시 들어오는 고리가 돌아야 큰 모델이 쉽게 못 가져갑니다. 고리가 끊긴 전문화는 시간이 갈수록 마릅니다. 반대로 고리가 도는 전문화는 모델 세대가 바뀌어도 살아남습니다. 제가 앞으로 보고 싶은 것은 그래서 모델 그림보다 데이터 고리입니다. 어디서 들어와서 어디서 고쳐지고 어디로 다시 들어가는지의 그림이죠.

전문화된 에이전트와 도구 사이 조정 부담을 표현한 네트워크 그림
전문화된 에이전트와 도구 사이 조정 부담을 표현한 네트워크 그림

그래서 사람의 자리는 어디로 옮겨갈까요

마지막에는 사람의 이야기로 끝내고 싶습니다. 모델이 쪼개지면 사람의 일도 쪼개질까요. 저는 오히려 반대로 본다고 말씀드리고 싶습니다. 부품이 잘게 나뉠수록 전체를 꿰는 눈이 더 귀해지기 때문입니다. 무엇을 나눌지, 어디까지 외우게 하고 어디부터 찾게 할지, 실패하면 어디서 잡을지를 정하는 일은 여전히 사람의 몫입니다.

생각해보면 사람 조직도 그랬습니다. 역할이 나뉠수록 각자의 솜씨보다 엮는 솜씨가 결과를 가릅니다. 누가 회의록을 잘 쓰느냐보다 누가 회의가 돌게 하느냐가 남았죠. AI 시스템도 같습니다. 작은 모델 하나를 잘 다듬는 솜씨보다 호출량과 지연과 데이터 고리를 보고 예산을 두는 솜씨가 남습니다. 어디에 돈을 두고 어디에 사람을 두는지를 정하는 일이죠.

그렇다면 지금 당장 무엇을 하면 될까요. 저는 거창한 것보다 작은 것부터 권하고 싶습니다. 매일 오는 반복 일 하나를 골라 작은 전문화로 붙여보고 청구서와 실패 로그를 같이 보는 것인데, 이렇게 하면 작은 성공부터 쌓을 수 있기 때문입니다. 큰 모델을 버리자는 말이 아니라 큰 모델을 아껴 쓰자는 말이죠. 비싼 호출은 특별한 경우에 남겨두고 싼 호출로 일상을 돌리는 것이죠. 그래서 그렇게 돌려보면 전문화는 구호로 끝나지 않고 매일 손에 붙는 습관이 됩니다. 생각해보면 이 습관이야말로 전문화를 이해하는 가장 빠른 길이라고 봅니다.

이 글을 덮고 나면 한 문장이 남습니다. 만능이 강해질수록 현장은 더 잘게 나눈다는 것입니다. 처음에는 역설처럼 들리지만 따져보면 자연스럽습니다. 강해진 만능은 아래로 가라앉아 공짜가 되고, 그 위에서 값을 만드는 쪽은 현장의 반복과 데이터와 흐름을 엮는 전문화이기 때문입니다. 그렇다면 여러분의 일 가운데 내일도 같은 모양으로 올 일은 무엇일까요. 그 질문에서 시작하면 됩니다.

참고 자료

  1. Why Specialization Is Inevitable · huggingface.co

    리뷰 원문