먼저 결론: 모델을 바꿀 때 작업 규칙도 다시 평가해야 한다

더 좋은 코딩 모델을 선택했는데 작업은 오히려 길어진다. 작은 변경에도 문서를 여러 개 읽고, 이미 설명한 내용을 다시 묻고, 충분히 확인한 테스트를 반복한다. 이런 상황에서 모델 성능만 의심하면 원인을 놓칠 수 있다. 에이전트에게 주어진 지침과 도구, 그리고 언제 멈출지를 결정하는 규칙도 결과에 영향을 주기 때문이다.

이 글은 gpt-6-astra를 사용하는 바이브 코딩을 다룬다. 비교 대상은 주로 GPT-5.5와 GPT-5.6 Sol이며, 자료 확인 기준일은 2026년 9월 25일이다. OpenAI의 모델 가이드, 스킬 문서, Codex 하네스 설명과 제작 사례를 읽고 실전 운용 관점으로 정리했다.

핵심 계기는 Eric Provencher의 9월 11일자 Rethinking skills and prompts for GPT-6 Astra다. 이 글은 과거 모델에 필요했던 세밀한 절차가 Astra에는 과도한 제약이 될 수 있다고 설명한다. 짧고 명확한 스킬 호출 조건, 필요한 문서만 읽는 구조, 분명한 완료 기준을 강조한다.

이 글의 기능 설명과 행동 경향은 공식 문서에 근거한다. ‘내 해석’, ‘제안’, ‘권장’으로 표시한 부분은 자료를 종합한 평가다. 여러 모델을 같은 작업으로 직접 벤치마크한 결과는 아니며, 제공사의 설명을 독립적인 생산성 검증으로 간주하지 않는다. 아래 설정 예시는 설명용이고 실제 저장소 설정을 변경한 것은 아니다.

1. 모델·스킬·하네스부터 구분하자

하네스는 모델 응답을 받아 보여 주는 창보다 넓은 개념이다. 문맥을 유지하고, 도구 실행 결과를 되돌려 주고, 실패와 승인을 처리하면서 작업을 이어 가는 주변 시스템이다. Codex 앱·CLI·IDE는 이러한 실행 기반을 사용한다. Codex as a platform

내가 보기에는 바이브 코딩의 품질을 세 질문으로 나누는 편이 유용하다. 모델이 문제를 해결할 수 있는가? 필요한 정보와 도구를 얻을 수 있는가? 완료했음을 확인할 수 있는가? 모델이 아무리 좋아도 실행 환경에 브라우저가 없으면 화면 검증은 할 수 없고, 요구사항이 비어 있으면 그럴듯한 구현이 원하는 결과와 어긋날 수 있다.

2. 무엇이 새로워졌고, 무엇은 이미 있었나

결과 중심 프롬프트는 Astra에서 처음 나온 원칙이 아니다

GPT-5.5 가이드부터 이미 목표·성공 기준·제약을 주고 경로는 모델이 선택하게 하라는 안내가 있었다. 이전 프롬프트를 전부 이식하기보다 필요한 계약을 보존하는 작은 프롬프트로 다시 평가하라는 권고도 있었다. 따라서 ‘예전 모델에는 세부 절차, Astra에는 자율성’이라는 이분법은 과장이다. GPT-5.5 가이드

GPT-5.6에서는 Programmatic Tool Calling, API 멀티 에이전트, 명시적 프롬프트 캐싱, 턴 간 추론 상태 활용, max reasoning effort가 이미 소개됐다. 모델을 바꿨을 때 새로 발견한 기능이 모두 그 모델에서 처음 생긴 기능은 아니다. GPT-5.6 가이드

Astra에서 더 신경 써야 할 행동 변화

위 내용은 제공사가 관찰한 경향이다. 모든 작업에서 동일하게 나타난다는 보장은 없다. GPT-6 프롬프팅 가이드

내 해석은 간단하다. Astra에는 ‘최선을 다해’라는 격려보다 허용된 행동과 확인 가능한 완료 상태를 알려 주는 편이 실용적이다. 질문 횟수가 줄어드는 것 자체보다, 중요한 질문은 남고 불필요한 대기는 줄어드는 것이 목표여야 한다.

