AI 에이전트 하네스, 내 직군에선 어떻게 쓸까? — 비개발자·개발자·데이터 직군별 실전 프롬프트 9선

AI 에이전트 하네스의 7가지 구성요소, 이론은 이해했는데 내 업무에 어떻게 적용할까요? 비개발자·개발자·데이터 직군별로 지금 바로 복붙 가능한 실전 프롬프트 3개씩, 총 9개를 정리했습니다.


AI 에이전트 하네스가 내 업무와 무슨 상관이냐고요?

지난 글에서 AI 에이전트 하네스의 7가지 핵심 구조를 정리했을 때 가장 많이 받은 반응이 “개념은 알겠는데, 나는 개발자도 아닌데 어떻게 써요?”였습니다. 솔직히 말하면, 하네스 아키텍처 자체를 직접 구현하는 건 엔지니어 영역이 맞습니다. 하지만 하네스를 잘 타는 라이더(best rider)가 되는 건 모든 직군의 이야기입니다.

ChatGPT나 Claude에게 “요약해줘” 한 줄 날리는 것과, Context·Memory·Orchestration 원리를 이해하고 설계된 프롬프트를 쓰는 것은 결과물이 완전히 다릅니다. 오늘은 비개발자, 개발자, 데이터 직군 각각 3개씩 — 지금 당장 복붙해서 쓸 수 있는 프롬프트를 드립니다.


📌 목차

  1. 비개발자 직군 (기획·마케팅·PM): 하네스 원리 적용 프롬프트 3선
  2. 개발자 직군: 하네스 원리 적용 프롬프트 3선
  3. 데이터 직군 (분석·사이언티스트): 하네스 원리 적용 프롬프트 3선
  4. 직군 공통: 프롬프트를 더 잘 쓰는 3가지 하네스 원칙

1. 비개발자 직군 (기획·마케팅·PM): 하네스 원리 적용 프롬프트 3선

비개발자에게 가장 관련 있는 하네스 요소는 Context & MemoryOrchestration입니다. AI에게 맥락을 명확히 주고, 작업을 단계별로 분해해 지시하는 것이 핵심입니다.

프롬프트 ① — Context & Memory 원리: 반복 설명 없이 AI를 내 전담 기획 파트너로 만들기

하네스의 Context DB는 “AI가 알아야 할 레시피북”이라고 했죠. 이걸 프롬프트로 구현하면 이렇습니다.

## 나의 컨텍스트 (매 대화 시작 시 붙여넣기)

나는 [회사명]의 프로덕트 마케터입니다.
- 주요 제품: [제품명] — B2B SaaS, 주 고객은 중소기업 HR 담당자
- 현재 분기 목표: 무료 체험 전환율 15% → 20% 달성
- 우리 팀 톤앤매너: 전문적이되 딱딱하지 않게, 수치 근거 중시
- 절대 쓰지 않는 표현: "혁신적인", "게임체인저", "패러다임"

이 컨텍스트를 기억하고, 오늘 요청할 [랜딩 페이지 카피 초안 작성]을 도와주세요.
제품 USP 3가지: (1) 설치 없이 브라우저만으로 사용 (2) 온보딩 7분 이내 완료 (3) HR 규정 자동 업데이트

왜 이게 하네스 원리인가: 매번 “우리 제품은요…”를 반복하는 대신, 컨텍스트 블록을 한 번 정의해두면 AI가 일관된 맥락으로 작업합니다. 팀 내 공유 문서에 이 블록을 만들어두면 누가 쓰든 동일한 품질이 나옵니다.

프롬프트 ② — Orchestration 원리: 큰 프로젝트를 AI와 함께 단계별로 쪼개기

하네스의 Orchestration은 “계획 → 행동 → 관찰 → 반복”입니다. 이 루프를 프롬프트로 구현하면 훨씬 정교한 결과물을 얻습니다.

다음 프로젝트를 단계별로 같이 진행합시다. 각 단계가 끝나면 내 피드백을 받고 다음으로 넘어가세요.

[프로젝트] Q3 신규 기능 출시 블로그 포스트 작성

