알아두어야 할 AI 코딩 에이전트 용어 31개, 다섯 기둥으로 정리했습니다

매주 새로운 용어가 피드에 등장합니다. Context engineering. Harness engineering. RLM. Progressive disclosure. AI 코딩 에이전트를 매일 쓰고 있는데, 어휘는 제 이해보다 훨씬 빠르게 늘어나고 있었습니다.

그래서 한번 멈추고, 모아 둔 용어 31개를 직접 그룹으로 나눠 봤습니다. 다섯 개의 기둥이 나왔고, 그 구조를 보고 나서야 Claude Code나 Codex 같은 도구의 전체 구조가 비로소 이해되기 시작했습니다.

다섯 기둥은 논리적인 순서를 따릅니다. 에이전트가 무엇을 볼지 설계하고, 작업을 여러 에이전트에 나누고, 실행 방식을 제어하고, 세션을 넘어 기억하게 하고, 외부 세계와 연결합니다.

설계. 분할. 제어. 기억. 연결.

에이전트가 보는 것을 설계하기

AI 모델은 딱 하나만 처리합니다. 바로 context window입니다. 시스템 프롬프트, 사용자 지시, 첨부 파일, 대화 기록, 메모리 블록, 로드된 skill까지 모두 하나의 토큰 스트림으로 이어붙여집니다. 그 스트림이 모델의 전부입니다. 많은 팀에서 에이전트 동작을 설정하는 데 사용하는 AGENTS.md 파일도 그 스트림의 한 조각에 불과합니다.

Prompt는 모델에게 직접 내리는 지시입니다. Prompt engineering은 신뢰할 수 있는 결과를 얻기 위해 예시와 출력 형식을 포함한 지시를 설계하는 실천입니다. 이 두 용어는 이미 잘 알려져 있지만, 실제로 모델에 들어가는 내용의 일부만을 다룹니다.

Context는 모델이 참조할 수 있는 모든 것입니다. 시스템 프롬프트, 대화 기록, 첨부 파일, 메모리, skill, 도구 출력까지 합쳐진 전체입니다. Context engineering은 무엇을 넣고, 무엇을 빼고, 어떤 순서로 배치할지를 결정하는 작업입니다. 이 차이는 실질적입니다. 2,000줄짜리 파일을 지시문 앞에 두느냐 뒤에 두느냐에 따라 동일한 프롬프트가 전혀 다른 결과를 낸다는 것을 직접 경험했습니다. 순서는 장식이 아닙니다.

Intent는 사용자의 실제 목표로, 실제로 입력한 텍스트와 다를 수 있습니다. “테스트를 고쳐줘”라고 쓰더라도 실제 의도는 “CI를 통과시켜줘”일 수도 있고, “새 API에 맞게 테스트를 리팩터링해줘”일 수도 있습니다. 에이전트의 라우팅은 여기서 시작되고, intent를 잘못 파악하면 이후 모든 것이 어긋납니다.

Skill은 호출 시 context에 로드되는 재사용 가능한 전문 지시 묶음입니다. 프롬프트를 위한 함수라고 생각하면 됩니다. 특정 동작을 원할 때마다 200줄짜리 지시를 붙여 넣는 대신, /refactor-clean을 호출하면 skill의 내용이 필요한 순간에 context window로 들어옵니다.

Progressive disclosure는 모든 skill을 한꺼번에 context에 로드하지 않는 설계 패턴입니다. 에이전트는 그 순간 필요한 skill만 로드합니다. Anthropic이 skills 블로그 포스트에서 이 방식을 공개했습니다. 이 방식이 중요한 이유는 context window 공간이 유한하기 때문입니다. skill 40개를 처음부터 전부 로드하면 모델이 작업을 시작하기도 전에 토큰이 소진됩니다. Progressive disclosure는 window를 가볍게 유지하고 모델의 집중도를 높입니다.

