프롬프트보다 중요한 건 이제 ‘루프’다

처음 걸린 생각

“프롬프트의 시대는 가고 루프의 시대가 시작되었다.” 제목만 보면 조금 과장처럼 들린다. 프롬프트가 사라질 리는 없으니까. 그런데 영상을 끝까지 보면, 이 말은 프롬프트가 무의미해졌다는 뜻이 아니었다. 프롬프트가 채팅창의 한 줄에서 작업 시스템 안으로 들어가고 있다는 말에 가까웠다.

예전에는 AI 옆에 사람이 붙어 있었다. “이 파일 고쳐줘”, “테스트 틀렸잖아”, “문서도 업데이트해줘”처럼 계속 다음 지시를 줬다. AI가 코드를 쓰지만, 리모컨은 사람이 들고 있는 구조다.

루프는 다르다. 사람이 매번 말하는 대신, 처음에 완료 기준과 반복 조건을 정한다. 실패하면 원인을 분석하고 다시 고치고, 문서와 작업 목록을 대조하고, 마지막에는 무엇을 했는지 증거를 제출하게 한다. 프롬프트가 사라진 게 아니라, 반복 가능한 감독 장치로 바뀌는 것이다.

영상은 “프롬프트를 덜 쓴다”는 말을 대충 맡긴다는 뜻이 아니라, 일하는 층위가 올라갔다는 뜻으로 해석한다.

문제는 AI가 못해서가 아니라, 너무 좁게 보기 때문이다

영상은 일정 관리 프로그램을 예로 든다. 제품 요구사항(PRD), 기술 구조(TRD), 사용자 흐름, 데이터베이스 설계, 화면 목록, 작업 목록, 코딩 규칙까지 준비해두면 AI가 알아서 잘 만들 것처럼 보인다.

그런데 실제로는 늘 빠지는 것이 생긴다.

• 일정 생성은 되는데 수정이 안 된다.
• 수정은 되는데 삭제 후 캘린더가 갱신되지 않는다.
• 월간 보기는 있는데 주간 보기는 없다.
• 반복 일정은 PRD에는 있는데 작업 목록에는 빠져 있다.
• 화면에는 알림 시간이 있는데 DB에는 알림 필드가 없다.
• 테스트는 통과했는데 사용자 흐름으로 보면 어색하다.

이때 사람은 다시 개입한다. “PRD에 있었잖아”, “유저 플로우에는 있는데 왜 화면에 없어?”, “테스트만 통과하면 뭐해?”라고 말하게 된다.

여기서 중요한 진단은 이것이다. AI가 바보라서가 아니라, 한 번에 보는 범위가 좁기 때문이다. 작업 목록을 주면 작업 목록만 보고, 코드 파일을 주면 그 코드만 보고, 테스트가 통과하면 끝났다고 말하기 쉽다. 하지만 제품은 PRD, 화면, 데이터, 테스트, 운영 기준이 서로 맞아야 한다.

루프는 “무엇을 통과해야 끝인가”를 묻는다

“프롬프트가 채팅창에 한 줄 명령에서 작업을 반복시키는 시스템 안으로 들어간 겁니다.”

영상에서 제안하는 상위 문서는 일종의 LOOP.md다. 새 기능이나 요구사항을 더 적는 문서가 아니다. 감독관 문서다. AI가 어떤 작업을 하든 끝났다고 말하기 전에 확인해야 할 기준을 적어둔다.

예를 들면 이런 질문들이다.

• PRD를 확인했는가?
• 사용자 흐름과 맞는가?
• 화면 설계와 충돌하지 않는가?
• DB 설계에 필요한 필드가 있는가?
• 디자인 시스템과 코딩 컨벤션을 지켰는가?
• 테스트, 타입 체크, 린트, 빌드를 통과했는가?
• 그 증거를 객관적으로 제출할 수 있는가?

루프는 PRD나 작업 목록을 대체하지 않는다. 그 위에서 “진짜 완료 기준”을 계속 확인하게 만든다.

이 관점이 마음에 들었다. AI 개발에서 가장 위험한 말은 “구현 완료했습니다”일 때가 많다. 완료라는 말은 쉽지만, 완료의 증거는 어렵다. 루프는 AI에게 “무엇을 기준으로 완료라고 말했는지”를 반복해서 묻게 만드는 장치다.

좋은 루프에는 세 가지 기준이 들어간다

영상은 루프의 기준을 세 가지로 나눈다.

첫째, 필수 통과 기준이다. 빌드 성공, 타입 체크 성공, 린트 성공, 테스트 성공, 마이그레이션 성공, 보안 키 노출 없음 같은 것들이다. 이건 80점이면 통과가 아니다. 하나라도 실패하면 끝난 게 아니다.

둘째, 측정 기준이다. 테스트 커버리지, 응답 속도, 접근성 점수, 번들 크기, API 실패율처럼 숫자로 볼 수 있는 항목이다. 일정 관리 프로그램이라면 반복 일정 테스트가 있는지, 생성·수정·삭제 플로우가 자동으로 검증되는지 같은 것들이 여기에 들어간다.

