AI에게 코딩을 맡길 때, 마지막까지 남는 맹점은 "브라우저 안에서 실제로 일어나고 있는 상태를 조사하는 것"입니다. 서버나 터미널의 로그는 AI가 읽을 수 있지만, 브라우저의 console은 보이지 않습니다. 그래서 에러를 수동으로 복사해서 붙여넣는 작업이 발생하게 됩니다.

이 부분을 메워주는 도구는 이미 다양하게 있습니다. Chrome DevTools MCP (Google 공식), BrowserTools MCP, Console Ninja…. 최근에는 Chrome의 DevTools 자체에 Gemini가 탑재되어, console 에러를 그 자리에서 읽고 해설해 주기도 합니다. 하지만, 모두 "브라우저와 코드(및 AI)가 같은 머신에 있다"는 전제를 가지고 있습니다. 그래서 그 전제에 얽매이지 않고, 다른 머신의 브라우저에서도 사용할 수 있도록 GreenLight를 만들었습니다.

GreenLight란

Chrome의 console 출력(log / warn / error / 예외)을 텍스트 파일에 자동으로 기록할 뿐인 작은 도구입니다. DevTools를 열고 있지 않아도, 전용 Chrome이 작동하는 동안에는 계속해서 기록합니다. Chrome DevTools Protocol (CDP)로 브라우저에 어태치(attach)하는 방식이므로, 대상 페이지의 소스에 손을 댈 필요가 없습니다.

설계 사상을 한마디로 말하자면, "AI에게 브라우저를 조작하게 하는 것"이 아니라 "사람이 직접 재현하고, 그 결과(파일)를 AI에게 읽히는" 패시브(passive)한 레코더입니다.

놓치지 않음: 리로드나 화면 전환을 넘나들며 세션 전체를 연속 기록합니다. "그때마다 쿼리"하는 방식과 같은 결손이 없습니다. -
PC를 넘나듦: dev와 test가 서로 다른 PC라도, 출력 폴더를 공유/동기화해 두면 파일이 그대로 전달됩니다. -
스마트폰 실기기 촬영 가능: USB로 연결한 Android 단말기의 Chrome도 동일한 메커니즘으로 그대로 기록할 수 있습니다 (자세한 내용은 후술).

동일 머신 전제 시 누락되는 케이스에 대응

왜 굳이 "다른 머신"을 강조하는가. 저의 환경은 다음과 같습니다

• 평소 사용은 Windows. 하지만 개발은 remote로 Linux 측에서 수행.
• Web 실기기 테스트는 Windows 측(혹은 별도의 PC를 한 대 더 준비)에서 폐쇄된 LAN으로 실행.
• 스마트폰 실기기(Android) 테스트의 경우, 브라우저가 돌아가는 곳은 손에 든 PC조차 아님.

이런 구성에서는 브라우저가 돌아가는 머신과 코드/AI가 있는 머신이 달라집니다. 그러면,

• AI로부터 MCP (Model Context Protocol) / CDP (Chrome DevTools Protocol)를 호출하는 계열은, 테스트기의 브라우저에서 AI가 있는 쪽으로 전달되지 않습니다.
• 빌드 도구의 플러그인(예: vite-console-forward)은 dev 서버를 경유하는 것을 전제로 하며, 출력도 터미널 중심입니다. 다른 머신에서 실제 빌드를 다루는 테스트에는 적용하기 어렵습니다.

"저쪽 브라우저의 console을 이쪽 AI에게 읽히고 싶다"는 단순한 요구인데, 의외로 기존 도구들에서 누락됩니다. GreenLight가 가장 효과를 발휘하는 지점이 바로 이 장면입니다.

그림으로 나타내면 이런 구성입니다. 테스트기(Windows나 Android)에서 돌아가는 브라우저의 console을 GreenLight가 파일로 만들고, 그것을 LAN 내의 개발기(Linux / Mac)의 AI에게 전달합니다.

단순함… 그것이 장점

GreenLight가 하는 일은 "Chrome의 console을 텍스트로 쓰는 것"뿐입니다. CDP나 전체 페이지 자동 어태치 같은 내부 로직은 있지만, 사용자에게 보이는 기능은 이것뿐입니다. 원래는 자신을 위한 조잡한 스크립트였습니다.

흥미로운 점은, 이 단순함이 그대로 장점으로 변한다는 것입니다.

