1. GPT의 등장 배경

1-1. LM (Language Model)

• 단어에 올 다음 단어(토큰)을 예측하는 모델
• "오늘 날씨가" -> "좋다"를 확률적으로 계산하는 모델

1-2. Transformer의 등장

• Google에서 번역 성능을 개선하기 위해 Transformer 구조를 제언한 논문(Attention Is All You Need (2017))을 발표

  • 이전까지는 RNN / LSTM 기반이었는데, Transformer는 문장을 순차적으로 보지 않고, 전체를 한 번에 보고 관계를 계산함

  • y = f(x) (입력 x → 모델 f → 출력 y) 로 비교하자면

    // 기존 RNN 느낌
    state = f(state, input)
    
    // Transformer 느낌
    output = f(allInputs)

1-3. GPT (Generative Pre-trained Transformer)의 핵심 아이디어

• OpenAI는 이 Transformer 구조에서 x의 범위를 극단적으로 키움
  • 데이터 규모, 파라미터 수, 학습 토큰 수 ↑↑↑
• 번역만 잘하던 모델이 요약, 질문답변, 코드, 추론까지 전부 어느 정도 잘하는 모델이 됨
• 즉, 특정 태스크용 모델이 아니라, 일반적인 목적으로도 사용할 수 있는 "범용 모델"이 되어버림
• "일반적인 목적을 위한 Transformer"라는 의미

1-4. GPT와 LLM의 관계

• GPT ⊂ LLM
• LLM (Large Language Model): 개념/분류 이름
• GPT: LLM의 한 구현체(브랜드)
• FE로 비유하자면 LLM은 프론트엔드 프레임워크 GPT는 React

2. GPT(LLM)의 동작 원리

• Transformer는 블록 단위로 반복됨
• 각 블록은 크게 두 부분으로 나뉨
  • Self-Attention
    이 단어가 다른 단어들과 얼마나 관련 있는지 계산
    입력된 프롬프트에서 LLM이 어느 부분에 집중해야 하는지 계산?
  • Feed Forward Network (FFN)
    계산된 정보를 비선형 변환으로 정제
    Self-Attention 에서 계산된 정보를 방대한 데이터에서 찾음?
• 이 블록을 N번 반복함

  [입력]
    ↓
  (Self-Attention)
    ↓
  (Feed Forward)
    ↓
  [다음 블록으로]

3. MCP(Model Context Protocol)의 등장 배경

• 앞에서 살펴본 GPT는 Transformer 구조를 기반으로 입력으로 주어진 컨텍스트 안에서 다음 토큰을 예측하는 모델이다. Self-Attention과 FFN 블록을 반복하면서 문맥을 이해하고 추론하는 능력은 매우 뛰어나지만, 모델은 “입력으로 주어진 것”만 이해할 수 있다.
• 즉, GPT는 다음과 같은 정보들을 스스로 알 수 없으므로 이런 정보들은 전부 사람이 프롬프트 안에 직접 설명해서 넣어줘야 했다.
  • 현재 작업 중인 프로젝트의 구조
  • 열려 있는 파일이나 코드
  • 조직이나 팀에서 사용하는 규칙
  • 외부 데이터베이스, API, 사내 문서
• 컨텍스트가 커질수록 문제가 커졌다. GPT가 커지고, 활용 범위가 넓어질수록 프롬프트는 점점 복잡해졌다.
  필요한 배경 설명이 늘어나고 파일이나 문서를 복사해서 붙여 넣고 매 요청마다 같은 맥락을 반복해서 설명해야 했다.
  컨텍스트가 누락되면 답변 품질이 급격히 떨어지고, 어떤 정보가 왜 필요한지 구조적으로 알기 어렵고, “이 정보는 어디서 왔는지” 관리가 되지 않는다.
• 모델 자체의 성능 문제가 아니라, 모델 주변의 컨텍스트 관리 방식이 한계에 도달한 것이다.
• 이 문제를 해결하기 위해 등장한 개념이 바로 MCP(Model Context Protocol) 이다.

