LLM을 제품에 녹이려면, 먼저 LLM을 이해해야 합니다.

이 글은 LLM이 무엇인지 쉽게 설명하면서, 그 설명에서 자연스럽게 드러나는 LLM의 한계를 짚습니다. 그리고 그 한계 위에서 “LLM을 제품에 잘 녹이려면 어떤 관점이 필요한가”를 끌어냅니다.

LLM은 AI·머신러닝·딥러닝과 어떻게 다른가?

AI에서 LLM까지

AI는 Artificial Intelligence라는 말 그대로, 사람이 보기에 지능적인 일을 수행하는 시스템 전반을 가리킵니다. AI라는 말 자체는 특정한 구현 방식을 의미하지 않습니다. 사람이 규칙을 직접 작성한 시스템도 AI라고 부를 수 있고, 데이터로부터 패턴을 학습하는 시스템도 AI라고 부를 수 있습니다.

Machine learning은 이 넓은 AI 안에서 데이터로부터 어떠한 패턴을 찾아내는 접근입니다. 사람이 모든 규칙을 직접 정하는 대신, 주어진 데이터에서 반복적으로 관찰되는 관계를 학습합니다. 무엇을 어떻게 학습하는지에 따라 다양한 machine learning 기법이 있습니다. Machine learning 중에서 모델을 만드는 부류가 있습니다. 주어진 입력과 출력 사이의 관계를 특정한 형식으로 표현한 것을 모델이라고 합니다. 어떤 입력이 들어왔을 때 어떤 출력이 나올 가능성이 높은지, 혹은 어떤 값이 더 적절한지를 계산할 수 있도록 만든 함수라고 생각할 수도 있습니다. LLM도 사람이 언어 규칙을 하나씩 작성해 만든 시스템이 아니라, 대량의 텍스트 데이터로부터 언어의 패턴을 학습한 모델입니다.

딥러닝은 이러한 모델을 만드는 방법 중 하나입니다. 딥러닝 모델은 많은 파라미터와 활성 함수를 거쳐 입력을 출력으로 변환합니다. 학습 과정에서는 모델이 낸 출력이 정답에 가까워지도록 하나의 목적 함수를 최적화합니다. 이때 모델은 어떤 규칙을 명시적인 문장으로 저장하는 것이 아니라, 수많은 파라미터 안에 입력과 출력 사이의 관계를 조금씩 조정해 갑니다. 일반적인 프로그램에서는 사람이 작성한 조건문과 절차가 명시적으로 드러납니다. 반면 딥러닝 모델에서는 사람이 직접 규칙을 나열하지 않고, 학습 데이터와 목적 함수를 통해 원하는 동작에 가까워지도록 모델을 조정합니다. 덕분에 사람이 규칙으로 다 쓰기 어려운 문제를 다룰 수 있지만, 동시에 왜 특정한 출력이 나왔는지를 명확히 설명하기는 어려워집니다.

자연어는 특히 이런 방식이 잘 맞는 영역입니다. 문장에는 언제나 하나의 정답만 있는 것이 아닙니다. 같은 의미를 여러 방식으로 표현할 수 있고, 같은 단어도 문맥에 따라 다르게 해석됩니다. LLM은 바로 이 자연어의 모호함을 딥러닝 모델로 다룹니다.

LLM을 이해하기 위해 먼저 LLM이 “언어를 다루는 딥러닝 모델”이라는 점에서 출발하고자 합니다.

LLM은 어떻게 문장을 만들어내나?

다음 단어를 예측하는 딥러닝 모델

LLM은 주어진 텍스트 뒤에 이어질 다음 단어, 더 정확히는 다음 토큰을 예측하도록 학습된 모델입니다. 텍스트가 입력되면 LLM은 그 뒤에 이어질 수 있는 여러 토큰 후보를 계산합니다. 이때 모델은 학습된 파라미터로부터 각 후보가 얼마나 그럴듯한지 점수화합니다.