출력이 단순한 텍스트이기 때문에, 어떤 AI에게도 그대로 전달할 수 있습니다 — "AI에게 읽히는" 최단 경로가 플레인 텍스트(plain text)이며, 그것을 묵묵히 계속 써 내려가는 도구는 의외로 없었습니다. 자체적인 네트워크 서비스를 갖지 않고, AI에게 조작 권한도 넘기지 않기 때문에 지켜야 할 신뢰 경계(trust boundary)가 거의 없어 결과적으로 안전합니다. 그리고 "console을 파일로 만든다" 이상의 것을 정해두지 않았기 때문에, 다른 머신의 LAN 테스트뿐만 아니라, 실패한 CI의 재현 로그를 나중에 AI에게 읽히거나, 결함의 증적(evidence)으로 남기는 등 예상치 못한 용도로도 유용하게 활용할 수 있습니다.

AI와의 궁합, 안전성, 그리고 넓은 응용 범위는 기능을 과하게 채워 넣어서 얻은 것이 아니라, 과하게 채우지 않았기에 남은 것입니다. "다른 머신의 브라우저 console을 AI에게 전달한다"는 것은, 그 단순함이 가장 명확하게 와닿는 사례라는 위치를 차지합니다.

왜 "파일"인가, 왜 클라우드로 하지 않는가

"테스트 기기의 console을 네트워크를 통해 서버로 보내 집약한다"—이른바 클라우드 수집—은 하지 않습니다. console 로그에는 토큰이나 개인정보가 아무렇지 않게 섞여 있기 때문에, 그것을 제3자의 서버로 보내고 싶지 않기 때문입니다.

그래서 GreenLight는 자체적인 네트워크 서비스를 일절 갖지 않습니다. 하는 일은 "로컬에 파일을 쓰는 것"뿐입니다. 다른 머신으로 전달하는 것은 개발자가 이미 가지고 있는 수단(공유 폴더/동기화, 향후에는 SSH 직접 전송도 검토 중)에 맡깁니다. 데이터는 자신의 손을 떠나지 않습니다.

CDP (Chrome DevTools Protocol)를 사용하는 이상, 보안을 소홀히 할 수 없습니다. 구현에서는 다음과 같이 처리하고 있습니다.

디버그 포트는 localhost만 허용 (127.0.0.1 바인딩. --remote-debugging-address를 붙이지 않음 = LAN/외부에 노출하지 않음).

모든 Origin을 허용하지 않음. 접속 측에서 Origin 헤더를 보내지 않는 방식을 채택하여 --remote-allow-origins=*가 필요 없도록 했습니다. 이를 통해 Chrome의 기본 Origin 체크가 작동하는 상태를 유지함으로써, 악의적인 웹 페이지가 디버그 포트에 CDP로 접속하여 해당 브라우저를 탈취하는 것을 방지할 수 있습니다.

샌드박스 (Sandbox)를 약화시키지 않음 (--no-sandbox나 --disable-web-security도 사용하지 않음).

"AI에게 전달하기 전에 로그 내용을 확인한다"는 운영 방식과 세트로, "최소한만 전달한다"는 것을 보장하는 사고방식입니다. 직접 테스트 중이라면 확인 없이 그대로 전달해도 문제없는 경우가 많을 것입니다. 그 부분은 개발자의 판단에 달려 있습니다.

사용법 (현재 Windows 전용)

하는 일은 glog.bat을 실행하는 것뿐입니다.

glog.bat 실행 (URL을 전달하면 해당 페이지를 연 상태로 실행할 수도 있습니다).

• 전용 프로필의 Chrome이 실행되므로, 기록하고 싶은 페이지를 직접 조작합니다.
• 모든 페이지의 console이 파일에 계속 기록됩니다 (중단하려면 Ctrl+C, Chrome은 열린 상태 유지).

브라우저를 조작하는 동안, console은 알아서 파일로 쌓여갑니다. 그다음 그 파일을 AI에게 전달하기만 하면 됩니다.

실제 출력은 다음과 같은 형태의 순수 텍스트입니다.

# === log file (re)created 2026-06-24 10:12:03 ===
main.js:128 [Fast Refresh] done in 412ms
app.js:142 Uncaught TypeError: Cannot read properties of undefined (reading 'id')
...

파일:행 메시지가 나열될 뿐입니다. 이 console.log를 그대로 AI에게 전달하면, 다른 머신에서 발생한 에러를 문맥과 함께 읽어줍니다 (첫 줄은 파일을 삭제하면 다시 기록되는 표식입니다).

은근히 편리한 점은, 기록 중에도 출력 파일을 삭제할 수 있다는 것입니다. 불필요한 앞부분(로그인 화면 등)은 목적 페이지에 도착한 후 파일을 삭제하면, 깨끗한 상태부터 기록할 수 있습니다. 도메인으로 필터링하는 것도 가능합니다 (기본값은 전부 기록).

