어디서 쓸 것인가: Web·Desktop App·CLI·VS Code 확장 비교

Codex는 "무슨 모델을 쓰느냐"만큼이나 "어디서 실행하느냐"가 중요합니다. 같은 Codex라도 실행 위치가 달라지면 파일을 어떻게 읽고 쓰는지, 어떤 권한으로 명령을 실행하는지, 결과물을 어떤 형태로 남기는지(세션/커밋/PR)가 달라집니다. 결국 도구 선택이 아니라 워크플로 전체의 선택이 됩니다.

이 챕터의 목표는 네 가지 표면(Web, Desktop App, CLI, VS Code 확장)을 "기능 나열"로 비교하는 것이 아니라, 당신의 일을 기준으로 선택할 수 있도록 선택 기준(프레임)을 만드는 것입니다.

'표면(surface)'은 인터페이스가 아니라 실행 환경이다

웹 화면이냐 터미널이냐는 겉모습의 차이처럼 보이지만, 실제로는 다음이 함께 바뀝니다.

• 컨텍스트의 출처: 열어 둔 파일/워크스페이스/레포 전체/업로드한 자료 등 무엇이 기본 맥락이 되는가

• 실행 권한과 경계: 로컬 파일 시스템을 직접 건드리는가, 샌드박스 안에서만 움직이는가

• 작업의 형태: 즉시 대화로 끝나는가, 백그라운드 태스크로 위임되는가, PR로 정리되는가

• 협업의 단위: 내 로컬 변경인가, 공유 가능한 세션인가, 팀이 리뷰하는 PR인가

따라서 "어디서 쓸 것인가"는 취향 문제가 아니라, 업무가 흘러가는 관문을 어디에 둘 것인가에 대한 결정입니다.

네 가지 표면을 한 문장으로 요약하기

Codex는 "가벼운 터미널 에이전트로 로컬에서 실행되며", ChatGPT 구독 기반 인증을 활용하고, VS Code 같은 IDE 확장을 제공하는 방향으로 소개됩니다.¹ 또한 Codex CLI는 협업(특히 GitHub)과 터미널/웹 양쪽 인터페이스를 강점으로 삼는 비교가 자주 등장합니다.²

비교 프레임: 4가지 기준만 잡으면 선택이 쉬워진다

네 가지 표면을 고를 때, 아래 네 가지 기준을 우선순위로 정해보세요. 이 네 가지가 "실행 위치가 워크플로를 결정한다"는 말을 가장 현실적으로 체감하게 해줍니다.

1) 로컬 편집이 중요한가, 결과물만 받으면 되는가

로컬 편집이 핵심인 사람에게 중요한 것은 "변경을 만들 수 있느냐"가 아니라, 내가 통제하는 파일 트리에서 자연스럽게 바뀌느냐입니다.

• CLI/VS Code는 로컬 레포와 붙어 있어, 변경→테스트→수정의 루프가 빠르게 닫힙니다.

• Web은 위임과 결과 수집에 유리하지만, 로컬에서 자주 열어보는 파일/터미널/디버거 흐름과는 거리가 생길 수 있습니다.

• Desktop App은 이 간극을 "GUI + 로컬 연동"으로 메우는 포지션이 됩니다. 웹처럼 접근성은 높이되, 로컬 파일과의 연결을 두려워하지 않는 쪽입니다.

일반적으로 데스크톱 앱은 로컬 자원을 더 잘 활용하고(파일 시스템, 하드웨어), 네트워크 품질에 덜 흔들리는 장점이 있습니다.³

2) 클라우드 위임(비동기)이 필요한가

Codex를 "비동기 코딩 에이전트"로 쓴다는 것은, 내가 코드를 치는 동안이 아니라 내가 다른 일을 하는 동안 작업이 진행된다는 뜻입니다. 이때 표면 선택은 다음을 결정합니다.

• 태스크를 쌓아두고 관리할 수 있는가(여러 작업의 상태/결과를 한 화면에서 보는가)

• 결과물을 팀 프로세스에 연결하는가(PR, 이슈, 리뷰)

Web 표면은 태스크 위임과 결과 수집에 가장 자연스럽습니다. 반대로 CLI는 "내가 있는 머신/레포"에서 계속 굴리는 자동화에 강합니다. 즉, 둘 다 비동기지만 성격이 다릅니다.

