AI Engineering 시각적으로 이해하기

모델이 한 번에 볼 수 있는 토큰 예산

토큰은 모델이 글을 읽을 때 쓰는 잘게 나뉜 단위이고, context window는 한 번의 호출에서 모델이 끝까지 붙잡고 볼 수 있는 작업 공간입니다. 시스템 지시, 지금 질문, 앞선 대화, 검색 문서, 도구 결과, 그리고 방금 만들 답변까지 전부 이 공간을 함께 씁니다.

모델 행동을 조정하는 지시 설계

prompt engineering은 모델에게 무엇을 하게 할지, 어떤 기준으로 답하게 할지, 어떤 형식과 태도를 지키게 할지를 지시하는 설계 작업입니다. 좋은 프롬프트는 문장을 예쁘게 꾸미는 기술이 아니라 작업 목표와 판단 기준을 모델이 오해하지 않도록 정리하는 일에 가깝습니다.

현재 호출에 맞는 정보를 골라 조립하는 설계

context engineering은 현재 호출에 필요한 정보만 골라 모델 앞에 배치하는 설계 방식입니다. 프롬프트 문구 자체보다, 어떤 대화 기록과 어떤 검색 결과와 어떤 상태 정보를 어떤 순서로 넣느냐가 더 큰 영향을 줄 때 이 개념이 중심에 옵니다.

자연어 대신 스키마로 결과를 받는 방식

structured output은 모델 결과를 자유로운 문장 대신 스키마에 맞는 객체나 필드 구조로 받는 방식입니다. 사람이 읽기 좋은 답을 만드는 것보다, 코드가 바로 읽고 검증하고 다음 단계로 넘길 수 있게 만드는 데 초점이 있습니다.

모델이 외부 도구를 호출해 데이터를 가져오거나 행동하는 방식

tool use는 모델이 외부 함수나 API를 직접 실행할 수 있는 것처럼 호출 의도를 표현하고, 애플리케이션이 그 호출을 실제로 수행하는 패턴입니다. 모델은 무엇을 물어봐야 하는지와 어떤 인자가 필요한지를 정하고, 실제 부작용은 런타임이 통제합니다.

의미를 벡터로 바꾸는 표현 기법

embeddings는 텍스트 같은 입력을 숫자 벡터로 바꿔 의미적 유사성을 계산할 수 있게 만드는 표현 방식입니다. 같은 단어를 쓰지 않아도 의미가 가까우면 벡터 공간에서 더 가까운 위치로 매핑되는 것이 핵심입니다.

문서를 검색 가능한 조각과 인덱스로 바꾸는 준비 단계

chunking과 indexing은 원문 문서를 검색 가능한 작은 단위로 나누고, 그 단위를 나중에 빠르게 찾을 수 있도록 저장하는 준비 단계입니다. RAG가 런타임 패턴이라면 chunking/indexing은 그 패턴이 의존하는 오프라인 데이터 준비층입니다.

외부 지식을 검색해 답변을 근거와 함께 생성하는 패턴

RAG는 질문 시점에 외부 지식을 검색해 그 결과를 모델 컨텍스트에 넣고 답변을 생성하는 패턴입니다. 모델 내부에 이미 기억된 내용만 믿지 않고, 현재 질문에 맞는 근거를 바깥에서 끌어와 답변을 grounding하는 데 목적이 있습니다.

목표를 여러 단계로 풀어가는 모델-도구 실행 루프

agent workflow는 모델이 한 번 답하고 끝나는 대신, 목표를 향해 여러 번 생각하고 도구를 쓰고 결과를 보고 다음 행동을 정하는 실행 루프입니다. 핵심은 '에이전트'라는 이름보다, 상태와 중간 관찰을 가진 multi-step 제어 구조라는 점입니다.

대화와 작업 상태를 다음 호출로 이어주는 저장층

memory는 한 번의 context window 밖으로 밀려나는 정보 중, 다음 호출에서도 다시 써야 하는 상태를 따로 저장해 두는 계층입니다. 사용자 선호, 진행 중인 작업, 이전 결정, 요약된 대화 기록 같은 것이 대표적입니다.

LLM 품질을 반복 가능하게 측정하는 테스트 체계

evals는 LLM 시스템의 품질을 감으로 보지 않고 반복 가능한 방식으로 측정하는 체계입니다. 프롬프트, 모델, retrieval, tool loop를 바꿨을 때 어떤 종류의 질문에서 좋아지고 나빠졌는지 비교 가능하게 만드는 것이 핵심입니다.

허용 범위와 실패 경로를 제어하는 안전 장치

guardrails는 시스템이 어떤 요청을 받아들이고, 어떤 도구를 쓰고, 어떤 형태의 결과를 내보낼 수 있는지를 통제하는 안전 장치입니다. 모델에게 '이렇게 해라'라고 말하는 수준을 넘어, 실제 런타임에서 허용 범위를 강제하는 계층에 가깝습니다.

LLM 시스템의 실패 원인을 추적하는 운영 계측

observability는 LLM 시스템 안에서 실제로 무슨 일이 벌어졌는지를 단계별로 추적할 수 있게 만드는 운영 계측입니다. 최종 답변만 보는 것이 아니라, 어떤 프롬프트가 들어갔고 어떤 문서가 검색됐고 어떤 도구가 얼마나 걸렸는지까지 연결해 보는 것이 핵심입니다.