Forge Fate
한국어
AI

사용법을 익히고 작업 환경을 정비하는 데 얼마나 투자할까?

약 8분

지난 편에서는 실제 diff나 테스트 실행 결과가 없는 목록 조회 사례를 통해, 변경을 판단하려면 계약과 실행 근거를 어떻게 확인해야 하는지 살폈다. 비슷한 작업이 다시 왔을 때 실행 위치와 확인할 계약을 매번 처음부터 설명해야 한다면, 이제 질문은 달라진다. 그 설명 중 무엇을 다음 작업을 위해 남겨 둘까?

OpenAI는 GPT-6 Astra를 다룬 글에서 작업 프롬프트, AGENTS.md, Skill에 쌓인 지침을 다시 살피라고 권한다. 관련 없는 문서를 매번 읽게 하거나 범위가 넓은 Skill을 적용하게 하는 설정이 오히려 작업을 무겁게 만들 수 있다는 취지다. 이는 해당 모델을 중심으로 한 제품별 조언이지, 설정을 줄이면 모든 프로젝트에서 성과가 좋아진다는 보장은 아니다.[S1]

아래의 목록 조회 개선은 정보를 어디에 둘지 설명하기 위한 가상 사례다. 실제 저장소의 설정이나 실행 결과를 전제로 하지 않는다. 이 사례를 통해 사용법을 더 익히는 데 쓸 시간과, 지금 쓰는 프롬프트를 그대로 유지할 이유를 함께 따져 보자.

같은 작업에 관한 정보도 둘 자리는 다르다

이번 목표가 “목록 조회 경로를 정리하되 정렬, 페이지 동작, 응답 호환 조건은 유지한다”라고 하자. 작업을 맡길 때 필요한 문장과 다음 작업에도 유효한 사실은 수명이 다르다. 반복해서 실행할 절차와 코드가 판정해야 할 계약도 서로 다른 일을 한다.

다음 배치는 공식 자료에서 가져온 필수 파일 구조가 아니라, 이 사례에 대한 필자의 설계 제안이다. OpenAI Cookbook은 AGENTS.md를 Codex가 인식하는 선택적 저장소 지침으로 소개하며, 지속적인 지침과 작업별 목표·맥락·검증 기록을 구분하는 한 사례를 보여 준다.[S3]

둘 자리목록 조회 개선에서 맡길 일두지 않을 내용
이번 요청의 프롬프트이번에 정리할 조회 경로, 유지할 정렬·페이지·응답 조건, 이번 변경에만 해당하는 예외모든 후속 작업에 적용할 영구 규칙
프로젝트 지침(AGENTS.md 등)작업을 실행하는 위치, 관련 테스트를 찾는 방법, 응답 계약의 정본을 확인할 위치처럼 반복 적용할 안정된 정보이번 요청의 데이터, 임시 우선순위, 한 번만 필요한 지시
좁은 Skill 후보리뷰 결과가 쌓였을 때 계약·변경점·검증 기록을 정해진 순서로 모으는 반복 절차와 필요한 참고자료목록 조회라면 무조건 수행할 스키마 변경 절차
테스트·스크립트정렬 순서, 페이지 경계, 합의된 응답 계약을 입력과 기대값으로 검사하는 단언“지침을 읽었으니 호환된다”는 판정

표에서 가장 중요한 경계는 마지막 행이다. 지침은 어디를 보고 어떻게 일할지 알려 줄 수 있지만, 응답이 실제로 계약을 지키는지는 실행 가능한 검사와 그 결과로 확인해야 한다. Skill에 “페이지 경계를 확인하라”고 적어도, 그 문장이 페이지 경계 테스트의 입력·단언·실행 기록을 대신하지는 않는다. 공식 Skill 평가 글 역시 호출 여부뿐 아니라 기대한 단계와 산출물이 나왔는지를 따로 살피도록 제안한다.[S2]

반대로 모든 것을 테스트로 옮길 수도 없다. “이번에는 조회 경로만 정리한다”는 목표는 이번 요청의 범위이며, 프로젝트의 영구 규칙도 코드로 검사할 계약도 아니다. 이번 데이터와 임시 예외를 AGENTS.md에 계속 쌓으면 다음 작업에서는 그것이 아직 유효한지 판단하는 일이 새 부담이 된다.

정비는 안정된 정보 하나에서 시작한다

