"그거 ChatGPT한테 시키면 되잖아요." 맞는 말입니다. 그런데 매주 같은 일을 매주 처음부터 설명하고 있다면, 그리고 결과물 검사를 매번 사람 눈으로 하고 있다면, 시키는 방법이 잘못된 겁니다. 이 글은 프롬프트가 아니라 일을 맡기는 구조, 요즘 말로 하네스(harness)를 다룹니다. 개발자 용어처럼 들리지만, 매주 리포트를 만들고 광고 소재를 검수하는 마케팅팀이야말로 이 개념의 수혜자입니다.
하네스라는 단어가 낯설다면
하네스는 원래 마구(馬具)를 뜻합니다. 말과 마차를 연결하는 가죽끈과 고리들. 말이 아무리 힘이 세도 하네스 없이는 마차를 끌지 못합니다. 힘은 말에게 있지만, 그 힘이 일이 되게 만드는 건 연결 장치라는 거죠.
AI 에이전트도 똑같습니다. 모델은 이미 충분히 똑똑합니다. 그런데 같은 모델을 쓰는데도 어떤 팀은 실제 업무를 통째로 맡기고, 어떤 팀은 "신기하긴 한데 실무엔 못 쓰겠다"에 머뭅니다. 차이는 모델이 아니라 연결 구조에서 납니다.
구체적으로 하네스는 이런 것들의 묶음입니다.
- 에이전트가 일을 시작하기 전에 읽는 지시서 (어떤 톤으로, 어떤 순서로, 뭘 하지 말 것)
- 일하는 동안 쓰는 도구 (스크립트, API, 사내 데이터 접근)
- 끝났다고 말하기 전에 통과해야 하는 검증 (린터, 체크리스트, 숫자 대조)
- 다음 작업에도 이어지는 기억 (지난번 피드백, 팀의 규칙)
이 네 가지가 파일로 존재하고, 에이전트가 그걸 읽고 따르도록 강제되어 있으면 하네스가 있는 겁니다. 없으면 매번 운에 맡기는 거고요.
프롬프트 엔지니어링과 뭐가 다른가
"프롬프트 잘 쓰는 법"은 한동안 그 자체로 기술 취급을 받았습니다. 여전히 유효하지만, 프롬프트는 본질적으로 1회성입니다. 잘 쓴 프롬프트도 채팅창을 닫으면 사라집니다. 다음 주에 같은 일을 시키려면 기억을 더듬어 다시 써야 하고, 동료는 당신의 프롬프트 노하우를 모릅니다.
| 구분 | 프롬프트 | 하네스 |
|---|---|---|
| 수명 | 대화 한 번 | 파일로 영구 보존 |
| 운전자 | 사람이 매번 개입 | 구조가 순서를 강제 |
| 품질 편차 | 그날의 프롬프트 실력 | 시스템에 저장된 기준 |
| 검증 | 사람 눈으로 | 자동 검사 + 사람은 마지막만 |
| 조직 자산화 | 개인 노하우 | 팀 전체가 공유 |
마케팅 조직에 비유하면 이렇습니다. 신입이 들어올 때마다 미디어 믹스 짜는 법을 구두로 설명하는 팀과, 온보딩 위키에 기준·예외·체크리스트가 정리된 팀. 둘 다 일은 돌아가지만 품질의 하한선이 다릅니다. 하네스 엔지니어링은 조직의 암묵지를 에이전트가 읽을 수 있는 파일로 옮기는 작업입니다.
📌 용어 정리
이 글에서 에이전트는 Claude Code, Codex CLI처럼 도구를 실행하며 여러 단계 작업을 스스로 진행하는 AI를 말합니다. 챗봇과의 차이는 "말만 하느냐, 일을 하느냐"입니다. 하네스는 그 에이전트를 감싸는 지시서·도구·검증·기억의 총체고요.
부품 1·2: 지시서와 도구
네 부품을 둘로 묶어 보겠습니다. 앞의 둘은 "일을 시키는" 쪽입니다.
지시서: 워크플로우를 파일로
지시서는 단순한 시스템 프롬프트가 아니라 업무 절차서에 가깝습니다. 좋은 지시서에는 순서가 있고, 각 단계의 완료 조건이 있고, 하지 말아야 할 것이 명시돼 있습니다. "보고서를 잘 써줘"가 아니라 "1단계에서 데이터를 불러오고, 2단계에서 전주 대비 변화를 표로 만들고, 수치를 추정하지 말고 모르면 모른다고 표시하라"는 식입니다.
Claude Code 생태계에서는 이런 지시서를 스킬(skill)이나 슬래시 커맨드 형태로 저장합니다. 형식은 별게 아닙니다. 마크다운 파일 하나입니다.
---
name: weekly-report
description: 주간 캠페인 리포트 작성 절차
---
1. 데이터 소스에서 지난 7일 지표를 불러온다
2. 전주 대비 ±20% 넘는 변화만 코멘트한다
3. 모든 수치는 원본 쿼리 결과와 대조한다
4. 추정·보간 금지. 빈 데이터는 "수집 누락"으로 표기
핵심은 마지막 두 줄 같은 금지 조항입니다. 에이전트는 시키지 않은 친절(그럴듯한 수치 채워 넣기)을 베풀다 사고를 냅니다. 뭘 할지만큼 뭘 하지 말지를 적어야 합니다.
도구, 손발이 없으면 머리도 소용없다
도구는 에이전트가 실제로 만지는 스크립트와 API입니다. 데이터를 읽는 쿼리, 이미지를 만드는 스크립트, 결과물을 배포하는 명령. 도구가 없으면 에이전트는 "이렇게 하시면 됩니다"라고 말만 하는 컨설턴트가 됩니다. 도구가 연결되는 순간 실무자가 되고요.
부품 3·4: 검증과 기억
뒤의 둘은 "일을 믿을 수 있게 만드는" 쪽입니다. 그리고 제 생각엔 여기가 하네스의 절반 이상입니다.
검증, 생성은 쉽고 믿는 게 어렵다
에이전트 결과물의 문제는 틀렸을 때조차 그럴듯하다는 점입니다. 그래서 사람 눈 대신 기계적으로 도는 검사가 필요합니다. 형식 검사, 금지 패턴 검사, 숫자 대조. 검사가 실패하면 에이전트가 스스로 고치고 다시 검사받는 루프까지 묶어야 완성입니다.
검증이 없는 자동화는 그냥 빠른 오답 생산기입니다. 속도가 빨라진 만큼 틀린 보고서도 빨리 나갑니다.
기억, 같은 피드백을 두 번 하지 않기
지난주에 "우리 팀은 ROAS 말고 iROAS로 불러"라고 고쳐줬는데 이번 주에 또 ROAS라고 쓰면 화가 나죠. 피드백을 메모리 파일에 적게 하고, 작업 시작 전에 읽게 만들면 같은 지적이 반복되지 않습니다. 기억은 하네스에서 가장 저평가된 부품입니다.
사례 분해: 이 블로그의 글쓰기 하네스
추상적인 얘기는 여기까지 하고, 실물을 뜯어보겠습니다. 이 블로그의 글은 /write라는 커맨드 하나로 시작합니다. 그 안에 이런 단계가 박혀 있습니다.
이 블로그의 글쓰기 하네스. 사람은 주제 선택과 경험 채우기, 마지막 검수에만 개입한다.
- 아이디어 풀(파일 50여 개)에서 주제를 골라 제안. 최근 발행한 카테고리는 피하도록 회전 규칙이 명시돼 있습니다.
- 초안 작성. 단, 글쓴이만 아는 실제 수치·사례 자리는 비워두고 TODO 주석으로 표시하라는 금지 조항이 있습니다. 에이전트가 그럴듯한 가짜 경험을 지어내는 걸 막는 장치입니다.
- 콘텐츠 린터 실행. 이 블로그의 MDX 렌더러가 깨지는 패턴(마크다운 굵게 표시와 한국어가 붙으면 따옴표가 깨집니다)을 과거에 여러 번 겪고, 그때마다 검사 룰로 박아뒀습니다.
- 탈AI 검수. 바로 오늘 추가한 단계인데, 아래에서 따로 설명하겠습니다.
- 대표 이미지 생성, OG 카드 삽입, 발행 스크립트 실행.
이 구조에서 사람이 하는 일은 셋으로 줄었습니다. 주제 고르기, 비워둔 자리에 실제 경험 채우기, 마지막 어투 다듬기. 나머지는 구조가 굴러갑니다.
{/* TODO_HUNY: /write 도입 전후로 글 한 편에 들던 시간이 체감으로 얼마나 달라졌는지 한두 문장. (예: 주말 반나절 → 저녁 한 시간 등 실제 체감치) */}
하네스는 자란다: 오늘 추가한 탈AI 검수
하네스의 진짜 재미는 한 번 만들고 끝이 아니라 사고가 날 때마다 진화한다는 데 있습니다. 오늘 아침에 추가한 규칙이 좋은 예라서 그대로 공개합니다.
발단은 단순했습니다. AI가 쓴 초안에서 자꾸 특유의 냄새가 났습니다. "~에 대해 알아보겠다"는 식으로 시작하는 도입부, 문장마다 붙는 "할 수 있습니다", 세 개씩 맞춰 나열하는 습관. 그래서 두 가지를 하네스에 박았습니다.
하나는 humanizer라는 오픈소스 스킬입니다. Wikipedia의 "Signs of AI writing" 문서를 기반으로 AI 글쓰기 패턴 33가지를 찾아 고치는 지시서인데, 부풀린 의미 부여, 홍보체, 빈 강조어, em-dash 남용 같은 패턴이 영어 기준으로 정리돼 있습니다. 여기에 한국어 블로그용 체크리스트 14개를 따로 만들어 붙였습니다. 어미 단조로움, 번역투, 단락 끝 요약 후렴 같은 한국어 고유의 티는 영어 가이드가 못 잡으니까요.
다른 하나는 그중 기계적으로 잡히는 것만 골라 린터에 경고 룰로 추가한 겁니다. 상투 표현 등장, "할 수 있습니다" 8회 초과, em-dash 5회 초과. 이렇게요.
재밌는 건 새 룰을 기존 발행글 전체에 돌려본 결과였습니다. em-dash 경고가 수십 개 글에서 쏟아졌습니다. 한 글에서 57곳이 잡힌 경우도 있었고요. 그동안 발행한 글들이 그만큼 AI 티를 내고 있었다는 뜻입니다. 사람 눈으로는 못 세던 걸 룰은 셉니다.
💡 하네스 진화의 원칙
같은 실수를 두 번 겪으면 그건 사람 잘못이 아니라 구조의 빈틈입니다. 피드백을 그때그때 지시서나 검사 룰로 옮겨 적으세요. "다음엔 조심해야지"는 하네스가 아닙니다.
마케팅팀에서 시작할 만한 하네스
코드를 모르는 팀도 시작점은 많습니다. 기준은 단순합니다. 매주 반복되는가, 규칙을 말로 설명할 수 있는가, 결과가 맞는지 기계적으로 확인 가능한가. 세 조건이 겹치는 업무가 1순위입니다.
| 업무 | 지시서에 들어갈 것 | 검증 룰 예시 |
|---|---|---|
| 주간 캠페인 리포트 | 지표 정의, 코멘트 기준, 추정 금지 | 수치가 원본 쿼리와 일치하는지 대조 |
| UTM·네이밍 QA | 팀 네이밍 컨벤션 | 규칙 벗어난 캠페인명 자동 플래그 |
| 광고 소재 카피 검수 | 금칙어, 브랜드 톤, 법적 표현 | 금칙어 사전 매칭 |
| 경쟁사 소재 모니터링 | 수집 범위, 요약 포맷 | 출처 링크 필수, 링크 없는 주장 차단 |
{/* TODO_HUNY: 팀에서 실제로 자동화했거나 시도해본 업무가 있다면 여기에 한 사례. 성공이든 실패든 실제 얘기가 표보다 힘이 셉니다. */}
반대로 하네스에 안 어울리는 일도 있습니다. 분기 전략 수립처럼 매번 맥락이 다르고 정답 검증이 안 되는 업무는 에이전트가 보조는 해도 구조화 효율이 낮습니다. 거기는 그냥 대화로 쓰는 게 낫습니다.
멀티 에이전트, 화려하지만 서두를 것 없다
에이전트 여러 개를 병렬로 돌리는 데모가 요즘 많이 보입니다. 리서치 에이전트 다섯이 동시에 조사하고 코디네이터가 취합하는 식이죠. 멋있긴 한데, 입문 단계에서는 권하지 않습니다.
이유는 두 가지입니다. 비용이 곱으로 늘고(병렬 세션은 사용량을 그대로 곱해 먹습니다), 디버깅이 어려워집니다. 단일 에이전트의 결과가 틀리면 지시서를 고치면 되는데, 다섯 에이전트의 합의가 틀리면 어디서부터 봐야 할지 막막해집니다.
병렬이 값어치를 하는 조건은 명확합니다. 서브태스크가 서로 진짜 독립적일 것, 각각이 충분히 큰 작업일 것, 그리고 결과를 합치는 기준이 미리 정의돼 있을 것. 이 조건이 안 맞으면 잘 짠 체크리스트 하나가 멀티 에이전트보다 성과가 좋습니다. 화려함과 효과는 별개입니다.
자주 빠지는 함정
처음부터 전부 자동화하려는 것. 가장 흔한 실패입니다. 업무 하나, 그것도 검증이 쉬운 업무 하나로 시작해서 한 달쯤 굴려보고 넓히세요.
검증 없이 믿는 것. 데모에서 잘 되는 것과 매주 안정적으로 도는 것 사이에는 큰 강이 있습니다. 그 강을 건너는 다리가 자동 검증입니다.
지시서 비대화. 규칙을 계속 추가하다 보면 서로 모순되는 조항이 생기고, 에이전트가 뭘 우선할지 헷갈리기 시작합니다. 분기마다 한 번씩 죽은 규칙을 정리하는 것도 하네스 관리의 일부입니다.
환각 수치를 그대로 내보내는 것. 숫자가 들어가는 업무라면 "원본과 대조" 검증을 반드시 넣으세요. 에이전트는 빈칸을 그럴듯한 숫자로 채우고 싶어 하는 본능이 있습니다.
마치며
프롬프트 엔지니어링이 "말을 잘 거는 기술"이었다면, 하네스 엔지니어링은 "일을 맡길 구조를 짜는 기술"입니다. 그리고 후자는 코딩 실력보다 업무를 단계와 규칙으로 분해하는 능력에 더 가깝습니다. 매주 반복 업무의 절차와 예외를 가장 잘 아는 사람, 그러니까 실무자가 제일 잘할 수 있는 일이라는 뜻입니다.
시작은 작게. 반복 업무 하나를 골라 절차를 파일로 적고, 결과를 검사할 룰 하나를 붙이는 것. 거기서부터 하네스는 사고가 날 때마다 한 줄씩 자랍니다.
Top comments (0)