Introduction
한참이나 그간 언급되었고 언급되고 있는 소위 AI engineering 시리즈에 대한 개념 정리 노트이다. 이들 거대 개념을 수박 겉햝기나마 한 이유는 AI agent 설계 시에 내가 지금 어디 있는지, 어디로 가는 것인지를 알기 위함이다.
따라서, 아래부터 이어질 단정적 표현은 'fact'가 아닌 내가 이해한 수준, 즉 '의견'으로 받아들여지면 좋을 듯(내가 이들 개념 정의자도 아니고). AI가 초안쓰고 내가 감수(?) 및 편집하고 딴 AI가 내용 검증했다.
내용 요약하자면,
•
prompt는 모델이 따를 말을 설계하고,
•
context는 모델이 볼 정보를 설계하며,
•
harness는 모델이 어겨도 시스템이 실패하지 않도록 실행 환경과 검증 가능한 경계를 설계하는 쪽에 가깝다.
참고로, 다른 둘과는 달리 harness engineering은 뭔가 buzzword에 가까워 보이기도.
Prompt Engineering
그간 뭔 prompt "engineering" 씩이나 하고 좀 우습게 봤었는데, 가면 갈 수록 prompt의 파워를 실감한다. 3개 engineering 중 가장 큰 impact로 느껴진다(근데 정작 내용은 짧다…).
•
핵심 가치: 기존 코드로 표현 비용이 크던 맥락 판단과 암묵지를 자연어로 다루기 쉽게 만든 질적 전환
•
코드만으로는 비용이 컸던 맥락 판단, 예외 처리, 암묵지를 자연어 인터페이스로 다루기 쉽게 함
•
비유: source code (무엇을 쓰느냐)
Context Engineering
Prompt Engineering과 달리 첨부터 중요하게 보였다. "뭘 알아야 답을 하지"란걸 생각하면 당연스럽다. Context는 사실 상 메모리인데 인간도 메모리가 제일 중요하고.
•
핵심 가치: 효율성과 품질 (가능한 것을 얼마나 잘 하느냐)
•
단, long-term memory 없이는 불가능한 multi-session agent task처럼 가능/불가능을 바꾸는 경우도 존재
•
비유: 런타임 메모리 레이아웃 설계 (inference 시점에 무엇이 메모리에 올라가 있느냐)
대표 기법
기법 | 설명 |
RAG | 외부 지식 검색 후 context 주입 |
Memory 요약 / compression | 장기 대화를 압축해서 유지 |
Tool result 주입 | 함수 실행 결과를 context에 삽입 |
Conversation pruning | 오래된 turn 제거 또는 교체 |
System prompt 구조화 | - role, 제약, 예시 등 정적 prompt/context 설계 (e.g. CLAUDE.md, AGENTS.md)- 자연어 지시를 설계한다는 점에서는 prompt engineering, 실행 시 context로 주입된다는 점에서는 context engineering, 그 지시가 runtime/tool/validator와 연결되어 검증·강제될 때는 harness engineering의 일부로 볼 수 있음. |
Few-shot example 선택 | - 쿼리 기반 동적 예시 선택 (예시 풀에서 유사도로 선택). -  고정 few-shot은 prompt engineering에 가까움. 핵심은 동적 예시 선택. |
Agent scratchpad | 중간 추론 과정을 context에 누적 (agent framework 구현자 레벨) |
Harness Engineering
agent 시스템 맥락에서 prompt/context engineering을 활용하고, runtime 관리와 code-enforced constraints를 더해 보는 상위 설계 관점
→ 내 이해로는 "LLM 자체를 제외한 agent 실행 환경을 설계하는 것"에 가깝다.
prompt/context engineering은 LLM 시대에 독립적인 설계 영역으로 부상한 것으로 볼 수 있고, harness engineering은 기존 소프트웨어 엔지니어링 원칙을 LLM agent 맥락에서 재조합·체계화하고 이름 붙인 실무 프레임에 가까워 보인다.
•
핵심 가치: 용어 정렬 + 사고 프레임 제공 (기존 소프트웨어 엔지니어링(SE) 원칙의 재적용 + 네이밍). 즉 Prompt / Context Engineering과는 달리, 기존 SE 원칙을 LLM agent 맥락에서 재조합·체계화한 실무 프레임으로 이해할 수 있음
•
Prompt, Context Engineering과의 구분
◦
비결정론적 LLM에 결정론적 constraint를 외부에서 강제하는 것
◦
"coding standards를 따르라" (prompt) → 확률적 준수
◦
linter가 PR을 block (코드) → 결정론적 강제
◦
반드시 지켜야 하는 결정론적 부분은 결국 코드/런타임 강제로 내려가는 편이 안전함
•
완전한 비결정론 탈출은 어렵고, harness는 그 비결정론을 코드로 된 외곽 울타리로 줄이는 구조로 볼 수 있음.
Harness와 Agent Framework의 관계
Agent framework는 tool 권한, 상태 관리, retry, memory, validator 같은 harness 구성 요소를 구현할 수 있는 수단으로 볼 수 있다. 다만 실제 강제 수준은 framework 자체보다 프로젝트의 설정과 검증 장치에 달린다.
•
역사적 발생 순서로는: agent framework 먼저 → 추상화/체계화 → harness engineering처럼 이해할 수 있음
•
개념적 순서로는: harness engineering (설계 원칙) → agent framework (구현체)처럼 볼 수 있음
•
Agent framework는 harness를 구현하는 수단, harness engineering은 무엇을 어떻게 설계해야 하는지에 대한 방법론
자연어 vs 코드. 내용의 기준
내 기준으로는 불변조건(invariant)인가, 선호(preference)인가가 가장 간단한 구분점이다.
모델이 어기면 안 되는 불변조건은 코드로 강제하고, 모델이 잘 판단하길 바라는 선호는 자연어로 유도한다.
달리 말하자면,
위반되면 "품질 저하"인 것은 자연어로, 위반되면 "시스템 실패"인 것은 코드로 막는다.
•
자연어로 둘 수 있는 것: 목표, 역할, 선호, 판단 기준, 예외적 상황의 해석
•
코드로 강제해야 하는 것: 권한, 입력 스키마, 상태 전이, retry 한계, 승인 절차, sandbox, 테스트, 평가, validator, linter, 로깅, 비용 제한
세 개념 비교
•
Prompt engineering → 자연어로 의도 전달
•
Context engineering → 런타임 정보 설계
•
Harness engineering → prompt/context + runtime + code-enforced constraints
비유 | 내 기준의 핵심 가치 | 성격 | |
Prompt engineering | Source code | 표현 비용 완화 + 질적 전환 | LLM 시대에 독립적인 설계 영역으로 부상 |
Context engineering | 런타임 메모리 레이아웃 | 효율성 + 품질 | LLM 시대에 독립적인 설계 영역으로 부상 |
Harness engineering | OS / 실행 환경 | 실행 안정성 + 검증/강제 가능한 경계 | 기존 원칙의 재적용에 가까움 |