3. 스킬 설계: 적절한 순간에 필요한 지침을 불러오기

설치된 스킬은 사용하지 않아도 선택 비용이 있다

Codex는 처음에 스킬의 이름·설명·경로를 보고 사용할 스킬을 고른다. 현재 문서상 초기 목록은 문맥 창의 최대 2%를 사용하며, 크기를 알 수 없으면 8,000자를 기준으로 한다. 목록이 커지면 설명이 축약되거나 일부 항목이 생략될 수 있다. 선택된 스킬의 본문은 이후 읽는다. Build skills

이 때문에 설명의 앞부분에 핵심 사용 조건을 둬야 한다. 다음은 내가 제안하는 예시다.

# 범위가 너무 넓은 설명
description: 웹 개발, 디자인, 문서, 화면 작업에 사용한다.

# 호출 조건이 분명한 설명
description: HTML·CSS·컴포넌트의 화면 구성을 변경할 때 사용한다.

Markdown 글을 쓴다는 이유만으로 프런트엔드 전체 설계 절차가 켜지는 상황을 줄이자는 뜻이다. 스킬의 설명은 홍보 문구가 아니라 언제 호출할지를 결정하는 인터페이스라고 보는 편이 좋다.

본문은 짧은 분기 안내, 세부 내용은 필요한 파일로

공식 Astra 글은 복잡한 스킬의 진입 문서를 간결하게 만들고, 필요한 참고자료와 스크립트로 안내하는 방식을 권한다. 모든 문서를 매번 읽도록 하면 점진적 로딩의 이점이 줄어든다. 스킬 재설계 권고

블로그 작업이라면 다음 구조를 제안한다.

blog-work/
├─ SKILL.md
├─ references/
│  ├─ paper-review.md
│  ├─ image-attribution.md
│  └─ publishing.md
└─ scripts/
   └─ validate-posts

진입 문서는 논문 리뷰일 때 첫 번째 자료, 외부 이미지를 쓸 때 두 번째 자료, 게시 요청일 때 세 번째 자료를 선택하도록 안내하면 된다. 이것은 선택한 지침을 대충 읽어도 된다는 뜻이 아니다. 불필요한 지침을 선택하지 않도록 설계하자는 뜻이다.

삭제할 규칙과 남길 규칙을 구분하기

아래는 공식 체크리스트가 아니라 나의 정리 기준이다.

특히 도구 의존성은 모델 문제가 아니다. 필요한 도구를 준비하거나 스킬 작성자가 허용 가능한 대안을 정해야 한다. 실행 중인 모델에게 금지된 대안을 몰래 선택하라고 요구하는 것은 해결책이 아니다.

4. AGENTS.md에는 프로젝트의 지속적인 규칙을 남긴다

공식 커스터마이징 문서는 지속적인 프로젝트 지침, 반복 업무를 담은 스킬, 외부 접근을 제공하는 MCP를 구분한다. 린터·타입 검사·훅으로 강제할 수 있는 규칙은 실행 장치와 함께 운영할 수 있다. Customization

다음은 Jekyll 블로그에 적용할 수 있는 제안용 예시다.

# Project rules
- Jekyll, Markdown, Liquid, SCSS를 유지한다.
- 기존 permalink와 URL을 보존한다.
- 요청과 무관한 기존 글 본문을 변경하지 않는다.
- 사용자의 미커밋 변경을 보존한다.

# Verification
- 글: front matter, 내부 링크, 이미지 경로, 빌드를 확인한다.
- 화면 변경: 영향받는 페이지의 모바일·데스크톱 화면을 확인한다.
- 기존 문제와 이번 변경으로 발생한 실패를 구분한다.

# Completion
- 초안, 로컬 검증, 원격 반영, 공개 배포 상태를 구분한다.
- 검증하지 못한 항목은 성공한 것처럼 보고하지 않는다.

