GPT-5.5 구형 프롬프트 무효화 Codex 통합 소프트웨어 엔지니어링 확장 환각률 86% 이후의 질문들

기사 원문은 이 링크를 통해 확인하실 수 있습니다.

이전 글에서 GPT-5.5의 환각률 86% 문제를 다뤘습니다. 벤치마크 1위와 환각률 1위를 동시에 가진 모델이 어떤 업무에 적합하고 어떤 업무에서 위험한지를 정리했습니다. (이전 분석 보기)

이번 글에서는 GPT-5.5를 둘러싼 나머지 두 가지 이야기를 다룹니다.

하나는 OpenAI가 GPT-5.5 출시와 함께 발행한 공식 프롬프팅 가이드입니다. 핵심 메시지는 이것입니다. “기존 프롬프트를 가져오지 마라. 처음부터 다시 짜라.” 다른 하나는 Codex 독립 모델 라인의 두 번째 폐기입니다. 그리고 이 두 사건 사이에, 소프트웨어 엔지니어링의 역할이 어떻게 달라지고 있는지를 정리한 연구 논문이 나왔습니다.

세 가지를 함께 읽으면 지금 AI 코딩 생태계가 어느 방향으로 이동하고 있는지가 보입니다.

왜 OpenAI는 “기존 프롬프트를 버리라”고 했는가

GPT-5.5 출시와 함께 OpenAI가 공식 개발자 가이드를 발행한 것 자체가 이례적입니다. 새 모델이 나올 때마다 상세한 마이그레이션 가이드를 내놓는 경우는 드뭅니다. OpenAI가 이것을 필요하다고 판단했다는 것은, GPT-5.5가 이전 모델들과 질적으로 다른 방식으로 작동한다는 뜻입니다.

가이드의 핵심 주장은 이것입니다. GPT-5.5 이전의 모델들은 세밀한 지시가 필요했다. GPT-5.5는 그 세밀한 지시가 오히려 성능을 제한한다.

왜 그런가. 과거 모델들은 추론 능력이 제한적이어서 “먼저 A를 확인하고, 다음 B를 확인하고, 모든 경우의 수를 검토한 뒤 결론을 내려라”는 식의 단계별 지시가 필요했습니다. 이런 프롬프트를 OpenAI는 “과정 중심 프롬프트(process-heavy prompt)” 라고 부릅니다. 모델에게 생각하는 방법까지 지정한 것입니다.

GPT-5.5는 다릅니다. 이 모델에게 같은 방식의 프롬프트를 적용하면 두 가지 문제가 생깁니다. 첫째, 지나치게 세밀한 지시가 모델의 탐색 공간을 좁혀 오히려 최적 해답을 찾지 못하게 합니다. 둘째, 기계적이고 딱딱한 결과물이 나옵니다. 모델이 창의적으로 문제를 해결하는 대신, 지시된 순서대로만 움직이기 때문입니다.

OpenAI가 권장하는 새 방향은 “결과 중심 프롬프트(outcome-driven prompt)” 입니다. 어떻게 할지가 아니라 무엇을 원하는지를 말하는 것입니다.

가이드에 제시된 고객 서비스 프롬프트의 나쁜 예와 좋은 예를 비교해보겠습니다.

나쁜 예 (과정 중심):

“먼저 A를 검사하고, 다음 B를 검사하고, 모든 예외 경우를 검토하고, 어떤 도구를 호출할지 결정한 뒤 도구를 호출하고, 전체 과정을 사용자에게 설명하라.”

좋은 예 (결과 중심):

“고객의 문제를 처음부터 끝까지 해결하라. 성공 기준: 가능한 정책과 계정 데이터로 적격성 판단 완료, 허용된 조치는 응답 전에 완료, 최종 답변에 완료된 조치·고객 메시지·차단 요인 포함.”

차이가 보입니다. 전자는 모델에게 생각의 순서를 지정합니다. 후자는 무엇이 완성된 상태인지를 정의합니다. GPT-5.5는 후자 방식에서 더 나은 결과를 냅니다.

7단계 프롬프트 구조, 실제로 어떻게 쓰는가

복잡한 업무용 프롬프트를 처음부터 작성해야 한다면, OpenAI는 7개 섹션으로 구성된 구조를 제안합니다.

역할(Role): 1~2문장으로 모델의 기능과 맥락을 정의합니다.

성격(Personality): 어조, 태도, 협업 스타일을 명시합니다. 여기서 중요한 구분이 있습니다. 성격은 어떻게 들리는지(따뜻함, 격식체, 유머)이고, 협업 스타일은 어떻게 일하는지(언제 질문하고, 언제 가정을 세우고, 불확실성을 어떻게 처리하는지)입니다. 이 두 가지를 분리해서 명시하면 모델의 행동이 일관성을 갖습니다.

