Codex Chrome extension 사용법 2026 – 로그인 웹사이트 작업과 인앱 브라우저 구분표

Posted on by

OpenAI Codex Chrome extension은 로그인된 Chrome 상태가 필요한 웹 작업을 Codex가 수행하게 해주는 확장 기능이다. 2026년 5월 8일 KST 기준 OpenAI 공식 문서는 이 확장을 Gmail, Salesforce, LinkedIn, 내부 도구처럼 로그인 컨텍스트가 필요한 사이트에 쓰라고 설명한다. 반대로 localhost, 파일 기반 미리보기, 로그인 없는 공개 페이지는 Codex 인앱 브라우저를 먼저 쓰는 흐름이 기본이다.

나도 처음엔 이걸 보고 살짝 헷갈렸다. Chrome 확장을 켜면 Codex가 더 강해지는 건가, 아니면 그냥 브라우저를 하나 더 붙이는 건가. 이런 도구는 이름보다 경계가 중요하다.

Codex Chrome extension을 제대로 이해하려면 설치 버튼보다 먼저 질문을 바꿔야 한다. “이걸 어떻게 설치하지?”보다 “이 작업은 내 로그인 세션이 필요한가?”를 먼저 물어야 한다. 여기서 답이 갈리면 어떤 브라우저를 쓸지도 거의 자동으로 정해진다.

이 글은 Codex Chrome extension을 처음 켜는 사람을 위한 사용법 글이다. 다만 설치 순서만 적으면 너무 얇다. 실제로 중요한 건 Chrome 확장, 인앱 브라우저, 플러그인, 웹사이트 허용 설정, 브라우저 히스토리 권한을 어디까지 나눌지다.

AI 브라우저 자동화는 편하다. 그리고 편한 기능은 보통 권한을 먹고 자란다. 권한을 어디에 줄지 모르면 생산성 도구가 갑자기 “내 계정으로 로그인한 손”이 된다.

먼저 잡을 기준

Codex Chrome extension은 모든 웹 작업의 기본값이 아니다. 로그인된 Chrome 프로필, 쿠키, 기존 세션, Chrome 확장, 내부 사이트 접근이 필요한 작업에서 쓰는 도구다. 일반적인 로컬 개발 검증이나 공개 페이지 확인은 인앱 브라우저가 더 자연스럽다.

작업 상황 먼저 쓸 도구 이유
localhost 웹앱 확인 Codex 인앱 브라우저 로그인 없는 개발 서버 검증에 적합
파일 기반 HTML 미리보기 Codex 인앱 브라우저 Codex 안에서 렌더링 상태를 같이 볼 수 있음
공개 웹페이지 확인 Codex 인앱 브라우저 Chrome 프로필을 쓸 이유가 적음
Gmail, CRM, 내부 admin Chrome extension 로그인 세션과 사용자 Chrome 상태가 필요
기존 Chrome 확장이 필요한 페이지 Chrome extension 인앱 브라우저는 일반 Chrome 확장을 쓰지 않음
이미 열어둔 Chrome 맥락이 중요한 작업 Chrome extension 실제 Chrome 프로필 기반으로 작업 가능

한 줄로 줄이면 이렇다. Codex가 “로그인된 내 브라우저”를 써야 하면 Chrome extension이다. Codex가 “그냥 페이지를 보고 클릭해도 되는 웹 미리보기”를 하면 인앱 브라우저다.

이 차이를 모르면 쓸데없이 Chrome 확장을 열게 된다. 그러면 Gmail, 사내 도구, 브라우저 히스토리처럼 민감한 영역과 단순 UI 검증이 한 바구니에 들어간다. 바구니가 커지면 편하지만, 넘쳤을 때 정리할 것도 커진다.

Codex Chrome extension이 하는 일

OpenAI 문서 기준으로 Codex Chrome extension의 핵심 역할은 Codex가 Chrome을 사용할 수 있게 하는 것이다. 여기서 Chrome은 그냥 새 브라우저 창이 아니라, 사용자가 실제로 로그인해 쓰는 Chrome 프로필에 가까운 의미다. 그래서 Gmail, Salesforce, LinkedIn, 내부 업무 도구 같은 예시가 나온다.

예를 들어 Codex에게 “이 콜 노트를 보고 CRM 계정 정보를 업데이트해줘”라고 맡긴다고 해보자. CRM은 보통 로그인이 필요하고, 조직 권한도 필요하고, 페이지 안에서 여러 클릭이 필요하다. 이때 인앱 브라우저는 로그인 세션이 없으니 바로 막힌다.

Chrome extension은 이 빈칸을 메운다. Codex가 사용자의 Chrome에서 필요한 페이지를 보고, 클릭하고, 입력하는 작업을 수행할 수 있게 한다. 물론 이 말은 곧 권한 관리가 중요하다는 뜻이기도 하다.

중요한 점은 “Codex가 Chrome을 사용할 수 있다”와 “Codex가 모든 사이트를 마음대로 사용해도 된다”는 말이 다르다는 것이다. OpenAI 문서는 기본적으로 새 웹사이트마다 Codex가 사용 허가를 묻는 구조를 설명한다. 즉, 확장을 설치했다고 해서 모든 문이 자동으로 활짝 열리는 구조로 이해하면 안 된다.

