📚 지식 노트

프롬프트 설계

모델은 프롬프트에 적힌 것 말고는 이 일의 사정을 모른다. 그래서 좋은 프롬프트는 새로 온 유능한 동료에게 주는 업무 설명과 비슷하다. 목적, 독자, 하지 말아야 할 것, 끝났을 때의 모양을 적는다. 자주 쓰는 재료는 넷이다.

• 역할과 규칙: "너는 데이터베이스 리뷰어다"처럼 관점을 정하고, 지킬 규칙(추측은 표시한다, 모르면 모른다고 한다)을 적는다. 보통 시스템 프롬프트에 둔다.
• 예시(few-shot): 입력과 원하는 출력의 쌍을 2~5개 보여 준다. 말로 설명하기 어려운 어조·형식을 가장 빨리 전달한다. 다만 모델은 예시를 꽤 그대로 따라 하므로, 서로 다른 경우를 고르게 넣는다. 예시만으로 새 과제를 푸는 능력이 처음 크게 드러난 GPT-3 이야기는 LLM 노트에 있다.
• 구조: 지시문과 자료가 섞이면 모델이 자료 속 문장을 지시로 착각하기 쉽다. 문서·코드는 태그나 구분선으로 감싸 "여기부터 자료"를 분명히 한다. 이것은 외부 문서에 숨긴 지시(프롬프트 인젝션)를 완전히 막지는 못한다. 방어는 AI 보안 노트에 있다.
• 출력 형식: 프로그램이 받아 쓸 결과라면 JSON 스키마를 주고, 가능하면 API의 구조화 출력 기능으로 형식을 강제한다. 말로만 부탁한 형식은 가끔 깨진다.

프롬프트를 고칠 때는 감으로 하지 말고 대표 입력 열댓 개를 정해 두고 바꾸기 전후 결과를 나란히 비교한다. 한 입력에서 좋아진 수정이 다른 입력을 망치는 일이 흔하다. 더 자세한 요령은 Claude 문서의 프롬프트 엔지니어링 안내가 잘 정리했다.

생각의 사슬과 자기 일관성

LLM은 토큰을 하나 낼 때마다 정해진 양의 계산만 한다. 여러 단계를 거쳐야 하는 문제를 바로 답하게 하면 그 계산을 한 토큰에 몰아넣어야 한다. 생각의 사슬(chain-of-thought, CoT)은 답 전에 중간 풀이를 글로 쓰게 하는 방법이다. 써 놓은 중간 결과가 다음 토큰의 입력이 되므로, 모델이 일종의 연습장을 얻는 셈이다. Wei 외(2022)는 풀이가 적힌 예시 몇 개만 보여 줘도 큰 모델의 수학·상식 추론 점수가 크게 오른다는 것을 보였고, 이 효과는 작은 모델에서는 잘 나타나지 않았다.

자기 일관성(self-consistency)은 여기에 표본을 더한다. 온도를 0보다 크게 두고 같은 문제를 여러 번 풀게 하면 풀이 경로가 매번 달라진다. 틀린 풀이는 제각각 다른 답으로 흩어지고 맞는 풀이는 같은 답으로 모이는 경향이 있으니, 최종 답만 모아 다수결한다(Wang 외, 2022). 정답을 기계적으로 비교할 수 있는 문제(수, 선택지, 코드 실행 결과)에서 잘 듣고, 자유 서술 답에는 그대로 쓰기 어렵다. 비용은 뽑은 횟수만큼 든다.

요즘의 추론 모델은 이런 생각을 학습 단계에서 길게 하도록 훈련되어, "단계별로 생각하라"를 따로 적지 않아도 답 전에 긴 생각 토큰을 만든다. 그래도 원리는 같다. 생각 토큰도 출력 토큰이라 돈과 시간이 들고, 쉬운 질문에서는 낭비다.

RAG: 찾아서 넣고 답하기

모델은 학습 뒤에 생긴 일과 회사 내부 문서를 모른다. 매번 다시 학습시키는 대신, 질문과 관련된 문서 조각을 찾아 컨텍스트에 넣고 그것을 근거로 답하게 하는 것이 RAG(retrieval-augmented generation)다. 이름은 Lewis 외(2020)에서 왔다. 그 논문은 검색기와 생성기를 함께 학습시켰지만, 지금 흔히 말하는 RAG는 이미 학습된 임베딩 모델과 LLM을 파이프라인으로 잇는 것이다.

