RAGRetrieval-Augmented Generation
질문에 맞는 문서를 먼저 찾아 프롬프트에 붙인 뒤 답하게 해, 학습에 없던 최신·사내 정보를 쓰게 하는 구조.
품질 문제의 대부분은 생성이 아니라 검색에서 난다 — 답이 틀리면 모델부터 바꾸지 말고 무엇이 검색됐는지 찍어봐라.
같이 볼 것 청킹 · 벡터 DB · 리랭커 · 컨텍스트 엔지니어링
05
에이전트·도구
카드에 자꾸 나오는 용어와, 그걸 알고 나면 무엇이 달리 읽히는지.
28개
에이전트Agent
목표를 받아 스스로 도구를 골라 쓰고, 결과를 보고 다음 수를 정하며 여러 턴을 도는 LLM 프로그램.
제목에 이 말이 붙으면 한 번의 답 품질이 아니라 실패해도 계속 도는 루프 이야기다 — 채점 기준이 정답률에서 완주율로 바뀐다.
하네스Harness
모델 바깥에서 프롬프트·도구·절차·재시도·중단 조건을 붙여 일을 끝까지 끌고 가는 실행 껍데기.
같은 모델로 점수가 껑충 뛴 발표는 대개 여기를 고친 것이다 — 모델 자랑인지 껍데기 자랑인지부터 가르고 읽어라.
같이 볼 것 에이전트 루프 · Terminal-Bench · 검증기 · 오케스트레이션
에이전트 루프Agent loop
생각 → 도구 호출 → 결과 관찰을 한 바퀴 돌고, 그 관찰을 다음 프롬프트에 다시 넣는 반복 구조.
한 번의 답이 아니라 이게 몇 바퀴 도느냐가 비용이다 — 토큰 요금이 터지는 자리는 거의 여기다.
툴 유즈Tool use
모델이 직접 답하는 대신 검색·실행·파일 쓰기 같은 외부 기능을 불러 그 결과를 받아 쓰는 방식.
모델이 틀리는 자리와 도구가 틀리는 자리는 다르다 — 디버깅은 어느 쪽이 잘못됐는지 가르는 데서 시작한다.
함수 호출Function calling
모델이 쓸 수 있는 기능의 이름과 인자 형식을 미리 알려주고, 그중 하나를 골라 인자를 채운 요청을 내놓게 하는 규약.
이름과 설명이 곧 프롬프트다 — 도구가 안 불리면 코드가 아니라 설명 한 줄이 범인인 경우가 많다.
구조화 출력Structured output
자유 문장 대신 미리 정한 스키마에 맞는 JSON만 나오도록 출력 형식을 강제하는 방식.
파싱 실패로 파이프라인이 죽는 자리를 없애 주지만, 스키마가 좁으면 모델이 할 말을 못 해 값이 뭉개진다.
MCPModel Context Protocol
도구와 데이터 소스를 한 규격으로 노출해, 어느 클라이언트에 붙여도 같은 방식으로 쓰게 하는 개방 프로토콜.
서버 하나를 만들면 여러 클라이언트가 같이 쓴다 — 대신 붙인 서버가 늘수록 도구 설명이 컨텍스트를 갉아먹는다.
같이 볼 것 툴 유즈 · 함수 호출 · 컨텍스트 엔지니어링 · 프롬프트 인젝션나온 자리 레포
에이전트 스킬Agent Skills
언제 쓰는지와 절차를 적어 둔 문서 묶음을 필요할 때만 읽혀서, 그 작업의 수행법을 그때 주입하는 방식.
상시 프롬프트를 안 늘리고 능력을 붙이는 값싼 수단이지만, 언제 불릴지 정하는 한 줄이 흐리면 그냥 안 불린다.
같이 볼 것 하네스 · 컨텍스트 엔지니어링 · AGENTS.md · 코딩 에이전트
AGENTS.md
빌드·테스트·코딩 규칙 같은 저장소 사용법을 코딩 도구가 읽도록 루트에 두는 규약 파일.
에이전트가 남의 저장소에서 테스트 명령부터 헤맨다면 대개 이 파일이 없어서다 — 규칙은 대화가 아니라 저장소에 적어야 남는다.
같이 볼 것 코딩 에이전트 · 에이전트 스킬 · 컨텍스트 엔지니어링 · 하네스
코딩 에이전트Coding agent
저장소를 직접 읽고 고치고 테스트를 돌려, 지시 하나를 커밋 가능한 변경까지 끌고 가는 도구.
자동완성과 다른 점은 결과가 아니라 과정이다 — 테스트를 스스로 돌릴 수 있느냐가 이 부류의 갈림길이다.
샌드박스Sandbox
모델이 만든 코드나 명령을 격리된 환경에서만 돌려, 실패해도 바깥이 안 망가지게 막는 실행 공간.
에이전트에게 셸을 주는 순간 필요한 물건이다 — 다만 도구 목록에 삭제나 push가 있으면 격리보다 승인선이 먼저다.
컴퓨터 유즈Computer use
화면을 보고 마우스·키보드를 움직여, API가 없는 프로그램까지 사람처럼 조작하게 하는 방식.
API가 없는 사내 툴을 자동화하는 마지막 수단이고, 그만큼 느리고 잘 깨져 단계마다 증거를 남겨야 한다.
청킹Chunking
긴 문서를 검색 단위로 자르는 작업으로, 자르는 크기와 겹침이 무엇이 찾아지는지를 결정한다.
표나 코드가 중간에서 잘리면 그 문서는 사실상 검색에서 사라진다 — 실패 사례는 대개 이 단계에 있다.
벡터 DBVector database
텍스트를 뜻이 담긴 숫자 배열로 바꿔 저장하고, 가까운 것끼리 빠르게 찾아 돌려주는 저장소.
키워드가 안 겹쳐도 찾아주는 대신, 사번이나 에러 코드처럼 글자 그대로 맞아야 하는 검색에는 약하다.
리랭커Reranker
1차 검색이 건져 온 후보 수십 개를 질문과 한 번 더 대조해 순서를 다시 매기는 작은 모델.
상위 5개만 프롬프트에 들어간다면 순서가 곧 답이다 — 검색기를 갈아엎는 것보다 이걸 붙이는 게 대개 싸다.
에이전트 메모리Agent memory
세션이 끝나도 남는 사실·선호·과거 결정을 밖에 저장해 두고, 필요할 때 꺼내 프롬프트에 넣는 장치.
많이 쌓을수록 좋아지지 않는다 — 철회되지 않은 옛 사실 하나가 남으면 모델이 그걸 근거로 자신 있게 틀린다.
같이 볼 것 컨텍스트 엔지니어링 · RAG · 롱호라이즌 · 에이전트
컨텍스트 엔지니어링Context engineering
한 번의 호출에 무엇을 넣고 무엇을 뺄지 정해, 한정된 입력 창을 예산처럼 굴리는 설계 작업.
프롬프트를 잘 쓰는 문제가 아니라 자리를 배분하는 문제다 — 도구 설명·메모리·검색 결과가 서로 자리를 뺏는다.
롱호라이즌Long-horizon
수십에서 수백 단계를 이어 가야 끝나는 작업의 성질로, 중간에 한 번 어긋나면 뒤가 전부 어긋난다.
단계당 95% 성공도 50단계면 거의 실패다 — 이 말이 붙은 논문은 정확도가 아니라 복구와 중단 조건을 다룬다.
오케스트레이션Orchestration
여러 모델 호출과 도구 실행의 순서·분기·재시도를 바깥 코드가 정해 놓고 돌리는 방식.
판단을 모델에 맡길수록 유연하고 코드에 맡길수록 재현된다 — 어디까지 코드로 굳힐지가 설계의 전부다.
멀티에이전트Multi-agent
역할을 나눈 여러 인스턴스가 서로 결과를 주고받으며 한 작업을 나눠 맡는 구성.
병렬로 빨라지는 대신 서로의 실수를 근거로 믿는다 — 하나로 안 되던 일이 셋으로 되는 경우는 생각보다 적다.
서브에이전트Subagent
본 세션이 자기 입력 창을 지키려고 따로 띄우는 하위 실행 단위로, 결과 요약만 돌려받는다.
긴 탐색을 대신 시키고 요약만 받는 게 목적이다 — 대신 요약에서 빠진 근거는 본 세션이 영영 못 본다.
같이 볼 것 멀티에이전트 · 오케스트레이션 · 컨텍스트 엔지니어링 · 에이전트
모델 라우터Model router
요청마다 난이도·비용·지연을 보고 어느 모델로 보낼지 자동으로 고르는 중간 계층.
쉬운 요청을 싼 모델로 흘려 비용을 깎는 자리이자, 한 곳이 죽으면 붙은 앱이 전부 죽는 단일 지점이다.
검증기Verifier
에이전트가 낸 결과를 테스트·컴파일·규칙으로 기계가 채점해, 통과할 때만 다음 단계로 넘기는 관문.
제목에 이 게이트가 붙은 논문은 대개 모델이 아니라 채점자를 붙여 점수를 올린 것이다 — 채점 가능한 도메인에서만 먹힌다.
트레이스Trace
에이전트가 어떤 프롬프트로 어떤 도구를 부르고 무엇을 돌려받았는지 한 런 전체를 순서대로 남긴 기록.
에이전트는 같은 입력으로 다시 돌려도 같은 실패가 안 나온다 — 그래서 원인 구간은 재현이 아니라 남겨둔 기록에서 찾는다.
같이 볼 것 에이전트 루프 · 하네스 · 평가(eval) · 백그라운드 에이전트
컨텍스트 컴팩션Context compaction
대화가 길어져 모델이 한 번에 볼 수 있는 분량이 차면, 앞부분을 요약본으로 갈아 끼워 자리를 비우는 처리.
요약되는 순간 빠진 세부는 다시 돌아오지 않는다 — 긴 런이 갑자기 하던 일을 잊는 사고는 대개 이 지점이다.
같이 볼 것 컨텍스트 창 · 컨텍스트 엔지니어링 · 에이전트 메모리 · 롱호라이즌
백그라운드 에이전트Background agent
사람이 지켜보지 않는 동안 별도 환경에서 혼자 실행되다가, 끝나면 PR이나 알림으로 결과를 내놓는 방식.
중간에 끼어들 지점이 없다 — 도구 권한과 승인선을 미리 좁혀 두지 않으면 검토는 결과물을 받은 뒤에만 가능하다.
작업 분해Task decomposition
큰 목표를 순서와 성공 조건이 분명한 작은 단위로 쪼개, 하나씩 실행하고 검사하게 만드는 단계.
쪼개기가 틀리면 이후 단계는 성실하게 틀린다 — 헛도는 에이전트의 원인은 도구보다 여기인 경우가 많다.