AI 에이전트가 잘 일하게 만드는 사람은 누구일까. 많은 사람이 먼저 프롬프트를 잘 쓰는 사람을 떠올린다. 어떤 사람은 모델을 고르는 엔지니어를 생각하고, 또 어떤 사람은 기능 요구사항을 정리하는 PM을 떠올린다. 모두 중요한 역할이다. 하지만 제품 수준의 AI 에이전트를 만들 때 결정적인 차이를 만드는 사람은 따로 있다. 바로 모델이 어떤 환경에서, 어떤 규칙 아래, 어떤 도구와 권한을 가지고, 어떤 검증 절차를 거쳐 일하게 할지 설계하는 사람, 즉 하네스 설계자다.
하네스 설계자는 단순히 AI에게 일을 "시켜보는" 사람이 아니다. 일을 맡길 수 있는 구조를 만든다. 에이전트가 실패했을 때 어디서 멈춰야 하는지, 어떤 기록이 남아야 하는지, 무엇은 자동으로 처리하고 무엇은 사람에게 넘겨야 하는지까지 설계한다. 말하자면 모델의 지능을 믿는 사람이 아니라, 지능이 안전하고 반복 가능하게 작동하도록 작업장을 만드는 사람이다.
하네스 설계자는 왜 별도의 역할인가
초기의 AI 프로젝트에서는 한 사람이 모든 일을 맡는 경우가 많았다. API를 붙이고, 프롬프트를 만들고, 결과를 눈으로 확인하면서 "그럭저럭 된다"는 수준까지 끌고 가는 방식이다. 데모 단계에서는 이런 접근이 충분히 통할 수 있다. 하지만 실제 서비스나 조직 업무에 들어가는 순간 문제가 달라진다.
이때부터 질문은 바뀐다. 모델이 똑똑한가보다, 이 모델이 이 상황에서 무엇을 볼 수 있는가, 어떤 도구를 쓸 수 있는가, 실수했을 때 어떤 피해가 생기는가, 그 실수를 누가 어떻게 발견하는가가 더 중요해진다. 바로 이 질문들을 구조로 바꾸는 사람이 하네스 설계자다.
하네스 설계자의 핵심 임무는 세 가지로 요약할 수 있다.
에이전트가 일하는 실행 환경을 정의한다.
실패를 줄이고 발견을 빠르게 하는 운영 구조를 만든다.
사람과 AI의 역할 경계를 제품 안에서 명확히 정한다.
즉, 하네스 설계자는 모델의 능력을 끌어내는 사람이라기보다, 모델의 능력이 현실에서 유효해지도록 만드는 사람이다.
프롬프트 작성자와 무엇이 다른가
프롬프트 작성자는 보통 모델에게 어떻게 말할지를 고민한다. 같은 일을 시켜도 표현 방식에 따라 결과가 달라지기 때문에, 이는 분명 중요한 능력이다. 좋은 프롬프트는 모호함을 줄이고, 출력 형식을 안정화하고, 모델이 따라야 할 우선순위를 정리해 준다.
하지만 프롬프트만으로 해결되지 않는 문제가 있다. 예를 들어 에이전트가 잘못된 파일을 수정했다면, 그것은 지시문 표현의 문제가 아닐 수 있다. 읽을 수 있는 파일 범위가 너무 넓었을 수도 있고, 작업 전 확인 단계가 없었을 수도 있으며, 변경 후 테스트를 강제하는 루프가 빠져 있었을 수도 있다. 이런 문제는 프롬프트를 다듬는 것만으로는 해결되지 않는다.
프롬프트 작성자가 "무슨 말을 할까"에 초점을 둔다면, 하네스 설계자는 "그 말이 실제 행동으로 이어질 때 어떤 제약과 절차가 필요한가"에 초점을 둔다. 프롬프트가 대화의 설계라면, 하네스는 작업의 설계다.
좋은 비유가 있다. 프롬프트 작성자는 숙련된 브리핑 담당자에 가깝다. 일을 명확하게 설명하고, 기대 결과를 잘 전달한다. 반면 하네스 설계자는 작업 현장의 감독관에 가깝다. 작업 순서를 정하고, 위험 구역을 구분하고, 품질 검사 지점을 만들고, 사고가 나면 즉시 멈추게 한다.
물론 현실에서는 두 역할이 겹친다. 특히 작은 팀에서는 한 사람이 둘 다 해야 한다. 그러나 사고방식은 분리할 필요가 있다. 프롬프트를 잘 쓰는 것과, 프롬프트가 실패하더라도 시스템이 안전하게 버티게 만드는 것은 다른 능력이다.
소프트웨어 엔지니어와 무엇이 다른가
하네스 설계자는 엔지니어와 매우 가까운 역할이다. 실제로 많은 팀에서는 백엔드 엔지니어, ML 엔지니어, AI 엔지니어가 이 역할을 겸한다. 그렇다면 둘은 같은 사람일까. 비슷하지만 완전히 같지는 않다.
소프트웨어 엔지니어가 주로 기능을 정확하게 구현하는 사람이라면, 하네스 설계자는 불확실한 모델이 기능 안에서 어떻게 행동할지를 제어하는 사람이다. 일반 소프트웨어에서는 입력과 출력의 관계를 비교적 명확하게 정의할 수 있다. 하지만 에이전트 시스템은 같은 입력이라도 상황, 컨텍스트, 도구 상태에 따라 다른 경로를 택할 수 있다. 그래서 하네스 설계는 단순 구현보다 행동 경계 설계에 더 가깝다.
예를 들어 일반 백엔드 엔지니어는 "사용자 요청이 오면 데이터베이스를 조회하고 결과를 반환하는 API"를 만든다. 하네스 설계자는 여기에 이런 질문을 더한다. 에이전트가 언제 조회를 시도해야 하는가? 어떤 경우에는 조회 대신 사람 승인을 받아야 하는가? 한 번 실패했을 때 몇 번까지 재시도해야 하는가? 응답에 확신이 낮으면 어떻게 표시해야 하는가? 결과를 사용자에게 바로 보여줄 것인가, 아니면 검토 큐로 보낼 것인가?
즉, 엔지니어링이 시스템을 "만드는" 일이라면, 하네스 설계는 시스템 안에서 에이전트가 "일하는 방식"을 설계하는 일이다. 코드가 필요 없다는 뜻은 아니다. 오히려 코드를 이해해야 더 잘할 수 있다. 다만 구현의 목표가 기능 완성이 아니라, 행동 품질과 운영 안정성이라는 점이 다르다.
PM과 무엇을 함께 결정하는가
하네스 설계자는 PM과 자주 부딪힌다. 좋은 의미에서 그렇다. PM은 사용자 문제와 비즈니스 목표를 정의한다. 하네스 설계자는 그것을 AI가 수행 가능한 작업 구조로 바꾼다.
예를 들어 PM이 "고객 문의에 자동 응답하는 에이전트를 만들자"고 말하면, 하네스 설계자는 곧바로 다음 질문을 던져야 한다. 어떤 문의까지 자동 응답할 수 있는가? 환불, 계약 해지, 법적 분쟁처럼 위험도가 높은 질문은 자동화 대상에서 제외할 것인가? 사용자에게는 AI 응답임을 명시할 것인가? 답변 속도와 정확도 중 무엇을 우선할 것인가? 실패했을 때 상담원에게 어떻게 자연스럽게 넘길 것인가?
이 과정에서 하네스 설계자는 PM의 요구사항을 반대하는 사람이 아니라, 요구사항을 운영 가능한 구조로 다듬는 사람이다. 좋은 PM은 기능을 정의하고, 좋은 하네스 설계자는 그 기능이 무너지지 않게 만든다.
PM과 하네스 설계자가 함께 봐야 할 핵심 질문은 다음과 같다.
어떤 문제를 AI가 맡고 어떤 문제를 사람이 맡는가
성공을 무엇으로 측정하는가
실패 비용이 큰 구간은 어디인가
사용자 경험상 기다려도 되는 지점과 즉시 응답해야 하는 지점은 어디인가
자동화 수준을 어디까지 허용할 것인가
AI 제품에서 PM이 없는 하네스 설계는 기술적으로 정교하지만 쓸모없어지기 쉽고, 하네스 설계가 없는 PM 기획은 그럴듯하지만 운영 단계에서 무너지기 쉽다.
디자이너와의 협업은 왜 중요한가
많은 팀이 AI를 기술 문제로만 본다. 하지만 에이전트는 사용자가 보지 못하는 곳에서만 일하지 않는다. 종종 사람과 협업한다. 그래서 인터페이스와 상호작용 설계가 매우 중요하다.
하네스 설계자는 디자이너와 함께 "AI가 어디까지 스스로 판단하고, 어디에서 사람에게 물어봐야 하는가"를 사용자 경험으로 풀어내야 한다. 승인 요청 화면은 어떻게 보여줄까. 에이전트가 어떤 근거로 결론을 냈는지 어느 수준까지 설명할까. 확신이 낮을 때는 어떤 표현을 사용할까. 자동 실행된 작업은 사용자가 어떻게 되돌릴 수 있을까.
이 질문들은 단순히 예쁜 화면의 문제가 아니다. 사용자가 시스템을 신뢰할 수 있는지, 지나치게 믿어 버리지 않는지, 필요할 때 개입할 수 있는지가 모두 여기에 달려 있다. 하네스 설계자는 디자이너와 함께 에이전트의 내부 규칙을 외부 경험으로 번역해야 한다.
특히 좋은 디자이너는 이런 부분에서 강하다. 사람은 어떤 순간에 불안을 느끼는지, 어떤 설명이 안심을 주는지, 어떤 버튼 하나가 과도한 자동화를 막아 주는지를 잘 안다. 하네스 설계자는 그 감각을 기술 구조와 연결하는 사람이다.
보안 담당자와의 관계는 왜 더 가까워질까
기존 소프트웨어에서도 보안은 중요했다. 그러나 에이전트 시스템에서는 보안이 더 일상적인 설계 문제가 된다. 이유는 간단하다. 에이전트는 읽고, 쓰고, 실행하고, 전송할 수 있기 때문이다. 다시 말해, 피해를 낼 수 있는 행동 단위를 직접 수행할 수 있다.
그래서 하네스 설계자는 보안 담당자와 멀리 떨어져 일할 수 없다. 어떤 도구를 연결할지, 어떤 자격 증명을 사용할지, 어떤 요청에는 승인 단계를 둘지, 외부 문서를 읽을 때 무엇을 믿지 말아야 하는지, 로그에 무엇을 남기고 무엇은 마스킹할지 같은 문제를 함께 정해야 한다.
보안 담당자는 보통 "하지 말아야 할 것"을 본다. 하네스 설계자는 "해야 할 일을 하면서도 위험을 줄이는 구조"를 본다. 둘은 방향이 다른 것이 아니라 초점이 다르다. 좋은 하네스 설계자는 보안을 마지막 검토 단계가 아니라 초기 설계 입력값으로 받아들인다.
여기서 중요한 점이 있다. 보안은 속도를 늦추는 장애물이 아니라, 자동화를 지속 가능하게 만드는 조건이라는 점이다. 승인 흐름, 권한 분리, 실행 기록, 비밀값 관리, 롤백 설계는 모두 보안을 위해서만 필요한 것이 아니다. 제품을 오래 운영하기 위해 필요한 기본 장치다.
하네스 설계자의 하루는 어떤 일로 채워지는가
이 역할이 추상적으로 들린다면, 실제로 어떤 일을 하는지 상상해 보자. 하네스 설계자의 하루는 생각보다 현장적이다.
어떤 날은 에이전트가 왜 같은 작업을 세 번 반복했는지 로그를 본다. 어떤 날은 새 도구를 붙이기 전에 입력 스키마를 줄이고 설명 문구를 다듬는다. 어떤 날은 PM과 함께 자동 승인 범위를 조정한다. 또 어떤 날은 보안 팀과 민감 데이터 접근 정책을 정리하고, 운영 팀과 장애 대응 절차를 맞춘다. 사용자의 불만 사례를 읽고, "모델이 틀렸다"가 아니라 "왜 이 상황에서 틀려도 막을 장치가 없었나"를 질문하는 일도 많다.
즉, 하네스 설계자는 한 번 멋진 구조를 만들고 끝나는 사람이 아니다. 실제 운영에서 생기는 마찰을 구조 개선으로 바꾸는 사람이다. 그래서 이 역할은 문서 작성, 로그 분석, 규칙 설계, 인터페이스 조정, 팀 간 조율을 모두 포함한다.
하네스 설계자에게 필요한 핵심 역량
이 역할은 특정 기술 하나만으로 성립하지 않는다. 프롬프트만 잘 써도 부족하고, 코딩만 잘해도 부족하다. 여러 층위를 함께 볼 수 있어야 한다.
첫째는 시스템 사고다. 한 지점의 개선이 다른 지점에 어떤 영향을 주는지 볼 수 있어야 한다. 도구를 하나 더 연결하면 정확도는 올라갈 수 있지만, 보안 표면도 넓어진다. 승인 단계를 넣으면 안전해지지만 처리 시간은 늘어난다. 하네스 설계자는 이런 교환 관계를 읽어야 한다.
둘째는 실패 감각이다. 무엇이 잘될지보다 무엇이 망가질지를 먼저 떠올릴 수 있어야 한다. 에이전트는 생각보다 자주 엉뚱한 파일을 만지고, 잘못된 근거를 자신 있게 말하며, 애매한 지시를 과하게 해석한다. 하네스 설계자는 낙관적 사용자 시나리오보다 비정상 상황을 더 집요하게 본다.
셋째는 작업 분해 능력이다. 큰 목표를 그대로 모델에 맡기지 않고, 검증 가능한 단위로 나누어야 한다. 이것은 기획 능력이면서 동시에 운영 능력이다. 일이 잘게 쪼개질수록 실패 위치가 보이고, 사람 개입 지점도 설계할 수 있다.
넷째는 관측 가능성에 대한 감각이다. 보이지 않으면 고칠 수 없다. 어떤 입력이 들어왔고, 어떤 컨텍스트가 제공되었고, 어떤 도구가 호출되었고, 왜 중단되었는지를 기록하는 습관이 필요하다. 하네스 설계자는 결과보다 경로를 중시한다.
다섯째는 협업 번역 능력이다. 엔지니어에게는 구조로 말하고, PM에게는 리스크와 우선순위로 말하고, 디자이너에게는 사용자 경험으로 말하고, 보안 담당자에게는 통제와 책임 경계로 말할 수 있어야 한다. 같은 문제를 서로 다른 언어로 설명할 수 있는 사람이 강하다.
여섯째는 운영 감각이다. 데모가 아니라 실제 사용 환경을 상상해야 한다. 사용량이 늘어나면 무엇이 병목이 되는지, 에러가 쌓이면 누가 대응하는지, 비용이 튀면 어떤 기능부터 줄여야 하는지, 모델이 바뀌면 무엇을 다시 검증해야 하는지를 생각할 수 있어야 한다.
정리하면 하네스 설계자에게 필요한 역량은 다음과 같다.
시스템 사고
실패 시나리오 설계 능력
작업 분해와 절차 설계 능력
로그와 평가를 읽는 운영 감각
협업을 위한 번역 능력
보안과 권한에 대한 기본 이해
이 중 어느 하나만 뛰어나서는 오래 가기 어렵다. 하네스 설계자는 넓게 연결하는 사람이다.
기술보다 중요한 판단 기준
많은 사람이 "어떤 프레임워크를 배워야 하네스 설계자가 될 수 있나요?"라고 묻는다. 물론 도구는 중요하다. 하지만 도구보다 더 중요한 것은 판단 기준이다.
좋은 하네스 설계자는 새로운 라이브러리를 볼 때도 먼저 이런 질문을 한다. 이 도구는 에이전트가 실수할 여지를 줄이는가, 아니면 단지 기능을 더 화려하게 만드는가? 이 구조는 장애가 났을 때 원인을 추적하기 쉬운가? 권한 모델을 세밀하게 나눌 수 있는가? 사람이 개입해야 할 순간을 자연스럽게 만들 수 있는가?
다시 말해, 하네스 설계자는 최신 기술의 소비자라기보다 운영 기준의 관리자다. 멋있어 보이는 구조보다 버틸 수 있는 구조를 고른다. 자동화율이 높다는 이유만으로 좋은 설계를 선택하지 않는다. 통제 가능성과 복구 가능성이 함께 오를 때만 진짜 진보다.
새로운 직무가 아니라, 여러 직무의 교차점
하네스 설계자는 아직 많은 조직에서 공식 직함이 아니다. 누군가는 AI 엔지니어라는 이름으로 일하고, 누군가는 PM이나 솔루션 아키텍트 역할 속에서 이 일을 한다. 하지만 이름이 없다고 역할이 없는 것은 아니다. 오히려 이미 많은 팀이 이 필요를 느끼고 있다.
AI 프로젝트가 반복해서 실패하는 이유 중 하나는, 이 역할을 아무도 명시적으로 맡지 않기 때문이다. 모델 선택은 누군가 하고, 프롬프트는 누군가 쓰고, 기능 구현은 엔지니어가 하고, 보안 검토는 마지막에 들어온다. 그런데 정작 "에이전트가 실제로 어떤 경계 안에서 일할 것인가"를 총괄하는 사람은 없다. 그러면 시스템은 부분적으로는 좋아 보여도 전체적으로는 불안해진다.
앞으로 조직 안에서는 이 역할이 여러 형태로 자리 잡을 가능성이 크다.
AI 제품 팀 안의 전문 역할로 독립할 수 있다.
시니어 PM이나 스태프 엔지니어가 겸할 수 있다.
보안, 운영, AI 엔지니어링을 잇는 아키텍트 역할로 자리 잡을 수 있다.
작은 조직에서는 창업자나 첫 번째 AI 리드가 사실상 수행할 수 있다.
중요한 것은 명칭이 아니라 책임의 존재다. 누군가는 반드시 하네스를 설계해야 한다.
어떤 팀 구조에서 잘 작동하는가
하네스 설계는 한 사람의 천재성보다 팀 구조의 영향을 더 많이 받는다. 이 역할이 잘 작동하려면 에이전트 기능을 기능 개발의 부속물로만 보지 않아야 한다. 제품, 엔지니어링, 보안, 운영이 초반부터 함께 움직여야 한다.
가장 건강한 구조는 하네스 설계자가 네 가지 흐름의 접점에 서는 형태다. 제품 목표는 PM이 끌고 가고, 구현 현실성은 엔지니어가 보며, 사용자 경험은 디자이너가 다듬고, 위험 경계는 보안 담당자가 통제한다. 하네스 설계자는 이 흐름을 하나의 실행 구조로 묶는다.
그래서 이 역할은 종종 '결정자'라기보다 '정렬자'에 가깝다. 모두의 관점을 듣고, 충돌하는 요구를 운영 가능한 형태로 조정한다. 예를 들어 PM은 자동화를 늘리고 싶고, 보안은 승인 단계를 늘리고 싶고, 디자이너는 사용자의 마찰을 줄이고 싶고, 엔지니어는 복잡도를 낮추고 싶어 할 수 있다. 하네스 설계자는 그 사이에서 "어디까지는 자동, 어디부터는 승인, 어떤 경우에는 되돌리기 가능" 같은 현실적인 타협 구조를 만든다.
하네스 설계자는 어떻게 성장하는가
이 역할에 바로 입문하는 사람도 있겠지만, 대부분은 다른 출발점에서 온다. 엔지니어 출신은 구현과 시스템 사고가 강하고, PM 출신은 문제 정의와 우선순위 설정이 강하다. 보안 출신은 위험 감각이 좋고, 데이터나 운영 출신은 모니터링과 재현 가능성에 강하다. 출발점은 달라도 괜찮다. 중요한 것은 자신의 강점을 유지하면서 부족한 축을 채우는 것이다.
커리어 경로를 거칠게 그려 보면 보통 이런 순서를 밟는다. 먼저 단일 기능 수준에서 AI 자동화를 설계해 본다. 그다음 실패 사례를 체계적으로 정리하면서 로그, 평가, 승인 흐름, 예외 처리를 붙인다. 이후 여러 업무 유형에 공통으로 쓰이는 패턴을 만들고, 마지막에는 팀이나 조직 차원의 운영 원칙과 거버넌스를 설계하게 된다.
실전에서 도움이 되는 성장 방식은 분명하다.
프롬프트를 잘 쓰는 데서 멈추지 말고, 실패를 막는 구조를 함께 설계해 본다.
작은 자동화라도 로그, 승인, 롤백, 테스트를 붙여 본다.
사용자 불만 사례를 읽고 모델 품질 문제가 아니라 시스템 문제로 다시 해석해 본다.
보안과 운영 팀이 어떤 질문을 던지는지 익힌다.
하나의 멋진 데모보다 오래 버티는 흐름을 만드는 연습을 한다.
이 과정을 거치면 시야가 달라진다. 기능을 추가하는 사람에서, 기능이 실제로 일하게 만드는 사람으로 성장한다.
앞으로 더 중요해질 이유
모델은 계속 좋아질 것이다. 도구 호출도 더 자연스러워지고, 긴 컨텍스트 처리도 더 안정될 것이다. 하지만 바로 그래서 하네스 설계자의 역할은 더 중요해진다. 모델이 강해질수록 할 수 있는 일이 많아지고, 할 수 있는 일이 많아질수록 잘못했을 때의 영향도 커지기 때문이다.
약한 모델 시대에는 한계가 분명해서 사람의 개입이 당연했다. 그러나 강한 모델 시대에는 오히려 과신이 위험해진다. 얼핏 보면 잘 작동하기 때문에, 어디까지 맡겨도 되는지 판단하는 능력이 더 중요해진다. 하네스 설계자는 이 과신의 시대에 브레이크와 계기판을 만드는 사람이다.
또한 모델 경쟁이 평준화될수록 차별점은 단순 성능이 아니라 운영 구조에서 나온다. 같은 모델을 써도 어떤 팀은 사고가 적고, 어떤 팀은 사용자 신뢰를 더 빨리 얻고, 어떤 팀은 사람과 AI의 협업을 더 자연스럽게 만든다. 그 차이를 만드는 것이 하네스다. 그리고 하네스를 만드는 사람이 바로 하네스 설계자다.
하네스 설계자는 결국 무엇을 만드는 사람인가
겉으로 보면 하네스 설계자는 프롬프트도 만지고, 도구도 붙이고, 정책도 쓰고, 로그도 보고, 팀 조율도 하는 사람이라서 정체가 흐릿해 보일 수 있다. 하지만 중심은 분명하다.
하네스 설계자는 AI에게 일을 맡길 수 있는 조건을 만드는 사람이다.
그는 모델의 답변이 아니라 모델의 노동 환경을 설계한다. 더 많이 말하게 만드는 것이 아니라, 더 안전하게 일하게 만든다. 더 똑똑해 보이게 만드는 것이 아니라, 더 믿고 맡길 수 있게 만든다.
AI 시대의 핵심 직무는 모델을 숭배하는 사람이 아니다. 모델이 현실의 업무와 서비스 안에서 제대로 일하도록 환경을 설계하는 사람이다. 프롬프트는 명령이고, 컨텍스트는 재료이며, 하네스는 작업장이라고 했다. 그렇다면 하네스 설계자는 작업장을 짓는 사람이다.
좋은 작업장이 있어야 좋은 작업이 나온다. 그리고 좋은 에이전트는, 결국 좋은 하네스 설계자에게서 나온다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.