AI 프로덕트 매니지먼트 특별 연재 ➁

PM도 AI 하네스를 설계해야 한다.

김영욱

Product Expert, SAP

왕위 및 영토 계승권, 종교, 경제적 이권 다툼 등으로 복잡했던 중세 유럽의 전쟁 승자를 바꾼 건 더 강한 말이 아니었습니다. 발밑에 걸치는 작은 쇠붙이 하나, 등자(鐙子, stirrup)였습니다. 

8세기 경 등자가 중국으로부터 유럽에 퍼지면서 기병은 완전히 다른 수준의 전투력을 갖게 됩니다. 등자가 없던 시절, 기수는 창을 힘껏 내지르면 그 반동으로 말에서 떨어졌습니다. 그런데 발을 단단히 디딜 등자가 생기자, 기수는 말과 창과 자기 몸을 하나로 묶어 돌진할 수 있게 됐죠. 말의 질주 에너지가 창끝 하나에 실리기 시작한 겁니다. 판을 바꾼 건 말이 아니라, 말 위에 얹은 작은 장치였다는 것입니다.

AI도 정확히 같은 지점에 와 있습니다. 우리는 지난 몇 년간 "어떤 모델이 더 빠르고 정확한가"에 열광했습니다. GPT-5냐, 클로드냐, 제미나이냐. 그런데 현장에서 제품의 성패를 가르는 건, 점점 모델 그 자체가 아니라 모델 위에 무엇을 얹느냐로 옮겨가고 있습니다. 부가적으로 '얹는 장치'에 2026년 업계가 붙인 이름이 바로 하네스입니다.

그리고 하네스라는 영어 단어의 본래 뜻이, 공교롭게도 말에 채우는 마구(馬具)입니다. 안장, 가슴끈, 그리고 마부의 손에 쥐어진 고삐. 말은 강하지만, 마구가 없으면 그 힘은 방향을 갖지 못합니다. 세상에서 가장 빠른 말도 고삐가 없으면 어디로 갈지 알 수 없죠. LLM이 바로 그 기운 넘치는  말입니다.

프롬프트의 시대는 끝나가고 있습니다

"프롬프트를 잘 쓰면 됩니다." 얼마 전까지 이 말은 거의 진리였습니다. 하지만 지금은 반쪽짜리 이야기가 됐습니다. AI를 다루는 기술은 지난 3년간 이렇게 진화했습니다.

2023~2024년은 프롬프트 엔지니어링의 시대였습니다. 한 번의 입력에 어떤 단어를, 어떤 순서로 넣느냐가 핵심이었죠. 2025년 중반엔 컨텍스트 엔지니어링이 떠올랐습니다. 단발 프롬프트가 아니라, 모델이 보는 정보 전체 즉 대화 이력, 메모리, 외부 데이터를 어떻게 설계하느냐가 화두가 됐습니다. 그리고 2026년, 에이전트가 혼자 일하기 시작하면서 또 한 번 판이 바뀝니다. 이제는 한 번의 입력도, 한 번의 컨텍스트도 아닌 환경 전체를 설계해야 합니다. 그 환경의 이름이 하네스 엔지니어링입니다.

이 용어를 처음 퍼뜨린 사람은 하시코프 공동창업자이자 테라폼을 만든 미첼 하시모토입니다. 2026년 2월, 그가 블로그에 쓴 한 문장이 업계 공용어가 됐죠.

“에이전트가 실수를 할 때마다, 같은 실수를 다시는 할 수 없도록 환경 자체를 손본다.”

프롬프트를 다시 쓰는 게 아닙니다. 그 실수가 구조적으로 불가능해지도록 도구와 규칙을 추가하는 겁니다. 이 관점의 전환이 하네스의 핵심입니다.

에이전트 = 모델 + 하네스 

업계의 정의는 의외로 단순합니다. 에이전트는 모델이 아닙니다. 모델 위에 얹힌 모든 것, 즉 도구 정의, 컨텍스트 파일, 가드레일, 피드백 루프, 관찰 장치가 합쳐졌을 때 비로소 에이전트가 됩니다. 모델을 뺀 나머지 전부를 묶어 부르는 이름이 하네스입니다.

이게 말장난이 아니라는 걸 가장 세게 증명한 사례가 있습니다. 2025년 8월 말, 오픈AI 엔지니어 세 명이 텅 빈 저장소에서 규칙 하나를 걸고 실험을 시작했습니다. "사람은 코드를 단 한 줄도 쓰지 않는다." 모든 코드는 코덱스라는 에이전트가 씁니다. 다섯 달 뒤, 그 저장소는 백만 줄이 넘는 프로덕션 시스템이 됐습니다.

