Computer Use를 활용한 바이브 코딩 앱 사용성 테스트: 정적 린터를 넘어 에이전트 동적 QA와 자율 PR 완결까지

Computer Use를 활용한 바이브 코딩 앱 사용성 테스트: 정적 린터를 넘어 에이전트 동적 QA와 자율 PR 완결까지

출처 및 참고: 디자이너이자 앱 빌더인 Eric Park의 실전 연구 및 커뮤니티 인사이트를 바탕으로, 자율 AI 에이전트(GPT-6 Astra High, Claude Fable 5.1 High 등)의 Computer Use(브라우저·데스크톱 제어) 프리미티브를 프로덕션 프론트엔드 사용성 테스트(UT) 및 자율 QA 파이프라인으로 체계화한 엔지니어링 포스트입니다.

---

1. 바이브 코딩의 검증 공백: "코드를 보는 것"과 "화면을 만져보는 것"의 간극

자연어 프롬프트와 LLM 코딩 에이전트의 결합인 바이브 코딩(Vibe Coding)은 소프트웨어 개발 속도를 유례없이 단축시켰습니다. 기획 아이디어를 몇 줄의 텍스트로 던지면 수 분 만에 풀스택 웹 애플리케이션 프로토타입이 동작합니다.

그러나 이 폭발적인 속도의 이면에는 심각한 검증 공백(Verification Void)이 존재합니다. 빌더가 생성된 수천 줄의 코드베이스와 세부 엣지 케이스를 직접 한 줄 한 줄 검토하지 않은 채 배포하기 때문입니다.

[바이브 코딩의 검증 딜레마]

자연어 기획서(PRD) ──▶ LLM 코딩 에이전트 ──▶ 초고속 코드 생성 ──▶ 동작은 하지만...?
                                                                │
  ┌─────────────────────────────────────────────────────────────┴─────────────────────────────┐
  ▼                                                                                           ▼
[정적 코드 검증의 한계]                                                          [기존 E2E 테스트의 한계]
- PRD 대조 린팅: 명세 누락만 잡음                                               - Happy Path 시나리오만 검증
- 렌더링된 실제 DOM 높이·위치 모름                                              - 비정상 조작 순서나 당혹감 미반영
- 미디어쿼리 줄바꿈 및 스크롤 트랩 감지 불가                                     - 시각적 레이아웃 파편화 포착 불가

기존의 자동화 검증은 주로 두 가지 방식에 머물렀습니다:
1. 기획서(PRD) 대조 코드 정적 린팅: 요구사항 명세서와 소스코드를 비교하여 누락된 로직을 찾는 방식입니다. 하지만 실제 브라우저 뷰포트 크기 변화, CSS 인터랙션, 타이밍 이슈는 감지하지 못합니다.
2. 단위 및 E2E 테스트 스크립트 (Playwright, Cypress 등): 개발자가 미리 가정한 정상 경로(Happy path)만을 기계적으로 반복할 뿐, 실제 사용자가 화면을 마주했을 때 겪는 인지적 혼란이나 기괴한 인터랙션을 재현하지 못합니다.

결국 프로덕션 배포 전, 인간 빌더가 직접 화면의 모든 버튼을 누르고 반응형 크기를 줄여보는 고통스러운 수동 QA(Manual Click Testing)를 수행해야 했습니다.

여기서 등장한 패러다임이 바로 "에이전트 인-더-루프 사용성 테스트(Agentic Usability Testing)"입니다. 고수준 인지 추론과 Computer Use(OS/브라우저 직접 조작) 능력을 갖춘 최신 에이전트에게 실제 사용자 역할을 부여하고, 화면을 직접 터치하며 발견한 버그를 코드 수정 PR까지 자율 완결하게 만드는 것입니다.

---

2. 실전 테스트 환경: BlindChoice 배틀그라운드

실제 프로덕션 환경에서 Computer Use 에이전트의 QA 역량을 실측하기 위해, 웹 서비스 BlindChoice(blind-test-b4u.pages.dev)를 대상으로 테스트를 진행했습니다.