인앱 브라우저와 뭐가 다른가

Codex 인앱 브라우저는 Codex thread 안에서 렌더링된 웹페이지를 같이 보는 장치다. 로컬 개발 서버를 띄우고, 화면 깨짐을 확인하고, 버튼이 삐져나왔는지 보고, 브라우저 코멘트를 남기는 작업에 잘 맞는다. 프론트엔드 작업할 때는 이쪽이 더 자연스럽다.

반대로 인앱 브라우저는 로그인 흐름, 기존 Chrome 쿠키, 사용자의 Chrome 프로필, Chrome 확장, 기존 탭을 쓰는 도구가 아니다. 그래서 로그인해야 볼 수 있는 페이지에서는 한계가 분명하다. 이런 페이지가 나오면 Chrome extension이 후보가 된다.

이 구분은 실무에서 꽤 중요하다. 내가 만든 앱의 /settings 화면이 모바일에서 깨지는지 보는 일은 인앱 브라우저가 맞다. 회사 CRM에 로그인해서 고객 계정 메모를 업데이트하는 일은 Chrome extension 쪽이다.

기준 인앱 브라우저 Chrome extension
위치 Codex 앱 안 사용자의 Chrome
로그인 세션 기본적으로 없음 사용자의 Chrome 세션 활용
로컬 개발 서버 잘 맞음 굳이 필요 없는 경우 많음
Chrome 확장 의존 페이지 부적합 적합
내부 도구 로그인 없으면 가능, 로그인 필요하면 한계 적합
보안 감각 비교적 좁은 실험 공간 실제 계정 권한과 가까움

개발자는 보통 localhost를 많이 본다. 그래서 프론트엔드 수정 검증은 인앱 브라우저를 먼저 쓰는 편이 깔끔하다. Chrome extension은 “로그인 때문에 어쩔 수 없이 실제 Chrome이 필요할 때” 꺼내는 카드에 가깝다.

이 정도만 기억해도 절반은 먹고 들어간다. 브라우저 자동화에서 제일 흔한 실수는 기능을 많이 켜는 게 아니라, 같은 권한으로 너무 다양한 일을 처리하는 것이다. 도구를 나누면 사고 범위도 줄어든다.

설치 순서

Codex Chrome extension은 Codex 앱의 Plugins 흐름에서 시작한다. Chrome 웹스토어에서 아무 확장이나 찾듯 시작하는 게 아니라, Codex 안에서 Chrome plugin을 추가하는 흐름으로 보는 것이 맞다. 공식 문서의 설치 흐름도 이 순서다.

  1. Codex 앱을 연다.
  2. Plugins로 이동한다.
  3. Chrome plugin을 추가한다.
  4. 안내되는 설정 흐름을 따라 Chrome extension을 설치하거나 연결한다.
  5. Chrome이 요구하는 권한 prompt를 확인하고 승인한다.
  6. Chrome을 열고 Codex extension 상태가 Connected인지 확인한다.
  7. 설정이 끝나면 새 Codex thread에서 Chrome 작업을 시도한다.

여기서 “새 thread”가 은근 중요하다. 확장을 붙인 직후 기존 thread에서 애매하게 연결 상태가 꼬일 수 있다. 문서도 설정 완료 뒤 새 Codex thread를 시작하는 흐름을 안내한다.

설치 확인의 핵심은 Connected 상태다. 확장이 설치되어 있어도 연결이 끊겨 있으면 Codex가 Chrome을 제대로 쓰지 못한다. Toolbar의 Codex extension 화면에서 연결 상태를 먼저 확인하자.

첫 프롬프트는 이렇게 작게 시작한다

처음부터 CRM 수정, Gmail 발송, 내부 어드민 업데이트를 맡기면 부담이 크다. 브라우저 자동화는 “읽기 → 확인 → 작은 입력 → 저장 전 확인” 순서로 넓히는 게 좋다. 처음에는 실제 변경이 없는 읽기 작업부터 시작하는 편이 안전하다.

예시는 이렇게 잡을 수 있다.

@Chrome Gmail에서 오늘 온 OpenAI 관련 메일 제목만 확인하고, 내용을 수정하거나 답장하지 말고 요약해줘.

@Chrome 내부 대시보드의 오늘 오류 카운트만 확인해줘. 어떤 버튼도 누르지 말고 숫자와 페이지 URL만 알려줘.

@Chrome Salesforce에서 ACME 계정 페이지를 열고 현재 상태 필드만 읽어줘. 저장 버튼은 누르지 마.

처음에는 “하지 말아야 할 일”을 같이 쓰는 것이 좋다. 답장하지 마, 저장하지 마, 삭제하지 마, 다운로드하지 마 같은 금지 조건은 브라우저 자동화에서 아주 현실적인 안전장치다. 사람도 웹페이지 앞에서는 실수하는데 AI라고 갑자기 손가락이 천사가 되는 건 아니다.

읽기가 안정되면 다음 단계로 넘어간다. 예를 들어 “입력란에 초안을 채우되, 저장 버튼은 누르기 전에 멈춰줘”가 좋다. 이러면 Codex가 일을 진행하되 최종 책임은 사람이 닫을 수 있다.

