에이전트에게 업무 설계도를 줬더니, 점수 차이는 전부 정책 질문에서 났습니다

한 프랜차이즈 ERP 의 업무를 에이전트가 맡을 수 있도록 업무별 '설계도'를 써 오고 있었습니다. 설계도는 업무 하나를 한 장에 적은 문서입니다. 목적·동작·금지·정해진 기준·사람에게 넘길 때 같은 칸이 있습니다.

그동안은 설계도를 어떻게 쓸지만 다듬었습니다. 설계도를 받은 에이전트가 실제로 일을 더 잘하는지는 한 번도 재지 않았습니다. 이번에 처음 쟀고, 차이가 나는 자리가 예상과 달랐습니다.

무엇을 어떻게 쟀나

대상은 '매입 분석' 업무 한 장입니다. 매입율이 낮은 매장을 찾고, 왜 낮은지 원인 후보를 대는 일입니다. 같은 질문 묶음을 에이전트에게 주되, 손에 쥐여 주는 재료만 바꿨습니다.

코드 + DB

DB 만

설계도 + DB

덜어낸 설계도 + DB

설계도를 Agent Skill 형태로 바꿔서

채점은 누가 답했는지 가리고 했습니다. 어느 조건의 답인지 알고 채점하면 설계도를 쓴 사람의 기대가 점수에 섞입니다. 질문에는 코드나 DB 에 답이 있는 질문과, 회사가 정한 규칙을 묻는 '정책형 질문' 셋을 섞었습니다.

LLM 에게 채점을 맡길 때 묻는 방식에 따라 결과가 어떻게 흔들리는지는 따로 정리해 둔 기록이 있습니다.

3점 차이는 전부 정책 질문에서 났습니다

먼저 설계도+DB 와 코드+DB 를 비교했습니다. 답은 비슷했습니다. 설계도를 준 쪽이 15~30% 빨랐을 뿐입니다.

다음은 설계도+DB 와 DB 만 준 조건입니다. 가린 채점에서 **10점 대 7점**이 나왔습니다. 질문별로 나눠 보니 3점 차이는 전부 정책형 질문에서 났습니다. 코드나 DB 에 답이 있는 질문에서는 두 조건의 점수가 같았습니다.

이유는 단순합니다. 테이블 구조·쿼리·계산식은 에이전트가 도구로 직접 찾아냅니다. 찾을 수 없는 건 '누가 이렇게 정했고 왜 그런가'입니다. 그 규칙은 사람 머릿속에만 있어서, 문서로 줘야만 에이전트가 맞힙니다.

그럼 코드에 있는 건 빼도 되나

차이가 정책 질문에만 있다면, 코드에서 찾을 수 있는 내용은 설계도에 적을 필요가 없습니다. 그래서 설계도를 덜어내고 같은 측정을 다시 했습니다.

덜어낸 기준은 두 가지였습니다. 코드·DB 에서 찾을 수 있는 것은 '어디를 보라'고 가리키기만 했습니다. 작업 이력과 건수 같은 기록성 내용은 뺐습니다. 예시 시나리오는 21개에서 4개로 줄었습니다.

결과는 설계도 분량 38% 감소, 점수 10점 그대로였습니다. 시간과 도구 호출은 약 25% 줄었습니다. 에이전트도 문서를 읽는 데 시간과 도구 호출을 씁니다. 길게 적은 설명은 점수를 올리지 못하고 읽는 비용만 늘렸습니다.

이 결과로 설계도의 원칙을 하나로 정했습니다. **코드·DB 에서 찾을 수 있는 것은 가리키기만 하고, 코드에 없는 규칙과 판단 기준을 적는다.** 매입 분석 한 장을 이 원칙으로 덜어낸 기준판을 만들었고, 나머지 업무도 이 모양으로 옮기기로 했습니다.

전달 형식을 바꾸면 비용이 달라졌습니다

설계도를 'Agent Skill'(요약 파일 하나와 딸린 참고 파일로 이뤄진 에이전트용 지침 묶음) 형태로 바꿔서도 쟀습니다. 점수는 역시 10점이었습니다. 토큰은 비교한 방식 중 가장 적었습니다.

