Prompt에서 Context를 지나 Harness Engineering으로

한 AI 엔지니어링 사례에서는 소규모 팀이 AI를 활용해 대규모 프로덕션 코드를 생성했다고 합니다. 여기서 흥미로운 점은 사람이 비즈니스 로직을 한 줄씩 직접 쓰는 역할에서 점점 멀어졌다는 것입니다. 이 실험이 던지는 질문은 단순합니다 — 그러면 그 엔지니어들은 뭘 한 걸까요?

답은 "AI를 제어하는 시스템을 만들었다"이고, 이 글은 그 시스템이 어떻게 진화해왔는지를 세 단계로 정리한 메모입니다. 단순한 프롬프트 요령 얘기가 아니라, AI를 실제 개발 프로세스 안에서 어떻게 통제할지에 대한 이야기입니다.

1단계: Prompt Engineering, 말하는 방식

LLM은 본질적으로 "이어쓰기 기계"입니다. 입력을 받으면 가장 그럴듯한 다음 토큰을 예측하는 구조입니다. 문제는 "그럴듯한"과 "내가 원하는"이 같지 않다는 점입니다.

Prompt Engineering은 이 간극을 줄이는 기술입니다. 제약 조건을 정교하게 걸어서 모델의 출력을 원하는 방향으로 유도합니다.

주요 기법들:

기법	핵심
Zero-shot	예시 없이 직접 지시
Few-shot	입출력 예시를 몇 개 보여주고 패턴 학습 유도
Chain-of-Thought	단계별 추론을 유도해서 논리적 정확도 향상
Role Prompting	"넌 20년 경력 Java 아키텍트야" 식의 역할 부여
Prompt Chaining	복잡한 작업을 작은 프롬프트 체인으로 분해

그런데 이건 이미 쇠퇴하고 있습니다.

GPT-3 시절에는 Few-shot 없이는 제대로 된 답을 못 뽑았습니다. GPT-4, Claude 3 이후로는 대충 말해도 의도를 파악합니다. 모델이 똑똑해질수록 프롬프트 정교함의 한계 효용이 급감합니다.

그리고 더 근본적인 문제가 있습니다 — 모델이 내 말을 완벽히 이해해도, 알아야 할 정보 자체를 모르면 여전히 틀린 답을 냅니다.

2단계: Context Engineering, 제공 정보

금붕어 비유가 적절합니다. 세상에서 가장 똑똑한 비서를 고용했는데, 이 비서의 기억이 7초밖에 안 된다고 생각해보세요. 매번 만날 때마다 프로젝트 배경, 지난 결정, 현재 상황을 브리핑해줘야 합니다.

LLM이 정확히 이 구조입니다. Context Window 밖의 정보는 존재하지 않습니다.

Context Engineering은 "이 제한된 창 안에 뭘 넣을 것인가"를 설계하는 기술입니다.

RAG (Retrieval-Augmented Generation)

모든 지식을 System Prompt에 때려박는 건 무리입니다. RAG는 "필요한 것만 검색해서 주입"하는 접근입니다:

사용자 질문 → 임베딩 → 벡터 검색 → 관련 문서 추출 → 컨텍스트에 주입 → LLM 응답

컨텍스트 압축

대화가 길어지면 Context Window가 찹니다. 연구에 따르면 컨텍스트가 길어질수록 "중간 부분을 까먹는(Lost in the Middle)" 현상이 발생합니다. 앞부분과 끝부분은 기억하는데 중간은 날립니다.

대응 전략:

Rolling Summary — 오래된 대화를 요약본으로 압축
Importance Scoring — 중요도 낮은 이력부터 제거
Hierarchical Memory — 단기 기억(상세) + 장기 기억(핵심만)

비슷한 대규모 AI 코드 생성 사례에서도 초기에 모든 코딩 규범을 거대한 agent.md에 몰아넣었다가, 100줄 이하의 인덱스로 압축하고 필요할 때 동적으로 불러오는 방식으로 바꾸자 모델 준수율이 크게 올라갔다고 합니다.

단일 진실 소스 (Single Source of Truth)