• Web의 비동기는 "클라우드에 맡기고 PR로 받기"에 가까워집니다.

• CLI의 비동기는 "내 환경에서 반복 실행(스크립트/작업 큐/CI)"에 가까워집니다.

Codex CLI가 GitHub 협업을 강점으로 소개되는 이유도, 결과를 PR/레포 흐름에 붙이기 쉬운 표면이기 때문입니다.²

3) 멀티태스크/병렬화가 필요한가

업무가 커질수록 병목은 "코드 작성"보다 "대기"에서 생깁니다. 빌드 기다리기, 테스트 기다리기, 리뷰 기다리기, 조사 기다리기 같은 대기들입니다. 멀티태스크는 이 대기를 흡수합니다.

• Web은 여러 태스크를 병렬로 던지고, 돌아온 결과를 비교·선택하기 좋습니다.

• CLI는 여러 터미널 세션/프로세스로 병렬화할 수 있지만, 이를 운영하는 사람의 습관(tmux, 스크립트, 큐)이 품질을 좌우합니다.

• VS Code는 "열린 워크스페이스" 중심이므로 병렬화가 가능해도, 결국 IDE가 한 프로젝트의 집중 흐름을 더 강하게 만듭니다.

병렬화가 정말 필요한지 판단하는 가장 쉬운 질문은 이것입니다. "지금도 이슈를 2~3개 동시에 굴리느냐?" 만약 그렇다면 Web 또는 CLI 중심으로 설계하는 편이 자연스럽습니다.

4) IDE 맥락이 성능을 좌우하는가

IDE 맥락이란 단순히 "에디터에서 편하다"가 아닙니다. 다음이 함께 붙어 있을 때 생산성이 커집니다.

• 열린 파일/심볼 탐색/리네임/리팩터링 도구

• 디버거, 테스트 러너, 터미널, Git 패널

• 프로젝트별 설정(프로파일, 워크스페이스 설정)

VS Code는 확장을 통해 워크플로를 IDE 안으로 끌어들이는 생태계를 갖고 있고, 확장은 설치/업데이트/권한 모델이 표준화되어 있습니다.⁴ Codex를 VS Code 확장으로 쓰면, Codex가 "내가 지금 보고 있는 맥락"을 기본값으로 삼아 대화/수정이 시작됩니다. 코드를 읽히기 위한 사전 작업이 줄어드는 만큼, 짧은 루프에 특히 강합니다.

표면별 '잘하는 일'과 '주의할 점'

Web: 위임과 협업의 중심

Web은 "작업을 맡기고, 결과를 받는" 흐름에 맞습니다. 이 표면을 중심에 두면 개발자는 점점 조율자(리드) 역할에 가까워집니다.

잘하는 일은 여러 이슈를 동시에 던져놓고, 각 결과를 PR 단위로 비교·선택하는 방식입니다. 팀 협업이 강한 조직(리뷰/이슈/PR이 일의 언어인 조직)에서 특히 잘 맞습니다.²

주의할 점은, 로컬 루프(테스트/디버깅/환경 재현)를 Web만으로 닫으려 하면 맥락 스위칭이 늘 수 있다는 것입니다. Web은 "내 로컬 환경 그대로"를 재현해주지 않습니다. 그래서 Web을 메인으로 쓰더라도, 마지막 검증은 로컬(또는 CI)로 닫히는 설계를 함께 가져가는 게 안전합니다.

Desktop App: 시각화와 접근성의 중심

Desktop App은 "웹의 편의성 + 로컬의 접근"을 묶는 허브가 됩니다. 터미널에 익숙하지 않거나, 변경 사항을 시각적으로 확인하면서 진행하고 싶은 사람에게 특히 유리합니다. 로컬에서 돌아가므로 파일 접근과 성능 면에서도 웹보다 유리한 경우가 많습니다.³

주의할 점은, GUI가 편한 만큼 "큰 변경을 작은 단위로 쪼개고 커밋/PR로 정리하는 습관"이 느슨해질 수 있다는 것입니다. 데스크톱 앱을 쓰더라도 결과물을 PR/커밋 단위로 남기는 규율은 따로 가져가야 팀이 흔들리지 않습니다.

CLI: 자동화와 대규모 변경의 중심

