Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

왜 GPT-5가 개발 워크플로를 바꾸는가
GPT-5에서 실제로 달라진 점
모델 크기는 어떻게 고를까
제어값은 언제 낮추고 언제 올릴까
에이전트 코딩에서 무엇이 달라지는가
커스텀 툴과 형식 제약을 같이 쓰는 법
Responses API와 Chat Completions API는 언제 쓰나
- Responses API
- Chat Completions API
비용과 지연 시간을 어떻게 줄일까
프로덕션 롤아웃 체크리스트
FAQ
References

왜 GPT-5가 개발 워크플로를 바꾸는가

OpenAI는 2025년 8월 7일 Introducing GPT-5 for developers에서 GPT-5를 코딩과 에이전트 작업을 위한 최고의 모델이라고 소개했다. 이 발표의 핵심은 더 좋은 채팅 모델이 하나 늘었다는 데 있지 않다. 개발자가 모델을 다루는 방식이, 프롬프트를 잘 쓰는 수준에서 도구 호출, 출력 제약, 지연 시간, 비용, 에이전트 실행까지 함께 설계하는 수준으로 올라갔다는 데 있다.

이전 세대의 개발 워크플로에서는 보통 이런 순서였다.

모델을 고른다.
프롬프트를 만든다.
JSON이 잘 나오길 바란다.
도구 호출이 깨지면 후처리한다.
비용과 속도는 나중에 따진다.

GPT-5는 이 흐름을 더 명시적으로 바꿔 준다. 이제 개발자는 모델에게 무엇을 시킬지뿐 아니라, 얼마나 길게 답할지, 얼마나 깊게 생각할지, 어떤 형식으로 출력할지, 어떤 도구를 어떤 제약으로 쓸지를 함께 정한다. 그 결과, 에이전트 코딩과 운영 자동화에서 프롬프트만 잘 다듬는 방식보다 훨씬 안정적인 설계가 가능해진다.

GPT-5에서 실제로 달라진 점

GPT-5가 실무에서 중요한 이유는 단순한 성능 향상보다도, 개발자가 제어할 수 있는 범위가 넓어졌기 때문이다.

1. 코딩과 에이전트 작업에 강하다

OpenAI는 GPT-5를 코드 수정, 버그 수정, 복잡한 코드베이스 질의, 도구를 오가는 에이전트 작업에 특히 강한 모델로 설명한다. 즉, 단일 답변 생성보다 작업 수행에 더 잘 맞는다.

2. 제어값이 더 명확하다

실무에서 가장 먼저 익혀야 할 제어는 두 가지다.

verbosity: 답변의 길이와 설명 수준을 조절한다.
reasoning_effort: 모델이 얼마나 깊게 추론할지 조절한다.

대체로 verbosity는 출력 형식과 읽기 경험을 바꾸고, reasoning_effort는 정답률, 지연 시간, 토큰 사용량 사이의 균형을 바꾼다.

3. 커스텀 툴이 더 유연하다

GPT-5는 커스텀 툴을 통해 JSON만이 아니라 plaintext 입력으로도 도구를 호출할 수 있다. 이 점은 SQL, DSL, 셸 스타일 명령, 특수한 내부 포맷처럼 구조화된 JSON으로만 표현하기 어색한 작업에서 특히 유용하다.

4. 형식 제약을 더 강하게 걸 수 있다

필요하다면 출력 형식을 정규식으로 제한하거나, 더 엄격하게는 CFG로 제한할 수 있다. 실무에서는 "그럴듯한 텍스트"보다 반드시 맞는 형식이 더 중요할 때가 많으므로, 이 기능이 에이전트 품질을 크게 올려 준다.

5. 여러 API 표면에서 쓸 수 있다

GPT-5는 Responses API와 Chat Completions API에서 사용할 수 있고, OpenAI의 Codex CLI에서도 기본 개발 워크플로에 자연스럽게 들어간다. 즉, 한 번 익힌 운영 원칙을 인터랙티브 채팅, 코드 에이전트, 배치성 작업에 모두 재사용하기 좋다.

모델 크기는 어떻게 고를까

GPT-5 계열은 보통 gpt-5, gpt-5-mini, gpt-5-nano로 나눠서 생각하면 편하다. 선택 기준은 "가장 똑똑한 모델"이 아니라 작업의 위험도와 반복성이다.

