🔥 LLM — 프롬프트 엔지니어링과 컨텍스트 엔지니어링

들어가며

Cursor로 작업하기 시작한 지 꽤 됐는데 처음 몇 달은 정말 프롬프트랑 씨름했어요. "더 자세히", "다시 해줘", "아니 그게 아니라"를 반복하면서 왜 AI가 이렇게 말을 못 알아듣지? 싶었거든요. 근데 어느 순간 패턴이 보이더라고요. 프롬프트를 잘 쓰는 게 문제가 아니라 AI한테 어떤 환경을 만들어주느냐가 훨씬 중요하다는 걸요.

이 글은 Cursor나 GitHub Copilot 같은 AI 코딩 도구를 써봤는데 왜 AI가 원하는 대로 동작하지 않는지 이해가 안 됐던 분들을 위해 썼어요. 특히 프롬프트만 갖고 씨름해본 프론트엔드 개발자라면 공감할 내용이 많을 거예요.

근데 그게 단순히 프롬프트를 더 길게 쓰는 문제가 아니라면 도대체 뭘 바꿔야 하는 걸까요?

---

LLM은 무엇을 하는 시스템인가

LLM을 '지능'이 아니라 '확률 모델'로 보기

AI와 대화할 때 느끼는 '지적인 존재와 대화하는 기분'은 사실 정교하게 설계된 수학적 확률의 결과물이에요. 개발자로서 이 메커니즘을 이해하면 AI가 왜 가끔 어처구니없는 실수를 하는지 그리고 왜 '맥락'을 설계해야 하는지 명확히 알 수 있어요.

AI가 세상을 읽는 단위: 토큰(Token)

LLM은 텍스트를 우리처럼 '단어'나 '글자'로 인식하지 않아요. 텍스트를 의미 있는 최소 단위인 '토큰'이라는 덩어리로 쪼개서 처리하는데 여기서 중요한 건 "도대체 어떤 기준으로 쪼개느냐"예요.

기준은 '빈도'예요 (BPE 알고리즘)

GPT 계열 LLM은 BPE(Byte Pair Encoding)라는 방식의 토크나이저를 사용해요. BERT 계열은 WordPiece를 다른 모델들은 또 다른 방식을 쓰기도 해서 모델마다 달라요. 공통적인 원리는 이래요. AI는 사전에 적힌 단어를 외우는 게 아니라 학습 데이터에서 '가장 자주 함께 등장하는 글자 쌍'을 묶어서 토큰으로 만들어요.
처음엔 s, t, r, a, w, b, e, r, r, y처럼 한 글자씩 시작하지만 데이터 속에서 t와 h가 자주 붙어 나오면 th를 한 덩어리로 묶고 나중에는 ing, pre, straw 같은 뭉치들을 하나의 토큰으로 확정 지어요.

중요한 건 이 과정이 모델을 만들 때 단 한 번만 이루어진다는 거예요. 서비스가 시작된 뒤에는 어휘 테이블이 고정되어 어떤 텍스트를 입력해도 항상 같은 방식으로 토큰이 쪼개져요(결정론적 토크나이징).

왜 strawberry에서 'r'의 개수를 틀릴까?

이게 바로 '빈도 기반' 토큰화의 맹점이에요. 토크나이저에 따라 쪼개지는 방식이 다르지만 핵심은 AI가 철자를 하나씩 보는 게 아니라 덩어리로 본다는 거예요. 예를 들어 일부 토크나이저에서는 straw + berry처럼 쪼개질 수 있어요. AI는 시각 정보가 없어서 단어 내부의 철자를 하나하나 눈으로 세지 못하고 대신 "이 토큰 뭉치가 나타났을 때 r이 몇 개라고 답할 확률이 높았지?"라는 통계적 추측을 해요. 직접 세는 게 아니라 '추측'을 하기 때문에 발생하는 오류예요.

대소문자 변환이 꼬이는 이유

hello와 HELLO는 AI 내부에서 서로 다른 토큰으로 처리돼요. AI는 소문자를 대문자로 바꾸는 로직을 실행하는 게 아니라 소문자 토큰 덩어리를 보고 그에 어울리는 대문자 토큰 덩어리를 예측해요. 이 과정에서 데이터가 부족한 희귀 단어는 확률 값이 흔들리며 글자가 깨지기도 해요.

