프롬프트에서 하네스로: 에이전틱 패턴의 진화

세 단계와 하나의 원칙

AI로 소프트웨어를 만드는 방법은 세 번 중심을 옮겼다. 각 전환은 앞 단계가 약속을 지키지 못한 데서 시작했다.

관통하는 원칙은 엄밀함의 이동(relocating rigor)이다. 엄밀함은 사라지지 않고 더 높은 추상화 층으로 옮긴다. 설계 문서가 자동화 테스트로, 컴파일러 타입 검사가 런타임 테스트 스위트로 옮겨 갔듯, AI 개발에서도 코드 작성 → 컨텍스트 설계 → 시스템 설계로 옮겨 간다. 그래서 "AI에게 코드를 맡기면 엄밀함을 잃는다"는 비판은 반만 맞다. 엄밀함을 둘 자리를 옮기지 않으면 잃는다.

엄밀함을 옮기는 세 원칙은 이렇다.

• 불변 조건은 기계가 강제하는 규칙으로 쓴다. "양수만 받는다"를 주석이 아니라 타입이나 단언(assertion)으로 검사한다.
• 실패는 즉시, 크게 드러나야 한다. 조용한 에러는 나중에 더 큰 문제로 돌아온다.
• 엔지니어의 일은 타이핑에서 의도 명세와 결과 검증으로 바뀐다.

세 단계는 서로 대체하지 않고 포함한다. 좋은 하네스에도 좋은 컨텍스트가, 좋은 컨텍스트에도 좋은 프롬프트가 필요하다. 프롬프트 엔지니어링은 죽은 것이 아니라 하네스의 하위 모듈이 됐다.

1. 프롬프트 엔지니어링

모델에 보내는 지시문의 품질이 결과를 정한다고 보는 접근이다. 자연어 지시가 곧 프로그램이 되는 패러다임(Software 3.0)에서 출발했다.

핵심 기법

네 가지 에이전틱 디자인 패턴

Andrew Ng이 정리한 실무 프레임워크다.

모델을 바꾸지 않아도 모델 바깥의 패턴을 바꾸면 성능이 뛴다. 약한 모델을 에이전틱 워크플로로 감싸면 강한 모델의 제로샷보다 나은 경우가 있다. 이것이 "모델 밖의 시스템이 중요하다"는 첫 신호였다.

플로우 엔지니어링: 즉답을 요구하지 않는다

생각의 사슬이 통하는 이유는 LLM에게 생각할 토큰이 필요하기 때문이다. 토큰 하나를 만드는 계산 깊이는 고정이므로(LLM은 무엇을 하고 왜 작동하나), 어려운 문제는 중간 과정을 토큰으로 써 내려갈 자리를 줘야 풀린다.

이 생각을 프롬프트 한 장에서 여러 단계의 흐름으로 넓힌 것이 플로우 엔지니어링(flow engineering) 이다. CodiumAI(현 Qodo)의 AlphaCodium(2024.01)이 붙인 이름이다. 핵심은 어려운 질문에 바로 답을 내라고 하지 않고, 맥락을 주고 반복해서 실험할 수 있는 구조를 만들어 주는 것이다.

① 문제 파악: 목표·입력·출력·제약을 자기 말로 정리한다
② 공개 테스트 해설: 주어진 예제가 왜 그런 입출력이 되는지 설명한다
③ 답안 2~3개: 정확성·단순성·강건성으로 순위를 매긴다
④ 테스트 추가 생성: 경계 사례를 담은 테스트를 더 만든다
⑤ 실행·수정 반복: 테스트를 돌려 실패하면 고치거나 새 답을 찾는다

모델을 바꾸지 않고 흐름만 바꿨다는 점에서, 위의 「모델 바깥의 패턴」을 가장 잘 보여 주는 예다. ④·⑤처럼 스스로 검증 수단을 만들고 돌리는 단계는 오늘날 코딩 에이전트의 테스트 루프와 같다. 코딩이 아닌 분야에서는 테스트 대신 합성 데이터(synthetic data)를 만들어 답을 확인하는 식으로 같은 구조를 옮길 수 있다.

