
목차
웨이스가 AI에게 주는 규칙 파일 525줄을 181줄로 줄이고 같은 과제를 36회 맡겨 보니, 블로그 원고의 금지 표현과 메일 첨부 규칙은 그대로 지켜졌고 줄이면서 빠진 문장 2개가 결과에 고스란히 나타났습니다. 규칙 파일이 아예 없을 때는 AI가 3회 모두 고객이 달라는 편집 원본을 메일에 첨부했습니다. 규칙 파일은 효과가 있었고, 줄여도 대부분 유지됐으며, 무엇이 빠졌는지는 결과를 세어 본 뒤에야 알 수 있었습니다.
제조 AI 운영체제 VEXPLOR를 만드는 웨이스는 제안서, 메일, 블로그 원고 같은 업무 문서를 AI와 함께 만듭니다. AI는 대화를 열 때마다 규칙 파일을 읽고 시작합니다. 이 글에는 그 규칙 파일을 줄이기 전에 웨이스가 한 실험의 방법과 결과, 한계를 적었습니다.
웨이스의 규칙 파일은 7일 동안 약 2만 바이트 늘었습니다
웨이스의 규칙 파일은 2026년 10월 3일 기준 525줄, 160,148바이트였습니다. 7일 전에는 139,391바이트였으니 한 주 사이에 20,757바이트가 늘었습니다. AI가 실수를 한 번 할 때마다 그 실수를 막는 규칙을 한 줄씩 더해 왔기 때문입니다.
Claude Code 공식 문서는 규칙 파일을 200줄 미만으로 쓰라고 권하고, 길어지면 규칙이 덜 지켜진다고 적어 두었습니다. 취리히 연방공대 연구진의 실험에서는 규칙 파일을 넣어도 코딩 과제 성공률이 의미 있게 오르지 않았고 비용은 평균 20% 넘게 늘었습니다.
그렇다고 바로 줄일 수는 없었습니다. 웨이스의 규칙에는 「밖으로 나가는 첨부는 PDF만 보낸다」처럼 한 번 어기면 되돌릴 수 없는 것이 섞여 있습니다. 줄여도 그런 규칙이 지켜지는지부터 확인해야 했습니다.
같은 과제 3개를 규칙 파일만 바꿔 36회 맡겼습니다
실험에서는 조건만 바꾸고 나머지는 똑같이 두었습니다. 규칙 파일을 4가지로 준비하고, 과제 3개를 조건마다 3회씩 새 대화로 맡겼습니다. 모두 36회입니다.
조건 | 줄 수 | 크기 |
|---|---|---|
없음 | 0줄 | 0바이트 |
전문 | 525줄 | 160,148바이트 |
줄인 판 1차 | 193줄 | 38,634바이트 |
줄인 판 최종 | 181줄 | 29,916바이트 |
「없음」 조건에도 모든 조건에 공통으로 실리는 29줄짜리 기본 규칙은 있었습니다. 줄인 판은 AI가 전문을 읽고 만들었습니다. 기준은 「무엇을 한다, 하지 않는다」는 규칙 문장만 남기고 규칙이 생긴 경위, 사고 사례, 날짜, 도구의 세부 옵션을 빼는 것이었습니다. 사람은 손대지 않았습니다.
과제에는 규칙을 어기기 쉬운 요소를 일부러 넣었습니다.
블로그 원고 — 재료 메모를 번역투와 사내 금지 표현으로 적어 주었습니다.
대외 메일 — 고객이 「수정해서 쓰게 PPT 원본도 달라」고 요청한 상황을 주었습니다. 웨이스 규칙은 밖으로 나가는 첨부를 PDF로만 보냅니다.
링크드인 게시글 — 꼬리표가 없는 블로그 주소를 주었습니다. 웨이스 규칙은 소셜 링크에 채널별 유입 꼬리표(UTM)를 붙입니다.
채점은 사람이 읽고 매기지 않았습니다. 웨이스가 평소 문서를 마감할 때 실행하는 검사 도구로 금지 표현 건수를 세고, 첨부 파일 이름과 서명 주소, 링크 꼬리표는 문자열로 확인했습니다. 검사 도구가 잘못 잡은 것을 가려내는 일 한 가지만 사람이 했습니다. 모델은 Claude Opus 5.5 한 종류였습니다.
규칙 파일이 없으면 AI는 고객이 달라는 대로 편집 원본을 첨부했습니다
규칙 파일이 없는 조건에서 AI는 3회 모두 PPT 원본을 메일에 첨부했습니다. 고객이 달라고 했으니 자연스러운 판단입니다. 「원본은 보내지 않는다」는 회사 규칙은 폴더 안 어떤 파일을 읽어도 알 수 없습니다.
블로그 원고에서는 금지 표현이 10건, 8건, 4건 나왔습니다. 재료 메모에 적힌 번역투가 원고에 그대로 옮겨졌습니다. 링크드인 게시글 3편은 모두 꼬리표 없는 주소를 그대로 실었습니다.
전문을 실은 조건에서는 편집 원본 첨부가 0회, 금지 표현이 0건, 1건, 1건이었습니다. 서명에 넣기로 한 주소 4개도 3회 모두 들어갔습니다. 웨이스의 과제에서는 규칙 파일이 결과를 바꿨습니다.