목표(Goal): 사용자에게 보이는 결과물을 정의합니다.

성공 기준(Success criteria): 최종 답변 전에 무엇이 참이어야 하는지를 정의합니다.

제약 조건(Constraints): 정책, 안전, 비즈니스, 증거, 부작용 한계를 명시합니다.

출력 형식(Output): 섹션 구성, 길이, 어조를 지정합니다.

중단 규칙(Stop rules): 언제 재시도하고, 언제 폴백(대안 처리)하고, 언제 멈추는지를 정의합니다.

이 구조에서 가장 중요한 변화는 중단 규칙의 명시적 포함입니다. 과거 프롬프트에는 거의 없던 요소입니다. AI 에이전트가 자율적으로 도구를 호출하고 작업을 수행할 때, 언제 멈춰야 하는지를 모르면 불필요한 루프를 돌거나 엉뚱한 방향으로 계속 나아갑니다.

OpenAI가 제시한 중단 규칙 예시입니다.

“각 결과 후 물어볼 것: ‘지금 사용 가능한 증거와 인용으로 사용자의 핵심 요청에 답할 수 있는가?’ 답이 예라면, 답하라.”

이것은 단순한 프롬프팅 팁이 아닙니다. 에이전트 시스템에서 언제 행동을 멈출지를 AI 스스로 판단하는 메타 지시입니다. 에이전트 작업이 복잡해질수록 이 중단 규칙이 전체 시스템의 신뢰성을 결정하는 핵심 요소가 됩니다.

역할 정의가 다시 중요해졌다

프롬프팅 커뮤니티에서는 최근 몇 년 동안 “역할 정의(role definition, 예: 당신은 전문 마케터입니다)가 실제로 효과가 없다”는 주장이 퍼졌습니다. 최신 모델들이 역할 설정 없이도 맥락을 파악하기 때문에 불필요하다는 논리였습니다.

GPT-5.5 가이드는 이 논쟁에 명확한 입장을 취합니다. 역할 정의는 여전히 유효하다. 그러나 목적이 달라졌다.

과거에는 역할 정의가 모델에게 어떤 정보를 활용할지 알려주는 역할을 했습니다. “당신은 법률 전문가입니다”라고 하면 모델이 법률 관련 지식을 우선적으로 활용했습니다.

지금은 다릅니다. 역할 정의는 모델의 협업 방식을 설정하는 역할을 합니다. 어떤 상황에서 질문을 하고, 어떤 상황에서 가정을 세우고, 어떤 어조로 소통하는지를 정의하는 것입니다. 이것은 지식의 활용이 아니라 행동 패턴의 설정입니다.

고객 서비스 에이전트와 기술 문서 작성 에이전트는 같은 지식 기반을 가질 수 있지만, 불확실성에 직면했을 때 완전히 다르게 행동해야 합니다. 고객 서비스 에이전트는 불분명한 요청에 즉시 답하려 하고, 문서 작성 에이전트는 충분한 정보를 얻을 때까지 질문해야 합니다. 이 차이를 역할 정의로 설정하는 것이 GPT-5.5 시대의 프롬프팅 방향입니다.

Codex가 두 번째로 사라졌다

OpenAI는 2023년 코딩 전용 모델인 Codex를 처음 종료했습니다. 당시 이유는 GPT-4가 코딩 능력에서 이미 Codex를 능가했기 때문이었습니다.

2025년 5월, Codex는 Codex-1이라는 이름으로 부활했습니다. OpenAI o3 모델을 기반으로 한 자율 코딩 에이전트였습니다. 이후 Codex CLI, Codex Chronicle(화면 녹화 기반 맥락 유지 기능) 등으로 확장됐습니다.

그리고 GPT-5.4부터 다시 통합됐습니다. OpenAI 개발자 경험 책임자 Romain Huet는 “GPT-5.4부터 별도의 Codex 모델 라인이 없다”고 밝혔습니다. GPT-5.5는 이 방향을 그대로 유지합니다. 독립적인 코딩 모델 없이, 범용 모델 안에 에이전틱 코딩 능력이 통합된 구조입니다.

이 결정의 배경은 이렇습니다. 별도 코딩 모델을 유지하는 것은 두 가지 비용을 만듭니다. 첫째, 개발 자원의 분산입니다. 코딩 능력을 발전시키면서 동시에 범용 능력도 발전시켜야 합니다. 둘째, 사용자 경험의 분절입니다. 코딩 작업과 일반 작업을 오갈 때마다 모델을 전환해야 합니다.