• 청크 나누기: 문서를 수백 토큰 단위로 자른다. 너무 크면 관련 없는 내용이 섞여 점수가 흐려지고, 너무 작으면 문맥이 끊긴다. 제목·절 경계를 따라 자르고, 경계에서 문장이 잘리지 않게 조금 겹친다.
• 임베딩: 글을 의미가 비슷하면 방향이 비슷한 벡터로 바꾼다. 질문과 문서를 서로 다른 인코더로 바꿔 내적으로 비교하는 밀집 검색이 DPR(2020)에서 낱말 검색(BM25)을 앞서며 자리 잡았다.
• 검색: 질문 벡터와 가장 가까운 청크 k개를 고른다. 수백만 개를 일일이 비교할 수 없어 근사 최근접 이웃 색인을 쓴다. HNSW 같은 색인의 원리는 데이터베이스 노트의 벡터 검색에 있다. 고유명사·코드명은 임베딩이 약하므로 낱말 검색을 섞는 하이브리드가 흔하다.
• 재순위: 임베딩 검색은 질문과 문서를 따로 읽어 빠르지만 거칠다. 후보 수십 개만 골라 질문과 문서를 한꺼번에 읽는 교차 인코더(재순위 모델)로 다시 줄 세운다.
• 근거 붙이기(grounding): 고른 청크에 번호를 달아 넣고, 자료에 없으면 모른다고 하고 주장마다 출처 번호를 달라고 한다. 사람이 근거를 확인할 수 있어야 환각을 잡는다.

임베딩끼리는 보통 코사인 유사도로 비교한다. 두 벡터 사이 각의 코사인으로, 길이는 무시하고 방향만 본다. cos = (a·b) / (|a||b|)이다. 같은 방향이면 1, 직각이면 0, 반대면 −1이다.

긴 컨텍스트 모델이 나와도 RAG가 사라지지 않는 이유는 둘이다. 문서 전체를 매번 넣으면 비싸고 느리며, 많이 넣을수록 모델이 가운데 있는 내용을 놓치기 쉽다. Lost in the Middle(2023)은 답이 담긴 문서가 컨텍스트의 처음이나 끝에 있을 때보다 가운데 있을 때 정답률이 눈에 띄게 떨어진다는 것을 보였다. 고른 것만 넣는 편이 대개 낫다. RAG가 실패하면 먼저 검색 결과를 눈으로 본다. 대부분은 생성이 아니라 검색(청크가 이상하거나 찾지 못함)에서 틀린다.

프롬프트, RAG, 미세 조정 중 무엇을

모델이 원하는 대로 답하지 않을 때 고칠 곳은 셋이다. 무엇이 모자란지에 따라 고른다. 지식이 모자라면 RAG, 형식·말투·좁은 과제의 솜씨가 모자라면 미세 조정, 무엇을 원하는지 전달이 모자라면 프롬프트다. 보통은 싸고 빨리 되돌릴 수 있는 프롬프트부터 시작한다.

셋은 함께 쓴다. 미세 조정한 모델에도 RAG로 자료를 넣고, 프롬프트로 지시한다. 미세 조정을 싸게 하는 LoRA와 큰 모델의 솜씨를 작은 모델로 옮기는 증류는 LLM 노트에 있다.

도구 사용과 MCP

도구 사용(tool use, function calling)은 모델이 계산·검색·파일 조작처럼 글만으로 못 하는 일을 프로그램에 맡기는 방법이다. 앱은 도구마다 이름, 설명, 입력의 JSON 스키마를 모델에 알려 준다. 모델은 필요하다고 판단하면 일반 답 대신 "이 도구를 이 인자로 불러 달라"는 구조화된 요청을 낸다. 실행하는 것은 모델이 아니라 앱이다. 앱이 결과를 대화에 붙여 다시 보내면 모델이 그것을 보고 답을 잇는다.

도구 설명은 프롬프트의 일부다. 이름과 설명이 모호하면 모델이 엉뚱한 도구를 고르거나 인자를 틀리게 채운다. 사람이 처음 보는 API 문서를 읽는다고 생각하고 쓴다. 모델이 도구 쓰는 법을 스스로 익히게 하는 연구로는 Toolformer(2023)가 있다. 글 사이에 API 호출을 끼워 보고, 그 결과가 뒤따르는 글을 더 잘 맞히게 해 준 호출만 학습 데이터로 남기는 방식이었다.

