OpenAI가 공개한 GPT-5.6 공식 활용 가이드: 마이그레이션부터 프롬프팅, Pro 모드까지

9bow · 7월 10, 2026, 7:30오전

GPT-5.6 모델 가이드 소개

OpenAI가 개발자 문서 사이트에 GPT-5.6 모델 패밀리를 위한 공식 활용 가이드(Model Guidance)를 공개했습니다. 이 문서는 GPT-5.6으로의 마이그레이션 절차, 새로 추가된 API 기능, 그리고 이전 세대와 달라진 프롬프팅 모범 사례를 한곳에 정리한 실무 지침서로, GPT-5.5나 GPT-5.4 기반 애플리케이션을 운영 중인 개발자라면 반드시 짚고 넘어가야 할 내용을 담고 있습니다.

가이드에서 가장 눈에 띄는 메시지는 *"마이그레이션을 모델 슬러그 교체가 아니라 튜닝 패스(tuning pass)로 취급하라"*는 것입니다. GPT-5.6은 더 적은 토큰으로 같은 수준 이상의 품질을 내는 경우가 많기 때문에, 기존 추론(reasoning) 설정을 그대로 옮기는 것이 아니라 대표 작업에서 현재 설정과 한 단계 낮은 설정을 함께 비교해보라고 권합니다. 즉, 모델 이름만 바꾸고 끝내면 GPT-5.6이 제공하는 토큰 효율 개선을 제대로 누리지 못한다는 의미입니다.

한편 이 가이드는 프롬프팅 관점에서도 흥미로운 전환점을 보여줍니다. 그동안 에이전트 하네스(harness)에 쌓여온 장황한 시스템 프롬프트를 걷어내고 최소한의 프롬프트로 시작하는 편이 오히려 성능과 비용 모두에서 유리하다는, 내부 평가 수치에 기반한 조언이 담겨 있기 때문입니다. GPT-5.6의 새 네이밍 체계와 안전 스택에 대한 개요는 GPT-5.6 Sol, Terra, Luna 프리뷰 소개 글에서 다룬 바 있으며, 이번 글은 그 후속으로 실제 개발 워크플로우에 적용할 수 있는 세부 지침을 정리합니다.

새 네이밍 체계: Sol, Terra, Luna 중 무엇을 쓸 것인가

GPT-5.6은 새로운 네이밍 체계를 도입했습니다. 용도별 세 가지 모델로 구성되며, gpt-5.6 별칭(alias)은 플래그십 모델인 gpt-5.6-sol로 요청을 라우팅합니다.

모델	포지셔닝	권장 용도
`gpt-5.6-sol`	플래그십 성능	최고 품질이 필요한 복잡한 작업
`gpt-5.6-terra`	낮은 가격에 강력한 성능	지능과 비용의 균형이 필요한 작업
`gpt-5.6-luna`	효율 중심	대용량, 고빈도 워크로드

가이드는 추론, 도구 호출, 멀티턴 워크플로우에는 Responses API를 사용할 것을 권장합니다. 아직 Chat Completions API를 쓰고 있다면 이번 마이그레이션을 계기로 함께 전환하는 것이 이후 소개할 기능들(Pro 모드, 추론 컨텍스트 유지 등)을 활용하는 전제 조건이 됩니다.

GPT-5.6에서 새로 추가된 핵심 기능들

가이드가 정리한 GPT-5.6의 주요 신기능은 다음과 같습니다. 각 기능은 별도의 공식 문서와 연결되어 있어, 필요한 부분만 골라 깊이 파고들 수 있습니다.

