4,872
에이전트가 이전 대화와 프로젝트 상태를 기억하면 사용자는 같은 설명을 반복하지 않아도 됩니다. 그러나 새 Model Spec은 문맥이 유용하다는 사실과 그 문맥을 현재 행동의 권한으로 삼을 수 있다는 판단을 분리합니다.[17]
OpenAI는 2026년 10월 29일 Model Spec을 개정하며 문맥 활용과 human agency 지침을 추가하고, 부작용 관리 지침을 확장했습니다. 이번 글은 모델의 성능 발표가 아니라 기억을 사용하는 앱의 행동 계약을 어떻게 설계할 것인가를 다룹니다.[21]
💡 💡 핵심: 기억은 의도 해석의 근거이지 새로운 권한이 아닙니다. 개인화에 쓸 수 있는 정보와 공유해도 되는 정보를 구분하고, 자동화 결과를 사람이 검증·수정·중단·인수인계할 수 있게 설계하는 것이 이 글의 제안입니다.[17]
개정 Spec은 인간 의도에 대한 충실성, 피해 최소화, 정직성과 투명성, 인간의 주도성, 배려라는 다섯 가치로 지침을 재구성했습니다. 세부적인 style guidance는 대부분 퇴역시키되, 객관적으로 접근하는 것 같은 더 강한 기본 원칙은 유지합니다.[21]
특히 새 Consider context carefully는 이전 대화·기억·검색 자료·파일·tool output을 어떻게 활용할지 다룹니다. 발표는 Support human agency 기본 지침을 추가하고 기존 Control and communicate side effects를 확장했다고 설명합니다.[21][17]
개발 관점의 해석: 사용자 취향에 맞는 답변을 만드는 일에서 한 걸음 더 나아가, 무엇을 근거로 판단했으며 어디까지 행동해도 되는지를 앱의 명세로 만들어 볼 만합니다.
Spec은 이전 지시, 선호, 사실과 추론, 프로젝트 상태를 구분합니다. 선호는 상황에 맞는 기본값이고, 과거의 사실과 추론은 오래됐거나 틀렸을 수 있는 근거입니다. 한 상황에서 받은 요청을 곧바로 영구적인 선호로 취급해서도 안 됩니다.[17]
예를 들어 평소 bullet 답변을 좋아하던 사용자가 두 문단의 추천서를 요청했다면, 현재 형식 요청을 따르는 것이 문서의 올바른 예시입니다. 반대로 진행 중인 프로젝트 맥락을 이미 알고도 처음부터 다시 묻는 것은 불필요한 반복으로 제시합니다.[17]
Spec은 문맥적 근거가 관련 있다는 이유만으로 권위를 얻는 것은 아니라고 명시합니다. 추론한 선호는 같은 수준 또는 더 높은 수준의 명시적 지시를 덮어쓸 수 없습니다.[17]
자율 실행에도 별도의 범위가 필요합니다. 어떤 하위 목표와 부작용을 허용하는지, 언제 승인받고 언제 끝낼지를 정해야 하며, 범위 밖 행동이 사용자에게 유익해 보인다는 이유로 예외를 만들 수 없다는 원칙입니다.[17]
개인 대화에서 활용하기 적절한 사실이 이메일·Slack 메시지·공유 문서에 공개하기에도 적절한 것은 아닙니다. Spec은 정보의 출처와 수신 대상, 목적에 맞는 contextual integrity를 요구합니다.[17]
따라서 “기억에서 가져올 수 있음”, “현재 작업에 관련 있음”, “외부 수신자에게 보여도 됨”을 같은 판단으로 묶지 않는 것이 좋습니다. 이는 원문 원칙을 앱 구조에 옮긴 설계 제안입니다.
다음은 Spec의 API나 공식 구현이 아니라 원칙을 구현하기 위한 제안 흐름입니다.
Spec 자체도 자율 실행 범위를 도구·시간·비용·제약 등을 담는 semi-structured record로 남겨 플랫폼의 검증과 감사를 돕도록 권고합니다. 다만 이것이 모든 제품에서 제공되는 공통 API schema라는 뜻은 아닙니다.[17]
💡 ⚠️ 설계 권고: 모델이 “권한이 있다”고 판단한 문장만으로 쓰기 도구를 열지 마세요. 허용 대상·행동·수신자를 애플리케이션에서 별도로 검사하고, 고위험 작업은 실제 승인 기록과 연결하는 쪽을 권합니다.
제안 시나리오: 내부 문서에서 주간보고 초안을 만드는 앱을 생각해 보겠습니다. 사용자는 초안 작성을 맡겼지만 팀 채널 전송은 아직 허용하지 않았습니다.
이때 과거에 같은 채널로 보냈다는 기록을 이번 전송 허가로 취급하지 않도록 설계합니다. 초안에는 보고에 필요한 프로젝트 사실만 넣고, 개인 대화에서 알게 된 건강 상태나 동료에 관한 사적인 평가는 별도 검토 대상으로 분리합니다.
출력에는 사용한 문서와 확인 시점, 현재 요청에서 정한 대상 독자, 아직 실행하지 않은 전송 단계를 표시하는 편이 좋습니다. 수신자·발송 시점·포함 내용을 승인받으면 해당 범위만 실행하도록 연결할 수 있습니다.
이 흐름은 여기서 구현하거나 실행한 결과가 아닙니다. 실제 앱에서는 정보 분류의 정확도와 승인 누락·중복 전송 같은 실패 경로를 별도로 검증해야 합니다.
매번 같은 입력을 받아 정해진 문서 초안만 만드는 작업이라면, 장기 기억을 먼저 붙이지 않고 현재 입력 + 명시적 템플릿 + 사람 검토로 시작하는 편을 권합니다. 기억의 신선도와 공개 범위를 관리하는 설계 부담을 늘리지 않아도 되기 때문입니다.
여러 대화에 걸친 프로젝트를 이어가는 일이 핵심이라면 관련 문맥을 활용할 이유가 있습니다. Spec도 문맥의 과용뿐 아니라 알려진 제약을 무시하거나 사용자가 프로젝트 설명을 반복하게 만드는 과소 활용의 비용을 함께 고려하라고 합니다.[17]
두 방식의 속도나 품질 우열을 이 글에서 측정하지는 않았습니다. 선택 기준은 “얼마나 많이 기억할까”보다 반복 설명을 줄이는 이익이 잘못된 재사용·공개 위험을 정당화하는가입니다.[17]
Spec에는 사용자가 동료에게 임신 사실을 알리지 않았다는 이전 문맥과, 특정 치즈를 피하도록 점심 장소 변경 이메일을 써 달라는 요청이 함께 나옵니다. 올바른 예시는 식이 제한만 언급하고, 잘못된 예시는 임신 사실을 팀 이메일에 드러냅니다.[17]
이는 실제 고객의 유출 사고나 제품 도입 성과가 아니라, 개인 문맥을 공유 산출물로 옮길 때의 경계를 설명하는 문서 예제입니다.[17]
다른 예시에서는 주간 매출 보고 자동화를 만든 뒤 휴가 중 담당자가 이어받을 수 있게 합니다. 올바른 결과는 팀 소유 공간에 설정하고, 담당자가 query·수신자·중단 방법을 확인할 수 있게 하는 것입니다. 담당자가 접근하지 못하는 개인 공간에 만들어 둔 경우는 잘못된 예시로 제시합니다.[17]
여기서 얻을 설계 교훈은 완료 조건을 “작업을 만들었다”가 아니라 책임자가 이해하고 통제할 수 있는 상태로 넘겼다로 확장하는 것입니다. 이 역시 실제 운영 성과를 측정한 주장은 아닙니다.
OpenAI는 현재 모델이 개정 Spec을 아직 완전히 반영하지 못한다고 명시합니다. 새 문서가 나왔다는 사실만으로 특정 모델이 그날부터 모든 원칙을 준수한다고 볼 수 없습니다.[21][17]
공식 model_spec_evals repository는 평가 prompt와 Inspect AI 기반 실행 코드를 제공하며, 후보 모델과 grader의 sampling을 늘리는 방법도 설명합니다. 공개 예제 결과를 모든 앱·최신 모델의 준수율로 옮겨 쓰면 안 됩니다.[43]
독립 작성자 Michel Justen의 9월 평가 글은 당시 공개 평가가 text-only이고, 거의 단일 응답이며, 비적대적이라는 한계를 지적합니다. 이 자료는 10월 29일 새 Spec을 시험한 결과가 아니며, 이번 조사에서 그 평가를 재실행하지도 않았습니다.[33]
따라서 팀 앱에서는 문서 속 올바른 답변과 비슷한 문장을 내는지뿐 아니라, 민감한 정보를 공유 초안에서 제외했는지, 범위 밖 도구 호출을 차단했는지, 담당자가 결과를 수정·중단할 수 있는지를 검증 대상으로 삼기를 권합니다.
💡 🔍 검증 범위: 개정 발표·날짜 고정 Spec·공식 repository·기존 독립 평가 글을 읽은 문헌 조사입니다. 새 버전의 실서비스 준수율, 보안성, 도입 효과는 독립 검증하지 않았습니다. 본문 시나리오도 실행하지 않았습니다.
이번 개정에서 가져갈 핵심은 가치 다섯 개를 암기하는 것이 아닙니다. 문맥을 활용할 때 관련성, 지시 권위, 공개 대상, 실행 범위를 나눠 판단하라는 것입니다.[17][21]
개발 적용은 작게 시작해도 됩니다. 초안 생성과 전송을 분리하고, 사실의 출처·시점을 남기며, 완료 결과를 사람이 검증하고 넘겨받을 수 있게 만드는 것부터 점검해 보세요.
공식 repository에는 Markdown 원문과 과거 HTML 버전 archive가 있습니다. 운영 기준을 문서화한다면 변화하는 최신 페이지뿐 아니라 검토한 버전도 함께 남기는 편을 권합니다.[35]
이 글의 기준은 2026-10-29 Model Spec, 자료 확인일은 2026-10-30 KST입니다. 실행 결과나 고객 도입 사례가 아니라, 새 행동 명세에서 개발자가 가져갈 설계 기준을 정리했습니다.
[17] https://model-spec.openai.com/2026-10-29.html — model-spec-2026-10-29
[21] https://openai.com/index/updated-model-spec — updated-model-spec
[33] https://micheljusten.substack.com/p/openai-stopped-reporting-model-spec — spec-eval-independent
[35] https://github.com/openai/model_spec — spec-repo
[43] https://github.com/openai/model_spec_evals — spec-evals-repo