목록 조회를 맡길 때마다 “어느 디렉터리에서 실행하고, 관련 테스트는 어디서 찾고, 응답 호환 조건은 무엇을 기준으로 보라”는 말을 되풀이한다고 하자. 이 셋을 한꺼번에 지침으로 복사하기보다, 먼저 오래 유지될 정보 하나를 고를 수 있다.

예를 들어 응답 계약의 상세 내용에 이미 정본이 있다면, 프로젝트 지침에는 “목록 응답을 바꿀 때 그 정본을 확인한다”는 연결만 남긴다. 계약 필드와 예외를 지침에도 다시 적으면 두 사본이 달라졌을 때 어느 쪽을 따라야 하는지부터 해결해야 한다. OpenAI의 GPT-6 Astra 관련 글도 모든 편집 전에 문서 묶음을 읽도록 하기보다, 해당 작업에 필요한 문서를 맥락에 맞게 가리키라고 권한다.[S1] 정본 자체가 불분명하다면 지침 문구를 늘리기 전에 팀이 쓰는 계약이 무엇인지부터 확인해야 한다.

여기서 Skill을 만드는 일은 다음 선택지다. 리뷰 결과를 정리할 때마다 계약 확인, 변경점 요약, 검증 기록 대조, 남은 질문 정리라는 같은 다단계 절차가 반복된다면 좁은 Skill 후보가 된다. OpenAI는 Skill의 이름과 설명을 Codex가 적용 여부를 판단하는 주요 신호로 설명한다.[S2] 따라서 설명도 “모든 목록 조회 작업에 사용”보다 “목록 조회 변경의 리뷰 기록을 정해진 항목으로 정리할 때 사용”처럼 실제 절차의 시작 조건을 드러내는 편이 낫다. 이 문구가 실제로 적절히 선택될지는 이후 작업에서 확인해야 한다.

적용하지 않을 조건도 분명해야 한다. 조회 로직만 정리하는 작업에 스키마 변경이 없다면 스키마 변경 Skill을 부를 이유가 없다. 단순한 수정 보고에 계약·검증 기록을 모으는 리뷰 절차가 필요하지 않다면 그 Skill도 건너뛸 수 있다. OpenAI의 제품별 조언은 범위가 넓거나 서로 겹치는 Skill 설명 때문에 관련 없는 지침이 선택될 수 있다고 지적한다.[S1] 다만 그 조언을 모든 모델이 같은 방식으로 Skill을 선택한다는 보장으로 읽을 수는 없다.

투자할지는 반복 부담과 유지 부담을 함께 본다

얼마나 반복해야 지침이나 Skill을 만들 만한가? 이 글에서 제안하는 기준에는 정해진 횟수가 없다. 먼저 네 가지를 묻는 편이 실용적이다.

  • 얼마나 자주 다시 설명하는가? 실행 위치처럼 여러 작업에서 되풀이하는 정보인지, 이번 요청에서만 필요한 조건인지 본다.
  • 빠뜨리면 무엇을 다시 해야 하는가? 관련 테스트를 놓쳐 검토를 되풀이하는지, 단지 짧은 질문을 한 번 더 하는지 구분한다.
  • 다음 작업에도 유효할 만큼 안정적인가? 응답 계약의 정본 위치는 유지되지만 이번 요청의 예외는 곧 사라질 수 있다.
  • 설정하고 돌보는 데 얼마나 드는가? 문구를 쓰는 시간뿐 아니라 잘못 적용된 이유를 찾고, 정본이 옮겨졌을 때 연결을 고치는 수고까지 센다.

이것은 공식 제품의 투자 공식이 아니라 필자의 판단 기준이다. 토큰을 덜 썼는지만 보면 다른 비용이 가려진다. 같은 내용을 재설명하는 횟수, 작업 중 개입해야 하는 순간, 잘못된 결과를 되돌리는 수고, 최종 결과를 검토하는 부담과 품질을 함께 보는 편이 목적에 맞다. OpenAI가 누적 지침의 재검토와 Skill의 호출·결과 평가를 권하는 것도 설정을 만든 뒤의 동작을 살필 이유가 된다.[S1][S2]