단어의 의미를 좌표로 바꾸는 기술: 임베딩(Embedding)

그럼 쪼개진 토큰들을 AI는 어떻게 구분할까요? 바로 '임베딩'이라는 기술로 텍스트를 수백~수천 차원의 숫자 벡터로 변환해요. 엄청 많은 숫자로 이루어진 좌표라고 생각하면 돼요.

의미의 지도

'사과'와 '바나나'는 '과일'이라는 공통점이 있죠? 그럼 임베딩 공간에서 두 단어의 좌표는 아주 가까운 곳에 위치하게 돼요. 반면 '컴퓨터'는 아주 멀리 떨어진 좌표에 배치되죠. 임베딩은 이처럼 단어의 '의미'를 수치화해서 AI가 비교할 수 있게 해주는 기술이에요. 그리고 이 좌표 개념은 나중에 RAG를 설명할 때 다시 등장하는데 여기서 한 번 제대로 잡아두는 게 좋아요.

그럼 AI는 어떻게 다음 단어를 만들어낼까요?

이 부분이 좀 헷갈릴 수 있는데요. 임베딩은 입력 텍스트를 수치로 표현하는 역할이고 다음 토큰을 예측하는 건 완전히 별개의 과정이에요.

토큰이 임베딩 벡터로 변환된 뒤에는 Transformer 블록 안의 Self-Attention과 Feed-Forward Network를 여러 층 통과해요. 여기서 "지금 이 토큰이 다른 어떤 토큰들과 얼마나 관련 있는가"를 계산하는 거예요. 그리고 마지막에 Softmax 함수가 전체 어휘에 대한 확률 분포를 계산해요.

그런데 AI가 내뱉는 단어는 단순히 "확률이 가장 높은 토큰을 집어오는 것"이 아니에요. 이 부분이 중요해요. temperature가 0으로 설정된 경우(greedy decoding)에는 가장 높은 확률의 토큰을 선택하지만 실제 서비스에서 기본값으로 쓰이는 temperature > 0 설정에서는 확률 분포에 비례해 무작위로 샘플링해요. 이 때문에 같은 프롬프트를 두 번 실행해도 답변이 달라지고 가끔 낮은 확률의 토큰이 선택되어 할루시네이션이 발생하기도 해요.

쉽게 말하면 임베딩은 "뭘 읽고 있는지 이해하는 단계"이고 Transformer 블록은 "그걸 바탕으로 뭐가 올지 추론하는 단계"예요. 이 두 단계를 묶어서 결국 LLM은 확률 분포에서 다음 단어를 계속 샘플링해 나가는 '확률 계산기'라고 볼 수 있어요.

프롬프트와 컨텍스트 엔지니어링은 이 AI의 확률 계산이 엉뚱한 곳으로 튀지 않도록 정확한 길목에 이정표를 세워주는 작업이에요. 그게 어떻게 가능한지 다음 섹션에서 하나씩 풀어볼게요.

---

LLM은 왜 우리가 생각한 대로 동작하지 않을까

AI와 대화하다 보면 앞의 내용을 갑자기 까먹거나 분명히 금지한 코딩 방식을 다시 사용하는 경우가 있어요. 이건 모델이 멍청해서가 아니라 LLM이 정보를 처리하는 '구조적 한계' 때문이에요.

AI에게는 '기억'이 아니라 '입력'만 있어요

인간은 대화할 때 당연히 알고 있는 '상식'이나 '어제의 기억'을 깔고 가요. 하지만 LLM에게는 오직 지금 입력창에 들어온 텍스트(컨텍스트)가 세상의 전부예요.

상태(State)가 없는 모델

LLM은 기본적으로 이전 대화를 기억하는 '뇌'가 없어요. 채팅을 이어갈 때 시스템은 사실 [이전 대화 전체 + 방금 한 질문]을 매번 통째로 묶어서 AI에게 다시 읽혀요.

토큰 제한(Context Window)

