OpenAI Computer Use와 Playwright CLI 브라우저 자동화 비교: 화면 판단은 모델, 로그인·첨부·검증은 selector 하네스가 맡는다

브라우저 자동화를 전부 OpenAI Computer Use에 맡기면 편해 보인다. 화면을 보고, 버튼을 찾고, 클릭과 입력 action을 돌려주는 구조라서 사람처럼 움직이는 agent를 만들 수 있다. 하지만 반복 발행, 로그인 세션, 파일 첨부, 공개 URL 검증처럼 실패했을 때 되돌리기 어려운 구간은 먼저 Playwright CLI 같은 selector 하네스를 봐야 한다.

2026-04-20 기준 공식 문서로 보면 결론은 단순하다. 화면 판단은 Computer Use가 맡기 좋고, 반복 실행과 검증은 Playwright가 맡기 좋다. 둘 중 하나를 고르는 문제가 아니라, 어느 단계에서 visual loop를 끊고 script로 고정할지 정하는 문제에 가깝다.

핵심만 먼저 적으면 이렇다.

• 화면이 자주 바뀌고 selector가 불안정한 one-off 탐색은 OpenAI Computer Use가 먼저 맞다.
• 로그인 세션, 파일 업로드, 공개 발행, 공개 HTML 검증이 붙는 반복 작업은 Playwright CLI가 먼저 맞다.
• 편집기 UI가 바뀐 상황처럼 화면 해석과 반복 실행이 섞이면 hybrid가 낫다. 모델이나 사람이 바뀐 화면을 확인하고, 통과한 단계는 다시 script로 잠근다.
• Computer Use도 운영 권한을 가진다. 인증된 페이지, 결제, 삭제, 공개 발행처럼 되돌리기 어려운 action에는 human-in-the-loop가 필요하다.

OpenAI Computer Use는 화면 판단 루프다

OpenAI Computer Use docs는 이 기능을 UI를 조작하는 agent로 설명한다. 모델은 screenshot을 보고 click, type, scroll 같은 interface action을 반환한다. 개발자 쪽 harness는 그 action을 실제 browser나 desktop environment에서 실행하고, 새 screenshot을 다시 모델에게 넘긴다. 이 loop가 끝날 때까지 반복된다.

현재 문서에서 중요한 변화는 구현 shape다. 새 구현은 gpt-5.4와 Responses API의 computer tool을 기준으로 잡아야 한다. 오래된 preview path인 computer-use-preview와 computer_use_preview는 migration 대상이고, 새 path에서는 computer_call이 단일 action이 아니라 actions[] 배열을 줄 수 있다.

OpenAI docs는 harness도 한 가지로 묶지 않는다.

harness shape	맞는 상황
built-in Responses API computer tool	screenshot 기반으로 모델이 직접 UI action을 제안해야 할 때
existing automation harness 위 custom tools	이미 Playwright, Selenium, VNC, MCP 기반 제어 흐름이 있을 때
browser/desktop controls를 노출하는 code execution environment	모델이 code와 UI 제어를 함께 써야 할 때

이 말은 중요하다. Computer Use를 쓴다고 기존 Playwright를 버릴 필요는 없다. 오히려 공식 문서도 local browser prototype의 빠른 시작점으로 Playwright나 Selenium을 언급한다. Computer Use는 visual judgment를 맡고, 반복 실행은 기존 harness가 맡는 구성이 자연스럽다.

Playwright CLI는 반복 실행과 검증에 강하다

Playwright docs에서 반복 자동화에 바로 연결되는 포인트는 네 가지다.

첫째, locator가 auto-waiting과 retry-ability의 중심이다. getByRole, getByLabel, getByPlaceholder, getByTestId처럼 사용자에게 보이는 속성이나 명시적 contract를 기준으로 element를 찾는다. DOM이 re-render되더라도 action 시점마다 element를 다시 찾는다.

둘째, actionability check가 있다. click()은 target이 하나인지, visible인지, stable인지, 이벤트를 받을 수 있는지, enabled인지 확인한 뒤 실행된다. 화면을 보고 대략 누르는 방식보다 느릴 수는 있어도, 실패 지점이 로그로 남는다.

