🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

프로덕션 AI 시스템의 핵심 병목은 모델 자체보다 토큰·검색·에이전트 루프·평가·컨텍스트를 어떻게 설계하고 측정하느냐에 있다.

📌 핵심 요약

• AI 시스템은 크게 Memory(RAG), Thinking(LLM·토큰), Actions(Agent), Measurement(Evals)를 Context Engineering으로 조립한 구조로 볼 수 있다.
• 토큰과 컨텍스트 윈도우는 비용, 지시문 유지, 장기 대화 품질을 좌우하는 기본 병목이다.
• 임베딩과 벡터 검색은 문서·제품·사용자 프로필처럼 의미 기반 검색이 필요한 영역에서 RAG의 기반이 된다.
• RAG는 모델을 새로 학습시키지 않고 필요한 데이터를 질의 시점에 검색해 답변 근거로 제공하지만, 검색 품질이 낮으면 답변도 무너진다.
• 에이전트는 도구를 쓰며 반복 행동할 수 있지만, 종료 조건·오류 처리·단계 제한이 없으면 비용과 품질 문제가 빠르게 커진다.
• Evals는 프롬프트, 검색, 모델, 에이전트 변경이 실제로 개선인지 퇴보인지 판단하게 해주는 프로덕션 운영의 핵심 장치다.

🧩 주요 포인트

1. 토큰과 컨텍스트 윈도우는 모델이 “무엇을 볼 수 있는가”를 결정하며, 긴 히스토리와 불필요한 정보는 지시문을 묻히게 만든다.
2. 임베딩은 텍스트의 의미를 숫자 벡터로 바꾸고, 벡터 검색은 의미적으로 가까운 정보를 빠르게 찾는 메커니즘이다.
3. RAG는 검색된 문서를 컨텍스트에 넣어 모델이 내부 데이터에 근거해 답하게 하지만, 청킹과 검색 정확도가 낮으면 환각을 막지 못한다.
4. 에이전트는 목표를 받고 행동·관찰·판단을 반복하는 루프이며, 도구 사용보다 루프 제어가 더 중요하다.
5. Evals는 AI 시스템을 감이 아니라 수치로 바꾸며, 회귀와 개선을 구분하게 해준다.
6. 컨텍스트 엔지니어링은 어떤 정보를 넣고, 줄이고, 정렬하고, 제외할지 결정하는 작업으로 프롬프트보다 더 큰 영향을 줄 수 있다.

🧠 상세 정리

1. 프로덕션 AI의 병목은 모델 이전에 시스템 이해다

원문은 AWS 계정에 하룻밤 사이 200달러 요금이 발생한 사례로 시작한다. 시스템이 다운된 것도 아니고 모니터링 대시보드가 장애를 감지한 것도 아니었다. 문제는 한 에이전트가 종료 조건 없이 6시간 동안 루프를 돌며 매 반복마다 OpenAI API를 호출했다는 점이었다. 겉으로는 “정상”처럼 보였지만, 실제로는 비용과 토큰이 계속 소모되고 있었다. 이 사례가 보여주는 병목은 단순히 비싼 API나 나쁜 모델이 아니다. AI 시스템이 어떻게 작동하는지 모른 채 라이브러리를 설치하고 튜토리얼을 따라 API를 호출하는 방식으로는 프로덕션 문제를 설명하거나 예방하기 어렵다. 원문은 AI 시스템을 Memory(RAG), Thinking(LLM·Tokens), Actions(Agents), Measurement(Evals)를 Context Engineering으로 조립한 구조로 요약한다.

2. 토큰과 컨텍스트 윈도우: 모델이 볼 수 있는 정보의 한계

LLM은 단어가 아니라 토큰이라는 단위로 입력을 처리한다. 공백과 구두점도 토큰에 포함될 수 있으며, 모델마다 한 번에 담을 수 있는 토큰 수인 컨텍스트 윈도우가 있다. 원문은 이를 회의실 화이트보드에 비유한다. 모델은 화이트보드에 적힌 내용만 볼 수 있고, 보드가 차면 오래된 내용은 밀려난다. 모델의 사고 능력이 사라지는 것이 아니라, 이전 정보에 접근하지 못하게 되는 것이다. 이 한계는 프로덕션에서 비용과 품질 문제로 이어진다. 모든 API 호출은 입력·출력 토큰에 따라 과금되고, 긴 대화 기록은 컨텍스트를 빠르게 채운다. 컨텍스트가 가득 차면 중요한 지시문이 사실상 덜 반영되거나 묻힐 수 있다. 원문 사례처럼 12개월치 고객 지원 대화를 매 요청마다 넣은 팀은 테스트에서는 잘 작동했지만, 실제 운영에서 대화가 길어지자 시스템 프롬프트가 8만 토큰 규모의 히스토리 아래 묻혀 버렸다. 해결책은 더 강한 모델이 아니라 오래된 히스토리를 요약해 컨텍스트를 집중시키는 것이었다.