웹사이트 접근 허용 방식

OpenAI 문서 기준으로 Codex는 기본적으로 새 웹사이트와 상호작용하기 전에 사용자에게 묻는다. 허용 기준은 대체로 host 단위다. 예를 들어 example.com 같은 도메인을 기준으로 허용 여부를 판단하는 흐름이다.

Codex가 어떤 사이트를 쓰겠다고 물으면 세 가지 선택지가 있다. 현재 chat에서만 허용할 수 있다. 해당 host를 항상 허용할 수 있다. 아예 거절할 수도 있다.

이 선택은 작업 성격에 맞춰야 한다. 공개 문서 페이지를 읽는 정도라면 현재 chat 허용으로 충분한 경우가 많다. 매일 보는 내부 대시보드라면 allowlist에 넣을 수도 있다.

하지만 Gmail, 결제, 고객정보, 관리자 콘솔 같은 사이트는 “항상 허용”을 가볍게 누르면 안 된다. 항상 허용은 다음부터 마찰을 줄여준다. 마찰을 줄인다는 건 때로 안전장치도 줄어든다는 뜻이다.

사이트 유형 권장 선택
공개 문서 현재 chat 허용 또는 필요 시 항상 허용
localhost 대체 불가 페이지 보통 인앱 브라우저 우선
사내 읽기 전용 대시보드 현재 chat 허용 후 반복 업무면 allowlist 검토
Gmail, CRM, CMS 현재 chat 허용부터 시작
결제, 금융, 관리자 삭제 기능 기본 거절 또는 사람이 직접 처리
고객 데이터 export 화면 자동 작업 금지에 가깝게 관리

Computer Use settings에서는 allowlist와 blocklist를 관리할 수 있다. allowlist에 있는 도메인은 다시 묻지 않고 사용할 수 있다. blocklist에 있는 도메인은 Codex가 쓰지 않는 방향으로 막을 수 있다.

나중에 정책을 바꾸는 것도 가능하다. allowlist에서 도메인을 제거하면 Codex가 다시 물어본다. blocklist에서 도메인을 제거하면 영구 차단 대신 다시 허용 여부를 묻는 상태가 된다.

always allow browser content는 조심해서 본다

문서에는 always allow browser content 설정도 나온다. 이 설정을 켜면 Codex가 웹사이트 사용 전에 매번 확인을 구하지 않는 방향으로 움직인다. 편하긴 하다.

하지만 이건 고위험 설정으로 봐야 한다. 브라우저는 생각보다 민감한 데이터가 많이 지나가는 곳이다. 검색 기록, 내부 URL, 계정 화면, 고객정보, 업무 메모, 관리자 버튼이 한 화면 안에 섞인다.

AI 자동화에서 확인 prompt는 귀찮은 장애물이 아니다. 확인 prompt는 “지금 이 사이트를 AI에게 보여줘도 되는가?”를 한 번 더 묻는 마찰이다. 마찰이 항상 나쁜 건 아니다.

개인 실험용 Chrome 프로필이라면 리스크가 작을 수 있다. 하지만 업무용 Chrome 프로필이나 여러 계정이 로그인된 브라우저라면 이야기가 달라진다. 항상 허용은 정말 자주 쓰는 낮은 위험 사이트부터 제한적으로 검토하는 편이 낫다.

브라우저 히스토리 접근은 별도 권한으로 본다

브라우저 히스토리는 그냥 방문 기록이 아니다. 내부 서비스 URL, 검색어, 활동 흔적, 다른 기기에서 동기화된 기록까지 포함될 수 있다. OpenAI 문서도 브라우저 히스토리를 민감한 영역으로 따로 설명한다.

Codex가 브라우저 히스토리를 쓰려고 하면 사용자에게 묻는다. 그리고 문서 기준으로 히스토리 접근에는 always allow 옵션이 없다. 요청 범위에 맞춰 스코프를 잡는 구조로 이해하면 된다.

히스토리는 편리하다. “아까 열었던 그 내부 페이지 찾아줘” 같은 요청에는 도움이 된다. 하지만 그 편리함 때문에 업무 흔적이 context로 들어갈 수 있다.

내 기준은 단순하다. 히스토리를 꼭 써야 하는 작업이면 목적과 기간을 좁힌다. 굳이 필요 없다면 히스토리 접근 없이 URL을 직접 알려주는 편이 낫다.

예를 들어 이렇게 쓰면 더 낫다.

@Chrome 브라우저 히스토리는 쓰지 말고, 내가 준 URL만 열어서 페이지 제목과 상태만 확인해줘.

@Chrome 최근 방문 기록에서 찾지 말고, 현재 열린 탭 그룹 안에서만 관련 페이지를 찾아줘.

브라우저 자동화는 기억력이 좋아질수록 민감해진다. 그래서 “더 많이 기억하게 하기”보다 “필요한 것만 보게 하기”가 더 좋은 운영 기준이 된다.

Chrome 권한 문구가 무섭게 보이는 이유