셋째, 로그인 state를 파일로 재사용할 수 있다. Playwright auth docs는 authenticated browser state를 저장해 다음 run에서 다시 쓸 수 있다고 설명한다. 다만 이 파일에는 cookies와 headers가 들어갈 수 있으므로 repository에 올리면 안 된다.

넷째, file upload는 API로 처리할 수 있다. locator.setInputFiles()나 filechooser event를 쓰면 첨부 메뉴를 사람이 보는 식으로 맞추는 대신, 어떤 파일을 넣었는지 script와 log로 남길 수 있다.

이 네 가지가 합쳐지면 Tistory 같은 발행 흐름에서는 답이 꽤 분명해진다. 카테고리, 태그, 첨부, 하단 섹션 재배치, 공개 URL HTTP 200 확인, 첨부 signed URL GET 확인은 visual judgment보다 재현성이 중요하다.

판단표: 무엇을 Computer Use에 맡기고 무엇을 Playwright에 맡길까

상황	먼저 볼 선택지	이유
새 SaaS 콘솔에서 설정 위치를 한 번 찾는다	Computer Use	화면 구조를 해석하는 일이 핵심이고 반복성이 낮다
같은 글쓰기 flow를 매일 반복한다	Playwright CLI	selector, session, file upload, verification log가 중요하다
편집기 UI가 바뀌어 기존 selector가 깨졌다	Hybrid	바뀐 화면은 모델이나 사람이 보고, 확인된 단계는 script로 고정한다
공개 발행, 결제, 삭제, 케이스 close가 있다	Playwright + human gate	action 결과가 외부에 남거나 되돌리기 어렵다
첨부 파일 위치와 공개 URL을 검증해야 한다	Playwright CLI	HTML, 파일명, HTTP status를 기계적으로 확인해야 한다

Computer Use를 피해야 한다는 뜻은 아니다. 반대로 selector가 없고 화면 해석이 핵심인 구간에서는 Computer Use를 먼저 쓰는 편이 낫다. 다만 Computer Use의 output은 다음 action 제안이지, 검증 로그 자체가 아니다. 발행이나 첨부처럼 증거가 필요한 단계는 script 쪽에 남겨야 운영이 편하다.

로컬 routing 실험 결과

이번 run에서는 live Computer Use 성공률이나 Playwright latency를 재지 않았다. 대신 공식 문서에서 나온 경계를 기준으로 browser workflow 5개를 scoring했다. 기준은 visual ambiguity, selector 안정성, 반복 횟수, 인증 세션, 파일 첨부, 공개/비가역 action, 검증 증거, human review 필요성이다.

task	recommendation	왜 그렇게 나왔나
visual-research-oneoff	computer_use	새 콘솔에서 위치를 찾는 one-off라 화면 해석 점수가 가장 컸다
tistory-publish-flow	playwright_cli	로그인 세션, 파일 첨부, 공개 발행, 공개 URL 검증이 한 흐름에 묶였다
attachment-placement-audit	playwright_cli	HTML에서 첨부 파일명이 하단 섹션 뒤에만 있는지 반복 검사해야 했다
redesigned-editor-recovery	hybrid_review_then_script	바뀐 화면을 먼저 해석해야 하지만, 통과 뒤에는 script로 잠가야 했다
crm-bulk-close	playwright_cli	40건 반복 close와 처리 로그가 필요하고, 되돌리기 어려운 action이었다

추천 분포는 computer_use 1, playwright_cli 3, hybrid_review_then_script 1이었다. 가장 중요한 contrast는 Tistory-style publish flow다. 화면을 보고 버튼을 찾는 것보다, 같은 프로필의 로그인 session을 유지하고, 파일 첨부를 정확히 넣고, 공개 HTML과 첨부 URL을 다시 읽는 일이 더 크다.

Tistory 발행 자동화에는 왜 Playwright CLI를 먼저 쓰나

Tistory 글 발행은 겉보기에는 브라우저 클릭 작업이다. 실제 운영에서는 다르다.

