Codex가 DevTools 내부까지 확인해 준다! 신기능 Developer mode (CDP)로 브라우저 디버깅을 실측해 보았다

서론

2026년 6월 11일의 Codex app 26.609에서, Browser use를 위한 Developer mode가 추가되었습니다.

OpenAI의 changelog에 따르면, Chrome과 Codex의 in-app browser에서 Developer mode를 사용할 수 있게 되었으며, Chrome DevTools Protocol (CDP)를 통해 network traffic, console output, runtime errors, page state, performance profiling까지 확인할 수 있다고 합니다.

요컨대, Codex가 브라우저를 「보고 클릭하는」 것뿐만 아니라, DevTools처럼 「왜 그런 상태가 되었는지」까지 조사할 수 있게 된 것입니다. 이것은 겉보기에는 사소해 보일지 몰라도 상당히 엄청난 기능이 아닐까요?

그래서 작은 로컬 페이지를 준비하여, Codex의 Browser use를 통해 console log, 404 fetch, runtime error, DOM state를 어디까지 추적할 수 있는지 테스트해 보았습니다.

Developer mode / CDP로 무엇이 바뀌는가

일반적인 Browser use에서도 Codex는 페이지를 열고, 클릭하고, DOM을 보고, 스크린샷을 찍을 수 있습니다.

하지만 프론트엔드 디버깅은 「무엇이 보이는가」만으로는 전혀 부족합니다.

예를 들어, 버튼을 눌렀을 때 화면이 깨졌다고 가정해 봅시다.

• JS의 예외(Exception)인지
• API가 404 / 500을 반환했는지
• DOM state와 표시 내용이 일치하지 않는지
• CSS가 예상치 못하게 적용되었는지
• 애초에 무거운 처리로 인해 멈춰버린 것인지

이런 부분들은 평소라면 DevTools의 Console / Network / Elements / Performance를 확인해야 하는 것들입니다.

Codex의 Developer mode는 Codex 자신이 controlled CDP access를 통해 그곳에 들어갈 수 있게 되는 기능입니다. 공식 문서에서도 console output, network traffic, DOM / applied styles, JavaScript profiling 등을 조사하는 용도가 언급되어 있습니다.

검증용 페이지 만들기

공개 기사에 올리기 쉽도록 사내 화면이나 타인의 X 스크린샷은 사용하지 않고, 수중에 작은 검증용 페이지를 만들었습니다. 순수한 HTML / JS / CSS만 있는 페이지이며, 리포지토리(Repository)로 공개하지는 않았습니다.

실행은 검증 페이지 디렉토리에서 평범하게 http.server를 띄우기만 하면 됩니다. 이를 http://127.0.0.1:4173/에서 엽니다.

python3 -m http.server 4173

페이지에는 3개의 버튼을 배치했습니다.

• Emit console log: 구조화된 console.info를 출력
• Trigger 404 fetch: 존재하지 않는 JSON을 fetch 하여 404와 console error를 출력
• Trigger runtime error: 의도적인 TypeError를 던져 포착하고, console error와 DOM 상태에 남김

페이지 내의 상태는 window.__MIY53_DEBUG_STATE__에도 두었으며, DOM에는 Last action과 Signal count를 표시합니다.

실제로 조작해 보기

Codex의 in-app Browser에서 페이지를 열고, 3개의 버튼을 차례로 눌러보았습니다.

결과 스크린샷은 다음과 같습니다!

DOM 상의 상태는 다음과 같이 되었습니다.

{
"lastAction": "error",
"signalCount": "4",
...

HTTP 서버 측에서도 예상대로 200과 404가 나오고 있습니다. 참고로 이 404 행은 버튼과는 별개로 진행한 통신 확인용입니다. 버튼에서 호출하는 URL에는 타임스탬프가 붙기 때문에, 후술할 console log와는 경로가 다릅니다.

HTTP/1.0 200 OK /
HTTP/1.0 200 OK /app.js
HTTP/1.0 404 File not found /api/not-found-check.json

그리고 Codex 측에서 확인할 수 있었던 console log는 다음과 같습니다.

[MIY-53] page loaded Object
[MIY-53] console signal Object
[MIY-53] expected network failure Error: HTTP 404 for ./api/not-found-1781252625294.json
...

app.js:50이나 app.js:60과 같이 발생 위치까지 남습니다.

적어도 이번과 같은 순수 JS (vanilla JS)라면, 스크린샷을 보고 "망가졌네요"라는 말을 듣는 것과는 차원이 다르며, 그대로 수정으로 연결할 수 있습니다 (minify 된 프로덕션 빌드라면 위치 정보의 정밀도는 떨어질 것입니다).

무엇이 좋은가

가장 큰 차이점은 Codex에게 "겉모습"이 아니라 "원인"을 물어볼 수 있게 된다는 점입니다.

화면만 본다면 "에러 표시가 나타나고 있습니다"에서 끝납니다.

하지만 console이나 network, runtime state까지 볼 수 있다면 다음과 같이 요청할 수 있습니다.

이 버튼을 눌렀을 때의 console error와 failed request를 확인해서,
원인이 되는 파일과 수정 후보를 제시해 주세요.

또는, 공식 문서상으로는 다음과 같은 요청도 가능할 것입니다 (이 부분은 이번에 검증하지 않았습니다).

화면이 느리니, Developer mode로 performance trace와 network를 보고,
병목 지점(bottleneck) 후보를 우선순위 순으로 정리해 주세요.

결국 Codex가 "브라우저 조작 담당"에서 "DevTools를 함께 봐주는 조사 파트너"가 되는 셈입니다. 이는 경험 측면에서 상당히 큰 변화입니다!

주의사항

편리해 보이는 한편, Full CDP access는 상당히 강력한 권한입니다. 이 부분은 솔직히 조금 무섭기도 합니다.

공식 문서에서도 Full CDP access는 브라우저 내부의 민감한 정보를 보거나 제어할 수 있기 때문에, Codex가 full CDP inspection을 사용하기 전에 명시적인 승인이 필요하다고 설명되어 있습니다.

사용 대상을 구분하는 것이 좋아 보입니다.

대상	적합 여부
로컬 개발 서버	적합
...

또한, 이 기사에서 실측할 수 있었던 것은 screenshot / DOM state / console log까지입니다. CDP를 통한 network request 목록이나 performance profiling은 공식 문서상 "가능하다"고 명시된 범위이지만, 이번에는 실측하지 않았습니다. 이 점은 구분해서 읽어주시기 바랍니다!

요약

Codex Developer mode / CDP는 Browser use를 "조작할 수 있는 브라우저"에서 "관측하며 디버깅할 수 있는 브라우저"로 바꾸는 기능이었습니다.

작은 로컬 페이지라도 화면, DOM, console error가 연결되는 것만으로 Codex에게 맡길 수 있는 조사 및 수정의 정밀도가 한 단계 올라갑니다.

특히 프론트엔드의 "겉모습은 망가졌는데, 원인이 fetch인지 JS 예외인지 CSS인지 모르겠다"와 같은 유형의 조사와 궁합이 매우 좋아 보입니다.

다음에 시도해 본다면 다음과 같은 내용들입니다.

• Full CDP access 활성화 시의 network request 목록 취득
• Performance trace를 Codex에게 읽혀서 병목 지점 후보를 뽑아낼 수 있는지
• Chrome extension 측에서 로그인된 SaaS를 다룰 때의 안전한 요청 문구

참고 링크

Discussion