하네스-루프 엔지니어링, PM은 어디까지 알아야 할까

이번 글은 필자가 출간한 『AI 프로덕트 매니지먼트』 책의 일부를 요즘IT 독자의 시선에 맞춰 재가공했습니다.

두 단어의 유행, 그리고 오해

2026년 상반기, AI 업계에는 두 개의 새 용어가 빠르게 자리 잡았습니다. 하네스 엔지니어링(Harness Engineering)과 루프 엔지니어링(Loop Engineering)입니다. AI에 관심 있는 분들이라면, 두 단어를 IT 뉴스와 블로그에서 심심찮게 보았을 겁니다. 그토록 인기 있는 단어지만, 둘을 나란히 놓고 그 차이를 명확하게 설명할 수 있는 PM은 의외로 많지 않습니다. 실제로 엔지니어들 사이에서도 두 개념이 자주 혼동되기 때문일 것입니다.

이 단어들을 제대로 다루기 전, 알아둘 흥미로운 사실이 하나 있습니다. AI 프로덕트 속 무한 루프에 빠져서 같은 실수를 반복하는 AI 에이전트와, 사람이 매번 명령을 입력해야만 움직이는 AI 에이전트는 근본적으로 원인이 같습니다. 에이전트 스스로 어떤 문제를 풀고 있는지 모른다는 것입니다. 다만, 해결 방식은 다릅니다. 전자는 하네스가 없어서 생긴 문제이고, 다른 하나는 루프가 없어서 생긴 문제죠. 그러나 그 둘을 구분하지 못한 팀은 잘못된 곳에 시간을 씁니다.

이 두 개념이 왜 헷갈리는지, 그리고 왜 이것이 엔지니어라기보단 PM의 문제인지를 다루어 보려 합니다.

1. 자동차로 설명하는 하네스와 루프

이해를 돕기 위해 자동차로 비유를 해 봅니다.

자동차의 핵심 요소 역시 아래 세 가지로 묶을 수 있습니다.

• 엔진 혹은 모터: 순수한 동력. 다만, 그 자체로는 어디로 갈지 결정하지 못합니다.
• 하네스: 브레이크, 에어백, 계기판, ABS. 엔진의 힘을 안전하고 예측 가능하게 만드는 모든 장치입니다.
• 루프: 운전자와 내비게이션. “지금 어디로 갈까, 다음엔 어디로 갈까, 지금 멈춰야 하나”를 결정합니다.

이걸 AI 에이전트에 대응시키면 이렇게 됩니다.

• LLM: 엔진(GPT-5, Claude Opus 같은 것들)
• 하네스: 브레이크와 안전 장치(가드레일, 검증기, 도구 권한, 관찰 가능성)
• 루프:운전자와 내비게이션(태스크를 언제 시작할지, 무엇을 다음에 할지, 언제 끝낼지)

따라서 두 개념은 서로 다른 질문에 답합니다.

• 하네스가 답하는 질문: 이 한 번의 실행이 안전하고 신뢰할 만한가?
• 루프가 답하는 질문: 시스템이 다음에 무엇을 할지, 그리고 언제 멈출지를 스스로 결정할 수 있는가?

훌륭한 하네스만 있고 루프를 갖추지 못한 자동차는 안전하게 주차장에만 서 있습니다. 한편 강력한 엔진과 야심 찬 내비게이션은 있지만 브레이크가 없는 자동차는 곧 사고를 냅니다. AI 에이전트의 실패도 정확히 이 두 가지에서 출발합니다.

2. 하네스의 구조를 이해하자

하네스를 여러분이 사용하는 컴퓨터로 설명하면, 이해가 쉽습니다.

핵심은 하네스가 운영체제 자리에 있다는 것입니다. CPU가 마주할 세상을 컨트롤하는 운영체제처럼, 하네스는 AI 모델이 마주할 세상을 정합니다.

이를 실제로 구현하기 위해 하네스 엔지니어링은 다음의 네 가지 구성요소로 이루어집니다.

• 가이드: 잘못 가기 전에 방향을 잡아주는 장치
• 센서: 결과를 검증하고 자가 수정하게 만드는 장치
• 도구 오케스트레이션: 에이전트가 외부와 연결되는 통로
• 휴먼 체크포인트: 사람의 판단이 필요한 자리

