TL;DR

  • GPT-6 Astra의 향상된 역량으로 기존의 세밀한 핸드홀딩과 스캐폴딩이 덜 필요해졌으므로, 스킬·AGENTS.md·작업 프롬프트를 재검토해야 함.
  • 스킬 설명은 적용 시점을 명확히 하면서 최대한 짧게 작성하고, 여러 워크플로가 있으면 최소한의 라우터 문서와 지원 문서·스크립트로 나누는 방식이 적합함.
  • AGENTS.md는 작업에 필요한 문서만 상황에 맞게 읽도록 안내하고, Astra가 자체적으로 수행하는 테스트·검증을 불필요하게 반복 지시하지 않는 구성이 바람직함.
  • Astra의 판단력과 안전성에 맞춰 과도하게 강한 의사결정 경계를 완화하되, 안전한 워크플로에는 계속 진행할 수 있는 명시적 권한을 부여해야 함.
  • 작업 완료 조건과 탐색 범위를 프롬프트에 명시해 Astra가 첫 구현 단계에서 멈추지 않고 실행·검사·수정까지 이어가도록 해야 함.

더 나은 스킬

  • 코딩 에이전트가 크게 발전하면서 모범 사례도 빠르게 바뀌고 있으며, 더 강력한 모델에서는 과거에 많은 수작업 안내와 스캐폴딩이 필요했던 작업이 더 이상 그렇지 않은 경우가 많음.
  • 지난 1년 동안 Codex 같은 에이전트를 프로젝트에 사용했다면, 좋은 결과를 유도하기 위해 많은 지침이 누적됐을 가능성이 큼. 릴리스가 나올 때마다 기존 가정을 재검토할 필요가 있었으며, GPT-6 Astra에서는 그 중요성이 더욱 커짐.
  • 지침은 다음과 같은 형태로 모델의 작업 방식을 형성함.
  • 스킬
  • AGENTS.md
  • 작업 프롬프트
  • 스킬은 일반적으로 특정 워크플로 안내나 특정 앱 사용법을 담은 마크다운(Markdown) 파일 형태의 프롬프트이며, 리소스와 번들 스크립트를 함께 패키징할 수도 있음.
  • 프로젝트에 많은 스킬을 패키징하는 방식이 기본값이 됐지만, 각 스킬의 이름과 설명은 모델이 언제 사용할지 판단할 수 있도록 컨텍스트에 로드됨.
  • 설명이 지나치게 길거나 스킬 수가 너무 많으면 Codex가 컨텍스트에 맞추기 위해 설명을 줄이기 시작함. 그 결과 모델이 각 설명의 내용을 덜 보게 되고, 적절한 스킬을 고르기 어려워짐.
  • 스킬 설명끼리 서로 모순되거나 사용 시점을 과도하게 강조하면, 작업에 실제로 도움이 되지 않는 지침까지 모델이 불러오는 문제가 생김.
  • 스킬을 만드는 일반적인 워크플로는 $skill-creator 스킬을 사용하는 방식이며, 이 스킬의 지침은 실제 사용에서 관찰된 여러 실패 유형을 줄이도록 최근 업데이트됨.
  • 스킬 설명은 모델이 언제 사용해야 하는지 명확히 하면서 가능한 한 짧게 작성해야 함.
  • 부적절한 예: Postgres 스키마 마이그레이션을 생성하고 검증함. 데이터베이스, 쿼리, 모델 또는 영속성을 다룰 때 사용함.
  • 적절한 예: Postgres 스키마 마이그레이션을 생성하고 검증함. 마이그레이션을 추가·변경하거나 롤아웃을 검토할 때 사용함.
  • 첫 번째 설명은 데이터베이스와 관련된 일을 조금이라도 할 때마다 스킬을 사용하도록 모델을 유도할 수 있지만, 두 번째 설명은 마이그레이션을 처리해야 할 때로 적용 범위를 좁힘.
  • 유용한 스킬의 핵심 지표 중 하나는 점진적 공개(progressive disclosure)임.
  • 스킬을 읽는 행위는 컨텍스트를 차지해 컨텍스트 압축에 가까워지게 하고, 현재 작업에 적용되지 않는 지침을 주입할 수 있음.
  • 여러 워크플로를 가진 스킬은 루트 문서를 최소한의 라우터로 만들고, 지원 문서와 스크립트를 가리키도록 구성하는 편이 적합함.
  • 모델이 어디를 찾아야 하는지 판단할 만큼만 안내하고, 당장 필요하지 않은 내용을 읽도록 강제하지 않는 방식임.
  • 많은 스킬이 정교한 일정표나 조리법처럼 작성됐지만, 모델이 뉘앙스와 모호성을 이해하는 능력이 크게 향상돼 지나치게 구체적인 지침이 오히려 결과를 방해할 수 있음.
  • 저장소 스킬은 다른 기여자의 에이전트도 안내하며, 이들은 서로 다른 모델을 사용할 수 있음. Sol이나 Luna에 도움이 되는 지침이 GPT-6 Astra를 과도하게 제한할 수 있으므로, 남겨둘 지침을 어떤 모델이 사용할지 고려해야 함.