Chrome extension을 설치할 때 권한 prompt가 꽤 크게 보일 수 있다. 페이지 debugger 접근, 웹사이트 데이터 읽기와 변경, 브라우징 기록, 알림, 북마크, 다운로드, native application 통신, tab group 관리 같은 범주가 언급될 수 있다. 처음 보면 “이거 설치해도 되나?” 싶다.

그런데 이 권한은 확장이 브라우저 workflow를 수행하기 위한 기술적 능력에 가깝다. 중요한 건 Chrome 권한이 넓게 보인다고 해서 Codex가 모든 것을 무조건 실행한다는 뜻은 아니라는 점이다. Codex 쪽에는 별도의 확인 prompt, settings, allowlist, blocklist가 있다.

하지만 반대로도 봐야 한다. 기술적으로 넓은 권한이 가능한 확장이기 때문에, 사용자는 Codex 설정을 대충 넘기면 안 된다. Chrome permission prompt와 Codex confirmation은 서로 다른 층의 안전장치다.

권한 영역 실무적으로 봐야 할 질문
페이지 조작 이 사이트에서 Codex가 클릭해도 되는가
웹사이트 데이터 이 페이지에 민감 정보가 있는가
브라우저 기록 히스토리 접근이 정말 필요한가
다운로드 파일 다운로드가 업무상 필요한가
북마크 북마크 수정까지 맡길 이유가 있는가
tab group thread별 작업 구분에 도움이 되는가
native app 통신 Codex 앱과 연결 상태가 정상인가

권한을 무서워만 할 필요는 없다. 하지만 권한을 “설치했으니 끝”으로 보면 안 된다. AI 브라우저 자동화는 설치보다 운영 기준이 더 중요하다.

OpenAI가 무엇을 저장한다고 설명하나

OpenAI 문서는 Chrome extension을 통한 Chrome 행동 전체를 별도의 완전한 기록으로 저장하지 않는다고 설명한다. 대신 Codex context에 들어간 브라우저 활동은 저장 대상이 될 수 있다. 예를 들어 Codex가 읽은 페이지 텍스트, 스크린샷, tool call, 요약, 메시지, thread에 포함된 내용이 여기에 해당한다.

이 차이는 중요하다. “전체 Chrome 기록을 통째로 저장한다”는 말과는 다르다. 하지만 “Codex에게 보여준 내용은 thread context에 들어갈 수 있다”는 의미는 남는다.

그래서 브라우저 작업에는 최소 공개 원칙을 적용하는 게 좋다. 비밀키, seed phrase, 개인식별정보, 결제 정보, 고객 export 파일은 가능한 한 브라우저 작업에 넣지 않는다. 꼭 필요하다면 사용자가 옆에서 확인 prompt를 보며 진행해야 한다.

Codex Memories 설정도 같이 봐야 한다. 문서 기준으로 browser use는 Codex Memories 설정을 따른다. Memories가 켜져 있으면 관련 저장 기억을 사용할 수 있고, 꺼져 있으면 browser use에 memories를 쓰지 않는다.

메모리 기능은 생산성에 도움을 준다. 하지만 브라우저 작업에서는 기억이 곧 context다. 업무 계정과 개인 계정이 섞인 환경이라면 Memories 상태도 한 번 확인하는 편이 좋다.

파일 업로드가 필요할 때

Chrome 작업 중 파일 업로드가 필요한 경우가 있다. 예를 들어 CMS에 이미지 파일을 올리거나, 내부 도구에 CSV를 업로드하거나, 지원 티켓에 첨부파일을 넣는 작업이다. 이때 file URL 접근 권한이 막혀 있으면 업로드 workflow가 실패할 수 있다.

공식 문서는 Chrome extension 설정에서 file URL access를 허용하는 흐름을 안내한다. Chrome toolbar의 extensions 메뉴에서 Manage Extensions로 들어간다. Codex extension의 Details를 연다. Allow access to file URLs를 켠다.

다만 이것도 필요한 경우에만 켜는 편이 좋다. 파일 URL 접근은 로컬 파일과 브라우저 자동화의 경계에 걸린다. 업로드해야 할 파일이 명확할 때만 쓰고, 작업이 끝난 뒤 계속 켜둘지 다시 판단하자.

파일 업로드 프롬프트는 이렇게 좁히면 좋다.

@Chrome 내가 지정한 파일 하나만 업로드해줘. 다른 로컬 파일은 열지 말고, 업로드 후 제출 버튼 앞에서 멈춰줘.

@Chrome CMS 첨부 화면에 이 이미지 파일을 올리고 alt text 초안만 입력해줘. 발행은 내가 직접 할게.

여기서도 핵심은 마지막 버튼이다. 업로드는 맡길 수 있어도 제출, 발행, 전송은 사람이 닫는 흐름이 안전하다. 특히 공개 발행이나 고객에게 가는 메시지는 더 그렇다.

연결이 안 될 때 보는 순서

Codex가 Chrome에 연결하지 못하면 먼저 blocklist부터 확인하는 게 좋다. 접근하려는 사이트가 설정에서 차단되어 있으면 연결 자체보다 정책 때문에 막힌 것일 수 있다. 그다음 확장 상태를 본다.

문제 해결 순서는 이렇게 정리할 수 있다.