도구가 늘면 앱마다 같은 연결(이슈 트래커, 파일, DB)을 따로 만드는 일이 반복된다. MCP(Model Context Protocol)는 이 연결을 규격으로 만든 것이다. 규격에 따르면 메시지는 JSON-RPC 2.0이고, AI 앱인 호스트 안에 서버마다 클라이언트가 하나씩 생겨 서버와 연결된다. 서버는 모델이 부를 도구, 읽을 자료인 리소스, 미리 만든 프롬프트를 내놓는다. 표준 전송은 로컬 프로세스와 표준 입출력으로 주고받는 stdio와 원격용 Streamable HTTP 둘이다. 언어 서버 프로토콜(LSP)이 편집기와 언어 지원을 떼어 놓은 것과 같은 발상이다.

MCP를 처음 만든 것은 Anthropic이지만, 2025년 12월 9일 Linux Foundation 아래의 Agentic AI Foundation(AAIF)에 기증됐다. Anthropic·Block·OpenAI가 함께 세운 재단이고, 기술 결정은 계속 MCP 관리자들이 한다(MCP 블로그). 특정 회사의 규격이 아니라 중립적인 공개 규격이 됐다는 뜻이다.

MCP가 에이전트와 도구를 잇는다면, A2A(Agent2Agent)는 서로 다른 회사·프레임워크로 만든 에이전트끼리 일을 맡기고 결과를 주고받게 하는 공개 규격이다. Google이 만들어 Linux Foundation에 기증했고, 두 규격은 서로 겹치지 않고 보완한다고 스스로 설명한다. 핵심 개념에 따르면 HTTP(S) 위에서 JSON-RPC 2.0으로 주고받는다. 에이전트는 자기 이름·능력·주소·인증 방법을 적은 JSON 명함(Agent Card)을 내놓고, 일은 ID와 상태를 가진 Task로 맡기며, 결과물은 Artifact로 돌려받는다. 상대 에이전트의 속은 보지 않고 일만 주고받는 구조라, 상대가 돌려준 글도 믿을 수 없는 입력으로 다룬다.

에이전트 루프: 생각 → 행동 → 관찰

도구 호출을 한 번이 아니라 일이 끝날 때까지 반복하게 하면 에이전트가 된다. 뼈대는 단순한 반복문이다. 모델을 부르고, 도구 요청이 있으면 실행해 결과를 붙이고, 다시 부른다. 모델이 도구 요청 없이 답하면 멈춘다. ReAct(2022)는 이때 행동 앞에 생각을 글로 쓰게 하면 행동만 할 때보다 낫다는 것을 보였다. 텍스트 게임·웹 쇼핑 같은 상호작용 과제에서 차이가 컸고, 위키백과 검색 질의응답에서는 생각만 하는 CoT와 섞을 때 가장 좋았다. 생각은 계획을 세우고 고치는 데, 관찰은 생각을 사실에 묶어 환각을 줄이는 데 쓰인다.

실패에서 배우게 하는 변형도 있다. Reflexion(2023)은 시도가 실패하면 모델이 "무엇이 틀렸고 다음엔 어떻게 할지"를 글로 반성하게 하고, 그 반성을 다음 시도의 컨텍스트에 넣는다. 가중치를 바꾸지 않고 말로 된 기억으로 성능을 끌어올린 셈이다. 반복문에는 언제나 최대 단계 수와 예산 상한을 둔다. 같은 실패를 되풀이하며 도는 에이전트는 흔하다.

무엇을 허락할지는 설계의 핵심이다. 읽기는 자유롭게, 쓰기·삭제·송금·메시지 전송은 사람 확인을 거치게 하는 식으로 나눈다. 에이전트에게 얼마나 맡길지에 대한 생각은 에이전트 신뢰 글에, 공격 쪽 이야기는 AI 보안 노트에 있다.

계획과 메모리

긴 일을 하려면 에이전트가 지금 어디까지 했는지 알아야 한다. 모델 자체는 호출 사이에 아무것도 기억하지 않으므로, 기억은 전부 하네스가 컨텍스트에 다시 넣어 주는 글이다. 이를 두 층으로 나눠 생각하면 편하다.

• 단기 기억 = 컨텍스트: 이번 작업의 대화, 생각, 도구 결과. 정확하지만 한도가 있고, 길수록 비싸고 가운데를 놓치기 쉽다.
• 장기 기억 = 바깥 저장소: 파일(할 일 목록, 진행 메모, 프로젝트 규칙 파일), 데이터베이스, 벡터 색인. 필요할 때 도구로 읽어 온다. Generative Agents(2023)는 경험을 기억 흐름에 쌓아 두고 최근성·중요도·관련성 점수로 꺼내 쓰며, 주기적으로 상위 수준의 반성을 적어 두는 구조를 보였다.

