OpenAI 개발자 블로그에 2026년 9월 11일 올라온 글 Rethinking skills and prompts for GPT-6 Astra (Eric Provencher) 를 정리한다. 요지는 한 줄이다. 모델이 좋아졌으니, 예전 모델을 길들이려고 쌓아둔 지시문이 이제는 짐이 된다.

코딩 에이전트를 1년쯤 쓰면 지시문이 계속 쌓인다. 스킬(skill), AGENTS.md, 그리고 작업 프롬프트 — 셋 다 모델이 일하는 방식을 규정한다. 새 모델이 나올 때마다 그 가정을 다시 볼 가치가 있었는데, GPT-6 Astra 에서는 그게 어느 때보다 중요해졌다는 게 글의 출발점이다.

출처 성격을 먼저 밝힌다. 이 글은 OpenAI 가 자사 모델에 대해 낸 1차 공식 문서다. “Astra 는 더 신중하다” 같은 모델 거동에 대한 서술은 벤더 주장이고, 이 글을 쓰는 시점에 그걸 검증한 중립 제3자 자료는 확인하지 못했다. 반면 “설명이 길면 잘린다” 같은 제품 동작은 벤더가 자기 제품에 대해 말하는 사실 진술이라 성격이 다르다. 아래에서 둘을 섞지 않으려 했다.

1. 스킬 — 설명이 길면 잘린다

스킬은 마크다운 파일로 저장된 프롬프트다. 리소스나 스크립트를 같이 묶을 수도 있다. 특정 워크플로나 특정 앱을 쓸 때의 지침으로 유용하다.

문제는 스킬의 이름과 설명(description)이 모델 컨텍스트에 항상 올라간다는 점이다. 언제 쓸지 판단하려면 봐야 하니까. 그런데 사람들이 설명을 너무 길게 쓰고, 스킬을 너무 많이 넣는다. 그러면 Codex 가 설명을 줄여서 넣기 시작한다. 모델이 보는 설명이 짧아지고, 결국 어떤 스킬을 골라야 할지 판단이 나빠진다.

더 나쁜 건 설명끼리 서로 모순되거나, 써야 할 시점을 과장하는 경우다. 그러면 모델이 지금 과제에 도움도 안 되는 지침을 불러온다.

1-1. 언제 적용되는지를 좁게 써라

글이 든 대비 예시가 명쾌하다.

나쁜 예

Create and validate Postgres schema migrations. Use when working with databases, queries, models, or persistence.

좋은 예

Create and validate Postgres schema migrations. Use when adding or changing a migration, or reviewing its rollout.

나쁜 쪽은 “데이터베이스 관련이면 뭐든” 으로 읽힌다. 쿼리 한 줄 고칠 때도 마이그레이션 스킬이 끌려온다. 좋은 쪽은 마이그레이션을 추가·변경하거나 롤아웃을 검토할 때로 발동 조건을 좁힌다.

1-2. 점진적 공개(progressive disclosure)

스킬을 읽는 것 자체가 컨텍스트를 쓴다. 컴팩션에 가까워지고, 지금 과제와 무관한 지침이 섞여 들어온다. 그래서 워크플로가 여럿인 스킬은 루트 문서를 최소한의 라우터로 만들고 보조 문서와 스크립트를 가리키게 하라는 게 권고다. 어디를 봐야 하는지만 알려주고, 지금 필요 없는 건 읽히지 말라는 뜻이다.

1-3. 레시피처럼 쓰지 마라

많은 스킬이 정교한 일정표나 요리법처럼 쓰여 있다. 모델이 뉘앙스와 모호함을 다루는 능력이 크게 좋아졌기 때문에, 예전에 도움이 되던 과잉 구체 지침이 이제는 결과를 해칠 수 있다는 것이다.

1-4. 그 스킬은 당신 모델만 쓰는 게 아니다

리포지터리에 넣은 스킬은 다른 기여자의 에이전트도 읽는다. 그 에이전트는 다른 모델일 수 있다. 글은 이걸 명시적으로 짚는다 — Sol 이나 Luna 에게 도움이 되는 지침이 GPT-6 Astra 에게는 과도한 제약이 될 수 있으니, 어떤 모델들이 이 지침을 읽게 될지 고려하라는 것이다.