읽어들일 수 있는 양(토큰)에는 한계가 있어요. 대화가 길어져서 이 한계를 넘어가면 시스템은 오래된 대화부터 잘라내요. 이때 가장 중요한 초기 규칙이나 핵심 요구사항이 기억에서 '드랍(Drop)'되는 거죠.

Attention Mechanism: 집중력의 편향과 실종

LLM의 핵심 기술은 Attention(어텐션)이에요. 문장 안에서 어떤 단어가 중요한지 집중해서 보는 기술인데 이 집중력은 완벽하지 않아요.

Lost in the Middle (중간 실종 현상)

AI는 입력된 텍스트의 맨 앞과 맨 뒤를 가장 잘 기억해요. 정작 중간에 적어둔 중요한 로직이나 제약 조건은 데이터 양이 많아질수록 Attention 가중치가 낮아지면서 무시될 확률이 높아져요. 이는 Stanford 연구팀(Liu et al., 2023)이 실증한 현상이기도 해요. 핵심 지시사항이 긴 컨텍스트의 중간에 묻혀 있으면 AI가 사실상 읽지 않고 넘어가는 거예요.

모호한 변수명이 AI를 혼란스럽게 만드는 이유

data, item, list처럼 의미 범위가 너무 넓은 이름은 다양한 문맥에서 등장했기 때문에 모델이 이 토큰의 역할을 추론할 때 Attention 가중치가 분산돼요. '지금 이 data는 API 응답인가, 폼 상태인가?'를 컨텍스트로 구분해야 하는데 모호한 이름일수록 그 구분이 어려워져요.

할루시네이션: '거짓말'이 아니라 '확률적 폭주'

가장 당황스러운 '할루시네이션(환각)'은 AI가 모르는 걸 아는 척하는 게 아니에요. 확률 계산의 연쇄 반응이 낳은 결과예요.

첫 단추의 저주 (Autoregressive)

AI는 문장을 한꺼번에 만드는 게 아니라 단어 하나를 내뱉고 그 단어를 포함해서 다음 단어를 예측해요. 만약 답변 초반에 낮은 확률이지만 그럴듯해 보이는 잘못된 단어(토큰)를 선택하면 그 뒤의 모든 단어는 그 '틀린 단어'를 진실로 가정하고 예측을 이어가요. 초반의 작은 확률적 이탈이 뒤로 갈수록 걷잡을 수 없는 거대한 소설(스노우볼 효과)로 변하는 거예요.

공백 메우기

AI는 학습 데이터에 없는 정보가 들어오면 "모릅니다"라고 하기보다 주변의 비슷한 정보를 참고해 그럴싸한 답변을 생성하려 해요. AI에게는 "정확성"보다 "맥락에 어울리는 다음 토큰을 제시하는 것"이 알고리즘상 우선순위이기 때문이에요.

---

프롬프트 엔지니어링이 잘 먹히는 이유

앞에서 살펴본 한계들 즉 중간 실종, 모호한 변수명, 확률적 폭주는 사실 어느 정도 막을 수 있어요. 프롬프트 엔지니어링이 바로 그 첫 번째 도구예요.

확률의 길목에 강제로 이정표 세우기

프롬프트 엔지니어링은 AI의 자유로운 확률 탐색을 제한하고 원하는 방향으로 유도하는 가이드라인이에요. "말 한마디에 답변 품질이 왜 이렇게 달라져?"라는 의문은 아래의 확률적 원리로 설명돼요.

역할 부여(Persona): 확률 분포의 '필터링'

"너는 10년 차 시니어 프론트엔드 개발자야"라고 역할을 정해주는 건 단순히 기분을 맞추는 게 아니에요. 이 문장을 넣는 순간 AI는 '초보자의 실수 코드'나 '블로그의 초급 예제' 토큰들이 나올 확률을 낮추고 대신 '클린 코드', '디자인 패턴', '성능 최적화'와 관련된 토큰들이 다음 단어로 선택될 가중치를 대폭 높여요. AI가 참조하는 확률의 영역(Search Space) 자체를 좁혀버리는 아주 효율적인 방법이에요.

