GAIA PortfolioSTAR 보기

AI GUI QA Automation Runtime

실패를 숨기지 않고, 실행 가능한 QA 런타임으로 바꾼 프로젝트

GAIA는 자연어 QA 목표를 받아 브라우저 화면을 의미 단위로 해석하고, 단계별 행동과 증거를 누적해 최종 성공 여부를 검증하는 AI 기반 GUI QA 자동화 시스템입니다.

개발 히스토리이력서 문장
개발 기간2025-2026

초기 MCP 실험부터 live demo까지

최신 회귀26/30

0 agent FAIL · 4 external/time blockers

검증 범위35 sites

173 public scenarios manifest

핵심 구조4-layer

Actor, action, ledger, judge

성공했던 지점

단순 클릭 봇이 아니라 검증 가능한 runtime으로 만들었다

  • 자연어 QA 목표를 role/ref 기반 action contract로 실행
  • LLM 자기 보고를 그대로 믿지 않고 evidence-based judge로 재검증
  • 실패 원인을 stale ref, no-state-change, bot-wall, auth gate 등으로 분리
  • PySide6 앱, Vercel board, Supabase Realtime을 연결한 현장 시연 시스템 구축
실패했던 지점

실패가 설계 방향을 바꿨다

보이는 버튼이 클릭되지 않았다

DOM상 visible인 요소라도 overlay가 pointer event를 가로채면 실행은 실패했다. 이후 visible과 actionable을 분리해 reason code와 실패 ref를 남겼다.

LLM이 이미 끝난 상황에서도 wait을 골랐다

actor가 자기 상태를 잘 모른다는 걸 확인했다. step별 action result, state change, screenshot evidence를 ledger에 남기고 judge가 완료 여부를 다시 보게 했다.

특화 로직이 범용성을 망쳤다

특정 사이트 성공률을 올리는 site-specific check를 넣었다가 runtime이 케이스 모음으로 변했다. 이후 filter/read-only 특화 경로를 삭제하고 범용 contract로 되돌렸다.

웹 점수판 결과가 서로 다른 실행끼리 섞였다

처음에는 scenario 단위로 묶어 같은 케이스를 여러 사람이 실행하면 기록이 섞였다. battleRunId를 도입해 실행 단위로 Human/GAIA 결과를 연결했다.

Commit-derived history

처음부터 잘 만든 게 아니라, 계속 갈아엎으며 수렴했다

단순 merge/README 커밋은 묶고, 구조가 바뀐 전환점 커밋 기준으로 before, failure signal, after를 정리했습니다.

2025.10

전용 browser automation host 분리

Before
server/main.py 중심의 섞인 구조
After
MCP host와 LLM vision agent 구조
9bf251b6, e5d54c54
2026.01-02

role/ref 실행 계약 도입

Before
selector, vision 중심 판단
After
Role Tree snapshot과 ref action contract
8e35a315, 167311d7
2026.04

특화 로직 삭제

Before
site/filter/read-only 특수 경로
After
generic runtime과 evidence-based verification
e38542fc, b12a09ec, d4e72b1b
2026.05

benchmark와 dashboard artifact화

Before
수동 성공 사례와 산발 로그
After
manifest, runner, Grafana, fail reason dashboard
1c95ebed, 286e9eab, 59787253
2026.05-06

Human vs GAIA live demo 완성

Before
CLI/GUI 결과가 현장 참여 경험과 분리
After
Vercel board, Supabase Realtime, run-scoped records
df4a3eab, ef2af956, 9a32400d
STAR troubleshooting

면접에서 바로 말할 수 있는 디버깅 스토리

01

KakaoMap actionability failure

Situation

스카이뷰 버튼이 보이는데 클릭이 반복 실패했다.

Action

LLM 판단, stale ref, browser actionability를 분리해 분석하고 pointer interception을 reason code로 보존했다.

Result

문제를 모델 오류가 아니라 runtime 진단 문제로 재정의해 같은 ref 반복 loop를 줄였다.

02

Multi-call Context Ledger

Situation

LLM API를 여러 번 호출하면 이전 실패와 증거 맥락이 끊겼다.

Action

action result, state change, screenshot, text evidence, judge result를 step ledger로 묶었다.

Result

단일 프롬프트가 아니라 하나의 QA 실행 상태로 판단을 이어가게 만들었다.

03

특화 fallback 제거

Situation

특정 사이트를 맞추는 로직이 늘어날수록 범용성이 떨어졌다.

Action

site-specific completion, read-only special path, filter semantic validator를 삭제하고 generic rule로 회귀했다.

Result

성공률을 예쁘게 보이는 패치보다 설명 가능한 runtime 구조를 선택했다.

04

Live battle run grouping

Situation

같은 시나리오를 여러 사람이 실행하면 이전 기록과 새 기록이 섞였다.

Action

battleRunId를 도입하고 Human/GAIA record를 execution 단위로 묶었다.

Result

현장 운영 방식과 데이터 모델이 맞아져 점수판 신뢰도가 올라갔다.

Core architecture

Multi-call Context Ledger

Actor Call
Action Result
Evidence Memory
Judge Call

하나의 긴 프롬프트가 아니라, step별 LLM 호출을 하나의 QA 실행 상태로 묶어 이전 action, 실패 feedback, screenshot evidence, 현재 DOM을 계속 이어갑니다.

Resume-ready bullets

이력서에 바로 옮길 수 있는 문장