프로그래매틱 도구 호출(Programmatic Tool Calling, PTC): 모델이 JavaScript 코드를 작성해 호스팅된 런타임에서 여러 도구를 호출하고, 호출 간 결과를 주고받으며 중간 출력을 직접 처리합니다. 매 단계마다 모델의 판단이 필요하지 않은, 도구 호출이 많은 정형화된 워크플로우에 적합합니다. 자세한 내용은 Programmatic Tool Calling 가이드를 참고해주세요.
멀티 에이전트(Multi-agent) 베타: 하나의 GPT-5.6 인스턴스가 여러 서브에이전트를 병렬로 조율하고 결과를 종합합니다. Codex의 울트라 모드와 유사하게, 독립적인 작업 흐름으로 깔끔하게 나뉘는 복잡한 작업에서 처리 시간을 줄이고 성능을 높일 수 있습니다. 현재 Responses API의 베타 기능으로 제공됩니다.
명시적 프롬프트 캐싱(Explicit Prompt Caching): 재사용할 프롬프트 접두 문맥(prefix)을 개발자가 직접 지정해 캐싱할 수 있습니다. 기존의 자동(implicit) 캐싱도 계속 사용할 수 있으며, 캐시 쓰기는 비캐시 입력 요금의 1.25배, 캐시 읽기는 기존처럼 할인된 요금이 적용됩니다. 설정 방법은 프롬프트 캐싱 문서에 정리되어 있습니다.
추론 유지(Persisted Reasoning): 이전 턴의 추론 항목을 다음 턴에서 재사용해 멀티턴 품질과 캐시 효율을 높입니다. reasoning.context 파라미터로 동작을 선택하며, 자세한 내용은 추론 유지 문서를 참고해주세요.
max 추론 강도: 더 많은 탐색과 검증이 필요한 고난도 작업을 위해 기존 xhigh 위에 max 추론 강도가 추가되었습니다. 현재 xhigh를 쓰고 있다면 대표 워크로드에서 두 설정을 비교해보라고 권합니다.
Pro 모드: 품질이 지연 시간이나 토큰 사용량보다 중요할 때, reasoning.mode: "pro" 설정으로 모델이 더 많은 작업을 수행한 뒤 하나의 최종 답변을 반환하게 할 수 있습니다.
토큰 효율과 프론트엔드 품질: GPT-5.6은 더 적은 출력 토큰으로 프론티어 성능에 도달하며, 레이아웃, 시각적 위계, 디자인 판단이 개선되어 더 완성도 높은 웹사이트와 애플리케이션을 만들어냅니다.
의도 이해(Intent Understanding): 모든 단계를 일일이 지정하지 않아도 사용자의 근본 목표와 의도한 작업 수준을 더 잘 추론합니다. 다만 중요한 제약 조건, 승인 경계, 성공 기준은 여전히 명시적으로 서술해야 합니다.
원본 이미지 해상도 유지: original 또는 auto 디테일로 전송된 이미지의 원본 크기를 패치 예산이나 픽셀 제한으로 리사이즈하지 않고 그대로 보존합니다. 큰 이미지는 입력 토큰과 지연 시간이 늘어날 수 있으므로 이미지 디테일 수준 문서를 함께 확인해주세요.

실시간 안전 분류기와 safety_identifier

GPT-5.6에는 출력 생성 중 실시간으로 동작하는 사이버 및 생물학 오용 분류기(misuse classifier)가 적용되어 있습니다. 이 때문에 일부 요청이 차단되거나 거부될 수 있고, 분류기가 출력을 동기적으로 검토하는 동안 생성이 몇 초간 일시 중지되어 응답이 길어질 수도 있습니다. 특히 방어적 활동과 공격적 활동이 초기에는 비슷해 보이는 이중 용도(dual-use) 영역에서는 정당한 작업에 개입하는 경우도 있다고 명시하고 있습니다.

OpenAI는 코드 리뷰, 취약점 연구, 패치 개발, 디버깅, 보안 교육, 방어 테스트 같은 정당한 작업에 대한 접근을 유지하면서도 적대적 압력에 견딜 수 있도록 안전 장치를 계속 개선하고 있다고 밝혔습니다. 개별 최종 사용자를 대상으로 하는 애플리케이션이라면, 요청마다 안정적이고 프라이버시를 보존하는 safety_identifier를 함께 전송할 것을 권장합니다. 구현 방법은 안전 모범 사례 문서를 참고해주세요.

마이그레이션 체크리스트: 슬러그 교체가 아닌 튜닝 패스

가이드는 GPT-5.5 또는 GPT-5.4에서 GPT-5.6으로 옮길 때 확인해야 할 항목을 구체적으로 나열합니다. 핵심은 추론 강도(reasoning effort) 재조정입니다. GPT-5.6은 none, low, medium, high, xhigh, max의 여섯 단계를 지원하며, 다음 원칙을 제시합니다.