CLI는 Codex를 "로컬에서 실행되는 에이전트"로 쓸 때 가장 깔끔한 형태입니다. 가볍게 설치해 레포 안에서 바로 돌리고, 필요하면 스크립트/CI로 연결합니다. Codex가 "가벼운 터미널 에이전트"라는 설명은, 바로 이 지점을 겨냥합니다.¹

잘하는 일은 다음 두 가지입니다.

• 대규모 변경: 파일 수가 많고 규칙이 명확한 리팩터링/마이그레이션

• 자동화: 반복 작업을 명령으로 굳히고, 밤새 실행하거나 CI에 붙이는 흐름

주의할 점은 "강력한 만큼 사고도 크게 난다"는 것입니다. CLI는 빠르게 많은 파일을 바꾸고, 명령을 실행할 수 있습니다. 따라서 승인/샌드박스 같은 안전장치와, 커밋을 잘게 쪼개는 습관이 함께 필요합니다.

VS Code 확장: IDE 속도와 맥락의 중심

VS Code 확장은 Codex를 "내가 지금 열어 둔 파일/프로젝트 맥락"에 바로 붙입니다. 코드 읽기, 작은 변경, 테스트 추가, 리뷰 대응처럼 짧은 루프가 하루 종일 이어지는 개발자에게 적합합니다.

특히 VS Code는 확장 설치/업데이트가 내장 흐름이며, 마켓플레이스 기반으로 관리됩니다.⁴ 즉, 팀 단위로 "같은 IDE 구성"을 맞추기도 쉽습니다.

주의할 점은, IDE 안에서 모든 걸 해결하려는 욕심입니다. 큰 작업을 한 번에 시키면 IDE 세션이 비대해지고, 결과가 PR 단위로 정리되지 않은 채 "작업 중인 로컬 변경"으로만 남을 위험이 있습니다. 큰 건 CLI 또는 Web로 보내고, VS Code는 짧은 루프를 닫는 역할에 두는 편이 안정적입니다.

선택 가이드: 내 업무를 한 문장으로 말해보면 답이 나온다

아래 문장 중 당신의 일상에 가장 가까운 것을 고르세요.

• "나는 IDE에서 코드를 읽고 고치고 테스트 돌리는 루프가 하루 종일이다." → VS Code 확장을 기본값으로 두고, 큰 작업만 Web/CLI로 보냅니다.

• "나는 이슈를 여러 개 굴리고, PR로 받아 리뷰하며 병렬로 처리하는 게 중요하다." → Web을 지휘본부로 두고, 로컬 검증은 VS Code/CLI로 닫습니다.

• "나는 자동화/스크립팅/CI가 핵심이고, 터미널이 편하다." → CLI를 중심에 두고, 필요할 때만 VS Code로 리뷰·수정합니다.¹

• "나는 터미널보다 GUI가 편하고, 변경을 눈으로 보며 진행하고 싶다." → Desktop App을 기본으로 두고, 결과 정리는 PR/커밋 규칙으로 보강합니다.³

추천 운영 모델: 하나만 고르지 말고 '기본값+보조'를 정하라

현실적인 답은 대개 혼합입니다. 중요한 건 "다 쓰기"가 아니라 기본값을 하나로 정하고, 나머지는 특정 상황에서만 쓰는 보조 표면으로 두는 것입니다.

예를 들어 다음처럼 분업하면 충돌이 줄어듭니다.

• Web: 이슈를 태스크로 위임하고 PR 후보를 여러 개 받아 비교

• CLI: 밤에 돌릴 자동화(테스트 생성, 대규모 리네임, 마이그레이션)

• VS Code: 낮에 짧은 루프(리뷰 반영, 버그 재현 후 소규모 패치)

• Desktop App: 비개발자와 함께 변경을 시각적으로 검토하거나, 레포 밖 자료를 다루는 작업 창구

이렇게 역할을 분리하면 "같은 Codex를 쓰는데도 왜 자꾸 흐름이 꼬이지?"라는 문제의 대부분이 사라집니다.

참고

¹The 2026 Guide to Coding CLI Tools: 15 AI Agents Compared

²Gemini CLI vs Claude Code vs Codex : AI Command-Line Tools (CLIs) Compared

³Web vs Desktop Applications: A Practical Comparison

⁴Use extensions in Visual Studio Code