자연어에서는 같은 문장 뒤에도 여러 표현이 자연스럽게 이어질 수 있습니다. LLM은 다양한 학습 데이터를 모델링해 입력 텍스트 뒤에 올 수 있는 후보들의 점수 분포를 계산하도록 만들어졌습니다.

이런 의미에서 LLM은 자연어의 분포를 묘사한 모델이라고 말할 수 있습니다. 여기서 분포란 특정 문맥에서 어떤 말이 더 자연스럽고 어떤 말이 덜 자연스러운지에 대한 모델의 전체적인 판단에 가깝습니다. LLM은 이 분포를 바탕으로 다음 토큰을 고르고, 다시 그다음 토큰을 예측하는 과정을 반복하며 문장을 생성합니다.

LLM은 대화를 기억할까? — ‘stateless 함수’라는 핵심

제품 개발에서 LLM을 사용할 때는 이 모델을 하나의 stateless한 함수처럼 이해할 수 있습니다. 단순화하면 LLM은 다음과 같이 동작합니다.

f( 입력 텍스트 )  →  이어지는 텍스트

여기서 stateless하다는 말은 모델이 이전 요청의 내용을 내부에 자동으로 기억하지 않는다는 뜻입니다. LLM은 입력에 포함되지 않은 대화 내역이나 외부 정보를 스스로 기억해 다음 응답에 반영하지 않습니다.

ChatGPT 같은 서비스는 이전 대화를 기억하는 것처럼 보입니다. 하지만 그 상태는 LLM 자체가 아니라 LLM을 감싼 제품과 서비스 계층이 관리합니다. 서비스가 이전 대화 내역을 보관하고, 다음 요청 때 다시 입력 문맥에 포함하기 때문에 대화가 이어지는 것처럼 동작합니다.

이 관점에서 LLM을 응용한 서비스를 만들 때 가장 중요한 제어면은 입력 텍스트입니다. 모델이 어떤 역할을 해야 하는지, 어떤 정보를 참고해야 하는지, 어떤 형식으로 답해야 하는지는 모두 입력 안에 들어가야 합니다. 제품 개발 관점에서 LLM을 제어하는 방법은 결국 입력 텍스트 하나뿐이라고 말할 수 있습니다. 그래서 LLM 활용 기술은 단순한 prompt 작성에서 출발해, 더 풍성한 입력을 구성하는 방향으로 발전했습니다.

prompt·context·tool·agent·harness는 무엇이고 어떻게 발전했나?

1. Prompt engineering — 지시문을 잘 쓰자

LLM을 제품에 적용하는 방법은 결국 이 stateless한 함수를 어떻게 활용할 것인가의 문제입니다. 초기에는 입력 텍스트를 하나의 prompt로 보고, prompt를 더 명확하게 쓰거나 예시를 넣거나 출력 형식을 지정하는 방식으로 LLM을 제어하려 했습니다. 이를 prompt engineering이라고 부릅니다.

2. Context engineering — 입력을 여러 재료로 구성하자

머지않아 사람들은 서비스에 필요한 입력을 하나의 지시문으로 다루기보다, 여러 문맥 요소로 나누어 구성하는 관점이 유용하다는 것을 깨달았습니다. 이전 대화 내역, 검색으로 찾은 문서, 사용 가능한 도구, 사용자가 보고 있는 화면, 오늘 날짜 같은 정보를 필요한 시점에 모아 LLM의 입력으로 구성하는 일을 prompt engineering과 구분해 context engineering이라고 부르게 되었습니다.

3. Tool calling — LLM이 도구를 부르게 하자

Tool 혹은 function calling이 더해지면 LLM은 어떤 도구를 어떤 인자로 호출하면 좋을지 선택할 수 있습니다. 제품은 LLM의 요청을 받아 실제 도구를 실행하고, 실행 결과를 다시 문맥에 넣어 LLM에게 전달합니다.