그리고, 루프는 이 하네스 위에서 돌아갑니다. “지금 무슨 작업을 골라야 하나 → 하네스가 안전하게 실행 → 완료됐나 확인 → 안 됐으면 다음 시도, 됐으면 다음 작업으로.” 이 사이클 그 자체가 루프입니다.

3. 그런데 이게 왜 PM의 문제일까

두 개념 모두 “엔지니어링”으로 끝납니다. 그래서 흔히 “그건 엔지니어들이 알아서 할 문제 아닌가요?”라는 반응을 봅니다.

절반만 맞는 말입니다. 하네스와 루프의 구현은 엔지니어의 몫입니다.하지만 그 설계 방침은 프로덕트 매니저의 결정입니다. 프로덕트에 대한 결정을 엔지니어가 대신 내리기 시작하는 순간, 여러분의 제품은 사용자가 아니라 개발 편의성 기준으로 설계되기 쉽습니다.

구체적으로 봅시다. 하네스와 루프를 만들 때 반드시 답해야 하는 질문들이 있습니다.

• 이 에이전트는 사용자 확인 없이 어디까지 자동으로 행동해야 하나요? 매번 확인을 받으면 사용자가 답답하고, 확인 없이 자동으로 수행하면 신뢰를 보장할 수 없는데, 어디에 선을 그어야 하나요?
• 에이전트가 실패했을 때, 사용자에게 명시적인 에러를 보여줄 것인가요? 아니면 조용히 폴백 동작으로 넘어갈 것인가요?
• 루프가 몇 번의 시도 후에도 문제를 풀지 못하면, 그때 누구/무엇을 호출하나요? 그 호출 횟수는 어떻게 되나요?
• 더 정교한 센서를 붙이면 응답이 느려지고 비용이 올라가겠지만, 비용 지불의 책임은 누구인가요?

이 질문들에 답할 수 있는 사람은 사용자가 무엇을 기대하고 무엇을 두려워하는지 아는 사람뿐입니다. 그것이 PM의 역할이지요.

엔지니어에게 “적당히 알아서 해주세요”라고 넘기면, 그들은 엔지니어의 관점에서 안전한 기본값을 고릅니다. 그건 대부분 “매번 사용자에게 확인받기”와 같은 답입니다. 그 결과, 사용성이 심각하게 떨어지는 제품이 나옵니다. 반대로 “최대한 자동화해서 매끄럽게”라고 얼버무리면 사용자가 원치 않는 순간에 에이전트가 결정을 내려 버리는 제품이 나올 것입니다. PM이 주도하지 않으면, 제품의 사용자 경험은 컨트롤되지 않습니다.

4. PM이 반드시 개입해야 할 세 지점

그럼 구체적으로 어디에 개입해야 할까요. 다음의 세 지점이 보입니다.

① 자동화의 범위와 휴먼 체크포인트

에이전트가 사용자 확인 없이 어디까지 행동할 수 있어야 하는가? 이 질문은 UX에 관한 것입니다.

여기에는 중요한 인사이트가 있습니다. 휴먼 체크포인트는 사용자를 답답하게 만드는 마찰이 아니라, 사용자의 시간을 가장 중요한 순간에 쓰도록 만드는 설계입니다. 확인을 위한 마찰이 너무 크면, 즉, 확인할 내용이 너무 많으면, 사용자는 무심코 모두 승인해 버리기 쉽습니다(그러면 체크포인트의 의미가 사라집니다). 반면 마찰이 너무 작으면 위험한 행동이 사용자의 의지나 예상과 상관없이 일어납니다.

PM이 답해야 할 질문은 이것입니다. “우리 제품에서 사용자가 반드시 멈추고 확인해야 할 순간은 언제인가? 그리고 그 순간을 확인하는 UX는 얼마나 구체적이고 명시적이어야 하는가?” 이건 엔지니어가 대신 답할 수 없습니다.

② 루프의 완료 조건과 인간 개입 트리거

에이전트가 계속 돌아야 하는지 멈춰야 하는지를 결정하는 것이 루프의 완료 조건입니다. 여기서 PM이 답해야 할 질문은 두 가지입니다.