전역·루트·하위 디렉터리 지침도 함께 봐야 한다. Codex는 지침을 계층적으로 합치며 AGENTS.override.md와 작업 경로에 가까운 지침이 영향을 줄 수 있다. 합산 크기 제한의 기본값은 32 KiB다. 루트 파일만 고치고 다른 지침을 그대로 두면 충돌이 남을 수 있다. AGENTS.md 탐색 규칙

내 생각에 AGENTS.md는 프로젝트의 사용 설명서 전체가 아니라, 에이전트가 처음부터 알아야 할 약속과 관련 문서의 길잡이에 가까워야 한다. 낡은 규칙은 많이 기억하는 것보다 정확히 정리하는 것이 중요하다.

5. 바이브 코딩 프롬프트: 구현 방법보다 완료 상태를 구체화한다

아래는 그대로 응용할 수 있도록 작성한 예시다.

목표:
아카이브에서 제목과 태그로 글을 검색할 수 있게 구현해줘.

제약:
Jekyll과 기존 permalink를 유지해.
서버나 데이터베이스는 추가하지 마.

완료 조건:
검색어 입력, 결과 없음, 초기화가 동작해야 해.
키보드로 사용할 수 있고 모바일에서 화면이 넘치면 안 돼.
빌드와 영향받는 화면을 확인하고 이번 변경으로 생긴 문제는 고쳐줘.

진행 범위:
관련 파일 조사·편집·로컬 검증까지 진행해. 배포는 제외해.

질문:
사소한 구현 선택은 기존 코드 패턴에 맞춰 판단해.
범위나 사용자 동작을 크게 바꾸는 결정은 질문해줘.

보고:
변경 내용, 수행한 검증, 미확인 사항을 간단히 알려줘.

이 예시가 유용하다고 보는 이유는 길어서가 아니다. 검색의 기본 동작과 접근성, 호환성, 진행 범위가 드러나기 때문이다. 반대로 ‘절대 질문하지 말고 완벽하게 끝내’는 말은 중요한 제품 결정을 숨길 수 있다.

질문도 구분할 필요가 있다. 기존 패턴으로 결정할 수 있는 사소한 선택은 가정을 기록하고 진행한다. 사용자의 선호가 있으면 좋지만 독립 작업은 가능한 경우에는 가능한 작업을 먼저 한다. 비용·공개 범위·데이터 삭제·아키텍처가 달라지는 결정은 그 전에 확인한다. 이것은 나의 운영 제안이며, 조직 정책이나 필수 승인 절차를 무효화하지 않는다.

화면 작업은 원하는 경험과 참고자료를 전달한다

공식 Astra 게임 제작 사례는 원하는 플레이 경험과 제약을 설명하고, 시각적 참고자료를 만든 뒤 구조를 발전시킨 과정을 소개한다. 자동 테스트와 실제 경험에 대한 검토를 함께 사용했다. 이는 제작 사례이지 이전 모델보다 생산성이 얼마나 개선됐는지를 측정한 통제 실험은 아니다. Building games with Astra

블로그라면 ‘패딩을 12px로 해’에 앞서 ‘모바일에서 여러 제목을 빠르게 훑을 수 있어야 하고, 이미지보다 글 탐색이 우선’이라고 설명할 수 있다. 내 관점에서는 사람이 모든 CSS 값을 대신 정하기보다 좋은 결과를 판단하는 기준을 제공하는 것이 더 중요한 역할이다.

6. 하네스 선택: 앱 사용자와 API 개발자의 문제가 다르다

Codex SDK와 app-server의 통합 범위는 하네스 설명에, 관리형 Agents API와 직접 루프를 구성하는 Responses API의 구분은 Agents 가이드에 정리돼 있다. Agents API와 Agents SDK도 동일한 이름의 제품이 아니므로 구분해야 한다.

내 추천은 단순하다. 개인 프로젝트에서 Codex 앱을 잘 쓰려는 단계라면 하네스를 새로 만드는 것보다, 빌드·브라우저·테스트 도구가 실제로 작동하고 필요한 권한이 정리돼 있는지부터 확인하겠다. 사용자 인터페이스나 실행 인프라를 직접 통제해야 할 이유가 있을 때 커스텀 하네스를 검토하는 편이 낫다.