컨텍스트 관리는 단기 기억을 한도 안에 유지하는 일이다. 다 쓴 도구 결과는 줄이거나 지우고, 한도에 가까워지면 지금까지의 진행을 요약해 앞부분을 갈아 끼운다(compaction). 요약은 손실 압축이라 중요한 결정과 남은 일은 파일로도 적어 두는 편이 안전하다. 작업을 시작할 때 계획을 할 일 목록으로 써 두고 하나씩 지우게 하는 것도 같은 이유다. 요약이 날아가도 목록이 남는다. 기억을 쉬는 시간에 정리하는 방식은 에이전트 기억과 꿈꾸기 글에서 따로 다뤘다.

멀티 에이전트 패턴

에이전트 여럿을 엮는 이유는 대개 컨텍스트다. 한 에이전트가 모든 탐색 결과를 품으면 컨텍스트가 금방 차고 흐려진다. 하위 에이전트에게 깨끗한 컨텍스트로 좁은 일을 맡기고 요약만 돌려받으면 주 에이전트의 컨텍스트가 가벼워진다. 흔한 모양은 셋이다.

• 오케스트레이터 · 워커: 주 에이전트가 일을 쪼개 하위 에이전트들에게 동시에 맡기고 결과를 합친다. 넓게 조사하는 일에 맞는다. 하위 작업이 서로를 몰라 같은 일을 겹쳐 하거나 서로 어긋난 결정을 내리기 쉽다.
• 파이프라인: 단계가 정해진 일을 차례로 넘긴다. 단계 사이에 프로그램 검사(형식 확인, 테스트)를 넣기 쉽다.
• 평가자 · 개선자: 한 에이전트가 만들고 다른 에이전트가 기준에 비춰 고칠 점을 돌려준다. 기준이 분명할 때 잘 듣는다. 같은 모델이 같은 맹점을 공유하므로 평가자에게 다른 관점(테스트 실행 결과 같은 바깥 신호)을 쥐여 주는 편이 낫다.

Anthropic의 에이전트 설계 글이 강조하듯, 가장 단순한 구성부터 시작해 필요가 확인될 때만 복잡하게 만든다. 에이전트가 늘면 토큰 비용이 그만큼 늘고, 어디서 틀렸는지 추적하기도 어려워진다.

코딩 에이전트는 어떻게 일하나

코딩 에이전트는 위의 루프에 개발 도구를 쥐여 준 것이다. 도구는 대개 파일 목록·검색·읽기, 파일 수정(바꿀 부분을 지정해 고치는 방식), 셸 명령 실행 정도다. 저장소 전체를 컨텍스트에 넣지 않는다. 사람처럼 디렉터리 구조를 보고, 이름으로 검색하고, 관련 파일만 골라 읽는다. 저장소의 규칙 파일(작업 방식, 빌드·테스트 명령)을 시작할 때 읽게 해 두면 매번 같은 탐색을 덜 한다.

코딩이 에이전트에게 유리한 분야인 이유는 검증 수단이 있기 때문이다. 테스트가 실패하면 오류 메시지가 다음 생각의 재료가 되고, 통과하면 멈출 근거가 된다. 거꾸로 테스트가 없는 저장소에서는 그럴듯하지만 틀린 수정이 그대로 끝난다. 그래서 테스트를 먼저 쓰게 하거나, 바꾼 동작을 확인하는 명령을 과제에 함께 적어 주는 것이 효과가 크다. 셸을 쓸 수 있다는 것은 무엇이든 할 수 있다는 뜻이므로 샌드박스·허용 명령 목록·네트워크 제한을 하네스 쪽에서 건다.

평가: 무엇으로 잘한다고 말하나

에이전트 평가는 대개 과제 성공률이다. 정해진 과제 묶음을 주고 끝 상태가 맞는지 프로그램으로 판정한다. 대표 예가 SWE-bench(2023)다. 인기 Python 저장소 12곳의 실제 GitHub 이슈와 그것을 고친 PR로 만든 과제 2,294개로, 모델은 이슈 설명과 그 시점의 코드베이스를 받아 패치를 낸다. 판정은 패치를 적용한 뒤 테스트를 돌려서 한다. 원래 PR이 통과시킨 테스트(고쳐야 할 것)가 통과하고 원래 통과하던 테스트(망가뜨리면 안 되는 것)도 그대로 통과해야 해결로 친다. 논문 당시 가장 잘한 모델은 1.96%를 풀었다.

이후 하위 세트가 생겼다. 비용을 줄인 Lite(300개), 사람이 검토해 설명이 모호하거나 테스트가 부당한 과제를 걸러 낸 Verified(500개), 여러 언어를 담은 Multilingual 등이다. 리더보드 숫자를 읽을 때는 몇 가지를 함께 본다.

