1. 생성형 인공지능에 대한 기본적인 이해
이 제품이 어떤 원리로 동작하는지 알아야 더 잘 쓸 수 있는 부분이 있습니다. 예컨대, 전자레인지를 이용할 때 전자파가 어떤 원리로 작동하는지는 몰라도 되는데요. 전자파로 음식물 내 수분을 끓여 온도를 올린다는 정도는 알면 좋습니다. 그러면 전자레인지로는 음식을 태우기 힘들다는 걸 알 수 있습니다.
이처럼 기본적으로 이해하고 있어야 제대로 사용할 수 있는 LLM의 특징들에 대해 다뤄 보려 합니다.
이런 생성형 인공지능 서비스의 핵심 엔진을 거대 언어 모델이라 하고, 줄여서 LLM이라고 부르는데요. 이 글에서는 이 용어를 사용하겠습니다. 엄밀히 말해 LLM은 문장을 생성하는 모델이고, ChatGPT나 Claude, Gemini 같은 AI 제품은 여기에 검색, 기억, 파일 처리 같은 기능을 결합한 서비스입니다.
이후 말할 특성들은 LLM 알고리듬과 학습 방식 자체에 내재한 특성이기 때문에 시간이 지나도 달라지기 쉽지 않을 근본적인 것들입니다. 그래서 중요합니다.
(1) 패턴 기반 생성 기계
LLM의 본질은 통계적 추론을 통해 문장을 완성하는 프로그램입니다. 즉, 방대한 학습 데이터에서 패턴을 발견하고, 입력과 가장 잘 맞는 패턴을 바탕으로 다음에 올 내용을 예측해 출력합니다. LLM은 개념과 원리를 명시적으로 배운 뒤 적용하는 방식으로 훈련되는 것이 아닙니다. 학습한 패턴을 바탕으로 그럴듯한 문장을 생성하는 것입니다.
예컨대 LLM에게 간단한 덧셈을 시키면 매우 잘합니다. 마치 수학의 원리를 이해한 것처럼 보이죠. 그러나 최근 연구에서는 흥미로운 결과가 나왔습니다. 숫자를 모두 임의의 기호로 바꿔도 같은 규칙을 적용할 수 있는지 실험했더니, 정확도가 크게 떨어졌습니다. 사람이 덧셈의 원리를 이해했다면 숫자를 다른 기호로 바꿔도 같은 규칙으로 계산할 수 있을 테지만, LLM은 그렇지 못했던 것입니다. 이는 현재의 LLM이 추상적인 규칙을 견고하게 적용한다기보다 학습한 패턴에 크게 의존한다는 점을 보여 줍니다.[1]
이런 특성 때문에 LLM에게는 예시가 매우 중요합니다. 예시는 원하는 결과의 패턴을 직접 보여 주기 때문입니다.
또한 LLM은 지시와 자료를 본질적으로 구분하지 못합니다. 지시와 자료는 UI로 나뉘어져 있을 뿐 LLM 엔진에게는 모두 완성해야 하는 하나의 텍스트에 불과하기 때문입니다. 그래서 읽어들인 웹페이지나 문서 속 문장을 사용자의 지시처럼 따르는 프롬프트 인젝션이 발생할 수 있습니다.[2]
통계적 추론 모델이기 때문에 생기는 또 다른 특징은 같은 요청에도 코드가 달라질 수 있다는 것입니다. 그럴듯한 답은 여러 가지기 때문이죠.
(2) 할루시네이션은 본질
지금의 LLM은 근본적으로 통계적 추론 모델입니다. 모든 상업용 LLM이 같은 원리에 기반해 개발돼 있습니다. 이 토큰의 다음에 나오면 자연스러울 만한 토큰이 무엇인지를 통계적으로 추론해서 그럴듯한 응답을 하는 것입니다. 즉, LLM의 관심사는 “그럴듯함”이지 사실 여부가 아닙니다.
또 LLM은 사람이 마음에 들어 하는 응답을 더 좋은 응답으로 여기도록 학습됐는데 사람들은 자신감 있는 말하기를 선호합니다. 그래서 LLM은 그럴듯한 이야기를 자신감 있게 하는 것입니다. 지금도 이는 사람들을 헷갈리게 만듭니다.
이런 것을 특별히 환각, 할루시네이션이라고 하는데, LLM 입장에서는 이것이 부작용이 아니라 본질입니다.
상용 LLM들은 훈련을 통해서 환각을 최대한 줄인 모델입니다. 그러나 근본 모델 자체에서 완전히 없앨 수는 없기 때문에 언제나 정확성은 별도로 체크를 해야 합니다.
LLM이 자신의 판단 과정을 설명할 때도 내부 계산을 들여다보고 보고하는 것이 아니라 그럴듯한 설명을 생성하는 것입니다. 따라서 자세하고 자신감 있는 설명이 곧 올바르다는 뜻은 아닙니다. 늘 긴장해야 합니다.[3]
(3) 학습 시점
미리 학습한 것에 기반해 답하므로, 학습 시점 이후의 정보는 가지고 있지 않습니다. 예컨대 Claude Fable 5는 2026년 1월까지의 데이터만 학습돼 있습니다.
실시간으로 학습을 할 수는 없습니다. 예컨대 우리가 나눈 대화를 실시간으로 학습하지 못합니다. 한 대화가 끝나면 방금 전의 대화는 다 까먹습니다. 뒤에서 다루겠지만, 심지어 방금 나눈 대화도 기억하지 못합니다(기억하는 것처럼 보이게 UI를 구성해 뒀을 뿐입니다). 이것도 인간과 다른 점이죠.
이를 보완하기 위해 최신 AI 제품들은 LLM에 기억을 흉내내는 장치를 달고 검색 기능을 연결하고 있습니다.
(4) LLM의 기억
앞서 LLM은 기억을 하지 못한다고 했습니다. 그런데 LLM이 새로운 기억을 전혀 추가하지 못한다면 어떻게 10초 전의 이야기는 기억하고 답을 하는 것일까요? 우리가 나누는 대화에서 “기억”은 사용자가 그렇게 느끼도록 설계해 둔 것입니다. LLM에게 연속된 대화란 없습니다. 매번이 새로운 메시지입니다.
연속성을 보장하기 위해 서비스들은 이전 대화 내용을 매번 입력에 함께 넣고 그다음 응답을 새로 생성합니다. 그래서 대화가 진행될수록 주고받는 데이터의 양은 늘어납니다.
단기 기억 능력을 상실한 천재 아이와 대화한다고 생각하시면 됩니다. 이 아이는 엄청나게 박식하지만 방금 전에 나눈 대화는 기억하지 못합니다. 그래서 대화를 나눌 때는 언제나 우리가 앞서 무슨 말을 했는지 다 적어서 보여 줘야 합니다.
참고로 대화가 길어진 만큼 항상 같은 단가의 토큰 비용이 드는 것은 아닙니다. 이전 입력과 같은 앞부분은 프롬프트 캐시가 적중하면 더 낮은 가격으로 처리됩니다. 예컨대 Claude API에서는 캐시된 입력의 요금이 일반 입력의 10분의 1입니다.[4]
다만 캐시된 부분도 컨텍스트 윈도우의 길이에는 포함됩니다. 또한 10분의 1 가격으로 할인되더라도, 대화가 길어질수록 지시 한 번의 비용은 계속 증가합니다.
그렇다면 요즘 ChatGPT나 Claude, Gemini 등이 다른 채팅방에서 오래 전 나눈 대화를 바탕으로 사용자를 기억하고 있는데, 어떻게 하는 걸까요? 매 대화의 시작점에 사용자에 대한 정보나 대화 검색 결과를 넣어서 함께 보내는 것입니다.
(5) 컨텍스트 윈도우(맥락 창)
LLM의 학습, 검색 보완, 기억에 대해 이야기했으니 이제 가장 중요한 개념인 컨텍스트 윈도우에 대해 이야기를 하겠습니다. 이 개념을 반드시 숙지하시기 바랍니다.
앞서 비유로 언급한 천재 아이가 한번에 수용할 수 있는 정보의 사이즈는 제한돼 있습니다. 이렇게 한꺼번에 주고받을 수 있는 대화창의 크기를 컨텍스트 윈도우라고 부릅니다. 컨텍스트 윈도우 사이즈는 모델별로 다릅니다.
컨텍스트 윈도우의 측정 단위는 ‘토큰’입니다. 컴퓨터가 모든 것을 2진수로 바꿔 해석하는 것처럼 LLM도 모든 것을 토큰으로 바꿔 해석합니다. 한글은 한 글자당 대략 1~3토큰입니다. 모델별, 상황별로 차이가 있습니다.
요즘 최신 모델들은 대체로 100만 토큰 정도의 컨텍스트 윈도우를 가지고 있는데요. 적당히 환산하면 200페이지 책 다섯 권 정도 분량입니다. 물론 근사치에 불과하다는 것은 염두에 둬야 합니다.
LLM 초기 모델들은 컨텍스트 윈도우가 작았습니다. 그래서 한 대화 안에서도 앞의 내용을 금세 까먹곤 했죠. 지금은 길이가 넉넉해져서 좀 낫습니다.
ChatGPT 등장 초기에는 컨텍스트 윈도우가 꽉 차면 앞부분을 날려 버렸습니다. 그래서 대화를 하다 보면 챗봇이 앞의 대화를 전혀 기억하지 못하는 일이 벌어지곤 했습니다. 최근에는 서비스에 따라 앞선 대화를 압축하는 기법을 사용합니다. 대화를 요약하는 것이죠.
추가로 염두에 둬야 할 것이 있습니다. LLM과 주고받는 내용이 눈에 보이는 대화만 있는 게 아니라는 점입니다. 서비스가 미리 심어 둔 지침, 우리가 설정해 둔 맞춤 지시사항이나 저장해 둔 기억, 검색이나 파일을 불러올 때 오간 내용까지 모두 컨텍스트 윈도우 안에 함께 들어갑니다.
그래서 화면에 보이는 대화는 짧아 보여도 실제로 오가는 양은 훨씬 많을 수 있습니다. 예컨대 책 세 권 분량짜리 자료를 읽히고 시작했다면 이미 컨텍스트 윈도우는 반 이상 소모됐을 수 있습니다. 게다가 요즘 대부분의 상용 추론 모델은 답을 내놓기 전에 스스로 생각을 정리하는 추론 과정을 거치는데, 화면에는 보이지 않는 이 추론 내용도 컨텍스트 윈도우를 함께 차지합니다.
Claude Code나 Codex와 같은 코딩 에이전트들은 남은 컨텍스트의 양이 얼마나 되는지 표시해 주기 때문에 가늠을 하며 작업을 할 수 있습니다. (보이지 않으면 /status 명령으로 확인할 수 있습니다.)
한 가지 더 기억해야 할 게 있습니다. 컨텍스트 윈도우를 꽉 채우지 않아도, 대화가 길어지는 것만으로 성능이 떨어진다는 보고가 있다는 점입니다.
최근 한 연구에서 최신 모델 18개를 시험한 결과 모든 모델에서 입력이 길어질수록 출력 품질이 조금씩 나빠졌습니다.[5] 어느 지점에서 갑자기 무너지는 절벽 형태가 아니라 토큰이 늘어나는 만큼 연속적으로 나빠지는 식이어서, 20만 토큰을 담을 수 있는 모델이 5만 토큰만 채운 상태에서도 눈에 띄게 떨어질 수 있습니다.[6]
이 현상을 컨텍스트 부패(context rot)라고 부릅니다. 이 현상때문인지 Codex는 100만 토큰까지 다룰 수 있으면서도, 기본 컨텍스트 윈도우를 25만 8000 토큰으로 제한해 뒀습니다.
또 하나는 위치 문제입니다. 같은 정보라도 대화의 앞부분이나 끝부분에 있으면 잘 찾아내지만, 중간에 묻혀 있으면 분명히 있는데도 못 찾는 경우가 많습니다. 대화 주제가 산만해서 놓치는 건 아닐까 하고 모든 대화를 공백으로 채운 채 정보 하나만을 놔둬 봤지만 그래도 정확도가 떨어졌습니다. 이를 중간 소실(lost in the middle) 현상이라고 부릅니다.[7]
따라서 컨텍스트 윈도우를 꽉 채울 때까지는 성능이 보장될 거라 생각하지 말고, 대화 품질이 떨어진다 싶으면 새 세션으로 넘기는 것이 좋습니다. 이때 AI에게 현재의 대화를 요약하라고 해서 받은 다음 새 세션에 넣어 주면 도움이 됩니다. 이 때 handoff 스킬이 도움이 됩니다. 같은 이유로, 대화 주제가 완전히 바뀌었다면 그 채팅을 이어가기보다 새로 시작하는 편이 낫습니다.
(6) 단지 채팅이 아님 – 에이전트(Agent)
LLM은 다음 문장 생성기라고 앞서 이야기했습니다. 이는 LLM이 단지 채팅이 아니라는 이야기입니다. 글을 작성할 수도, 번역을 할 수도 있지만, 여러 파일을 읽고, 수정하고, 새로 쓸 수도 있습니다.
컴퓨터는 기본적으로 문장형 명령을 통해 작동하는 기계고, LLM은 이런 명령들을 아주 잘 생성하기 때문입니다.
그래서 이제 LLM은 단지 채팅이 아니라 에이전트로서 작동하기 시작합니다. 에이전트는 대리인이라는 뜻인데요. 사용자가 필요한 일을 지시하면 스스로 계획을 세우고, 필요한 도구를 선정해 실행하는 프로그램입니다.
여기서 핵심은 도구입니다. 기존의 챗봇은 도구 사용에 한계가 있었습니다. 그러나 에이전트 프로그램들은 기존의 챗봇에 비해 훨씬 더 많은 도구를 다룰 수 있습니다. 그만큼 할 수 있는 일도 늘어났습니다.
에이전트는 Claude Code, Codex나 OpenCode, Pi Agent 같은 프로그램을 말합니다.
에이전트에게 도구를 연결하면 사람 대신 파일을 찾고, 코드를 수정하고, 테스트를 실행하고, 오류 메시지를 읽어 다시 고칠 수 있습니다. 도구가 없는 챗봇을 사용하면 사람이 AI의 답을 복사해 실행하고 그 결과를 다시 전달해야 합니다. 이때 사람은 가장 빠른 시스템에서 가장 느린 구성 요소, 즉 AI에게 타이핑 서비스를 제공하는 병목이 되기 쉽습니다.
(7) 보상 함수 하이재킹
에이전트가 자율적으로 일한다는 것이 결과를 믿고 맡겨도 된다는 뜻은 아닙니다. LLM은 실제로 일을 제대로 끝내는 것뿐 아니라, 사용자에게 도움이 되는 것처럼 보이고 일이 끝난 것처럼 말할 수도 있습니다.
그래서 예컨대 테스트를 고치라는 요청을 받았을 때 원인을 해결하는 대신 테스트를 비활성화하거나 값을 하드코딩해 통과시키는 지름길을 택할 수도 있습니다. 이를 보상 함수 하이재킹이라고 부릅니다.[8] 보상만 납치한다는 뜻이죠.
따라서 에이전트의 “완료했습니다”라는 보고는 완료의 증거가 아닙니다. 에이전트는 사람이 만족하는 답을 선호하도록 훈련돼 있기 때문에 “완료했습니다”라는 문장을 생성했을 뿐일 수도 있습니다.
생성된 코드뿐 아니라 테스트 자체도 틀릴 수 있으므로, 기대한 동작이 실제로 이뤄지는지 사람이 확인해야 합니다. 새벽에 장애가 났을 때 “그 부분은 AI가 작성했다”는 말로 책임을 피할 수는 없습니다. 결과에 대한 책임은 도구를 사용한 사람에게 있습니다.
(8) 거의 모든 것을 알지만 나에 대해선 모른다
LLM은 인터넷의 공개 자료를 포함한 방대한 자료로 훈련받았습니다. 그래서 엄청나게 많은 것을 알고 있지만 내부 자료에 대해서는 거의 아무것도 모른다는 커다란 불균형이 있습니다.
그래서 AI를 대할 때는 맥락을 모르는 신입과 대화하듯 지시하는 것이 좋습니다. 신입에게 업무 지시를 내린다고 생각해 보면, 취지와 맥락을 설명해 주고, 지시를 명확하게 하고, 필요하면 참고 자료와 예시를 알려 줄 겁니다.
AI에게 내리는 좋은 지시의 특성도 같습니다. AI는 취지와 맥락을 모르지만 그 외 아는 것은 많은 신입이라고 생각하시면 대체로 좋은 지시를 작성할 수 있습니다.
2. 제품
(1) 개요
이제 구체적인 서비스 제공 기업과 제품, 그리고 모델에 대해서 말해 보려고 합니다. AI 발전 속도가 빠른만큼 이 아래 부분은 시간이 지나면 낡을 것입니다.
기업과 제품은 잘 알려져 있습니다. OpenAI의 ChatGPT가 선구적입니다. Anthropic의 Claude는 코딩과 에이전트 작업에서 특히 강세를 보이는 제품이고요.
Google의 Gemini는 최근 코딩 성능에서 밀린다는 평을 받습니다. 그럼에도 구글은 가장 거대한 인프라를 갖추고 있으므로 앞으로도 주요 플레이어로 남을 것입니다.
중국의 DeepSeek도 염두에 둬야 하는 기업이자 모델인데요. 매우 싼 비용으로 괜찮은 성능의 LLM 모델을 제공하기 때문입니다.
(2) 모델
서비스별 모델을 아는 것은 LLM을 잘 사용하는 데 있어서 중요합니다. 고급 모델은 성능이 좋지만 느리고 비쌉니다. 모든 작업에 고급 모델을 사용하는 것은 비효율적입니다.
정액 구독제를 사용하는 경우 고급 모델이 “비싸다”는 것은 돈이 더 든다는 뜻이라기보다 정해진 시간 동안의 사용 한도를 더 빨리 소진한다는 뜻입니다.
모델은 상당히 복잡하고 또 계속 변합니다. 개념을 아는 것이 중요합니다.
- 보통 위쪽에 있는 것이 더 고급 모델 혹은 최신 모델이다.
- 무조건 고급 모델이 좋은 것은 아니다. 일반적 수준에서는 성능 차이가 크지 않다.
- 복잡한 문제를 고급 모델이 더 잘 해결한다.
- 고급 모델은 대체로 더 느리고 사용 한도를 더 많이 소모한다.
일반적인 작업을 할 때는 2-3번째 모델을 사용하고 복잡한 작업을 할 때 맨 위의 모델을 사용하는 것을 권합니다.
(3) 추론 수준
추론 기법은 LLM들이 성능 향상을 이룬 핵심적 기법 중 하나입니다. DeepSeek R1이 추론 모델을 널리 알렸고, 현재 주요 AI 기업들도 추론 기능을 제공합니다.
추론이란 답을 바로 출력하지 않고, 중간 단계에 더 많은 계산을 사용해 답의 정확도를 높이는 방법입니다. 일부 제품은 모델이 생성한 추론 과정이나 그 요약을 보여 줍니다.
추론에 대해서도 모델과 비슷한 상충 관계가 작동합니다.
- 높은 추론은 정확도를 높이는 대신 속도를 늦추고 더 많은 토큰을 소모합니다.
- 높은 추론 수준이 무조건 좋은 것은 아닙니다. 간단한 질문에 대해서는 성능 향상이 없을 수 있습니다.
추론은 서비스별로 이름이 다르게 붙어있습니다. ChatGPT에서는 “추론 강도”라고 부르고, Claude에서는 “노력, 사고”라고 부릅니다.
(4) 에이전트
에이전트는 컴퓨터에 있는 도구와 파일들을 다룰 수 있는 현재 가장 진일보한 형태의 LLM 활용법입니다.
2025년 초 출시된 Anthropic의 Claude Code가 가장 앞섰다는 평을 받습니다. OpenAI도 Codex CLI를 내놨고, 구글은 Antigravity 에디터와 CLI를 내놨습니다. 지금은 모두 데스크톱 앱으로도 사용할 수 있습니다.
이런 상용 AI 기업들이 내놓은 공식 에이전트 외에도 모델만 갈아끼우면서 사용할 수 있는 에이전트들이 있습니다. OpenCode와 Pi Agent가 그런 에이전트입니다.
알리바바가 만든 Open Code Review는 코드 리뷰에 특화된 에이전트입니다.
- Yang Yan et al., “Do Large Language Models Truly Grasp Addition? A Rule-Focused Diagnostic Using Two-Integer Arithmetic,” EMNLP 2025, arXiv:2504.05262, https://arxiv.org/abs/2504.05262. 숫자 대신 임의의 기호를 쓰자 수치 정확도 99.81%였던 Claude 3.5 Sonnet이 7.51%까지 떨어졌다.↩︎
- Kai Greshake et al., “Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection,” arXiv:2302.12173, https://arxiv.org/abs/2302.12173.↩︎
- Miles Turpin et al., “Language Models Don’t Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting,” arXiv:2305.04388, https://arxiv.org/abs/2305.04388.↩︎
- Anthropic, “Pricing,” https://docs.anthropic.com/en/docs/about-claude/pricing.↩︎
- Chroma, “Context Rot: How Increasing Input Tokens Impacts LLM Performance”; https://ioob.dev/posts/context-rot-long-context-window-2026/↩︎
- MorphLLM, “Context Rot”; https://www.morphllm.com/context-rot↩︎
- Nelson F. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts,” Transactions of the Association for Computational Linguistics 12 (2024), arXiv:2307.03172, https://arxiv.org/abs/2307.03172.↩︎
- 《바이브 코딩 프로덕션의 원칙》, 219~225쪽.↩︎
댓글 남기기