제 회사에는 AI가 매일 읽는 지침 파일이 몇 개 있습니다. 회사 소개, 업무별 순서, 하지 말아야 할 것 목록 같은 것들이죠. 처음엔 한 장이었는데 지금은 꽤 두꺼워졌습니다. 규칙이 하나 생길 때마다 밑에 한 줄씩 붙였으니까요. 그런데 최근에 깨달은 게 있습니다. 그 파일은 관리하지 않으면 자산이 아니라 부채가 됩니다.
오늘은 AI 지침 파일 관리 이야기를 해보려 합니다. AI에게 줄 정보를 어떻게 설계하느냐는 예전에 컨텍스트 엔지니어링이라는 이름으로 한 번 정리했고, 반복 업무 규칙을 파일로 떼어내는 방법은 에이전트 스킬 이야기에서 다뤘습니다. 오늘 할 이야기는 그 다음 단계입니다. 만드는 법이 아니라 이미 만든 규칙을 언제 어떻게 지울 것인가.
1. 지침 파일은 시간이 지나면 조용히 틀려집니다
문제의 성질부터 짚겠습니다. 지침 파일이 처음부터 틀린 경우는 거의 없습니다. 쓸 때는 다 맞는 말이었죠. 문제는 사업이 바뀌는 속도가 문서를 고치는 속도보다 빠르다는 데 있습니다.
실제로 저희 자동화 지침에는 한동안 이미 중단하기로 결정한 작업의 실행 순서가 그대로 남아 있었습니다. 그 작업은 외부 비용 문제로 그만두기로 했는데, 지침에서는 지워지지 않았던 겁니다. 다행히 "여기는 중단됨" 이라는 표시를 크게 붙여둬서 사고는 안 났습니다. 만약 그 표시가 없었다면? AI는 매일, 아주 성실하게, 하지 말자고 결정한 일을 계속 만들어냈을 겁니다. 그리고 결과물이 나오니까 저는 한참 동안 몰랐겠죠.
AI에게 일을 맡긴 뒤로 저는 이 차이를 자주 느낍니다. 사람 직원이라면 "사장님 이거 저번에 접기로 하지 않았나요?"라고 묻습니다. AI는 안 묻습니다. 문서에 적혀 있으면 그게 회사의 뜻입니다. 그래서 1인 기업에서는 지침 파일이 곧 권한 위임장이고, 안 지운 한 줄이 곧 지시가 됩니다.
2. 안 치운 규칙이 일으키는 사고 세 가지
제가 겪은 유형은 크게 셋입니다.
첫째, 끝난 일을 계속 합니다. 위에 쓴 경우죠. 중단·폐기 결정은 보통 대화나 메신저에서 이뤄지는데, 그 결정이 문서에 반영되지 않으면 자동화는 어제와 똑같이 돕니다. 사람은 분위기로 아는데 AI는 문서로만 압니다.
둘째, 옛날 방식이 새 방식을 이깁니다. 방식을 바꿨는데 예전 설명이 지침에 남아 있으면, AI는 둘 다 읽고 대개 더 구체적으로 적힌 쪽을 따릅니다. 새 방식은 한 줄, 옛 방식은 열 줄이면 결과는 보나 마나입니다. 결과물이 왜 자꾸 예전 스타일로 나오는지 몰라 프롬프트를 고치고 있었는데, 범인은 제가 안 지운 문단이었습니다.
셋째, 이미 한 일을 또 합니다. 이게 제일 최근에 걸린 건인데요. 저희는 AI에게 매일 글감 초안을 잡게 하고, "최근에 쓴 것과 겹치지 않게"라는 규칙을 줬습니다. 여기서 '최근'을 처음에 2주로 잡았습니다. 그때는 글이 열 편 남짓이었으니 충분했죠. 지금은 예순 편이 넘습니다. 그러니 두 달 전에 쓴 주제가 "안 겹치는 새 주제"로 올라옵니다. 규칙이 틀린 게 아니라, 규칙이 만들어질 때의 전제가 만료된 겁니다. 어제와 오늘 이틀 연속으로 같은 일이 있었고, 저는 발행 직전에 전체 목록을 대조하고서야 알아챘습니다.
세 번째 유형이 특히 무섭습니다. 앞의 둘은 결과물이 이상해서 눈에 띄는데, 이건 결과물이 멀쩡해 보입니다. 잘 쓴 글이 올라오는데 두 달 전 글과 내용이 같을 뿐이죠.
3. 한 달에 한 번, 지침 파일 쳐내는 순서
그래서 규칙을 하나 만들었습니다. 한 달에 한 번, 지침 파일을 위에서 아래로 읽으면서 세 가지로 분류합니다. 코딩은 전혀 필요 없고, 파일을 열어 읽는 일입니다.
① 지금도 맞는 것 → 그대로 둡니다. 단, 숫자가 들어간 규칙(몇 자, 몇 개, 며칠, 몇 주)은 한 번 더 봅니다. 사고는 거의 다 여기서 납니다. 위의 '2주' 같은 것들이죠. 숫자 규칙 옆에는 그 숫자를 정한 이유를 한 줄 적어두세요. 이유가 적혀 있으면 전제가 바뀐 걸 알아챌 수 있고, 안 적혀 있으면 영원히 안 바뀝니다.
② 이제 안 하는 것 → 지우지 말고 '중단'이라고 크게 표시합니다. 저는 삭제보다 이쪽을 권합니다. 지워버리면 몇 달 뒤에 누군가(저 자신이거나 AI가) 좋은 아이디어라며 똑같은 걸 다시 제안하거든요. 대신 중단한 날짜와 이유를 같이 남깁니다. "○월 ○일 비용 문제로 중단, 재개는 별도 지시 전까지 없음" 정도면 충분합니다. 이렇게 해두면 AI가 그 항목을 건너뛰고, 저는 나중에 재개 여부를 판단할 근거를 갖습니다.
③ 바뀐 것 → 새 내용으로 덮어쓰고 옛 문장은 없앱니다. 여기서만큼은 삭제가 맞습니다. 같은 주제에 대해 서로 다른 지시가 두 개 남아 있으면 AI는 반드시 둘 중 하나를 고르는데, 그 선택은 제 뜻과 무관합니다.
분류가 끝나면 마지막으로 분량을 봅니다. 규칙이 길어질수록 AI가 그 안에서 중요한 항목을 정확히 집어낼 확률은 떨어집니다. 사람도 그렇잖아요. 200페이지를 주면서 "알아서 중요한 거 찾아봐" 하면 일이 될 리 없습니다. 그래서 저는 "이번 업무에 필요한 A4 두세 장"을 기준선으로 잡고, 넘치면 별도 파일로 쪼갭니다.
4. 지침보다 강한 건 '실패 로그'입니다
쳐내기와 짝이 되는 게 하나 있습니다. 가장 안 하는 것이고 효과는 가장 좋습니다. 실패 로그입니다. 잘못된 결과가 나왔을 때 "왜 이렇게 됐는지 + 다음엔 어떻게 할지"를 한 줄씩 쌓는 파일이죠.
이게 왜 중요하냐면, 지침은 제가 미리 예상한 것만 담고 있기 때문입니다. 반면 실패 로그는 실제로 벌어진 것을 담습니다. 한 달만 쌓아도 이 파일이 지침보다 정확해집니다. 저는 같은 지적을 두 번 한 뒤에야 분량 규칙을 문서에 박아 넣었는데, 그 뒤로는 같은 실수가 안 나옵니다. 세 번 말할 걸 한 번 적는 게 훨씬 쌉니다.
흥미롭게도 이걸 자동으로 하려는 연구도 나와 있습니다. 스탠퍼드·SambaNova·UC 버클리 연구진의 ACE(Agentic Context Engineering)라는 프레임워크인데, 모델을 다시 학습시키는 대신 입력 컨텍스트를 계속 고쳐 쓰게 만드는 접근입니다. 일을 수행하는 역할, 성공과 실패에서 교훈을 뽑는 역할, 그 교훈을 구조화된 '플레이북'에 반영하는 역할로 나눠서 지침 자체가 진화하게 합니다. 논문 초록 기준으로 기존 강력한 베이스라인 대비 에이전트 과제에서 +10.6%, 금융 추론 과제에서 +8.6% 향상됐다고 보고되며 ICLR 2026에 채택됐습니다(arXiv:2510.04618).
우리가 논문을 따라 구현할 필요는 없습니다. 가져갈 메시지는 한 줄입니다. 실패에서 뽑은 교훈을 그때그때 규칙 문서에 반영하면, 모델을 안 바꿔도 시스템이 점점 똑똑해집니다. 돈이 안 드는 개선 작업 중에 이게 제일 저평가돼 있다고 생각합니다. 이런 문서와 자동화를 어떤 순서로 쌓아 올렸는지는 「AI 회사를 만들었습니다 -실전편-」에 정리해뒀습니다.
마무리 — 안 지운 한 줄이 내일의 지시입니다
정리하겠습니다. AI에게 줄 지침을 만드는 건 시작이고, 진짜 일은 그 뒤에 있습니다. 사업은 매달 바뀌는데 문서는 가만히 있으니, 가만히 있는 문서가 어느 순간 틀린 지시가 됩니다. 그러니 한 달에 한 번은 열어서 끝난 것에 중단 표시를 붙이고, 바뀐 것은 덮어쓰고, 숫자 규칙의 전제를 다시 보세요.
오늘 딱 하나만 하신다면 이걸 권합니다. 지침 파일에서 숫자가 들어간 규칙을 전부 찾아 옆에 이유를 한 줄씩 적어보세요. 10분이면 됩니다. 저는 이걸 하다가 '2주'를 발견했고, 두 달 전 글을 또 낼 뻔한 걸 막았습니다. AI는 우리가 적어둔 대로 일합니다. 그래서 안 지운 한 줄은 지운 적 없는 지시입니다.
작성: Art Gourmet · 본문의 사례(중단 결정된 작업이 지침에 남아 있던 건, 중복 확인 기준이 2주로 고정돼 두 달 전 주제가 다시 올라온 건)는 2026년 9월 자사 자동화 운영 중 직접 겪은 내용입니다. ACE 관련 수치는 arXiv:2510.04618 초록 기준입니다.