에이전트는 딸린 참고 파일 넷 중 셋만 열었습니다. 셋 모두 열 이유가 있을 때 열었습니다. 처음엔 요약만 읽고 필요할 때 본문을 여는 '단계적 공개'가 실제로 작동한 것입니다. 전달 형식은 점수가 아니라 비용을 바꿨습니다.

같은 구조를 사람이 보는 진행 기록 화면에도 적용했습니다. 업무 한 장을 요약·본문·참고 세 단계로 나눴고, 첫 화면 글자가 60% 줄었습니다. 스킬의 요약과 화면의 요약, 스킬의 참고 파일과 화면의 참고 칸이 같은 내용을 가리키게 맞췄습니다.

모든 조건에서 비어 있던 것, 지표 정의

어느 조건에서나 같은 곳이 비어 있었습니다. 저희가 쓴 설계도에 매입율 셈법이 빠져 있었습니다. 어느 매장끼리 비교하는지, 금액에 부가세를 넣는지를 적어 두지 않았습니다.

그러자 같은 질문에 **숫자가 매번 두 갈래로 갈렸습니다.** 비율도, 해당 매장 수도 달랐습니다. 사람끼리도 생기는 일입니다. 다만 에이전트는 셈법이 둘이라는 사실을 알리지 않고, 실행할 때마다 다른 숫자를 확정된 답처럼 내놓습니다.

지표 정의는 코드에서 확인해 설계도의 '지표 계산' 칸에 적었습니다.

금액은 부가세 포함으로 셈한다

계약상 같은 브랜드 조합을 운영하는 매장끼리 비교한다

일정 매출 이상인 매장만 넣는다

평균이 아니라 중앙값으로 본다

정의가 아직 문서에 없는 지표는 화면과 스킬 모두 '잠정'으로 표시하게 했습니다. 업무마다 '정해지지 않은 것' 목록도 둘이 같은 규칙으로 보여 줍니다.

이 측정이 말하지 못하는 것

업무 한 장, 질문 몇 개로 한 첫 측정입니다. 정책형 질문이 셋뿐이라 표본이 작습니다. 3점 차이가 전부 정책 질문에서 났다는 방향은 분명하지만, 몇 점 차이인지는 다시 재면 달라질 수 있습니다.

같은 설정으로 두 번 돌려도 결과가 얼마나 흔들리는지는 앞서 실측한 기록이 있습니다.

덜어낸 설계도는 처음과 같은 질문으로 다시 쟀습니다. 설계도가 그 질문에 맞춰졌을 가능성이 있습니다. 새 질문으로 다시 재는 일이 남아 있습니다.

코드가 정리돼 있지 않거나 DB 컬럼 이름만으로 뜻을 알 수 없는 시스템에서는 '코드에 있는 건 빼라'가 그대로 통하지 않을 수 있습니다. Agent Skill 의 토큰 절감도 참고 파일이 넷뿐인 작은 구성에서 본 결과입니다.

에이전트용 업무 문서를 쓸 때 점검할 것

문서에 적힌 내용 중 코드·DB 에서 에이전트가 직접 찾을 수 있는 것은 위치만 가리키고 있는가

누가 정했고 왜 그런지, 언제 사람에게 넘기는지가 적혀 있는가

지표마다 비교 대상·포함 범위·금액 기준이 정의돼 있는가, 없으면 '잠정'으로 표시되는가

요약만 먼저 읽히고 참고 내용은 필요할 때 열리는 구조인가

효과를 잴 때 누가 답했는지 가리고, 코드에 답이 있는 질문과 정책 질문을 섞었는가

에이전트에게 주는 문서의 쓸모는 코드에 없는 것에서 나왔습니다. 길게 적은 설명은 점수를 올리지 못했고, 정의가 빠진 지표 하나는 같은 질문의 답을 둘로 갈랐습니다. 업무 문서를 쓰기 전에 '에이전트가 이걸 직접 찾을 수 있는가'를 먼저 물어보시기 바랍니다.