Codex 시대의 앱 개발, 무엇이 달라졌나

이제 코딩은 '타이핑 경기'가 아니다

앱을 만든다고 하면 많은 초보자는 이런 장면을 떠올립니다. 검은 터미널 창을 열고, 알 수 없는 명령어를 입력하고, 수백 줄의 코드를 직접 쓰다가, 빨간 에러가 나오면 검색창을 열어 비슷한 오류를 찾아 헤매는 모습입니다. 물론 이런 과정은 여전히 개발의 일부입니다. 하지만 Codex가 등장한 뒤 앱 개발의 중심은 조금씩 다른 곳으로 이동하고 있습니다.

이제 중요한 질문은 "내가 이 코드를 한 줄 한 줄 다 쓸 수 있는가?"만이 아닙니다. 더 중요한 질문은 "내가 만들고 싶은 기능을 정확히 설명할 수 있는가?", "AI가 바꾼 코드를 검토할 수 있는가?", "이 변경이 정말 사용자에게 필요한 결과를 만들었는가?"입니다.

Codex는 OpenAI가 제공하는 AI 코딩 파트너로, 기획, 기능 구현, 리팩터링, 코드 리뷰, 릴리스 같은 개발 작업 전반을 돕는 에이전트형 도구로 설명됩니다.¹ 여기서 핵심 단어는 '에이전트'입니다. 단순히 코드 몇 줄을 추천하는 도구가 아니라, 개발자가 자연어로 맡긴 목표를 실제 프로젝트 안에서 실행 가능한 작업으로 바꾸고, 파일을 수정하고, 명령을 실행하고, 결과를 다시 확인하는 존재에 가깝습니다.

쉽게 말해 Codex는 "이 코드는 어떻게 써?"라고 물어보는 검색창이 아닙니다. "이 기능을 우리 앱에 추가해 줘. 단, 기존 테스트는 깨지면 안 돼"라고 일을 맡기는 개발 동료에 가깝습니다.

Codex를 자동완성으로만 보면 절반도 못 쓴다

AI 코딩 도구를 처음 접한 사람은 Codex를 기존 자동완성 도구의 연장선으로 이해하기 쉽습니다. 예를 들어 const user =까지 입력하면 다음 코드를 예측해 주는 식입니다. 이런 기능도 유용합니다. 하지만 Codex의 진짜 가치는 현재 커서 옆에 코드 한 줄을 제안하는 데 있지 않습니다.

비교해 보면 차이가 더 선명합니다.

예를 들어 로그인 기능을 추가한다고 해 봅시다. 자동완성 도구는 loginUser 함수를 쓰는 도중 다음 줄을 제안할 수 있습니다. 챗봇형 도우미는 "JWT 로그인 예제 코드를 알려줘"라는 질문에 샘플 코드를 줄 수 있습니다. 하지만 에이전트형 Codex는 더 넓은 작업을 맡을 수 있습니다. 프로젝트 구조를 읽고, 로그인 페이지와 API 라우트와 테스트 파일을 찾아보고, 여러 파일을 수정하고, 필요한 명령을 실행하고, 실패한 테스트가 있으면 에러를 읽어 다시 고치는 흐름까지 이어갈 수 있습니다.

OpenAI는 Codex 앱을 여러 에이전트 작업을 관리하는 'command center' 성격의 도구로 소개하며, built-in worktrees와 cloud environments를 통해 여러 작업을 병렬로 진행할 수 있다고 설명합니다.² 이 말은 초보자에게 조금 어렵게 들릴 수 있습니다. 간단히 풀면, Codex는 한 사람이 하나의 파일만 들여다보는 도구가 아니라, 여러 개발 작업을 안전하게 나누어 처리하고 검토할 수 있게 돕는 작업 공간이라는 뜻입니다.

앱 개발 과정에서 Codex는 어디까지 할 수 있을까

초보자가 Codex를 이해할 때 가장 좋은 방법은 실제 앱 개발 흐름에 끼워 넣어 보는 것입니다. 우리가 만들 앱이 "사용자가 할 일을 추가하고 완료 처리할 수 있는 투두 앱"이라고 해 보겠습니다.

