프롬프트 엔지니어링 / 에이전트 / 하네스 — 무엇이 다른가 (LLM 워크플로우 용어 지도)
프롬프트 엔지니어링 / 에이전트 / 하네스 — 무엇이 다른가 (LLM 워크플로우 용어 지도)
Claude한테 일 시키는 방법은 세 가지로 나뉘는 것 같다.
한 마디 잘 묻는 프롬프트 엔지니어링(Prompt Engineering, 줄여서 PE). 도구를 쥐어준 에이전트(Agent). 그 위에 운영 틀을 얹은 하네스(Harness).
셋 다 “AI 활용”으로 묶이지만 무게가 다르다. 어디에 어떤 도구가 맞는지 헷갈렸던 정리를 여기에 적어둔다.
요약: PE는 한 번의 입력 최적화, 에이전트는 도구를 들고 알아서 도는 AI, 하네스는 그 둘을 어떻게 운영할지 정하는 메타 틀이다. 작은 → 큰 순서로 쌓인다. 5/3 글에서 다룬 하네스의 내부 구조는 이 위계 지도의 마지막 칸에 해당한다.
이 글은 Claude Code를 매일 쓰면서 PE·에이전트·하네스라는 단어가 다 비슷해 보였던 사람을 위해 썼다.
입문자가 아니라 한 번씩 다 써본 사람의 정리에 가깝다.
이런 적 있다면 이 글이 도움이 된다
- ChatGPT에 비슷한 작업을 시킬 때마다 거의 같은 프롬프트를 매번 다시 입력한 적이 있다.
- Claude Code가 한 작업에서 5분 만에 토큰 한도를 다 쓴 걸 본 적이 있다.
- 같은 종류의 실수가 작업마다 또 반복되는 걸 보고 어떻게 멈추지가 답답했던 적이 있다.
세 가지 모두 같은 원인이다. 셋이 같은 단계가 아니다.
한 번의 입력 최적화로 풀 일, 도구를 쥐어줘야 풀 일, 운영 틀로만 풀 일이 다 섞여 있다.
위계를 잡으면 어디에 시간을 쓸지가 분명해진다.
한 줄 정의로 시작한다
| 단계 | 한 줄 정의 | 비유 |
|---|---|---|
| PE (프롬프트 엔지니어링) | 한 번의 질문으로 원하는 답을 받아내는 기법 | 신입에게 일을 한 번 시키는 법 |
| 에이전트 | 도구를 들고 알아서 돌아가는 AI | 권한을 받은 1년 차 |
| 하네스 | 에이전트·프롬프트·문맥을 굴리는 운영 틀 | 회사의 매뉴얼과 평가 체계 자체 |
작은 단위가 큰 단위에 포함된다.
에이전트는 내부에 PE를 쓰고, 하네스는 에이전트를 굴리는 운영 환경이다.
셋이 같은 층위에 있는 게 아니라 위계가 있다는 점이 핵심이다.
1. 프롬프트 엔지니어링 — 가장 작은 단위
ChatGPT가 처음 나왔을 때 개발자·기획자 사이에서 가장 먼저 정리된 게 이쪽이다.
한 번의 입력에서 최대 출력을 뽑아내는 법.
역할 부여(“당신은 시니어 개발자다”), 단계 지시(“우선 분석한 뒤 코드를 작성하라”), 예시 1~3개를 같이 주는 식의 패턴이 정리됐다.
이 단계의 한계는 분명했다.
매번 다시 물어야 한다. 어제 잘 받았던 답을 오늘 다시 받으려면 같은 프롬프트를 또 입력해야 했다.
작업이 반복될수록 손이 많이 갔다. 출력이 길어지면 문맥이 끊기는 일도 잦았다.
지금 PE가 사라진 건 아니다.
다만 작업의 단위가 한 번의 질문이 아니라 더 큰 흐름으로 옮겨졌고, PE는 그 안의 작은 부품으로 들어가게 된 것 같다.
2. 에이전트 — PE를 내부에 품는 단계
다음 단계는 AI에게 손을 주는 것이다.
함수 호출, 웹 검색, 파일 읽기, 셸 실행. 이걸 받은 AI는 한 번의 답이 아니라 자율 루프를 돈다.
“이 데이터 분석해줘”라고 하면, 파일을 직접 열어서 읽고, 코드를 실행해 결과를 보고, 그래프까지 그려내는 식이다.
Claude Code, Cursor, Windsurf 같은 도구가 이 단계에 있다.
작업 한 건당 도구 호출이 10~50회씩 일어나는 게 보통이다. 사용자는 매 호출을 일일이 지시하지 않는다.
큰 목표만 주고 AI가 알아서 도구를 골라 쓴다.
에이전트 내부에는 여전히 PE가 돈다.
도구를 부를 때마다 어떻게 부를지가 프롬프트로 정해진다. 다만 그 프롬프트를 사람이 일일이 짜는 게 아니라 에이전트가 작업 흐름에 맞춰 자동 생성한다.
이 단계의 어려움은 다른 곳에서 온다.
어디까지 자율로 둘 것인가, 언제 멈출 것인가. 잘못된 방향으로 돌면 5분 만에 토큰 한도를 다 쓰고 결과는 엉뚱해진다.
같은 실수를 다음 작업에서 또 반복한다. 이 시점에서 다음 층이 필요해진다.
3. 하네스 — 운영 틀
카파시(Andrej Karpathy, 전 OpenAI 창립 멤버, 전 Tesla AI 책임자)가 17분짜리 영상에서 정리한 표현이 가장 정확한 것 같다.
“모델이 아닌 모든 것이 하네스다.”
PE도 에이전트도 모델 자체를 굴리는 도구다. 하지만 모델 바깥에서 그것을 어떻게 운영할지를 결정하는 층이 따로 있다.
용어 자체는 새것이 아니다.
EleutherAI의 lm-evaluation-harness(2022~)가 LLM 벤치마크 평가용 틀로 이 단어를 먼저 썼다.
카파시는 이 의미를 모델 운영 전반으로 확장했고, 2025년 이후 Anthropic 등이 agent harness로 활용 범위를 넓혔다.
하네스의 내부 구조는 크게 세 부분으로 나뉜다.
컨텍스트 파일(CLAUDE.md 같은 기준 문서), 자동 강제 시스템(훅·게이트·검사), 가비지 컬렉션(쌓이는 임시 파일을 정리하는 절차).
이 셋이 어떻게 작동하는지는 5/3 글에서 따로 다뤘다.
이 글에서 강조하고 싶은 건 위치다.
하네스는 PE의 대체도 에이전트의 대체도 아니다. 그 위에 얹는 운영 층이다.
PE와 에이전트가 부탁이라면, 하네스는 강제다. 카파시의 한 줄을 그대로 가져오면 “프롬프트는 부탁, 하네스는 강제.”
이 정의를 작업 시점에서 풀면 이렇다.
PE는 Claude한테 이번에는 잘 부탁한다고 비는 일이다.
하네스는 다음에도 같은 실수가 안 나오게 강제 절차를 미리 박아두는 일이다.
5/3 글에서 다룬 fail-fast 규칙(에러를 가리지 말고 즉시 멈추기)·git stash 안전 규칙(변경 분실 차단)이 후자의 사례다.
같은 실수가 두 번 보이면 자동 게이트를 한 줄 끼워 넣어 두 번째부터는 강제로 멈추게 만드는 식이다.
카파시의 정의가 원리라면, 실전에서는 어떤 게이트를 어디에 두느냐가 핵심이다.
4. 도구 진화 — PE에서 하네스로
말로만 위계를 적어놓으면 추상적이다. 실제로 겪은 흐름을 그대로 적는다.
| 시기 | 주력 | 마찰점 |
|---|---|---|
| 2024년 | ChatGPT 프롬프트 위주 | 같은 작업을 매번 다시 입력 |
| 2025년 | Claude Code 본격 사용 (에이전트) | 같은 실수를 다음 작업에서 또 반복 |
| 2026 ~ | 하네스 개념 도입 | 운영 규칙이 한 자리에 모이기 시작 |
PE만 쓰던 시기에는 작업을 한 번씩 다 잘 풀려고 했다.
에이전트로 넘어가니 작업을 큰 단위로 묶어서 시킬 수 있었지만, 그 다음 날 같은 실수가 나왔다.
하네스 단계로 넘어가면서 비로소 “이 실수는 어떻게 못 일어나게 할까”를 묻기 시작한 것 같다.
흥미로운 건 이 흐름이 되돌리는 게 아니라 쌓이는 것이라는 점이다.
하네스를 굴리면서도 매일 PE를 쓴다. 에이전트는 그 안에서 돈다.
위계는 더 큰 그릇을 만드는 작업이지, 아래 그릇을 버리는 작업이 아니다.
물론 반대 흐름도 있다.
작업 빈도가 낮아진 사람은 하네스를 거두고 PE 단계로 돌아가기도 한다.
그건 후퇴가 아니라 빈도에 맞춰 도구를 줄이는 적응이다.
위계는 한 방향 진화가 아니라, 그때그때 적정 그릇을 고르는 일에 가까운 것 같다.
5. 어떨 때 어떤 게 필요한가
세 가지 중 무엇이 필요한지는 반복 횟수와 실수 비용으로 가르는 것 같다.
| 상황 | 필요한 도구 |
|---|---|
| 한 번의 답이 필요 (이메일 초안·요약 등) | PE 충분 |
| 같은 작업이 반복되는데 단계가 많다 (코드 리팩토링·자료 조사) | 에이전트 적합 |
| 같은 실수가 반복되는데 비용이 크다 (배포 실수·동일 형식 오류) | 하네스 필요 |
대부분의 사람은 PE에서 시작해도 충분하다.
에이전트는 도구를 다룰 수 있는 환경에서만 의미가 있다.
하네스는 반복 운영자의 영역이다. 작업 빈도가 낮다면 굳이 들일 필요가 없을지도 모른다.
Q&A — 자주 묻는 질문
Q. PE는 결국 사라지지 않나?
A. 사라지지 않는다.
작업의 단위가 한 번의 질문이 아니라 큰 흐름으로 옮겨졌을 뿐, PE는 그 안의 작은 부품으로 들어가 있다.
에이전트가 도구를 부를 때마다 그 호출 자체가 PE다.
Q. Harness에서 PE로 돌아가는 건 후퇴인가?
A. 후퇴가 아니라 적응이다.
작업 빈도가 낮아진 사람은 하네스 유지비가 더 비싸진다. 그때는 거두는 게 맞다.
위계는 한 방향 진화가 아니라 그때그때 적정 그릇을 고르는 일에 가깝다.
Q. 1인 사용자에게도 하네스가 필요한가?
A. 모두에게 필요하진 않다.
같은 실수가 반복되는데 비용이 크다는 신호가 있을 때만 의미가 있다.
일주일에 한 번 ChatGPT를 쓰는 사람은 PE 단계로 충분하다.
마무리 — 위계는 계속 다시 그려질 것 같다
이 세 가지가 앞으로 어떻게 합쳐질지 모르겠다.
PE는 작아지고 에이전트는 자율 폭이 더 커지고 있다. 하네스 개념 자체도 며칠 사이 정의가 바뀌는 영역이다.
정의가 굳어지지 않은 영역이라 표를 그려놓고 나중에 다시 보면 또 칸이 늘어나 있을 것 같다.
그래도 지금 정리해두는 이유는 어디에 시간을 쓸지를 헷갈리지 않기 위해서다.
PE에 더 쏟을지, 에이전트를 더 자주 쓸지, 하네스 자체를 더 다듬을지.
변화가 더 명확해지면 다시 적어볼 것이다.
이 글은 cd4761 하네스 시리즈의 입구다.
5/3 글이 내부 구조를 다룬다면, 이 글은 위치를 잡는다.
다음 글은 3개월 차 회고가 될 것 같다.
관련 글
- 하네스 엔지니어링 — CLAUDE.md만 쓴다고 끝나지 않는다 (3대 구성요소) — 하네스의 내부 구조 (이 글의 §3에서 인용)
- CLAUDE.md 작성법 — Claude Code 기본 설정 — 하네스 컨텍스트 파일의 기본
- 패밀리카로 6개 수집 도구를 돌려봤다 — Google이 막은 자리와 다음 학습 방향 — 에이전트 단계의 1차 측정 사례
8년 차 프론트엔드 · 박사(블록체인) · 회사를 나오게 된 뒤 AI 도구를 매일 1차 자료로 기록 중. cd4761.blogspot.com에서 Claude Code 운영 흐름과 시행착오를 정리한다.
태그: #프롬프트엔지니어링 #에이전트 #하네스 #LLM워크플로우 #ClaudeCode #AI도구 #카파시 #1인운영자
댓글
댓글 쓰기