4. MCP(Model Context Protocol)의 개념

• MCP(Model Context Protocol)는 LLM이 사용하는 컨텍스트를 구조적으로 정의하고 전달하기 위한 표준 인터페이스다.
• 핵심 아이디어는 단순하다.
  프롬프트에 모든 것을 텍스트로 때려 넣지 말고, 컨텍스트의 “출처와 역할”을 명확히 하자.
• GPT는 생각하는 엔진이고 MCP는 생각에 필요한 맥락을 공급하는 규약이다.
• FE로 비유하면 훨씬 직관적이다. JSX만 던지는 앱이 아니라, 상태와 데이터 흐름이 구조화된 앱으로 가기 위한 변화라고 볼 수 있다.
  • GPT: 렌더링 엔진
  • 프롬프트: JSX 문자열
  • MCP: 상태 관리, 데이터 소스, 외부 리소스 연결 규칙

4-1.프롬프트 중심 방식의 한계

• 기존 방식에서는 모든 정보가 단순한 문자열 프롬프트 안에 섞여 있었다.
• 어떤 내용이 규칙인지, 어떤 내용이 참고 자료인지, 어떤 정보가 외부 도구에서 온 것인지 모델 입장에서는 전부 같은 텍스트일 뿐이다.
• MCP는 이 문제를 해결하기 위해 컨텍스트를 역할 단위로 분리한다.
• MCP에서는 다음과 같은 것들이 명확해진다.
  • 이 컨텍스트는 어디서 왔는지
  • LLM이 어떤 방식으로 접근해야 하는지
  • 필요할 때 동적으로 불러와야 하는 정보인지
• 예를 들면 파일 시스템, Git 저장소, 디자인 시스템 템플릿, 데이터베이스, 외부 API 이런 것들을 LLM이 사용할 수 있는 Context Provider로 정의한다.
• LLM은 “모든 걸 기억하는 존재”가 아니라, 필요한 컨텍스트를 요청해서 참고하는 존재가 된다.

5. 기타

5-1. Transformer를 대체하려는 시도

• Transformer의 단점
  • Attention 비용이 O(n²)
  • 긴 문맥에서 메모리 & 속도 문제
• 여러 시도 중 현재 가장 유명한 건 Mamba
  • MIT에서 제안한 State Space Model (SSM) 기반 구조
  • 긴 시퀀스 처리에는 강하지만, 범용 언어 추론에는 아직 Transformer만큼 검증되지 않
  • Mamba가 잘 되는 영역: 음성 처리, 시계열 데이터, 긴 로그 스트림, 센서 데이터
  • "언어 추론"보다는 "연속 신호 처리"에 강함

5-2. 어텐션 캐싱 프레임워크 = vLLM

• co-lead
• Attention 결과(KV Cache)를 효율적으로 관리하는 LLM 서빙 프레임워크
• GPU 메모리 파편화 해결, 토큰 생성 속도 대폭 개선, 현재 실무에서 매우 널리 사용됨
• 캐싱을 메모리에서 어떻게 최적화하는지에 대한 질문에서 나온 프레임워크

5-3. GPT는 무엇을 공개했고, 무엇을 안 공개했나

• OpenAI는 Transformer 구조 자체는 공개된 논문 기반을 사용
• 데이터 구성, 학습 레시피, 파라미터 수, 튜닝 방식, RLHF 세부 구조 는 전부 비공개
• f=f(x)라는 형태는 알려줬지만, f 내부 구현은 블랙 박스
• FE로 비유하자면 다이나믹 프로그래밍이라는 개념은 알려줬지만
  실제 점화식과 테이블 구조는 안 알려준 수준
• 초기에는 "오픈"을 강조했지만, GPT-3 이후부터는 사실상 클로즈드 모델 전략으로 전환됨