1. 로그인 profile이 살아 있는지 확인해야 한다.
2. 제목, 본문, 카테고리, 태그를 같은 순서로 넣어야 한다.
3. public artifact를 첨부하되 본문 첫 화면에 올라오면 안 된다.
4. 첨부 block은 하단 실행 로그 첨부 섹션 아래에 있어야 한다.
5. 공개 뒤 URL이 200인지 확인해야 한다.
6. 첨부 signed URL도 GET 200인지 확인해야 한다.

이 중 Computer Use가 잘할 수 있는 부분은 화면에서 지금 어디가 첨부 버튼인지 찾기 같은 판단이다. 그러나 매 run마다 필요한 건 판단보다 증거다. 어떤 파일을 올렸는지, 하단으로 이동했는지, 공개 URL이 열리는지, 첨부가 살아 있는지를 로그로 남겨야 한다. 그래서 이 블로그 automation에서는 Tistory editor control을 Playwright CLI와 CDP 재사용 script에 맡기는 쪽이 맞다.

Hybrid pattern은 UI가 바뀔 때 쓴다

현실에서는 selector가 항상 안정적이지 않다. 에디터가 바뀌거나 메뉴 위치가 달라지면 script가 깨질 수 있다. 이때 처음부터 Computer Use에 모든 발행 권한을 넘기는 대신, hybrid pattern을 쓰는 편이 낫다.

1. 새 화면 screenshot을 보고 메뉴 구조를 찾는다.
2. human review로 공개 발행 같은 위험 action을 막는다.
3. 새 locator나 file chooser path를 script에 반영한다.
4. 같은 작업이 반복되면 Computer Use loop를 줄이고 script로 재실행한다.
5. 공개 URL, attachment URL, HTML ordering check는 계속 script가 맡는다.

이 구조는 모델을 배제하지 않는다. 모델을 매번 누르는 손으로 쓰는 대신, 바뀐 화면을 읽고 하네스를 고치는 눈에 더 가깝게 쓰는 방식이다.

구현 전 체크리스트

브라우저 자동화에 Computer Use를 붙이기 전에 아래 질문부터 보면 시행착오가 줄어든다.

1. 이 작업은 한 번만 하는 화면 탐색인가, 같은 flow를 계속 반복하는가.
2. role, label, placeholder, test id 같은 selector contract가 있는가.
3. 인증 cookie나 profile state를 저장해야 하는가.
4. 파일 upload가 있고, 첨부 위치를 나중에 검증해야 하는가.
5. 공개 발행, 결제, 삭제, close처럼 되돌리기 어려운 action이 있는가.
6. 실패했을 때 screenshot보다 HTML, URL, status code, run log가 더 중요한가.
7. untrusted page content가 모델에게 instruction처럼 보일 위험이 있는가.
8. human gate 없이 진행해도 되는 action과 멈춰야 하는 action이 분리돼 있는가.

위 질문에서 반복, 세션, 파일, 공개, 검증이 많이 나오면 Playwright CLI가 먼저다. 화면이 바뀜, selector 없음, 한 번만 판단, 사람 확인 후 진행이 많이 나오면 Computer Use나 hybrid가 먼저다.

같이 보면 좋은 글

• OpenAI computer environment와 skills로 브라우저+셸 에이전트 만들기
• OpenAI Responses API에 MCP 서버 붙이기: 원격 도구 연결 최소 예제
• OpenAI Realtime API 연결 기준: 브라우저 음성은 WebRTC, 서버 로직은 WebSocket·sideband로 나눠야 한다

참고 자료

• OpenAI Computer use
• Playwright locators
• Playwright auto-waiting
• Playwright authentication
• Playwright actions and file upload

실행 로그 첨부

민감정보를 제거한 공개용 로그와 실험 스크립트만 아래에 첨부한다.

• wn112-computer-use-playwright-router-public.json
• wn112-computer-use-playwright-router-summary-public.md
• wn112-computer-use-playwright-router-public.py

wn112-computer-use-playwright-router-public.json

0.01MB

wn112-computer-use-playwright-router-summary-public.md

0.00MB

wn112-computer-use-playwright-router-public.py

0.01MB