제안서 초안에 지난 분기 포지셔닝이 들어갔다고 해보자. 담당자가 문장을 고쳐 제출하면 그 문서는 해결된다. 하지만 AI가 참고한 낡은 자료를 그대로 두면 다음 제안서에서도 같은 교정이 필요하다. AX LABS의 글 은 개인 채팅에 남은 이런 교정을 팀의 작업 기준으로 옮기는 과정을 프롬프트 여섯 개로 나눠 설명한다.

채팅 기록에서 회사 지도까지

출발점은 새 문서를 쓰는 일이 아니다. 팀원은 최근 AI 작업에서 자신이 바로잡은 사실과 여러 번 설명한 회사 사정을 찾는다. 좋은 결과를 낸 요청 조건과 매번 다시 붙여 넣은 자료도 모은다. 이때 실제 교정 문장을 남기고 개인 취향과 팀이 공유할 기준을 구분한다. 확실하지 않은 내용은 확인 대상으로 둔다.

다음은 AI가 먼저 읽을 짧은 지도 파일이다. 회사가 하는 일과 현재 우선순위, 출처가 충돌할 때 무엇을 우선할지, 세부 자료가 어디에 있는지를 적는다. 예를 들어 decisions/에는 결정의 이유와 대체된 결정을, policies/에는 반복해서 적용할 규칙을 둔다. learnings.md에는 검토를 통과한 교정을 모은다. 코딩 에이전트를 쓴다면 AGENTS.md나 CLAUDE.md를 진입점으로 삼을 수 있다. 필요한 자료를 작업에 맞춰 열어야 오래된 회의 메모가 현재 승인된 결정과 뒤섞이지 않는다.

교정을 어디에 남길 것인가

결과물을 고친 뒤에는 오류의 원인을 따져야 한다. 낡은 사실이라면 출처와 확정일이 있는 지식 항목을 고치고, 새로 정한 방향이라면 결정 기록에 남긴다. 검증된 작업 방법은 스킬로, 반복 절차는 입력·출력과 중단 조건을 갖춘 워커 명세로 옮긴다. 발송·결제·삭제처럼 외부에 영향을 주는 행동은 프롬프트 문장에만 맡기지 않고 권한과 승인 단계에서 통제한다.

교정이 나올 때마다 바로 정책으로 만들지는 않는다. 원문은 3회 규칙을 제안한다. 1회에는 고치고 끝낸다. 같은 교정이 2회 나오면 메모만 남긴다. 서로 다른 사람이 서로 다른 작업에서 3회째 같은 문제를 지적하면 정책 후보로 올린다. 승격할 때는 확정일과 소유자, 대체하는 기존 규칙을 함께 기록한다. 한 사람의 표현 취향이 팀 전체의 규칙으로 굳는 일을 막기 위해서다.

실행하고 다시 점검하기

반복 업무를 워커로 만들 때는 필요한 입력과 참고할 파일, 단계별 판단 기준과 출력 형식을 적는다. 언제 멈춰 사람에게 물을지, 결과가 잘못됐음을 알아챌 실패 신호는 무엇인지도 정해야 한다. 외부 공유 전 승인자도 지정한다. 3회가 쌓인 정책 후보는 공유 전에 기존 규칙과 충돌하는지, 다른 팀에도 적용되는지, 어떤 예외가 있는지 반대 관점에서 검토한다.

운영을 시작한 뒤에는 매주 답을 찾지 못한 요청과 충돌한 출처를 확인한다. 오래된 근거, 반복된 교정, 열리지 않은 파일도 점검한다. 원문은 파일 개수보다 출처 충돌 건수를 관리 지표로 제안한다. 반복 업무 하나를 골라 지도와 교정 기록을 만들고 실제 작업을 한 번 돌려 보면, 다음 주에 무엇을 고쳐야 할지 드러난다.