기존 GPT-5.5나 GPT-5.4에서 옮겨온다면, 현재 추론 강도를 기준선(baseline)으로 유지한 채 한 단계 낮은 설정과 비교합니다.
none을 쓰고 있다면 지연 시간 기준선으로 유지하되, 워크플로우가 추론이나 도구 사용의 이점을 본다면 low도 함께 테스트합니다.
균형 잡힌 시작점으로는 medium, 지연 시간에 민감한 워크로드에는 low를 사용합니다.
high와 xhigh는 추론을 늘렸을 때 측정 가능한 품질 향상이 있을 때만 사용합니다.
max는 품질이 최우선인 가장 어려운 워크로드에만 예약해두고, xhigh와 비교해 품질, 지연 시간, 비용의 최적 지점을 찾습니다.

추론 유지 기능은 이전 턴의 추론이 얼마나 유효한지에 따라 설정합니다. reasoning.context를 생략하거나 auto로 두면 모델 기본값을 사용하고, 작업의 목표와 가정, 우선순위가 턴 사이에 안정적으로 유지된다면 all_turns로 설정합니다. all_turns에서는 previous_response_id로 대화를 이어가야 이전 응답의 추론이 모델에 제공되며, 히스토리를 직접 관리한다면 이전 사용자 입력과 모든 응답 출력 항목을 보존해 다시 전송해야 합니다. store: false나 데이터 무보존(Zero Data Retention) 환경에서는 include: ["reasoning.encrypted_content"]를 추가하고 반환된 암호화 추론 항목을 재전송합니다. 이전 추론이 더 이상 유효하지 않은 작업이라면 current_turn으로 설정합니다.

프롬프트 캐싱은 코드 변경 없이 기존 자동 캐싱을 계속 쓸 수 있지만, GPT-5.6에서는 캐시 쓰기가 비캐시 입력 요금의 1.25배이므로 cached_tokens와 cache_write_tokens를 추적해 순비용을 파악해야 합니다. 불필요한 캐시 쓰기를 피하려면 명시적 브레이크포인트나 prompt_cache_options.mode: "explicit"을 사용하고, 기존 prompt_cache_retention 파라미터는 prompt_cache_options.ttl로 교체합니다.

마지막으로 가이드는 마이그레이션한 워크플로우를 대표 작업에서 벤치마크하라고 강조합니다. 작업 성공률, 최종 답변의 완결성, 필요한 근거, 총 토큰, 지연 시간, 비용을 함께 비교하되, *"호출, 턴, 중간 출력이 줄어드는 것은 최종 사용자에게 보이는 답변이 요구 품질을 여전히 충족할 때만 개선"*이라는 점을 못박고 있습니다.

Codex로 마이그레이션 자동화하기

흥미롭게도 이 가이드 자체를 Codex가 대신 적용해줄 수 있습니다. OpenAI Docs 스킬을 설치하면 다음 한 줄로 프로젝트 전체에 권장 변경 사항을 적용할 수 있습니다.

$openai-docs migrate this project to the GPT-5.6 model family

이 스킬은 OpenAI skills 저장소에서 내려받아 다른 코딩 에이전트에서도 사용할 수 있습니다. 에이전트가 공식 문서 기반으로 마이그레이션을 수행하는 방식은, 스킬(skill)이라는 형태로 모델에 도메인 지식을 주입하는 최근 흐름을 잘 보여주는 사례입니다.

프롬프트는 더 짧게: 최소 프롬프트가 이긴다

이번 가이드에서 가장 주목할 만한 부분입니다. 가이드는 GPT-5.5에 적용되던 프롬프팅 지침이 GPT-5.6에도 그대로 유효하다고 전제하면서도, 프롬프트의 양에 대해서는 분명한 방향 전환을 제시합니다. OpenAI 내부 평가에서, 길고 명시적인 시스템 프롬프트를 최소한의 프롬프트로 교체했더니 점수가 약 10~15% 향상되면서도 총 토큰은 41~66%, 비용은 33~67% 줄었다고 합니다. 중복된 지시문과 예시를 제거하고 도구 설명을 단순화하는 것이 모델 특화 지침을 추가하는 것보다 더 확실한 효율 개선을 가져왔다는 것입니다.