+-----------------------------------------------------------------------------------+
| BlindChoice 서비스 개요                                                           |
| 사용자가 어떤 AI 모델이 만든 것인지 모른 상태에서 동일한 기획 과제에 대해       |
| 각 모델이 디자인/구현한 인터랙티브 웹 화면을 직접 써보고 블라인드 투표하는 서비스|
+-----------------------------------------------------------------------------------+

• 대결 과제: "옷장 속 아기옷, 한눈에 정리해요" (아기옷장 관리 UI 디자인 및 프로토타입 구현)
• 대결 모델 A: Claude Fable 5.1 High (소요 시간 10분 36초, 도구: Mobbin MCP, 힉스필드 MCP, 21st.dev MCP)
• 대결 모델 B: GPT-6 Astra High (소요 시간 14분 46초, 입력 토큰 1,597,926 / 출력 토큰 24,3xx)

테스트 지시 프롬프트

빌더는 복잡한 테스트 시나리오 대신, 실제 사용자의 눈높이를 가진 짤막한 자연어 지시만을 주입했습니다:

"사용자 테스트를 해보자. 여기는 AI 모델이 디자인을 잘하는지 사용자가 블라인드 테스트하는 곳인데, 
너가 사용자가 되었다고 생각하고 한번 진행해보고, 개선점이나 버그가 잡히면 알려줘. 
computer use 스킬을 사용해."

이 단 한 줄의 프롬프트로 에이전트는 브라우저를 띄우고, 마우스 커서를 움직여 클릭과 휠 스크롤을 수행하며 인간 사용자의 탐색 과정을 시뮬레이션하기 시작했습니다.

---

3. 에이전트가 포착한 실전 결함: P0부터 P1까지

놀랍게도 Computer Use 에이전트들은 단순한 시각적 흠집을 넘어, 제품의 핵심 비즈니스 규칙을 파괴하는 치명적인 결함(P0)과 인터랙션 마찰(P1)을 정밀하게 적발해 냈습니다.

🔍 클릭하여 확대

flowchart TD
    User["인간 빌더 (자연어 사용자 테스트 지시)"] --> Agent["Computer Use 활성화 에이전트\n(Astra High / Fable 5.1 High)"]
    Agent --> Actions["화면 상호작용\n- 클릭, 스크롤, 탭 전환, 키보드 입력"]
    Actions --> Blocked{"동작 멈춤 / 이상 징후 포착"}

    Blocked --> BugP0["P0 결함: 제품 약속 붕괴\n- 미탐색 100% 오인식 & 투표 조기 잠금 해제\n- 1명 표본 승패 노출 (5명 규칙 위반)\n- 투표 직후 빈 박스 (Empty State 누락)"]
    Blocked --> BugP1["P1 결함: 레이아웃 & 조작 마찰\n- 886px 투표 바 2줄 잘림\n- 라우팅 전환 시 스크롤 위치 보존\n- 카드 스택 휠 하이재킹 (스크롤 트랩)"]
    Blocked --> ToolLimit["도구 한계 포착 & 인간 핸드오프\n- '길게 누르기(Long-press)' 미지원\n- Enter/Space 미반응 시 사용자에게 조작 요청"]

    BugP0 --> Report["우선순위별 체계적 버그 보고서 도출\n(P0 / P1 / P2, 재현 경로, 해결책)"]
    BugP1 --> Report
    Report --> PR["코드베이스 직접 추적 및 수정 PR 자율 생성\n(Fable 5.1: blind-test main +20 -3)"]
  

3.1. P0 결함: 제품 핵심 약속 및 데이터 무결성 붕괴

1) 스크롤 판정 로직 결함: 보지도 않았는데 100% 탐색 오판

