Claude Code, Codex, API, MCP처럼 도구 이름이 늘어나면 선택이 어려워집니다. 이 장에서는 도구를 순위로 비교하기보다, 내 업무의 병목에 맞춰 고르는 기준을 세웁니다.
이미지: 보고서, 코드, API, 반복 업무에 맞춰 도구를 고르는 작업대
이 장에서 손에 남는 것
- 일반 챗봇 / Claude Code / Codex / Responses API 4단 분류와 잘 맞는 상황 표
- "어떤 게 더 강한가?"가 아니라 "내 병목이 어디?"로 옮기는 도구 선택 사고법
- 6개 판단 기준으로 보는 도구 비교표 (개인 자동화 / 회사 규칙 / 파일 반복 / 병렬 구현 / 백그라운드 / 비개발자 적용)
- 본 책이 Claude Code 중심인 이유 — 비개발자 업무가 파일·양식·규칙·검증 중심이라서
- 도구 혼합 사용 시 역할 분담 — 분석은 Claude Code, 구현은 Codex, 서버는 Responses API
- 동일 자동화도 3가지 도구로 갈리는 실제 사례 (주간보고 초안 / 웹 대시보드 / 서버 자동 실행)
예상 소요: 본문 읽기 약 20분 + 내 업무 병목 진단 약 10분.
AI 도구가 늘어날수록 많은 사람이 "어떤 도구가 제일 좋은가"를 먼저 묻습니다. 하지만 실제로 중요한 것은 도구의 순위가 아니라 지금 줄이고 싶은 업무 병목이 무엇인지입니다.
이 문제는 도구 선택보다 업무 구조를 나누는 문제에 가깝습니다. 같은 "주간보고서 자동화"라도 세부 작업은 다를 수 있습니다. 파일을 읽어 초안을 만드는 일, 웹 대시보드를 구현하는 일, 서버에서 매주 자동 실행하는 일은 서로 다릅니다. 같은 이름의 자동화라도 필요한 도구가 달라집니다.
Claude Code, OpenAI Codex, Responses API는 서로 다른 층위의 도구입니다. 이 장에서는 세 도구를 업무 자동화 전자책의 맥락에 맞춰 정리합니다.
먼저 결론부터 말씀드리겠습니다. 이 책은 Claude Code 중심으로 쓰지만, Claude Code가 모든 상황에서 유일한 답이라는 뜻은 아닙니다. Claude Code, Codex, Responses API는 서로 다른 층위의 도구입니다. 어떤 업무를 자동화하려는지에 따라 선택이 달라집니다.
도구 선택을 스마트폰 앱 고르듯 접근하면 헷갈립니다. "어느 앱이 더 좋나?"보다 "어떤 일을 하려는가?"가 먼저입니다. 택시를 부를 때 지도 앱을 쓰지 않고, 길을 볼 때 메신저를 쓰지 않습니다. AI 도구도 마찬가지입니다. 업무 문맥 정리에 맞는 도구와 코드 구현에 맞는 도구, 서버 자동 실행에 맞는 도구는 다릅니다.
핵심 포인트
도구 선택의 첫 질문은 "무엇이 더 강한가?"가 아닙니다. "내가 줄이려는 병목은 문서 처리인가, 코드 구현인가, 반복 실행인가?"입니다.
세 도구의 성격
세 도구를 한 줄로 구분하면 다음과 같습니다. Claude Code는 작업공간에서 함께 일하는 동료에 가깝고, Codex는 개발 작업을 밀어주는 엔지니어에 가깝고, Responses API는 자동화 제품을 만들기 위한 부품에 가깝습니다. 여기에 일반 챗봇과 회사 시스템 자동화까지 놓고 보면 선택이 더 쉬워집니다.
| 구분 | 잘 맞는 상황 | 결과물 | 주의점 |
|---|---|---|---|
| 일반 챗봇 | 짧은 요약, 문장 다듬기, 아이디어 정리 | 답변 텍스트 | 파일 저장, 검증, 반복 절차는 약합니다. |
| Claude Code | 내 작업 폴더의 문서·엑셀·회의록 처리 | 새 파일, 검증표, 로그 | 권한과 원본 보호 규칙을 먼저 정해야 합니다. |
| Codex (OpenAI) | 앱 구현, 테스트, PR 리뷰, 코드 변경 | 코드 변경, 테스트 결과, PR | 비개발 문서 업무만으로는 과할 수 있습니다. |
| 회사 시스템 자동화/API | 서버 반복 실행, 웹훅, 데이터베이스 연동 | 운영 기능, 로그, 알림 | 개발·보안·운영 책임이 함께 필요합니다. |
Claude Code는 작업공간 흐름과 문맥 주입에 강한 에이전트형 도구입니다. 파일을 읽고, 명령을 실행하고, 규칙을 따르고, 승인 기반으로 작업하게 만들기 좋습니다. 회사 양식, 보고서, 문서, 엑셀 처리 같은 업무에는 이 구조가 잘 맞습니다.
Codex는 개발 작업, 병렬 구현, PR 리뷰 자동화에 강합니다. 코드 수정, 테스트, GitHub 리뷰, worktree 기반 병렬 작업이 중심인 업무라면 Codex가 더 직접적일 수 있습니다.
Responses API는 완성된 업무 도구라기보다, 서비스나 사내 시스템에 AI 응답, 도구 호출, 상태 관리 흐름을 넣기 위한 API 계층입니다. 웹훅, 백그라운드 실행, 내부 시스템 연동처럼 개발자가 직접 자동화 시스템을 만들 때 강합니다.
| 판단 기준 | Claude Code | Codex | Responses API |
|---|---|---|---|
| 개인 로컬 업무 자동화 | 강함 | 강함 | 직접 구현 필요 |
| 회사 규칙과 문맥 주입 | CLAUDE.md, Skills 중심 |
AGENTS.md, Skills 중심 |
앱 설계로 구현 |
| 파일 기반 반복 업무 | 강함 | 강함 | Shell/API 조합 필요 |
| 병렬 구현과 PR 리뷰 | 중간 | 강함 | 직접 연결 필요 |
| 백그라운드 실행 흐름 관리 | 공식 제공 범위 확인 필요 | 개발·리뷰 흐름에 맞춰 검토 | 직접 설계 가능 |
| 비개발자 업무 적용 | 문서·엑셀·양식 흐름에 적합 | 개발/리뷰 흐름에 적합 | 사내 시스템 개발에 적합 |
내 업무에 적용하는 질문
지금 필요한 것은 파일을 읽고 결과물을 만드는 일인가, 실제 앱을 구현하는 일인가, 서버에서 반복 실행되는 시스템을 만드는 일인가?
왜 이 책은 Claude Code 중심인가
이 책의 독자는 주로 비개발자 직장인입니다. 이들에게 가장 중요한 것은 GitHub PR 리뷰나 대규모 리팩터링이 아닙니다. 더 현실적인 문제는 다음과 같습니다.
- 회사 양식에 맞춰 보고서를 쓰고 싶습니다.
- 엑셀 파일을 매주 취합하고 싶습니다.
- 회의록에서 액션아이템을 뽑고 싶습니다.
- 공문이나 정산서를 템플릿으로 만들고 싶습니다.
- 외부 발송 전 사람이 확인할 수 있는 초안을 만들고 싶습니다.
이런 업무는 파일, 폴더, 템플릿, 규칙, 검증 기준이 중심입니다. Claude Code의 작업공간 기반 접근, CLAUDE.md, Skills, 계획과 승인 흐름은 이 목적에 잘 맞습니다.
예시: 같은 "자동화"라도 도구가 달라지는 경우
상황 1: 주간보고서 초안을 만들고 싶습니다. 이 경우 Claude Code가 잘 맞습니다. 입력 파일, 회사 양식, 검증 기준이 중심이니까요.
상황 2: 주간보고서를 웹 대시보드에서 버튼으로 만들고 싶습니다. 이 경우 Codex가 필요할 수 있습니다. 실제 웹앱 구현, 테스트, 배포가 들어가기 때문입니다.
상황 3: 매주 금요일 서버가 자동으로 데이터를 모으고, 결과를 데이터베이스에 저장하고, 실패하면 알림을 보내야 합니다. 이 경우 Responses API 같은 API 계층이나 별도 백엔드 자동화가 필요할 수 있습니다.
"주간보고서 자동화"라는 말만으로는 도구를 고를 수 없습니다. 같은 표현 안에 초안 생성, 제품 구현, 서버 운영이 섞여 있기 때문입니다. 도구 선택은 업무 이름이 아니라 실제로 줄이고 싶은 병목에서 출발해야 합니다.
개발곰곰의 팁
회의에서 "이거 자동화합시다"라는 말이 나오면 바로 도구를 고르지 마세요. 먼저 "초안 생성 자동화인가요, 화면 개발인가요, 서버 반복 실행인가요?"라고 물어보면 논의가 훨씬 선명해집니다.
개발 자동화와 업무 자동화의 경계
Claude Code를 쓰다 보면 자연스럽게 개발 자동화와 사업 자동화까지 생각이 넓어집니다. 예를 들어 보고서 초안을 잘 만들게 되면 "이걸 버튼 하나로 실행하는 내부 페이지로 만들 수 없을까?"라는 생각이 듭니다. 정산 검증표가 잘 나오면 "새 송장이 들어올 때마다 서버에서 자동으로 돌릴 수 없을까?"라는 욕구가 따라옵니다.
여기서 중요한 것은 욕심을 줄이는 일이 아니라 층위를 구분하는 일입니다.
| 원하는 결과 | 먼저 할 일 | 주로 맞는 도구 | 이유 |
|---|---|---|---|
| 내 폴더에서 보고서·엑셀·회의록 초안을 만들고 싶다 | 파일, 양식, 검증 기준을 정리합니다. | Claude Code | 작업공간과 파일 흐름이 중심입니다. |
| 팀원이 누르는 웹 화면이나 내부 대시보드를 만들고 싶다 | 요구사항, 화면, 데이터 구조를 정합니다. | Codex | 실제 앱 구현과 테스트가 필요합니다. |
| 매주 서버가 자동으로 데이터를 모으고 저장해야 한다 | 실패 처리, 권한, 로그, 알림 기준을 정합니다. | Responses API 또는 백엔드 자동화 | 제품 안에 들어가는 장기 실행 흐름입니다. |
| 반복되는 정산·마케팅·보고 업무를 사업 운영 프로세스로 묶고 싶다 | 초안 생성, 검증표, 승인 흐름을 표준화합니다. | Claude Code에서 시작, 필요 시 Codex/API 확장 | 처음부터 시스템을 만들기보다 먼저 확인한 업무 절차가 필요합니다. |
이미지: 문서 업무, 앱 구현, 서버 자동화 요구에 따라 도구를 고르는 흐름
개발 자동화는 코드를 줄이는 일이고, 업무 자동화는 반복 절차를 줄이는 일입니다. 사업 자동화에서는 이 둘이 섞일 수 있지만 순서는 분명해야 합니다. 먼저 사람이 하던 절차를 Claude Code로 안정화하고, 반복 가치가 확인되면 Codex나 API 계층으로 제품화합니다.
Codex를 함께 쓰면 좋은 경우
자동화가 단순 문서 처리에서 실제 소프트웨어 개발로 넘어가면 Codex가 유리합니다. 예를 들어 팀에서 쓰는 웹 대시보드를 만들거나, 자동화 결과를 관리하는 내부 도구를 개발하거나, GitHub PR 리뷰를 자동화하려는 경우입니다.
이때 역할 분담은 다음과 같이 해볼 수 있습니다.
Claude Code: 업무 절차 분석, 회사 규칙 정리, 자동화 요구사항 작성
Codex: 실제 앱 구현, 테스트, PR 리뷰
Responses API: 서버 자동화, 웹훅, 장기 실행 작업이렇게 나누면 각 도구가 잘하는 일을 맡습니다. Claude Code로 업무 흐름을 정리하고, Codex로 구현을 진행하며, Responses API 같은 API 계층으로 장기 실행 시스템을 만듭니다. 물론 처음부터 이 조합을 모두 쓸 필요는 없습니다. 업무가 커질 때 선택지가 있다는 정도로 이해하면 충분합니다.
핵심 포인트
여러 도구를 함께 쓰는 목적은 복잡한 조합을 만드는 데 있지 않습니다. 업무 분석과 구현, 운영을 서로 맞는 도구에 나눠 맡기기 위해서입니다.
실제 구현 흐름
도구 선택은 아래 질문으로 결정합니다.
| 질문 | 선택 |
|---|---|
| 내 폴더의 문서, 엑셀, 회의록을 처리하는가? | Claude Code |
| 웹앱, 내부 대시보드, API, 테스트가 필요한가? | Codex |
| 제품 서버에서 사용자 요청을 자동 처리해야 하는가? | Responses API 또는 서버 구현 |
| 외부 앱 데이터를 읽고 초안을 만들고 싶은가? | MCP, 단 읽기부터 시작 |
예를 들어 주간보고서 초안을 만드는 일은 Claude Code가 맞습니다. 보고서 제출 현황을 보는 사내 웹 대시보드를 만드는 일은 Codex가 맞습니다. 결제 웹훅을 받아 자동으로 라이선스를 부여하는 일은 API와 서버 구현 문제입니다.
도구 선택
문서 자동화는 로컬 파일과 검증표가 중심이므로 Claude Code를 먼저 씁니다. 코드베이스 변경, 테스트, 배포가 필요하면 Codex를 씁니다. 서버 기능은 권한과 로그, 실패 재시도까지 설계할 수 있을 때만 API로 확장합니다.
검증 체크
- 해결하려는 문제가 문서 처리인지 코드 구현인지 구분했습니까?
- 자동화 결과가 로컬 파일인지 웹 기능인지 명확합니까?
- 배포와 운영 책임이 필요한 작업을 단순 프롬프트로 처리하려 하지는 않습니까?
- 외부 API 사용 시 실패 로그와 재시도 기준이 있습니까?
안 될 때 대안
도구가 헷갈리면 먼저 로컬 파일 산출물로 문제를 줄입니다. 로컬에서 반복 흐름을 확인한 뒤에 앱, API, MCP로 확장합니다.
반론: "도구를 여러 개 쓰면 더 복잡하지 않나?"
맞습니다. 도구가 늘어나면 실제로 복잡해집니다. 계정과 권한, 파일 위치, 결과물 관리 방식도 함께 늘어나기 때문입니다. 그래서 처음부터 여러 도구를 섞지 않는 편이 좋습니다. 비개발자 업무 자동화는 Claude Code 하나로 시작해도 충분합니다. 문서, 엑셀, 회의록, 브리핑 초안까지는 하나의 작업공간에서 충분히 배울 수 있습니다.
다른 도구는 필요가 생겼을 때 붙이면 됩니다. 처음부터 도구 조합을 복잡하게 만들기보다, 지금 업무의 병목이 문서 처리인지 코드 구현인지 장기 실행인지부터 확인하는 편이 낫습니다.
- 코드 구현이 필요해지면 Codex를 고려합니다.
- 서버 자동 실행이 필요해지면 API 계층을 고려합니다.
- 팀 배포와 리뷰 흐름이 중요해지면 GitHub 기반 도구를 고려합니다.
도구를 많이 아는 것이 목표는 아닙니다. 목표는 지금 업무의 병목을 줄이는 일이고, 그 병목이 바뀌면 도구도 자연스럽게 바뀝니다.
핵심 포인트
처음에는 하나의 도구로 작게 성공하는 편이 낫습니다. 다른 도구는 지금 쓰는 도구로 해결되지 않는 병목이 분명해졌을 때 붙이면 됩니다.
이 장의 결과물
| 결과물 | 무엇인가 | 다음 챕터 연결 |
|---|---|---|
| 4단 도구 분류 표 | 챗봇 / Claude Code / Codex / Responses API의 잘 맞는 상황 | 책 전반 의사결정 |
| 6개 기준 도구 비교표 | 개인·회사 규칙·파일·병렬·백그라운드·비개발자 차원 | 도구 선택 시 매번 참조 |
| 도구 선택 결정 흐름 | 문서? → Claude Code / 앱? → Codex / 서버? → API | 새 자동화 시작할 때 |
| 본 책이 Claude Code 중심인 이유 | 비개발자 업무 = 파일·양식·규칙·검증 | 책 정체성 |
| 도구 혼합 역할 분담 모델 | 분석·구현·운영을 3개 도구로 | 자동화 성장 단계 |
연결 안내
- 도구 선택 후 실행 단계: 6~10장 2부 핵심 레시피.
- 도구가 자주 바뀔 때 운영 부담 관리: 4부 마무리. 자동화 유지보수와 롤백.
- Claude Code로 시작했지만 자동화 ROI가 안 나오는 영역 판단: 1부 마무리. 자동화하지 마세요.
핵심 포인트
5장의 목표는 도구 이름을 외우는 것이 아닙니다. 업무 병목을 보고, 지금 필요한 도구의 층위를 고르는 기준을 갖추는 것입니다.
안전 노트
도구가 늘어날수록 권한 관리 비용도 같이 늘어납니다. 새 도구를 도입할 때마다 (a) 어떤 폴더·MCP에 접근하는지 명확히 정의(13장 권한 사다리), (b) 외부 발송·금액 확정·삭제 같은 위험 작업은 사람 승인 게이트를 통과시키는 규칙(안전 원칙 4, 7), 이 두 가지를 같이 따져야 합니다. 비개발자가 처음 시작할 때는 Claude Code 한 도구 + 업무 키트 7종으로 충분합니다. 도구 확장은 ROI가 확인된 뒤에 합니다.
내 업무에 적용하기 — 도구 선택 워크시트
도구를 고를 때는 이름보다 병목을 먼저 봅니다. 아래 표 빈칸을 채우면 내 업무에 맞는 도구가 자연스럽게 나옵니다.
| 점검 항목 | 질문 | 내 답 |
|---|---|---|
| 가장 큰 병목 | 문서 처리 / 코드 구현 / 반복 실행 중 어디? | |
| 결과물 형태 | 새 파일 / 웹 앱 / API 응답 중 무엇? | |
| Claude Code로 충분한 단계 | 어디까지가 책의 2~3부 범위에서 해결되는가? | |
| 다른 도구가 필요해지는 신호 | 어떤 요구가 생겨야 Codex/API로 확장? | |
| 도입 전 선결 정리 | 회사 양식·규칙 중 먼저 명문화할 것? |
답을 채우다 막힌다면 그 부분은 도구 문제가 아니라 업무 정의 문제입니다. 도구를 바꾸기 전에 그 업무의 입력·출력·검증을 먼저 정리해야 합니다 (1장의 5요소 워크시트로 돌아가도 좋습니다).
참고: 이 장의 도구 비교는 각 제품의 공식 문서를 바탕으로, 비개발자 업무 자동화 관점에 맞춰 재구성했습니다.