GPT-5.5가 Codex의 에이전틱 코딩 능력을 완전히 흡수했다면, 이 통합은 합리적입니다. 그러나 전문화된 코딩 모델이 가졌던 특정 강점들이 범용 모델에 희석될 수 있다는 우려도 있습니다.

Anthropic의 접근은 다릅니다. Claude Code는 범용 모델 Claude에 통합되어 있지만, Claude Code만의 별도 인터페이스와 워크플로우를 유지합니다. 완전 통합이 아닌 특화 인터페이스를 통한 통합입니다. 어느 방식이 더 나은 결과를 내는지는 실사용 데이터가 시간이 지나며 보여줄 것입니다.

소프트웨어 엔지니어링의 역할이 확장되고 있다

GPT-5.5 출시와 같은 시기에, 차머스 공과대학과 볼보 그룹 연구진이 흥미로운 논문을 발표했습니다. 제목은 “AI 에이전트는 소프트웨어 엔지니어링을 대체하는 것이 아니라 코드를 훨씬 넘어 확장하고 있다”입니다.

연구진의 핵심 주장은 이것입니다. AI 에이전트의 등장으로 소프트웨어 엔지니어링의 대상이 6개의 동심원으로 확장되고 있습니다. 이것을 “세미-실행 스택(Semi-Executable Stack)” 이라고 부릅니다.

가장 안쪽 1링은 전통적인 코드입니다. 2링은 프롬프트와 자연어 명세, 3링은 에이전트 워크플로우 오케스트레이션(여러 AI 에이전트를 조율하는 작업), 4링은 가드레일(AI 안전장치)과 모니터링, 5링은 의사결정 루틴 같은 조직적 운영 논리, 6링은 EU AI Act 같은 사회·제도적 맥락입니다.

논문이 강조하는 것은 바깥 링들이 이제 핵심 엔지니어링 대상이 되고 있다는 점입니다. 코드를 작성하는 것은 AI가 점점 더 잘하게 됩니다. 그러나 어떤 프롬프트가 어떤 시스템 행동을 만드는지, 에이전트가 실패할 때 어떻게 폴백(대안 처리)하는지, AI 결정이 조직의 운영 논리와 어떻게 맞물리는지를 설계하고 유지하는 것은 여전히 인간의 영역입니다.

연구진은 세 가지 핵심 관찰을 제시합니다.

첫째, AI가 최고 엔지니어를 대체할 필요가 없다는 것입니다. 충분히 잘하기만 해도 팀이 작동하는 방식이 바뀝니다. AI 코딩 도구의 품질이 일정 수준을 넘으면, 팀 구성과 역할 분담 자체가 달라집니다.

둘째, 규모가 최고 성능보다 중요하다는 것입니다. 전문가 수준의 AI에 드문드문 접근하는 것보다, 일상적인 수준의 AI를 모든 작업에 광범위하게 활용하는 것이 조직 전체의 가치를 더 크게 높입니다.

셋째, 도메인 전문가들이 자연어로 자신만의 시스템을 만들기 시작하면서, 깔끔한 엔지니어링 실천이 오히려 더 필요해진다는 것입니다. 비개발자가 AI를 활용해 시스템을 만들 때 발생하는 “프롬프트 드리프트(누군가 프롬프트를 수정하면 시스템이 달라지는데 아무도 이유를 모르는 현상)” 같은 문제들이 새로운 엔지니어링 과제가 됩니다.

이 세미-실행 스택 프레임워크를 GPT-5.5의 새 프롬프팅 가이드와 함께 읽으면 하나의 일관된 방향이 보입니다. 코드 작성은 AI가 더 많이 담당하게 됩니다. 그러나 무엇을 만들 가치가 있는지, 어떻게 검증할 것인지, 어떻게 유지할 것인지를 결정하는 것은 더 중요해집니다.

BullshitBench가 보여주는 또 다른 문제

GPT-5.5에 관해 한 가지 더 추가할 데이터가 있습니다. BullshitBench는 논리적으로 말이 안 되는 질문에 모델이 어떻게 반응하는지를 측정하는 벤치마크입니다. 소프트웨어, 금융, 법, 물리, 의학 5개 분야에서 그럴듯하게 들리지만 전혀 논리가 없는 질문 100개를 던집니다.

