---
title: "오픈AI 코덱스, 크롬 확장으로 로그인된 웹까지 직접 건드린다"
published: 2026-05-09T01:05:01.762Z
canonical: https://jeff.news/article/2485
---
# 오픈AI 코덱스, 크롬 확장으로 로그인된 웹까지 직접 건드린다

오픈AI가 맥OS와 윈도우용 코덱스 크롬 확장 프로그램을 공개했다. 이제 코덱스는 샌드박스 브라우저나 플러그인만으로 부족했던 로그인 기반 웹서비스, 사내 시스템, 업무용 SaaS까지 실제 브라우저 세션 안에서 다룰 수 있다. 대신 모든 웹사이트 데이터 접근, 디버거 접근, 기록 접근 같은 센 권한이 필요해서 보안 설계가 핵심 이슈로 따라붙는다.

- 코덱스(Codex)가 이제 사용자의 실제 크롬 브라우저 안으로 들어옴
  - 오픈AI가 8일 맥OS와 윈도우용 코덱스 크롬 확장 프로그램을 공개함
  - 기존에는 코덱스 데스크톱 앱 안의 샌드박스 브라우저나 깃허브, 슬랙, 피그마, 노션 같은 전용 플러그인 중심으로 움직였음
  - 문제는 로그인 세션이 필요한 웹서비스였음. 사내 시스템이나 업무용 SaaS는 샌드박스 밖의 실제 브라우저 맥락이 필요하니까 막히는 구간이 있었음

- 이번 확장의 핵심은 “로그인된 웹”을 코덱스가 직접 다룰 수 있다는 점임
  - 링크드인, 세일즈포스, 지메일, 사내 업무 시스템처럼 인증된 세션이 필요한 사이트에서 정보를 읽거나 작업을 수행할 수 있음
  - 로컬 개발 서버나 로그인 없이 볼 수 있는 공개 페이지는 기존 인앱 브라우저가 계속 맡음
  - 사용자는 프롬프트에서 `@Chrome`을 호출해 “세일즈포스를 열고 통화 메모 기반으로 계정 정보를 업데이트해줘” 같은 식의 지시를 줄 수 있음

- 오픈AI는 코덱스가 작업별로 3가지 도구 계층을 자동 전환한다고 설명함
  - 전용 통합이 있는 작업은 플러그인을 사용함
  - 로그인 기반 컨텍스트가 필요한 작업은 크롬을 사용함
  - 로컬호스트나 공개 페이지 작업은 인앱 브라우저가 처리함
  - 이 구조가 흥미로운 이유는 에이전트가 “어떤 도구를 써야 하는지”까지 스스로 고르는 방향으로 가고 있다는 점임

```mermaid
sequenceDiagram
    participant 사용자
    participant 코덱스
    participant 플러그인
    participant 크롬
    participant 인앱브라우저
    사용자->>코덱스: 업무 지시 입력
    코덱스->>플러그인: 전용 통합 가능 여부 확인
    코덱스->>크롬: 로그인 세션이 필요한 작업 실행
    코덱스->>인앱브라우저: 공개 페이지나 로컬호스트 처리
    크롬-->>코덱스: 페이지 컨텍스트와 작업 결과 반환
    코덱스-->>사용자: 결과 보고
```

- 개발자 입장에서 바로 와닿는 기능도 꽤 있음
  - 웹 애플리케이션 테스트에 쓸 수 있고, 열린 탭 사이의 컨텍스트를 모아서 작업할 수도 있음
  - 크롬 데브툴(Chrome DevTools)을 병렬로 활용하는 기능도 제공함
  - 작업별 탭 그룹(Tab Groups)을 기반으로 움직여서, 사용자의 현재 브라우징 세션을 덜 건드리고 백그라운드 작업을 수행하는 방식임

> [!IMPORTANT]
> 이건 단순한 브라우저 자동화가 아니라, 로그인된 업무 환경을 AI 에이전트가 직접 작업 공간으로 쓰기 시작했다는 얘기임.

- 대신 권한 요청이 꽤 세다. 여기서부터는 편의성보다 보안 얘기가 먼저 나올 수밖에 없음
  - 설치 시 페이지 디버거 접근, 모든 웹사이트 데이터 읽기 및 수정, 브라우징 기록 접근, 북마크 관리, 다운로드 제어, 탭 그룹 관리 권한을 요구함
  - 오픈AI는 새 도메인 접근 전 사용자 허가를 받도록 했고, 허용 목록(Allowlist)과 차단 목록(Blocklist)을 사용자가 관리할 수 있게 함
  - 브라우저 기록 접근은 특히 민감한 권한으로 보고 세션마다 별도 승인을 받게 함