순서 확인할 것 의미
1 대상 웹사이트가 blocklist에 있는지 확인 정책 차단 여부 확인
2 Chrome toolbar에서 Codex extension 상태 확인 Connected인지 확인
3 Codex Plugins에서 Chrome plugin이 켜져 있는지 확인 Codex 쪽 plugin 활성화 확인
4 같은 Chrome profile을 쓰는지 확인 다른 프로필에 설치했을 수 있음
5 새 Codex thread에서 다시 시도 thread 연결 상태 꼬임 해소
6 Chrome과 Codex 재시작 일반 연결 문제 해소
7 extension 제거 후 plugin 재추가 native host 또는 연결 흐름 재설정
8 계속 실패하면 /feedback 사용 thread ID 포함해 지원 요청

여기서 Chrome profile 문제는 은근 자주 나올 수 있다. 업무용 프로필, 개인 프로필, 테스트 프로필을 나눠 쓰는 사람이라면 특히 그렇다. 확장을 설치한 프로필과 실제 작업하는 프로필이 다르면 Connected처럼 보여도 원하는 페이지를 못 쓸 수 있다.

native host 관련 메시지가 나오면 plugin 재설치 흐름을 다시 타는 게 낫다. 확장만 지웠다 깔기보다 Codex의 Plugins에서 Chrome plugin을 제거하고 다시 추가하는 쪽이 공식 문서 흐름에 맞다. 연결형 도구는 양쪽이 같이 맞아야 한다.

활용 예시 1: Gmail 요약과 답장 초안

Gmail은 Chrome extension이 필요한 대표적인 예시다. 로그인 세션이 필요하고, 실제 받은편지함에 접근해야 하며, 메일 내용은 공개 웹페이지가 아니다. 그래서 인앱 브라우저보다 Chrome extension 쪽이 자연스럽다.

다만 Gmail 작업은 단계별로 나눠야 한다. 첫 단계는 읽기와 요약이다. 두 번째 단계는 답장 초안 작성이다. 마지막 전송은 사람이 하는 편이 안전하다.

좋은 프롬프트는 이렇게 생겼다.

@Chrome Gmail에서 오늘 온 OpenAI 관련 메일 5개를 찾아 제목, 보낸 사람, 내가 해야 할 일을 표로 정리해줘. 답장은 보내지 마.

@Chrome 이 메일 thread에 답장 초안을 작성해줘. Draft까지만 만들고 send는 누르지 마.

이렇게 하면 Codex는 반복 읽기와 초안 작성 시간을 줄여준다. 하지만 최종 발송 책임은 사람이 유지한다. 메일은 한 번 나가면 “아차”가 바로 캘린더 초대와 회의로 돌아온다.

활용 예시 2: CRM과 세일즈 메모 정리

Salesforce 같은 CRM도 공식 문서의 대표 예시에 가깝다. 계정 페이지가 로그인 뒤에 있고, 고객 정보와 내부 필드가 섞여 있기 때문이다. Chrome extension을 쓰되 작업 범위를 좁혀야 한다.

가장 안전한 흐름은 call note를 기준으로 “업데이트 후보”를 만들고 사람이 확인하는 것이다. Codex가 바로 저장 버튼을 누르는 것보다, 필드별 변경안과 근거를 먼저 보여주게 하면 된다. CRM은 데이터 품질이 중요해서 자동 수정이 틀리면 나중에 파이프라인이 지저분해진다.

프롬프트는 이렇게 쓸 수 있다.

@Chrome Salesforce에서 ACME 계정을 열고 이 call note와 비교해 업데이트가 필요한 필드 후보를 알려줘. 저장하지 말고 변경안만 표로 보여줘.

@Chrome 내가 승인한 필드만 입력란에 반영해줘. Save 버튼을 누르기 전에는 멈춰줘.

작업을 둘로 나누면 검수 지점이 생긴다. AI가 빠르게 후보를 만들고, 사람은 business context를 보고 승인한다. 이게 브라우저 자동화의 제일 건강한 역할 분리다.

활용 예시 3: 내부 대시보드 점검

내부 대시보드는 Chrome extension과 잘 맞을 때가 많다. 로그인이 필요하고, 사내 네트워크나 SSO가 걸려 있고, 매번 같은 지표를 확인해야 하기 때문이다. 하지만 읽기 전용부터 시작해야 한다.

예를 들어 매일 아침 에러 카운트, 배치 실패 여부, 고객 문의 건수, 배포 상태를 확인하는 업무가 있다. 이런 일은 Codex가 페이지를 열어 숫자를 읽고 표로 정리하는 데 적합하다. 버튼을 누르거나 데이터를 수정하는 일과 분리하면 리스크가 낮다.

프롬프트 예시는 이렇게 잡는다.

@Chrome 내부 운영 대시보드에서 오늘 실패한 batch job 이름과 실패 시간을 읽어 표로 정리해줘. 재시작 버튼은 누르지 마.

@Chrome admin dashboard에서 warning 상태인 항목만 확인하고, 조치가 필요한 순서로 정리해줘. 페이지 변경은 하지 마.

