어느 날 AWS 계정에 200달러 청구서가 생긴 걸 봤습니다.
시스템이 다운된 게 아니었어요.
한 에이전트가 중단 조건 없이 6시간 동안 루프를 돌며 매번 OpenAI API를 호출한 겁니다.
모든 모니터링 대시보드는 정상이라고 표시했어요.
아무도 눈치채지 못하다가 아침에 청구서가 도착했죠.
이것이 바로 AI 시스템을 실제로 어떻게 작동하는지 이해하지 않고 구축했을 때 일어나는 일입니다.
대부분의 사람들은 AI 엔지니어링을 거꾸로 배웁니다.
라이브러리를 설치합니다. 튜토리얼을 따라 합니다. API를 호출합니다. 뭔가 작동하게 만듭니다. 발전하고 있다고 느낍니다.
그러다 이해할 수 없는 방식으로 무언가가 고장 납니다.
멈출 때까지 숫자를 무작위로 바꿉니다.
그건 엔지니어링이 아닙니다. 키보드로 하는 희망입니다.
이 문제를 해결하는 6가지 개념이 여기 있습니다.
모든 것을 설명하는 한 문장
아무리 복잡한 AI 시스템도 결국 다음일 뿐입니다:
메모리 (RAG) + 사고 (LLM + 토큰) + 행동 (에이전트) + 측정 (평가)
…이 모든 것이 컨텍스트 엔지니어링 (Context Engineering) 을 통해 조립됩니다.
그게 이 분야의 전부입니다.
아래 내용은 각 부분이 실제로 무엇을 의미하는지 풀어낸 것일 뿐입니다.
1. 토큰과 컨텍스트 윈도우
LLM은 단어를 읽지 않습니다. 토큰이라는 덩어리를 읽습니다.
"engineering" → 1 토큰
"unbelievable" → 2 토큰 공백과 구두점도 포함됩니다.
모든 모델에는 컨텍스트 윈도우가 있습니다. 한 번에 담을 수 있는 토큰의 엄격한 한계입니다.
→ Claude: 200,000 토큰
→ GPT-5: 400,000 토큰
회의실 화이트보드라고 생각하면 됩니다.
모델은 현재 보드에 있는 것만 가지고 작업합니다.
보드가 가득 차면 오래된 노트가 지워져 새 공간을 만듭니다.
모델이 생각하는 능력을 잃는 것은 아닙니다.
이전 정보에 접근할 수 없게 되는 것입니다.
이것이 프로덕션 시스템을 망가뜨리는 이유:
→ 토큰은 비용이 듭니다 — 모든 API 호출은 입력 및 출력 토큰당 비용이 청구됩니다
→ 긴 채팅 기록은 윈도우를 빠르게 채웁니다
→ 컨텍스트가 가득 차면 이전 지침이 조용히 사라집니다
→ 컨텍스트에 무엇을 넣을지는 엔지니어링 결정이지 기본값이 아닙니다
이를 증명하는 실패 사례:
한 팀이 모든 요청에 대해 12개월 전체 채팅 기록을 컨텍스트로 제공하는 고객 지원 에이전트를 구축했습니다.
5번의 상호작용으로 테스트했을 때는 완벽하게 작동했습니다.
프로덕션에서 50번의 상호작용 후, 에이전트가 자체 시스템 프롬프트를 무시하기 시작했습니다.
지침은 여전히 있었습니다.
80,000 토큰의 대화 기록 아래에 묻혀 있었습니다.
모델이 효과적으로 더 이상 그것에 주목하지 않게 된 것입니다.
해결책은 더 나은 모델이 아니었습니다.
컨텍스트를 집중적으로 유지하기 위해 오래된 기록을 요약하는 것이었습니다.
불편한 진실:
대부분의 "프롬프트 엔지니어링 실패"는 실제로는 토큰 및 컨텍스트 윈도우 실패로 위장된 것입니다.
엔지니어들은 프롬프트를 비난하지만, 실제 문제는 중요한 지침이 500줄 컨텍스트의 3번째 줄에 있고 모델이 더 이상 가중치를 부여하지 않는다는 점입니다.
2. 임베딩과 벡터 검색
임베딩은 의미를 숫자로 변환하여 "유사성"을 수학적으로 계산할 수 있게 만듭니다.
임베딩이 해결하는 문제:
50,000개의 문서가 있습니다. 사용자가 질문을 합니다. 매번 50,000개를 모두 읽지 않고 가장 관련성 높은 3개를 찾아야 합니다.
키워드 검색은 여기서 실패합니다.
문서에 "자동차"라고 쓰여 있고 사용자가 "차"에 대해 묻는다면 키워드 검색은 찾지 못합니다.
답이 없어서가 아니라 단어가 일치하지 않았기 때문입니다.
임베딩은 이 문제를 다르게 해결합니다.
임베딩 모델은 텍스트를 벡터, 즉 수학적 공간에서 의미를 나타내는 숫자 목록으로 변환합니다.
의미적으로 유사한 텍스트 → 숫자적으로 유사한 벡터
"car"와 "automobile" → 가까이 위치
"car"와 "photosynthesis" → 멀리 위치
벡터 검색의 실제 작동 방식:
- 모든 문서가 벡터로 변환되어 저장됩니다
- 사용자의 질문도 벡터가 됩니다
- 시스템은 질문 벡터에 가장 가까운 저장된 벡터를 찾습니다
- 그것들이 가장 관련성 높은 문서입니다
이것은 대략적인 마법이 아닙니다. 기하학입니다.
유사성은 계산할 수 있는 실제 수학적 속성입니다.
프로덕션에서 나타나는 곳:
→ 모든 문서 시스템의 의미 검색
→ 유사한 제품, 기사, 사용자 프로필 찾기
→ RAG의 검색 단계 (다음 개념)
→ AI 에이전트의 메모리
3. RAG (검색 증강 생성)
모델을 데이터에 대해 훈련시키는 대신, 쿼리 시점에 관련 데이터를 검색하여 모델에 컨텍스트로 제공합니다.
RAG가 해결하는 문제:
LLM은 많은 것을 알고 있습니다. 하지만 사용자의 데이터는 모릅니다.
회사의 내부 문서, 제품 데이터베이스, 고객 지원 기록 등.
그 어느 것도 훈련 세트에 없었습니다.
두 가지 선택지가 있습니다: 데이터에 대해 모델을 훈련시키거나 (비용이 많이 들고 느리며 즉시 구식이 됨) 모델이 필요할 때 정확히 데이터를 제공하는 것입니다.
RAG는 두 번째 선택지를 체계적으로 수행합니다.
3단계 파이프라인:
→ 검색 (RETRIEVE):
질문이 벡터가 됨 → 벡터 데이터베이스가 가장 유사한 저장 문서를 찾음 → 상위 3-5개 청크 검색
→ 증강 (AUGMENT):
검색된 문서가 모델의 컨텍스트에 추가됨 → 프롬프트는 "이 컨텍스트를 사용하여 이 질문에 답하세요"가 됨
→ 생성 (GENERATE):
모델이 실제 데이터에 기반한 답변을 생성 — 환각이 아님
RAG가 무너지는 지점:
→ 잘못된 검색 = 잘못된 답변. 모델은 받은 정보로만 작업할 수 있음
→ 잘못된 청킹은 답변과 컨텍스트를 분리함
→ 검색이 유용한 것을 찾지 못하면 모델이 여전히 환각할 수 있음
실제 RAG 실패 사례:
한 팀이 500페이지 기술 매뉴얼을 위한 내부 지식 어시스턴트를 구축했습니다.
데모에서는 완벽하게 작동했습니다. 프로덕션에서는 답변이 모호하고 때로는 틀렸습니다.
문제는 청크 크기였습니다.
매뉴얼을 원시 문자 수 기준으로 1,000토큰 청크로 나누었습니다.
표는 중간 행에서 나뉘었고, 단계별 지침은 중간 단계에서 나뉘었습니다.
검색은 올바른 일반 영역을 찾고 있었지만 실제 답변은 놓치고 있었습니다.
청크 크기를 절반으로 줄이고 중복을 추가하자 문제의 80%가 하룻밤 사이에 해결되었습니다.
단호한 의견:
RAG는 검색이 나쁠 때 과대평가됩니다.
LLM은 나쁜 검색을 고칠 수 없습니다. 단지 그 주변에서 환각할 수 있을 뿐입니다.
잘못된 답변이 보인다면 프롬프트를 조정하는 것을 중단하세요.
검색 정밀도를 측정하기 시작하세요.
거기에 답이 있습니다.
4. 에이전틱 루프 (Agentic Loop)
에이전트는 작업이 완료될 때까지 행동을 반복적으로 선택하고, 실행하고, 결과를 관찰하고, 다음에 무엇을 할지 결정함으로써 작동합니다.
일반 LLM 호출은 상태가 없습니다 (stateless). 물으면 답하고 끝입니다.
에이전트는 상태가 있습니다 (stateful). 행동하고, 관찰하고, 결정하고, 반복합니다.
루프를 평범한 영어로 설명하면:
- 목표를 받습니다
- 다음 행동을 결정합니다
- 실행합니다 — 검색, 코드, 파일 읽기
- 결과를 관찰합니다
- 학습한 내용을 바탕으로 다음 행동을 결정합니다
- 목표가 완료될 때까지 반복합니다
- 최종 답변을 반환합니다
도구는 에이전트에 힘을 실어줍니다.
도구 없이 LLM은 텍스트로만 응답합니다.
도구를 사용하면 웹 검색, 파일 읽기, 코드 작성, API 호출, 정의된 모든 작업을 실행할 수 있습니다.
초보자가 항상 잘못하는 세 가지:
→ 중단 조건이 없는 에이전트는 영원히 실행됩니다. 중단 시점을 정의해야 합니다 — 단계 제한, 시간 제한 또는 목표 조건
→ 더 많은 도구 ≠ 더 나은 성능. 도구가 너무 많으면 모델이 어떤 것을 사용해야 할지 혼란스러워짐
→ 도구 오류는 명시적으로 처리해야 합니다. 조용한 실패는 에이전트가 자신 있게 쓰레기를 생성하게 만듦
하룻밤 사이의 200달러 실패, 자세히:
에이전트에는 최대 단계 수가 없었습니다. 목표: 주제를 연구하고 요약을 생성하기.
웹 검색 도구 중 하나가 빈 결과를 반환했습니다.
에이전트는 중단하는 방법을 몰랐습니다.
계속 검색하고, 재시도하고, 중간 요약을 생성했습니다 — 각각이 또 다른 검색을 촉발했습니다.
6시간 후: 847번의 LLM 호출. 2,100,000 토큰 소비. 일관성 있어 보이지만 완전히 순환적인 요약. 200달러 청구서.
해결책은 세 줄이었습니다: 최대 단계 카운터, 빈 결과에 대한 명시적 핸들러, 신뢰도가 낮을 때의 에스컬레이션 경로.
동일한 에이전트는 이제 평균 12회 미만의 호출로 완료됩니다.
당신이 들어야 할 의견:
대부분의 에이전트는 모델이 나빠서 실패하는 것이 아니라 엔지니어가 루프를 자체 관리되는 것처럼 취급하기 때문에 실패합니다.
그렇지 않습니다.
가드레일, 중단 조건, 오류 핸들러 — 첫 번째 사고 후에 추가하는 것이 아니라 처음부터 내장되어야 합니다.
5. 평가 (Evals)
평가는 AI 시스템이 실제로 작동하는지, 그리고 변경 사항이 더 나아졌는지 나빠졌는지 알 수 있는 방법입니다.
이 개념은 화려하지 않기 때문에 대부분의 튜토리얼이 건너뛰는 부분입니다.
데모를 만드는 엔지니어와 프로덕션 시스템을 구축하는 엔지니어를 구분하는 것이기도 합니다.
평가가 없는 문제:
프롬프트를 변경합니다. 검색 로직을 업데이트합니다. 최신 모델로 전환합니다.
더 나아졌나요?
알 수 없습니다. 몇 가지 예제를 수동으로 확인할 수는 있지만 그것은 느낌일 뿐 증거가 아닙니다.
평가의 실제 모습:
→ 골든 데이터셋: 주요 사용 사례와 5가지 알려진 까다로운 엣지 케이스를 포함하는 25-50개의 실제 입력과 알려진 올바른 출력
→ 가능한 경우 이진 메트릭:
— RAG 시스템이 올바른 문서를 검색했나요? 예/아니오
— 에이전트가 오류 없이 완료했나요? 예/아니오
— 응답에 필요한 정보가 포함되어 있나요? 예/아니오
→ 시간 경과에 따른 종합 점수 추적:
— 검색 정확도: 89% → 변경 후 → 84%. 회귀 발견.
— 작업 완료율: 76% → 새 에이전트 버전 → 81%. 개선 확인.
평가 주기:
배포 → 평가로 측정 → 실패 발견 → 실패를 골든 데이터셋에 추가 → 수정 → 다시 평가 실행 → 점수 비교 → 숫자가 개선된 경우에만 출시
솔직한 진실:
"도움 정도: 3.7/5"는 실행 가능한 정보를 제공하지 않습니다.
"올바른 문서를 84%의 시간 동안 검색함"은 문제가 정확히 어디에 있는지와 수정이 얼마나 개선되었는지 알려줍니다.
평가가 없는 AI 시스템은 제품이 아닙니다.
자신 있게 변경할 수 없는 데모입니다.
6. 컨텍스트 엔지니어링 (Context Engineering)
모델의 컨텍스트 윈도우에 어떤 정보를 넣을지, 어떻게 구조화할지, 무엇을 제외할지 정확히 결정하는 학문입니다.
사람들을 불편하게 만드는 의견이 있습니다:
컨텍스트 엔지니어링이 프롬프트 엔지니어링보다 더 중요합니다.
잘 정리된 컨텍스트의 평범한 프롬프트가 노이즈에 묻힌 훌륭한 프롬프트보다 항상 더 나은 성능을 냅니다.
대부분의 팀은 최적화 노력의 80%를 프롬프트에 쏟고 컨텍스트에는 거의 신경 쓰지 않습니다.
결과가 그것을 반영합니다.
순진한 접근 방식은 실패합니다:
모든 것을 포함합니다. 모든 기록. 모든 검색된 문서. 모든 도구 설명. 시스템 프롬프트. 사용자 메시지. 모두.
일관된 이유로 실패합니다: 모델이 무엇이 가장 중요한지 혼란스러워합니다.
"중간에서 길을 잃다"라는 문서화된 효과가 있습니다 — 긴 컨텍스트 깊숙이 묻힌 정보는 사용될 가능성이 낮아집니다.
컨텍스트 엔지니어링이 실제로 수반하는 것:
→ 선택: 이 특정 결정에 어떤 문서, 사실 또는 기록이 필요한가?
→ 압축: 대화의 오래된 부분을 요약하여 토큰을 절약할 수 있는가?
→ 순서: 중요한 지침은 시작과 끝에 있어야 함 — 중간이 아님
→ 가지치기: 출력 품질에 영향을 주지 않고 제거할 수 있는 것은 무엇인가?
→ 구조: 헤더, 구분자, 레이블이 지정된 섹션은 모델이 정보를 얼마나 안정적으로 사용하는지에 영향을 미침
실용적인 예:
에이전트가 45분 동안 실행되었습니다. 80,000 토큰의 대화 기록이 누적되었습니다. 윈도우는 128,000입니다.
기록이 윈도우를 채우더라도 원래 목표와 제약 조건을 잃고 싶지 않습니다.
컨텍스트 엔지니어링: 오래된 도구 출력을 압축하고, 이전 추론을 요약하고, 세션 내내 작업 정의를 두드러지게 유지합니다.
프롬프트 엔지니어링은 좋은 지침을 작성하는 것입니다.
컨텍스트 엔지니어링은 해당 지침이 실제로 따르는 환경을 구축하는 것입니다.
이 6가지 개념이 하나의 시스템을 형성하는 방법
메모리 → RAG + 임베딩 (시스템이 아는 것)
사고 → LLM + 토큰 + 컨텍스트 윈도우 (아는 것을 바탕으로 추론하는 방법)
행동 → 에이전틱 루프 + 도구 (세상에서 할 수 있는 것)
측정 → 평가 (작동하는지 아는 방법)
접착제 → 컨텍스트 엔지니어링 (위의 모든 것 사이에 무엇이 흐를지 결정하는 것)
간단한 챗봇은 사고만 있습니다.
고객 지원 에이전트는 메모리 + 사고 + 행동입니다.
신뢰할 수 있는 프로덕션 시스템은 측정을 추가합니다.
정교함은 구성 요소가 얼마나 잘 연결되는지에 있습니다.
단일 요청의 흐름:
사용자 질문
→ 컨텍스트 엔지니어링이 포함할 내용 결정
→ 임베딩이 관련 메모리 검색 (RAG)
→ 토큰이 윈도우에 얼마나 들어갈지 결정
→ LLM이 조립된 컨텍스트를 바탕으로 추론
→ 에이전틱 루프가 더 많은 정보가 필요한지 결정
→ 평가가 출력이 실제로 올바른지 측정
어디서부터 시작할까
여섯 가지를 모두 한 번에 마스터할 필요는 없습니다.
→ 토큰과 컨텍스트 윈도우부터 시작하세요 — 구축하는 모든 것에 영향을 미칩니다 → 의미 검색이나 메모리가 필요할 때 임베딩을 추가하세요
→ 모델을 자체 데이터에 기반해야 할 때 RAG를 배우세요
→ 자동화가 필요할 때 에이전틱 루프를 배우세요
→ 무엇이든 프로덕션에 출시하기 전에 평가를 추가하세요
→ 다른 모든 것이 직관적이 될 때 컨텍스트 엔지니어링을 적용하세요
이 순서는 임의적이지 않습니다.
각 개념은 다음 개념을 배우기 쉽게 만듭니다.
솔직한 최종 의견
프로덕션에서 AI로 어려움을 겪는 대부분의 팀은 잘못된 모델이나 잘못된 라이브러리 때문에 어려움을 겪는 것이 아닙니다.
이 여섯 가지 개념 중 하나를 건너뛰었기 때문에 어려움을 겪는 것입니다.
에이전트가 영원히 루프를 도는 이유는 아무도 중단 조건을 생각하지 않았기 때문입니다.
RAG 답변이 틀린 이유는 아무도 검색을 측정하지 않았기 때문입니다.
프롬프트가 긴 세션에서 작동을 멈추는 이유는 아무도 컨텍스트 윈도우가 어떻게 채워지는지 이해하지 못했기 때문입니다.
이것들은 정교한 문제가 아닙니다.
기술적인 용어로 포장된 기본적인 문제들입니다.
도구는 6개월마다 바뀝니다.
이 여섯 가지 개념은 도구가 작동하는 방식입니다.
개념을 배우면 새 도구에 절대 혼란스러워하지 않을 것입니다.
더 중요한 것은 — 에이전트가 밤새 루프를 도는 모습을 보며 무슨 일이 일어났는지 궁금해하며 200달러를 쓰지 않을 것입니다.
이것이 도움이 되었다면:
→ 이 글을 리포스트하여 아는 모든 AI 엔지니어와 공유하세요
→ 더 많은 시스템과 분석을 위해 @sairahul1을 팔로우하세요
→ 북마크에 추가하세요 — 다음에 프로덕션에서 무언가가 고장 났을 때 참조하게 될 것입니다
저는 AI, 제품 구축, 그리고 당신이 잠자는 동안 작동하는 시스템에 대해 글을 씁니다.