도입(설치 및 설정 상세)은 README에 정리되어 있습니다.

스마트폰 실기기 (Android)의 console도 기록 가능

"다른 머신"의 대표적인 예가 스마트폰입니다. 놀랍게도 USB로 연결된 Android 단말기의 Chrome도 PC와 완전히 동일한 메커니즘으로 console을 파일에 기록할 수 있습니다. chrome://inspect를 열어 일일이 복사/붙여넣기 하는 작업은 이제 필요 없습니다.

config.android.json에 "source": "android"를 적고 glog.bat --config android로 실행하기만 하면 됩니다. adb가 단말기의 DevTools를 localhost로 브릿지(bridge)해주고, 이후 CDP로 어태치(attach)하여 기록합니다 (단말기의 소스에는 손대지 않습니다). 페이지 이동이나 새로고침을 넘나들며 연속적으로 기록하므로, 실기기의 디버그 로그를 복사/붙여넣기 없이 그대로 AI에게 전달할 수 있습니다.

한 가지 주의할 점이 있습니다. Android는 본인의 실기기 Chrome에 연결하는 것이므로, 개인 탭이나 로그인 중인 서비스도 함께 존재합니다. 따라서 filter_enabled: true 설정을 통해 기록 대상 사이트를 좁히는 것을 강력히 권장합니다 (adb 준비 및 설정에 대한 자세한 내용은 README를 참조하세요).

작동 원리 (관심 있는 분들을 위해)

• Chrome을 --remote-debugging-port와 전용 --user-data-dir를 사용하여 실행 (Chrome 136 이후 버전에서는 기본 프로필에서 원격 디버깅이 비활성화되어 있으므로 전용 프로필을 사용해야 합니다).
• 브라우저 레벨에서 CDP (Chrome DevTools Protocol)를 하나만 열어 모든 페이지에 자동으로 어태치(Attach)합니다. console 출력과 예외(Exception)를 모아서 파일에 계속 추가(Append)합니다.
• 기록할 때마다 파일을 열고 닫으며, 핸들(Handle)을 계속 붙잡고 있지 않습니다. 따라서 기록 중에도 파일을 삭제할 수 있습니다.
• localhost 한정, --remote-allow-origins=*를 사용하지 않는 방식, 샌드박스(Sandbox) 유지와 같은 보안 측면은 앞서 언급한 바와 같습니다.

제한 사항

• Windows 전용 (현재). chrome.exe 자동 감지나 콘솔 관련 기능이 Windows를 전제로 하고 있어, macOS / Linux는 지원하지 않습니다.
• Google Chrome 전용 (현재). Safari 등 다른 브라우저는 현재 지원하지 않습니다.
• console 중심. 네트워크 본문(Body) 등은 대상에서 제외됩니다.
• 자율 디버깅에는 적합하지 않음. AI가 스스로 클릭 $\rightarrow$ 새로고침 $\rightarrow$ 확인... 과정을 반복하는 용도는 라이브 제어 (MCP 등)의 영역입니다. GreenLight는 "사람이 재현 $\rightarrow$ AI가 읽음" 방식의 패시브(Passive) 측면 도구입니다.

향후 계획

• macOS / Linux 지원 (캡처 측은 브라우저가 구동되는 OS에서 실행되므로, 테스트 기기의 OS에 맞춰 확장하고 싶습니다).
• Safari (iOS / Mac) 지원: CDP가 아닌 WebKit의 Inspector 프로토콜이 필요합니다. Safari는 macOS를 전제로 하므로, 구현한다면 별도의 구현 방식이 될 것입니다.
• 출력 파일을 SSH로 직접 전송 (공유 폴더에 의존하지 않고, 암호화된 상태 그대로 자신의 개발 기기로 전달). 공유 폴더로 충분한 경우가 많아 우선순위는 낮습니다.

요약

"Windows를 상용으로 사용하면서 Linux에서 원격(Remote) 개발을 하는 경우", "별도의 PC를 LAN에 두고 실기기 테스트를 하는 경우" —— 이러한 구성에서 AI에게 브라우저의 console 로그를 전달하고 싶은 분들에게 아마 가장 매력적일 것입니다. 다만 내용은 "console을 텍스트로 옮기는 것뿐"이므로, 각자의 필요에 맞는 활용법을 찾아주신다면 기쁘겠습니다. MIT 라이선스입니다.

Discussion