워크플로와 에이전트는 구분한다. 워크플로는 흐름이 미리 정해진 파이프라인(생성 → 리뷰 → 테스트)이고, 에이전트는 LLM이 다음 행동을 스스로 고르는 자율 프로세스다. 우열은 없다. 원칙은 가능한 한 단순하게 시작하기다. 워크플로로 충분하면 에이전트를 쓰지 않는다.

한계: 프롬프트가 완벽해도 볼 수 없으면 모른다

프로젝트가 커지면 "기존 유틸 함수를 재사용하라"고 아무리 써도 에이전트가 새 함수를 만든다. 유틸 파일이 컨텍스트 창에 없으면 존재를 모르기 때문이다. 프롬프트 문제가 아니라 컨텍스트 문제다. 측정·테스트 없이 시행착오로 프롬프트를 고치는 블라인드 프롬프팅(blind prompting)도 한계였다. 모델은 비결정적이라 "Please" 한 단어, 줄바꿈 하나에도 결과가 바뀐다.

바이브 코딩이라는 극단

코드를 읽지 않고, 에러는 복사해 붙이고, 돌아가면 끝내는 방식이 바이브 코딩(vibe coding)이다. 프롬프트 엔지니어링의 논리적 극단이다. 원래 주말 프로젝트용이라는 단서가 붙었지만 실무로 번졌고, 데모에서 빛나던 MVP가 운영에서 무너지는 숙취가 뒤따랐다. 아무도 읽지 않은 코드는 아무도 고칠 수 없다.

LLM이 모든 코드를 썼더라도 사람이 리뷰하고 테스트했다면 그것은 바이브 코딩이 아니다. (Simon Willison)

핵심은 누가 코드를 썼느냐가 아니라 엄밀함이 어디 있느냐다. 바이브 코딩은 엄밀함의 세 원칙을 모두 어긴다.

2. 컨텍스트 엔지니어링

다음 단계를 풀 수 있도록 컨텍스트 창을 딱 맞는 정보로 채우는 기술이다. 질문이 "무엇을 말할까"에서 "무엇을 보여 줄까"로 바뀐다.

LLM을 운영체제로 보기

프롬프트는 OS에 치는 명령 한 줄이다. 성능은 RAM(컨텍스트 창)에 무엇을 올리느냐가 정한다. 필요한 파일이 마운트되지 않은 디스크에 있으면 ls를 아무리 정교하게 쳐도 소용없다.

컨텍스트 창에 들어가는 재료는 다섯 가지다. 시스템 프롬프트, 사용자 입력, 대화 기록, 도구 결과, 검색한 지식.

네 가지 전략: Write · Select · Compress · Isolate

컨텍스트 엔지니어링은 정보를 많이 넣는 일(context stuffing)이 아니다. 양보다 신호 대 잡음 비를 최적화한다.

중간 정보 유실(lost in the middle): 긴 컨텍스트 한가운데 묻힌 정보는 정확도가 크게 떨어진다. 컨텍스트가 일정 수준 넘게 차면 성능이 떨어지는 「멍청한 구간(dumb zone)」이 있다는 경험칙도 있다. 많이 넣을수록 좋다는 직관과 반대다.

저장과 표현을 나눈다

컨텍스트는 원시 데이터를 쏟아 놓은 것이 아니라 더 큰 상태 시스템 위의 컴파일된 뷰다.

• 저장과 표현 분리: 전체 대화·도구 결과는 세션에 원본 그대로 두고, 매 턴 모델에 보낼 작업 컨텍스트는 필요한 것만 골라 새로 조립한다. DB의 테이블과 뷰 관계와 같다.
• 명시적 변환 파이프라인: "시스템 프롬프트 주입 → 관련 기록 선택 → 도구 결과 요약 → 토큰 예산 확인"처럼 이름 붙은 단계를 정해진 순서로 돌린다. 즉흥적인 문자열 이어 붙이기가 아니다.
• 기본 범위 제한: 서브에이전트에게는 전체 대화가 아니라 맡은 일에 필요한 것만 준다. 컨텍스트 창 버전의 최소 권한 원칙이다.