기술 결정이 Slack, 문서, PDF, GitHub Issue에 흩어져 있으면 사람도 헷갈립니다. AI한테는 재앙입니다. 뭘 믿어야 할지 모르니까 전부 섞어서 사불상을 만들어냅니다.

해법: 모든 결정/규범/문서를 코드 레포에 강제 통합. AI의 정보 소스를 하나로 고정.

3단계: Harness Engineering, 시스템 제어

여기가 이 글의 핵심입니다.

Prompt를 잘 쓰고, Context를 잘 관리해도 생기는 문제가 있습니다. 코드 생성 Agent한테 로그인 모듈을 맡겼더니:

로그인 로직은 맞게 짬 ✓
요청 안 한 DB 레이어를 "리팩토링" 해버림 ✗
테스트 통과했다고 주장하지만 실제로 테스트를 실행한 적 없음 ✗
프로젝트 네이밍 컨벤션 무시 ✗
중복 함수 3개 생성 ✗

이건 프롬프트 문제도, 컨텍스트 문제도 아닙니다. 시스템 레벨에서 제약, 검증, 피드백이 없어서 생기는 문제입니다.

Harness는 말 그대로 "마구(馬具)"입니다. 말에 고삐를 채우는 것입니다. AI Agent에 필요한 건 정확히 이겁니다.

AI Agent System = LLM + Harness (그 외 모든 것)

대규모 AI 코드 생성 사례에서 적용한 3대 전략

전략 1: Context Governance

초기에 거대한 agent.md에 모든 규범을 몰아넣었다가 실패. 100줄 인덱스 + 동적 로딩으로 전환. 산발적 결정 기록(Slack, 메일)을 전부 코드 레포로 이전.

전략 2: Verification Loop

Agent가 "완료했습니다"를 신용하지 않습니다:

Chrome DevTools 연결 — AI가 직접 스크린샷 찍어서 UI 시각 검증
관측성 도구 연결 — 로그, 성능 지표 직접 읽어서 문제 진단
Lint + 자동화 테스트 강제 — 미통과 시 에러를 AI에게 돌려보내 재수정

"자칭 완료"를 "검증된 완료"로 바꾸는 게 핵심입니다.

전략 3: Tech Debt Cleanup

AI가 대량 코드 생성하면 중복, 스타일 불일치, 폐기 문서가 쌓입니다. 백그라운드에서 Codex 태스크를 돌려 GC처럼 주기적으로 정리합니다. 기술 부채가 쌓이기 전에 청소합니다.

Anthropic의 F-Harness: 다중 Agent 분업

Anthropic은 다른 문제를 발견했습니다 — AI는 자기 버그에 후한 점수를 줍니다.

단일 Agent가 복잡한 UI를 구현할 때 생기는 일:

컨텍스트 소진으로 중간에 길을 잃음
절반만 끝내고 "다 했습니다" 선언
자기 평가가 과도하게 낙관적

해법: 역할 분리.

역할	하는 일
Planner	모호한 요구를 상세한 기능 목록으로 분해
Generator	기능 목록 따라 하나씩 실행, 완료 확인 후 다음으로
Evaluator	Generator와 독립된 제3자 심사. 생성 편향에 오염 안 됨

비용은 비쌉니다:

	단일 Agent	F-Harness (3 Agent)
시간	~20분	~6시간
비용	~$9	~$200
품질	미완성, 겨우 동작	프로덕션 레벨

22배의 비용으로 "겨우 동작"을 "프로덕션"으로 올립니다. 복잡도가 단일 Agent의 신뢰성 경계를 넘으면, 다중 Agent Harness가 유일한 해법이라는 주장입니다.

세 단계의 관계: 대체가 아니라 중첩

가장 흔한 오해는 "Harness가 최상위니까 Prompt나 Context는 쓸모없어진다"는 생각입니다.

아닙니다. 중첩 구조입니다:

Prompt가 나쁘면 → Context를 아무리 잘 넣어도 모델이 잘못 해석
Context가 없으면 → Harness가 완벽해도 Agent가 정보 진공 속에서 방황
Harness가 없으면 → 단발 대화는 잘 되지만 복잡한 태스크에서 에러 누적 → 붕괴

