얼마 전 note에 공개한 기사 「AI 에이전트 설계를 뒷받침하는 3가지 엔지니어링: Prompt・Context・Harness」에서 다룬 용어들을 레퍼런스로 한꺼번에 정리해 둡니다.

이 분야는 새로운 용어가 계속해서 등장하고 정의도 흔들리고 있기 때문에, 기사를 읽을 때의 부교재로서, 그리고 스스로 정리하기 위한 용도로 남겨두는 것입니다.

• 원문 기사 (note): https://note.com/ebe0911/n/n9ee5dbd40546

⚠️ 정의는 「구현자가 현장에서 사용하는 의미」를 우선하여 풀어서 설명했습니다. 엄밀한 학술적 정의와는 입도가 다를 수 있습니다.

Prompt Engineering (프롬프트 엔지니어링)

LLM에 대한 지시(Prompt)를 작성하는 방법을 궁리하여, 1회의 상호작용으로 좋은 출력을 이끌어내는 기술. 「어떻게 쓸 것인가」의 최적화. 2022~2024년에 확립됨.

Context Engineering (컨텍스트 엔지니어링)

모델의 추론 시, 컨텍스트 윈도우(Context Window)에 「무엇을・어떤 순서로・어떤 형식으로」 넣을지를 설계하는 기술. 「무엇을 전달할 것인가」의 설계. 2025년에 Andrej Karpathy가 명명하여 확산됨.

Harness Engineering (하네스 엔지니어링)

모델의 외부에 있는 동작 환경 전체(도구・제약・메모리・피드백・인간의 확인 등)를 설계하는 기술. 「어떤 환경에서 구동할 것인가」의 설계. 2026년에 주류화됨.

Harness (하네스)

직역하면 「마구(고삐·안장)」. 에이전트 문맥에서는 모델을 목적대로 달리게 하기 위한 외부 메커니즘 일체를 가리킴. 아무리 우수한 말(모델)이라도 고삐가 없다면 원하는 방향으로 나아가지 못한다는 비유.

Agent = Model + Harness

Mitchell Hashimoto에 의한 정식화. 에이전트의 실력은 「모델의 성능」과 「하네스의 설계」로 결정된다는 사고방식.

이 세 가지는 대체 관계가 아니라

포함 관계: Harness ⊃ Context ⊃ Prompt.

Prompt (프롬프트)

LLM에 주는 입력 텍스트. 지시・문맥・예시 등을 포함.

System Prompt (시스템 프롬프트)

모델의 역할이나 지켜야 할 규칙을 정의하는, 대화의 토대가 되는 지시. 원문 기사의 Dify 예시에서는 글자 수나 제목의 제약을 스키마(Schema)가 아닌 여기서 적용함.

Chain-of-Thought / CoT (사고의 연쇄)

「중간 사고 과정」을 차례대로 쓰게 함으로써, 복잡한 추론의 정답률을 높이는 수법.

Few-shot / Zero-shot (퓨샷 / 제로샷)

프롬프트 내에 정답 예시를 몇 가지 보여주는 것이 Few-shot, 예시 없이 지시만 주는 것이 Zero-shot.

Tree-of-Thought / ToT (사고의 나무)

여러 사고 경로를 가지치기하듯 탐색・비교하여 좋은 경로를 선택하는 수법. CoT의 발전형.

Context Window (컨텍스트 윈도우)

모델이 한 번에 처리할 수 있는 토큰(Token)의 상한 범위. 유한한 리소스이며, 무엇을 넣느냐가 성능을 좌우함.

Token (토큰)

모델이 텍스트를 다루는 최소 단위. 단어보다 세밀한 「덩어리」로, 컨텍스트 양이나 요금 계산의 단위가 됨.

Context Rot (컨텍스트 오염 / 문맥의 열화)

컨텍스트가 늘어날수록 모델의 주의(Attention)가 분산되어, 필요한 정보를 정확하게 포착하지 못하게 되는 현상. Anthropic이 지적함.

Transformer / Attention (트랜스포머 / 주의 메커니즘)

현재 LLM의 기반 아키텍처. 모든 토큰이 서로의 관련도를 계산함 (n²의 계산량). 이것이 Context Rot의 구조적인 원인.

RAG (검색 증강 생성 / Retrieval-Augmented Generation)

외부 데이터를 검색하여 컨텍스트에 추가함으로써, 답변의 근거와 최신성을 보완하는 수법. Context Engineering의 대표적인 예.

AI Agent (AI 에이전트)

LLM 스스로가 「다음에 무엇을 할지」를 동적으로 판단하고, 도구를 사용하여 자율적으로 태스크를 진행하는 시스템.

Workflow (워크플로우)

LLM과 도구를 미리 정해진 코드의 경로에 따라 구동하는 방식. 예측 가능하고 안정적임. 에이전트와 대조되는 개념으로, 「화려한 자율성보다 수수한 워크플로우가 정답」인 상황이 많음.

LLM (대규모 언어 모델 / Large Language Model)

대량의 텍스트로 학습된 언어 모델. 에이전트의 「두뇌 (추론 코어)」에 해당함.

Policy / 추론 코어

상황을 보고 다음 수를 결정하는 핵심. 대부분의 경우 LLM이 담당함.

Planner (플래너 / 계획)

목표를 실행 가능한 작은 단계로 분해하는 기능.

Action Space / Tool Use / Function Calling (행동 공간 · 도구 사용 · 함수 호출)