너는 10년 차 시니어 프론트엔드 개발자야.
React, TypeScript 전문가이고 성능 최적화와 클린 코드를 중요하게 생각해.
아래 컴포넌트의 불필요한 리렌더링 원인을 찾아서 수정해줘.

예시 주기(Few-shot): 임베딩의 '나침반'

"A는 B처럼 바꿔줘"라고 말하는 것보다 예시 데이터를 한두 개 보여주는 게 훨씬 강력해요. 예시는 AI에게 "이런 토큰 패턴을 따라가라"는 물리적인 증거가 돼요. 백 마디 설명보다 하나의 예시 토큰 뭉치가 AI의 확률적 폭주(할루시네이션)를 막는 가장 강력한 브레이크예요.

아래 형식으로 컴포넌트를 리팩토링해줘.

[변환 전]
function handleClick(data) {
  process(data);
}

[변환 후]
function handleUserProfileClick(userProfile: UserProfile): void {
  updateUserProfile(userProfile);
}

이 패턴으로 아래 코드를 바꿔줘:
function handler(item) {
  doSomething(item);
}

생각의 사슬(Chain of Thought): 확률의 '징검다리' 놓기

"단계별로 생각해서 답해줘"라는 프롬프트가 잘 먹히는 이유도 확률 때문이에요. 한 번에 결과를 내라고 하면 너무 넓은 확률 범위에서 정답을 찾다 길을 잃는데 "단계별로 생각하라"고 하면 AI는 정답으로 가는 중간 과정의 토큰들을 먼저 생성해요. 이 중간 토큰들이 새로운 컨텍스트가 되어 최종 정답 토큰이 올바르게 나올 확률을 비약적으로 높여주는 징검다리 역할을 해요.

아래 버그를 수정해줘. 단, 바로 코드를 쓰지 말고
1. 버그의 원인이 뭔지 분석
2. 어떤 방향으로 수정할지 설명
3. 수정된 코드 작성
순서대로 단계별로 생각해서 답해줘.

한계: 왜 프롬프트만으로는 부족할까?

하지만 프롬프트 엔지니어링은 결국 '임시방편'이에요.

토큰의 휘발성: 질문이 길어질수록 프롬프트 자체가 차지하는 토큰이 많아져서 정작 코드를 짤 공간이 줄어들어요.

관리의 어려움: 질문을 살짝만 바꿔도 확률 분포가 뒤틀려 답변이 완전히 달라지는 '취약성'이 있어요.

노동 집약적: 매번 채팅창에 길게 설명하는 건 개발자의 생산성을 오히려 갉아먹어요.

---

프롬프트의 한계를 넘는 방법: 컨텍스트 엔지니어링

프롬프트는 '기술'이고, 컨텍스트는 '설계'예요

프롬프트 엔지니어링이 "지금 당장 이 문제를 잘 풀어봐!"라고 외치는 '응원'이라면 컨텍스트 엔지니어링은 "네 책상 위에 이 참고서들을 올려둘게. 여기서 정답을 찾아서 풀어"라고 환경을 세팅해 주는 '지원'이에요.

RAG (Retrieval-Augmented Generation): 외부 지식의 실시간 주입

LLM은 학습이 끝난 시점 이후의 정보나 로컬 컴퓨터에만 있는 '나만의 코드'를 알지 못해요. 이때 사용하는 핵심 기술이 바로 RAG(검색 증강 생성, Retrieval-Augmented Generation)예요.

작동 원리 (검색 후 생성)

1. 사용자가 "이 컴포넌트 로직 좀 고쳐줘"라고 질문해요.
2. 시스템이 질문 텍스트를 임베딩 벡터로 변환해요.
3. 프로젝트 내 문서, 코드 조각들도 미리 임베딩 벡터로 변환해서 저장해뒀기 때문에 질문 벡터와 각 문서 벡터 사이의 cosine similarity(코사인 유사도)를 비교해요.
4. 유사도가 높은 관련 코드 조각이나 API 명세서를 추출해서 프롬프트 앞에 '참고자료'로 붙여 AI에게 보내요.

앞서 설명한 임베딩이 바로 이 과정에서 실제로 써먹혀요. 질문과 문서를 같은 좌표 공간 위에 올려놓고 가장 가까운 것들을 찾아내는 거죠.