KV 캐시 적중률이 운영 지표다

LLM은 토큰마다 어텐션의 Key·Value를 계산한다. 요청의 앞부분(prefix)이 이전 요청과 같으면 그 부분은 캐시를 재사용한다. 캐시를 읽는 토큰은 일반 입력보다 훨씬 싸다(Claude API에서는 기본 입력 단가의 10분의 1). 반대로 앞부분의 토큰 하나만 바뀌어도 그 뒤 캐시가 전부 무효가 된다. 서버 쪽에서 KV 캐시가 GPU 메모리를 어떻게 차지하는지는 LLM 서빙의 병목에 있다.

flowchart TB
  win["컨텍스트 창"]
  win --> st["안정된 앞부분(stable prefix)<br/>시스템 프롬프트, 정체성, 도구 정의, 장기 요약"]
  win --> va["변하는 뒷부분(variable suffix)<br/>최신 사용자 입력, 새 도구 결과"]

그래서 운영에서는 프롬프트의 "품질"보다 안정성이 더 중요하다. 실무 원칙은 이렇다.

에이전트 인프라

한계: 컨텍스트는 필요조건일 뿐이다

• 단일 턴에 갇힌다. 컨텍스트 기법은 "이번 호출에 무엇을 넣을까"에 집중한다. 에이전트는 수십 번 연쇄 결정을 한다. 15턴째에 이미 압축된 3턴째 결과가 필요하면? 컨텍스트를 완벽히 구성해도 그것을 소비하는 루프가 엉망이면 시스템 문제다.
• 에러 복구가 없다. 도구 호출 실패, 환각, 비용 급증에는 별도 장치가 필요하다. 무료 → 저가 → 고가 순으로 시도하는 비용 인식 복구, 같은 실수 반복을 감지해 멈추는 수확 체감 감지, 연속 실패 시 자동 정지하는 서킷 브레이커.
• 보안을 다루지 않는다. 무엇을 넣을지는 다루지만 무엇을 막을지는 다루지 않는다.

3. 하네스 엔지니어링

에이전트가 실수할 때마다, 그 실수가 구조적으로 다시 일어날 수 없도록 시스템을 바꾼다.

프롬프트를 고치는 것이 아니라 에이전트를 둘러싼 규칙·도구·제약·피드백 루프를 바꾸는 일이다.

에이전트 = 모델 + 하네스

하네스는 에이전트에서 모델을 뺀 전부다. 모델이 CPU라면 하네스는 운영체제(컨텍스트 관리, 도구 관리, 권한 통제, 에러 복구)다. 말이 아무리 힘세도 고삐와 마구가 없으면 밭을 갈 수 없다. 에이전트의 정의 "목표를 이루려고 루프 안에서 도구를 실행하는 LLM"에서 핵심은 루프이고, 하네스는 그 루프를 통제한다.

하네스의 네 사분면

• 가이드는 비용이 거의 없지만 강제력이 없다. 에이전트가 무시할 수 있다.
• 계산형 피드백은 가이드를 무시해도 기계적으로 잡는다. 커스텀 린터로 아키텍처 규칙을 강제하면 사람 리뷰어를 대신한다. 자율성의 핵심 축이다.
• 지시문은 결정적 규칙이 못 잡는 뉘앙스("불확실하면 확인을 구하라")를 다룬다.
• 추론형 피드백은 컴파일은 되지만 의미가 틀린 코드를 잡는다.

운영 하네스는 네 사분면을 겹겹이 쌓는다(심층 방어). 운영에서 성공하는 "AI 에이전트" 대부분은 마법 같은 자율 존재가 아니라 핵심 지점에 LLM을 끼운 잘 설계된 전통 소프트웨어다. 결정적 게이트의 필요성은 AI 시대 개발자의 역할의 「하네스와 오라클」에도 있다.

실전 패턴

자율 루프 설계는 루프 엔지니어링, 생성·검증 루프를 디자인 시스템에 적용한 예는 디자인 시스템을 아는 화면 생성 에이전트 설계하기에 있다.