단계 1: 이 기능의 핵심 독자(페르소나)와 그들의 핵심 고민 3가지를 먼저 제안해주세요.
단계 2: 내 피드백 반영 후, 포스트 제목 후보 5개를 만들어주세요. (SEO 고려, 숫자 포함 우선)
단계 3: 확정 제목 기반으로 개요(H2 섹션 4개)를 잡아주세요.
단계 4: 섹션별로 초안을 써주세요. 한 번에 전부 쓰지 말고 섹션 1개씩 검토받으며 진행합시다.

지금은 단계 1만 시작하세요.

왜 이게 하네스 원리인가: AI에게 전체를 한꺼번에 던지면 중간 검토 없이 엉뚱한 방향으로 가버립니다. 단계를 명시적으로 쪼개고 human-in-the-loop를 설계하면, Orchestration의 “클로즈드 루프 패턴”이 실현됩니다.

프롬프트 ③ — Observability 원리: AI 결과물을 스스로 검증하게 만들기

하네스의 Observability는 “볼 수 없는 건 신뢰할 수 없다”입니다. AI 결과물에 대해서도 같은 원칙을 적용하세요.

아래 이메일 뉴스레터 초안을 작성해주세요.

[조건]
- 수신자: 무료 체험 7일차 사용자
- 목표: 유료 전환 유도
- 분량: 300자 이내

초안 작성 후, 반드시 다음 체크리스트를 스스로 평가해주세요:
□ CTA(행동 유도 문구)가 1개만 있는가?
□ "지금 바로"처럼 긴박감을 주는 표현이 포함됐는가?
□ 우리 톤앤매너(전문적이되 딱딱하지 않게)를 지켰는가?
□ 300자를 초과하지 않는가?

체크리스트 결과와 함께 최종본을 제시해주세요.

왜 이게 하네스 원리인가: 가드레일(Guardrails)을 프롬프트 안에 내재화한 방식입니다. AI가 스스로 evals를 돌리게 만들면, 검토 없이 퇴고 없는 초안을 그대로 쓰는 실수를 방지합니다.


2. 개발자 직군: 하네스 원리 적용 프롬프트 3선

개발자에게 핵심 하네스 요소는 Tools & Action, State & Persistence, Sandbox & Compute입니다. AI를 단순 코드 생성기가 아니라, 내 코드베이스의 맥락을 아는 페어 프로그래머로 만드는 것이 목표입니다.

프롬프트 ① — Tools & Action 원리: AI가 실제로 실행 가능한 Tool을 설계하게 만들기

우리 서비스의 AI 에이전트에 추가할 Tool을 설계해줘.

[상황]
- 에이전트가 "사용자 주문 현황 조회" 기능을 수행해야 함
- 백엔드: FastAPI, DB: PostgreSQL
- MCP 기반 도구 연결 예정

다음 형식으로 Tool 스펙을 정의해줘:
1. Tool 이름과 설명 (LLM이 언제 이 Tool을 쓸지 판단할 수 있게 명확하게)
2. Input 파라미터 스키마 (JSON Schema)
3. Output 형식
4. 실패 시 에러 처리 방식 (에이전트 루프가 재시도할 수 있도록)
5. FastAPI 엔드포인트 구현 예시 코드

민감한 DB 자격증명은 Tool 외부(환경변수)에 보관하는 패턴으로 작성해줘.

왜 이게 하네스 원리인가: 하네스의 Tools 레이어에서 “모델이 전달한 인자 검증 → 호출 디스패치 → 결과 파싱”까지 설계하는 것, 그리고 자격증명을 에이전트 외부에 두는 Sandbox 원칙을 함께 구현합니다.

프롬프트 ② — State & Persistence 원리: 멀티스텝 작업의 체크포인트 설계

10단계짜리 데이터 파이프라인 에이전트를 만들고 있어.
문제: 7단계에서 크래시 나면 처음부터 재실행해야 해서 시간·비용 낭비가 심해.

[현재 스택] Python, Redis, Celery