이런 작업은 반복될수록 가치가 커진다. 다만 자동 재시작, 삭제, 계정 잠금 해제 같은 액션은 별도 승인 루프가 필요하다. 읽기와 쓰기를 섞는 순간 브라우저 자동화는 운영 도구가 아니라 원격 손가락이 된다.

활용 예시 4: 블로그 운영과 CMS

TECHTAEK 같은 블로그 운영에도 Chrome extension은 쓸 수 있다. WordPress admin, Search Console, AdSense, 뉴스레터 도구처럼 로그인된 웹 콘솔을 다뤄야 하는 경우가 있기 때문이다. 하지만 여기서도 발행 버튼은 조심해야 한다.

좋은 활용은 초안 관리와 점검이다. 예를 들어 WordPress 초안 목록에서 제목, slug, meta description 누락 여부를 확인하게 할 수 있다. Search Console에서 특정 글의 색인 상태나 검색어 노출을 확인하게 할 수도 있다.

프롬프트는 이렇게 쓴다.

@Chrome WordPress 초안 목록에서 Codex 관련 글만 찾아 제목, slug, meta description 입력 여부를 확인해줘. 발행하지 마.

@Chrome Search Console에서 techtaek.com의 Codex Chrome extension 관련 URL 상태를 확인하고, 색인 요청 버튼은 누르지 말고 상태만 알려줘.

이 흐름은 꽤 실전적이다. 블로그 운영에서 은근 시간을 잡아먹는 건 글쓰기보다 관리 화면 확인이다. Codex가 이런 반복 확인을 줄여주면 사람은 판단과 수정에 시간을 더 쓸 수 있다.

다만 AdSense, 결제, 광고 설정은 신중해야 한다. 돈이 직접 움직이는 화면은 읽기 전용으로 시작하는 게 좋다. 저장 버튼 앞에서 멈추게 하는 습관을 들이면 나중에 사고를 많이 줄일 수 있다.

활용 예시 5: 리서치와 LinkedIn

LinkedIn 같은 로그인 기반 리서치도 Chrome extension 후보가 될 수 있다. 프로필, 회사 페이지, 연결 관계, 메시지 화면이 로그인 뒤에 있기 때문이다. 다만 서비스 약관과 개인정보 경계를 반드시 봐야 한다.

Codex에게 시킬 수 있는 안전한 작업은 공개적으로 볼 수 있는 범위 안에서 요약하는 것이다. 예를 들어 특정 회사 페이지의 최근 업데이트 제목을 정리하거나, 이미 열린 프로필의 공개 요약을 정리하는 식이다. 대량 수집이나 자동 메시지 발송은 다른 문제다.

프롬프트는 이렇게 좁힌다.

@Chrome 내가 열어둔 LinkedIn 회사 페이지에서 최근 게시물 제목과 주제만 정리해줘. 메시지나 연결 요청은 보내지 마.

@Chrome 현재 열린 프로필의 공개 정보만 보고 미팅 준비 메모를 만들어줘. 다른 페이지로 이동하지 마.

브라우저 자동화는 “할 수 있다”와 “해도 된다”가 다르다. 특히 사람 계정과 연결된 서비스에서는 자동화의 편리함보다 플랫폼 규칙과 관계 리스크가 먼저다. AI가 대신 클릭한다고 해서 내 책임이 사라지는 건 아니다.

맡기면 안 되는 작업

Codex Chrome extension은 강력하지만 모든 웹 작업을 맡기는 도구는 아니다. 특히 돈, 법적 제출, 고객 데이터, 계정 보안, 대량 발송이 걸린 작업은 사람이 닫아야 한다. AI가 중간 정리까지 도와주는 것과 최종 실행을 맡기는 것은 다르다.

내 기준으로 아래 작업은 기본적으로 자동 실행 금지에 가깝다.

작업 이유
은행 이체 되돌리기 어렵고 금전 피해가 직접 발생
증권 매매 투자 판단과 주문 실행은 분리 필요
세금 신고 제출 법적 책임과 금액 오류 리스크 큼
고객 데이터 export 개인정보 유출 위험
대량 이메일 발송 관계, 법적, 평판 리스크
관리자 삭제 작업 복구 비용이 큼
password manager 조작 계정 보안 핵심 영역
API key 발급 화면 secret 노출과 권한 남용 위험

이런 작업에서도 Codex를 완전히 못 쓰는 건 아니다. 예를 들어 신고 화면의 안내 문구를 읽고 체크리스트를 만드는 일은 가능하다. 하지만 제출 버튼, 매수 버튼, 송금 버튼은 사람이 누르는 게 맞다.

AI에게 “마지막 버튼 앞에서 멈춰줘”라고 쓰는 습관은 생각보다 강력하다. 이 한 줄이 자동화와 책임 사이에 작은 문턱을 만든다. 작은 문턱이 없으면 사람은 어느 날 큰 계단에서 넘어진다.

내 기본 운영표

내가 Codex Chrome extension을 팀이나 개인 업무에 붙인다면 기본값은 이렇게 잡겠다. Chrome extension은 로그인된 웹 작업에만 쓰고, 나머지는 인앱 브라우저나 플러그인으로 분리한다. 그리고 첫 달은 allowlist를 아주 짧게 유지한다.