초반에 반복해서 겪은 실패 패턴이 있습니다. context에 너무 많은 것을 밀어 넣고 왜 출력 품질이 떨어지는지 의아해하는 것이었습니다. 200K context window는 이론상 최대치입니다. 실제로는 시스템 프롬프트, MCP 서버 정의, 대화 기록을 제하면 사용 가능한 공간이 70K 이하로 줄어들 수 있습니다. Context engineering은 그 제약을 존중하는 일입니다.

여러 에이전트에 작업을 분할하기

하나의 에이전트가 모든 것을 처리하는 구조는 context window가 꽉 차고 출력 품질이 떨어지기 전까지는 단순해 보입니다. 멀티 에이전트 아키텍처가 존재하는 이유가 여기에 있습니다.

Subagent는 메인 에이전트가 작업을 위임하는 자식 프로세스입니다. 메인 에이전트는 전문화된 작업을 오프로드함으로써 자신의 context를 깔끔하게 유지합니다. Claude Code에서 백그라운드 리서치 작업을 시작하면, 그것이 바로 자체 context window에서 동작하며 결과만 돌려주는 subagent입니다.

Swarm은 여러 에이전트가 같은 문제의 서로 다른 부분을 병렬로 처리하는 패턴입니다. 파일 다섯 개를 동시에 분석해야 한다면, 하나의 에이전트가 순차적으로 처리하는 대신 swarm을 통해 다섯 에이전트가 각각 하나씩 담당할 수 있습니다.

Fleet은 실행 중인 에이전트들의 운영 뷰입니다. 아키텍처 용어가 아니라 관리 용어입니다. subagent 세 개와 백그라운드 에이전트 두 개가 활성 상태일 때, 그 전체를 fleet이라고 합니다.

Handoff는 한 에이전트(또는 사람)에서 다른 에이전트로 작업을 넘기는 것입니다. 순차적인 워크플로에서 Agent A가 자신의 단계를 완료하고 Agent B에게 넘깁니다. 중요한 세부 사항은 무엇이 전달되는가입니다. 출력만 전달되는지, 아니면 전체 context가 전달되는지에 따라 다릅니다. 대부분의 handoff는 요약만 전달하기 때문에 정보 손실이 발생할 수 있고, 이를 미리 고려해야 합니다.

Background agent는 사용자 개입 없이 비동기로 실행됩니다. GitHub의 Copilot Workspace와 Anthropic의 Claude Code 모두 이 패턴을 지원합니다. 작업을 지시하고 노트북을 닫으면 에이전트가 독립적으로 작업하고, 돌아왔을 때 결과가 나와 있습니다.

직접 빠진 함정이 있습니다. 너무 이른 시점에 너무 많은 에이전트로 작업을 쪼개는 것이었습니다. context가 잘 설계된 단일 에이전트가 잘못 조율된 멀티 에이전트 구성보다 작업의 80%를 더 잘 처리합니다. 단일 에이전트가 context 한계나 품질 저하에 부딪히고 있다는 근거가 생겼을 때 분할하는 것이 맞습니다.

에이전트의 실행을 제어하기

올바른 코드를 생성하는 에이전트도 위험한 도구를 몰래 호출하거나 건드리면 안 되는 파일을 수정한다면 쓸모가 없습니다. 제어는 세 번째 기둥이고, 대부분의 팀이 가장 적게 투자하는 영역입니다.

Harness는 에이전트의 실행, 검증, 생명주기를 감싸는 운영 틀입니다. 권한 검사부터 출력 유효성 검사, 재시도 로직까지 포함합니다. Harness engineering은 그 틀 안의 제약과 피드백 루프를 설계하는 일입니다. OpenAI가 Codex가 구조화된 harness 패턴으로 백만 줄 이상의 코드를 생성한 방식을 공개하면서 이 용어가 주목받게 되었습니다.

Trace는 에이전트가 취한 모든 단계와 결정의 실행 로그입니다. 에이전트가 한 번만 필요한 정보를 가져오는데 웹 검색 도구를 작업마다 14번씩 호출하고 있다는 사실을 발견한 뒤로 trace를 진지하게 보기 시작했습니다. trace 없이는 에이전트가 효율적으로 작동하고 있다고 착각했을 것입니다. Trace는 AI 에이전트의 디버깅에 가장 가까운 도구입니다.