배경 설명도 설득력이 있습니다. 무거운 프롬프트는 모델의 불필요한 탐색, 반복 검증, 컨텍스트 누적을 부추기는 경향이 있고, 시간이 지나면서 하네스에 쌓여온 오래된 프롬프트 지시문 상당수는 이미 모델의 기본 동작이 되었기 때문에, *"모델이 자연스럽게 수행하지 않는 동작에만 집중하는 것이 가장 큰 이득을 만든다"*고 설명합니다. 구체적인 실행 지침은 다음과 같습니다.

작업을 안정적으로 완수하는 가장 작은 프롬프트와 도구 집합에서 시작하고, 평가에서 구체적인 격차가 드러날 때만 지시문, 도구, 예시를 추가합니다.
작업과 관련된 도구만 노출하고, 도구 설명은 간결하고 정확하게 유지합니다. 큰 도구 집합과 장황한 정의는 시작 컨텍스트를 늘리고 도구 선택의 일관성을 떨어뜨립니다.
예시와 스타일 지침은 아껴서 사용합니다. 프론트엔드, 포맷팅, 문체 지침은 제품 고유 요구사항에만 남기고, 모델이 따라 할 수 있는 반복 표현이나 "X가 아니라 Y" 패턴은 피합니다.
시작 컨텍스트와 누적 컨텍스트를 모두 모니터링합니다. 무거운 프롬프트와 오래된 컨텍스트는 지연 시간과 비용을 늘리면서 불필요한 탐색과 반복 검증을 부추깁니다.

자율성과 권한 경계를 명시적으로 정의하기

GPT-5.6은 능동적이고 끈질기게(proactive and persistent) 동작할 수 있는 모델입니다. 따라서 각 요청이 어느 수준의 행동까지 허용하는지를 프롬프트에서 정의해야 합니다. 가이드는 다음과 같은 간결한 정책이면 대체로 충분하다고 제시합니다.

For requests to answer, explain, review, diagnose, or plan, inspect the relevant
materials and report the result. Do not implement changes unless the request also
asks for them.

For requests to change, build, or fix, make the requested in-scope local changes
and run relevant non-destructive validation without asking first.

Require confirmation for external writes, destructive actions, purchases, or a
material expansion of scope.

파일 읽기, 로그 확인, 검색, 범위 내 코드 수정, 비파괴적 테스트 실행처럼 승인 없이 안전하게 수행할 수 있는 로컬 작업을 명시하는 것이 좋습니다. 반대로 "먼저 물어봐라", "변경하지 마라", "승인을 기다려라" 같은 문구를 프롬프트 곳곳에 반복하는 것은 피해야 합니다. 반복된 금지 지시는 안전하고 당연한 작업에서도 불필요한 승인 확인을 유발할 수 있기 때문입니다.

응답 스타일 제어: 간결함 지시의 함정

GPT-5.6의 응답은 평균적으로 최근 모델들보다 짧습니다. 형식적인 서두가 줄고, 추측성 분기가 적어지고, 목록이 짧아지고, 답변과 근거 사이의 반복이 줄었습니다. 데이터 접근 권한이 없는 상태에서 이탈(churn) 분석을 요청받았을 때, GPT-5.5는 가능한 데이터셋과 비즈니스 맥락 입력을 여럿 나열한 반면 GPT-5.6은 대시보드 내보내기나 테이블 접근을 요청하고, 필요한 최소 필드를 나열한 뒤, 수행할 분석을 설명했다는 비교 사례가 인상적입니다. 커다란 자리표시자 프레임워크를 제공하는 대신 표적화된 질문 하나를 던지는 쪽으로 바뀐 것입니다.

여기서 중요한 주의점이 나옵니다. GPT-5.6은 GPT-5.5보다 "간결하게 답하라", "짧게 유지하라", "최소한의 텍스트만 사용하라" 같은 지시에 더 민감합니다. 이미 압축 성향이 있는 모델에게 이런 일반적인 간결함 지시를 주면, 단순히 군더더기를 제거하는 데 그치지 않고 작업의 우선순위 자체를 바꿔서, 요청받은 완전한 산출물 대신 더 짧은 대체물을 내놓는 것이 낫다고 판단할 수 있기 때문입니다. 가이드는 간결함 지시를 우선순위 지시로 교체하라고 권합니다.

Lead with the conclusion. Include the evidence needed to support it, any material
caveat, and the next action. Omit secondary detail and repetition.

Keep all required facts, decisions, caveats, and next steps. Trim introductions,
repetition, generic reassurance, and optional background first.