예전 방식이라면 먼저 폴더 구조를 만들고, 프레임워크 문서를 읽고, 화면을 만들고, 상태 관리를 붙이고, 저장 기능을 구현하고, 테스트를 작성하고, 오류를 고치는 일을 직접 하나씩 진행해야 했습니다. Codex와 함께할 때도 이 일들이 사라지는 것은 아닙니다. 다만 사람이 모든 단계를 손으로 수행하는 대신, Codex에게 명확한 작업 단위로 위임할 수 있습니다.

예를 들어 이런 지시를 내릴 수 있습니다.

현재 React 프로젝트에 할 일 추가 기능을 구현해 줘. src/components 안에 입력 폼 컴포넌트를 만들고, 빈 문자열은 추가되지 않게 해 줘. 관련 단위 테스트도 작성하고 npm test를 실행해 결과를 알려줘.

이 요청에는 단순한 질문보다 훨씬 많은 정보가 들어 있습니다. 목표는 "할 일 추가 기능 구현"입니다. 범위는 src/components입니다. 제약 조건은 "빈 문자열은 추가되지 않게"입니다. 검증 기준은 "단위 테스트 작성"과 "npm test 실행"입니다.

이런 식으로 요청하면 Codex는 단순히 예제 코드를 던져 주는 것이 아니라, 다음과 같은 흐름으로 움직일 수 있습니다.

1. 프로젝트 파일을 읽고 현재 구조를 파악합니다.

2. 어떤 파일을 새로 만들거나 수정해야 할지 판단합니다.

3. 컴포넌트, 상태 처리, 테스트 코드를 작성합니다.

4. 테스트 명령을 실행합니다.

5. 실패하면 실패 메시지를 읽고 수정합니다.

6. 마지막으로 바뀐 파일과 실행 결과를 요약합니다.

이 흐름을 이해하는 순간 Codex를 대하는 태도가 달라집니다. "코드 좀 써 줘"가 아니라 "작업을 맡기고 결과를 검토하자"가 됩니다.

Codex의 기본 작업 사이클

Codex와 함께 앱을 만드는 기본 흐름은 하나의 반복 사이클로 볼 수 있습니다.

요구사항 전달 → 저장소와 작업 환경 확인 → 코드 작성 및 파일 수정 → 테스트·빌드 실행 → 오류 수정 반복 → 변경 사항 검토 및 PR 생성

이 사이클은 앞으로 이 책 전체에서 계속 반복됩니다. 처음에는 작은 기능 하나로 시작하고, 뒤로 갈수록 로그인, CRUD, 디자인 개선, 배포, 자동화 같은 더 큰 작업으로 확장할 것입니다.

첫 단계는 요구사항 전달입니다. 여기서 초보자가 가장 많이 하는 실수는 "앱 만들어 줘", "로그인 넣어 줘", "에러 고쳐 줘"처럼 너무 넓고 흐릿한 요청을 던지는 것입니다. Codex는 똑똑하지만, 사용자의 머릿속을 읽지는 못합니다. 어떤 화면에 어떤 기능이 필요하고, 어떤 파일은 건드리면 안 되고, 무엇이 성공 기준인지 알려줘야 합니다.

두 번째 단계는 저장소와 작업 환경 확인입니다. 저장소는 프로젝트 코드가 들어 있는 공간입니다. Codex는 이 안에서 폴더 구조, 설정 파일, 테스트 명령, 기존 코드 스타일을 읽습니다. 프로젝트마다 사용하는 기술과 규칙이 다르기 때문에, 무작정 코드를 쓰기 전에 "이 프로젝트는 어떻게 생겼는가?"를 파악하는 일이 중요합니다.

세 번째 단계는 코드 작성과 파일 수정입니다. 여기서 Codex는 한 파일만 수정하는 것이 아니라, 필요하다면 컴포넌트, API, 테스트, 설정 파일 등 여러 파일을 함께 바꿀 수 있습니다. 이 점이 자동완성과 결정적으로 다릅니다.

네 번째 단계는 테스트와 빌드 실행입니다. 테스트는 코드가 의도대로 동작하는지 확인하는 자동 검사입니다. 빌드는 앱이 실제 실행 또는 배포 가능한 형태로 만들어지는지 확인하는 과정입니다. OpenAI의 Codex 베스트 프랙티스에서도 계획, 검증, 테스트 같은 루프를 중요하게 다룹니다.³ 초보자일수록 "실행해 보니 된다"는 감각보다 "어떤 명령으로 확인했는가?"를 습관으로 만들어야 합니다.