모델	추천 용도	장점	주의점
`gpt-5`	복잡한 코드 수정, 에이전트 루프, 설계 판단, 어려운 디버깅	가장 강한 추론과 작업 수행 능력	비용과 지연 시간이 상대적으로 높다
`gpt-5-mini`	일반적인 제품 기능, 중간 난이도 도구 호출, 대화형 코딩 보조	균형이 좋고 폭넓게 쓰기 쉽다	가장 어려운 문제에서는 한계가 보일 수 있다
`gpt-5-nano`	분류, 추출, 라우팅, 초저지연 작업, 대량 처리	가장 빠르고 저렴하다	복잡한 추론에는 맞지 않는다

실무 팁은 단순하다. **핵심 경로는 gpt-5, 보조 경로는 gpt-5-mini, 대량 전처리는 gpt-5-nano**로 나누면 설계가 쉬워진다.

제어값은 언제 낮추고 언제 올릴까

GPT-5를 잘 쓰는 팀은 "좋은 프롬프트"보다 좋은 기본값을 만든다. 아래 기준으로 시작하면 운영이 편하다.

제어값	낮출 때	높일 때
`verbosity`	UI에 짧은 답만 보여주고 싶을 때, 구조화된 결과만 필요할 때	코드 리뷰 설명, 디버깅 해설, 사용자 교육 문서가 필요할 때
`reasoning_effort`	단순 분류, 짧은 요약, 빠른 1차 응답이 중요할 때	복잡한 버그 수정, 다단계 에이전트 작업, 도구 선택이 중요한 경우

추천하는 사고방식은 이렇다.

verbosity는 사용자가 읽는 느낌을 조절한다.
reasoning_effort는 모델이 일하는 깊이를 조절한다.

처음부터 둘 다 높게 두면 품질은 좋아 보일 수 있지만, 비용과 지연 시간이 급격히 불어난다. 반대로 둘 다 너무 낮추면 속도는 빨라도 에이전트가 문제를 충분히 풀지 못한다.

에이전트 코딩에서 무엇이 달라지는가

GPT-5는 단발성 코드 생성기보다 코드베이스를 함께 읽는 협업자에 가깝다. 그래서 실전에서 중요한 것은 "코드를 한 번에 잘 쓰는가"가 아니라 다음 흐름이다.

작업 범위를 잘 이해하는가
필요한 파일과 도구를 적절히 고르는가
중간 결과를 설명하며 진행하는가
변경 후 검증을 스스로 하는가
실패하면 맥락을 유지한 채 다시 시도하는가

이런 작업에서는 gpt-5가 가장 잘 맞는다. 특히 다음 상황에 유리하다.

레거시 코드베이스에서 부분 수정이 필요할 때
여러 파일을 함께 바꾸고 원인을 추적해야 할 때
테스트 작성, 리팩터링, 문서 갱신이 함께 필요할 때
도구 호출을 여러 번 오가며 계획을 조정해야 할 때

반대로 작은 규칙 기반 작업이나 대량 분류는 굳이 최고급 모델이 아니어도 된다. 이때는 gpt-5-mini나 gpt-5-nano를 먼저 고려하는 편이 비용 효율적이다.

커스텀 툴과 형식 제약을 같이 쓰는 법

커스텀 툴의 핵심 가치는 "모델이 도구를 호출한다"가 아니라, 도구 입력의 형태를 작업에 맞게 바꿀 수 있다는 점이다.

예를 들어 다음과 같은 작업은 plaintext가 더 자연스럽다.

SQL 쿼리 실행
사내 DSL 검증
설정 파일 초안 생성
쉘 스타일 명령 전달

그리고 형식이 중요하면 출력 제약을 추가한다.

정규식은 간단한 패턴 고정에 좋다.
CFG는 더 복잡한 언어 문법이나 내부 포맷에 좋다.

실무에서는 이렇게 조합하면 된다.

도구 입력은 plaintext로 단순화한다.
도구 출력 또는 모델 응답은 regex나 CFG로 제한한다.
실패 시에는 사람이 읽을 수 있는 오류 메시지를 남긴다.

이 방식은 에이전트가 "대충 맞는 답"을 내는 대신, 실제로 실행 가능한 답을 내도록 유도한다.

Responses API와 Chat Completions API는 언제 쓰나

GPT-5는 두 API 모두에서 쓸 수 있지만, 실무에서는 역할이 조금 다르다.