왜 강력한가?

AI가 자신의 희미한 '확률적 기억'에 의존하지 않고 눈앞에 있는 '실제 자료(Ground Truth)'를 보고 답변하게 만들기 때문이에요. 할루시네이션을 물리적으로 방어하는 가장 확실한 방법이죠.

Cursor에서 @Codebase를 사용하면 프로젝트 전체를 벡터 인덱싱해 관련 코드를 검색해 주입하는 방식으로 RAG와 유사한 동작을 해요. 반면 @파일명으로 특정 파일을 지정하는 건 해당 파일 전체를 컨텍스트에 직접 붙여넣는 방식(Context Stuffing)으로 RAG와는 구별돼요.

구조화된 지식 설계: 정적 컨텍스트와 동적 컨텍스트

컨텍스트 엔지니어링의 핵심은 "무엇을 고정하고 무엇을 유동적으로 줄 것인가"를 설계하는 거예요.

정적 컨텍스트 (Static Context)

프로젝트 전체에 적용되는 변하지 않는 규칙이에요. Cursor 기준으로는 .cursor/rules/ 디렉터리 아래에 .mdc 형식으로 규칙 파일을 두는 방식이 현재 표준이에요 (과거에 쓰던 .cursorrules 파일은 Cursor 0.45 이후 deprecated됐어요). 매 질문마다 "우리는 Tailwind를 써"라고 말할 필요 없이 시스템의 기본값(Default)으로 확률을 고정해버려요.

동적 컨텍스트 (Dynamic Context)

현재 작업 중인 파일, 관련된 타입 정의, 최신 API 응답 값 등 질문에 따라 바뀌는 정보예요. RAG가 이 부분을 담당해서 AI에게 필요한 만큼의 정보를 실시간으로 공급해요.

관심사 분리 (SoC)와 토큰 다이어트

AI가 한 번에 읽을 수 있는 토큰(Context Window)은 유한해요. 무조건 많이 주는 게 능사가 아니라는 뜻이에요. 너무 많은 정보를 주면 오히려 AI의 집중력(Attention)이 흩어지거든요.

프론트엔드에서 컴포넌트를 쪼개듯 컨텍스트도 쪼개야 해요. 전역 규칙은 루트의 설정 파일에 특정 기능에 대한 깊은 설명은 해당 폴더의 README.md에 배치해서 AI가 필요한 순간에 필요한 정보만 읽도록 유도하는 게 진정한 엔지니어링이에요.

---

프론트엔드 개발자는 LLM을 어떻게 다뤄야 할까

왜 인간이 보기 좋은 코드가 AI에게도 좋을까?

LLM은 인간과 문맥을 이해하는 방식이 다르지만(숫자와 확률) 역설적으로 인간이 읽기 좋게 짠 코드에서 압도적인 퍼포먼스를 내요. 그 이유는 LLM의 '학습 데이터'와 '추론 방식'에 숨겨져 있어요.

LLM의 교과서는 '사람이 쓴 깨끗한 코드'예요

LLM은 GitHub에 공개된 수억 줄의 코드를 학습했어요. 여기서 중요한 점은 AI가 성능이 검증된 오픈소스나 유명 라이브러리의 코드를 가장 비중 있게 공부했다는 거예요. 이런 고퀄리티 프로젝트들은 '클린 코드 가이드'를 철저히 따라요.

AI 입장에서 const a = 1; 같은 코드보다 const userCount = 1; 같은 코드가 훨씬 더 '익숙하고 정답일 확률이 높은' 데이터예요. 클린 코드를 작성하면 AI는 자신이 학습했던 가장 훌륭한 코드들의 확률 분포를 따라가며 정답을 내놓게 돼요.

변수명이 AI의 추론 품질을 바꿔요

나쁜 예시

// AI가 이 코드를 보면 혼란스러워요
function handler(data: any) {
  process(data);
}

