컨텍스트 윈도우는 RAM이다 — LLM을 운영체제로 보는 관점

 

LLM을 운영체제의 커널로 보는 프레임

안녕하세요. 서비나라입니다.

공인전자문서센터에서 전자문서 인프라를 다루며 서버와 운영체제의 자원 관리를 실무로 익혀온 입장에서, 최근 접한 강연 하나가 유독 마음에 걸렸습니다.

Andrej Karpathy의 「[1hr Talk] Intro to Large Language Models」 강연이 2023년 말 던진 화두입니다. 그는 LLM을 챗봇이나 단어 생성기로 부르는 것이 정확하지 않다고 말합니다. 대신 "떠오르는 운영체제의 커널 프로세스"라고 부릅니다.

제가 보기에 이 비유는 단순한 수사가 아니라, LLM을 다루는 실무 판단 기준으로 바로 옮길 수 있는 프레임입니다. 이번 글에서는 그 프레임을 하나씩 뜯어보겠습니다.

LLM을 챗봇이라고만 부르면 무엇을 놓칠까요

강연에서 Karpathy는 이렇게 말합니다. "LLM을 챗봇이나 단어 생성기로 보는 건 정확하지 않습니다. 떠오르는 운영체제의 커널 프로세스(kernel process)로 보는 편이 훨씬 맞습니다."

이 발언은 어디까지나 화자 개인의 관점입니다. 사실 명제가 아니라 프레임이라는 점을 먼저 짚고 넘어가겠습니다. 다만 제가 보기에 이 프레임은 실무에서 꽤 쓸모가 있습니다.

챗봇이라는 이름은 대화창 안에서만 LLM을 생각하게 만들지만, 커널 프로세스라는 이름은 자원 관리와 스케줄링이라는 다른 질문을 떠올리게 합니다. 무엇을 메모리에 올리고, 언제 디스크로 내리고, 어떤 요청을 우선 처리할지 같은 질문입니다. 이 프레임이 강조하는 것은 결국 자원의 우선순위 문제입니다.

이 프레임을 따라가면 자연히 다음 질문으로 이어집니다. 그렇다면 LLM의 'RAM'은 무엇일까요.

커널 프로세스의 재료: 파일 두 개와 제조의 비대칭

Karpathy는 강연에서 거대 언어 모델을 이렇게 정의합니다. "거대 언어 모델은 그냥 파일 두 개입니다. 파라미터 파일과 그것을 실행하는 코드죠." 신경망 아키텍처 구현만 놓고 보면, 다른 의존성 없이 C 코드 약 500줄이면 충분하다고 그는 설명합니다.

이 정의만 보면 커널 프로세스는 무척 가벼워 보입니다. 하지만 그 안에 들어갈 파라미터를 만드는 과정은 전혀 다른 이야기입니다.

강연은 Llama 2 70B를 예로 듭니다. 이 모델을 만들려면 GPU 약 6,000장을 12일가량 돌려야 한다고 밝히며, 비용은 약 200만 달러로 추산합니다. 이 수치는 2023년 말 강연 시점, Llama 2 70B 기준이라는 점을 분명히 해둡니다.

완성된 파라미터 파일의 크기도 함께 짚습니다. 700억 개 파라미터를 float16 기준 각각 2바이트로 저장하기 때문에, 파라미터 파일은 140GB가 됩니다.

정리하면 이렇습니다. 신경망 구현 자체는 파일 두 개와 코드 500줄로 가볍게 끝납니다. 다만 화자는 시연에 7B 모델을 썼고, 실제 70B는 그보다 약 10배 느리다고 밝힙니다. 실행 쪽의 무게가 이렇게 달라져도, 그 파일을 만드는 제조 과정은 여전히 GPU 수천 장과 막대한 비용을 요구합니다. 이 비대칭이야말로 "커널 프로세스" 비유를 추상적 수사가 아니라 구체적 그림으로 만들어 줍니다.

컨텍스트 윈도우는 RAM이다 : 유한한 작업 기억

유한한 작업 기억: 트레이 하나에 다 들어가지 않는다

Karpathy는 컨텍스트 윈도우(context window)를 이렇게 설명합니다. "컨텍스트 윈도우는 언어 모델의 작업 기억이라는 유한하고 귀한 자원입니다. 커널 프로세스가 필요한 정보를 컨텍스트 윈도우 안팎으로 페이징한다고 상상해 보세요." 또 다른 대목에서는 "브라우징으로 접근하는 디스크·인터넷이 있고, RAM에 해당하는 것이 LLM에서는 컨텍스트 윈도우"라고 정리합니다.

