AI 코딩 에이전트를 믿기 전에, Supabase Evals가 먼저 묻는 질문

핵심 요약 (TL;DR)

AI 코딩 에이전트가 ‘잘한다’는 말은 대개 멋진 데모에서 출발합니다. 그러나 제품을 만드는 사람에게 필요한 것은 그보다 훨씬 구체적인 질문입니다. 인증 설정이 꼬였을 때 복구하는지, 빈 데이터 조회의 원인을 찾는지, 로컬 환경과 실제 서비스의 차이를 이해하는지처럼 말입니다. Supabase가 공개한 Evals는 바로 이 간극을 다루는 공개 평가 저장소입니다. 핵심은 모델 이름의 순위를 외우는 일이 아니라, 내 프로젝트에도 같은 방식의 검증 장치를 두는 데 있습니다.

왜 ‘잘 만든 데모’만으로는 부족할까요?

에이전트는 같은 요청에도 도구 권한, 시작 파일, 데이터 상태, 프롬프트에 따라 전혀 다른 결과를 냅니다. 그래서 한 번 멋지게 만든 화면은 재현성과 유지보수를 보장하지 않습니다. 특히 데이터베이스와 인증이 붙은 서비스에서는 화면이 떠도 권한 정책, 마이그레이션, 엣지 함수가 틀려 있을 수 있습니다.

Supabase Evals는 평가 하나를 시나리오로 취급합니다. 각 시나리오에는 에이전트가 받는 요청, 결과를 판정하는 scorer, 그리고 필요할 때 원격 프로젝트 상태와 로컬 작업 파일이 들어갑니다. 즉 ‘이 기능을 만들어 달라’에서 끝나지 않고, 에이전트가 바꾼 결과가 실제 조건을 통과하는지 확인합니다.

어떤 작업 환경에서 시험하나요?

저장소는 MCP 도구 표면만 쓰는 평가와, Docker 샌드박스 안에서 Supabase CLI를 쓰는 로컬 스택 평가를 구분합니다. 후자의 경우 에이전트는 파일과 셸 도구를 통해 작업하고, 채점기는 작업 뒤의 워크스페이스와 실행 결과를 봅니다. 이것은 ‘모델이 답변을 그럴듯하게 했는가’가 아니라 ‘프로젝트 상태가 바뀌었는가’를 묻는 설계입니다.

최근 저장소에는 자동 평가 결과를 갱신한 커밋도 공개돼 있습니다. 다만 그 결과를 절대적인 모델 서열로 읽을 이유는 없습니다. 특정 Supabase 과제와 도구 구성에서의 관찰일 뿐입니다. 오히려 공개된 프롬프트와 scorer를 읽어 보면, 우리 서비스에서 무엇을 실패로 정의해야 하는지가 선명해집니다.

내 바이브코딩 프로젝트에는 어떻게 옮길 수 있을까요?

거창한 벤치마크부터 만들 필요는 없습니다. 먼저 사용자가 실제로 겪을 세 장면을 고르세요. 예를 들어 회원 가입 후 본인 데이터만 조회되는지, 결제 실패 뒤 주문 상태가 어긋나지 않는지, 빈 검색 결과가 오류처럼 보이지 않는지입니다. 각 장면에 시작 상태·수행 요청·통과 조건을 한 문장씩 적습니다.

그다음 에이전트에게 기능 구현을 맡긴 뒤 같은 조건을 반복 실행하세요. 테스트가 아니라 사람이 수동으로 확인해야 한다면, 확인 절차와 기대 화면도 기록해 두는 편이 좋습니다. 생성 속도를 올리는 도구일수록, ‘완료’의 기준을 사람이 먼저 설계해야 합니다.

자주 묻는 질문

이 저장소의 결과만 보고 에이전트를 골라도 될까요?

아닙니다. 공개 평가 결과는 특정 과제와 런타임에서의 참고 자료입니다. 내 서비스의 언어, 권한 구조, 배포 환경을 반영한 작은 평가를 추가해야 합니다.

바이브코더도 scorer를 만들 수 있을까요?

가능합니다. 처음에는 데이터 한 건이 생성됐는지, 권한 없는 요청이 거절되는지처럼 명확한 조건부터 시작하면 됩니다. 복잡한 점수보다 실패를 재현하는 조건이 먼저입니다.

MCP를 쓰면 평가가 필요 없을까요?

아닙니다. MCP는 도구 연결 방식입니다. 어떤 도구를 썼는지와 작업 결과가 올바른지는 별개의 문제입니다.

어떤 원문을 확인했나요?

• Supabase Evals README: https://github.com/supabase/evals
• 최근 결과 갱신 커밋: https://github.com/supabase/evals/commit/7dafe0c8