검색 · 코드 실행 · API 호출 등, 모델이 외부 세계에 작용하는 수단의 집합. LLM이 구조화된 「함수 호출 (Function Calling)」을 출력하고, 확정적인 코드가 이를 실행하는 형태가 기본임.

Memory (메모리)

작업 중인 문맥을 유지하는 **단기 메모리 (Short-term Memory)**와, 세션을 넘어 지식을 유지하는 **장기 메모리 (Long-term Memory)**로 크게 나뉨.

Verifier / Critic (검증기 / 비평가)

출력이 타당한지 점검하고, 필요하다면 수정을 요구하는 역할. 원문 기사의 Dify 예시에 나온 「LLM2 (자기 비평)」가 이에 해당함.

Agentic Loop (에이전트 루프)

「행동 → 환경으로부터의 관측 → 메모리에 추가 → 다음 판단」을 반복하는 순환. 컨텍스트는 팽창하고 출력은 짧아지는 비대칭적인 구조가 됨.

Orchestration (오케스트레이션)

여러 에이전트나 도구를 협조시켜 하나의 태스크를 완성하는 설계 및 제어.

Multi-agent (멀티 에이전트)

역할이 다른 여러 에이전트를 연계시키는 구성. 단일 에이전트로 충분하다면 그것이 최선이며, 필요해졌을 때 비로소 여러 개로 구성함.

Prompt Chaining (프롬프트 체이닝)

태스크를 여러 단계로 나누고, 이전 LLM 출력을 다음 입력으로 전달하여 직렬로 연결하는 패턴.

Routing (라우팅)

입력을 분류하여 적절한 전문 처리 프로세스로 배분하는 패턴.

Parallelization (병렬화)

태스크를 분할하여 동시 실행(sectioning)하거나, 여러 번 시도하여 다수결(voting)을 취하는 패턴.

Orchestrator-Workers (오케스트레이터–워커)

상위 에이전트가 동적으로 서브 태스크를 추출하여 여러 워커에게 할당하는 Anthropic의 패턴.

Evaluator-Optimizer (평가자–최적화자)

생성 역할과 평가 역할을 나누어, 피드백을 통해 반복적으로 개선하는 패턴.

Manager pattern (매니저형)

중앙의 사령탑 에이전트가 다른 전문 에이전트를 「도구로서」 호출하는 방식 (OpenAI의 정리).

Handoff / Decentralized (핸드오프 / 분산형)

전문 에이전트끼리 담당에 따라 제어권을 서로 주고받는 방식.

CLAUDE.md / AGENTS.md (지시 파일)

리포지토리에 배치하여 에이전트에게 전제 조건 · 규약 · 수행 방법을 전달하는 프로젝트 지시 파일. 하네스 (Harness)의 대표적인 부품.

Human-in-the-Loop / HITL (인간의 확인)

중요한 판단이나 부작용이 있는 조작 전에 인간의 리뷰 및 승인을 거치도록 하는 설계.

Guides / Sensors (사전 제어 / 사후 제어)

Martin Fowler의 정리. 미리 행동 범위를 정하는 것이 Guides이며, 이탈을 사후에 감지하여 수정하는 것이 Sensors임. 하네스는 이 두 계통의 조합임.

Feedback Loop (피드백 루프)

실행 결과나 검증 결과를 에이전트에게 되돌려주어 다음 행동을 개선하게 하는 메커니즘.

Evaluation Harness (평가 하네스) / lm-evaluation-harness

모델을 정형적으로 평가하는 프레임워크. EleutherAI의 lm-evaluation-harness (2020)가 「harness」라는 용어의 기원이며, 이것이 에이전트 문맥으로 전용됨.

Dify

노코드(No-code) / 로코드(Low-code)로 LLM 앱이나 워크플로우를 구축할 수 있는 플랫폼. 원문 기사의 LinkedIn 포스트 생성 에이전트는 이것으로 구축됨.

JSON Schema / strict mode

출력의 구조(타입, 필수 항목, 추가 프로퍼티(Property) 허용 여부 등)를 정의하는 사양. strict 모드에 가깝게 설정하면, 출력 노드의 변수를 하나씩 개별 필드로 다시 참조해야 하는 등 제약 사항으로 인한 문제(ハマり, 함정)가 발생할 수 있음(즉, Harness 측의 문제).

Temperature (온도 파라미터)

출력의 무작위성(Randomness)을 조정하는 값. 높으면 다양하고(원문 기사의 초안 생성은 temp 0.7), 낮으면 안정적임(자기 비판은 temp 0.3).

Codex (OpenAI)

OpenAI의 코딩 에이전트. "Harness engineering"이라는 용어가 확산되는 계기가 된 사례.

12 Factor Agents

Dex Horthy (HumanLayer)가 제안한 신뢰할 수 있는 에이전트를 만들기 위한 원칙 모음. "컨텍스트(Context)를 40% 이상 채우면 성능이 떨어진다"와 같은 실전 지식으로 알려져 있음.

• 원문 기사 (note): 「AI 에이전트 설계를 뒷받침하는 3가지 엔지니어링: Prompt · Context · Harness」 https://note.com/ebe0911/n/n9ee5dbd40546
• Zenn: https://zenn.dev/ebe_ryuki
• X: https://x.com/EBE_Ryuki

클라우드 × 생성형 AI × 커리어에 대해, 구현 기반의 지견을 발신하고 있습니다. 오류나 보충할 점이 있다면 댓글로 지적해 주시면 감사하겠습니다.