3. 임베딩과 벡터 검색: 의미를 숫자로 바꿔 찾는 방식

임베딩은 텍스트의 의미를 숫자 벡터로 변환한다. 이 메커니즘의 목적은 “비슷함”을 수학적으로 계산할 수 있게 만드는 것이다. 예를 들어 5만 개 문서 중 사용자의 질문과 가장 관련 있는 3개 문서를 찾아야 할 때, 단순 키워드 검색은 한계가 있다. 문서에는 “automobile”이라고 쓰여 있고 사용자는 “cars”라고 묻는다면, 키워드는 일치하지 않지만 의미는 가깝다. 벡터 검색은 이 문제를 기하학적으로 처리한다. 각 문서를 벡터로 변환해 저장하고, 사용자의 질문도 벡터로 변환한 뒤, 질문 벡터와 가장 가까운 저장 벡터를 찾는다. “car”와 “automobile”은 가까이 있고, “car”와 “photosynthesis”는 멀리 있는 식이다. 이 구조는 문서 시스템의 의미 검색, 유사 제품·기사·사용자 프로필 탐색, RAG의 검색 단계, AI 에이전트의 메모리 기능에 사용된다.

4. RAG: 모델을 다시 학습시키지 않고 필요한 데이터를 넣는 구조

RAG는 Retrieval-Augmented Generation의 약자로, 모델을 내부 데이터로 다시 학습시키는 대신 질문 시점에 관련 데이터를 검색해 컨텍스트에 넣는 방식이다. LLM은 일반 지식은 많이 갖고 있지만 회사 내부 문서, 제품 데이터베이스, 고객 지원 이력 같은 사유 데이터는 알지 못한다. 이를 해결하는 한 방법은 모델을 재학습시키는 것이지만, 원문은 이것이 비싸고 느리며 금방 오래된 데이터가 된다고 설명한다. RAG의 기본 파이프라인은 세 단계다. 먼저 질문을 벡터로 바꾸고 벡터 데이터베이스에서 가장 유사한 문서 조각을 검색한다. 다음으로 검색된 문서를 모델의 컨텍스트에 추가한다. 마지막으로 모델은 그 컨텍스트를 바탕으로 답변을 생성한다. 하지만 RAG는 검색이 나쁘면 그대로 무너진다. 500페이지 기술 매뉴얼을 1,000토큰 단위로 단순 분할한 사례에서는 표가 중간에 잘리고 단계별 설명도 끊겨, 검색은 대략 맞는 영역을 찾았지만 실제 답을 놓쳤다. 청크 크기를 줄이고 겹침을 추가하자 상당수 문제가 개선됐다.

5. 에이전트 루프: 행동하는 AI에는 반드시 제어 장치가 필요하다

일반적인 LLM 호출은 상태가 없다. 사용자가 묻고 모델이 답하면 끝난다. 반면 에이전트는 목표를 받고, 다음 행동을 결정하고, 도구를 실행하고, 결과를 관찰한 뒤, 다시 다음 행동을 결정한다. 이 루프 덕분에 에이전트는 웹 검색, 파일 읽기, 코드 작성, API 호출 같은 실제 행동을 수행할 수 있다. 하지만 이 힘은 동시에 위험이 된다. 원문은 초보자가 자주 놓치는 지점을 세 가지로 정리한다. 종료 조건이 없는 에이전트는 계속 실행될 수 있고, 도구가 많다고 항상 성능이 좋아지는 것은 아니며, 도구 오류를 명시적으로 처리하지 않으면 에이전트가 잘못된 결과를 자신 있게 생성할 수 있다. 200달러 비용 사고도 이 구조에서 발생했다. 빈 검색 결과를 받은 에이전트가 멈추지 못하고 재검색과 중간 요약을 반복해 847번의 LLM 호출과 210만 토큰을 소비했다. 해결은 최대 단계 수, 빈 결과 처리, 낮은 신뢰도 시 에스컬레이션 경로를 넣는 것이었다.

6. Evals: 데모와 제품을 가르는 측정 체계

