클릭 전에 코드를 읽는 QA 에이전트 Sentinel — 버그는 UI 뒤에 숨어 있다 (blog.simbastack.com)

한줄 요약

코드를 읽고 비즈니스 플로우를 스스로 도출하는 QA 에이전트 Sentinel이 MIT 라이선스로 공개됐다.

---

무엇이 달라지나?

대부분의 AI 테스트 도구는 브라우저를 열고 버튼을 클릭하며 화면을 스캔한다. 레이아웃 깨짐이나 콘솔 에러 정도는 잡아내지만, 그게 한계다. 서버에 실제로 데이터가 저장됐는지, 상태 머신이 올바르게 전이됐는지는 UI만 보고는 알 수 없다.

Sentinel은 접근 방식 자체가 다르다. 테스트를 실행하기 전에 저장소를 먼저 읽는다. grep과 find 기반의 결정론적 분석으로 프론트엔드 라우트, API 엔드포인트, 서비스 레이어, DB 엔티티 구조를 추출한 뒤, 이 다이제스트를 바탕으로 모델이 비즈니스 플로우를 도출한다. 코드를 이해한 다음 테스트를 설계하는 방식이다.

실제 데모에서 이 차이가 잘 드러난다. Next.js 프론트엔드와 별도 API 서버, Postgres DB로 구성된 호텔 PMS에 저장소와 관리자 크레덴셜만 넘겼더니, Sentinel은 스스로 예약 전체 라이프사이클, 그룹 예약, 요금 관리, 야간 감사, 결제-청구서-환불 흐름 등 9개의 핵심 비즈니스 플로우를 도출해냈다. 테스트 계획서는 아무것도 제공하지 않았다.

실무에서 어떤 의미인가?

Sentinel이 실제로 찾아낸 버그들을 보면, 왜 백엔드 검증이 필요한지 바로 이해된다.

예약 확정 API가 NO_AVAILABILITY를 반환했는데, 해당 예약이 이미 그 객실을 점유하고 있는 상황이었다. UI는 때로는 "객실 없음" 토스트를 보여주고, 때로는 아무 피드백도 없이 조용히 실패했다. 백엔드 상태 머신의 버그였고, 화면만 봐서는 절대 재현할 수 없다.

캘린더에는 이미 예약된 객실이 가용 상태로 표시됐다. API 응답과 UI 표시가 서로 달랐던 것인데, 두 레이어를 동시에 확인하지 않으면 잡을 수 없는 종류의 버그다.

체크인 API가 200을 반환했지만 서버에서 해당 게스트의 registrationStatus는 여전히 NONE이었다. 상태 전이가 절반만 완료된 채 멈춘 것으로, 화면에는 정상으로 보인다.

이런 버그들은 개발 외주나 내부 개발을 막론하고 QA 단계에서 놓치기 쉬운 유형이다. 프론트엔드가 "성공한 것처럼" 보이는 응답을 받으면 테스터도 사람도 넘어가기 쉽다. Sentinel은 매 스텝마다 api_request 툴을 통해 실제 서버 상태를 직접 확인한다. 브라우저가 보내는 Authorization 헤더를 그대로 재사용해 페이지 내부에서 fetch를 실행하는 방식으로, 별도 인증 설정 없이 백엔드를 검증한다.

플로우는 기본적으로 두 번씩 실행된다. AI 에이전트는 비결정론적이기 때문에 같은 플로우라도 한 번은 버그를 못 잡고 다른 한 번에 잡는 경우가 있다. 두 시도의 결과를 합산해 더 나쁜 판정을 최종 리포트에 반영하는 구조다. 하드 버짓도 있다. 90번의 툴 호출을 넘기면 액션 툴이 동작을 거부하고 finish만 남긴다.

시각적 검사도 별도 레이어로 존재한다. 에이전트가 방문한 각 화면(URL 기준 중복 제거, 기본 최대 8개)에 대해 멀티모달 모델이 시각적 계층 구조, 여백, WCAG 대비 기준 위반 가능성, 타이포그래피, 깨진 상태 등을 평가한다. DOM 기반 검사로는 볼 수 없는 레이어다.

플로우 계획은 커밋 단위로 캐시된다. 코드가 바뀌지 않으면 재도출하지 않고, 변경이 생기면 그때 다시 분석한다. 15분마다 실행되는 스케줄러가 각 저장소를 확인하고, 새 커밋에는 코드 리뷰 에이전트가, 주기적으로는 QA 에이전트가 돌아간다.

현재 지원 스택은 Next.js 라우트, Express·Fastify 라우트 모듈, Prisma·Drizzle·일반 SQL 스키마다. 다른 스택은 recon 패치 수준의 작업으로 확장 가능하다고 밝히고 있다.

도입 전 체크포인트

Sentinel은 아직 초기 단계의 오픈소스 프로젝트다. 실제 적용을 검토한다면 몇 가지를 먼저 점검해야 한다.

지원 스택 확인이 먼저다. recon 엔진이 JS 생태계 중심으로 설계돼 있다. Python, Go, Java 등 다른 백엔드 스택은 직접 recon 로직을 작성해야 한다.

테스트 환경 격리가 필수다. 에이전트가 실제 예약, 결제, 상태 변경을 직접 실행한다. 프로덕션 DB에 연결하면 안 된다. 별도 테스트 테넌트와 격리된 환경이 없으면 시작하기 어렵다.

비결정성을 이해하고 써야 한다. 두 번 실행해도 버그를 모두 잡는다는 보장은 없다. 결과를 신뢰하려면 반복 실행 횟수와 판정 기준을 팀이 직접 조율해야 한다.

모델 의존성도 변수다. Sentinel은 현재 Mimo(Xiaomi 모델)를 결정 엔진으로 사용한다. 모델 교체가 어느 정도까지 가능한지는 코드를 직접 확인해야 한다.