AI를 잘 쓰는 PM과 그렇지 않은 PM의 차이는 프롬프트 문장력에서 갈리지 않습니다.

진짜 차이는 루프를 설계하는 능력에서 납니다.

서울 600명이 내린 진단

지난주 서울에서 열린 컨버전스 인사이트 서밋(CIS 2026)에 기업·학계 관계자 약 600명이 모였습니다. 엔터프라이즈 AI 도입 전략을 주제로 한 자리였는데, 이 컨퍼런스에서 가장 많이 나온 진단이 하나 있습니다.

“많은 기업이 AI에 큰 비용을 투입하고도 체감 변화가 작은 원인은 더 좋은 모델이 아니라, 시스템과 에이전트 간 연결 부족이다.”

모델이 문제가 아닙니다. 설계가 문제입니다.

같은 시기 해외에서는 다른 신호가 왔습니다. 루프 하나를 제대로 설계한 팀이 PR(풀 리퀘스트) 40개 분량의 작업을 대체했다는 사례입니다. 도구를 바꾼 것이 아닙니다. 루프를 설계했습니다.

프롬프트는 입력, 루프는 시스템

20년 PM으로 이 두 신호를 함께 보면, 진단은 하나로 모입니다.

AI 시대 PM의 병목은 어떤 프롬프트를 쓰느냐에 있지 않습니다. 어떤 루프를 설계하느냐에 있습니다.

프롬프트는 입력(input)입니다. 루프는 시스템(system)입니다.

입력을 아무리 최적화해도 시스템이 없으면 성과는 일회성에 그칩니다. 반면 루프가 있으면, AI가 실행하고 끝이 아닙니다 — 실행하고, 검증하고, 피드백을 받아 다음 실행을 개선합니다. 이 반복이 쌓일수록 팀의 자산이 됩니다.

불편한 신호가 하나 있습니다. 최근 Nature에 실린 연구에 따르면, AI 도구를 루프 없이 쓴 팀은 시간이 지날수록 오히려 역량이 퇴화했습니다. AI가 대신 해주는 것이 늘어날수록 인간이 판단에 개입하는 빈도가 줄었기 때문입니다. 도구를 쓰는 것만으로는 부족합니다. 그 도구를 누가, 언제, 어디서 멈추고 검증할지를 설계해야 합니다.

루프 디자이너의 세 가지 설계 단위

Andrew Ng은 이것을 **FDE(Full-stack Decision Engineer)**라는 개념으로 정리합니다. AI 시대 가장 가치 있는 역할은 프롬프트를 잘 쓰는 사람이 아니라, AI의 실행 결과를 검증하고 다음 루프를 설정하는 사람이라는 의미입니다.

루프 디자이너로서 PM이 설계해야 할 것은 세 가지입니다.

1. 실행 단위를 쪼갠다

에이전트에게 “이거 해줘”가 아닙니다. “이 단계까지 해줘, 내가 확인하고 다음 단계로 넘길게”라는 구조를 만드는 것입니다. 에이전트의 작업 단위가 작을수록 검증이 쉬워지고, 오류가 전파되기 전에 잡을 수 있습니다.

# 루프 단위 설계 예시
loop:
  step_1: 초안 생성 → human_review
  step_2: 검증 통과 시 다음 단계 진행
  step_3: 실패 시 오류 유형 태깅 → 재실행

단순해 보이지만, 이 구조가 없는 에이전트 도입은 블랙박스가 됩니다.

2. 검증 지점을 명시한다

에이전트가 스스로 “끝났다”고 판단하는 지점과, 인간이 개입해야 하는 지점을 명시적으로 정의합니다. 이것이 평가 설계(eval design)의 시작입니다. PM이 이 경계를 정의하지 않으면, 에이전트는 끝났다고 판단하고, 인간은 미처 확인하지 못합니다.

3. 피드백을 루프에 연결한다

한 번 실행한 결과가 다음 실행을 개선하는 구조를 만듭니다. 에러 로그, 수정 히스토리, 검토 코멘트가 에이전트의 다음 컨텍스트로 들어가야 합니다. 이것 없이는 AI를 쓸수록 일회성 소비에 그칩니다.

PM의 산출물이 바뀐다

기존 PM의 산출물은 PRD(기능 명세서)였습니다. AI 시대 PM의 산출물은 루프 설계서입니다.

  • 어디서 에이전트가 실행하는가
  • 어디서 인간이 검증하는가
  • 실패 시 어떻게 복구하는가
  • 그 결과가 어떻게 다음 루프에 반영되는가

이 네 가지를 정의하는 것이 AI PM의 새 핵심 직무입니다.

CIS 2026의 진단처럼, 지금 많은 팀이 AI 도구는 도입했지만 루프는 설계하지 않았습니다. 그래서 비용은 나가는데 체감 변화가 없습니다. 모델을 바꿔도 같습니다.

당신 팀의 AI 업무 방식은 프롬프트인가요, 루프인가요?