AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

깔끔했던 Transformer가 복잡해진 이유, 그리고 에이전트의 한계

2022년 메타에는 두 갈래의 머신러닝이 있었습니다. Llama로 이어진 LLM 작업은 Transformer 모듈을 반복해 쌓은 깔끔한 구조였고, 추천시스템 그래프는 그에 비하면 끔찍할 만큼 복잡했죠. 그런데 몇 년이 지난 지금, 업계는 그 격차를 줄였습니다. 추천시스템을 단순하게 만든 게 아니라, LLM을 그만큼 복잡하게 만드는 방식으로요.

사진 출처: Ian Barber, “LLMs are complicated now” (Seb Raschka의 LLM 아키텍처 갤러리 인용)

메타에서 콘텐츠 이해·추천시스템을 다뤘던 엔지니어 Ian Barber가 최근 자신의 블로그에 LLM이 점점 복잡해지는 현상을 짚은 글을 올렸습니다. 핵심은 단순합니다. 모델을 더 좋게 만들려는 노력이 역설적으로 모델을 더 복잡하게 만들었고, 이 복잡성은 AI 에이전트가 알아서 풀어줄 수 있는 종류가 아니라는 것입니다.

출처: LLMs are complicated now – Ian’s Blog

“어텐션만 있으면 된다”던 모델은 어디로 갔나

한때 Transformer는 같은 블록을 위로 쌓기만 하면 되는 깔끔한 구조였습니다. 지금은 다릅니다. “어텐션이 전부”라던 모델이 이제는 온갖 어텐션 변종을 동시에 씁니다. 쿼리를 묶고(grouped), 압축하고(compressed), 띄엄띄엄 계산하고(sparse), 선형으로 바꾸고(linear), 일정 범위만 보는(sliding-window) 방식이 한 모델 안에 섞여 들어갑니다.

여기에 Mixture-of-Experts가 더해졌습니다. 입력에 따라 필요한 부분만 골라 쓰는 선택적 라우팅인데, 이제는 피드포워드 층뿐 아니라 어텐션 블록부터 잔차 연결(residual stream)까지 거의 모든 곳에 라우팅이 들어갑니다. 비전·오디오 인코더도 예전엔 바깥에 덧붙이는 식이었지만 지금은 모델 안에 녹아들었고, 모델이 여러 GPU에 걸쳐 추론하면서 중간중간 GPU 간 통신 연산까지 끼어듭니다. 깔끔했던 스택이 어느새 추천시스템만큼 빽빽해진 셈입니다.

복잡해질 수밖에 없었던 이유

Barber는 이 흐름이 추천시스템이 먼저 걸었던 길과 똑같다고 봅니다. 추천시스템도 거의 10년간은 비교적 단순한 구조였는데, 복잡성은 한 가지 긴장에서 자라났습니다. 성능을 계속 끌어올려야 한다는 압박과, 효율을 지켜야 한다는 압박 사이의 긴장입니다. 특히 추론 단계의 효율이 문제였죠.

성능 최적화가 ‘선택’이던 시절엔 깔끔한 모델 정의를 유지할 수 있습니다. 문제는 최적화가 ‘필수’로 바뀌는 순간입니다. 이때부터는 성능 개선이 모델 구조 자체를 떠받치는 요소가 됩니다. 새로운 어텐션 변종 A를 B로 바꿔보고 싶다고 해봅시다. B가 10% 느린 건 감당할 수 있지만, 10배 느리면 못 씁니다. 그런데 A가 이미 최적화되어 있다면, B도 최소한 부분적으로는 최적화해봐야 그게 탐색할 가치가 있는지조차 판단할 수 있습니다. 연구의 반복 루프 자체가, 단순히 “이미 아는 걸 최적화하라”와는 다른 종류의 유연성을 요구하는 것입니다.

에이전트가 이걸 풀어줄까

여기서 자연스러운 기대가 나옵니다. PyTorch나 JAX로 모델을 정의해서 Claude 같은 에이전트에게 던지면, 알아서 최적으로 융합된(fused) 커널을 만들어주지 않을까? Barber는 여기에 함정이 있다고 짚습니다. 생성된 결과가 ‘맞는지’ 확인하려면, 고정되고 쓸 만한 baseline이 필요하다는 것입니다.

문제의 본질은 이렇습니다. 손으로 일일이 최적화해 과거로 돌아가는 길은, 그럴 가치가 있을지도 모르는 일에 막대한 시간을 쏟아야 합니다. 그렇다고 무작정 생성으로 앞서 나가는 길은, 결과를 검증할 baseline이 없으면 무의미합니다. 양쪽 다 막혀 있다면 남는 답은 하나뿐입니다. 처음부터 조합 가능하게(composable) 설계하는 것입니다.

Barber가 꼽은 좋은 사례가 PyTorch의 FlexAttention입니다. 한 부류의 어텐션 연산 전체를 Triton 템플릿으로 커널을 생성할 수 있게 만든 작업인데, 애초에 조합 가능하고 검증 가능하도록 설계되어서 성능에 큰 손해 없이 여러 변종을 탐색할 수 있습니다. 복잡성을 사후에 떠안는 대신, 설계 단계에서 다룰 수 있게 만든 것이죠.

복잡성을 다루는 능력이라는 것

이 글이 흥미로운 건, “AI가 다 자동화해줄 것”이라는 기대가 정확히 어디서 깨지는지를 보여주기 때문입니다. 에이전트는 검증할 기준이 있을 때 강력하지만, 그 기준 자체를 만들고 구조를 본질로 깎아내는 일은 여전히 사람의 몫으로 남습니다.

Barber는 최근 Anthropic에 합류한 Andrej Karpathy를 언급하며 글을 맺습니다. Karpathy가 지난 몇 년간 보여줬듯, 아키텍처를 본질까지 깎아내고 조합 가능하게 만드는 능력은 영리한 에이전트 설정만큼이나 중요하다는 것입니다. 복잡성은 피한다고 사라지지 않습니다. 다룰 수 있게 설계하느냐, 떠안고 허덕이느냐의 차이만 남을 뿐입니다.


AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다