인프라 실무에서 가장 자주 부딪히는 문제가 바로 이 자원 배분입니다. 서버의 RAM이 유한하듯, 컨텍스트 윈도우도 유한합니다. 이 관점을 받아들이면 프롬프트 작성이라는 작업이 조금 다르게 보입니다. 단순히 질문을 잘 쓰는 일이 아니라, 유한한 작업 기억에 무엇을 올리고 무엇을 뺄지 결정하는 일이 됩니다.

다만 이 대목도 강연 시점(2023년 말, GPT-4·Llama 2 세대) 기준이라는 점은 밝혀야 합니다. 컨텍스트 윈도우의 크기나 활용 방식은 모델 세대마다 달라질 수 있는 값입니다. 강연에서 다룬 것은 그 시점의 모델을 전제로 한 설명입니다.

폐쇄형과 오픈소스, 데스크톱 OS 생태계와 겹쳐보기

강연은 이 대응관계를 데스크톱 운영체제 생태계까지 확장합니다. "데스크톱 OS에는 Windows·macOS 같은 폐쇄형과 Linux 기반 오픈소스 생태계가 있습니다. 마찬가지로 LLM에도 GPT·Claude·Bard 같은 폐쇄형과, 빠르게 성숙하는 오픈소스 생태계가 있습니다." 아래 표로 정리하면 이렇습니다.

구분	데스크톱 OS	LLM 생태계(강연 시점)
폐쇄형	Windows, macOS	GPT 시리즈, Claude 시리즈, Bard
오픈형	Linux 기반 배포판	오픈소스 LLM
특징	다양한 배포판이 공존	빠르게 성숙 중인 생태계로 소개

이 비교에서 언급된 모델명(GPT, Claude, Bard)은 강연 당시 기준입니다. '빠르게 성숙 중'이라는 평가 역시 그 시점의 관찰입니다. 이후 각 진영의 판도가 어떻게 바뀌었는지는 이 강연만으로는 알 수 없습니다.

제가 이 표를 만든 이유는 판도를 단정하기 위해서가 아닙니다. 폐쇄형·오픈형이라는 구도 자체가 데스크톱 OS 역사와 겹쳐 보인다는 화자의 관찰을 정리하고 싶었습니다. 이 프레임을 실무에 옮기면, 폐쇄형과 오픈형 가운데 무엇을 쓸지도 결국 자원과 통제권의 문제로 좁혀집니다.

도구를 쓰는 LLM: 시스템 콜이라는 비유

도구를 쓰는 LLM: 머릿속으로 풀지 않는다

마지막으로 다루고 싶은 대목은 도구 사용입니다. Karpathy는 "언어 모델이 스스로 직접 답하는 게 아니라, 그 일을 해낼 도구를 쓰도록 되어 있습니다"라고 말합니다. 이를 사람이 도구를 쓰는 방식에 빗댑니다. "우리도 머릿속으로만 풀지 않고 온갖 도구를 씁니다. 거대 언어 모델도 똑같습니다."

운영체제 비유를 계속 따라가면, 이 대목은 시스템 콜(system call)에 대응하는 구조로 읽힙니다. 커널 프로세스가 모든 일을 직접 처리하지 않고, 필요할 때 시스템 콜로 외부 자원을 호출하듯 움직입니다. LLM도 계산이나 검색 같은 일을 스스로 떠안지 않고, 도구를 호출해 처리한다는 설명입니다.

제가 보기에 이 부분은 앞서 다룬 비유들 가운데 가장 직관적으로 와닿는 대목입니다. 이 대응관계는 LLM을 도구 사용형 시스템으로 설계할 때 참고할 만한 구도로 보입니다.

다만 이 역시 강연 시점에 화자가 관찰한 LLM의 동작 방식을 설명한 것입니다. 도구 호출이라는 구조 자체는 이후에도 이어질 수 있는 설계 방향이지만, 그 구체적인 형태나 성숙도는 시점마다 다를 수 있다는 점을 감안해서 읽어야 합니다.

결론 및 요약

이번 글에서는 Karpathy가 2023년 말 강연에서 제시한 "LLM은 커널 프로세스"라는 프레임을 세 갈래로 뜯어봤습니다. 컨텍스트 윈도우를 유한한 RAM으로 보는 관점, 폐쇄형·오픈소스 구도를 데스크톱 OS 생태계와 겹쳐보는 관점, 도구 사용을 시스템 콜에 빗대는 관점입니다.

제가 강조하고 싶은 것은 이 프레임이 사실 명제가 아니라 화자의 관점이라는 점입니다. 그럼에도 실무에서 프롬프트를 설계하거나 LLM 기반 시스템을 구성할 때, 이 관점을 빌리면 무엇을 먼저 결정해야 하는지가 조금 더 선명해집니다. 강연 원본을 직접 찾아보시고, 각자의 실무 맥락에 맞게 이 비유를 어디까지 받아들일지 판단해 보시길 권합니다. 다만 판단의 몫은 늘 읽는 사람에게 남아 있습니다.