• 언제 성공인가?: 에이전트가 무엇을 달성했을 때 “이제 됐다”고 판단할 수 있는가? 이 기준이 명확하지 않으면 에이전트는 무한 루프에 빠지거나, 반대로 미완성 상태에서 조기 종료됩니다.
• 언제 사람을 부르는가?: 실패, 예외, 예상치 못한 상황에서 언제 사람의 개입을 요청할 것인가? 몇 번의 시도 후에? 어떤 신호를 감지했을 때? 그리고 부를 사람은 누구인가?

이 질문에 답할 수 없으면 두 가지 극단적인 상황이 벌어집니다. 에이전트가 아무도 부르지 않고 조용히 잘못된 결과를 내놓거나, 반대로 사소한 상황에서도 사람을 부르느라 자동화의 의미가 사라집니다.

③ 비용·품질·속도의 트레이드오프

이건 하네스와 루프 모두에 해당합니다. 더 정교한 센서를 붙이면 품질은 올라가지만 비용과 응답 시간이 늘어납니다. 루프가 더 많은 시도를 하면 성공률은 올라가지만 사용자는 오래 기다려야 합니다.

이 트레이드오프에서 무엇을 우선할지는 순수한 프로덕트 레벨의 결정입니다. 사용자가 정확도를 위해 응답 시간을 얼마나 감수할 수 있는가? 우리 비즈니스 모델이 감당할 수 있는 토큰 비용의 상한은 얼마인가? 이 질문에 답할 수 있는 사람은 시장과 사용자를 아는 사람이지, 인프라 비용만을 아는 사람이 아닙니다.

5. AI PM이라면 반드시 던져야 할 세 가지 질문

하네스와 루프라는 AI 엔지니어링의 새로운 개념을 실무에 적용하는 가장 빠른 방법은 세 가지 핵심 질문을 던지는 것입니다.

• “우리 에이전트가 사용자 확인 없이 할 수 있는 행동과, 반드시 확인을 받아야 하는 행동의 경계는 어디에 있습니까?”

이 경계가 문서로 정의되어 있는지, 아니면 엔지니어가 코드를 짜면서 결정한 것인지 확인해 보기 바랍니다.

• “에이전트가 수행한 작업이 성공했는지 실패했는지, 누가 어떻게 판단합니까?”

만약 답이 “사용자가 불만을 제기하면 알게 됩니다”라면, 여러분 팀에는 센서가 없다는 뜻입니다. 즉, 배포 후 품질을 실시간으로 확인할 수 있는 신호가 없다는 말입니다.

• “에이전트가 몇 번의 시도 후에도 작업을 완료하지 못하면, 그때 무슨 일이 일어납니까?”

이 질문에 명확한 답이 없다면, 여러분의 루프는 완료 조건과 인간 개입 트리거가 설계되지 않은 상태입니다.

위의 세 가지 질문에 팀이 명확하게 답할 수 있다면, 여러분은 이미 하네스와 루프를 프로덕트 관점에서 관리하고 있는 훌륭한 AI PM입니다.

마치며: PM이 개입하지 않으면 사용자 경험은 우연이 됩니다

하네스 엔지니어링과 루프 엔지니어링이란 단어에는 “엔지니어링”이 붙어 있지만, 그 안의 가장 중요한 결정들은 프로덕트에 관련된 결정입니다. 어디까지 자동화할 것인지, 언제 사람을 부를 것인지, 실패는 어떻게 보여줄 것인지, 그리고 비용과 품질 사이 어디에 선을 그을 것인지.

엔지니어가 이 결정을 대신 내리기 시작하면, 여러분의 제품은 사용자가 아니라 개발 편의성의 관점에서 설계됩니다. 그리고 이는 요즘 여러 AI 프로덕트들이 어색한 배경이기도 할 것입니다. 사용자와 제품의 관점에서 이 모든 질문에 답할 수 있는 사람이 PM이어야 합니다. 그리고 이것이 PM이 하네스와 루프를 알고, 그 결정에 관여해야 하는 진짜 이유일 것입니다.

이 주제를 비롯해 AI 프로덕트 매니지먼트의 다른 개념들을 최근 제가 출간한 『AI 프로덕트 매니지먼트』에서 확인할 수 있습니다. 이번 아티클은 그 책의 관점 일부를 최근의 하네스와 루프 엔지니어링 논의까지 확장한 요약편입니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.