Diff는 에이전트의 변경 전후 코드를 비교한 것입니다. trace와 함께 diff는 검증의 기반을 이룹니다. 볼 수 없는 것은 검토할 수 없고, diff는 pull request가 사람의 변경을 검토 가능하게 만드는 것처럼 에이전트의 변경을 검토 가능하게 만듭니다.

Guardrails는 위험한 출력을 막는 규칙과 유효성 검사입니다. “rm -rf가 포함된 셸 명령은 절대 실행하지 않는다”처럼 단순할 수도 있고, 출력에 민감한 데이터가 포함되는 것을 차단하는 콘텐츠 분류기처럼 정교할 수도 있습니다.

Sandbox는 제한된 권한을 가진 격리된 실행 환경입니다. Codex는 Docker sandbox 안에서 실행되며, 에이전트는 코드를 작성하고 테스트를 실행할 수 있지만 네트워크에 접근하거나 호스트 시스템을 수정할 수 없습니다. 이것이 “에이전트가 실수를 했다”와 “에이전트가 실수를 해서 프로덕션에 영향을 줬다”의 차이를 만듭니다.

CLI(command-line interface)는 에이전트 시대에 다시 주목받고 있습니다. 터미널을 통해 도구를 실행하는 것이 프로토콜 레이어를 거치는 것보다 토큰 효율이 높기 때문입니다. 토큰 하나하나가 비용이 되고 context 공간을 소비할 때, CLI의 직접성은 실질적인 의미를 가집니다.

REPL(read-eval-print loop)은 코드를 즉시 실행할 수 있는 인터랙티브 환경입니다. 에이전트는 REPL을 통해 가설을 검증하고, 중간 결과를 확인하고, 파일을 디스크에 쓰기 전에 솔루션을 반복적으로 개선합니다.

세션을 넘어 기억하기

대형 언어 모델에는 명확한 경계가 있습니다. context window입니다. 가득 차면 오래된 내용이 밀려납니다. 몇 시간이나 며칠에 걸치는 작업에서 이것은 실질적인 문제가 됩니다.

Memory는 단일 context window를 넘어 대화 기록과 작업 상태를 저장하는 모든 시스템입니다. Memory hierarchy는 이 저장소를 계층으로 구성합니다. 보통 단기(현재 대화), 중기(최근 세션), 장기(영구 지식)로 나뉩니다. 이 설계는 CPU 캐시 계층 구조와 유사한데, 이유도 같습니다. 서로 다른 접근 패턴에는 서로 다른 저장 전략이 필요합니다.

Embeddings는 텍스트를 의미를 담은 수치 벡터로 변환합니다. RAG(retrieval-augmented generation)의 기반이 되는데, 에이전트가 벡터 데이터베이스를 검색해 관련 정보를 context window로 가져옵니다. 에이전트가 이전 세션의 내용을 “기억”할 때, 보통 embedding 기반의 유사도 검색을 수행하고 있는 것입니다.

Long-running agent는 여러 context window에 걸쳐 상태를 유지하며, 단일 세션보다 오래 걸리는 작업을 처리합니다. 모델 자체에는 영구 메모리가 없기 때문에 외부 상태 관리가 필요합니다.

Geoffrey Huntley가 만든 Ralph Loop는 메모리 문제를 실용적인 방식으로 해결하는 자율 코딩 루프입니다. 각 반복마다 새로운 에이전트 인스턴스를 시작하지만, 진행 상황은 git 커밋과 progress 파일을 통해 유지됩니다. 새 인스턴스는 git 히스토리와 progress 노트를 읽어 지금까지 무엇을 했는지 파악한 뒤 이어서 진행합니다. 반복을 거듭할수록 저장소 자체에 쌓인 context가 각 루프를 개선하면서 test-time scaling을 극대화합니다.