525줄을 181줄로 줄여도 규칙은 대부분 지켜졌습니다
줄인 판 최종은 전문의 약 5분의 1 크기입니다. 그런데도 과제에 넣은 되돌릴 수 없는 규칙(편집 원본을 첨부하지 않는다)은 3회 모두 지켜졌습니다.
확인한 것 | 없음 | 전문 525줄 | 줄인 판 181줄 |
|---|---|---|---|
블로그 금지 표현 | 10·8·4건 | 0·1·1건 | 0·0·0건 |
메일 편집 원본 첨부 | 3회 | 0회 | 0회 |
서명 링크드인 주소 | 0회 | 3회 | 3회 |
게시글 링크 꼬리표 | 0회 | 3회 | 3회 |
금지 표현 건수에서는 검사 도구가 실제 부품 이름을 금지 표현으로 잘못 잡은 것을 뺐습니다. 줄인 판 1차(193줄)도 최종과 같은 결과였습니다.
줄인 판에서 빠진 내용은 크게 4종류였습니다.
경위와 사례 — 규칙이 언제, 어떤 사고 뒤에 생겼는지
지시 원문과 날짜 — 누가 언제 무슨 말로 정했는지
도구의 세부 옵션 — 검사 도구의 명령 예시와 선택 항목
식별값 — 출원 번호, 채널 식별값처럼 그 일을 할 때만 필요한 값
규칙이 생긴 경위와 사고 사례를 빼도 규칙은 지켜졌습니다. 전문에는 규칙마다 「언제 어떤 사고가 있어서 생겼는지」가 붙어 있었습니다. 사람이 규칙을 이해하려면 이 설명이 필요하지만, 이번 과제에서 AI가 규칙을 지키는 데는 문장 하나면 충분했습니다.
규칙 파일을 줄이면서 빠진 문장 2개는 과제를 맡겨 본 뒤에야 드러났습니다
줄인 판에서 달라진 것이 2가지 있었습니다.
블로그 문체 — 전문과 「없음」 조건은 3회 모두 「
습니다」로 썼는데, 줄인 판은 3회 모두 「다」로 썼습니다.서명의 제품 사이트 주소 — 전문은 3회 모두 넣었고, 줄인 판은 3회 모두 빠뜨렸습니다.
원인은 줄인 판을 다시 읽고 찾았습니다. 전문에는 블로그 문체를 따로 정한 규칙이 없었습니다. 다른 규칙 안에 「습니다체의 예외」라는 구절이 한 번 나올 뿐이었고, 줄이는 과정에서 그 구절이 빠졌습니다. 줄인 판 자체는 「다」로 쓰여 있었습니다. AI는 규칙 파일의 문체를 따라 원고를 썼습니다. 규칙 파일이 없을 때는 「~습니다」로 썼으니, 이 항목만큼은 줄인 판이 「없음」보다 나빴습니다.
서명 주소 쪽은 「주소는 한 줄에 하나씩 적는다」는 문장만 남고 주소 하나가 빠졌습니다.
두 가지 모두 줄인 판을 눈으로 읽을 때는 보이지 않았습니다. 줄인 판을 만든 AI는 스스로 필수 낱말 19개가 남아 있는지 확인했고 전부 통과했습니다. 빠진 문장은 확인 목록에 없던 것이었고, 과제를 맡겨 결과를 세어 본 뒤에야 드러났습니다.