Evals는 AI 시스템이 실제로 잘 작동하는지, 변경이 개선인지 회귀인지 판단하는 방법이다. 프롬프트를 바꾸고, 검색 로직을 수정하고, 새 모델로 전환했을 때 “좋아진 것 같다”는 느낌만으로는 프로덕션 판단을 할 수 없다. 원문은 이 지점을 튜토리얼이 자주 건너뛰지만 실제 제품에서는 핵심이라고 강조한다. 실용적인 eval은 정답이 알려진 실제 입력 25~50개로 구성된 golden dataset에서 시작한다. 주요 사용 사례와 어려운 엣지 케이스를 포함하고, 가능하면 이진 지표를 사용한다. 예를 들어 RAG가 올바른 문서를 검색했는지, 에이전트가 오류 없이 완료했는지, 답변에 필수 정보가 포함됐는지 등을 Yes/No로 측정한다. 이후 검색 정확도나 작업 완료율을 시간에 따라 추적하면, 어떤 변경이 성능을 89%에서 84%로 낮췄는지 또는 76%에서 81%로 올렸는지 확인할 수 있다.

7. 컨텍스트 엔지니어링: 프롬프트가 작동할 환경을 설계하는 일

컨텍스트 엔지니어링은 모델의 컨텍스트 윈도우에 어떤 정보를 넣고, 어떤 순서로 배치하고, 무엇을 제외할지 결정하는 작업이다. 원문은 좋은 프롬프트보다 잘 정리된 컨텍스트가 더 중요할 수 있다고 주장한다. 훌륭한 지시문도 노이즈 속에 묻히면 모델이 제대로 사용하지 못한다. 초보적인 접근은 모든 히스토리, 모든 검색 문서, 모든 도구 설명, 시스템 프롬프트, 사용자 메시지를 한꺼번에 넣는 것이다. 그러나 정보가 많아질수록 무엇이 중요한지 흐려지고, 긴 컨텍스트의 중간에 묻힌 정보가 덜 사용되는 “lost in the middle” 문제가 발생할 수 있다. 실제 컨텍스트 엔지니어링은 필요한 정보 선택, 오래된 대화 압축, 중요한 지시문의 위치 조정, 품질에 영향을 주지 않는 정보 제거, 헤더와 구분자 같은 구조 설계를 포함한다. 즉 프롬프트 엔지니어링이 좋은 지시문을 쓰는 일이라면, 컨텍스트 엔지니어링은 그 지시문이 실제로 따라질 수 있는 환경을 만드는 일이다.

🧾 핵심 주장 / 시사점

• 프로덕션 AI 문제의 상당수는 모델 성능 부족이 아니라 토큰, 컨텍스트, 검색, 루프 제어, 평가 부재에서 발생한다.
• RAG의 품질은 LLM보다 검색과 청킹 품질에 크게 좌우되며, 잘못된 검색을 프롬프트만으로 보정하기는 어렵다.
• 에이전트는 반드시 종료 조건, 단계 제한, 오류 처리, 낮은 신뢰도 대응 경로를 포함해야 한다.
• Evals 없이 운영되는 AI 시스템은 변경의 효과를 검증할 수 없기 때문에 안정적으로 개선하기 어렵다.
• 컨텍스트 엔지니어링은 Memory, Thinking, Actions, Measurement를 연결하는 접착제 역할을 한다.

✅ 액션 아이템

• 현재 운영 중인 LLM 호출에서 입력·출력 토큰 비용과 컨텍스트 윈도우 사용량을 추적한다.
• RAG 시스템이 있다면 검색된 문서가 실제 정답 문서인지 측정하는 retrieval accuracy 지표를 만든다.
• 에이전트 워크플로에 최대 단계 수, 최대 실행 시간, 빈 결과 처리, 도구 오류 처리 규칙이 있는지 점검한다.
• 주요 사용 사례와 실패 사례를 포함한 25~50개 규모의 golden dataset을 구성해 변경 전후 성능을 비교한다.

❓ 열린 질문

• 현재 AI 시스템의 실패가 프롬프트 문제인지, 아니면 컨텍스트 윈도우·검색·청킹 문제인지 어떻게 구분하고 있는가?
• 에이전트가 목표를 완료하지 못하거나 도구가 빈 결과를 반환했을 때, 멈추거나 에스컬레이션하는 명확한 조건이 있는가?
• 운영 중인 RAG나 에이전트 변경은 정량 eval로 검증되고 있는가, 아니면 일부 예시를 수동 확인하는 수준에 머물러 있는가?