Responses API

새 기능과 에이전트형 워크플로에는 Responses API가 더 자연스럽다. 이유는 도구 사용, 스트리밍, 구조화된 흐름, 장기적인 에이전트 설계에 더 잘 맞기 때문이다.

Chat Completions API

기존 코드베이스와의 호환성이 중요하거나, 이미 Chat Completions 중심으로 쌓인 서비스라면 점진적으로 유지할 수 있다. 다만 새 프로젝트라면 장기적으로는 Responses API 쪽이 운영하기 쉽다.

간단히 말해:

새 에이전트 제품은 Responses API 우선
기존 레거시 서비스는 Chat Completions 유지 또는 단계적 이전

비용과 지연 시간을 어떻게 줄일까

GPT-5는 강력하지만, 제대로 쓰지 않으면 비용이 쉽게 커진다. 실무에서 가장 효과적인 두 가지 방법은 프롬프트 캐싱과 Batch API다.

프롬프트 캐싱

시스템 프롬프트, 도구 설명, 공용 예시처럼 반복되는 접두부가 길다면 프롬프트 캐싱이 큰 도움이 된다. 특히 에이전트 앱은 같은 정책과 도구 설명을 여러 요청에서 반복하므로 캐시 적중률이 잘 나온다.

좋은 패턴은 다음과 같다.

고정 지침을 앞에 둔다.
사용자별 입력은 뒤에 둔다.
도구 목록과 예시 순서를 자주 바꾸지 않는다.

Batch API

즉시 응답이 필요 없는 대량 작업은 Batch API가 잘 맞는다. 예를 들어 다음 작업은 배치화하기 좋다.

대량 분류
로그 요약
데이터 추출
오프라인 평가

Batch API는 비동기 요청 그룹을 처리하므로, 지연 시간이 덜 중요한 작업에서는 비용과 처리량 모두에 유리하다.

실전 기준

즉시 반응이 중요하면 온라인 요청을 쓴다.
같은 접두부가 반복되면 프롬프트 캐싱을 쓴다.
결과를 바로 보여줄 필요가 없으면 Batch API를 쓴다.

프로덕션 롤아웃 체크리스트

GPT-5를 프로덕션에 넣을 때는 모델 성능보다 운영 설계가 더 중요하다.

핵심 작업과 보조 작업을 분리한다.
gpt-5, gpt-5-mini, gpt-5-nano를 같은 용도로 섞지 않는다.
verbosity와 reasoning_effort의 기본값을 팀 단위로 정한다.
커스텀 툴 입력 형식을 표준화한다.
regex나 CFG가 필요한 지점을 초기에 찾는다.
프롬프트 캐싱이 먹히는 접두부를 고정한다.
Batch API로 넘길 수 있는 작업을 분리한다.
실패 로그, 지연 시간, 토큰 비용을 같이 본다.
에이전트가 만든 결과를 자동 검증하거나 사람 검토로 넘긴다.
모델 교체가 쉬운 인터페이스를 유지한다.

이 체크리스트의 목적은 한 번에 완벽한 에이전트를 만드는 것이 아니다. 작은 안정 경로를 먼저 만들고, 점점 넓히는 것이 목표다.

FAQ

GPT-5는 어떤 작업에 가장 잘 맞나

복잡한 코드 수정, 도구를 오가는 에이전트 작업, 코드베이스 이해, 다단계 디버깅에 가장 잘 맞는다.

`gpt-5-mini`와 `gpt-5-nano`는 어떻게 고르나

gpt-5-mini는 범용 제품 기능과 균형형 워크로드에, gpt-5-nano는 분류와 추출 같은 초저비용 작업에 맞는다.

`reasoning_effort`는 언제 높여야 하나

버그 원인 추적, 도구 선택이 어려운 작업, 여러 단계를 거치는 에이전트 루프에서는 높이는 편이 낫다.

`verbosity`는 왜 중요한가

같은 정답이라도 길이와 설명 수준이 다르면 UI 품질과 운영 효율이 크게 달라진다. 짧은 JSON이나 액션 결과만 필요하면 낮추는 편이 좋다.

새 프로젝트는 Responses API와 Chat Completions API 중 무엇부터 시작하나

새 프로젝트라면 Responses API부터 시작하는 편이 낫다. 기존 서비스와 호환성이 크면 Chat Completions를 유지하면서 단계적으로 옮길 수 있다.