**RLM(Recursive Language Model)**은 근본적으로 다른 접근 방식을 취합니다. 긴 입력을 모델에 직접 넣는(context window를 초과할 수 있는) 대신, 원본 데이터를 REPL 변수에 저장하고 모델이 코드를 작성해 탐색하게 합니다. 모델은 재귀적인 함수 호출을 통해 저장된 데이터에 대해 목표를 좁힌 쿼리를 실행합니다. 원본 데이터가 context window에 들어오지 않기 때문에 잘림으로 인한 정보 손실이 없습니다. 논문 저자들은 이 방식이 일반적인 context window의 100배에 해당하는 입력을 처리할 수 있다고 주장합니다.

두 방식 모두 동일한 제약을 인정하지만 해결 방식이 다릅니다. Ralph Loop는 외부 영속성을 사용해 context window의 한계와 함께 작동합니다. RLM은 데이터를 context window 밖에 두어 한계를 우회합니다. 어느 쪽이 더 낫다고 단정할 수 없으며, 병목이 작업 연속성(Ralph Loop)인지 입력 크기(RLM)인지에 따라 선택이 달라집니다.

에이전트를 외부 세계와 연결하기

외부 도구, API, 서비스에 접근할 수 없는 에이전트는 텍스트 생성에 머물 수밖에 없습니다. 프로토콜이 통합 문제를 해결합니다.

**MCP(Model Context Protocol)**는 모델이 외부 도구와 연결하는 방식을 표준화합니다. MCP가 없으면 N개의 모델과 M개의 도구를 연결하는 데 N x M개의 커스텀 구현이 필요합니다. MCP를 쓰면 각 모델과 도구가 프로토콜을 한 번씩만 구현하면 되어 통합 비용이 N + M으로 줄어듭니다. USB가 성공한 원리와 같습니다. 인터페이스 하나에 합의하면 모든 것이 연결됩니다.

**ACP(Agent Communication Protocol)**는 에디터와 코딩 에이전트 사이의 통신을 표준화합니다. Zed와 JetBrains가 개발을 이끌고 있습니다. 해결하려는 문제는 MCP와 비슷하지만 레이어가 다릅니다. 모델과 도구 사이가 아니라 에디터와 에이전트 사이의 문제입니다.

**LSP(Language Server Protocol)**는 에디터와 코드 분석 서버 사이 통신의 확립된 표준입니다. 프로토콜 표준화가 개발자 도구에서 작동한다는 것을 처음 증명한 사례입니다. grep으로 30초 걸리던 참조 검색이 LSP를 통하면 50ms 안에 완료됩니다. 원본 파일 내용 대신 구조화되고 정밀한 결과를 돌려주기 때문에 토큰 사용량도 2,000개 이상에서 약 500개로 줄어듭니다. LSP는 ACP 설계의 참조 모델이기도 한데, 문제의 형태가 거의 동일하기 때문입니다.

세 프로토콜은 서로 다른 레이어에서 동작하지만 동일한 아키텍처 원칙을 공유합니다. 점대점 커스텀 통합은 확장되지 않습니다. 표준 인터페이스는 확장됩니다.

지도이지 영토가 아닙니다

이 용어들 대부분은 6개월 전에는 존재하지 않았습니다. 낯설게 느껴진다면 당연한 일입니다. 어휘가 늘어나는 것은 분야가 성장하고 있기 때문이고, 새로운 개념에는 이름이 필요합니다.

다섯 기둥의 가치는 정의를 외우는 것에 있지 않습니다. 새로운 용어를 만났을 때 그것이 어디에 속하는지 즉시 파악할 수 있는 정신적 틀을 갖는 것에 있습니다. “agent memory”라는 말이 나오면 네 번째 기둥에 속한다는 것을 알 수 있습니다. 새로운 프로토콜이 출시되면 다섯 번째 기둥에 해당한다는 것을 압니다. 이 틀은 새로운 어휘를 무너지지 않고 흡수합니다.

지금도 용어를 수시로 찾아봅니다. 달라진 점은 이제 그것이 어느 선반에 속하는지 알고 있다는 것입니다.