영역 기본 정책
공개 문서 읽기 인앱 브라우저 또는 일반 web context
localhost 검증 인앱 브라우저
Gmail 읽기 Chrome extension, 현재 chat 허용
Gmail 답장 draft까지만, send는 사람
CRM 업데이트 변경안 검토 후 입력, save 전 정지
내부 대시보드 읽기 전용부터 시작
CMS 초안 관리 저장 전 확인
Search Console 상태 확인 중심
AdSense와 결제 읽기 전용 또는 사용 안 함
browser history 기본 off, 필요할 때만 요청별 허용
file URL access 업로드 작업 때만 켜기

이 표의 핵심은 도구가 아니라 기본값이다. 좋은 자동화는 실행력이 센 자동화가 아니라 기본값이 덜 위험한 자동화다. 처음부터 넓게 열고 나중에 줄이는 것보다, 좁게 열고 필요한 만큼 넓히는 쪽이 운영하기 쉽다.

특히 allowlist는 천천히 늘리는 편이 좋다. 처음부터 자주 쓰는 모든 사이트를 항상 허용해두면 편하다. 하지만 나중에 어떤 사이트가 왜 허용됐는지 기억이 안 난다.

허용 목록은 작은 문서로 남겨두는 것도 좋다. 도메인, 용도, 허용 범위, 마지막 검토일을 적으면 된다. 팀에서는 이 기록이 나중에 감사 로그의 가벼운 출발점이 된다.

프롬프트 템플릿

처음 쓰는 사람은 프롬프트를 길게 쓰지 않아도 된다. 다만 작업 범위, 금지 행동, 멈출 지점을 명확히 적는 것이 좋다. 아래 템플릿만 있어도 대부분의 Chrome 작업을 안전하게 시작할 수 있다.

@Chrome [사이트/페이지]에서 [확인할 항목]만 확인해줘.
읽기만 하고, 입력·저장·전송·삭제는 하지 마.
결과는 표로 정리해줘.

@Chrome [사이트/페이지]에서 [입력할 초안]을 작성해줘.
저장 버튼을 누르기 전에 멈추고, 내가 확인할 수 있게 변경 내용을 요약해줘.

@Chrome [업무 목적]을 위해 [특정 URL]만 열어줘.
브라우저 히스토리는 사용하지 말고, 다른 탭으로 이동하지 마.
민감 정보가 보이면 작업을 멈추고 알려줘.

@Chrome [파일명] 하나만 업로드해줘.
다른 로컬 파일은 열지 말고, 제출 버튼은 누르지 마.
업로드 후 화면 상태를 알려줘.

이 템플릿의 핵심은 “만”과 “하지 마”다. AI에게 일을 잘 시키는 문장은 친절한 설명보다 경계가 선명하다. 경계가 선명하면 Codex도 덜 헤맨다.

팀에서 쓰기 전 체크리스트

개인 사용과 팀 사용은 다르다. 팀에서는 Chrome extension이 개인 생산성 도구이면서 동시에 회사 계정과 내부 데이터에 닿는 도구가 된다. 그래서 최소 체크리스트가 필요하다.

체크 항목 질문
계정 범위 개인 Chrome 프로필과 업무 Chrome 프로필이 분리되어 있는가
allowlist 항상 허용 도메인이 문서화되어 있는가
blocklist 금융, 결제, 고객 export 등 금지 도메인이 있는가
browser history 누가 어떤 상황에서 허용할 수 있는가
Memories 업무 브라우저 작업에서 memories 사용 기준이 있는가
파일 업로드 file URL access를 언제 켜고 끄는가
최종 실행 send, save, publish, delete 버튼은 누가 누르는가
감사 중요한 작업 결과가 thread나 문서에 남는가

팀에서 가장 위험한 문장은 “그냥 알아서 해줘”다. 사람에게도 위험한 문장인데 AI에게는 더 위험하다. 특히 브라우저는 버튼이 많고, 버튼 중 일부는 돈과 고객과 배포에 연결되어 있다.

정책은 거창할 필요 없다. 처음에는 “읽기는 가능, 쓰기는 초안까지만, 최종 실행은 사람” 정도로 시작해도 된다. 이 정도만 있어도 무작정 자동화하는 것보다 훨씬 낫다.

FAQ

Q. Codex Chrome extension을 켜면 인앱 브라우저는 안 써도 되나?

아니다. 둘은 대체재라기보다 용도가 다르다. localhost, 파일 미리보기, 공개 페이지 검증은 인앱 브라우저가 더 깔끔하다.

Chrome extension은 로그인된 Chrome 상태가 필요할 때 쓰는 쪽에 가깝다. 모든 작업을 Chrome으로 몰아넣으면 권한 경계가 흐려진다. 도구는 강한 쪽이 아니라 맞는 쪽을 쓰는 게 낫다.

Q. Chrome extension을 설치하면 Codex가 내 모든 사이트를 바로 쓰나?

기본 흐름은 새 웹사이트 사용 전에 확인을 묻는 방식이다. 사용자는 현재 chat 허용, host 항상 허용, 거절 중에서 고를 수 있다. allowlist와 blocklist도 설정에서 관리할 수 있다.