여기서 진짜 배울 점은 "AI가 코드를 잘 짜더라"가 아닙니다. 보고서를 읽어보면 처음 몇 주는 진척이 지독하게 느렸다는 고백이 나옵니다. 모델이 부족해서였을까요? 처음부터 끝까지 모델은 같았습니다. 환경이 미비했기 때문이었습니다. 에이전트가 뭔가에 실패할 때마다 이 팀은 "프롬프트를 더 잘 써보자"라고 하지 않았습니다. 대신 딱 한 가지만 물었습니다. “어떤 능력이 빠져 있는가, 그리고 그걸 에이전트가 읽고 검증할 수 있는 형태로 어떻게 만들 것인가?”

엔지니어의 일이 '코드를 쓰는 것'에서 '환경을 설계하는 것'으로 옮겨간 겁니다. 이 팀이 다섯 달간 한 일은 사실 코드를 쓴 게 아니라 하네스를 만든 것이었습니다. 코드는 그 하네스 위에서 에이전트가 자라난 결과물이고요. 그래서 이런 말이 업계에 돕니다. "하네스가 제품을 만든다. 모델이 만드는 게 아니다."

하네스를 이해하는 가장 쉬운 방법, 컴퓨터

하네스가 아직 손에 잡히지 않는다면, 우리가 매일 쓰는 컴퓨터를 떠올려보면 단번에 정리됩니다.

컴퓨터에서 실제로 계산을 하는 건 CPU입니다. 하지만 CPU 혼자서는 아무것도 하지 못합니다. 전원이 켜진 CPU는 그저 명령을 처리할 준비가 된 연산 장치일 뿐이죠. 이 CPU가 쓸모 있는 일을 하게 만드는 건 운영체제(OS)입니다. OS는 메모리를 관리하고, 파일을 열고, 어떤 프로그램이 어떤 자원에 접근할 수 있는지를 통제합니다. 다시 말해, OS는 CPU가 마주할 세상을 정합니다. CPU가 무엇을 보고, 무엇을 만질 수 있는지를 결정하는 거죠.

AI 에이전트도 똑같은 구조입니다. 실제로 '생각'하는 건 LLM입니다. CPU 자리죠. 모델이 지금 보고 있는 정보, 즉 컨텍스트 윈도우는 작업 기억인 메모리(RAM)에 해당합니다. 그리고 하네스는 정확히 운영체제 자리에 있습니다. 하네스는 모델이 어떤 도구를 쓸 수 있는지, 어떤 정보를 보는지, 어디까지 행동해도 되는지를 통제합니다. OS가 CPU가 마주할 세상을 정하듯, 하네스는 AI 모델이 마주할 세상을 정합니다.

그리고 우리가 OS 위에서 실제로 켜서 쓰는 것이 애플리케이션이듯, 이 하네스 위에서 사용자가 실제로 만나는 최종 결과물이 바로 에이전트입니다. 사용자는 LLM을 직접 만지지 않습니다. 하네스가 빚어낸 에이전트를 마주할 뿐이죠. 이렇게 보면 "모델이 아니라 하네스가 제품을 만든다"는 말이 왜 나오는지 분명해집니다. 아무리 빠른 CPU도 형편없는 OS 위에서는 제 성능을 내지 못합니다. 반대로 평범한 CPU라도 잘 설계된 OS 위에서는 안정적으로 돌아가죠. AI도 다르지 않습니다.

하네스는 네 개의 구성요소로 이루어집니다

그렇다면 이 '운영체제'는 구체적으로 무엇으로 이루어져 있을까요? 하네스는 크게 네 가지 요소로 구성됩니다. 이 내개의 단어가 PM이 엔지니어와 대화할 때 쓸 수 있는 공통 언어이기도 합니다.

➀ 가이드 - 잘못 가기 전에 막는 장치

가이드는 행동하기 '전에' 방향을 잡아주는 장치입니다(피드포워드 통제). 가장 대표적인 게 시스템 프롬프트지만, 그게 전부는 아닙니다. 코드 저장소 루트에 놓이는 AGENTS.md, CLAUDE.md 같은 규칙 파일도 전부 가이드입니다. "빌드는 이 명령으로 한다", "이 정보는 절대 노출하지 않는다" 같은 규칙이 담기죠. PM 관점에서 가이드는 곧 정책입니다. 어떤 어조로 답할지, 무엇을 절대 말하지 않을지, 어떤 도구는 확인 없이 써도 되고 어떤 도구는 반드시 확인을 받아야 하는지 — 이 답이 곧 가이드의 내용입니다.

