클로드에게 “이 부분 고쳐줘"만 반복하면 이미 아는 문제 안에서만 맴돕니다. 수정 지시가 쌓일수록 본인이 인식하지 못한 사각지대는 그대로 남습니다. 지시 대신 평가를 요청하는 방식으로 바꾸면 보이지 않던 영역이 드러납니다.

어떤 직무를 맡기느냐가 결과를 가릅니다

클로드에게 시니어 UX 디자이너 역할을 주고 사용자 흐름을 평가하게 하면 버튼 하나 고치는 수준이 아니라 동선 전체를 다시 짚어줍니다. PM 관점을 줬을 때는 고객 피드백과 실제 지표를 대조하면서 우선순위를 정리해냅니다.

시니어 엔지니어로 코드베이스를 리뷰시키면 성능 병목과 중복 코드를 동시에 잡습니다. 역할이 구체적일수록 피드백의 밀도가 달라집니다.

모든 단계를 자동화하면 비용이 튑니다

에이전트를 파이프라인으로 엮어두면 그럴싸해 보입니다. 전체 코드베이스를 역할별로 여러 번 읽히면 토큰 비용이 급증하고 응답 지연도 생깁니다.

꼭 필요한 시점에 딱 하나의 페르소나만 부르는 게 낫습니다. 배포 전에 안정성이 불안하면 QA 리드만 꺼내서 에러 처리 누락을 심각도 순으로 뽑아달라고 합니다. 전체를 돌리지 않아도 충분합니다.

QA 관점으로 한 번 더 들여다보기

기능이 돌아간다는 확인만으로는 부족합니다. QA 역할을 주고 제품을 보게 하면 UI 깨짐이나 예외 처리 미비가 꽤 나옵니다. 혼자 보면 그냥 넘어갔을 지점들입니다.

역할을 바꿔가며 같은 코드를 들여다보는 과정이 바이브코딩의 기술 부채를 줄이는 실질적인 방법입니다.

  • 전문가 역할을 부여한 평가 요청이 단순 수정 지시보다 잠재 결함을 더 많이 잡아냄
  • 전체 자동화 파이프라인보다 필요한 시점에 특정 페르소나 하나만 호출하는 편이 토큰 비용을 아낌
  • QA 리드 페르소나로 엣지 케이스를 검증하면 기능 구현 이후 쌓이는 기술 부채를 줄일 수 있습니다.