4. Agent — 목표를 향해 반복하자

이 과정을 한 번의 호출로 끝내지 않고, 목표를 정해 반복하면 agent라는 구조로 이해할 수 있습니다. Agent는 LLM에 도구, 반복 실행, 목표 달성 과정을 결합한 형태입니다. Agent가 수행할 수 있는 일은 제공된 도구와 입력 문맥, 반복을 제어하는 외부 구조에 의해 확장됩니다.

5. Agent team / swarm — agent가 다른 agent를 호출

LLM 자체도 하나의 함수처럼 호출할 수 있으므로, 어떤 agent가 다른 LLM을 호출하는 구조도 만들 수 있습니다. 이때 호출되는 LLM을 sub-agent로 보고, 여러 agent가 역할을 나누어 일하는 구성을 agent team 혹은 agent swarm이라고 부르기도 합니다.

6. Harness — 넓어진 만큼 안전장치로 감싸자

Agent에게 목표와 도구를 주고 활동 반경을 넓히면, 그만큼 잘못된 방향으로 진행할 가능성도 커집니다. 따라서 결과가 좋은지 확인하는 feedback, 하면 안 되는 일을 막는 guard, 실행 가능한 범위를 제한하는 sandbox 같은 구조가 필요해집니다. Agent가 접하는 외부 환경과 활동 반경을 감싸는 이런 제어 구조를 이르기 위해 harness라는 용어가 등장했습니다.

정리하면, prompt · context · agent · swarm · harness는 별개의 개념이 아니라 ‘기억 없는 함수(LLM)를 제품에 쓰기 위해 입력과 외부 환경을 점점 더 넓게 구성·제어해 온 하나의 흐름’으로 이해할 수 있습니다. 

제니퍼는 LLM을 어떻게 쓰고 있나

제니퍼에서 LLM을 제품에 적용하는 과정도 앞에서 살펴본 흐름과 크게 다르지 않습니다.

LLM은 학습 데이터에 포함된 일반적인 엔지니어링 지식을 바탕으로, 좋은 prompt만으로도 모니터링 데이터 분석에 도움을 줄 수 있습니다. 직접 에러 메시지나 프로파일 일부를 ChatGPT 같은 범용 LLM에 붙여 넣고 질문해 보시면 어느 정도 유용한 답변을 얻으실 수 있을 것입니다.

하지만 제니퍼가 제품 안에서 제공하려는 도움은 그보다 더 매끄러워야 합니다. LLM은 제니퍼 화면의 의미, 선택된 대상, 조회 시간, 지표의 성격을 스스로 알지 못합니다. 사용자가 이러한 정보를 직접 LLM에 전달하도록 안내하는 대신, 제품 안에서 문맥을 잘 구성해 LLM에 전달하고 사용자의 모니터링 데이터 분석을 돕고자 합니다.

• 제니퍼 도움말 챗봇 — RAG를 적용한 context engineering 사례입니다. 사용자가 질문하면 관련 매뉴얼과 도움말 문서를 검색하고, 그 내용을 LLM 입력에 함께 넣어 답변을 생성합니다. 모델 자체가 제니퍼 매뉴얼을 새로 학습한 것이 아니라, 필요한 문서를 실행 시점의 문맥으로 제공하는 방식입니다.

• 제니퍼 인사이트 — Context engineering 관점에서 이해할 수 있는 사례입니다. 차트, 대시보드, 프로파일, 스택트레이스, 에러 정보 등 모니터링 도구가 다루는 데이터는 그 양이 많기도 하고 분석하기에 복잡할 수 있습니다. 제니퍼 인사이트는 이러한 데이터에 더해 각 화면의 의미, 시간 범위, 도메인 정보, 차트별 요약, 분석 규칙, 출력 형식과 같은 요소들을 LLM이 읽을 수 있는 구조화된 문맥으로 구성합니다.

