Codex App changelog 정리: Sites, Appshots, Computer Use 업데이트가 의미하는 것

• Codex App changelog를 기능 목록으로만 보면 놓치는 부분
• Sites preview: 생성 이후의 배포와 검사까지 이어지는 변화
• Appshots와 Computer Use: 화면 맥락을 넘기는 방식
• Browser use와 리뷰 흐름: 코드 작성 이후 검증 단계
• Windows와 모바일 접근성: 작업을 이어서 확인하는 방식
• 지금 바로 써볼 기능과 조심해서 볼 기능
• 정리

Codex App changelog를 기능 목록으로만 보면 놓치는 부분

Codex App changelog를 처음 보면 날짜, 버전, 기능명, 버그 수정 항목이 한꺼번에 들어와서 우선순위가 잘 보이지 않습니다. 2026년 6월 항목만 봐도 Sites, Profile section, Computer Use readiness, Appshot error reporting, terminal placement, iOS follow-up behavior, Windows SSH 연결이 같이 등장합니다. 기능명만 나열하면 흩어진 업데이트처럼 보이지만, 실제로는 개발자가 작업을 확인하는 방식이 Codex App 안으로 더 깊게 들어오는 변화입니다.

예전의 AI 코딩 도구를 “코드 초안을 빠르게 받는 도구”로만 보면 changelog에서 절반은 놓칩니다. 프론트엔드 작업에서는 코드를 받은 다음이 더 자주 문제입니다. 로컬 서버를 띄우고, 화면에서 간격을 보고, hover나 focus 상태를 확인하고, 모바일 폭에서 레이아웃이 터지는지 보고, 마지막으로 diff에서 불필요한 수정이 섞였는지 확인해야 합니다.

최근 Codex App 업데이트는 이 후반 작업을 조금씩 제품 안으로 끌어옵니다. 브라우저를 통해 결과를 보고, 데스크톱 앱의 현재 화면을 문맥으로 넘기고, 원격 기기의 작업 상태를 모바일에서 확인하고, 만든 웹사이트를 다시 열어 배포와 검사까지 이어가는 식입니다. 그래서 이 글에서는 changelog를 날짜순 번역으로 풀지 않고, 개발자가 체감할 수 있는 작업 단계 기준으로 묶어 봅니다.

읽는 기준은 두 가지면 충분합니다. 첫째, 이 기능이 내 개발 과정 중 어느 시간을 줄이는지 봅니다. 둘째, 그래도 직접 확인해야 하는 책임이 어디에 남는지 봅니다. Codex App이 화면을 보고 조작할 수 있는 범위가 넓어질수록 검수 기준도 같이 정교해져야 합니다.

Sites preview: 생성 이후의 배포와 검사까지 이어지는 변화

2026년 6월 2일 업데이트에서 가장 먼저 볼 항목은 Sites preview입니다. Sites는 Codex App 안에서 웹사이트, 대시보드, 내부 도구, 웹 앱, 게임을 만들고 저장하고 배포하고 검사할 수 있는 기능으로 소개되었습니다. 여기서 봐야 할 지점은 “웹페이지를 하나 만들어준다”가 아니라, 만든 결과물을 Codex App 사이드바에서 다시 열고 관리하는 작업 단위가 생겼다는 점입니다.

일반적인 프론트엔드 작업에서는 초안을 만드는 시간보다 그 다음 확인 과정이 더 길어질 때가 많습니다. 간단한 관리자 대시보드를 만든다고 해도 레이아웃, 반응형, 빈 데이터 상태, 버튼 위치, 필터 UI, 오류 메시지를 계속 만져야 합니다. Sites가 Codex App 안에 들어온다는 것은 이런 프로토타입을 대화 기록 안에만 남기지 않고, 다시 접근 가능한 프로젝트처럼 다루려는 방향입니다.

환경 변수와 secrets 관리가 함께 언급된 것도 눈여겨볼 부분입니다. 웹 앱은 화면만 예쁘면 끝나지 않습니다. API 키, 인증 정보, 외부 서비스 연결, 배포 환경 설정이 붙습니다. 이 항목은 “민감한 값을 마음대로 넣어도 된다”는 뜻이 아니라, 오히려 어떤 값이 공개되어도 되는지와 어떤 값이 비공개 설정으로 분리되어야 하는지 더 분명히 나눠야 한다는 신호입니다.

