클로드에게 “이 부분 고쳐줘"만 반복하면 이미 아는 문제 안에서만 맴돈다. 수정 지시가 쌓일수록 본인이 인식하지 못한 사각지대는 그대로 남는다. 지시 대신 평가를 요청하는 방식으로 바꾸면 보이지 않던 영역이 드러난다. 어떤 직무를 맡기느냐가 결과를 가른다 클로드에게 시니어 UX 디자이너 역할을 주고 사용자 흐름을 평가하게 하면 버튼 하나 고치는 수준이 아니라 동선 전체를 다시 짚어준다. PM 관점을 줬을 때는 고객 피드백과 실제 지표를 대조하면서 우선순위를 정리해낸다. 시니어 엔지니어로 코드베이스를 리뷰시키면 성능 병목과 중복 코드를 동시에 잡는다. 역할이 구체적일수록 피드백의 밀도가 달라진다. 모든 단계를 자동화하면 비용이 튄다 에이전트를 파이프라인으로 엮어두면 그럴싸해 보인다. 전체 코드베이스를 역할별로 여러 번 읽히면 토큰 비용이 급증하고 응답 지연도 생긴다. 꼭 필요한 시점에 딱 하나의 페르소나만 부르는 게 낫다. 배포 전에 안정성이 불안하면 QA 리드만 꺼내서 에러 처리 누락을 심각도 순으로 뽑아달라고 한다. 전체를 돌리지 않아도 충분하다. QA 관점으로 한 번 더 들여다보기 기능이 돌아간다는 확인만으로는 부족하다. QA 역할을 주고 제품을 보게 하면 UI 깨짐이나 예외 처리 미비가 꽤 나온다. 혼자 보면 그냥 넘어갔을 지점들이다. 역할을 바꿔가며 같은 코드를 들여다보는 과정이 바이브코딩의 기술 부채를 줄이는 실질적인 방법이다. 전문가 역할을 부여한 평가 요청이 단순 수정 지시보다 잠재 결함을 더 많이 잡아냄 전체 자동화 파이프라인보다 필요한 시점에 특정 페르소나 하나만 호출하는 편이 토큰 비용을 아낌 QA 리드 페르소나로 엣지 케이스를 검증하면 기능 구현 이후 쌓이는 기술 부채를 줄일 수 있음