가끔 하는 목록 조회 변경이라면 요청 프롬프트에 그때의 조건을 적는 것으로 충분할 수 있다. 호출자마다 유지해야 할 응답 계약이 달라진다면, 그 차이를 영구 지침으로 일반화하는 순간 예외 관리가 더 어려워질 수도 있다. 이미 짧은 프롬프트로 범위를 명확히 전달하고 결과를 검토할 수 있다면, 현 상태를 유지하는 것도 투자 판단의 결과다.

반면 매번 같은 정본을 찾아 달라고 다시 요청하고, 누락될 때마다 계약 검토를 되풀이한다면 작은 연결 하나를 지침에 둘 이유가 생긴다. 리뷰 기록 정리에 일정한 순서가 필요하고 여러 작업에서 실제로 반복된다면 그때 Skill에 쓸 시간을 검토할 수 있다. 두 경우 모두 설정이 일을 덜어 줄 것이라는 예상일 뿐, 아직 확인된 개선 결과는 아니다.

한 가지만 바꾸고 남길 이유를 확인한다

정비의 효과를 알고 싶다면 변경 전에 비교할 문제를 좁힌다. 예를 들어 “관련 테스트의 위치를 매번 다시 설명한다”를 문제로 정하고, 다음 비슷한 작업에서 테스트 위치를 찾았는지와 결과를 검토하는 수고가 어땠는지를 볼 수 있다. Skill 후보라면 필요한 작업에서 적용됐는지뿐 아니라 필요 없는 작업에 호출됐는지도 살핀다. OpenAI의 Skill 평가 글은 기대한 호출, 누락된 단계, 불필요한 실행과 산출물을 미리 정한 기준으로 관찰하도록 제안한다.[S2]

그다음 한 가지만 바꾼다. 테스트 위치의 정본을 가리키는 지침 한 항목을 추가했다면, 동시에 리뷰 Skill까지 만들지 않는다. 이후 비슷한 실제 작업에서 필요한 정보를 찾는지, 엉뚱한 절차가 끼어들지 않는지, 중요한 조건을 놓치지 않는지 살핀다. 정렬이나 페이지 동작처럼 코드로 판정할 계약은 여전히 관련 테스트·스크립트의 입력과 단언, 실제 실행 결과로 확인한다.

도움이 드러나지 않거나 설정을 해석하고 고치는 부담이 더 크다면 문구를 좁히거나 제거한다. Skill이 자꾸 필요 없는 작업에 적용된다면 이름과 설명의 범위를 다시 잡거나, 반복 절차라는 가정 자체를 접을 수 있다. 모델이나 프로젝트가 바뀔 때에는 남아 있는 규칙마다 왜 만들었는지, 가리키는 정본이 여전히 맞는지, 다른 지침과 중복되는지를 돌아본다. 누적된 지침을 재검토하자는 공식 조언도 이런 점검의 출발점이다.[S1] 오래된 작업 안내를 정리하는 일은 권한·승인·보안 경계를 해제하는 일과 구별해야 한다.

남길 것은 설정의 양보다 배치와 검증의 판단이다

도구의 동작이 바뀌면 오늘 적절한 지침이나 Skill도 다시 살펴야 한다. 그때에도 쓸 만한 능력은 반복되는 부담을 발견하고, 정보를 둘 위치를 고르고, 코드로 검사할 계약과 사람이 검토할 판단을 가른 뒤 유지 비용을 다시 따지는 능력일 것이다. 이는 특정 기능을 모두 익혀야 한다는 결론이 아니라, 그런 부담이 실제로 반복될 때에 대한 조건부 투자 제안이다.

최근 여러 번 설명한 내용 하나를 떠올려 보자. 이번 요청에만 필요한가, 프로젝트에서 안정적으로 유지되는가, 분명한 반복 절차인가, 실행 가능한 계약인가? 답에 따라 한 곳만 작게 정비할 수도 있고 지금의 프롬프트를 유지할 수도 있다. 다음 편 「지금의 나는 무엇을 더 배우고, 무엇은 미뤄도 될까?」에서는 이 판단을 학습 우선순위로 이어 간다.

Sources

오류 제보·의견 보내기

글 제목과 주소가 포함된 메일 초안을 엽니다. 내용과 받는 사람을 확인한 뒤 보내주세요.

받는 사람: [email protected]

메일 앱에서 작성

메일 앱이 열리지 않으면 아래 내용을 복사해 평소 쓰는 이메일에 붙여 넣으세요.

문의 안내

관련 글