이렇게 하면 필수 내용을 제거하도록 부추기지 않으면서도 유용한 간결함을 유지할 수 있습니다. 구조 지침도 마찬가지로 가볍게 유지합니다. 전역 응답 템플릿이 아니라 가벼운 작업별 개요(outline)를 제공하고, 좁은 제약 조건은 평가로 필요성이 입증될 때만 추가합니다.

친근함(warmth) 제어에도 같은 원칙이 적용됩니다. "친절하고 따뜻하게" 같은 일반적 지시로는 모델이 의미 있게 나아지지 않으므로, 다음처럼 구체적인 지침을 사용합니다.

Be direct and tactful. Acknowledge friction specifically when relevant. Avoid
canned reassurance and unnecessary sign-offs.

Pro 모드: 품질이 최우선일 때만 선택적으로

Pro 모드(Pro Mode) 는 요청 하나에 더 많은 모델 작업을 투입한 뒤 단일 최종 답변을 반환하는 Responses API의 실행 모드입니다. 어려운 작업의 신뢰성을 높일 수 있지만 지연 시간이 늘어나고, 투입된 작업의 토큰이 사용량에 합산되어 선택한 모델의 표준 토큰 요금으로 과금됩니다. GPT-5.5 시절의 별도 Pro 모델과 달리, GPT-5.6에서는 선택한 모델을 유지한 채 reasoning.mode를 pro로 설정하는 방식이라는 점이 다릅니다. reasoning.effort는 독립적으로 선택하며, 생략하면 표준 모드와 Pro 모드 모두 medium이 기본값입니다.

가이드가 제시하는 사용 기준은 명확합니다. 미미한 품질 개선이 결과에 실질적인 영향을 주고, 작업이 그 이득을 볼 만큼 어려울 때, 예를 들어 복잡한 최적화, 고부가가치 코딩이나 리뷰, 명확한 평가 기준이 있는 심층 분석에 사용합니다. 반대로 일상적이거나 지연 시간에 민감하거나 대용량인 작업, 그리고 평가에서 의미 있는 이득이 확인되지 않는 모든 경우에는 표준 모드를 사용합니다.

또 하나 흥미로운 지침은 *"모드가 아니라 작업을 위해 프롬프트하라"*는 것입니다. Pro 모드는 API 요청에서 활성화하는 것이지 프롬프트로 켜는 것이 아니므로, "Pro 모드를 사용하라", "더 열심히 생각하라", "여러 후보 답변을 생성하라" 같은 요청을 프롬프트에 넣을 필요가 없습니다. 표준 모드에서 쓰던 것과 같은, 결과 중심의 프롬프트를 그대로 사용하면 됩니다. 가이드의 예시는 다음과 같습니다.

Review this database migration plan for failure modes that could cause data loss
or extended downtime. For each finding, cite the relevant step, estimate impact
and likelihood, and recommend a specific mitigation. Return the five most
important risks in severity order.

도입 전에는 같은 대표 작업에서 표준 모드와 Pro 모드를 비교해 작업 성공률, 답변 완결성, 필요 근거, 총 토큰, 지연 시간, 비용을 측정하고, 품질이나 신뢰성 이득이 추가 비용을 정당화하는 곳에만 선택적으로 사용합니다. 자세한 내용은 추론 모드 가이드를 참고해주세요.

Programmatic Tool Calling: 작업의 형태로 판단하기

프로그래매틱 도구 호출(Programmatic Tool Calling, PTC) 은 코드가 여러 도구 결과나 큰 중간 출력을 처리해 훨씬 작은 구조화된 결과를 반환하는, 경계가 명확한(bounded) 워크플로우에 가장 적합합니다. 필터링, 조인, 랭킹, 중복 제거, 집계, 검증처럼 예측 가능한 처리가 대표적인 사용처입니다.

주의할 점은 호출이 많거나 병렬이거나 의존적이라는 사실만으로는 PTC를 정당화할 수 없다는 것입니다. 가이드는 다음 경우에 일반 도구 호출을 유지하라고 명시합니다.

호출 한 번으로 충분한 경우
중간 출력이 이미 작은 경우
각 결과가 모델의 다음 결정을 바꿀 수 있는 경우
작업에 승인이 필요한 경우
최종 출력이 인용(citation)이나 네이티브 아티팩트를 보존해야 하는 경우