7. GPT-6 기능을 활용하는 실행 설계

비동기 도구: 기다리는 동안 독립 작업을 진행한다

Async tool calling은 함수·커스텀 도구를 호출한 뒤 결과가 오기 전에도 모델이 다른 작업을 이어 가게 한다. 실행은 애플리케이션이 담당하며 결과를 원래 call_id에 연결해야 한다. 응답 생성 자체를 비동기로 처리하는 background mode와는 다르다. Async tool calling

예를 들어 긴 검증 작업을 시작하고 그동안 변경 설명을 정리할 수 있다. 단, 검증 성공을 전제로 하는 최종 보고는 결과가 온 뒤 해야 한다. 직접 하네스를 만든다면 미완료 작업, 타임아웃, 취소, 늦게 도착하는 결과까지 처리해야 한다. 비동기는 시간 절약 수단이지 의존관계를 없애는 기능이 아니다.

작업 중 방향 수정: 이전 행동을 되돌리는 기능은 아니다

GPT-6 Responses API의 WebSocket 기반 mid-turn steering은 응답 도중 요구사항을 추가하거나 바꾸는 기능이다. 문서상 GPT-5.6 이하에서는 지원되지 않는다. 다만 이미 수행한 행동이나 시작한 도구를 취소하지 않는다. Mid-turn steering

나는 ‘그거 말고 다르게’보다는 ‘배치는 유지하고 색상만 절제해. 기능 추가는 하지 마’처럼 유지할 부분과 바꿀 부분을 구체적으로 전달하겠다. 특히 배포 같은 외부 영향이 있는 작업을 사후 메시지로 되돌릴 수 있다고 기대해서는 안 된다.

도구 탐색과 프로그램 호출: 문맥에 모든 결과를 넣지 않는다

Tool search는 필요한 도구 정의를 동적으로 로드한다. 함수·서버의 설명은 여전히 검색에 중요하다. GPT-5.4 이후 지원되는 기능으로 Astra만의 신규 기능은 아니다. Tool search

Programmatic Tool Calling은 JavaScript로 호출·반복·필터링·집계를 묶고 필요한 결과만 반환하는 데 적합하다. 매 결과마다 새로운 모델 판단이 필요하거나 승인·인용·네이티브 산출물 보존이 중요한 작업은 직접 호출이 적합할 수 있다. Programmatic Tool Calling

내 기준으로 수백 개 상태에서 실패 항목을 추리는 작업은 프로그램화하기 좋다. 반면 논문마다 실험의 의미를 읽고 비판하는 작업은 단순 반복 처리와 다르다. ‘도구를 적게 호출했다’보다 판단이 필요한 곳에 판단을 남겼는가가 중요하다.

8. 긴 작업과 병렬화: 주의력을 어디에 쓸 것인가

Compaction은 긴 대화에서 다음 작업에 필요한 상태를 더 작은 문맥으로 이어 가는 기능이다. 서버 측 임계치 기반 처리와 별도 compact 기능이 있으며, 반환되는 항목은 사람이 읽는 일반 요약문과 다르다. Compaction

그와 별개로 사람이 이해할 수 있는 작업 상태도 유용하다. 나는 장기 작업에서 목표·제외 범위·결정 사항·변경 파일·검증 결과·남은 문제를 짧게 남기겠다. 도구 로그 전체를 대화에 계속 쌓아 두는 것과 필요한 상태를 보존하는 것은 다르다.

서브에이전트는 독립 조사와 탐색, 로그 분석에 도움이 된다. 현재 Codex 문서는 직접 요청이나 적용 지침에 따른 위임을 설명한다. 토큰 소비가 늘 수 있고 병렬 편집은 충돌을 일으킬 수 있다. Subagents

