✍️ Today I Learned

최근 1~2년 사이 AI 코딩 어시스트 도구가 폭발적으로 늘었다. 여러 도구를 번갈아 쓰다 보니 구독, 키 관리, 컨텍스트 세팅이 제일 피로하기도해서 결국 VS Code에 Codex Extension + ChatGPT Plus로 정착했다.

현 시점에서 해당 구성으로 사용하는 이유와 내가 사용하고 있는 개발 환경을 간략하게 소개해보고자 이번 포스팅을 남긴다.

1. Codex를 선택한 핵심 이유 (ChatGPT Plus 구독자 관점)

여러 다른 모델들을 이것저것 구독해 사용하는건 비용적으로 큰 부담으로 다가오기에 하나의 범용적인 모델을 사용하고자했다.

그 중 ChatGPT는 GPT-3.5 시절부터 꾸준히 구독해 왔기에 구독을 해지하는건 상상하기 어렵다. (이젠 GPT 없이는 살 수 없어..😂)

Codex를 선택한 이유에 비용 효율적인 이유도 무시 못한다.💸

비용 효율적인 측면 외에도 다양한 장점 또한 열거해보자면 아래와 같다.

쉬운 세팅: VS Code에서 Sign in with ChatGPT → 워크스페이스 열기만 하면 끝. 키 발급, 권한 범위 설정, 토큰 제한 튜닝 같은 “초기 세팅 코스트”가 거의 없다.
IDE 네이티브 UX: Codex는 열려 있는 파일들을 그대로 컨텍스트로 써서, “파일 읽기 → 변경 계획 제안 → diff 미리보기 → 적용”까지 한 흐름으로 처리한다.
성능 / 품질: 규모가 큰 구현에서는 Claude에 비해 맥락 유지나 계획, 추론 폭이 약해 보일 수 있으나 프로젝트 구조 파악, 리팩터링, 테스트 추가, 성능 개선 같은 일상 개발 작업을 안정적으로 처리한다. “대형 생성형 작업”보다 지속 가능한 생산성이 중요할 때 강함.
로컬 + 클라우드: 로컬 IDE에서 작은 태스크를 쪼개 진행하고, PR 리뷰는 클라우드로 위임해 백그라운드로 돌리기 좋다. 도구를 더 늘리지 않아도 된다는건 큰 장점이다.
팀 온보딩에도 유리: 프로젝트에 간단한 메모리 문서(/codex/*)를 두면, 같은 규칙과 컨텍스트로 출발할 수 있어 일관성이 높아진다.

2. Extension VS CLI

Codex를 사용하는 방법으로는 주로 두가지 방법이 보편적이며 차이점을 요약하자면 아래와 같다.

	VS Code Extension	CLI (Codex CLI)
시작 난이도	설치 → 로그인 즉시 사용	npm/brew 설치 후 실행
로그인	ChatGPT로 클릭 로그인	ChatGPT 로그인 또는 API Key
컨텍스트	열린 워크스페이스 기준	현재 터미널 경로 기준
변경 적용	diff 미리보기 후 적용	패치 제안 → 명령 실행 중심
UI/UX	IDE 패널·파일뷰 통합	터미널 중심·스크립트 친화
적합 작업	소/중 규모 리팩토링·버그 픽스	빌드·배치·자동화 파이프라인
강점	파일 단위 수정 가시성 높음	스크립트 위주 자동화 작업
약점	터미널 자동화는 제한적	가시성 낮음
권한/안전	무단 적용 방지 흐름 용이	권한·경로 제어는 셸 규칙 따름
자동화/스케줄링	IDE 내 매뉴얼 트리거 중심	크론·CI와 결합 용이
Git 워크플로	변경 파일 확인·커밋 편리	터미널 Git 명령 일괄 처리
학습 곡선	낮음(시각적)	중간(명령형)

나는 CLI가 아닌 Extension으로 사용중이며, 모델이 요청을 추론해나가는 과정을 시각적으로 확인하고 검토할 수 있다는 장점이 가장 큰 강점이라 생각한다.

추론 과정을 확인하고 제안 사항을 시각적으로 확인할 수 있다는건 큰 장점이다. 👍

3. 사용할만한 기본 프롬프트

각 레포지토리의 도메인/규칙/빌드·테스트 명령이 다르기 때문에, Codex가 해당 워크스페이스 전용 컨텍스트를 즉시 읽게 만드는 게 가장 보편적인 구성 방법이라 생각한다.

/
  /codex/
    /memory/
      00-glossary.md
      ...
    /prompt/
      start.json
      ...

버전 관리: /codex/*는 커밋(히스토리 · 리뷰 대상)
우선 순위: 우선 순위 적용이 필요하다면 파일명에 숫자 프리픽스(00-, 01- …)로 로드 순서 고정

조직 구성원들과 함께 위와 같은 구조로 사용하고 /codext/*은 커밋하여 히스토리 및 리뷰 대상으로 관리해보고 있다.

다만, /codex/라는 폴더를 자동으로 인식해 규칙을 따르진 않으므로 우리팀의 컨벤션이라 생각하고, 작업 때 명시적으로 지시하거나 각자 로컬 전역에서 사용될 수 있도록 사용하고 있다.

{
  "start": {
    "prefix": "start",
    "description": "start 프롬프트",
    "body": [
      "[역할]" ,
      "- 너는 이 프로젝트의 시니어 엔지니어다.",
      "[컨텍스트 로드]",
      "- /codex/memory/*.md 문서를 우선 읽어라.",
      "- /codex/memory/*.md 적용 순서는 숫자 프리픽스를 따른다.",
      "- 용어 해석은 00-glossary.md 기준으로 통일한다.",
      "[제약]",
      "- 무단 적용 금지. 모든 변경은 diff 미리보기로 먼저 제시한다.",
      "[출력 포맷]",
      "1) 계획(목표/단계/위험/테스트전략) 10줄 이내 → 승인",
      "2) diff 미리보기  → 승인 후",
      "[흐름]",
      "- 지금은 계획만 출력하고 대기하라."
      "- 계획 승인이 이뤄지면 diff 미리보기를 출력하고 대기하라."
    ]
  }
}

🤔 Understanding

이러한 AI 코드 어시스트는 앞으로도 계속 늘고, 서로의 강·약점이 빠르게 바뀔꺼라 예상한다. 그래서 특정 도구 자체에 과몰입하기보단 잘 다루기 위한 루틴을 몸에 익히는 게 핵심이라 느꼈다.

개발 흐름이 제일 중요하다.: 계획 → diff 미리보기 → 적용 → 테스트 루틴을 표준화하면, 어떤 어시스트를 써도 리스크를 낮춘 채 생산성을 유지할 수 있다.
컨텍스트는 문서로 유지한다.: /codex/memory/* 같은 고정 컨텍스트가 있으면, 도구가 바뀌어도 품질이 흔들리지 않는다.
프롬프트는 규격화: 역할 · 목표 · 제약 · 출력 포맷등을 템플릿으로 굳히면 도구가 바뀌어도 전환 비용이 거의 0에 가깝다.

위와 같은 최소한의 규칙을 통해 AI를 내가 제어할 수 있는 역량을 갖추는게 제일 중요하다 생각한다. 앞으로 도구는 계속 바뀌겠지만, 프로세스·컨텍스트·프롬프트를 표준화하면 어떤 어시스트가 추가돼도 바로 대응할 수 있는 “역량” 생긴다 생각한다.