개인 프로젝트나 포트폴리오 기준으로 보면 Sites는 아이디어를 빠르게 시각화하는 용도로 먼저 접근하는 것이 현실적입니다. 쇼핑몰 카드 목록, 이벤트 신청 페이지, 간단한 예약 관리 화면처럼 형태를 먼저 잡아야 하는 작업에서는 시간을 줄일 수 있습니다. 반대로 운영 서비스의 최종 배포 도구처럼 바로 믿고 쓰기에는 확인할 것이 많습니다. 실제 데이터 연결, 접근 권한, 보안 설정, 에러 처리, SEO 기준은 별도 체크리스트로 남겨야 합니다.

Sites를 볼 때 확인할 기준

확인할 지점	실제 작업에서 보는 기준
초안 제작	랜딩 페이지, 대시보드, 내부 도구처럼 화면 구조를 빠르게 잡는 데 맞는지 확인합니다.
저장과 재접근	한 번 만든 결과물을 다시 열어 수정하고 이어서 관리할 수 있는지 봅니다.
배포	공유용 preview인지, 운영 배포 후보로 검토해도 되는 수준인지 구분합니다.
환경 변수	공개되어도 되는 값과 secrets로 분리해야 하는 값을 먼저 나눕니다.
검사	화면만 예쁜지보다 빈 상태, 오류 상태, 모바일 화면까지 확인합니다.

Appshots와 Computer Use: 화면 맥락을 넘기는 방식

2026년 5월 21일 업데이트에서는 Appshots, Goal mode, Remote computer use, 고급 in-app browser annotation이 함께 소개되었습니다. 이 중 Appshots와 Computer Use는 이름만 보면 비슷하지만 역할은 다릅니다. Appshots는 앞에 떠 있는 앱 창을 스크린샷과 가능한 텍스트 맥락으로 Codex에 넘기는 기능입니다. Computer Use는 Codex가 데스크톱 앱을 보고, 클릭하고, 입력하는 조작 범위까지 포함합니다.

Appshots는 “지금 화면이 이런데 이 상태를 보고 판단해줘”에 가깝습니다. 에디터, 브라우저, 디자인 툴, 오류 창을 말로 설명하기 애매할 때 화면 상태를 그대로 넘길 수 있습니다. 예를 들어 콘솔 오류와 화면 깨짐이 동시에 보이는 상황이라면, 긴 설명을 쓰는 것보다 현재 창을 문맥으로 넘기는 쪽이 빠릅니다.

Computer Use는 한 단계 더 들어갑니다. 화면을 이해하는 데서 멈추지 않고 실제 앱을 조작할 수 있습니다. 2026년 5월 29일 업데이트에서 Windows 지원이 추가되면서 이 기능은 macOS 중심의 흐름을 벗어나기 시작했습니다. Windows에서 VS Code, PowerShell, 브라우저, 로컬 앱을 함께 쓰는 개발자라면 체감 지점이 생깁니다.

다만 이 기능을 “알아서 다 해주는 자동 조작”으로 받아들이면 위험합니다. 화면을 보고 클릭할 수 있다는 것은 권한과 실수의 범위도 넓어진다는 뜻입니다. 파일 삭제, 환경 설정 변경, 계정 정보 입력, 결제, 운영 배포처럼 되돌리기 어려운 작업은 지시 범위를 먼저 좁혀야 합니다. AI가 화면을 볼 수 있게 되는 순간, 편해지는 만큼 확인 책임도 같이 커집니다.

Appshots와 Computer Use의 차이

구분	주된 역할	주의할 점
Appshots	현재 앱 화면과 텍스트 맥락을 Codex에 전달합니다.	화면에 민감정보가 보이는지 먼저 확인해야 합니다.
Computer Use	Codex가 데스크톱 앱을 보고 클릭하고 입력할 수 있습니다.	조작 범위와 권한을 제한해야 합니다.
Remote computer use	원격 환경에서도 작업을 이어갈 수 있게 합니다.	신뢰할 수 있는 작업인지, 승인 흐름이 있는지 확인해야 합니다.

Browser use와 리뷰 흐름: 코드 작성 이후 검증 단계

프론트엔드 작업에서 AI가 코드를 만들어주는 것만으로는 부족합니다. 화면이 실제로 의도대로 보이는지 확인해야 하기 때문입니다. Codex App changelog에서 browser use, in-app browser, Chrome context capture, review UI 개선이 반복해서 나오는 이유도 여기에 있습니다.