내 추천은 읽기 중심의 독립 작업부터 나누는 것이다. 예를 들어 한 에이전트는 논문 실험 조건, 다른 에이전트는 구현의 재현성, 또 다른 에이전트는 평가 한계를 조사한다. 메인 에이전트는 근거를 대조한다. 같은 파일을 여러 에이전트가 동시에 고치는 방식은 소유권과 통합 책임을 정한 뒤 사용해야 한다. 작은 문구 수정에 여러 검토자를 붙이는 것이 항상 더 좋은 것은 아니다.

9. 비용과 API 호환성: 모델 이름만 바꾸면 끝나지 않는다

프롬프트 캐시는 동일한 앞부분을 재사용한다. 도구 정의와 순서, 지침, 설정도 캐시 일치에 영향을 준다. GPT-5.6 이후에는 명시적 경계와 prompt_cache_options.ttl을 사용하며 현재 TTL 값은 30m이다. 캐시 쓰기는 일반 입력의 1.25배, 읽기는 0.1배 요율로 설명된다. Prompt caching

따라서 안정적인 지침을 앞에 두고 변동 데이터를 뒤에 두는 것이 합리적이다. 다만 캐시를 유지하려고 무관한 문맥까지 보존할 필요는 없다. 내 평가 지표는 토큰 단가가 아니라 실패와 재작업을 포함한 성공 작업당 총비용이다.

직접 API 하네스를 바꾸는 경우에는 다음도 확인해야 한다.

모델 이행 시 가능한 경우 기존 reasoning 수준에서 비교를 시작하는 것이 공식 안내다. 모든 작업을 무조건 최고 수준으로 올려야 한다는 의미는 아니다. GPT-6 이행 가이드

공개 API 모델 페이지는 Astra의 reasoning 값으로 low, medium, high, xhigh, max를 기재한다. 앱의 지능 수준이나 실행 모드를 그대로 API 인자로 간주해서는 안 된다. Astra 모델 사양 실제 구현에서는 중간 진행 메시지와 최종 응답, 도구 결과의 재전달, 기능 조합도 함께 점검해야 한다. API 배포 체크리스트

10. 자율성과 권한을 혼동하지 않기

샌드박스는 기술적으로 할 수 있는 범위이고, 승인 정책은 행동 전에 사용자에게 물어야 하는 조건이다. 둘은 함께 작동하지만 같은 설정은 아니다. Agent approvals & security

내 생각에 가장 위험한 오해는 ‘Astra가 더 신중하니 권한 제한을 없애도 된다’는 결론이다. 제공사가 설명하는 행동 경향은 보안 경계를 대체하지 않는다. 반대로 모든 로컬 검증에 승인을 요구하면 작업의 흐름이 끊긴다. 어떤 데이터와 환경에 접근하는지, 어떤 외부 효과가 생기는지에 따라 경계를 정해야 한다.

읽기·로컬 편집·검증·커밋·push·배포를 하나의 ‘알아서 해’로 뭉개지 않는 것이 좋다. 이미 승인된 범위를 명확히 기록하면 반복 질문을 줄일 수 있지만, 조직 정책과 도구의 필수 승인 절차를 프롬프트로 무효화할 수는 없다.

11. 내 평가: 절차를 줄인 만큼 검증 기준은 선명해야 한다

스킬의 가치는 길이가 아니라 빠지면 잃는 지식에 있다

스킬이 없어도 모델이 자연스럽게 하는 일반 절차를 길게 반복한다면 유지 비용을 의심해 볼 만하다. 반면 회사의 데이터 정의, 프로젝트의 함정, 출처 검증 기준, 배포 순서처럼 모델이 알 수 없는 지식은 가치가 높다. 나는 스킬마다 ‘이 지침이 없으면 어떤 구체적인 오류가 늘어나는가?’를 묻겠다.

짧은 스킬이 항상 좋은 것도 아니다. 위험한 마이그레이션이나 규정 준수 업무는 구체적인 절차가 필요하다. 목표는 글자 수 감소가 아니라 관련 지식을 필요한 시점에 정확히 제공하는 것이다.

바이브 코딩이 쉬워질수록 사람은 합격 기준을 더 잘 정해야 한다