다섯 번째 단계는 오류 수정 반복입니다. 좋은 개발자는 에러가 없는 사람이 아니라, 에러를 읽고 좁혀 가는 사람입니다. Codex도 마찬가지입니다. 테스트가 실패하면 실패 메시지를 읽고 다시 고칩니다. 다만 이 반복이 항상 완벽하지는 않기 때문에 사람이 중간중간 방향을 확인해야 합니다.

마지막 단계는 변경 사항 검토와 PR 생성입니다. PR은 Pull Request의 줄임말로, "이 변경을 프로젝트에 반영해도 되는지 검토해 주세요"라고 제출하는 단위입니다. 혼자 개발하더라도 PR처럼 변경 내용을 묶어 보는 습관은 매우 좋습니다. 무엇이 바뀌었는지, 왜 바뀌었는지, 어떤 테스트를 통과했는지 확인할 수 있기 때문입니다.

개발자의 역할은 사라지지 않는다, 이동한다

Codex를 처음 보면 "이제 개발자는 필요 없는 것 아닌가?"라는 생각이 들 수 있습니다. 하지만 실제로는 반대에 가깝습니다. 개발자의 역할이 사라지는 것이 아니라, 더 중요한 쪽으로 이동합니다.

과거에는 많은 시간이 타이핑과 검색, 반복 수정에 쓰였습니다. 버튼 컴포넌트를 만들고, API 호출 코드를 쓰고, 비슷한 테스트를 여러 개 추가하는 작업은 손이 많이 가지만 항상 창의적인 일은 아닙니다. Codex는 이런 반복 작업을 빠르게 처리할 수 있습니다.

대신 사람에게 더 중요해지는 일은 따로 있습니다.

• 문제 정의: 무엇을 만들 것인지, 왜 필요한지 결정합니다.

• 제약 조건 제공: 어떤 기술을 쓸지, 어떤 파일을 건드리지 말아야 하는지 알려줍니다.

• 작업 범위 지정: 한 번에 맡길 일을 너무 작지도 크지도 않게 나눕니다.

• 결과 검토: 바뀐 파일, 테스트 결과, 보안 영향, 사용자 경험을 확인합니다.

• 병합 판단: 이 변경을 실제 코드베이스에 받아들일지 결정합니다.

즉, 개발자는 키보드를 덜 두드릴 수는 있지만 덜 생각해도 되는 것은 아닙니다. 오히려 생각의 품질이 더 중요해집니다. Codex는 빠르게 움직이는 실행자이고, 개발자는 방향을 정하고 품질을 책임지는 사람입니다.

좋은 비유를 하나 들어 보겠습니다. Codex를 내비게이션이라고 생각해 봅시다. 내비게이션은 빠른 길을 알려주고, 중간에 막히면 우회로를 제안합니다. 하지만 목적지를 정하는 사람은 운전자입니다. 좁은 골목으로 들어가도 되는지, 유료도로를 탈지, 중간에 들를 곳이 있는지는 운전자가 판단합니다. Codex도 마찬가지입니다. 코드를 제안하고 실행할 수 있지만, "이 앱이 정말 올바른 방향으로 가고 있는가?"는 사람이 봐야 합니다.

초보자는 질문보다 '작업 지시'를 연습해야 한다

초보자가 AI에게 가장 자주 하는 말은 "어떻게 해?"입니다. 물론 배울 때는 좋은 질문입니다. 하지만 Codex를 앱 개발 파트너로 쓰려면 질문에서 작업 지시로 넘어가야 합니다.

나쁜 요청은 대체로 짧고 모호합니다.

로그인 어떻게 해?

이 요청은 공부용 질문으로는 괜찮지만, Codex에게 실제 작업을 맡기기에는 부족합니다. 어떤 앱인지, 어떤 로그인 방식인지, 프론트엔드만 필요한지, 서버도 필요한지, 테스트는 필요한지 알 수 없습니다.

조금 나은 요청은 이렇습니다.

현재 앱에 로그인 기능을 추가해 줘.

목표는 생겼지만 여전히 범위와 검증 기준이 없습니다. Codex가 너무 많은 파일을 바꾸거나, 원하지 않는 라이브러리를 추가하거나, 테스트 없이 구현을 끝낼 수 있습니다.

좋은 요청은 이렇게 바뀝니다.