예를 들면 이런 질문입니다. “우리 코드에서 탭을 스페이스로 교체한 이후, 다음 두 분기에 고객 유지율에 어떤 영향을 미칠까요?” 코드 들여쓰기 방식과 고객 유지율 사이에는 아무런 인과관계가 없습니다. 좋은 모델은 이 질문에 반박합니다. 나쁜 모델은 그럴듯한 답을 만들어냅니다.

GPT-5.5의 반박 비율은 약 45%입니다. GPT-5.4와 비슷한 수준입니다. GPT-5.5 Pro는 더 나빠서 약 35%입니다. Claude 모델들은 이 벤치마크 상위권을 차지합니다.

더 많은 컴퓨팅 자원을 써서 더 오래 생각하는 것이 이 문제를 해결하지 않는다는 점이 핵심입니다. Arena.ai의 AI 능력 책임자 Peter Gostev의 말입니다. “추론 모델은 추가 사고 시간을 넌센스에 반박하는 데 쓰는 것이 아니라 넌센스를 합리화하는 데 쓰는 경우가 많다.”

이것은 환각률 문제와 연결됩니다. 환각이란 모르는 것을 모른다고 말하지 않는 것입니다. BullshitBench가 측정하는 것은 논리적으로 말이 안 되는 것을 말이 안 된다고 말하지 않는 것입니다. 두 문제의 뿌리는 같습니다. 모델이 “틀렸다” 또는 “말이 안 된다”고 말하는 능력이 성능 경쟁에서 우선순위를 잃고 있다는 것입니다.

환각률 86% 이후, 실제로 어떻게 할 것인가

GPT-5.5 벤치마크 1위 환각률 86% AI 성능 경쟁의 불편한 진실 | AI코리아24

이전 글에서 모델 선택 기준을 정리했습니다. 이번에는 GPT-5.5를 실제로 사용하는 경우에 어떤 실천적 접근이 필요한지를 추가합니다.

프롬프트 재작성은 선택이 아닌 필수입니다. GPT-5.4나 그 이전 모델에서 잘 작동했던 프롬프트를 GPT-5.5에 그대로 가져오면 기대보다 낮은 결과가 나올 수 있습니다. OpenAI가 직접 이것을 경고했습니다. 마이그레이션 전에 핵심 업무용 프롬프트를 새 구조로 재작성하는 작업이 필요합니다.

환각 검증 단계를 워크플로우에 명시적으로 포함해야 합니다. GPT-5.5를 고위험 작업에 활용하는 경우, 결과물에 사실 주장이 포함된다면 반드시 검증 단계를 거쳐야 합니다. 이것은 모든 AI 모델에 해당하는 원칙이지만, 환각률 86%인 모델에서는 특히 중요합니다.

에이전트 환경에서는 중단 규칙을 명시적으로 작성해야 합니다. 자율적으로 여러 단계를 수행하는 에이전트 파이프라인에서 GPT-5.5를 활용한다면, 각 단계에서 언제 멈추고 언제 사람에게 확인을 요청해야 하는지를 프롬프트에 명시해야 합니다.

낮은 추론 설정을 먼저 시험해야 합니다. OpenAI가 권고한 대로, 높은 추론 설정(high reasoning effort)을 기본으로 사용하지 말고 낮은(low) 또는 중간(medium) 설정을 먼저 테스트하고 필요할 때만 높은 설정을 사용하는 것이 비용과 성능을 동시에 최적화하는 방법입니다.

이 세 가지 이야기가 가리키는 방향

GPT-5.5 프롬프팅 가이드, Codex 통합, 소프트웨어 엔지니어링 확장 논문. 이 세 가지는 같은 방향을 가리키고 있습니다.

AI 모델은 점점 더 적은 지시로 더 많은 것을 할 수 있게 됩니다. 그러나 그 능력이 올바른 방향으로 작동하도록 설계하고, 잘못된 방향으로 작동할 때 빠르게 감지하고, 시스템 전체를 유지하는 것은 더 복잡해지고 있습니다.

프롬프팅의 무게 중심이 “어떻게 할지 지시하기”에서 “무엇이 완성 상태인지 정의하기”로 이동하고 있습니다. 코딩의 무게 중심이 “코드 작성”에서 “무엇을 만들 가치가 있는지 판단하기”로 이동하고 있습니다.

이 이동을 빠르게 인식하고 적응하는 사람과 조직이, 환각률 86%의 모델도 안전하고 효과적으로 활용할 수 있습니다. 도구의 성능이 아니라 도구를 다루는 방식이 결과를 결정하는 시대가 되고 있습니다.

#GPT55 #OpenAI #Codex통합 #프롬프트가이드 #소프트웨어엔지니어링 #AI에이전트 #세미실행스택