개요
“프롬프트 잘 쓰는 법”에 집착하던 시대가 저물고, 이제는 AI가 스스로 일하고 검증하도록 만드는 “루프”를 설계하는 시대로 넘어가고 있다는 이야기를 다룹니다. 클로드를 만든 회사 앤트로픽의 개발자들이 이제 프롬프트를 거의 쓰지 않는다는 말의 진짜 의미를, 일정 관리 프로그램이라는 친숙한 예시로 풀어냅니다. 핵심은 사람이 매번 다음 명령을 내리는 리모컨 방식에서, AI가 기준을 통과할 때까지 스스로 반복하고 증거를 제출하는 작업 시스템 설계로 일하는 층위가 한 단계 올라갔다는 점입니다.
이 영상은 AI 개발과 바이브 코딩을 주제로 다루는 콘텐츠로, 앤트로픽 개발자 보리스 천이의 발언을 출발점으로 삼아 실무 관점에서 루프 설계의 개념을 차근차근 설명합니다.
핵심 내용
프롬프트를 안 쓴다는 말의 진짜 의미
영상은 앤트로픽 개발자들이 프롬프트를 거의 안 쓴다는 이야기에서 출발합니다. 화자도 과거에 “존 프롬프트 백선” 같은 것을 모아두며 꽤 집착했다고 고백합니다. 그런데 보리스 천이는 “내가 클로드 코드에게 계속 프롬프트 하는 게 아니라 클로드가 스스로 프롬프트하게 내버려 둔다”라고 말하며, 영어로는 “그냥 요리하게 놔둬라(Ready, cook)”는 표현을 씁니다.
처음 들으면 무책임하게 들리지만 실제 의미는 반대에 가깝습니다. 프롬프트를 덜 쓴다는 건 일을 대충 한다는 뜻이 아니라, 오히려 일하는 층위가 한 단계 올라갔다는 뜻입니다.
리모컨 방식 vs 루프 방식
예전에는 사람이 AI 옆에 앉아 “이 파일 고쳐 줘”, “테스트 잘못됐잖아 다시 해”, “문서 업데이트 해 줘”, “구현해야 할 항목이 빠졌잖아”처럼 계속 다음 명령을 줬습니다. AI가 코드를 쓰긴 하지만 실제로는 사람이 리모컨을 들고 계속 채널을 바꾸는 구조였습니다.
루프 방식은 다릅니다. 사람이 매번 말로 지시하는 게 아니라 처음에 이렇게 정합니다. “이 목표를 달성할 때까지 반복해라”, “이 기준을 통과하기 전까지는 완료라고 말하지 마라”, “테스트가 실패하면 원인을 분석하고 다시 고쳐라”, “마지막에는 네가 무엇을 했는지 증거 보고서를 제출해라.” 프롬프트가 사라진 게 아니라, 채팅창의 한 줄 명령에서 작업을 반복시키는 시스템 안으로 들어간 것입니다. 예전의 프롬프트가 명령어였다면 지금의 루프는 작업 감독관입니다.
일정 관리 프로그램으로 보는 한계
영상에서는 일정 관리 프로그램을 예로 듭니다. 간단해 보이지만 실제로는 무척 복잡합니다. 보통 제품 요구 사항을 적는 문서, 기술 구조를 적는 TRD, 유저 플로우, 데이터베이스 디자인, 스크린, 테스크스(페이지·테스크 단위 개발 순서), 코딩 컨벤션까지 만들어 둡니다.
문서와 작업 목록이 다 있으니 AI에게 프롬프트만 던지면 알아서 작업 계획을 세우고 검증까지 해줄 것 같습니다. 그런데 실제로 시켜보면 항상 뭔가 빠집니다. 일정 생성은 되는데 수정이 안 되고, 삭제 후 캘린더가 자동 갱신되지 않고, 월간 보기는 있는데 주간 보기는 없고, 반복 일정은 PRD에 설계됐는데 테스크스에는 누락되고, 화면에는 알림 시간이 있는데 DB에는 알림 필드가 없는 식입니다. AI가 바보라서가 아니라 문제를 한 번에 너무 좁게 보기 때문입니다. 테스크스를 주면 테스크스만 보고, 테스트를 통과하면 끝났다고 쉽게 생각합니다.
설계 꼭대기의 감독관, 루프.md
그래서 필요한 것이 상위 루프입니다. 설계의 가장 꼭대기층에 ‘루프.md’라는 문서를 하나 만들어 둡니다. 이 문서는 새로운 기능이나 요구 사항을 담지 않습니다. 그저 감독관 역할을 합니다.
이 문서가 하는 일은 단순합니다. 어떤 테스크를 하든 끝났다고 말하기 전에 PRD를 확인했는지, 유저 플로우와 맞는지, 스크린에 반영됐는지, DB 설계와 충돌하지 않는지, 디자인 시스템을 지켰는지, 테스크스에 언급된 사항을 빠뜨리지 않았는지, 코딩 컨벤션을 따랐는지, 테스트·타입체크·린트·빌드를 통과했는지, 그리고 그 증거를 객관적으로 제출할 수 있는지를 다시 확인하게 합니다.
중요한 건 루프가 기존 설계 문서를 대체하지 않는다는 점입니다. PRD, TRD, 테스크스, TDD, 서브 에이전트, 워크트리는 여전히 필요하고, 그 위에 루프가 하나 더 올라갑니다. PRD가 “무엇을 만들 것인가”, 테스크스가 “어떤 순서로 만들 것인가”를 말한다면, 루프는 “무엇을 통과해야 진짜 끝났다고 볼 것인가”를 묻습니다. 영상은 AI 개발에서 가장 위험한 문장이 “구현 완료했습니다”라고 지적합니다. 완료했다는 말은 쉽지만 문제는 증거이기 때문입니다.
루프의 세 가지 기준: 필수·측정·평가
루프에는 보통 세 가지 기준이 들어갑니다.
첫 번째는 필수 통과 기준입니다. 통과 아니면 실패로, 빌드 성공·타입체크 성공·린트 성공·테스트 성공·마이그레이션 성공·보안 키 노출 없음 등이 해당합니다. 80점이면 통과하는 식이 아니라 하나라도 실패하면 끝난 게 아닙니다.
두 번째는 측정 기준입니다. 숫자로 측정할 수 있는 기준으로 테스트 커버리지, 응답 속도, 접근성 점수, 번들 크기, 에러 로그, API 실패율 등입니다. 일정 관리 프로그램이라면 날짜 계산 유틸 테스트가 있는지, 반복 일정 테스트가 있는지, 일정 생성·수정·삭제 플로우가 자동으로 검증되는지를 봐야 합니다.
세 번째는 평가 기준입니다. 사람이 보던 판단 기준을 AI에게 맡기는 영역으로, 아키텍처가 적절한가·코드가 유지보수 가능한가·사용자 흐름이 자연스러운가·에러 메시지가 이해하기 쉬운가·작업 범위를 넘어서지 않았는가 등을 1점부터 5점까지 평가하게 할 수 있습니다.
다만 조심해야 합니다. AI에게 그냥 몇 점이냐고 물으면 대체로 후하게, 자기가 한 일에 좋은 점수를 줍니다. 그래서 점수만 쓰게 하면 안 되고 반드시 점수 뒤에 근거를 쓰게 해야 합니다. 예를 들어 “유저플로우 3점 — 일정 생성과 삭제 흐름은 구현됐지만 수정 후 월간 캘린더가 즉시 갱신되는 흐름이 검증되지 않았다. 수정 후 캘린더 상태 갱신 테스트를 추가한다”처럼 써야 합니다. 점수가 중요한 게 아니라 점수 뒤에 붙은 근거와 수정 액션이 중요합니다.
사람의 병목을 줄이는 운영 감시 루프
지금까지의 루프가 품질을 끌어올리는 루프라면, 또 하나는 사람의 병목을 줄이는 루프입니다. AI가 반복 일정 기능을 구현하고 깃허브에 PR을 올렸다고 해보면, 보통 사람은 PR이 열렸는지, CI가 도는지, 테스트가 실패했는지, 실패 로그는 무엇인지, 리뷰 댓글이 달렸는지, 메인 브랜치와 충돌이 생겼는지, 배포가 성공했는지를 일일이 확인해야 합니다. 개발을 하는 건지 옆에서 경비를 서는 건지 헷갈릴 때가 많습니다.
루프를 걸면 달라집니다. “15분마다 PR 상태를 확인해라”, “CI가 실패하면 로그를 읽고 원인을 분류해라”, “단순 린트 오류나 타입 오류면 직접 고쳐서 다시 푸시해라”, “리뷰 댓글 중 단순 수정은 반영해라”, “DB 구조 변경·권한 정책 변경·제품 방향 변경이 필요한 댓글은 사람에게 질문해라”, “모든 체크가 통과하면 머지 준비 보고서를 작성해라”처럼 정할 수 있습니다. 이것이 운영 감시 루프입니다. AI가 PR을 지켜보다가 고칠 수 있는 건 고치고 사람이 판단해야 할 것만 가져옵니다.
자동 처리와 사람 호출의 경계선
여기서도 경계선은 필요합니다. 자동으로 처리해도 되는 것은 린트 오류 수정, 타입 오류 수정, 단순 버그 수정, 누락된 테스트 추가, 문서 업데이트, 리뷰어가 지적한 단순 네이밍 수정 등입니다. 반대로 반드시 사람에게 물어봐야 하는 것은 DB 스키마 변경, 데이터 손실 가능성이 있는 마이그레이션, 인증과 권한 정책 변경, 결제와 보안 관련 수정, PRD와 충돌하는 리뷰 반영, 기능 범위가 커지는 수정, 테스트는 통과하지만 설계 의도가 달라지는 변경 등입니다.
영상은 이 경계가 없으면 루프가 아니라 사고 제조기가 될 수 있다고 경고합니다. “요리하게 놔뒀더니 갑자기 주방을 열심히 리모델링하고 있는” 셈으로, 파스타를 만들라고 했더니 수도관을 뜯는 일이 벌어질 수 있다는 비유를 듭니다. 그래서 좋은 루프에는 자동 처리 기준과 인간 호출 기준이 함께 있어야 합니다.
실전 가이드
영상의 내용을 실제로 적용하려면 다음 과정을 따라해볼 수 있습니다.
먼저 기존 설계 문서를 점검하는 것부터 시작합니다. PRD, TRD, 유저 플로우, DB 디자인, 스크린, 테스크스, 코딩 컨벤션이 갖춰져 있는지 확인합니다. 이 단계는 루프를 얹기 위한 토대이며, 문서들이 서로 일관되는지 대조하는 작업이 핵심입니다.
다음으로 설계 꼭대기에 ‘루프.md’ 감독관 문서를 만듭니다. 여기에는 “끝났다고 말하기 전에 PRD·유저플로우·스크린·DB·테스크스·컨벤션·테스트를 다시 확인하고 증거를 제출하라”는 점검 항목을 정의합니다. 이때 필수 통과 기준(빌드·타입체크·린트·테스트·마이그레이션·보안), 측정 기준(커버리지·응답 속도·실패율 등), 평가 기준(1~5점과 반드시 근거·수정 액션 포함)을 함께 넣는 것이 좋습니다.
마지막으로 운영 감시 루프를 추가합니다. PR 상태를 주기적으로 확인하고, 자동 처리할 수 있는 것(린트·타입·단순 버그·문서·네이밍)과 사람에게 반드시 물어야 하는 것(DB 스키마·마이그레이션·인증/권한·결제/보안·범위 확대)의 경계선을 명확히 정의합니다. 이 경계선이 제대로 작동하는지를 성공 지표로 삼아 점검합니다.
비판적 검토
영상은 “프롬프트를 안 쓴다”는 다소 자극적인 명제를 명확한 개념(루프 설계)으로 풀어내고, 일정 관리 프로그램이라는 누구나 떠올릴 수 있는 예시로 추상적인 이야기를 구체화한 점이 인상적입니다. 특히 평가 점수에 반드시 근거와 수정 액션을 붙이게 하는 부분, 그리고 자동 처리와 사람 호출의 경계선을 구분하는 부분은 실무에서 바로 적용할 만한 통찰입니다.
다만 영상은 개념과 원칙 중심이라, 루프.md를 실제로 어떻게 작성하고 도구에서 어떻게 동작시키는지에 대한 구체적인 구현 화면은 다루지 않습니다(영상 말미에 다음 영상에서 실제 화면으로 구현해 보이겠다고 예고합니다). 실무에 적용하실 분들은 자신의 프로젝트에 맞는 필수·측정·평가 기준을 직접 정의하고, 자동 처리 권한을 어디까지 줄지에 대한 팀 차원의 합의를 함께 검토하시길 권장합니다.
핵심 요점
영상을 본 후 기억해야 할 다섯 가지:
- 프롬프트는 사라진 게 아니라 보이지 않는 곳으로 들어갔습니다. 채팅창의 한 줄 명령이 설계 문서·루프·테스트·검증 보고서 안으로 이동한 것이며, 일하는 층위가 한 단계 올라간 것입니다.
- 리모컨 방식(매번 다음 명령)에서 루프 방식(기준을 통과할 때까지 스스로 반복하고 증거 제출)으로 전환하는 것이 핵심입니다. AI 개발에서 가장 위험한 문장은 증거 없는 “구현 완료했습니다”입니다.
- 루프는 기존 설계 문서를 대체하지 않고 그 위에 얹힙니다. PRD가 “무엇을”, 테스크스가 “어떤 순서로”를 말한다면 루프는 “무엇을 통과해야 진짜 끝인가”를 묻는 감독관입니다.
- 좋은 루프에는 세 가지 기준(필수 통과·측정·평가)이 들어가며, 평가 점수는 반드시 근거와 수정 액션과 함께 작성하게 해야 후하게 매기는 편향을 막을 수 있습니다.
- 운영 감시 루프로 사람의 병목(PR 확인·CI 로그·배포 대기)을 줄이되, DB 스키마·인증/권한·결제/보안·범위 확대처럼 사람이 반드시 판단해야 하는 경계선을 정의해야 루프가 사고 제조기가 되지 않습니다.
참고자료
영상에서 언급된 자료와 더 깊이 있는 학습을 위한 출처들:
- 앤트로픽 개발자 보리스 천이의 “클로드가 스스로 프롬프트하게 내버려 둔다 / Ready, cook” 발언 (영상 내 인용)
- 루프.md 감독관 문서 개념 및 세 가지 기준(필수·측정·평가) (영상 설명)
- 운영 감시 루프(PR 상태 점검·CI 수정·리뷰 반영·머지 준비 보고서)와 자동 처리/사람 호출 경계선 (영상 설명)