모델이 바뀌면, 쌓아둔 스킬과 지시문도 다시 읽어야 한다

Eric Provencher는 GPT-6 Astra를 쓰면서 기존 스킬과 프롬프트를 다시 살피자고 제안했다. 지난 모델을 원하는 방향으로 움직이려고 덧붙인 지시가 새 모델에서도 도움이 되는지 확인하자는 글이다. 원문은 스킬, AGENTS.md, 작업의 경계와 완료 조건을 차례로 다룬다.

스킬 설명은 언제 꺼내 읽을지 알려주는 문장이다

Eric은 많은 스킬을 내려받아 두는 습관부터 지적한다. 스킬 이름과 설명은 모델이 어떤 스킬을 쓸지 판단하는 맥락에 들어간다. 설명이 길고 대상이 넓으면 선택을 돕기보다 서로 경쟁하거나 충돌할 수 있다는 것이다.

원문이 든 차이는 데이터베이스와 관련된 모든 작업에 개입하는 설명과, 마이그레이션에만 적용되는 설명 사이에 있다. 두 설명이 같은 자료를 가리켜도 호출 범위가 다르다. Eric은 필요한 상황을 분명하게 표현하면서 설명을 짧게 유지하라고 권한다.

이어서 필요한 내용을 단계적으로 읽게 하는 구조를 제안한다. 여러 작업을 다루는 스킬이라면 첫 문서가 관련 자료와 스크립트로 안내하고, 세부 절차는 해당 작업에서 읽도록 두는 방식이다. 지금 필요하지 않은 내용을 처음부터 모두 읽는 비용을 줄이려는 취지다.

저장소의 상시 지시에는 매번 비용이 붙는다

AGENTS.md에 대한 질문은 적용 범위다. 오타 하나를 고칠 때도 전체 저장소 지도와 문서 묶음을 읽도록 했다면, 그 요구가 지금 작업에 필요한지 살펴야 한다는 설명이다. 관련 문서의 위치를 알려주는 일은 유용할 수 있지만, 모든 수정에 같은 준비 절차를 붙이는 일과는 다르다.

Eric은 이전 모델에서 효과가 있던 자세한 절차가 Astra에는 과한 제약이 될 수 있다고 본다. 또 저장소의 스킬을 다른 모델도 읽는다는 점을 짚는다. 특정 모델에 맞춘 처방을 팀의 공통 규칙으로 남길 때는 누가 그 지시를 사용할지 고려해야 한다는 것이다.

모델별 성향에 관한 이 설명은 작성자의 관찰이다. 이 글에서 모델을 비교 실험해 일반적인 우열이나 모든 작업에서의 행동을 확인한 것은 아니다. 따라서 원문을 모든 스킬을 삭제하라는 지침으로 넓혀 읽을 이유도 없다.

멈출 곳과 끝낼 곳을 함께 쓴다

원문의 후반부는 승인 경계와 지속성으로 넘어간다. 이전의 무단 실행을 막으려고 만든 강한 정지 규칙이, 사용자가 맡기려던 작업까지 멈추게 할 수 있다는 문제다. Eric은 안전한 작업의 구체적인 범위를 적는 예로, 프로덕션에 접근하지 않는 임시 데이터 기반 로컬 테스트를 든다.

완료 조건도 같은 방식으로 구체화한다. 구현만 필요한지, 실행해서 결과를 확인하고 실패를 고치는 일까지 포함하는지 요청에 담으라는 설명이다. 첫 구현 뒤 반드시 검토를 받으라고 적으면 모델이 그 지점에서 멈추는 것도 자연스럽다.

ZDL이 이 글에서 가져오는 질문은 지시마다 붙은 이유가 아직 유효한가이다. 반복 실수를 막은 규칙과 특정 모델의 약점을 보완한 지시는 수명이 다를 수 있다. 어떤 문제를 막으려고 추가했는지 모르면, 규칙을 유지할지 줄일지도 판단하기 어렵다.

Eric의 글은 새 모델을 계기로 지시문을 검토하자는 제안이다. 실제 작업 환경의 규칙은 이번 글을 쓰며 변경하지 않았다. 검토할 대상은 스킬의 개수만이 아니라 호출 범위, 상시 적용 비용, 그리고 작업이 끝나는 지점이다.

이 글을 읽고 나면, 모델을 바꾼 뒤 스킬 설명과 상시 지시문에서 무엇을 먼저 걷어낼지 정하게 된다.

이메일로 다음 글 받기