Codex·Claude Code 데스크톱 앱과 CLI, 작업공간 통제는 어디서 갈리나

코딩 에이전트를 앱으로 열면 편하고, 터미널에서 실행하면 더 통제하기 쉬울까? Codex와 Claude Code를 두 방식으로 써본 사람들의 선택은 갈렸지만, 핵심은 화면 모양보다 어디서 실행하고 어떤 파일에 접근하도록 허용했는가에 있다.

앱과 CLI는 같은 일을 다른 방식으로 보여준다

OpenAI는 Codex 앱을 여러 작업을 감독하는 화면으로 소개한다. 프로젝트별 대화에서 변경 내용을 확인하고 diff에 의견을 달거나 편집기로 열 수 있다. 내장된 Git worktree를 선택하면 같은 저장소의 작업도 별도 복사본에서 진행한다. 앱은 기존 Codex CLI의 세션 기록과 설정도 이어받는다. (openai.com)

Codex CLI의 중심은 터미널 안에서 코드를 살펴보고 수정한 뒤 테스트하는 흐름이다. OpenAI 공식 안내는 대화형 작업뿐 아니라 codex exec를 이용한 스크립트·CI 실행도 CLI의 용도로 꼽는다. 한 작업의 명령과 결과를 연달아 확인하려면 터미널이 자연스럽다. 여러 작업의 상태와 diff를 한눈에 비교하려면 앱이 편하다. (developers.openai.com)

Claude Code에서도 앱의 Code 탭과 CLI를 완전히 다른 코딩 제품으로 볼 필요는 없다. Anthropic 문서에 따르면 데스크톱 Code 탭은 CLI와 같은 기반 엔진을 사용한다. 앱은 세션을 나란히 놓고 변경 사항을 시각적으로 검토할 때, CLI는 스크립트와 자동화를 실행할 때 적합하다고 설명한다. 다만 데스크톱 앱의 Chat·Code·Cowork 탭을 모두 같은 실행 환경으로 뭉뚱그려서는 안 된다. 이 비교의 대상은 코딩 작업을 수행하는 Code 탭이다. (code.claude.com)

폴더를 골랐다는 사실만으로 접근이 차단되지는 않는다

커뮤니티에서는 CLI를 별도 작업공간에서 실행한다는 경험이 공유됐다. 필요한 자료만 그곳에 두고 운영 중인 서버와 분리하려는 방식이다. 중요한 것은 터미널이라는 외형이 아니다. 에이전트가 실행되는 환경과 권한의 경계를 따로 마련했다는 점이다.

OpenAI의 Codex 설명에 따르면 기본 샌드박스는 작업공간 안의 쓰기를 제한하고, 네트워크 사용처럼 경계 밖에서 이뤄지는 행동에는 승인을 요구한다. 그러나 OpenAI의 보안 설명은 읽기와 쓰기를 구분한다. Codex의 기본 로컬 설정에서는 작업공간 밖 파일도 읽을 수 있는 범위가 있다. 따라서 폴더 하나를 선택했다고 다른 파일의 읽기까지 모두 막혔다고 가정해서는 안 된다. 샌드박스와 승인 설정은 앱·CLI·IDE 확장에 걸쳐 적용될 수 있다. (openai.com)

Claude Code 역시 작업 디렉터리를 출발점으로 삼는다. 폴더 밖 읽기를 더 엄격하게 막으려면 별도 권한 설정이 필요하다. Anthropic은 도구별 허용·거부 규칙과 운영체제 수준의 셸 샌드박스를 서로 다른 보호 층으로 구분한다. 파일을 읽는 도구를 제한해도 셸 명령의 경계까지 자동으로 같아지는 것은 아니다. 작업공간을 좁히는 실천은 유효하지만, 경계가 실제로 적용됐는지는 제품별 설정에서 확인해야 한다. (code.claude.com)

앱에서도 작업을 격리하고 실행 위치를 고를 수 있다

CLI만이 분리된 작업공간을 만들 수 있다는 생각은 현재 제품 기능과 다르다. Codex 앱은 Git worktree로 병렬 작업을 나눈다. Claude Code 데스크톱 Code 탭도 새 세션에서 worktree를 선택할 수 있다. worktree는 서로 다른 코드 변경이 충돌하지 않게 돕지만, 그 자체가 서버 접속이나 모든 파일 읽기를 차단하는 보안 장벽은 아니다. (openai.com)

실행 위치도 먼저 봐야 한다. Anthropic 문서는 데스크톱 Code 탭의 Local 세션은 사용자 컴퓨터에서, Cloud 세션은 Anthropic이 관리하는 환경에서 실행된다고 명시한다. SSH 세션은 연결한 원격 기계에서 돌아간다. 같은 앱 화면이라도 어느 환경을 골랐느냐에 따라 접근하는 파일과 도구가 달라진다. (code.claude.com)

소규모 팀이라면 화면 취향보다 이 차이가 실무에 직접 닿는다. 공유 저장소의 두 수정안을 비교할 때는 worktree와 diff 화면이 도움이 된다. 반면 운영 자료가 섞인 기계에서 작업한다면 앱이든 CLI든 필요한 파일만 들어 있는 별도 실행 환경이 더 분명한 경계다. OpenAI도 에이전트가 실행 환경에 제공된 파일·자격증명·네트워크에 접근할 수 있다고 설명한다. (developers.openai.com)

반복 실행은 CLI, 여러 변경 검토는 앱이 선명하다

작업이 끝난 뒤 무엇을 확인해야 하는지도 선택을 가른다. CLI에서는 에이전트가 실행한 명령과 테스트 결과, 후속 지시를 한 터미널 흐름에서 따라갈 수 있다. Codex는 비대화형 실행을 반복 작업에 연결할 수 있고, Claude Code도 CLI에서 스크립트와 자동화를 지원한다. 같은 검사를 자주 돌리는 개인 개발자라면 이런 연결이 앱 화면보다 실질적인 이점일 수 있다. (developers.openai.com)

반대로 동시에 진행한 기능 수정과 버그 수정을 검토할 때는 화면이 역할을 한다. Codex 앱은 스레드 안에서 diff를 보여주고, Claude Code 데스크톱은 여러 세션을 한 창에서 관리한다. 써본 사람들 사이에서도 터미널의 연속적인 작업 흐름을 선호하는 의견과 앱의 세션·변경 목록이 더 읽기 쉽다는 의견이 함께 나온다. 어느 쪽이 코드 품질을 높인다는 근거로 받아들일 이야기는 아니다.

메모리 우려는 측정값 없이 우열로 만들기 어렵다

커뮤니티에서는 데스크톱 앱이 메모리를 더 쓸 수 있다는 걱정도 나왔다. 실제 사용 반응에는 앱이 무겁다는 경험이 있지만 환경과 함께 실행한 작업이 제각각이다. 조사한 공식 자료만으로 Codex와 Claude Code의 앱·CLI 메모리 사용량을 동일 조건에서 비교할 수는 없었다. 특정 제품의 하자나 CLI의 일정한 성능 우위로 단정할 근거도 부족하다.

선택은 두 질문으로 좁혀진다. 여러 세션의 변경을 시각적으로 검토해야 하는가, 아니면 명령과 테스트를 반복 가능한 흐름에 묶어야 하는가? 더 중요한 질문도 남는다. 선택한 화면 뒤에서 에이전트가 실제로 접근할 수 있는 파일, 명령, 네트워크는 어디까지인가.