data, handler, process 같은 이름은 의미 범위가 너무 넓어서, 모델이 이 토큰의 역할을 추론할 때 Attention 가중치가 분산돼요. 실제로 이런 상황을 겪었어요. data라는 이름의 변수가 API 응답 처리 함수와 폼 상태 관리 함수 두 곳에 있었는데 AI에게 수정을 요청했더니 엉뚱한 쪽을 건드렸거든요. "분명히 API 쪽 고치라고 했는데?" 싶었는데 알고 보니 AI가 '지금 이 data는 API 응답인가, 폼 상태인가?'를 컨텍스트로 구분하지 못하고 길을 잃은 거였어요.

좋은 예시

// AI가 이 코드를 보면 맥락을 즉시 파악해요
async function fetchUserProfileById(userId: string): Promise<UserProfile> {
  return await userApi.getProfile(userId);
}

fetchUserProfileById처럼 명확한 이름은 모델이 이 토큰의 역할을 추론할 때 Attention이 정확한 곳에 집중해요. 이름만 보고도 "아, 이건 사용자 프로필을 ID로 가져오는 비동기 함수구나!"라고 AI가 확신을 갖고 다음 로직을 예측할 수 있게 돼요.

토큰 효율성: 적은 양으로 최대의 정보량 전달

인간이 보기 좋은 코드는 보통 '관심사 분리(SoC)'가 잘 되어 있어요. 한 파일에 2,000줄이 들어있는 코드는 AI에게도 '토큰 과부하'를 줘요. 중요한 정보(맥락)가 중간에 섞여서 집중력(Attention)이 흐려지기 때문이에요. 기능을 작게 쪼개고 이름을 잘 지어놓으면 AI는 아주 적은 양의 토큰만 읽고도 현재 상황을 완벽하게 파악해요.

TypeScript: AI에게 주는 가장 강력한 '지도'

개발자에게 TypeScript는 귀찮은 존재?일 수 있지만 AI 협업에서는 치트키예요.

// 타입 정의가 있으면 AI는 이 구조를 참고해 코드를 생성해요
interface UserProfile {
  id: string;
  name: string;
  email: string;
  role: 'admin' | 'user' | 'guest';
}

// 타입 없이 작성하면 AI가 없는 프로퍼티를 만들어내기도 해요
function updateUser(user: UserProfile): void {
  // AI가 user.password 같은 없는 필드를 쓰는 환각을 줄여줘요
}

타입 정의는 AI에게 "이 객체는 이 구조를 기준으로 코드를 써줘"라고 강력한 가이드라인을 치는 것과 같아요. 타입을 잘 적어두면 AI가 존재하지 않는 프로퍼티를 사용하는 할루시네이션을 상당히 줄일 수 있어요. 다만 타입이 있다고 AI 코드 검토를 생략해도 된다는 의미는 아니에요.

---

정리

내일 당장 할 수 있는 것부터 시작해요.

1. AI 규칙 파일 만들기 - Cursor를 쓴다면 .cursor/rules/ 디렉터리에 .mdc 파일을 만들어보세요. 기술 스택, 코딩 컨벤션, 절대 쓰면 안 되는 패턴을 적어두면 매 대화마다 반복 설명하는 시간이 사라져요.
2. any 줄이기 - TypeScript 타입 정의를 느슨하게 any로 쓰던 곳이 있다면 하나씩 좁혀가세요.
3. 변수명 다듬기 - data, item, temp로 된 곳이 있다면 역할이 드러나는 이름으로 바꿔보세요.

---

프롬프트를 잘 쓰는 건 기술이에요. 근데 컨텍스트를 잘 설계하는 건 자산이에요. 한 번 만들어두면 다음 대화, 그 다음 대화 모델이 바뀌어도 계속 일해줘요.

AI가 어디서 길을 잃는지 알고 나면 이제 우리가 할 일은 그 길목에 이정표를 미리 세워두는 거예요. 그게 전부예요.

---

참고 자료

• 『LLM을 위한 프롬프트 엔지니어링』 - 존 베리먼, 엘버트 지글러 저, 제이펍 (2026)
• 『LLM 핵심 이론, 구조로 이해하기 -ChatGPT·RAG·Agent의 작동 원리를 한 번에-』 (인프런)
• Lost in the Middle: How Language Models Use Long Contexts - Liu et al., Stanford (2023)