다음을 설계해줘:
1. 각 단계 완료 시 Redis에 체크포인트 저장하는 패턴 (step_id, status, output_summary)
2. 재시작 시 마지막 성공 체크포인트부터 재개하는 로직
3. 체크포인트 만료(TTL) 전략 — 언제 초기화할지
4. 단계별 idempotency 보장 방법

실제 코드 예시와 함께 설명해줘.

왜 이게 하네스 원리인가: 하네스의 State & Persistence가 말하는 “10단계 작업의 7단계 크래시 시 8단계부터 재개”를 실제 코드로 구현하는 프롬프트입니다.

프롬프트 ③ — Cost & Optimization 원리: 작업별 모델 라우팅 설계

우리 에이전트 시스템의 LLM 비용을 최적화하고 싶어.
현재 모든 작업에 claude-opus-4-7을 쓰고 있는데 너무 비싸.

[에이전트가 수행하는 작업 목록]
- 사용자 의도 분류 (5가지 카테고리)
- 복잡한 계약서 조항 해석 및 리스크 분석
- SQL 쿼리 자동 생성 (스키마 주어짐)
- 이메일 초안 작성 (템플릿 기반)
- 코드 버그 원인 추론 (스택트레이스 분석)

각 작업에 대해:
1. 추천 모델 (claude-opus-4-7 / claude-sonnet-4-6 / claude-haiku-4-5)
2. 추천 이유 (추론 깊이, 속도, 비용 트레이드오프)
3. 라우팅 기준 코드 스니펫 (if-else 또는 룰 기반)

을 정리해줘. 월 토큰 예산 기준 예상 절감율도 계산해줘.

왜 이게 하네스 원리인가: 하네스 7번째 요소인 Cost & Workflow Optimization의 핵심 — “결정론적 vs 비결정론적 처리 구분, 단계별 적합 모델 선택”을 실무에 바로 적용하는 프롬프트입니다.


3. 데이터 직군 (분석·사이언티스트): 하네스 원리 적용 프롬프트 3선

데이터 직군에게 핵심 하네스 요소는 Context DB(도메인 지식 내재화), Observability(분석 결과 검증), Orchestration(반복 분석 자동화)입니다.

프롬프트 ① — Context DB 원리: 도메인 지식을 AI에 내재화해 분석 품질 높이기

## 분석 컨텍스트 (이 블록을 매번 첨부)

[비즈니스 도메인] 이커머스 — 패션 버티컬
[핵심 지표 정의]
- GMV: 결제 완료 기준 (취소·환불 제외)
- 재구매율: 첫 구매 후 90일 내 2회 이상 구매한 사용자 비율
- LTV: 코호트 기준 12개월 누적 GMV
[데이터 특이사항]
- 매주 화요일 정기 배치로 데이터 갱신 → 월요일 데이터는 불완전할 수 있음
- 시즌 이벤트(설날·추석·블랙프라이데이) 기간은 YoY 비교 시 반드시 별도 처리
- outlier 기준: 1회 구매액 50만원 초과는 B2B 주문으로 필터링

위 컨텍스트를 반영해서 다음 분석을 도와주세요:
[요청] 이번 달 신규 유입 채널별 재구매율 비교 쿼리 작성 (BigQuery SQL)

왜 이게 하네스 원리인가: 하네스의 Context DB는 “사람들이 머릿속에 들고 출근하는 SOP”라고 했습니다. 데이터 정의·특이사항·outlier 처리 기준을 AI에게 명시적으로 주입하면, 도메인을 모르는 AI가 엉뚱한 쿼리를 작성하는 실수를 방지합니다.

프롬프트 ② — Observability 원리: AI가 생성한 쿼리/분석을 자동 검증하게 만들기

아래 BigQuery SQL 쿼리를 검토하고 개선해줘.

[쿼리]
SELECT
  channel,
  COUNT(DISTINCT user_id) AS users,
  SUM(gmv) AS total_gmv
FROM orders
WHERE created_at >= '2026-05-01'
GROUP BY channel

검토 항목:
1. 비즈니스 로직 오류: 취소·환불 제외 처리가 됐는가? 월요일 불완전 데이터 필터는?
2. 성능 이슈: 파티션 프루닝이 제대로 되고 있는가?
3. 엣지 케이스: NULL channel 처리, B2B outlier 필터 누락은 없는가?
4. 가독성: 나중에 팀원이 보기 어려운 부분이 있는가?