➁ 센서 - 결과를 검증하고 스스로 고치게 만드는 장치

센서는 행동한 '뒤에' 그게 맞았는지 알려주고, 틀렸으면 다시 하게 만드는 장치입니다(피드백 통제). 가이드가 사전 예방이라면 센서는 사후 검증이죠. 코딩 에이전트 세계에서 가장 익숙한 센서는 린터와 테스트입니다. 에이전트가 코드를 짜면 린터가 규칙을 검사하고, 테스트가 동작을 확인하고, 실패하면 그 결과가 다시 에이전트에게 전달돼 스스로 고칩니다. 이 자가 수정 루프가 센서의 본질입니다. AI 프로덕트에선 출력 형식 검증기, 환각을 판별하는 별도의 LLM 호출(LLM-as-a-Judge), 사용자 피드백 위젯이 모두 센서입니다. AI 프로덕트의 품질을 측정하는 이밸(Eval)도 본질적으로 이 센서 레이어에 속하고요. PRD에 "이 기능엔 어떤 센서를 달까"를 적는 것이, AI PM이 새로 익혀야 할 가장 중요한 문서화 능력입니다.

➂ 도구 오케스트레이션 - 에이전트의 손과 발

에이전트가 바깥세상과 연결되는 통로가 도구입니다. 웹 검색, 데이터베이스 조회, 이메일 발송, 캘린더 조작, 결제 처리. 에이전트가 무엇을 할 수 있는가는, 곧 어떤 도구를 쥐고 있는가와 같은 말입니다. 그런데 도구를 많이 준다고 좋은 게 아닙니다. 컨텍스트 윈도는 한정돼 있고, 도구가 너무 많으면 에이전트가 오히려 헷갈려 합니다. 어떤 도구를, 어느 단계에서, 어떤 사용자에게 허용할지, 이런 것들이 다 도구 오케스트레이션입니다. PM에겐 이게 권한 설계 문제와 직결됩니다. 결제 도구를 자동으로 호출하게 둘 것인가, 아니면 사용자 승인 단계를 무조건 끼워 넣을 것인가? 이 결정 하나가 에이전트의 능력과 위험을 동시에 정합니다.

④ 휴먼 체크포인트 - 사람의 판단이 필요한 자리

완전한 자율은 거의 항상 잘못된 설계입니다. 좋은 하네스는 어디를 자동화하고 어디에 사람을 끼워 넣을지를 명시적으로 정합니다. "이 명령을 실행하시겠습니까?" 같은 승인 게이트, 긴 작업 중간의 진행 보고, 일정 비용을 넘으면 자동으로 멈추고 사람을 부르는 비용 게이트가 전부 휴먼 체크포인트입니다. 여기 중요한 반전이 있습니다. 휴먼 체크포인트는 사람이 에이전트를 감시하려는 장치가 아닙니다. 정반대입니다. 실수 비용이 가장 큰 자리에만 사람을 배치해서, 사람의 시간을 가장 중요한 곳에 쓰려는 설계입니다. 그리고 이 마찰의 균형 (너무 자주 물으면 답답하고, 너무 안 물으면 위험한 일이 자동으로 벌어지는) 을 잡는 게 바로 UX의 역할입니다.

이 넷은 따로 있으면 별 의미가 없습니다. 맞물려 돌아갈 때 비로소 하네스가 됩니다. 사내 코드 리뷰를 돕는 AI 에이전트를 예로 들면, 가이드(코딩 컨벤션·보안 규칙)가 방향을 잡고, 센서(린터·테스트·별도 평가자)가 품질을 검증하고, 도구 오케스트레이션(저장소 조회·이력 확인)이 능력 범위를 정하고, 휴먼 체크포인트(PR 생성 전 인간 리뷰어 승인)가 가장 위험한 결정에 사람을 앉힙니다. 같은 LLM을 써도, 이 네 레이어를 어떻게 설계했느냐에 따라 완전히 다른 제품이 나옵니다.

그래서, PM은 어디에 서 있을까요