Prompt Engineering  → "뭐라고 말할까"
Context Engineering → "뭘 알려줄까"
Harness Engineering → "시스템이 어떻게 안정적으로 돌아가게 할까"

Harness 감쇠 법칙

Anthropic 연구진이 발견한 규칙 하나:

모델이 강해질수록, 필요한 Harness가 얇아집니다.

Claude 3.0에서는 강제적인 체크포인트, 컨텍스트 리셋, 하드코딩된 검증 규칙이 필수였습니다. Claude 3.5에서는 그중 상당수가 불필요해졌습니다. 모델 자체의 자기 검증 능력이 올라갔기 때문입니다.

이게 의미하는 바:

오늘은 Harness가 필수입니다 — 모델이 아직 완벽하지 않기 때문입니다
Harness는 과도기 기술일 수 있습니다 — 모델이 규칙을 내재화하는 방향으로 진화하는 중입니다

실무 판단 기준은 "이 제약은 모델 능력 부족 때문인가, 비즈니스 로직 자체가 요구하는 것인가?"입니다. 전자는 모델이 강해지면 사라집니다. 후자만 남습니다.

엔지니어의 역할 변화

OpenAI 실험의 결론:

"Human steer, agents execute."

엔지니어가 하는 일이 바뀝니다:

과거	지금
하루에 코드 몇 줄 쓰나	Harness가 얼마나 높은 코드 처리량을 감당하나
얼마나 복잡한 로직을 짜나	얼마나 견고한 Agent 시스템을 설계하나
얼마나 어려운 버그를 잡나	얼마나 완전한 자동 피드백 루프를 만드나
개인 산출량	시스템 레버리지

코드를 쓰는 사람에서, 코드를 잘 쓰게 만드는 시스템을 설계하는 사람으로.

내 생각

솔직히 말하면, 이 글의 프레이밍 자체는 새롭지 않습니다. Prompt → RAG → Agent Orchestration 순서는 이미 업계 공감대입니다. 하지만 정리가 깔끔하고, OpenAI와 Anthropic의 실제 실험 데이터를 기반으로 한다는 점에서 가치가 있습니다.

특히 인상적인 포인트 두 가지:

Harness 감쇠 법칙 — "오늘 만드는 Harness의 상당 부분이 내년에는 불필요해진다"는 관찰입니다. 이걸 인지하고 있느냐 없느냐가 과잉 설계를 피하는 핵심입니다. 미디어 파이프라인으로 치면, 예전에는 세그먼트 에러를 수동으로 검출해야 했지만 이제는 패키저가 알아서 잡아주는 것과 비슷한 진화입니다.
Verification Loop — "AI가 완료했다고 하면 믿지 마라, 검증해라"는 원칙입니다. 이건 라이브 스트리밍 운영에서도 익숙한 철학입니다. 인코더가 "정상"이라고 리포트해도 실제 출력을 모니터링하지 않으면 방송 사고가 납니다. 시스템 신뢰도의 기본은 독립적인 검증 계층이라는 건 도메인을 불문합니다.

결국 핵심 메시지는 하나입니다: "AI를 잘 쓰는 것"은 프롬프트를 잘 쓰는 게 아니라, AI가 잘 돌아가는 시스템을 만드는 것입니다. 그리고 그 시스템을 만드는 사람이 엔지니어의 새로운 정체성이 됩니다.

참고 자료

Tencent Cloud Developer article 참고

Prompt에서 Context를 지나 Harness Engineering으로 ​

1단계: Prompt Engineering, 말하는 방식 ​

2단계: Context Engineering, 제공 정보 ​

RAG (Retrieval-Augmented Generation) ​

컨텍스트 압축 ​

단일 진실 소스 (Single Source of Truth) ​

3단계: Harness Engineering, 시스템 제어 ​

대규모 AI 코드 생성 사례에서 적용한 3대 전략 ​

Anthropic의 F-Harness: 다중 Agent 분업 ​

세 단계의 관계: 대체가 아니라 중첩 ​

Harness 감쇠 법칙 ​

엔지니어의 역할 변화 ​

내 생각 ​

참고 자료 ​