각 항목별로 문제점과 수정 쿼리를 함께 제시해줘.

왜 이게 하네스 원리인가: 하네스의 Evals(회귀 테스트)를 쿼리 레벨에서 구현한 것입니다. “고객보다 먼저 회귀를 포착”하는 것처럼, 실제 실행 전에 AI가 AI 결과물을 검증하는 이중 체크 구조입니다.

프롬프트 ③ — Orchestration 원리: 반복 리포트 생성을 에이전트 루프로 자동화

매주 월요일 아침에 자동으로 실행되는 주간 리포트 에이전트를 설계해줘.

[리포트 구성]
1. 전주 GMV (WoW, YoY 비교)
2. 신규 가입자 수 및 첫 구매 전환율
3. 채널별 ROAS 상위 3개 / 하위 3개
4. 이상치 감지: 전주 대비 10% 이상 급등·급락 지표 자동 하이라이트

[기술 스택] Python, BigQuery, Slack Webhook

다음을 설계해줘:
1. 전체 플로우 (데이터 수집 → 계산 → 이상치 감지 → 슬랙 발송)
2. 각 단계를 함수로 분리한 코드 스켈레톤
3. 월요일 데이터 불완전 이슈 처리 방법 (전주 집계는 화요일 배치 후가 정확)
4. 특정 단계 실패 시 에러 알림만 보내고 나머지 단계는 계속 진행하는 패턴

왜 이게 하네스 원리인가: Orchestration의 “사용할수록 개선되는 클로즈드 루프”를 데이터 파이프라인에 적용합니다. 4번 요구사항(실패 격리)은 State & Persistence의 회복 탄력성 원칙이기도 합니다.


4. 직군 공통: 프롬프트를 더 잘 쓰는 3가지 하네스 원칙

위 9개 프롬프트를 관통하는 공통 원칙 3가지를 정리하면 이렇습니다.

① 컨텍스트는 선불로 내라 (Context First)

AI에게 결과물을 요청하기 전에 배경·제약·정의를 먼저 줘야 합니다. 하네스의 Context DB처럼, “레시피북 없이 요리사를 부엌에 밀어 넣는” 실수를 피하세요. 팀 공유 문서에 Context 블록 템플릿을 만들어두면 누가 써도 일관된 품질이 나옵니다.

② 한 번에 다 시키지 마라 (Decompose Tasks)

Orchestration 원리처럼 큰 작업은 반드시 단계로 쪼개고, 중간 결과를 검토한 뒤 다음 단계로 넘어가세요. “블로그 글 써줘” 대신 “독자 페르소나 먼저 정의해줘 → 제목 후보 5개 → 개요 → 섹션별 초안” 순으로 진행하면 최종 결과물 품질이 크게 높아집니다.

③ AI가 스스로 검증하게 만들어라 (Built-in Evals)

Observability 원칙처럼, 프롬프트 안에 체크리스트나 검토 기준을 내재화하세요. “초안 작성 후 다음 항목을 스스로 평가해주세요”라는 구조는 한 번의 프롬프트로 초안 생성과 검토를 동시에 처리합니다. 실수를 사람이 잡기 전에 AI가 먼저 잡는 구조입니다.


✍️ 글을 마치며

AI 에이전트 하네스는 엔지니어만의 이야기가 아닙니다. Context를 명확히 주고, 작업을 단계로 쪼개고, 결과물에 검증 기준을 심는 것 — 이 세 가지만 제대로 해도 여러분은 이미 하네스를 잘 타는 라이더입니다. 모든 기업이 같은 모델에 접근 가능한 시대에, 프롬프트 설계 역량이 곧 경쟁력입니다.

오늘 소개한 9개 프롬프트 중 하나만 골라서 내일 실제 업무에 써보세요. 결과가 달라지는 걸 직접 체감하시면 됩니다. 어떤 직군의 프롬프트가 제일 유용하셨나요? 댓글로 알려주세요!

Leave a Comment