하네스 엔지니어링이라는 말이 뜨면서, 어떤 회사엔 아예 '하네스 엔지니어'라는 직군까지 생기고 있습니다. 그러면 PM의 자리는 어디일까요? PM은 코드를 짜지도, 가드레일을 직접 구현하지도 않습니다. 하지만 하네스 설계 회의에서 PM만이 답할 수 있는 질문이 분명히 있습니다. 다음 세 가지입니다.

첫째, 자동화의 범위

이 에이전트가 사용자 확인 없이 어디까지 행동해도 되는가? 매번 확인받으면 사용자는 답답해합니다. 확인 없이 다 자동화하면 사용자는 신뢰를 거둡니다. 이건 기술 결정이 아닙니다. 사용자가 우리 제품에 무엇을 기대하고 무엇을 두려워하는지 알아야 답할 수 있는, PM의 영역입니다.

둘째, 비용과 신뢰의 균형

센서를 정교하게 달수록 응답은 느려지고 토큰 비용은 늘어납니다. 가드레일을 강하게 걸수록 에이전트의 능력은 줄어듭니다. 어디서 비용을 지불하고 어디서 위험을 감수할 것인가? 이 답도 결국 사용자가 무엇을 가장 중요하게 여기는지에 달려 있습니다.

셋째, “어떻게 실패할 것인가”

모든 AI 시스템은 언젠가 실패합니다. 그 실패가 사용자에게 어떻게 보여야 할까요? 명시적인 에러 메시지일까요, 아니면 조용한 폴백일까요? 실패했을 때 어떤 데이터를 자동으로 모아 다음 개선에 써야 할까요? 전부 하네스 설계 결정이고, 전부 PM이 깊이 관여해야 할 문제입니다.

정리하면 이렇습니다. 엔지니어가 "어떻게 만들 것인가"를 책임진다면, PM은 "어디까지 자동화하고, 어디서 사람을 부르고, 실패는 어떻게 보이게 할 것인가"를 책임집니다. 이게 AI 프로덕트 PM의 가장 새로운 책임입니다.

오늘부터 해 볼 세 가지

➀ 써볼 것

지금 맡은 AI 기능 하나를 골라 네 칸으로 나눠보세요. 가이드 / 센서 / 도구 / 휴먼 체크포인트. 각 칸에 한 줄씩 채워보면, 빈 칸이 곧 다음 설계 과제입니다.

➁ 참고할 것

다음 PRD에 딱 한 항목만 추가해보세요. "이 기능엔 어떤 센서를 달고, 어디에 휴먼 체크포인트를 둘 것인가." 이 한 줄이 데모용 AI와 프로덕션용 AI를 가릅니다.

➂ 적용해볼 것

에이전트가 실수했을 때 던지는 질문을 바꿔보세요. "프롬프트를 어떻게 고치지?"가 아니라, "이 실수가 구조적으로 불가능해지려면, 환경에 무엇을 더해야 하지?" 이 질문 하나가 하네스 엔지니어링의 시작입니다.

중세의 판을 바꾼 건 더 빠른 말이 아니라, 발밑의 작은 발걸이였습니다. AI도 그렇습니다. 모델 경쟁만 바라보고 있으면, 정작 제품의 성패를 가르는 장치를 놓칩니다. 좋은 AI PM은 가장 센 말을 고르는 사람이 아닙니다. 고삐를 어떻게 쥘지 아는 사람입니다.

위 콘텐츠는 『AI 프로덕트 매니지먼트』김영욱 저자가 작성한 특별 기고문입니다.

『프로덕트 매니지먼트』로 PM의 성장 가이드를 제시한 김영욱 저자가 이번에는 AI 시대에 맞춰 PM의 역할과 책임을 다시 정의합니다. 책은 소프트웨어와 AI 시스템이 근본적으로 어떻게 다르게 작동하는지에서 출발해 AI 프로덕트에서 발생하는 새로운 실패를 설계 단계부터 어떻게 다뤄야 하는지, 그 판단이 PRD와 지표, 팀의 협업 방식을 어떻게 바꾸는지 짚습니다.

더 나아가 AI PRD와 평가 플랜 작성, 하네스 설계, AI 지표와 모니터링, 머신러닝 엔지니어와의 협업까지. 아이디어를 실제 프로덕트로 만들고 운영하는 전 과정을 한 권에 담았습니다. 과거의 PM이 '어떤 기능을 만들 것인가'를 결정했다면, AI 시대의 PM은 '시스템이 어떻게 동작하고, 틀리며, 오류를 어떻게 설계할 것인가'까지 책임져야 합니다. AI를 ‘프로덕트’로 만드는 방법이 필요한 모든 분께 추천합니다.