셋째, 평가 기준이다. 아키텍처가 적절한지, 코드가 유지보수 가능한지, 사용자 흐름이 자연스러운지, 에러 메시지가 이해하기 쉬운지 같은 판단 영역이다. 다만 AI에게 “몇 점이야?”만 물으면 대체로 후하게 답하므로, 점수 뒤에 반드시 근거와 수정 액션을 붙이게 해야 한다.

예를 들어 “사용자 흐름 3점. 일정 생성과 삭제는 구현됐지만 수정 후 월간 캘린더가 즉시 갱신되는 흐름이 검증되지 않았다. 수정 액션: 일정 수정 후 캘린더 상태 갱신 테스트를 추가한다.”처럼 말이다. 점수보다 중요한 건 뒤에 붙은 근거와 다음 행동이다.

루프는 품질만이 아니라 사람의 병목도 줄인다

영상 후반부에서 더 흥미로웠던 건 운영 감시 루프다. AI가 PR을 올린 뒤에도 사람은 계속 GitHub를 새로고침한다. CI가 도는지, 실패했는지, 로그가 뭔지, 리뷰 댓글이 달렸는지, 충돌이 생겼는지, 배포가 성공했는지 확인한다. 코드를 짜는 건지, PR 옆에서 경비를 서는 건지 헷갈릴 때가 있다.

루프는 이 시간을 줄일 수 있다.

예를 들면 15분마다 PR 상태를 확인하고, CI가 실패하면 로그를 읽고 원인을 분류하고, 단순 린트·타입 오류는 직접 고쳐 다시 푸시하고, 리뷰 댓글 중 단순 수정은 반영하게 한다. 모든 체크가 통과하면 머지 준비 보고서를 작성하게 할 수도 있다.

다만 경계선이 필요하다. AI가 혼자 처리해도 되는 일과 반드시 사람에게 물어봐야 하는 일을 나눠야 한다.

AI가 자동 처리해도 되는 것:

• 린트 오류 수정
• 타입 오류 수정
• 단순 테스트 실패 수정
• 누락된 테스트 추가
• 문서 업데이트
• 리뷰어가 지적한 단순 네이밍 수정

사람을 호출해야 하는 것:

• DB 스키마 변경
• 데이터 손실 가능성이 있는 마이그레이션
• 인증·권한 정책 변경
• 결제·보안 관련 수정
• PRD와 충돌하는 리뷰 반영
• 기능 범위가 커지는 수정
• 테스트는 통과하지만 설계 의도가 달라지는 변경

이 경계가 없으면 루프가 아니라 사고 제조기가 된다. 영상의 표현처럼, 파스타를 만들라고 맡겼더니 주방 수도관을 뜯고 있는 상황이 생길 수 있다.

내 쪽으로 가져오면

이 영상을 보고 바로 써먹을 수 있는 건 거창한 AI 에이전트 시스템보다, 내 작업의 완료 기준을 문서화하는 일이다.

예를 들어 글을 발행하는 루프라면 이렇게 쓸 수 있다.

• 원문 또는 transcript를 읽었는가?
• 자동 초안을 그대로 발행하지 않았는가?
• 제목, 설명, 인용, 캡처가 실제 내용과 맞는가?
• 빌드가 성공했는가?
• 배포 후 라이브 URL에서 제목과 본문 일부가 확인되는가?
• 남은 리스크를 사용자에게 짧게 보고했는가?

개발 루프도 비슷하다. “테스트 돌려라”가 아니라 “실패하면 원인을 분류하고, 고칠 수 있는 범위면 고치고, 권한·데이터·제품 범위가 바뀌면 멈춰서 물어봐라”까지 들어가야 한다.

프롬프트를 잘 쓰는 사람에서, AI가 의심하고 고치고 증거를 제출하게 만드는 사람으로 역할이 이동한다.

오늘의 결론

프롬프트는 끝난 게 아니다. 다만 눈에 보이는 채팅창 밖으로 이동하고 있다. 설계 문서, 체크리스트, 테스트, 검증 보고서, PR 감시 루프 안으로 들어간다.

앞으로 중요한 사람은 AI에게 명령을 멋지게 내리는 사람만은 아닐 것이다. AI가 스스로 일하고, 스스로 의심하고, 고칠 수 있는 것은 고치고, 사람에게 물어야 할 지점에서는 멈추고, 마지막에 증거를 제출하게 만드는 사람. 말하자면 작업 시스템을 설계하는 사람이 더 중요해진다.

이 영상의 한 줄을 내 말로 바꾸면 이렇다. 좋은 프롬프트는 한 번의 답을 얻지만, 좋은 루프는 일이 끝날 때까지 AI가 계속 다시 보게 만든다.

원본 영상

• 제목: 프롬프트의 시대는 가고 루프의 시대가 시작되었다 프롬프트 안녕~
• 채널: 바이브랩스

원본 영상: 프롬프트의 시대는 가고 루프의 시대가 시작되었다 프롬프트 안녕~ · 바이브랩스