로컬 개발 서버를 띄운 뒤 Codex가 브라우저에서 결과를 확인할 수 있다면, 단순 문법 오류를 넘어 시각적인 문제까지 작업 범위에 넣을 수 있습니다. 카드 간격이 어색하거나, 모달이 화면 아래로 밀리거나, 버튼 색상이 디자인 기준과 맞지 않는 문제는 코드만 봐서는 바로 드러나지 않습니다. 브라우저 확인이 붙으면 이런 문제를 “코드 수정 요청”이 아니라 “화면 상태 기반 수정”으로 다룰 수 있습니다.

고급 in-app browser annotations도 이 맥락과 연결됩니다. 화면 위에서 폰트 크기, 색상, 간격 같은 지점을 직접 표시할 수 있으면, “이 부분이 좀 이상해요”보다 훨씬 명확한 피드백을 줄 수 있습니다. 퍼블리싱이나 프론트엔드 UI 수정에서는 설명이 모호할수록 결과가 흔들립니다. annotation은 그 흔들림을 줄이는 장치입니다.

Review UI 개선도 가볍게 넘길 내용은 아닙니다. AI가 만든 코드는 결과 화면보다 변경 범위가 더 중요할 때가 있습니다. 의도한 컴포넌트 하나만 바꿨는지, 공통 스타일을 건드렸는지, 관련 없는 파일까지 수정했는지 diff에서 확인해야 합니다. Codex App이 diff stat 정렬, review UI, PR 흐름을 계속 손보는 것은 코드 생성 이후의 검토 단계를 제품의 핵심 사용 흐름으로 보고 있다는 뜻입니다.

브라우저 검증에서 바로 확인할 부분

Codex에게 UI 수정을 맡겼다면 결과를 받을 때 바로 세 가지를 봐야 합니다. 첫째는 화면 크기입니다. 데스크톱에서 맞아 보여도 모바일에서 카드가 터질 수 있습니다. 둘째는 상태입니다. 데이터가 있을 때만 보지 말고 로딩, 빈 데이터, 오류 상태를 같이 확인해야 합니다. 셋째는 변경 범위입니다. 버튼 하나를 고쳤는데 전체 테마나 공통 컴포넌트가 바뀌었다면 다시 좁혀야 합니다.

Windows와 모바일 접근성: 작업을 이어서 확인하는 방식

2026년 5월 29일 업데이트에서는 Computer Use가 Windows에서 동작하고, Windows 기기를 원격 제어 대상으로 사용할 수 있다는 내용이 포함되었습니다. 이 변화는 Windows 개발자에게 특히 큽니다. AI 개발 도구의 일부 데스크톱 기능은 macOS에 먼저 제공되는 경우가 많았고, Windows 사용자는 WSL이나 별도 환경을 끼워 맞춰야 할 때가 있었습니다.

Codex App은 2026년 3월 Windows 앱 제공 시점에 PowerShell과 native Windows sandbox를 사용하는 방향을 안내했습니다. 즉, Windows에서 Codex를 쓰기 위해 꼭 WSL이나 가상 머신으로 작업을 옮기지 않아도 되는 기반이 만들어졌습니다. 이미 Windows에서 VS Code, PowerShell, 브라우저, 로컬 서버 중심으로 개발하는 사람에게는 이 차이가 직접적입니다.

모바일 접근성도 같은 축에 있습니다. ChatGPT for iOS 업데이트에는 Codex 잠금, follow-up 동작 설정, diff line wrapping, Windows machine SSH 연결 지원이 포함되었습니다. 이건 작은 화면에서 복잡한 개발을 끝내라는 의미보다, 실행 중인 작업을 확인하고, 방향을 조정하고, 필요한 경우 원격 host 연결을 이어가는 기능으로 보는 편이 현실적입니다.

특히 오래 걸리는 AI 작업은 중간 확인 지점이 있어야 합니다. 처음에는 “이 컴포넌트만 수정해줘”라고 했는데, 시간이 지나면서 테스트 추가, 스타일 정리, 파일 이동까지 작업이 넓어질 수 있습니다. 모바일에서 진행 상태를 보거나 원격 연결로 작업을 확인하는 기능은 이런 이탈을 늦게 발견하지 않게 만드는 장치로 쓸 수 있습니다.

지금 바로 써볼 기능과 조심해서 볼 기능