다만 항상 허용 계열 설정을 켜면 마찰이 줄어든다. 마찰이 줄어드는 만큼 검토 지점도 줄어든다. 그래서 민감 사이트에는 보수적으로 접근하는 것이 좋다.

Q. 브라우저 히스토리는 켜도 되나?

필요할 때만 켜는 편이 좋다. 히스토리에는 내부 URL, 검색어, 다른 기기 활동 흔적 같은 민감한 정보가 들어갈 수 있다. OpenAI 문서도 browser history를 별도 위험 영역으로 다룬다.

작업에 URL을 직접 줄 수 있다면 히스토리를 쓰지 않아도 된다. 히스토리를 써야 한다면 목적을 좁히고, 요청 단위로 허용하는 흐름이 낫다. 항상 허용 옵션이 없는 것도 그만큼 민감한 영역이라는 신호로 보면 된다.

Q. 파일 업로드는 어떻게 하나?

Chrome extension 세부 설정에서 file URL access를 허용해야 할 수 있다. Chrome의 Manage Extensions에서 Codex extension Details를 열고 관련 설정을 켜는 흐름이다. 설정을 바꾼 뒤에는 Chrome 작업을 다시 시작하는 편이 좋다.

파일 업로드는 가능하더라도 범위를 좁혀야 한다. 지정한 파일 하나만 올리게 하고, 제출이나 발행은 사람이 확인하는 흐름을 추천한다. 로컬 파일 접근은 생각보다 민감하다.

Q. 연결이 자꾸 끊기면 뭘 먼저 봐야 하나?

대상 사이트가 blocklist에 있는지 먼저 본다. 그다음 Chrome toolbar에서 Codex extension이 Connected인지 확인한다. Codex Plugins에서 Chrome plugin이 켜져 있는지도 확인한다.

Chrome profile도 중요하다. 확장을 설치한 프로필과 실제 로그인된 프로필이 다르면 작업이 꼬일 수 있다. 그래도 안 되면 새 thread, Chrome과 Codex 재시작, plugin 제거 후 재추가 순서로 보면 된다.

이 기능의 진짜 가치는 어디에 있나

Codex Chrome extension의 가치는 “AI가 브라우저를 클릭한다”에만 있지 않다. 진짜 가치는 로그인 뒤에 숨어 있던 반복 업무를 Codex workflow 안으로 끌어오는 데 있다. Gmail, CRM, CMS, 내부 대시보드 같은 곳에서 사람의 확인 시간을 줄일 수 있다.

하지만 이 기능은 생산성만큼이나 운영 감각이 중요하다. 브라우저는 코드 저장소보다 더 지저분한 작업 공간이다. 버튼, 광고, 알림, 개인정보, 검색 기록, 로그인 세션이 한데 섞인다.

그래서 나는 이 기능을 “강한 자동화”보다 “현실 웹 업무를 다루는 좁은 손”으로 보는 게 맞다고 생각한다. 손이 생겼으면 장갑도 필요하다. 그 장갑이 allowlist, blocklist, browser history 제한, 마지막 버튼 전 정지 같은 설정이다.

처음부터 완전 자동화를 목표로 잡지 말자. 먼저 읽기 작업을 맡긴다. 그다음 초안 입력을 맡긴다. 마지막 실행은 사람이 한다.

이 세 단계만 지켜도 Codex Chrome extension은 꽤 쓸 만한 업무 도구가 된다. 그리고 사고 날 확률도 많이 줄어든다. AI 도구는 똑똑함보다 기본값이 오래 간다.

오늘 적용할 5줄 요약

  1. 로그인된 Chrome 상태가 필요한 웹 작업이면 Codex Chrome extension을 쓴다.
  2. localhost, 파일 미리보기, 공개 페이지 검증은 인앱 브라우저를 먼저 쓴다.
  3. Chrome plugin 설치 후 extension 상태가 Connected인지 확인하고 새 thread에서 시작한다.
  4. allowlist는 천천히 늘리고, browser history와 file URL access는 필요할 때만 허용한다.
  5. send, save, publish, delete 같은 마지막 버튼은 사람이 누르는 기본값으로 시작한다.

이 기능을 잘 쓰면 Codex가 코드 편집기 밖으로 조금 나온다. 다만 나온 만큼 내 계정과 내 웹 작업에 가까워진다. 그래서 사용법의 핵심은 “어디까지 시킬 것인가”다.

설치는 10분이면 끝날 수 있다. 운영 기준은 조금 더 걸린다. 그런데 오래 쓰는 도구는 보통 설치보다 운영 기준에서 갈린다.

Codex Chrome extension은 잘 쓰면 귀찮은 웹 업무를 줄여준다. 막 쓰면 내 Chrome에 로그인된 모든 업무를 한 프롬프트에 올려버릴 수도 있다. 그러니 처음엔 작게, 읽기부터, 마지막 버튼 앞에서 멈추게.

이 정도면 생산성도 챙기고, 식은땀도 덜 흘린다. AI 시대에도 식은땀은 아직 로컬 실행이다. 가능하면 실행 횟수를 줄이자.

관련 글

출처