• 모델 점수가 아니라 시스템 점수다: 같은 모델도 하네스(도구, 프롬프트, 시도 횟수)에 따라 점수가 크게 다르다. 비교하려면 같은 하네스로 잰 값끼리 본다.
• 표본 오차: 정답률 70%를 500문제로 쟀다면 95% 신뢰 구간이 대략 ±4.0%p다. 1~2%p 차이는 순위를 가를 근거가 못 된다.
• 오염: 공개 저장소의 공개 이슈라 학습 데이터에 답이 섞였을 수 있다. 새로 만든 과제나 비공개 과제로 다시 재는 이유다.
• 시도 횟수: 코드 생성에서 쓰는 pass@k는 k번 시도해 하나라도 맞을 확률이다(Codex 논문의 추정식). 실제 사용에서는 사람이 결과를 하나만 보는 경우가 많으니 pass@1이 기준이다.

공개 벤치마크는 출발점일 뿐이다. 자기 일에 쓸 에이전트라면 실제 과제 수십 개로 작은 평가 묶음을 만들고, 프롬프트·모델·도구를 바꿀 때마다 돌린다. 자동 판정이 어려운 출력은 다른 모델에게 기준표를 주고 채점하게 하기도 하지만(LLM-as-judge), 채점 모델의 편향을 사람이 표본으로 확인해야 한다.

비용과 지연

API 비용은 입력 토큰과 출력 토큰으로 따로 매기고, 출력이 몇 배 비싼 것이 보통이다. 지연도 비슷하다. 입력은 한꺼번에 병렬로 처리하지만 출력은 한 토큰씩 차례로 만들어야 해서 응답 시간은 대개 출력 길이가 좌우한다. 에이전트에서는 여기에 하나가 더 붙는다. 호출마다 지금까지의 기록 전체를 다시 보내므로, 단계가 늘면 누적 입력이 단계 수의 제곱에 가깝게 는다.

• 프롬프트 캐시: 많은 API가 직전 요청과 앞부분이 같으면 그 부분을 할인하고 더 빨리 처리한다. 앞부분이 같아야 하므로 시스템 프롬프트·도구 정의처럼 고정된 것을 앞에, 바뀌는 것을 뒤에 둔다. 중간에 날짜나 무작위 값을 끼우면 캐시가 깨진다.
• 모델 나누기: 분류·추출처럼 쉬운 일은 작고 빠른 모델에, 계획과 어려운 판단만 큰 모델에 맡긴다. 하위 에이전트에 작은 모델을 쓰는 식이다.
• 생각의 양: 추론 모델의 생각 토큰은 출력으로 계산된다. 생각 예산을 일의 난이도에 맞춘다.
• 병렬화: 서로 무관한 도구 호출은 한 번에 요청해 동시에 실행한다. 급하지 않은 대량 작업은 할인된 배치 처리를 쓰는 곳이 많다.
• 짧은 도구 결과: 거대한 로그나 파일을 통째로 돌려주지 말고 하네스가 잘라서 준다. 한 번 들어간 토큰은 그 뒤 모든 호출에서 다시 비용이 된다.

흔한 오해

• "에이전트는 알아서 하니 지켜볼 필요가 없다" — 같은 실패를 되풀이하며 돌거나 테스트를 고쳐 통과시키는 일이 흔하다. 단계·예산 상한과 되돌릴 수 없는 행동 앞의 사람 확인이 기본이다.
• "에이전트를 여럿 두면 하나보다 낫다" — 토큰 비용과 추적의 어려움이 함께 는다. 컨텍스트를 나눌 이유가 있을 때만 나눈다(멀티 에이전트 절).
• "컨텍스트 창이 길어지면 RAG는 필요 없다" — 비용·지연과 가운데를 놓치는 문제 때문에 고른 것만 넣는 편이 대개 낫다(RAG 절).
• "도구가 돌려준 결과는 믿어도 된다" — 웹 페이지·메일·MCP 서버의 도구 설명 모두 모델이 읽는 글이라 숨긴 지시가 들어 있을 수 있다. 개인 데이터 접근, 믿을 수 없는 글, 밖으로 보내는 수단 세 가지가 한 에이전트에 모이면 특히 위험하다(AI 보안 노트의 에이전트와 도구 권한 절).
• "MCP는 보안 기능이다" — 연결 방식을 정한 규격일 뿐, 어떤 서버를 믿고 무엇을 허락할지는 호스트와 사용자가 정한다.

핵심 논문

요약은 직접 정리한 것이다. few-shot 학습을 보인 GPT-3 논문은 LLM 노트, 그 밖의 대표 논문은 논문 노트에 있다.