코드 작성이 쉬워지면 실행되는 결과물을 빨리 얻을 수 있다. 그러나 요구사항이 충족됐는지, 기존 사용자가 불편해지지 않았는지, 비용이 감당 가능한지는 별도의 질문이다. 나는 사람의 역할이 사라지기보다 코드 작성의 세부 지시에서 목표·제약·품질 판단으로 이동한다고 본다.

AutoDev 리뷰에서 다룬 실행 피드백도 같은 맥락이다. 테스트를 돌리는 루프는 중요하지만, 테스트가 잘못된 목표를 확인한다면 초록색 결과만으로 충분하지 않다. 더 많은 에이전트나 더 긴 추론이 잘못된 합격 기준을 자동으로 바로잡아 주지는 않는다.

제공사의 가이드도 출발 가설로 평가해야 한다

이 글의 공식 자료는 기능과 권장 방식을 파악하는 데 유용하지만 독립적인 비교 실험은 아니다. Astra가 특정 환경에서 더 자주 멈춘다면 모델 성향, 지침 충돌, 도구 부재, 실제 권한 부족을 나눠 봐야 한다. 관찰 하나를 모델 전체의 성격으로 일반화하는 것도, 모든 문제를 프롬프트 탓으로 돌리는 것도 피하고 싶다.

12. 이전 설정보다 나아졌는지 확인하는 방법

공식 스킬 평가 글은 산출물뿐 아니라 스킬 호출, 필요한 절차, 스타일, 불필요한 실행과 토큰 소비를 함께 확인한다. Testing Agent Skills Systematically with Evals

내가 제안하는 비교는 다음과 같다. 아래는 실험 설계안이며 측정 결과가 아니다.

같은 저장소 상태와 도구 환경에서 대표 작업을 반복한다. 문구 수정, 이미지 경로 오류, 모바일 레이아웃, 테스트가 있는 버그, 모호한 요구사항, 승인된 배포, 도구 부재, 미커밋 변경이 있는 상황 등을 포함한다. 작업 순서나 이전 실행의 파일 변경이 다음 조건에 영향을 주지 않도록 분리해야 한다.

측정할 것은 완료율, 실제 결함, 추가 개입 횟수, 불필요한 승인, 오작동한 스킬 호출, 시간과 비용, 무관한 변경, 거짓 완료 보고다. 모델 출력의 변동성을 고려해 여러 번 실행하고 사람이 결과를 확인한다. ‘느낌상 더 좋다’는 판단을 작업별 검증으로 바꾸자는 취지다. 평가 설계 원칙

마무리: 먼저 정리하고, 그다음 병렬화하자

내가 Astra 환경을 손본다면 먼저 겹치는 스킬 호출 조건과 오래된 승인 규칙을 확인하겠다. 다음으로 프로젝트의 불변 조건과 완료 기준을 정리하고, 빌드·브라우저·테스트가 실제로 작동하도록 준비하겠다. 그 뒤에 독립 작업의 위임, 비동기 도구, 캐시를 조정하겠다.

Astra를 잘 쓰는 환경은 지침이 가장 많은 환경이 아니라, 필요한 지식과 권한이 분명하고 결과를 확인할 수 있는 환경이라고 생각한다. 모델을 업그레이드할 때마다 규칙을 더 붙이기 전에, 기존 규칙이 지금도 어떤 문제를 해결하고 있는지부터 물어보자.

더 읽을 자료

• Astra 스킬·프롬프트 재설계: 이 글의 출발점. 기존 지침을 다시 평가할 이유.
• GPT-6 모델 가이드: 행동 경향과 API 이행 조건. 최신 모델을 따라 내용이 바뀔 수 있다.
• Build skills, AGENTS.md: 지침의 작성·발견·로딩 방식.
• Codex 하네스, Agents: 실행 계층과 책임 범위.
• 비동기 도구, 작업 중 방향 수정, 프롬프트 캐시: 직접 하네스를 구현할 때 참고할 문서.
• 스킬 평가: 설정 변경의 효과를 반복 측정하는 방법.