Injoys
생성형 AI의 품질을 높이는 일을 모두 ‘프롬프트를 잘 쓰는 것’으로 묶으면, 실패 원인을 정확히 진단하기 어렵다. 프롬프트·컨텍스트·하네스·에이전틱·루프 엔지니어링은 서로 대체하는 유행어가 아니라, 요청 표현, 정보 선택, 실행 환경, 자율적 의사결정, 반복 개선이라는 서로 다른 제어면을 다루는 보완적 설계 방식이다.
다섯 개념의 핵심 정의
| 구분 | 핵심 질문 | 주된 설계 대상 | 대표 산출물 | 대표 성공 기준 |
|---|---|---|---|---|
| 프롬프트 엔지니어링 | AI에게 일을 어떻게 지시할 것인가? | 지시문, 제약, 예시, 출력 형식 | 프롬프트 템플릿, 예시 입력·출력 | 지시 준수율, 형식 정확도, 1차 결과 품질 |
| 컨텍스트 엔지니어링 | 지금 AI에게 무엇을 보여줄 것인가? | 시스템 지침, 검색 문서, 대화 상태, 메모리, 도구 결과 | 컨텍스트 조립 규칙, 검색·요약 정책 | 관련성, 최신성, 근거성, 토큰 효율 |
| 하네스 엔지니어링 | AI가 실수하기 어렵게 어떤 작업 환경을 만들 것인가? | 도구, 권한, 샌드박스, 저장소 구조, 검증기, 로그 | 작업 규칙, 도구 인터페이스, 테스트·CI, 런북 | 재현성, 안전성, 검증 가능성, 복구 가능성 |
| 에이전틱 엔지니어링 | 다음 행동을 누가, 어떤 범위에서 결정할 것인가? | 목표, 계획, 도구 선택, 상태 전이, 위임 | 에이전트 루프, 오케스트레이션, 승인 지점 | 과업 완료율, 적절한 도구 선택, 인간 개입률 |
| 루프 엔지니어링 | 첫 결과가 틀렸을 때 어떻게 수렴시킬 것인가? | 생성, 평가, 원인 분류, 수정, 재실행, 종료 조건 | 평가기, 회귀 테스트, 재시도 정책, 실패 분류 | 1차 통과율, 복구율, 반복 횟수, 최종 통과율 |
다섯 개념을 한 줄로 연결하면 다음과 같다.
요청을 표현한다 → 필요한 정보를 보여준다 → 안전한 작업 환경을 제공한다 → AI가 다음 행동을 선택하게 한다 → 결과가 기준을 통과할 때까지 검증하고 개선한다.
용어를 해석할 때의 주의점
프롬프트 엔지니어링과 에이전트는 비교적 널리 쓰이는 용어지만, 하네스 엔지니어링은 아직 사용 범위가 문맥마다 다르다. 어떤 글은 모델을 제외한 거의 모든 실행 계층을 하네스로 부르고, 어떤 글은 코딩 에이전트 사용자가 저장소 바깥에 만드는 규칙·검증·피드백 구조로 좁혀 설명한다. ‘루프 엔지니어링’도 단일 표준에 의해 고정된 정식 분류라기보다, 생성과 검증을 폐쇄형 피드백 과정으로 설계한다는 실무적 명칭으로 이해하는 편이 정확하다.
1. 프롬프트 엔지니어링: 지시의 품질을 설계한다
프롬프트 엔지니어링은 모델에게 전달하는 지시를 명확하고 검증 가능하게 만드는 작업이다. 흔히 한 번의 요청과 응답에서 가장 눈에 띄는 효과를 내지만, 시스템 메시지나 멀티턴 대화 규칙에도 적용된다.
좋은 프롬프트는 보통 다음 요소를 분리한다.
- 목표: 무엇을 완료해야 하는가
- 입력: 분석 대상과 입력 경계는 어디까지인가
- 제약: 하지 말아야 할 것, 허용 범위, 길이와 형식
- 출력 계약: JSON, 표, 코드 패치 등 결과 구조
- 성공 기준: 무엇을 만족하면 정답으로 볼 것인가
- 불확실성 처리: 정보가 부족하거나 충돌할 때 어떻게 할 것인가
- 예시: 기대 행동을 보여주는 대표적 입력·출력
실무 템플릿은 다음처럼 단순하게 시작할 수 있다.
목표:
입력:
제약:
출력 형식:
성공 기준:
검증 방법:
불확실할 때의 처리:
대표 예시:
프롬프트를 다듬기 전에 성공 기준과 경험적 테스트 방법을 먼저 정의해야 한다는 점이 중요하다. 모든 실패가 프롬프트 수정으로 해결되는 것은 아니며, 비용·지연 시간·도구 오류·잘못된 자료 선택은 다른 계층의 문제일 수 있다.
프롬프트 엔지니어링이 잘 해결하는 문제
- 결과 형식이 자주 깨지는 문제
- 지시의 우선순위가 모호한 문제
- 분류, 추출, 변환, 요약처럼 입력과 출력이 비교적 명확한 문제
- 대표 예시를 주면 성능이 안정되는 문제
프롬프트만으로 해결하기 어려운 문제
- 필요한 사실이나 파일이 입력에 없는 경우
- 오래되거나 서로 충돌하는 문서가 섞인 경우
- 외부 시스템을 안전하게 조회·수정해야 하는 경우
- 여러 단계의 실행 상태와 실패 복구가 필요한 경우
- 결과의 정답 여부를 객관적으로 검사할 방법이 없는 경우
2. 컨텍스트 엔지니어링: AI가 보는 정보를 설계한다
컨텍스트 엔지니어링은 모델이 답을 생성하는 순간 사용할 수 있는 정보 전체를 선택·정렬·압축·갱신하는 작업이다. 컨텍스트에는 프롬프트뿐 아니라 시스템 지침, 사용자 요청, 대화 이력, 검색 문서, 메모리, 도구 설명, 도구 실행 결과, 현재 시간, 권한 상태와 작업 진행 상태가 포함될 수 있다.
컨텍스트 창은 유한하므로 ‘많이 넣기’가 아니라 필요한 정보를 적시에 넣기가 목표다. Anthropic은 컨텍스트를 에이전트의 중요하지만 유한한 자원으로 설명하며, 긴 상호작용에서는 최소한의 도구 집합, 대표 예시, 런타임 검색, 압축과 메모리 같은 전략을 권고한다.
핵심 설계 원칙
- 관련성 우선: 현재 단계에 필요한 정보만 넣는다.
- 출처와 최신성: 문서의 작성 시점, 버전, 소유자, 신뢰도를 함께 관리한다.
- 즉시 검색: 모든 자료를 미리 주입하기보다 필요할 때 파일·DB·검색 시스템에서 가져온다.
- 정보 계층화: 고정 규칙, 현재 과업, 참고 자료, 도구 결과를 구분한다.
- 충돌 처리: 여러 자료가 다르면 우선순위와 기준 원본을 명시한다.
- 압축과 상태 보존: 오래된 대화는 요약하되 결정, 미해결 문제, 근거 링크는 잃지 않는다.
- 지시와 데이터 분리: 웹페이지나 문서 속 문장을 시스템 명령처럼 취급하지 않도록 경계를 둔다.
예시
고객 지원 AI가 환불 정책을 답할 때 단순히 “정확히 답하라”는 프롬프트만 강화해도 한계가 있다. 올바른 컨텍스트 엔지니어링은 고객의 국가, 구매일, 상품 유형, 현재 정책 버전, 예외 조항, 주문 상태를 필요한 순간에 조회해 함께 제공하고, 답변에 사용한 정책 조항을 추적 가능하게 만든다.
3. 하네스 엔지니어링: AI가 일하는 환경을 설계한다
하네스는 모델의 지능을 실제 업무로 연결하는 실행 골격이다. 하네스 엔지니어링은 AI가 자주 하는 실수를 문서, 도구, 권한, 구조, 자동 검증과 피드백으로 예방하거나 조기에 발견하도록 작업 환경을 설계하는 일이다.
하네스의 주요 구성요소
| 구성요소 | 역할 | 예시 |
|---|---|---|
| 작업 지침 | 반복 업무의 절차와 금지 사항을 명시 |
AGENTS.md, 런북, 체크리스트 |
| 지식 구조 | AI가 필요한 자료를 쉽게 찾게 함 | 저장소 지도, ADR, 용어집, 예시 모음 |
| 도구 인터페이스 | 행동의 입력·출력을 명확히 제한 | 파일 검색, DB 조회, 코드 실행, 배포 API |
| 실행 환경 | 실패를 격리하고 재현성을 높임 | 샌드박스, 컨테이너, 고정 의존성 |
| 검증기 | 결과가 기준을 만족하는지 자동 확인 | 스키마 검사, 단위 테스트, 린터, 정책 검사 |
| 권한·승인 | 위험한 행동을 제한 | 최소 권한, 읽기/쓰기 분리, 인간 승인 |
| 관측성 | 무엇을 보고 어떤 행동을 했는지 기록 | 트레이스, 로그, 도구 호출 기록, 비용 |
| 복구 구조 | 실패 후 안전하게 되돌리고 재개 | 체크포인트, 롤백, 재시도 예산 |
OpenAI의 하네스 엔지니어링 사례는 엔지니어의 역할을 단순한 코드 작성보다 환경, 의도, 저장소 지식, 테스트·검증·리뷰·복구 루프를 설계하는 쪽으로 설명한다. 핵심은 AI에게 “더 열심히 하라”고 재요청하는 것이 아니라, 부족했던 능력과 신호를 환경에 명시적으로 추가하는 것이다.
자료 구조 예시
/ai
/instructions # 공통 규칙과 역할별 지침
/skills # 반복 작업 절차
/examples # 좋은 결과와 나쁜 결과
/evals # 평가 데이터와 채점 규칙
/policies # 권한, 보안, 승인 정책
/runbooks # 장애·예외 대응
이 구조 자체가 정답은 아니다. 중요한 것은 자료가 최신 상태로 유지되고, 중복·충돌이 적으며, AI가 필요한 시점에 찾을 수 있고, 규칙이 자동 검사로 이어지는지다.
4. 에이전틱 엔지니어링: 목표와 도구를 주고 다음 행동을 위임한다
에이전틱 엔지니어링은 AI에게 목표, 도구, 작업 상태와 경계 조건을 주고, 목표를 달성하기 위한 다음 단계를 일정 범위에서 스스로 선택하게 만드는 설계다.
Anthropic은 워크플로를 미리 정해진 코드 경로로 LLM과 도구를 조율하는 시스템, 에이전트를 모델이 자신의 과정과 도구 사용을 동적으로 결정하는 시스템으로 구분한다. OpenAI도 에이전트를 LLM이 워크플로 실행을 관리하고, 외부 시스템과 상호작용할 도구를 동적으로 선택하는 시스템으로 설명한다.
기본 에이전트 루프
- 현재 목표와 상태를 관찰한다.
- 다음 하위 목표나 행동을 계획한다.
- 도구를 선택해 실행한다.
- 결과와 환경 변화를 확인한다.
- 완료, 수정, 재시도, 인간 이관 중 하나를 결정한다.
에이전트가 적합한 경우
- 작업 순서가 입력마다 달라지는 경우
- 자연어, 문서, 코드처럼 비정형 정보를 해석해야 하는 경우
- 여러 도구를 선택적으로 사용해야 하는 경우
- 중간 결과를 보고 계획을 바꿔야 하는 경우
- 실패 원인이 다양하고 일정 수준의 복구가 가능한 경우
에이전트가 과한 경우
- 규칙과 순서가 고정된 단순 자동화
- 단일 API 호출이나 SQL로 확실히 해결되는 업무
- 검증 수단이 없고 오류 비용이 매우 큰 업무
- 결제, 삭제, 배포처럼 되돌리기 어려운 행동을 승인 없이 수행하는 구조
- 단일 에이전트로 충분한데 역할만 늘린 다중 에이전트 구조
자율성은 이분법이 아니다. 추천만 하는 보조형, 제한된 읽기·쓰기만 허용한 실행형, 주요 단계마다 승인을 받는 감독형, 저위험 범위에서 장시간 동작하는 고자율형으로 나눌 수 있다. 업무 위험과 검증 능력에 맞춰 단계적으로 확장해야 한다.
5. 루프 엔지니어링: 검증 가능한 개선 과정을 설계한다
루프 엔지니어링은 단순한 재시도가 아니다. 생성 → 검증 → 실패 원인 분석 → 수정 전략 선택 → 재실행 → 종료 판단을 명시적인 폐쇄형 피드백 시스템으로 만드는 것이다.
제대로 된 루프의 구성
- 후보 생성: 초안, 코드, 계획, 데이터 변환 결과를 만든다.
- 검증: 테스트, 스키마, 참조 데이터, 정책, 근거 검사를 실행한다.
- 원인 분류: 지시 오류, 컨텍스트 누락, 도구 실패, 구현 결함, 평가기 결함을 구분한다.
- 수정: 실패 원인에 맞는 최소 변경을 적용한다.
- 재실행: 전체를 처음부터 반복하지 말고 필요한 단계부터 다시 수행한다.
- 종료: 통과, 최대 반복 횟수, 비용 한도, 시간 한도, 불확실성 임계치 중 하나에서 멈춘다.
- 회귀 보호: 새 수정이 기존 성공 사례를 깨뜨리지 않았는지 확인한다.
에이전트 평가는 입력과 출력만 보는 단일 턴 평가보다 복잡하다. 에이전트는 여러 번 도구를 호출하고 환경 상태를 바꾸므로, 최종 결과뿐 아니라 과정과 환경 변화를 함께 검사해야 한다. 자동 평가의 핵심은 입력을 주고 출력 또는 변경된 상태에 채점 논리를 적용하는 것이다.
검증기의 우선순위
- 결정적 검증: 컴파일, 단위 테스트, 스키마, 수학적 제약, 권한 검사
- 참조 기반 검증: 기준 데이터, 원문 인용, 데이터베이스 대조
- 규칙 기반 검증: 금칙어, 필수 필드, 정책 조건
- 모델 기반 평가: 문체, 의미 보존, 종합 품질처럼 규칙화가 어려운 항목
- 인간 평가: 고위험 판단, 목표 자체의 타당성, 예외 승인
가능하면 결정적 검증을 먼저 사용하고, 모델 평가만으로 자기 결과를 자기 채점하게 하지 않는다. 모델 평가를 쓸 때는 평가 기준, 예시, 편향 점검, 표본 인간 검토를 함께 둔다.
다섯 방식은 계층이지 대체재가 아니다
실제 시스템에서는 다섯 방식이 함께 작동한다.
- 프롬프트는 현재 행동의 계약을 만든다.
- 컨텍스트는 판단에 필요한 상태와 근거를 제공한다.
- 하네스는 행동 가능한 환경과 안전장치를 제공한다.
- 에이전틱 설계는 다음 행동의 선택권을 배분한다.
- 루프 설계는 오류를 발견하고 품질을 수렴시킨다.
따라서 “컨텍스트 엔지니어링이 프롬프트 엔지니어링을 대체했다”거나 “에이전트를 쓰면 워크플로가 필요 없다”는 식의 이해는 부정확하다. 더 넓은 계층이 좁은 계층을 포함하거나 활용할 뿐이며, 단순한 문제에는 단순한 설계가 더 안정적일 수 있다.
실무 예시: 버그를 수정하는 AI 코딩 시스템
“로그인 후 특정 사용자만 500 오류가 발생한다”는 버그를 AI가 수정한다고 가정해 보자.
프롬프트 엔지니어링
- 오류 재현 조건을 확인하라.
- 공개 API는 변경하지 마라.
- 최소 수정으로 해결하라.
- 수정 후 테스트 결과와 남은 위험을 보고하라.
컨텍스트 엔지니어링
- 이슈 설명과 오류 로그
- 관련 요청 추적 ID
- 인증·사용자 모델 관련 파일
- 최근 변경 내역
- 아키텍처 규칙과 코딩 표준
- 실패한 테스트와 실행 환경 정보
하네스 엔지니어링
- 저장소 검색, 파일 읽기·편집, 테스트 실행 도구
- 격리된 브랜치와 샌드박스
- 포맷터, 린터, 단위·통합 테스트
- 변경 금지 영역과 권한 정책
- 모든 명령과 파일 변경의 로그
- 실패 시 롤백과 체크포인트
에이전틱 엔지니어링
AI가 재현, 가설 수립, 관련 코드 탐색, 패치, 테스트, 결과 요약의 순서를 상황에 따라 선택한다. 다만 배포나 데이터 변경은 인간 승인을 요구한다.
루프 엔지니어링
테스트가 실패하면 같은 명령을 반복하는 대신 실패 유형을 분류한다. 재현 실패라면 컨텍스트 수집을 보완하고, 회귀 실패라면 패치를 줄이며, 환경 오류라면 의존성과 설정을 복구한다. 모든 필수 테스트가 통과하고 변경 근거가 남으면 종료한다.
문제 증상으로 어떤 엔지니어링이 필요한지 찾는 법
| 증상 | 우선 점검할 영역 |
|---|---|
| 출력 형식이나 문체가 자주 어긋난다 | 프롬프트 |
| 답변에 필요한 사실·파일이 빠진다 | 컨텍스트 |
| 도구를 잘못 고르거나 위험한 명령을 실행한다 | 하네스와 권한 설계 |
| 고정 순서로는 처리하기 어려운 변형이 많다 | 에이전틱 설계 |
| 첫 결과는 자주 틀리지만 자동 판정은 가능하다 | 루프와 평가기 |
| 실패 원인을 알 수 없고 재현이 어렵다 | 하네스의 관측성 |
| 반복할수록 비용만 늘고 품질이 나아지지 않는다 | 원인 분류, 검증 신호, 종료 조건 |
| 자료가 많을수록 오히려 답이 나빠진다 | 컨텍스트 정리와 검색 정책 |
권장 구축 순서
1단계: 성공 기준과 평가 세트를 먼저 만든다
대표 업무, 어려운 사례, 금지 사례를 모으고 결과를 어떻게 판정할지 정의한다. 정답 데이터가 없으면 최소한 스키마, 필수 근거, 정책 준수, 인간 평가 기준을 만든다.
2단계: 단일 호출 기준선을 만든다
가장 단순한 프롬프트와 필요한 최소 컨텍스트로 성능, 비용, 지연 시간을 측정한다. 기준선 없이 에이전트를 도입하면 복잡성의 효과를 구분하기 어렵다.
3단계: 컨텍스트 공급을 계측한다
어떤 문서와 도구 결과가 들어갔는지, 얼마나 오래됐는지, 실제 답변에 사용됐는지 기록한다. 검색 실패와 과도한 컨텍스트를 구분한다.
4단계: 최소 하네스를 만든다
도구 수를 줄이고 이름과 입력을 명확히 한다. 샌드박스, 최소 권한, 자동 테스트, 로그, 체크포인트를 우선한다.
5단계: 제한된 자율성을 부여한다
단일 에이전트가 읽기 중심의 저위험 업무부터 수행하게 한다. 종료 조건과 인간 이관 조건을 명시하고, 쓰기·삭제·결제·배포 권한은 별도로 승인한다.
6단계: 검증·복구 루프를 닫는다
실패 분류, 수정 전략, 최대 반복 횟수, 비용 한도, 회귀 테스트를 연결한다. 성공률이 안정된 뒤에만 도구와 자율 범위를 넓힌다.
운영 지표
보편적인 목표 수치는 없으므로 업무 위험과 비용에 맞춰 기준을 정해야 한다.
| 지표 | 의미 |
|---|---|
| 과업 완료율 | 최종 성공 기준을 충족한 비율 |
| 1차 통과율 | 반복 수정 없이 처음부터 통과한 비율 |
| 복구율 | 첫 실패 후 루프를 통해 성공한 비율 |
| 평균 반복 횟수 | 성공 또는 중단까지 필요한 사이클 수 |
| 도구 선택 오류율 | 부적절하거나 불필요한 도구 호출 비율 |
| 근거 완전성 | 핵심 주장에 추적 가능한 출처가 있는 비율 |
| 인간 개입률 | 승인, 수정, 재지시가 필요했던 비율 |
| 단위 성공당 비용·지연 | 성공한 과업 하나를 완료하는 데 든 자원 |
| 안전 사건 수 | 권한 위반, 잘못된 쓰기, 비가역 행동 발생 수 |
| 회귀 실패율 | 새 변경이 기존 성공 사례를 깨뜨린 비율 |
자주 발생하는 설계 실수
| 영역 | 실수 | 개선 방법 |
|---|---|---|
| 프롬프트 | 모든 예외를 한 문장에 누적한다 | 규칙을 구조화하고 대표 예시와 평가를 분리한다 |
| 프롬프트 | 성공 기준 없이 “잘 작성하라”고 지시한다 | 형식, 필수 내용, 금지 사항, 판정 기준을 명시한다 |
| 컨텍스트 | 관련 없는 문서를 모두 넣는다 | 런타임 검색과 단계별 컨텍스트를 사용한다 |
| 컨텍스트 | 오래된 정책과 최신 정책을 함께 제공한다 | 버전·유효일·기준 원본을 관리한다 |
| 하네스 | 기능이 겹치는 도구를 많이 제공한다 | 최소 도구 집합과 명확한 파라미터를 설계한다 |
| 하네스 | 쓰기 권한과 되돌리기 기능이 없다 | 최소 권한, 샌드박스, 체크포인트를 둔다 |
| 에이전틱 | 처음부터 다중 에이전트를 만든다 | 단일 에이전트와 결정적 워크플로부터 검증한다 |
| 에이전틱 | 완료 조건 없이 계속 실행하게 한다 | 명시적 종료·예산·이관 조건을 둔다 |
| 루프 | 같은 요청을 그대로 반복한다 | 실패 원인을 분류하고 수정 지점을 바꾼다 |
| 루프 | 생성 모델 하나로 모든 결과를 자기 평가한다 | 결정적 검사, 참조 대조, 인간 표본 검토를 조합한다 |
구현 체크리스트
- 성공 조건이 문장뿐 아니라 가능한 범위에서 기계적으로 검사 가능한가?
- 프롬프트, 참고 자료, 도구 결과의 우선순위가 분리되어 있는가?
- 문서의 출처, 버전, 유효일과 소유자를 추적할 수 있는가?
- 도구 이름과 파라미터가 서로 겹치지 않고 명확한가?
- 읽기, 쓰기, 삭제, 결제, 배포 권한이 위험도별로 분리되어 있는가?
- 실패를 격리할 샌드박스와 되돌리기 수단이 있는가?
- 모든 중요 행동과 도구 호출을 재현 가능한 형태로 기록하는가?
- 테스트, 스키마, 정책 검사 등 외부 검증기가 있는가?
- 최대 반복 횟수, 비용, 시간, 인간 이관 조건이 정의되어 있는가?
- 새 개선이 기존 사례를 깨뜨리지 않는 회귀 평가가 있는가?
결론
좋은 AI 시스템은 가장 긴 프롬프트를 가진 시스템이 아니다. 실패가 지시, 정보, 환경, 의사결정, 검증·복구 중 어디에서 발생했는지 구분하고, 해당 계층에 가장 단순한 해결책을 배치한 시스템이다. 먼저 성공 기준과 단일 호출 기준선을 만들고, 필요한 만큼만 컨텍스트와 하네스를 보강한 뒤, 검증 가능한 범위에서 자율성과 반복 루프를 확장하는 것이 안정적인 접근이다.
