[$blog-batch-generator](~/.codex/skills/blog-batch-generator/SKILL.md) AI 도구, 초보자, 5개 포스트 만들어줘
[$blog-batch-generator](~/.codex/skills/blog-batch-generator/SKILL.md) AI 도구, 중급자, 5개 포스트 만들어줘
[$blog-batch-generator](~/.codex/skills/blog-batch-generator/SKILL.md) AI 도구, 고급자, 5개 포스트 만들어줘
...
어제 밤에 Codex를 켰다. 최근 GPT-5.6-sol 모델이 올라와서 Codex 기본 모델로 설정해둔 상태다. 화면에는 12개 줄이 나열되어 있었다. 12개 줄을 복사해서 붙여넣고, 각각이 끝나길 기다렸다가, 다음 단계를 또 실행해야 한다. 손으로 하면 30분은 걸릴 일이다. 그런데 GPT-5.6 가이드를 읽고 나서 든 생각은, 이걸 명령어 하나로 루프로 만들 수 있겠다는 거였다.
GPT-5.6 가이드에서 가져온 두 개념
OpenAI가 공개한 GPT-5.6 모델 가이드를 study-clipper로 정리하면서 두 가지가 눈에 박혔다. 지금 Codex에서 GPT-5.6-sol을 쓰고 있으니까 가이드가 더 직접적으로 와닿았다. 첫째는 "자율성 경계(Autonomy Boundaries)"다. 모델이 스스로 판단해서 실행할 수 있는 영역과, 사람이 승인해야 하는 영역을 명령어에 명시적으로 구분하라는 가이드다. 로컬 파일 생성이나 검증 같은 안전한 작업은 모델이 알아서 하게 두고, 외부 전송이나 기존 파일 덮어쓰기 같은 위험한 행동은 승인을 요구하게 만드는 방식이다.
둘째는 "Leaner Prompts"다. 반복적인 지시어와 불필요한 예시를 제거하면 성능이 1015% 향상되고 토큰 사용량이 4166% 줄어든다는 내부 평가 결과가 있었다. 핵심은 "각 명령은 한 번만 기술하라"는 것이다. 같은 지시를 세 번 반복하는 건 모델에게 혼란을 줄 뿐이다.
이 두 개념을 Codex에서 배치 생성 파이프라인을 설계하는 데 적용해봤다. 내가 하려는 작업은 단순하다. 12개 조건(주제, 난이도, 대상 독자) 각각에 대해 첫 번째 스킬을 실행하고, 결과가 나오면 즉시 두 번째 스킬을 실행하는 것. 첫 번째 결과물은 모든 조건이 공통으로 사용하니까 한 번만 지정하면 된다.
프롬프트로 루프를 짠다는 것
처음에는 스킬 파일을 하나 만들어야 한다고 생각했다. batch-orchestrator라는 이름으로 SKILL.md를 작성하고, 거기에 12개 조건 목록과 실행 순서를 정의하는 식이었다. 그런데 내가 내린 판단은 달랐다. 스킬 파일 대신 명령어를 직접 주는 쪽이 더 가볍다. 파일을 만들고 경로에 넣고 Codex가 로드하게 하는 건 구조가 무거운 편이다. 반면 명령어는 그 자리에서 바로 실행된다.
GPT-5.6 가이드의 leaner prompts 원칙을 적용해서, 명령어에서 모든 중복을 제거했다. 12개 조건은 번호가 매겨진 목록 하나로 정의했다. 각 조건에 대한 실행 명령은 템플릿 하나로 통일하고, 변수만 주제, 난이도, 독자층으로 교체하는 구조로 만들었다. "각 항목에 대해 다음을 실행하라"는 지시는 한 번만 기술했다. 이전 버전에서는 "첫 번째 스킬을 실행하고 결과를 확인하고 두 번째 스킬을 실행하라"는 설명을 12번 반복했는데, 그럴 필요가 없었다.
자율성 경계도 명령 안에 박았다. "로컬 파일 생성은 승인 없이 자동 실행, 기존 파일 덮어쓰기 시에만 확인 요청"이라는 두 줄로. 이 한 줄이 모델이 각 단계마다 "이제 뭐 하죠?"라고 물어오는 걸 차단해준다. 모델이 안전한 작업은 알아서 진행하고, 정말 위험한 행동 앞에서만 멈춘다.
이건 처음 시도하는 작업이다. 아직 Codex에 이 프롬프트를 넣고 돌려보지 않았다. 그래서 예상과 다르게 작동할 부분이 있을 수 있다. 예를 들어 12개 조건 중 7번째에서 실패하면 어떻게 할 것인가. AI가 스스로 복구하기는 어려울 것이다. 그래서 재시도 루프를 2회 정도 넣기로 했다. 1차 실패 시 동일 조건으로 재실행, 2차 실패 시에도 재시도. 3회째 실패하면 그때는 사람에게 보고한다. 이 구조를 명령 안에 박아두면, 모델이 실패를 만났을 때 멈추지 않고 정의된 횟수만큼 스스로 재시도한다. AI의 한계를 인정하되, 그 한계 안에서 최대한 자율성을 주는 설계다.
결과적으로 명령은 30줄 남짓으로 줄었다. 12개 조건 목록, 공통 설정 두 줄, 실행 루프 지시 세 줄, 경계 정의 두 줄. 스킬 파일로 만들었으면 SKILL.md만 수십 줄이었을 텐데, 명령어가 훨씬 가볍다. GPT-5.6 가이드가 말하는 대로, 반복 지시를 제거하니 의도 자체가 더 명확해졌다. 모델이 헷갈릴 여지가 줄어든 느낌이다.
스킬을 계속 만들면 자율성이 쌓인다
내가 이 작업을 하면서 든 생각이 있다. "스킬을 계속 만들어서 자율성을 주면, 내가 생각하는 반복적인 일이나 검증 같은 건 정말 쉽게 될 듯." 이 말이 계속 머물렀다. 지금은 두 개의 스킬이 있고, 그 사이를 잇는 루프 명령을 하나 짰다. 다음에는 이 루프 자체를 스킬로 만들면, 호출 한 줄로 12개 조건 실행이 끝난다.
지금 당장 이 패턴을 적용할 다른 작업은 없다. 그런데 이 구조 자체가 재사용 가능하다는 게 중요하다. "목록 정의 → 각 항목에 대해 실행 → 결과 확인 → 다음 단계 실행 → 실패 시 2회 재시도"라는 패턴. 이게 한 번 만들어지면, 다음에 비슷한 반복 작업이 생겼을 때 목록만 바꾸면 된다. 뼈대는 그대로 재사용된다. 스킬을 하나씩 만들 때마다 자율성이 한 층씩 쌓이는 구조다. 지금은 두 스킬 사이를 잇는 루프를 짰지만, 다음에는 다른 스킬 조합에 같은 뼈대를 쓸 수 있다.
GPT-5.6 가이드에서 "intent understanding"라는 항목을 봤다. 모델이 사용자의 근본 목표를 더 잘 추론해서, 모든 단계를 처방할 필요가 줄어든다는 내용이었다. 내가 12개 줄을 복사해서 붙여넣던 시점에서는 내가 모든 단계를 처방하고 있었다. "이 조건 실행, 저 조건 실행, 그 다음 이거 실행." 명령어로 루프를 짜고 나니, 처방이 아니라 목표와 제약만 주면 모델이 나머지를 채우는 구조가 됐다. "12개 조건을 순차 실행하라, 첫 번째 끝나면 두 번째 즉시 실행하라, 로컬 파일은 자동 생성하라." 이게 전부다.
이게 내가 말한 "자율성"의 의미인 것 같다. 모델이 알아서 하는 게 아니라, 자율성의 경계를 명확히 정의해주면 모델이 그 안에서 최대한 움직인다. 반복적인 일과 검증을 사람이 하던 것을, 경계만 그어주면 모델이 가져간다. 스킬을 하나씩 만들 때마다 그 경계가 넓어지고, 내가 손으로 해야 하는 일이 줄어든다. 블로그 콘텐츠 생성에서 12개 조건을 손으로 실행하던 게, 프롬프트 하나로 자동화됐다. 다음에는 이 프롬프트를 스킬로 만들면, 호출 한 줄로 끝난다. 그다음에는 그 스킬들을 조합하는 메타 스킬을 만들 수도 있다. 각 단계에서 자율성이 한 층씩 쌓이는 구조다.
GPT-5.6 가이드를 읽기 전에는 "명령어로 루프를 짠다"는 게 추상적으로 느껴졌다. 가이드를 읽고 나니 구체적인 설계 원칙이 보였다. 경계를 그어라. 지시를 한 번만 써라. 모델이 목표를 추론하게 둬라. 이 세 가지를 적용하니, 30줄짜리 루프가 완성됐다. GPT-5.6-sol이 실제로 이 루프를 어떻게 실행할지는 아직 검증 안 됐지만, 구조는 명확하다. 다음 스텝은 이 명령을 Codex에 넣고 돌려보는 거다. 최신 모델에게 내가 직접 설계한 루프를 맡기는 첫 실험이 된다.