Codex App 업데이트를 모두 같은 무게로 받아들일 필요는 없습니다. 개인 개발자가 바로 써도 부담이 적은 기능이 있고, 팀 권한이나 보안 기준을 먼저 확인해야 하는 기능이 있습니다. 이 구분 없이 “새 기능이니까 써봐야겠다”로 접근하면 오히려 작업 흐름이 복잡해집니다.

바로 써볼 만한 기능은 브라우저 검증, review UI, terminal placement, Appshots 같은 영역입니다. 기존 작업 방식을 크게 흔들지 않으면서 피드백 속도를 줄여주기 때문입니다. 예를 들어 터미널이 오른쪽 패널에 열릴지 하단 패널에 열릴지 정하는 기능은 작아 보이지만, 실제로는 코드와 실행 로그를 동시에 보는 방식에 영향을 줍니다.

반면 Sites의 secrets, plugin sharing, remote computer use, Windows remote control, access token과 관련된 기능은 조금 더 보수적으로 봐야 합니다. 팀에서 사용할 경우 누가 어떤 권한을 갖는지, 어떤 플러그인을 공유할 수 있는지, 원격 제어가 언제 허용되는지 정해야 합니다. 회사 프로젝트나 고객 데이터가 있는 환경에서는 기능 사용 여부보다 승인 흐름과 로그 확인이 먼저입니다.

개인 프로젝트에서도 기준은 필요합니다. 포트폴리오용 랜딩 페이지 초안을 Sites로 만들 수는 있지만, 실제 공개 전에는 접근성, 메타 태그, 이미지 alt, 반응형, 폼 검증, 외부 API 키 노출 여부를 직접 확인해야 합니다. Codex가 만든 결과물은 출발점이지 검수 완료 상태가 아닙니다.

기능별 적용 기준

기능 영역	먼저 써볼 상황	직접 확인할 부분
Sites	프로토타입, 내부 도구, 포트폴리오 초안 제작	배포 범위, secrets 관리, 접근 권한, SEO
Appshots	화면 상태를 말로 설명하기 어려울 때	스크린샷 안의 민감정보
Computer Use	반복 조작이나 데스크톱 앱 흐름을 맡길 때	파일 변경, 계정 정보, 승인 범위
Browser use	UI 수정 결과를 브라우저에서 확인할 때	반응형, 상태별 화면, 실제 사용자 흐름
Review UI	AI가 수정한 diff를 검토할 때	관련 없는 파일 수정 여부와 변경 범위
모바일 원격 확인	진행 중인 작업을 밖에서 확인할 때	작은 화면에서 놓칠 수 있는 코드 변경

정리

Codex App changelog의 핵심은 기능이 많아졌다는 사실만이 아닙니다. 2026년 6월 기준 업데이트 흐름을 보면 Codex App은 코드 생성기에서 개발 작업 공간으로 이동하고 있습니다. Sites는 생성한 결과물을 저장하고 배포하고 검사하는 방향을 보여주고, Appshots와 Computer Use는 다른 앱과 데스크톱 화면을 작업 맥락으로 끌어옵니다. Browser use와 review UI는 코드가 만들어진 뒤 실제 화면과 diff를 확인하는 단계를 더 앞에 둡니다.

개발자가 이 변화를 볼 때 기준은 단순합니다. Codex에게 맡길 수 있는 단계와 직접 확인해야 하는 단계를 나눠야 합니다. 화면 초안, 반복 수정, 브라우저 확인, diff 정리는 Codex가 도와줄 수 있습니다. 하지만 보안 설정, 배포 판단, 민감정보 처리, 최종 품질 검수는 여전히 개발자의 몫입니다.

앞으로 Codex App 업데이트를 볼 때는 기능 이름보다 작업 단계를 먼저 보면 됩니다. 내가 하던 개발 과정 중 어느 단계가 Codex 안으로 들어왔는지, 그리고 그 단계가 내 프로젝트에서 실제로 시간을 줄여줄지 확인하면 됩니다. 그렇게 보면 changelog는 단순 릴리즈 노트가 아니라, AI 코딩 도구가 어디까지 개발 환경으로 들어오고 있는지 보여주는 기록에 가까워집니다.

참고 자료

OpenAI Developers의 Codex changelog, Sites, Appshots, Computer Use, In-app browser, Windows 관련 문서를 기준으로 업데이트 항목과 기능 범위를 확인했습니다.