라우팅 지침도 작업별로 구체적이어야 합니다. 도구를 열어두는 것만으로, 혹은 "Programmatic Tool Calling을 효율적으로 사용하라" 같은 일반적 지시만으로 올바른 경로 선택을 기대해서는 안 되며, 어떤 단계가 PTC를 쓰는지, 어떤 도구를 호출할 수 있는지, 정확한 출력 스키마와 필요한 근거는 무엇인지, 동시성과 재시도와 중단 조건은 어떻게 되는지, 어떤 작업은 일반 호출로 남겨야 하는지를 명시해야 합니다. 가이드가 제시하는 템플릿은 다음과 같습니다.

<tool_orchestration>
Use Programmatic Tool Calling for [bounded stage] using only [eligible tools].
Run independent calls concurrently when safe. Use only documented tool input
and output fields.

Process and reduce the intermediate results, then emit exactly [output schema],
including the evidence needed for the final answer.

Stop when [condition] is met. Retry transient failures at most [R] times.
Do not repeat completed calls or perform side-effecting actions. If a required
result is still missing, return a clear structured failure.

Use direct tool calls for [semantic judgment, approval, or final validation].
</tool_orchestration>

API 측에서는 programmatic_tool_calling 도구를 추가하고 allowed_callers로 호출 가능한 도구를 옵트인하며, 각 호출의 call_id와 caller 연결을 보존한 채 program 항목, 프로그램이 발행한 함수 호출, program_output 항목을 처리하도록 애플리케이션을 갱신해야 합니다. 도구 설명에는 예상 반환 필드, 타입, 오류 동작을 문서화해야 하며, 프로그램을 작성하기 전에 반환 형태를 알 수 없는 도구라면 모델이 결과를 확인한 뒤 사용 방식을 결정할 수 있도록 일반 도구 호출을 사용하는 편이 낫습니다. 두 경로가 모두 필요하다면 명확한 핸드오프 지점을 하나 정의하고, 경로를 오가거나 완료된 작업을 반복하지 않도록 지시합니다.

평가 역시 프로그램 결과가 아니라 최종 사용자에게 보이는 답변을 대상으로 해야 합니다. 요구 품질 기준과 주요 효율 목표를 사전에 정의하고, 토큰, 지연 시간, 호출 수, 턴 수가 줄어드는 것은 답변이 그 품질 기준을 충족할 때만 개선으로 간주합니다. 자세한 내용은 Programmatic Tool Calling 가이드를 참고해주세요.

정리하며: 프롬프트 엔지니어링에서 프롬프트 다이어트로

이번 가이드를 관통하는 흐름은 명확합니다. 모델이 똑똑해질수록 개발자가 할 일은 지시문을 쌓는 것이 아니라 걷어내는 것에 가까워지고 있습니다. 최소 프롬프트로 10~15%의 성능 향상과 최대 66%의 토큰 절감을 얻었다는 내부 평가, 간결함 지시가 오히려 산출물 품질을 해칠 수 있다는 경고, 반복된 금지 지시가 불필요한 승인 확인을 유발한다는 관찰은 모두 같은 방향을 가리킵니다. 프롬프트에 쌓인 관성적 지시문들이 이제는 비용이자 성능 저하 요인이 되었다는 것입니다.

동시에 Pro 모드와 PTC, 멀티 에이전트 같은 기능들은 공통적으로 *"평가로 입증될 때만 사용하라"*는 단서를 달고 있습니다. 대표 작업으로 구성된 평가 세트를 갖추고 설정 변경의 효과를 측정하는 습관이, 화려한 신기능보다 먼저 갖춰야 할 기본기임을 다시 확인할 수 있습니다. GPT-5.5 기반 시스템을 운영 중이라면 이 가이드의 체크리스트를 따라 추론 강도와 캐싱 설정부터 재점검해보시기를 권합니다.

OpenAI GPT-5.6 모델 가이드 원문

OpenAI skills 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~

JunHan_Zang · 7월 11, 2026, 4:54오후

5.6 평이 좋던데, 이번에 fable에서 갈아탈까봐요

9bow · 7월 16, 2026, 8:19오전

네네, 저는 둘 다 $100짜리 플랜을 유지하고 있는데, 아래저래 Codex에 손이 더 자주가긴 하네요 ^^;