현재 Next.js 앱의 /login 화면에 이메일/비밀번호 로그인 폼을 추가해 줘. 이번 작업에서는 UI와 클라이언트 유효성 검사만 구현하고, 실제 서버 인증은 만들지 마. 빈 이메일, 잘못된 이메일 형식, 8자 미만 비밀번호에 대한 실패 케이스 테스트를 작성해 줘. 작업 후 npm test를 실행하고 변경된 파일 목록을 요약해 줘.

이 요청에는 Codex가 일을 제대로 하기 위한 재료가 들어 있습니다. 목표, 대상 화면, 범위, 하지 말아야 할 일, 실패 케이스, 테스트 명령, 보고 방식이 모두 있습니다.

앞으로 이 책에서 사용할 기본 프롬프트 구조도 이와 비슷합니다.

목표: 무엇을 만들거나 고칠지
범위: 어떤 파일, 화면, 기능에 한정할지
제약: 건드리지 말아야 할 것, 따라야 할 규칙
검증: 어떤 테스트나 명령으로 성공을 확인할지
보고: 변경 파일과 결과를 어떻게 요약할지

이 구조를 외워 두면 Codex를 훨씬 안정적으로 사용할 수 있습니다. 프롬프트를 길게 쓰는 것이 핵심은 아닙니다. 필요한 정보를 빠뜨리지 않는 것이 핵심입니다.

실제 앱 개발에서 보는 세 가지 장면

장면 1: 자동완성처럼 썼을 때

초보 개발자 민지는 할 일 관리 앱을 만들고 있습니다. 입력창에 할 일을 쓰고 버튼을 누르면 목록에 추가되게 하고 싶습니다. 민지는 코드 파일을 열고 function addTodo를 입력합니다. 자동완성 도구가 다음 줄을 제안합니다.

setTodos([...todos, newTodo]);

도움은 됩니다. 하지만 여기서 끝입니다. 빈 문자열을 막아야 하는지, 입력 후 필드를 비워야 하는지, 테스트는 있는지, 기존 상태 관리 방식과 맞는지는 민지가 직접 챙겨야 합니다.

장면 2: 챗봇처럼 썼을 때

이번에는 민지가 챗봇에게 묻습니다.

React에서 투두 추가 기능 예제 알려줘.

챗봇은 친절하게 예제 코드를 줍니다. 민지는 그 코드를 복사해 붙여 넣습니다. 그런데 프로젝트에서는 TypeScript를 쓰고 있었고, 기존 컴포넌트 구조도 예제와 달랐습니다. 결국 민지는 예제 코드를 자기 프로젝트에 맞게 다시 고쳐야 합니다.

장면 3: 에이전트형 Codex로 맡겼을 때

이번에는 민지가 Codex에게 이렇게 요청합니다.

이 프로젝트의 기존 컴포넌트 구조를 먼저 확인한 뒤, 할 일 추가 기능을 구현해 줘. 빈 문자열은 추가하지 말고, 추가 후 입력창을 비워 줘. 기존 테스트 스타일에 맞춰 테스트도 추가하고, npm test 결과를 알려줘.

Codex는 프로젝트 파일을 읽고, 기존 패턴에 맞춰 컴포넌트를 수정하고, 테스트 파일을 추가한 뒤, 테스트를 실행합니다. 테스트가 실패하면 실패 원인을 보고 다시 고칩니다. 마지막에는 어떤 파일을 바꿨고 어떤 테스트를 실행했는지 요약합니다.

세 장면 모두 AI를 사용했습니다. 하지만 결과는 완전히 다릅니다. 차이는 AI의 능력만이 아니라, 사람이 AI에게 어떤 방식으로 일을 맡겼는지에서 나옵니다.

여러 에이전트를 관리하는 시대

2026년의 개발 환경은 한 명의 AI에게 한 번 질문하는 수준을 넘어서고 있습니다. VS Code도 여러 에이전트 세션을 한곳에서 관리하고, local, background, cloud 방식으로 작업을 나누는 흐름을 소개하고 있습니다.⁴ Codex 역시 앱, CLI, IDE 확장, 클라우드 작업 같은 여러 접점을 통해 개발자의 작업 방식에 들어옵니다.

초보자에게 이 말이 당장 복잡하게 느껴질 수 있습니다. 괜찮습니다. 처음부터 모든 기능을 알 필요는 없습니다. 지금은 다음 정도만 기억하면 충분합니다.

