한줄 요약
구글의 시니어 AI PM 슈밤 사부(Shubham Saboo)는 "PM의 다음 기술은 프롬프트 엔지니어링이 아니라 루프 엔지니어링"이라고 말합니다. 완벽한 프롬프트를 매번 새로 쓰는 대신, 실행할 때마다 스스로 좋아지는 시스템을 설계하라는 겁니다.
루프 엔지니어링이 뭔가요?
루프 엔지니어링(Loop Engineering)은 AI 시스템이 반복해서 도는 사이클을 설계하는 일입니다. 에이전트의 행동을 결정하는 무언가를 바꾸고 → 에이전트를 실행하고 → 결과를 평가하고 → 품질이 좋아지면 변경을 유지하고 나빠지면 되돌리고 → 그 학습을 저장해서 다음 버전이 한 발 앞에서 시작하게 만드는 것이죠.
지난 2년간 대부분의 PM은 프롬프트를 더 잘 쓰는 데 집중했습니다. 더 좋은 지시, 더 좋은 컨텍스트, 더 좋은 예시로 Claude·Codex·Cursor에게 무엇을 할지 잘 설명하는 일이요. 사부의 주장은 그 종착지가 "매번 완벽한 프롬프트를 쓰는 PM"이 아니라 "실행할 때마다 좋아지는 시스템을 설계하는 PM"이라는 겁니다.
엔지니어와 PM은 루프의 시작점이 다르다
엔지니어에게 이 사이클은 코드에서 시작합니다. 하지만 PM에게는 다른 곳에서 시작합니다. 바로 제품 업무를 빚어내는 아티팩트(artifact)입니다.
- PRD 리뷰 스킬
- 고객 콜 요약기
- 평가 루브릭(eval rubric)
- 출시 체크리스트
- 리서치 워크플로
- CLAUDE.md 지시문
- 프롬프트 템플릿
- 우선순위 프레임워크
이것들의 공통점은 오래 쓰이고 재사용된다는 점입니다. 여러분의 판단이 그 안에 새겨져 있고, 한 번의 실행이 아니라 수십 번의 실행에 걸쳐 에이전트의 행동을 좌우합니다.
프롬프트가 풀지 못하는 진짜 문제: 아티팩트 드리프트
재사용되기 때문에 이 아티팩트들은 양방향으로 복리가 붙습니다. 좋은 아티팩트는 매주 일을 더 날카롭게 만들고, 나쁜 아티팩트는 매주 조용히 일을 더 느리게 만듭니다. 결과물이 이상하게 느껴지는데 이유를 말할 수 없을 때까지요.
사부가 짚는 진짜 문제가 이겁니다. 한동안 이렇게 일하다 보면 AI 작업 공간이 드리프트(drift)하기 시작합니다.
- CLAUDE.md가 점점 길어집니다.
- PRD 리뷰 스킬이 점점 까다로워집니다.
- 리서치 워크플로에 지난 프로젝트의 지시가 끼어듭니다.
- 출시 체크리스트가 너무 길어져 에이전트가 절반을 무시합니다.
- 평가 기준이 바뀌는데 언제, 왜 바뀌었는지 잊어버립니다.
한 달 뒤, 에이전트가 더 나빠진 것처럼 느껴집니다. PRD를 더 못 쓰고, 리서치 요약이 뻔해지고, 예전엔 잡아내던 제품 뉘앙스를 놓칩니다. 모델이 나빠진 게 아닙니다. 아티팩트가 드리프트했는데 아무도 지켜보지 않았던 겁니다.
루프 엔지니어링이 PM에게 푸는 문제는 프롬프트 하나를 더 좋게 만드는 게 아닙니다. 제품 업무를 빚는 아티팩트가 서서히 썩는 대신 계속 좋아지도록 만드는 것입니다.
Photo by Octavio Fossatti on Unsplash
루프는 무엇으로 이루어지나 — 5가지 부품
쓸 만한 루프는 다섯 부분으로 구성됩니다.
이 중 정지 조건이 가장 중요합니다. 많은 AI 시스템은 모델이 나빠서 실패하는 게 아니라, 루프에 깔끔한 출구가 없어서 실패합니다. 에이전트가 계속 생성하고, 범위를 계속 넓히고, 일을 계속 만들어냅니다. 또는 증거가 부족한데 자신만만한 요약을 내놓습니다.
좋은 PM 루프는 이렇게 말할 수 있어야 합니다. "의미 있는 변화가 없다", "입력이 너무 빈약하다", "이건 막혀 있다", "품질 기준을 못 넘었다", "이건 사람의 결정이 필요하다." '멈춰'라고 말할 수 있는 루프는 켜두고 떠날 수 있고, 그러지 못하는 루프는 계속 지켜봐야 합니다.
실제로는 이렇게 생겼다 — 고 객 리서치 예시
고객 리서치를 예로 들어보겠습니다.
- 단순 버전: 에이전트에게 "이 콜들을 요약해줘"라고 묻습니다. 한 번은 유용하지만, 다음 요약이 더 나아지진 않습니다.
- 더 나은 버전: 우리 팀이 중요하게 보는 것(페인포인트, 현재 우회책, 긴급도, 반대 의견, 제품 갭, 정확한 인용, 후속 조치)을 아는 고객 콜 요약기를 만듭니다.
- 루프 버전: 매주 실행됩니다. 요약기를 써서 새 콜을 이전 테마와 비교하고, 반복되는 것·새로운 것·증거가 빈약한 곳을 표시합니다. 여러분이 결과를 검토하고, 요약이 뉘앙스를 놓쳤으면 아티팩트를 개선합니다. 다음 실행은 더 좋아집니다.
PRD 리뷰도 같습니다. "이 PRD 리뷰해줘"(단순) → 팀의 품질 기준을 아는 PRD 리뷰 아티팩트(더 나은) → 그 아티팩트가 실제로 더 좋은 피드백을 주는지 테스트하는 루프(루프 버전)로 발전합니다. 기준이 흐트러지면 프롬프트가 아니라 아티팩트를 고칩니다.
PM의 첫 루프: 주간 제품 시그널
사부는 제품 전략을 정하려는 루프부터 시작하지 말라고 합니다. 너무 넓고 주관적이고 틀리기 쉽습니다. 대신 제품 운영(product ops)에서 시작하라고 합니다. 반복 업무가 있고, 증거가 있고, 일관성이 중요한 영역이니까요.
좋은 첫 루프는 주간 제품 시그널 루프입니다.
매주 금요일, 루프가 고객 콜·지원 티켓·세일즈 노트·실험 업데이트·분석 요약·출시된 변경·열린 에스컬레이션을 읽고 하나의 제품 시그널 메모를 만듭니다.
이 메모는 뻔한 요약이 아니어야 합니다.
- 반복되는 시그널과 고립된 노이즈를 분리할 것
- 고객의 정확한 표현을 담을 것
- 지난주 대비 무엇이 바뀌었는지 보여줄 것
- 증거가 빈약한 곳을 짚을 것
- 어떤 로드맵 가정이 강해졌는지/약해졌는지/그대로인지 식별할 것
검토 후 메모가 중요한 걸 놓쳤으면 아티팩트를 업데이트하고, 에이전트가 약한 증거에 과한 가중치를 줬으면 루브릭을 조입니다. 몇 주가 지나면 유용해지고, 몇 달이 지나면 로드맵 회의 전에 반드시 확인하는 자료가 됩니다.
자주 묻는 질문
루프 엔지니어링과 프롬프트 엔지니어링은 무엇이 다른가요?
프롬프트 엔지니어링은 작업을 한 번 잘 해내게 돕고, 루프 엔지니어링은 그 작업을 매번 빚어내는 아티팩트를 개선합니다. 프롬프트는 모델에 넣는 입력을 다듬고, 루프는 실행할 때마다 결과를 평가해 학습을 저장하는 시스템 전체를 설계합니다.
PM이 가장 먼저 만들어볼 루프는 무엇인가요?
제품 전략 같은 넓은 주제가 아니라 주간 제품 시그널 루프처럼 제품 운영 영역에서 시작하는 게 좋습니다. 매주 고객 콜·티켓·실험·분석을 읽어 하나의 시그널 메모를 만들고, 메모가 놓친 부분이 있으면 아티팩트를 고쳐 다음 실행을 개선합니다.
루프를 켜두고 떠나려면 무엇이 필요한가요?
명확한 정지 조건입니다. "의미 있는 변화 없음", "증거 부족", "사람의 결정 필요" 같은 상황에서 멈출 수 있어야 합니다. '멈춰'라고 말하지 못하는 루프는 계속 지켜봐야 하므로 자동화의 의미가 없습니다.
인사이트
이 글에서 진짜 핵심은 "AI가 나빠졌다"는 느낌의 정체를 짚은 부분입니다. 많은 분이 시간이 지나면서 "Claude가 예전 같지 않다"고 느끼는데, 사부의 진단은 모델이 아니라 내 아티팩트가 드리프트했다는 겁니다. CLAUDE.md가 길어지고 스킬이 누덕누덕해지는 걸 아무도 안 지켜봤다는 거죠. 이건 지피터스 멤버분들이 직접 겪는 문제입니다.
그래서 루프 엔지니어링은 거창한 자동화가 아니라 '내 아티팩트를 지켜보는 습관'에 가깝습니다. Claude Code의 /loop, AutoResearch, Hermes Agent 같은 사례가 이미 루프의 구체적 형태였지만, 사부는 그걸 PM의 일상 아티팩트(PRD 리뷰·콜 요약·루브릭)로 끌어내렸습니다. 코드를 안 짜는 기획자도 바로 적용할 수 있는 지점이 여기입니다.
마지막으로 사부는 "맛(taste)은 여전히 중요하다, 다만 이제 증명이 필요할 뿐"이라고 말합니다. PM의 판단력 — PRD가 모호한지, 고객 인용이 과장됐는지, 출시 계획이 의존성을 못 본 척하는지 감지하는 능력 — 은 사라지지 않습니다. 루프 엔지니어링은 그 판단을 없애는 게 아니라 오히려 중심에 놓습니다. 좋은 루브릭과 검증 기준이 결국 그 사람의 판단력을 복리로 증폭시키기 때문입니다.
원문: Shubham Saboo, "Loop Engineering for Product Managers" (X)
