LLM을 쓰다 보면 신기한 순간도 많은데, 이상하게 쉬운 문제에서 틀릴 때가 있습니다. 글은 자연스럽게 쓰면서 strawberry에 r이 몇 개인지 같은 걸 틀리는 식이고요. 이 글은 그게 단순한 버그라기보다 모델 구조랑 관련이 있다는 관점에서 정리해 봤습니다.
트랜스포머부터 보기
2017년 "Attention is All You Need" 논문 이후로 트랜스포머는 현대 LLM의 기본 구조가 됐습니다. ChatGPT, Claude, Gemini, LLaMA 같은 모델도 이 흐름 위에 있고요. 텍스트뿐 아니라 이미지, 오디오, 번역까지 확장됐으니까 지금 AI 붐을 이해하려면 트랜스포머를 피해 가기는 어려운 것 같아요.
LLM이 자주 흔들리는 지점
LLM은 텍스트 길이 제어에서 자주 흔들립니다. 200단어를 요청했는데 150단어나 250단어를 내놓는 식이고요. 문자열 패턴을 정확히 세는 것도 약합니다. "strawberry"에서 r 개수를 세는 문제나 한글 반복 패턴을 다루는 문제에서도 틀릴 수 있고요.
트랜스포머 구조
트랜스포머의 핵심은 어텐션입니다. 문장 안의 단어들이 서로 어떤 관계인지 한꺼번에 보는 방식이죠. 수식으로 쓰면 보통 이렇게 표현합니다.
이 구조는 시퀀스가 길어질수록 계산량이 크게 늘어나죠.
여기서 n은 시퀀스 길이, d는 차원입니다.
셀프 어텐션과 메모리 문제
트랜스포머는 여러 관점에서 단어 간 관계를 보는 멀티헤드 어텐션을 씁니다. 성능은 좋은데 그만큼 계산 자원도 많이 먹고요. 멀티헤드 어텐션의 수학적 구조는 이렇게 표현되죠.
각 헤드가 따로 계산하니까 메모리도 많이 필요합니다.
Chain-of-Thought 프롬프팅
Chain-of-Thought(CoT) 프롬프팅은 이 한계를 어느 정도 줄이는 방법입니다. 바로 답을 내라고 하지 않고 중간 과정을 쓰게 만드는 방식이죠. 수식으로 보면 이렇게 생각해볼 수 있을 것 같아요.
CoT의 실제 적용 예시
일반적인 프롬프팅이랑 CoT 프롬프팅은 느낌이 꽤 다릅니다.
일반적 프롬프팅:
Q: strawberry에서 'r'의 개수는?
A: 2개
CoT 프롬프팅:
Q: strawberry에서 'r'의 개수를 단계별로 세어주세요.
A: 1단계: 각 글자 확인
s(r없음) → t(r없음) → r(첫번째) → a(r없음) → w(r없음)
→ b(r없음) → e(r없음) → r(두번째) → r(세번째) → y(r없음)
총 개수: 3개
하드웨어 요구사항과 제약
요즘 트랜스포머 모델은 컴퓨팅 파워를 상당히 먹습니다. 대략 이런 수식으로 생각해볼 수 있죠.
그래서 NVIDIA GPU 같은 고성능 하드웨어가 중요해졌고요. 모델 성능 얘기를 하다 보면 결국 전력이랑 메모리, GPU 가격 같은 현실적인 문제로 돌아오게 되더라고요.
다른 구조들이 나오는 이유
트랜스포머는 AI 발전의 중요한 기반인데 한계도 분명합니다. 특히 시퀀스가 길어질수록 어텐션 계산량이 확 늘어나는 문제가 있습니다. 그래서 이걸 다른 방식으로 풀어보려는 시도가 계속 나오고 있고요. MoE는 계산량을, SSM 계열은 시퀀스 길이에 따른 비용을 줄이는 쪽에 가까운 것 같아요.
MOE(Mixture of Experts)는 여러 전문가 모델을 묶어두고 필요한 전문가만 골라 쓰는 구조입니다. 모든 계산을 한 모델이 다 하는 대신 입력에 맞는 일부 전문가만 활성화하는 거죠.
여기서 g_i(x)는 각 전문가를 고르는 게이팅 함수, f_i(x)는 각 전문가 모델의 출력입니다. 계산량이랑 메모리를 줄이면서 더 큰 모델을 운영하려는 시도고요.
모델이랑 컴퓨팅을 같이 키우는 하이퍼스케일 방향도 있습니다. 성능을 단순화하면 이런 스케일링 법칙으로 볼 수 있습니다.
N은 파라미터 수, C는 컴퓨팅 능력, α랑 β는 스케일링 계수입니다. 모델 크기랑 컴퓨팅 파워가 늘 때 성능이 어떻게 바뀌는지 보는 식이죠. 근데 이 방향은 비용 문제가 같이 커져서, 아래에 나오는 SSM 계열처럼 구조 자체로 효율을 높이려는 시도도 같이 진행되는 것 같아요.
새로 나오는 아키텍처들
SSM (State Space Model)
SSM은 트랜스포머의 대안으로 자주 언급되는 구조입니다. 시스템 상태를 계속 업데이트하면서 입력을 처리합니다. 수식으로는 이렇게 씁니다.
SSM은 선형 시간 복잡도라서 긴 시퀀스를 효율적으로 처리할 수 있습니다. 메모리 사용량도 트랜스포머보다 줄일 수 있어서 긴 입력을 다루는 작업에 장점이 있고요.
Mamba 아키텍처
Mamba는 SSM을 바탕으로 선택적 상태 업데이트 메커니즘을 넣은 모델입니다. 수식은 이렇습니다.
선택적 상태 업데이트로 계산 효율을 높이고 하드웨어 최적화까지 같이 고려합니다. 특히 긴 컨텍스트 처리 쪽에 장점이 있다고 알려져 있고요.
Jamba와 하이브리드 구조
Jamba는 트랜스포머랑 Mamba의 장점을 섞은 하이브리드 모델입니다. 단순화하면 이런 혼합 구조로 볼 수 있습니다.
활성 파라미터는 120B이고, 처리량이랑 긴 시퀀스 처리 능력을 같이 노립니다. 트랜스포머의 병렬 처리 능력이랑 Mamba의 시퀀스 처리 효율을 같이 쓰려는 구조죠.
계산 복잡도 비교와 앞으로 궁금한 점
지금까지 본 구조들은 계산 복잡도부터 갈립니다.
- 트랜스포머는 O(n²)라서 긴 시퀀스 처리에 제약이 있고요.
- SSM이랑 Mamba는 O(n) 선형 복잡도라 더 효율적으로 처리할 수 있고요.
- Jamba는 O(n·log(n))으로 효율성이랑 성능의 균형을 노리는 편이죠.
여기서 더 궁금한 건 두 가지입니다. 하나는 실시간 처리. 지연 시간을 단순화하면 이렇게 볼 수 있는데,
이게 개선되면 실시간 응용에도 LLM을 더 자연스럽게 붙일 수 있을 것 같아요. 다른 하나는 멀티모달입니다. AI가 텍스트만 다루는 데서 벗어나 이미지, 오디오, 상호작용까지 같이 처리하는 방향인데,
사람이 여러 감각 정보를 같이 쓰는 거랑 비슷한 방향으로 가고 있다는 뜻이기도 하죠. 모델이 커지는 것만으로는 이 두 문제가 다 해결되진 않아서, 계산 효율이랑 구조 자체가 계속 중요한 주제로 남을 것 같아요.
마무리
LLM을 쓰다 보면 "이렇게 똑똑한데 왜 이런 걸 틀리지?" 싶을 때가 많습니다. 근데 구조를 조금 들여다보면 이 모델들이 사람처럼 세고 계산하는 방식이 아니라는 걸 알게 되더라고요.
그래서 앞으로의 모델은 그냥 더 커지는 것만으로는 부족할 것 같아요. 더 긴 문맥을 다루고, 더 적은 자원으로 돌아가고, 필요할 땐 도구나 외부 시스템이랑 연결되는 방향이 중요해질 거고요.
저도 AI를 계속 쓰고 만들면서, 장점뿐 아니라 이런 한계까지 같이 이해하는 게 중요하다고 느낍니다. 그래야 AI를 과대평가하지도 않고, 반대로 쓸모없는 기술처럼 무시하지도 않을 수 있으니까요.
참고 문헌
- Vaswani, A., et al. (2017). "Attention Is All You Need". arXiv preprint arXiv:1706.03762.
- 안될공학. (2023). "트랜스포머를 넘어 MoE와 SSM까지, 미래 AI의 방향은?...". YouTube
- Gu, A., et al. (2023). "Mamba: Linear-Time Sequence Modeling with Selective State Spaces". arXiv preprint arXiv:2312.00752.
- Wei, J., et al. (2022). "Chain of Thought Prompting Elicits Reasoning in Large Language Models". arXiv preprint arXiv:2201.11903.
- Brown, T., et al. (2020). "Language Models are Few-Shot Learners". arXiv preprint arXiv:2005.14165.