보안: 치명적 삼요소와 2의 규칙

에이전트가 다음 셋을 동시에 가지면 보안 사고는 시간문제다. 이를 치명적 삼요소(lethal trifecta)라고 한다.

1. 신뢰할 수 없는 입력을 처리한다(외부 웹, 메일, 사용자 입력)
2. 민감한 시스템·데이터에 접근한다(개인정보, 내부 API, DB)
3. 상태를 바꿀 수 있다(메일 발송, 파일 삭제, API 호출)

프롬프트 인젝션 한 번으로 회사 데이터가 빠져나갈 수 있다(공격 사례는 LLM 보안 공격). 2의 규칙(Rule of Two)은 이를 실행 규칙으로 바꾼다. 셋 중 최대 둘만 동시에 허용하고, 셋 다 필요하면 사람의 승인을 거친다.

이 가드레일은 기능 제약이 아니라 신뢰의 전제 조건이다.

하네스는 걷어 낼 수 있어야 한다

모델이 좋아지면 하네스의 "똑똑한" 로직 일부는 쓸모없어진다. 이전 모델용 에러 복구 로직의 절반이 다음 모델에서는 짐이 될 수 있다. 하네스 설계는 무엇을 만들까만큼 무엇을 쉽게 뗄 수 있게 할까의 문제다. 오늘의 과잉 설계는 내일의 모델 업데이트에 족쇄가 된다.

다음에 옮겨 갈 자리

• 감독 에이전트(guardian agent): 배포 직전 다른 에이전트가 실시간으로 "규정 위반"을 막는다. 엄밀함이 실행에서 감독으로 옮긴다.
• 평가 엔지니어링: 벤치마크 점수보다 실제 작업 완료율과 실패에서 회복하는 방식이 중요해진다. 컴파일 여부는 기계가 판단하지만 "글이 잘 읽히나", "디자인이 아름다운가" 같은 검증 불가능한 보상은 LLM-as-judge로 평가하되 평가자 편향이 남는다. 자세한 방법은 평가 주도 개발을 본다.
• 지식 엔진: 코드에 남지 않는 "왜 이 아키텍처를 골랐나", "반년 전에 왜 롤백했나"를 코드 그래프·커밋 기록·세션 메모리로 엮어, "이 함수를 고쳐"가 아니라 "이 함수가 왜 이렇게 생겼는지 이해하고 고쳐"를 가능하게 한다.

역사

GitHub Copilot의 변화가 세 단계의 축소판이다. 현재 파일 자동완성(프롬프트) → 대화형 Copilot Chat(컨텍스트로 이동) → 여러 파일을 고치고 린트 루프를 도는 에이전트 모드 → 이슈를 받아 클라우드에서 PR까지 만드는 코딩 에이전트(하네스).

정리

• 프롬프트 → 컨텍스트 → 하네스로 옮겨 온 것은 엄밀함이 놓이는 자리다. 각 단계는 앞 단계를 버리지 않고 포함한다.
• 프롬프트가 완벽해도 필요한 정보가 컨텍스트 창에 없으면 소용없다. 컨텍스트는 양이 아니라 신호 대 잡음 비와 앞부분 안정성(KV 캐시)으로 설계한다.
• 컨텍스트가 완벽해도 그것을 소비하는 루프가 엉망이면 실패한다. 하네스는 결정적·비결정적 × 사전·사후의 네 사분면을 겹쳐 쌓는다.
• 만드는 쪽과 판정하는 쪽을 나누고, 볼 수 없는 지식은 레포에 넣고, 실수는 하네스를 고쳐 구조적으로 막는다.
• 외부 입력·민감 데이터·상태 변경 중 둘까지만 허용하고, 모델이 좋아지면 걷어 낼 수 있게 만든다.

관련 노트: 내 일을 줄이는 하네스 만들기, 루프 엔지니어링, AI 시대 개발자의 역할, 디자인 시스템을 아는 화면 생성 에이전트 설계하기, 멀티 에이전트, 프롬프트 작성법 치트시트, 평가 주도 개발