최신 상태의 AGENTS.md

  • AGENTS.md는 모델이 저장소에서 작업할 때마다 적용되므로, 각 지침이 여전히 필요한지 자주 재검토해야 함.
  • 모든 수정 전에 여러 문서나 전체 저장소 지도를 읽도록 요구하는 방식은 오타 수정 같은 작업에는 과도함. GPT-6 Astra는 매번 프로젝트 전체를 검토하도록 압박하지 않아도 필요한 내용을 스스로 판단할 수 있음.
  • 문서 읽기 지침은 작업에 필요한 범위에 맞춰 작성해야 함.
  • 부적절한 예: 모든 수정 전에 architecture.md, database.md, deployment.md를 읽음.
  • 적절한 예: 서비스 경계를 확인할 때 architecture.md, 스키마 변경 때 database.md, 배포 준비 때 deployment.md를 사용함.
  • 모든 수정 전에 파일을 읽도록 프롬프트하면 컨텍스트를 소모하고 작업을 느리게 만들 수 있음. 다만 문서를 상황에 맞게 가리키는 방식은 여전히 유용하며, 문서 자체도 최신 상태로 유지해야 함.
  • 이전 모델은 테스트를 실행하고 작업을 확인하도록 독려할 필요가 있었지만, GPT-6 Astra는 이를 스스로 수행하므로 같은 지침을 반복하면 불필요한 테스트가 발생할 수 있음.
  • Astra는 철저하지만 작업을 어디까지 이어갈지에 대해서는 더 조심스러울 수 있음. 안전하다는 사실을 알고 있는 특정 워크플로에는 AGENTS.md를 통해 계속 진행할 권한을 부여할 수 있음.
  • 예시로 로컬 테스트가 폐기 가능한 픽스처를 사용하고 프로덕션에 접근하지 않는다면, 매 단계 승인을 요청하지 말고 테스트를 실행하며 요청된 변경으로 발생한 실패를 수정한 뒤 영향을 받은 테스트를 다시 실행하도록 지시할 수 있음.

의사결정 경계

  • 작업 경계를 설명하는 방식을 주의 깊게 검토해야 함.
  • 이전 모델이 승인 없이 작업을 대신 수행했다면 먼저 물어보도록 강한 표현을 추가했을 수 있으며, 이는 당시에는 유용했을 수 있음.
  • GPT-6 Astra는 정렬 수준이 가장 높은 모델로서 안전하다고 판단하지 않은 작업을 수행하지 않는 경향이 있으므로, 그 판단력을 전제로 다뤄야 함.
  • 다른 모델이 과도하게 진행하는 것을 막기 위해 강한 경계를 설정했지만 이제 GPT-6 Astra로 전환한다면 해당 표현을 업데이트할 필요가 있음. Astra가 이를 지나치게 엄격하게 받아들여 실제로는 계속 진행해도 되는 작업을 중단할 수 있기 때문임.

지속성

  • GPT-5.6 Sol이 요청을 받고 오랫동안 계속 작업하는 방식에 익숙하다면, GPT-6 Astra는 언제 멈출지 더 신중하게 판단하는 모델로 느껴질 수 있음.
  • Astra는 첫 구현에 도달한 뒤에도 작업이 남아 있는 상태에서 검토를 요청하며 돌아올 수 있음.
  • 따라서 시작 전에 완료 조건을 정의하는 방식이 유용함. 완전히 끝날 때까지 계속하도록 Astra를 독려해야 할 수 있음.
  • 구현을 실행하고, 결과를 검사하고, 실패한 부분을 수정하는 일이 작업에 포함된다면 그 범위를 요청문에 명시해야 함.
  • 첫 구현 뒤 검토를 위해 멈추라는 요구는 모델을 더 이른 종료 지점으로 끌어가므로, 실제로 그 시점에 결정이 필요한지 확인해야 함.
  • 첫 번째 시도 이후에도 계속 탐색하기를 원한다면 무엇을 탐색하고 어디에서 멈출지 구체적으로 밝혀야 함.
  • 새 모델의 등장은 기존 지침을 정리할 기회이며, 이 글에서 논의한 기준에 따라 GPT-6 Astra에 감사를 맡긴 뒤 이전에는 시도하지 못했을 작업을 구축하는 방식이 가능함.