에이전트를 돌려 놓고 결과를 받아 보면, 내가 적어 둔 답과 다른 숫자가 나올 때가 있습니다. 그럴 때 보통은 에이전트를 먼저 의심하게 됩니다. 저도 그랬습니다.
업무용 에이전트를 만들 때 제가 지키는 순서가 있습니다. 에이전트를 돌리기 전에 정답지를 먼저 써 둡니다. 회의록이면 결정이 몇 개고 할 일이 몇 개인지, 제안요청서면 요구사항이 몇 건인지를 미리 적습니다. 그리고 에이전트를 돌린 뒤 결과를 정답지와 대조합니다.
에이전트에게는 일을 시키는 문서만 줍니다. 무엇을 어떻게 하라는 지시문, 칸과 항목을 짝지은 대응표 같은 것들입니다. 정답지는 그 바깥에 따로 덮어 둡니다. 보여 주면 시험이 아니라 받아쓰기가 되니까요.
이 순서에는 전제가 하나 있습니다. 정답지는 맞고, 어긋나면 에이전트가 틀린 것이라는 전제입니다. 저도 그렇게 믿고 채점해 왔습니다. 그런데 이번 달에 그 전제가 네 번 깨졌고, 그때마다 고민이 하나씩 쌓였습니다. 결과가 정답지와 다를 때 저는 무엇을 먼저 의심해야 할까요.
다섯 종의 에이전트를 합성 자료로 끝까지 돌려 봤습니다
만든 에이전트를 실제 도구로 처음부터 끝까지 한 번 돌려 보는 것을 저는 골든런이라고 부릅니다. 설명서가 아니라 실제로 끝까지 도는지를 보는 첫 완주입니다. 도구는 실제로 쓰고, 자료만 지어냅니다. 맞는 답을 적어 둔 문서는 따로 정답지라고 부르겠습니다.
9월 6일과 11일, 이틀에 걸쳐 업무 에이전트 다섯 종을 골든런으로 돌렸습니다. 회의록에서 할 일 뽑기, 제안요청서에서 요구사항 세기, 사업계획서를 제출 양식으로 옮기기, 제안 전략 잡기, 기록물 보존기간 검토하기입니다.
자료는 전부 제가 지어낸 합성 자료입니다. 가상의 회의 전사본, 가상의 공고문, 가상의 기록물 목록이죠. 일부러 함정도 심어 뒀습니다. “다음 주 수요일” 같은 상대 기한, 번호가 하나 빠진 요구사항 목록, 글자 수를 넘는 칸 같은 것들입니다. 실행 중에는 사람이 끼어들지 않았고, 결과만 제가 정답지와 대조했습니다.
과제마다 정답지와 대조한 실행은 두 번에서 네 번입니다. 9월 11일에 돌린 네 과제는 실행마다 자료 폴더를 처음 상태로 새로 복사해서, 앞 실행의 결과가 다음 실행에 보이지 않게 했습니다. 9월 6일에 돌린 회의록 과제는 그 방식을 쓰기 전이라, 같은 조건을 두 번 돌린 게 아니라 구성을 달리해 두 번 돌린 결과입니다.
에이전트가 틀린 적이 없었다는 얘기는 아닙니다. 회의록 에이전트는 마이크를 넘겨받은 사람의 발언을 앞사람 것으로 붙여서, 할 일 하나의 담당자를 잘못 적었습니다. 그건 에이전트 지침을 고쳤고요. 이 글은 그 반대편, 정답지나 제가 쓴 기준 쪽이 틀렸던 네 번의 이야기입니다.
요일과 건수는 제가 세지 않고 적은 숫자였습니다
회의 전사본에 날짜를 “9월 4일(목)”이라고 적어 뒀습니다. 회의에서 누군가 “다음 주 수요일까지”라고 말하고요. 정답지에는 목요일 기준으로 계산한 날짜를 적었습니다.
한 실행은 실제 달력으로 계산해서 다른 날짜를 냈습니다. 확인해 보니 2026년 9월 4일은 금요일이었습니다. 제가 전사본에 요일을 잘못 적었고, 정답지도 그걸 따라 틀렸던 겁니다.
다른 실행은 전사본에 적힌 “(목)”을 믿고 제 정답지와 같은 날짜를 냈습니다. 입력을 믿은 것도 나름 방어가 되는 행동입니다. 그런데 정답지 기준으로는 이쪽이 통과였습니다. 제 오기를 따라간 쪽이 통과하고, 달력을 확인한 쪽이 탈락할 뻔했습니다.
제안요청서 에이전트도 비슷했습니다. 정답지에는 “기능 요구사항 11건, 전체 합계 32건, 총괄표의 33건과 불일치”라고 적었습니다. 숫자가 안 맞는 함정을 심었다고 생각했거든요.
두 실행 모두 기능 요구사항 12건, 전체 33건이라고 했습니다. 총괄표와 같다고요. 대신 요구사항 번호 하나가 비어 있다고 짚었습니다. 다시 세 보니 두 실행이 맞았습니다. 번호가 하나 빠진 건 맞는데 건수는 어긋나지 않았습니다. 함정을 심은 저는 정답지를 쓰면서 목록을 직접 세지 않았던 겁니다.
제가 쓴 문서 두 개가 서로 다른 말을 하고 있었습니다
사업계획서를 제출 양식으로 옮기는 에이전트입니다. 날짜 형식이 틀린 값이 있으면 어떻게 할까요. 정답지는 “그대로 옮기고 위반으로 보고한다”였습니다.
첫 실행은 그 값을 칸에 넣지 않고 비워 뒀습니다. 틀렸나 싶어 에이전트가 읽은 문서를 다시 봤습니다. 칸 대응표에는 “형식 위반은 고치지 말고 그대로 옮긴 뒤 보고”라고 적혀 있었고, 작업 지침에는 “규칙을 어기는 값은 넣지 않고 위반 목록에 적는다”라고 적혀 있었습니다.
에이전트는 둘 중 하나를 골랐을 뿐이고, 어느 쪽을 골라도 지시를 어긴 게 아니었습니다.
그래서 두 문서를 한 줄로 맞췄습니다. 글자 수를 넘어서 줄여야만 칸에 들어가는 값만 비우고, 날짜 형식 위반 같은 나머지는 그대로 넣고 보고한다. 그 뒤로 새 사본에서 두 번 더 돌렸고, 둘 다 정답지와 같았습니다.
막힌 곳: 세는 방법을 안 적은 칸은 정의를 조여도 갈렸습니다
제일 오래 붙잡혀 있던 건 제안 전략 에이전트였습니다.
이 에이전트는 공고문의 평가 배점을 읽고 정성 배점을 셉니다. 정성 배점은 평가위원의 판단이 들어가는 점수이고, 발표 점수도 여기에 넣었습니다. 이 점수가 크면 제안서로 뒤집을 여지도 크니까요. 가상 공고는 가격 20점을 뺀 평가 항목을 다 더하면 78점이었습니다. 공고문 표기는 80점이었는데, 이 어긋남도 일부러 심어 둔 함정이었습니다. 두 실행 모두 한쪽을 고르지 않고 78과 80을 나란히 적은 뒤 둘이 안 맞는다고 짚었습니다. 이건 제가 바란 그대로였고, 아래 숫자는 항목을 실제로 더한 78을 바닥으로 씁니다.
정답지에는 35점이라고 적었습니다. 사업 이해도 10점, 답변 품질 방안 15점, 발표 10점. 제가 판단이 들어간다고 떠올린 세 항목만 더한 값입니다.
두 실행은 각각 53점을 냈습니다. 방향이 반대였습니다. 기능 충족도 20점과 실적 5점, 두 항목만 빼고 나머지를 전부 정성 배점으로 셌습니다. 78에서 25를 뺀 53이죠. 읽어 보니 말이 되는 해석이었습니다.
저는 더해서 셌고, 실행들은 빼서 셌습니다. 틀린 건 숫자가 아니라 제 기준이었습니다. ‘정성 배점’이라는 말만 있고, 무엇을 넣고 무엇을 빼는지는 어디에도 안 적혀 있었습니다.
그래서 정의를 적었습니다. 빼는 항목 두 종류를 명시했죠. 이제 맞겠지 하고 다시 돌렸습니다. 세 번의 셈을 같은 막대에 얹으면 이렇게 됩니다.
적은 정의대로 세면 53점입니다. 그런데 다시 돌린 실행은 45점을 냈습니다. 이 실행에는 가상 회사 정보를 채워 넣었는데, ‘수행 조직 및 인력’ 8점을 정성으로 보지 않고 자격을 확인하는 점수로 봤습니다. 정의를 더 조인다고 풀릴 문제가 아니었습니다. 두 해석 다 방어가 되거든요.
되돌린 결정: 정의를 조이는 대신 계산식을 드러내게 했습니다
한 번 조여 보고 방향을 바꿨습니다. 정의를 더 촘촘히 쓰는 대신, 에이전트가 숫자를 낼 때 어떤 항목을 뺐는지 식으로 적게 했습니다. 45점을 낸 실행의 보고는 이랬습니다.
정성 = 78 − 기능 요구사항 충족도 20 − 유사사업 실적 5 − 수행 조직 및 인력 8 = 45
숫자가 흔들리는 걸 막지는 못합니다. 저도 45와 53 중 하나를 정답으로 못 박지 않았습니다. 대신 읽는 사람이 “수행 조직을 왜 뺐지?”를 바로 판단할 수 있습니다. 숫자 하나만 있으면 그 질문을 떠올리기 어렵습니다.
식을 적게 한 실행에서 경계가 하나 더 보였습니다. 이 에이전트는 배점 중 전략으로 대응하지 못한 점수도 함께 보고하는데, 그 실행이 가격 20점을 거기에 넣었습니다. 그렇게 세면 ‘대응 못 한 점수 0점’이라는 목표는 영원히 못 채웁니다. 가격은 제안서 문장으로 대응하는 점수가 아니니까요.
같은 형태가 기록물 에이전트에서 한 번 더 있었습니다. “보존기간 재검토 후보”를 올리라고만 했더니 8건 중 7건을 후보로 올렸습니다. 무엇을 후보로 올릴지를 제가 안 정했거든요. “성격과 보존 연수가 명백히 어긋나는 것만 후보”라고 한 줄 넣자 후보가 2건으로 줄었습니다. 여기서 고친 것은 제 지시이지 정답지가 아닙니다. 정답지의 2건은 실행 전에 적어 둔 값 그대로입니다.
측정 표준은 계산식을 적으라고 이미 요구하고 있었습니다
돌이켜 보면 새 문제가 아니었습니다. 무언가를 세서 판단에 쓰는 일은 소프트웨어 공학에서 표준으로 정리돼 있습니다. 측정 프로세스 표준인 ISO/IEC/IEEE 15939(2017년 판)입니다.
이 표준은 측정을 지표 고르기부터 시작하지 않습니다. 먼저 “무엇을 알고 싶은가”라는 정보 요구를 세우고, 거기서 무엇을 잴지를 거꾸로 정합니다. 그리고 재는 값을 두 층으로 나눕니다. 속성 하나를 정해진 방법으로 센 기초 측정치, 그리고 기초 측정치 둘 이상을 결합해서 만든 파생 측정치입니다. 둘을 잇는 계산을 측정 함수라고 부릅니다.
제 정답지에 대입하면 항목별 배점은 기초 측정치고, ‘정성 배점’은 파생 측정치입니다. 그러니 정성 배점에는 어떤 항목을 더하고 빼는지, 즉 측정 함수가 따라붙어야 했습니다. 저는 이름만 적고 함수는 안 적었습니다.
사람 채점자 둘에게 “정성 배점을 세 주세요”라고 했다면 한 사람이 “수행 조직도 넣어요?”라고 물었을 가능성이 큽니다. 사람끼리도 말없이 갈리는 일은 흔하지만, 되물을 기회가 있으니 함수가 문서에 없어도 대화가 그 빈자리를 메울 여지가 있었습니다.
이번에 돌린 에이전트들은 묻지 않았습니다. 방어가 되는 해석 하나를 골라서 끝까지 일관되게 적용했습니다. 그래서 결과가 틀려 보이지도 않았습니다. 53점도 45점도 근거가 있는 숫자입니다. 수행자가 사람에서 에이전트로 바뀌면, 오래전부터 표준에 있던 ‘측정 함수를 적는다’는 요구가 선택이 아니게 됩니다.
정답지와 어긋날 때 의심하는 순서를 바꿨습니다
저는 골든런을 에이전트 시험이라고 생각했습니다. 네 번을 겪고 나니 절반은 제 기준의 시험이었습니다. 제가 쓴 지시가 한 가지 답만 허용하는지를 보는 시험이죠.
첫 단계에는 조건이 붙습니다. 같은 모델에 같은 지시로 돌린 두 실행은 서로 독립된 증인이 아닙니다. 같은 쪽으로 기울 수 있습니다. 그래서 두 실행이 같다는 건 정답지를 다시 볼 이유일 뿐, 정답지가 틀렸다는 증거는 아닙니다. 확인은 늘 원자료로 합니다.
아직 남은 문제: 합성 자료였고, 정답지와 기준을 같은 사람이 썼습니다
전부 합성 자료로 돌린 결과입니다. 실제 회의록, 실제 공고문으로 사람이 끝까지 돌려 본 적은 아직 없습니다. 합성 자료는 제가 함정을 아는 자료라서, 제가 모르는 종류의 애매함은 여기서 안 나왔을 겁니다.
정답지를 쓴 사람과 기준을 쓴 사람이 같다는 것도 남아 있습니다. 둘 다 저입니다. 요일을 틀린 사람이 요일 계산 기준도 썼죠. 이번엔 두 실행의 일치가 그 사각지대를 비춰 줬지만, 두 실행이 같이 틀리는 경우는 이 방법으로 못 잡습니다.
마치며: ‘에이전트가 맞췄나’가 아니라 ‘내 기준이 한 가지 답만 허용하나’
세는 칸에는 계산식이 붙어 있어야 했습니다. 이름만 적힌 기준은 사람 사이에서는 대화로 버텼지만, 묻지 않는 에이전트 앞에서는 실행마다 다른 숫자가 됩니다.
이름만 적힌 기준은 사람 사이에서는 대화로 버텼지만, 묻지 않는 에이전트 앞에서는 실행마다 다른 숫자가 됩니다.
에이전트 결과를 채점하고 계시다면, 채점표에서 ‘몇 개’, ‘몇 점’, ‘비율’이 들어간 칸을 하나 골라 그 옆에 계산식을 한 줄로 적어 보시길 권합니다. 무엇을 더하고 무엇을 빼는지 안 써지면, 그 칸은 에이전트가 돌 때마다 다른 숫자를 낼 자리입니다. 아직 에이전트를 쓰지 않더라도 평가표나 요구사항 문서의 숫자 칸에 똑같이 해 볼 수 있습니다. 팀이라면 숫자 칸 목록을 먼저 뽑고 칸마다 담당을 붙이는 편이 빠릅니다. 식이 안 써지는 칸이 곧 합의가 빠진 칸이니까요.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- ISO/IEC/IEEE 15939:2017 Systems and software engineering, Measurement process: https://www.iso.org/standard/71197.html