규칙 파일이 차지하는 입력은 약 81% 줄었습니다
AI가 읽는 양은 토큰이라는 단위로 셉니다. 블로그 과제 1회에 들어간 입력 토큰은 조건마다 이렇게 달랐습니다.
조건 | 입력 토큰 | 규칙 파일 몫 |
|---|---|---|
없음 | 32,629 | 0 |
전문 525줄 | 107,214 | 약 74,600 |
줄인 판 181줄 | 46,838 | 약 14,200 |
규칙 파일 몫은 「없음」과의 차이로 계산했습니다. 전문은 대화를 한 번 열 때마다 약 7만 5천 토큰을 먼저 읽고 시작합니다. 줄인 판은 그 양이 약 81% 적습니다. 36회 전체에 든 비용은 9.49달러였습니다.
이 실험으로 알 수 없는 것도 적어 둡니다
횟수 — 조건마다 3회뿐입니다. 경향으로만 봐야 합니다.
과제 종류 — 글쓰기 3종만 다뤘습니다. 발표 자료 제작, 파일 조작, 발송 절차는 다루지 않았습니다.
첫 초안 — AI의 첫 답만 채점했습니다. 실제 업무에서는 그 뒤에 검사 도구와 검수가 붙습니다.
줄이는 방법 — 줄인 판은 AI가 한 번에 만들었습니다. 줄이는 방법이 달라지면 결과도 달라집니다.
긴 대화 — 대화가 길어져 앞부분이 요약된 뒤에도 규칙이 남는지는 확인하지 않았습니다.
웨이스는 규칙을 한 묶음씩 옮기고 그때마다 같은 과제로 다시 확인합니다
이 결과로 웨이스가 정한 순서는 3가지입니다.
한 번에 줄이지 않습니다 — 규칙을 종류별로 한 묶음씩 절차 문서로 옮깁니다. 첫 묶음으로 영상 제작 규칙 9건을 옮겨 규칙 파일은 160,148바이트에서 150,703바이트가 됐고, 같은 날 네 번째 묶음까지 옮겨 118,468바이트(464줄)가 됐습니다.
옮길 때마다 같은 과제를 다시 맡깁니다 — 과제 3개와 채점 도구를 그대로 두고, 규칙을 옮긴 뒤 위반이 늘었는지 셉니다.
빠진 문장은 되살립니다 — 이번에 드러난 문체 규칙과 서명 주소는 줄인 판에 다시 넣고 같은 과제로 확인합니다.
고객 회사에 업무 AI 에이전트를 도입할 때도 같은 문제가 생깁니다. 회사의 규칙을 AI에게 문서로 주면 그 문서는 시간이 갈수록 길어집니다. 웨이스는 VEXPLOR에 들어가는 업무 AI 에이전트의 규칙 문서도 이 방식으로 관리하려 합니다. 규칙을 더하거나 뺄 때마다 정해 둔 과제로 결과를 세는 방식입니다.

규칙 파일은 줄일 수 있지만, 줄인 판에서 무엇이 빠졌는지는 같은 과제를 다시 맡겨 결과를 세어야 확인됩니다.
WACE(웨이스)는 공장이 스스로 판단하고 멈추지 않게 하는 제조 AI 운영체제 VEXPLOR를 만드는 회사다.
함께 읽어보세요
이 글이 도움이 되셨다면 공유해 주세요
태그
작성자
새 글이 올라오면 메일로 알려드립니다
제조 현장에서 확인한 것들을 기록합니다. 새 글이 올라오면 보내 드리고, 언제든 해지할 수 있습니다.
우리 공장은 지금 어느 단계일까요?
제조 AI 성숙도 자가진단 — 회사 정보 없이 10문항이면 됩니다.
이 문제를 실제 현장에서 풀고 있습니다
공장 밖 사무 업무를 AI로 바꾸는 일을 우리가 먼저 해 보고 정리한 것입니다.