개인적으로 이 항목이 가장 실무적이라고 본다. 리포에 체크인된 지침은 사실상 여러 벤더의 모델을 동시에 대상으로 하는 공용 인터페이스다. 특정 모델의 약점을 때우려고 넣은 문장이 리포에 영구히 남아 다른 모델을 망가뜨리는 구조다.

2. AGENTS.md — “매번 읽어라” 를 지워라

AGENTS.md 는 그 리포에서 모델이 일할 때 항상 적용된다. 그래서 각 지시가 아직도 필요한지 자주 되물어야 한다.

나쁜 예

Before every edit, read architecture.md, database.md, and deployment.md.

좋은 예

Use architecture.md for service boundaries, database.md for schema changes, and deployment.md when preparing a deployment.

오타 하나 고치는 데 문서 세 개와 리포 전체 지도를 먼저 읽으라는 건 과하다. 글의 표현은 직설적이다 — 편집할 때마다 파일을 읽으라고 시키는 건 컨텍스트를 태우고 작업을 느리게 만드는 훌륭한 방법이다. 문서를 가리키는 것 자체는 여전히 유용하지만, 맥락에 따라 가리켜야 한다. 물론 그 문서들이 최신이어야 한다는 전제가 붙는다.

또 하나. 예전 모델은 테스트를 돌리고 자기 작업을 검증하도록 떠밀어야 했다. Astra 는 알아서 한다. 그래서 같은 지시가 이제는 불필요한 테스트를 유발한다.

3. 경계선 표현 — 세게 써둔 문장이 발목을 잡는다

이 절이 이 글에서 가장 흥미롭다.

예전 모델이 허락 없이 일을 저질러서, “반드시 먼저 물어봐라” 같은 강한 문장을 넣어둔 경우가 많다. 그런데 OpenAI 는 Astra 를 자사에서 가장 정렬된(most aligned) 모델이라고 설명하면서, 안전하다고 판단되지 않으면 애초에 실행하지 않으니 그에 맞게 대우하라고 한다.

즉 다른 모델이 선을 넘는 걸 막으려고 써둔 문장을 그대로 두고 Astra 로 갈아타면, Astra 가 그걸 너무 진지하게 받아들여서 당신이 사실은 계속 진행하길 원했던 지점에서 멈춰 설 수 있다.

강한 경계 문장이 안전장치에서 생산성 저해로 성격이 바뀌는 순간이 있다는 얘기다. 여기서 주의할 점 — 이건 “경계를 지워라” 가 아니다. 지금도 유효한 경계인지 다시 보라는 말이다. 실제로 위험한 경계는 그대로 둬야 한다.

4. 지속성(persistence) — 완료를 먼저 정의하라

GPT-5.6 Sol 이 한 번 시키면 길게 쭉 가는 데 익숙하다면, Astra 는 언제 멈출지에 대해 더 머뭇거리는 느낌을 받을 수 있다. 첫 구현을 해놓고 아직 남은 일이 있는데도 리뷰를 받으러 돌아올 수 있다는 것이다.

그래서 시작 전에 “완료”를 정의하라는 게 처방이다. 과제에 구현을 돌려보고, 결과를 확인하고, 실패한 걸 고치는 것까지 포함된다면 그걸 요청에 넣어라. 그리고 중요한 지적이 하나 붙는다 — “첫 구현 후 리뷰를 위해 멈춰라” 라는 요구사항 자체가 모델을 더 이른 정지점으로 끌어당긴다. 그게 정말 당신이 내려야 하는 결정인지 따져보라는 것이다.

첫 패스를 넘어 계속 탐색하길 원한다면, 무엇을 탐색할지와 어디서 멈출지를 말하라.

글은 AGENTS.md 로 특정 워크플로에 미리 허가를 주는 예시도 든다.

The local tests use disposable fixtures and have no production access. Run them, fix failures caused by the requested change, and rerun affected tests without asking for approval at each step.

“로컬 테스트는 일회용 픽스처를 쓰고 프로덕션 접근이 없다” 처럼 왜 안전한지를 함께 밝히는 형태다. 단순히 “물어보지 말고 해라” 가 아니라 판단 근거를 준다는 점이 핵심으로 보인다.