• Tool calling — 제니퍼 인사이트는 tool calling도 활용하고 있습니다. 사용자가 자연어로 질문하면 LLM이 필요한 데이터를 얻기 위한 제니퍼 OpenAPI 호출을 요청하고, 제품이 그 결과를 다시 문맥에 넣어 응답을 이어갑니다. 하지만 아직까지는 매끄러운 분석 경험에는 미치지 못했다고 보고 있습니다. 지금은 기존 API를 LLM이 사용할 수 있는 도구로 연결하고, 그 결과를 답변과 차트, 테이블로 보여주는 단계입니다.

향후 고객의 눈높이에 맞는 agent를 구성한다면, 제니퍼의 각 기능은 context의 일부로 전달되는 정보를 넘어 agent가 활동할 수 있는 작업 공간으로 생각할 수 있습니다. 사용자가 무엇을 맡길 수 있는지, agent가 어디까지 실행하고 어디서 멈춰야 하는지, 결과를 어떻게 검토할지를 제품 안에서 자연스럽게 표현해야 합니다.

자주 묻는 질문 (FAQ)

Q. LLM은 대화를 기억하나요?

A. 아니요. LLM은 stateless 함수라 이전 요청을 스스로 기억하지 않습니다. ChatGPT가 대화를 기억하는 것처럼 보이는 이유는 서비스가 지난 대화를 저장해 두었다가 다음 요청 때 다시 입력에 붙여 넣기 때문입니다. 기억은 LLM이 아니라 LLM을 감싼 서비스가 관리합니다.

Q. Prompt engineering과 context engineering의 차이는 무엇인가요?

A. Prompt engineering은 입력을 하나의 지시문으로 보고 더 명확하게 쓰는 방식이고, context engineering은 지난 대화·검색 문서·도구 설명·날짜 같은 여러 재료를 실행 시점에 모아 입력을 구성하는 방식입니다. 후자는 입력을 한 덩어리가 아니라 여러 문맥 요소의 조합으로 다룹니다.

Q. RAG란 무엇인가요?

A. RAG(검색 증강 생성)는 질문과 관련된 문서를 먼저 검색해 그 내용을 LLM 입력에 함께 넣어 답을 생성하는 기법입니다. 모델을 새로 학습시키지 않고 필요한 문서를 실행 시점의 문맥으로 제공한다는 점이 핵심이며, context engineering의 대표 사례입니다.

Q. Tool calling이란 무엇인가요?

A. LLM이 어떤 도구를 어떤 인자로 호출할지 선택해 요청하면, 제품이 실제로 그 도구를 실행하고 결과를 다시 입력 문맥에 넣어 LLM에게 돌려주는 방식입니다. LLM은 무엇을 부를지 고르고, 실행은 제품이 담당합니다.

Q. Agent와 일반 LLM 호출은 어떻게 다른가요?

A. 일반 호출은 한 번 입력하고 한 번 답을 받습니다. agent는 목표를 정해 두고 ‘LLM이 도구 선택→실행→결과 확인’을 목표 달성까지 반복하는 구조로, LLM에 도구·반복 실행·목표 달성 과정을 결합한 형태입니다.

Q. Harness란 무엇인가요?

A. Agent의 행동을 감싸 안전하게 만드는 제어 구조입니다. 결과를 확인하는 feedback, 금지된 일을 막는 guard, 실행 범위를 제한하는 sandbox 등을 묶어 agent가 외부 환경과 상호작용하는 범위를 통제합니다.

Q. LLM을 제품에서 제어하는 방법은 결국 무엇인가요?

A. 결국 입력 텍스트 하나입니다. LLM은 stateless 함수이므로 역할·참고 정보·출력 형식을 모두 입력에 담아야 합니다. prompt·context·tool·agent·harness는 이 입력과 외부 환경을 점점 넓게 구성·제어해 온 단계들입니다.