• 현상: BlindChoice는 "두 후보의 화면을 충분히 비교한 뒤 투표한다"는 전제를 지키기 위해, 화면을 스크롤하여 일정 비율 이상 탐색해야 투표 버튼이 잠금 해제되도록 설계되어 있었습니다.
• 버그: 그러나 비교 뷰어에서 "B 크게 보기" 모드로 전환하는 순간, 실제로는 스크롤을 단 1px도 내리지 않았음에도 B 100% 봤어요로 판정되었습니다. 그 결과 A 후보를 겨우 11%만 본 상태에서도 하단 투표 버튼이 즉시 활성화되어 버렸습니다.
• 원인 분석: 렌더링 높이가 0이거나 화면에 아직 마운트되지 않은 가상 DOM 요소의 높이를 탐색률 계산 분모에 그대로 합산하면서 분자가 100%로 튀어버리는 계산 결함이었습니다.

2) 표본 수 규칙 위반: 단 1명의 투표로 승패 확정 노출

• 현상: 서비스 규칙상 "최소 5명 이상 투표 후 결과 공개"라는 집계 정책을 명시하고 있었습니다.
• 버그: 그러나 과거 대결 목록(/past) 및 마이페이지(/me) 카드에서는 단 1명의 표본만 투표했음에도 "A 100% · 승"으로 승패가 버젓이 노출되었습니다. 청첩장 과제에서는 "A 0% · A 모델 승"이라는 모순된 데이터와 참여자 수 불일치(1명 vs 2명)가 발견되었습니다.
• 에이전트 제안: 5표 미만의 데이터는 카드 목록에서도 집계 중 상태로 마스킹하고, 동률 및 소수 표본에 대한 무승부 산식 규정을 명문화할 것을 요구했습니다.

3) Empty State 누락: 투표 직후 나타난 휑한 빈 상자

• 현상: 사용자가 투표와 선택 이유를 입력하고 제출한 직후 나타나는 결과 화면에서 "다른 사람들은 이렇게 말했어요" 피드 영역이 아무런 안내 문구 없이 완전히 비어 있는 박스(Empty Container)로 렌더링되었습니다.
• 에이전트 제안: 등록된 의견이 0건일 때 "아직 등록된 의견이 없어요. 첫 번째 의견을 남겨보세요!"라는 플레이스홀더 UI를 강제하도록 권고했습니다.

---

3.2. P1 결함: 레이아웃 파편화 및 인터랙션 마찰

코드 린터나 정적 검사로는 절대로 찾아낼 수 없는 브라우저 렌더링 레벨의 결함들도 대거 발굴되었습니다:

[결함 사례: 886px 반응형 레이아웃 붕괴]

   Desktop (> 900px)                  Tablet Breakpoint (~886px)