5. 남의 얘기가 아니다 — Claude Code 쪽에서 겪은 같은 함정

이 글은 Codex/AGENTS.md 기준으로 쓰였지만, Claude Code 의 CLAUDE.md 와 SKILL.md 도 구조가 같다. 설명이 컨텍스트에 상주하고, 루트 문서가 항상 적용되고, 스킬이 늘수록 서로 간섭한다.

내가 직접 겪은 사례 하나. SKILL.md 의 front matter 에서 description 값을 따옴표로 감싸지 않았는데, 한국어 설명 안에 콜론+공백이 들어 있었다. YAML 이 그걸 매핑 구분자로 읽으면서 front matter 파싱이 통째로 실패했고, 그 스킬은 목록에 아예 뜨지 않았다. 에러도 없이 조용히 죽었고, 다섯 개가 그 상태로 몇 달을 갔다.

이건 위 글의 주제와 정확히 맞물린다. 스킬의 description 은 모델이 그 스킬을 고를지 말지를 결정하는 유일한 입력이다. 길어서 잘려도 문제, 파싱이 깨져서 안 뜨는 것도 문제다. 어느 쪽이든 조용히 실패한다 — 모델이 스킬을 안 썼다는 사실 자체가 표면에 안 드러난다. 그래서 스킬을 추가·수정한 뒤에는 파싱과 목록 노출을 기계적으로 검사하는 단계를 하나 두는 게 맞다.

정리 — 무엇을 지울지의 문제다

이 글이 말하는 작업은 전부 추가가 아니라 삭제다.

영역 예전에 필요했던 것 지금 해야 할 일
스킬 설명 언제 쓸지 넓게 적어두기 발동 조건을 좁게, 짧게
스킬 본문 단계별 레시피 라우터 + 필요할 때만 읽는 하위 문서
AGENTS.md “매번 문서 3개 읽어라” 상황별로 어떤 문서를 볼지만
검증 “테스트 꼭 돌려라” 알아서 하므로 제거
경계 “반드시 먼저 물어라” 아직 유효한 경계인지 재검토
지속성 (Sol 은 알아서 길게 감) 완료 조건을 미리 정의

글의 마지막 문장이 좋다. 새 모델은 집 청소를 할 좋은 기회지만 전부 손으로 볼 필요는 없다 — 이 글에서 논의된 내용을 기준으로 모델에게 감사(audit)를 시키고, 그 시간에 예전엔 시도조차 못 했을 걸 만들라는 것이다.

다만 한 가지는 덧붙이고 싶다. 이 조언들은 “현재 모델이 그만큼 좋아졌다” 는 전제 위에 서 있다. 그 전제가 참인지는 결국 각자 리포에서 확인해야 한다. 지시문을 지우는 건 쉽지만, 지운 뒤에 무엇이 나빠졌는지 보려면 지우기 전 상태를 기록해 두는 것이 먼저다. 한 번에 다 걷어내지 말고, 지운 항목과 그 이후 관찰을 짝지어 남기는 편이 안전하다.

References

1차 · 벤더 공식 (OpenAI 가 자사 제품·모델에 대해 낸 문서)

  • Eric Provencher, Rethinking skills and prompts for GPT-6 Astra, OpenAI Developers Blog, 2026-09-11. 원문
    • 본문의 인용문(스킬 설명 대비 예시, AGENTS.md 대비 예시, 로컬 테스트 허가 문구)은 모두 이 글의 원문 표현이다.
    • ⚠️ 한계: 모델 거동에 관한 서술(“Astra 는 가장 정렬된 모델”, “Sol 보다 더 머뭇거린다” 등)은 벤더 자체 평가이며, 이 글 작성 시점에 이를 검증한 중립 제3자 벤치마크는 확인하지 못했다. 재현 조건도 문서에 제시되어 있지 않다.

필자 경험

  • 5절의 SKILL.md front matter YAML 파싱 실패 사례는 필자의 Claude Code 환경에서 직접 겪고 수정한 건이다. 일반적인 YAML 동작에 기인하며 특정 벤더 버그가 아니다.