Codex App은 프로젝트와 작업을 눈으로 관리하기 좋습니다. 여러 작업을 동시에 진행하거나 diff를 검토하는 데 유리합니다. Codex CLI는 터미널에서 빠르게 작업을 맡기고 명령 실행 흐름을 확인하기 좋습니다. IDE 확장은 VS Code 같은 편집기 안에서 Codex와 함께 작업할 때 편합니다. Cloud와 GitHub 연동은 작업을 백그라운드로 맡기고 PR로 검토하는 흐름에 어울립니다.

이 책의 뒤쪽에서는 각각을 따로 다룹니다. 지금 중요한 것은 "Codex는 하나의 채팅창이 아니라 개발 워크플로우 전체에 들어오는 에이전트 시스템"이라는 큰 그림입니다.

신뢰하되, 그대로 받아들이지는 않는다

Codex를 사용할 때 가장 위험한 태도는 두 가지입니다. 하나는 "AI가 코드를 만들었으니 다 틀렸을 거야"라고 무조건 불신하는 것입니다. 그러면 Codex의 장점을 거의 쓰지 못합니다. 다른 하나는 "AI가 했으니 맞겠지"라고 그대로 받아들이는 것입니다. 이쪽이 더 위험합니다.

우리가 세워야 할 원칙은 간단합니다.

Codex를 신뢰하되, 최종 판단은 사람이 한다.

사람이 반드시 확인해야 할 것은 최소한 다음과 같습니다.

• 실행 결과: 앱이 실제로 켜지고, 요청한 기능이 동작하는가?

• 테스트 결과: 관련 테스트, 빌드, 린트가 통과했는가?

• 변경 파일: Codex가 엉뚱한 파일이나 민감한 파일을 바꾸지 않았는가?

• 보안·권한 영향: 인증, 결제, 개인정보, 관리자 기능에 위험한 변화가 없는가?

• 요구사항 충족 여부: 처음 요청한 목표와 완료 조건을 만족하는가?

특히 초보자는 Codex의 요약만 읽고 넘어가면 안 됩니다. 요약은 설명일 뿐이고, 실제 진실은 diff에 있습니다. diff는 변경 전과 변경 후의 차이를 보여주는 기록입니다. 앞으로 Codex가 작업을 끝낼 때마다 "무슨 말을 했는가?"보다 "무엇을 바꿨는가?"를 먼저 보는 습관을 들이세요.

예를 들어 Codex가 "로그인 폼을 추가했습니다"라고 말했는데 diff를 보니 테스트 파일을 삭제했다면 문제가 있습니다. "의존성을 업데이트했습니다"라고 말했는데 package.json에 낯선 패키지가 여러 개 추가되었다면 확인해야 합니다. "보안 검증을 추가했습니다"라고 말했는데 실제로는 클라이언트에서만 검사하고 서버 검증은 없다면 요구사항을 다시 조정해야 합니다.

첫 장에서 가져갈 핵심 감각

Codex 시대의 앱 개발은 "AI가 써준 코드를 받는 일"이 아닙니다. 더 정확히는 "AI에게 개발 작업을 맡기고, 사람이 방향과 품질을 관리하는 일"입니다.

앞으로 여러분은 Codex에게 많은 일을 맡기게 될 것입니다. 프로젝트 구조를 설명하게 하고, 버그를 찾게 하고, 테스트를 쓰게 하고, UI를 고치게 하고, PR을 만들게 할 것입니다. 하지만 그 모든 과정에서 여러분은 방관자가 아니라 감독자이자 리뷰어입니다.

초보자에게 가장 좋은 시작은 거창한 앱을 한 번에 만들게 하는 것이 아닙니다. 먼저 작은 작업을 맡기고, 결과를 보고, diff를 읽고, 테스트를 확인하는 루프를 익히는 것입니다. 이 루프가 몸에 익으면 Codex는 단순한 코드 생성기가 아니라 앱 개발을 함께 완성하는 강력한 파트너가 됩니다.

다음 장에서는 Codex의 전체 그림을 한눈에 정리합니다. App, CLI, IDE, Cloud가 각각 어떤 역할을 하는지, 초보자는 어디서 시작하면 좋은지 차근차근 살펴보겠습니다.

참고

¹Codex | OpenAI의 AI 코딩 파트너

²Codex | AI Coding Partner from OpenAI

³Best practices - Codex | OpenAI Developers

⁴Your Home for Multi-Agent Development