┌───────────────────────────────┐     ┌───────────────────────────────┐
│ [ A가 더 좋아요 ] [ B가 좋아요 ] │     │ [ A가 더 좋아요 ]             │
└───────────────────────────────┘     │ [ B가... (뷰포트 아래로 잘림)  │
                                      └───────────────────────────────┘

1. 중간 해상도($886\text{px} \sim 890\text{px}$) 투표 바 짤림:
   - 데스크톱 전체화면에서는 가로 한 줄로 깔끔하게 나오던 하단 플로팅 투표 바가, 창 너비 $886\text{px}$ 부근에서 flex 줄바꿈이 일어나며 2줄로 꺾였습니다. 이로 인해 두 번째 버튼인 "B가 더 좋아요" 하단이 브라우저 뷰포트 밖으로 잘려 나갔습니다.
2. 라우트 전환 시 스크롤 위치 비초기화 (Scroll Leaks):
   - 랜딩 페이지에서 아래로 스크롤을 내린 후 "테스트 시작"을 누르면, 새 페이지가 열리면서 스크롤 오프셋(137px, 469px)이 그대로 유지되어 상단 타이틀이 잘린 채 진입했습니다. 중요한 사유 입력창이 화면 밖으로 밀려나 사용자에게 보이지 않는 문제가 발생했습니다.
3. 랜딩 카드 스택 휠 이벤트 하이재킹 (스크롤 트랩):
   - 랜딩 페이지 중앙의 인터랙티브 카드 스택 위에서 마우스 휠을 굴릴 때, 휠 이벤트가 카드 컴포넌트에 갇혀버렸습니다. 휠을 70틱 넘게 굴려도 카드 2장만 겨우 넘어가고 전체 페이지 스크롤이 불가능해지는 치명적인 인터랙션 트랩이었습니다.

---

4. 도구 한계에 직면했을 때의 '인간 핸드오프(Hand-off)'

이번 테스트 과정에서 가장 흥미로웠던 장면 중 하나는 Computer Use 도구의 한계 상황에서 에이전트가 보여준 협업 태도였습니다.

BlindChoice 서비스는 실수로 인한 오클릭 투표를 방지하기 위해 "버튼을 1.5초간 길게 눌러(Long-press) 투표 확정" 인터랙션을 채택하고 있었습니다.

하지만 현재 LLM 에이전트의 Computer Use 도구 규격(Tool Schema)에는 단순 click, move, scroll만 존재할 뿐, "마우스 버튼을 일정 시간 누르고 유지(Hold duration)"하는 파라미터가 없었습니다.

[에이전트의 위기 돌파 시도]
1단계: 일반 클릭 시도 ──▶ 롱프레스 미충족으로 투표 무반응
2단계: 키보드 포커스 후 Enter / Space 연타 ──▶ 키보드 이벤트 미등록으로 무반응
3단계: 자가 한계 인식 후 인간에게 즉각 핸드오프(Hand-off)!

에이전트는 여기서 멈추거나 환각을 일으키지 않고, 즉각 빌더에게 대화를 건넸습니다:

"현재 제 Computer Use 도구에는 버튼 누름 시간을 지정하는 파라미터가 없습니다. 혹시 화면에서 직접 'B가 더 좋아요' 버튼을 길게 눌러주신 뒤, 완료되었다고 말씀해 주시겠습니까? 그 후 이어지는 결과 화면부터 사용자 테스트를 계속 진행하겠습니다."

신체가 없거나 도구의 표현력이 부족할 때 스스로를 억지로 속이지 않고, 인간을 물리적 조작 도구로 호출하는 'Human as a Tool / Human Hand-off'의 성숙한 협업 패턴을 입증한 것입니다.

---

5. 브라우저 탐색부터 소스 코드 자율 수정 PR까지

테스트의 백미는 Claude Fable 5.1의 자율 문제 해결 루프였습니다.

문제를 보고서로 정리하는 데서 그치지 않고, 에이전트는 로컬 터미널을 통해 프로젝트 리포지토리(blind-test main)로 직접 진입했습니다.

# Claude Fable 5.1의 자율 디버깅 트레이스
$ git status
On branch main
Your branch is up to date with 'origin/main'.

# 브라우저에서 포착한 스크롤 판정 로직 소스코드 검색
$ grep -rn "scrollProgress" src/components/
src/components/CompareViewer.tsx:42: const progress = calculateScroll(element);

# 불필요한 미마운트 DOM 필터링 및 라우팅 진입 시 window.scrollTo(0, 0) 보정
# Git diff 확인
$ git diff --stat
 src/components/CompareViewer.tsx | 15 ++++++++++-----
 src/hooks/useScrollRestore.ts    |  8 ++++++++
 2 files changed, 18 insertions(+), 5 deletions(-)

에이전트는 브라우저에서 발견한 스크롤 판정 계산 버그와 페이지 전환 시 스크롤 누수 현상을 소스코드 상에서 완벽히 역추적하여, +20, -3 라인의 간결하고 정밀한 패치 코드를 작성하고 풀 리퀘스트(PR) 발행을 완료했습니다.

[완전 자율 에이전트 QA 루프]

브라우저 Computer Use (동적 조작) ──▶ 비즈니스/UX 결함 포착 ──▶ 원인 코드 역추적
                                                                         │
    Pull Request (PR) 자동 생성 ◀── 단위 테스트 및 빌드 검증 ◀─── 소스코드 자동 패치

---

6. 정적 린터 vs 동적 Computer Use QA 비교

소프트웨어 품질 보증 파이프라인에서 두 접근 방식은 상호 배타적인 것이 아니라 명확한 역할 분담을 가집니다.

비교 항목	정적 기획/코드 린터 (PRD-to-Code Linter)	동적 Computer Use 에이전트 QA
입력 대상	PRD 문서, 텍스트 요구사항 명세, Git Diff 소스코드	브라우저 렌더링 화면(스크린샷), DOM 트리, 실제 사용자 인터랙션
핵심 검출 영역	로직 누락, API 스펙 불일치, 타입 오류, 시맨틱 모순	반응형 CSS 깨짐, 스크롤 트랩, 버튼 잘림, Empty State 누락, 조작 단절
실행 속도 및 비용	밀리초(ms) 단위, 초저비용 (텍스트 인퍼런스)	수 초~수 분 소요, 스크린샷 비전 추론으로 상대적 고비용
파이프라인 위치	코드 작성 및 로컬 커밋 단계의 실시간 자가 교정 린터	스테이징 환경 배포 전 E2E 사용자 여정 및 사용성 검증
대표 모델/도구	Jev, Claude Code Linter, ESLint, Biome	GPT-6 Astra, Claude Fable, Stagehand, Playwright

정적 린터가 코드 레벨에서 "설계도대로 부품이 만들어졌는가?"를 검사한다면, Computer Use 에이전트는 "실제 조립된 완성차를 타고 달릴 때 승차감이 어떤가?"를 검증합니다.

---

7. 차세대 발전 방향: 다중 페르소나 사용자 리크루팅 시뮬레이션

실제 현업의 정성적 사용성 테스트(UT)에서는 편향을 방지하기 위해 최소 2~5명 이상의 다양한 배경을 가진 사용자를 리크루팅합니다.

이 원리를 AI 에이전트 QA에 확장하여, "다중 페르소나 주입 테스트(Persona-conditioned Turns)" 아키텍처로 발전시킬 수 있습니다:

🔍 클릭하여 확대

flowchart LR
    A["동일한 웹 애플리케이션\n(Staging App)"] --> B["페르소나 A: 디지털 취약계층\n(고령자, 키보드/마우스 미숙련)"]
    A --> C["페르소나 B: 파워 엔지니어\n(컴공과 출신, 엣지 케이스 집중 공략)"]
    A --> D["페르소나 C: 도메인 전문가\n(금융/의료 등 전문 지식 기반 검증)"]

    B --> E["네비게이션 혼선, 모호한 UX 문구,\n접근성(a11y) 결함 집중 발굴"]
    C --> F["비정상 조작, 네트워크 지연,\n데이터 정합성 모순 집중 발굴"]
    D --> G["도메인 전문 용어 적합성,\n신뢰도 및 규정 준수 검증"]
  

인간 사용자를 섭외하여 시간당 수십만 원의 리크루팅 비용을 쓰기 전, 사전에 정의된 다중 페르소나 에이전트 군단을 투입해 UX 사각지대를 90% 이상 사전 소거할 수 있습니다.

---

8. 핵심 요약 및 엔지니어링 시사점

1. 코드를 보는 것과 화면을 만져보는 것은 완전히 다른 영역이다:
   아무리 꼼꼼한 코드 리뷰와 타입 시스템을 갖추었더라도, $886\text{px}$ 반응형 줄바꿈 오류나 카드 스택 마우스 휠 트랩, 라우팅 스크롤 누수는 렌더링된 화면을 직접 조작해보기 전에는 결코 드러나지 않습니다.
2. 에이전트는 훌륭한 비판적 테스터다:
   LLM 에이전트에게 단순 생성 작업만 맡기면 자화자찬과 전진 본능에 빠지기 쉽지만, 명확한 페르소나와 검증 목표를 주고 "비판적 사용자"로 포지셔닝하면 놀라울 정도로 날카로운 결함 발굴기가 됩니다.
3. 실행은 AI가, 최종 판단과 취향은 사람이:
   AI가 브라우저를 조작하며 버그를 수집하고 PR을 올리는 것은 기술적 '실행'입니다. 그러나 이 제품이 전달하고자 하는 본질적인 브랜드 경험과 재미, 최종적인 디자인 완성도를 결정하는 것은 여전히 인간 엔지니어와 디자이너의 안목(Taste)입니다.