- 가장 까다로운 리스크는 프롬프트 인젝션(prompt injection)임
  - 악성 웹페이지 콘텐츠가 AI의 지시 체계를 오염시켜 엉뚱한 행동을 유도할 수 있음
  - 웹페이지를 읽고, 판단하고, 실제 서비스에 입력까지 하는 에이전트에서는 이 문제가 그냥 이론이 아니라 운영 리스크가 됨
  - 오픈AI는 브라우저 활동 전체를 저장하지 않고, 대화 컨텍스트에 들어간 페이지 텍스트, 스크린샷, 요약본 같은 정보만 저장된다고 설명함

> [!WARNING]
> 회사 계정과 사내 SaaS에서 이런 확장을 쓰려면 “어느 도메인까지 허용할지”, “브라우저 기록 접근을 누가 승인할지”, “프롬프트 인젝션을 어떻게 감시할지”가 먼저 정해져야 함.

- 메모리(Memories) 기능도 브라우저 작업과 엮임
  - 메모리를 켜면 코덱스가 과거 사용자 선호도와 저장된 정보를 활용해 브라우저 작업을 수행함
  - 메모리를 끄면 이전 세션 데이터를 쓰지 않고 독립적으로 작업함
  - 개인화와 격리 사이에서 선택지를 둔 셈인데, 기업 환경에서는 기본값을 어떻게 둘지가 꽤 민감할 듯함

- 전체적으로 보면 브라우저가 AI 자동화의 핵심 런타임이 되어가는 그림임
  - 예전에는 AI가 코드나 텍스트를 만들어주는 도구에 가까웠음
  - 이제는 로그인된 웹서비스와 사내 시스템을 넘나들며 실제 업무를 처리하는 에이전트로 이동 중임
  - 편하긴 한데, 권한과 책임 경계가 흐려지는 만큼 보안팀과 플랫폼팀이 같이 봐야 할 주제가 됨

---

## 기술 맥락

- 이번 선택의 핵심은 코덱스가 자체 샌드박스 브라우저만 고집하지 않고, 사용자의 실제 크롬 세션을 활용하도록 한 거예요. 로그인된 SaaS나 사내 시스템은 인증 쿠키, 탭 상태, 사용자 권한이 얽혀 있어서 별도 브라우저로는 현실적인 업무 자동화가 어렵거든요.

- 플러그인, 크롬, 인앱 브라우저를 나눈 것도 이유가 있어요. 깃허브처럼 전용 API가 잘 잡힌 서비스는 플러그인이 더 안정적이고, 로컬호스트 테스트는 인앱 브라우저가 편하고, 세일즈포스처럼 로그인 맥락이 중요한 곳은 실제 크롬이 맞아요.

- 다만 크롬 확장은 브라우저 데이터 읽기와 수정 권한을 크게 요구할 수밖에 없어요. 그래서 사이트별 승인, 허용 목록, 차단 목록, 세션별 기록 승인 같은 장치가 붙은 거고요. 기능보다 권한 모델이 제품의 신뢰도를 좌우하는 구조예요.

- 프롬프트 인젝션이 특히 중요한 이유는 웹페이지가 이제 단순한 참고 자료가 아니라 에이전트의 입력 채널이 되기 때문이에요. 페이지 안의 악성 문구가 “사용자 지시”처럼 모델에 섞이면, 로그인된 서비스에서 실제 변경 작업까지 이어질 수 있거든요.

## 핵심 포인트

- 코덱스가 크롬 확장을 통해 링크드인, 세일즈포스, 지메일, 사내 시스템 같은 로그인 기반 웹사이트에서 작업 가능
- 플러그인, 크롬, 인앱 브라우저를 작업 성격에 따라 자동 전환하는 3계층 구조 도입
- 새 도메인 접근 전 사용자 승인, 허용 목록과 차단 목록, 세션별 브라우저 기록 승인으로 권한 리스크 완화
- 프롬프트 인젝션과 브라우저 데이터 저장 범위가 핵심 보안 쟁점

## 인사이트

AI 에이전트가 코드 생성 보조를 넘어 실제 업무 브라우저를 조작하는 단계로 넘어가는 신호임. 다만 권한 범위가 워낙 넓어서, 편의성보다 보안 운영 정책이 먼저 정리돼야 팀 단위 도입이 가능해 보임.