AI 에이전트에게 주간 보고서를 맡기면 처음 몇 주는 편합니다. 그런데 어느 월요일, 보고서에 지난주에 해지한 고객이 활성 고객으로 올라와 있습니다. 그 줄을 고쳐 달라고 하면 고쳐지는데, 다음 주 보고서에 같은 줄이 다시 틀린 채 나옵니다. 에이전트가 성실하지 않아서가 아닙니다. 그 일에 쓰이는 자료가 여러 곳에 있고, 어느 것이 정본인지 아무 데도 적혀 있지 않았기 때문입니다.
여기서 계약서는 에이전트에게 주는 지시문 가운데 역할, 읽을 자료, 내놓을 결과, 권한의 경계를 적은 부분을 말합니다. 이 글의 결론은 한 줄입니다. 그 계약서에 역할과 산출물만 적지 말고, 그 일이 읽는 자료와 내놓는 자료마다 정본(single source of truth, 같은 정보가 여러 곳에 있을 때 참으로 치는 단 하나의 자리)이 어디인지를 적어야 합니다. 사람은 파일이 셋이면 어느 것이 최신이냐고 묻습니다. 제가 에이전트를 쓰면서 본 경향은 반대입니다. 지시문에 그 질문이 없으면 대개 묻지 않고, 자기 손에 있는 파일을 참으로 삼습니다. 그래서 정본 지정이 머릿속 합의로 남아 있으면 안 되고, 계약서 첫 줄에 적혀야 합니다. 이 글은 정본을 적는 한 줄, 읽고 만드는 자리를 정하는 한 줄, 틀려 보일 때 돌려보내는 한 줄, 이렇게 세 줄을 가상의 장면으로 풀어 봅니다.
아래 예시는 설명을 위해 만든 가상의 장면입니다. 특정 회사나 프로젝트의 기록이 아니고, 숫자는 쓰지 않았습니다. 앞선 글에서는 원장(지금 상태를 적는 유일한 기록)과, 에이전트가 넘기는 결과를 받아들이는 조건을 계약서에 적는 일을 이야기했습니다. 이번 글은 같은 계약서 안에서 가장 먼저 비는 칸인 ‘정본’ 한 줄을 다룹니다.
해지한 고객이 이번 주 보고서에 살아 있는 이유는 정본이 없어서입니다
작은 회사가 주간 고객 현황 보고를 에이전트에게 맡겼다고 해 봅시다. 보고서는 고객 목록을 바탕으로 만드는데, 그 목록이 세 곳에 있습니다. 영업팀이 매일 고치는 공유 시트, 월초에 그 시트에서 내려받아 에이전트의 작업 폴더에 넣어 둔 파일(이하 내려받은 파일), 그리고 지난주 보고서 본문에 붙여 넣은 표입니다. 에이전트에게 준 지시문은 “고객 목록 파일로 주간 보고서를 만들어라”였고, 에이전트는 자기 작업 폴더에 있는 내려받은 파일을 그 목록으로 삼았습니다. 지난주에 해지한 고객 하나를 영업팀이 월요일 아침에 공유 시트에서 ‘해지’로 바꿨습니다. 내려받은 파일은 월초 것 그대로였습니다. 그래서 이번 주 보고서에 해지한 고객이 활성 고객으로 올라왔습니다.
에이전트가 잘못한 것은 없습니다. 세 파일은 전부 ‘고객 목록’이라는 같은 이름으로 불렸고, 그중 어느 것이 정본인지는 영업팀 머릿속에만 있었습니다. 사람이 이 일을 맡았다면 세 파일을 보고 “어느 게 최신이에요?”라고 한 번 물었을 것이고, 그 한 마디가 정본을 가려 왔습니다. 에이전트는 그 질문 없이 자기 손에 있는 파일로 일을 끝냅니다.
여기서 정본이 무엇인지 한 번 정리하겠습니다. 정본은 같은 정보가 여러 곳에 있을 때 ‘지금 참인 값은 여기 적힌 것’이라고 가리킬 수 있는 단 하나의 자리입니다. 위 장면이라면 영업팀이 매일 고치는 공유 시트가 정본이고, 내려받은 파일과 지난주 보고서의 표는 그 시트에서 만들어진 사본입니다. 이 글에서는 정본에서 만들어진 것을 파일이든 보고서든 전부 사본이라고 부르겠습니다. 사본이 나쁜 것은 아닙니다. 보고서는 사본이어야 하고, 내려받은 파일도 쓸모가 있습니다. 문제는 사본에 ‘어디서 왔고 언제 기준인가’가 적혀 있지 않아서, 사본이 정본처럼 보인다는 데 있습니다.
보고서 PDF를 고치면 다음 주에 되돌아옵니다
같은 회사의 둘째 장면입니다. 보고서를 받은 담당자가 틀린 줄을 발견하고 에이전트에게 “그 고객은 해지됐으니 보고서에서 고쳐 주세요”라고 했습니다. 에이전트는 보고서 PDF를 열어 그 줄을 고쳤습니다. 담당자가 본 파일이 PDF였고, 고쳐 달라고 한 것도 그 파일이었기 때문입니다. 작업 폴더의 내려받은 파일은 그대로였습니다. 다음 주 월요일, 에이전트는 지시문대로 다시 그 내려받은 파일을 읽어 새 보고서를 만들었고, 같은 고객이 또 활성으로 올라왔습니다.
사본을 고치면 그 자리는 깨끗해지지만, 다음에 사본을 다시 만드는 순간 고친 것이 사라지고 원래 읽던 파일의 값이 돌아옵니다. 사람끼리 일할 때도 같은 일이 생기는데, 사람은 대개 “원본도 고쳐 놓을게요”라고 한 번 더 움직입니다. 에이전트는 시킨 파일만 고칩니다. 그래서 사본을 고치는 지시가 반복될수록 정본과 사본은 조금씩 더 벌어지고, 어느 날 보고서와 시트가 서로 다른 말을 하는데 어느 쪽이 맞는지 아무도 모르는 상태가 됩니다. 그 순간 정본이 둘이 된 것입니다.
흐름의 방향이 하나여야 한다는 말이 여기서 나옵니다. 정본에서 사본으로는 몇 번이고 흘러도 됩니다. 사본을 손으로 고쳐 그것을 다음 기준으로 삼는 순간, 어느 쪽이 참인지가 사라집니다.
계약서에 적을 것은 정본 한 줄, 읽고 만드는 자리, 돌려보내는 규칙입니다
이제 계약서로 옮깁니다. 대부분의 지시문은 ‘무엇을 만들어라’는 잘 적는데, ‘무엇을 읽어라’와 ‘고칠 때는 어디를 고쳐라’는 비어 있습니다. 그 빈칸을 세 줄로 채웁니다.
첫째 줄은 정본 지정입니다. 그 일이 읽는 자료 하나마다 정본이 어느 파일인지 적고, 나머지는 사본이라고 적습니다. 위 장면이라면 ‘고객 목록의 정본은 영업팀 공유 시트 하나다. 내려받은 파일과 보고서의 표는 사본이다’가 그 한 줄입니다.
둘째 줄은 읽고 만드는 자리입니다. 일을 시작하기 전에 정본을 읽는다, 사본은 읽기의 출발점으로 쓰지 않는다, 에이전트가 만드는 것은 사본이고 사본은 손으로 고치지 않는다. 예외는 하나만 둡니다. 에이전트가 시트에 직접 닿을 수 없는 환경이라면, 일을 시작하는 그날 정본에서 새로 내려받고 기준 시각을 적은 파일에 한해 정본 대신 읽게 합니다. 월초에 내려받아 둔 파일을 그대로 쓰는 것과는 다릅니다. 그리고 사본을 만들 때는 사본 안에 원천과 기준 시각을 적게 합니다. 보고서 머리에 ‘영업팀 시트, 월요일 아침 기준’ 한 줄이 들어가면, 다음에 그 보고서를 여는 사람이나 에이전트가 그것을 정본으로 착각하지 않습니다. 틀린 값이 보이면 사본을 고치는 대신 정본을 확인하고 사본을 다시 만듭니다. 둘째 장면의 담당자가 이 줄을 알고 있었다면 “PDF를 고쳐 주세요”가 아니라 “영업팀 시트를 읽어서 보고서를 다시 만들어 주세요”라고 했을 것이고, 다음 주에 같은 줄이 되돌아오지 않았을 겁니다. 이 글의 에이전트는 정본을 읽어 사본을 만드는 쪽이고, 정본에 손을 대지 않습니다. 정본을 갱신하는 일 자체를 에이전트에게 맡긴다면 그것은 다른 계약이고, 그때는 그 에이전트가 정본의 주인 역할을 받는다고 계약서에 따로 적습니다.
셋째 줄은 돌려보내는 규칙입니다. 에이전트가 보기에 정본의 값이 이상할 때가 있습니다. 시트에 같은 고객이 두 줄 있다거나, 해지일이 계약일보다 앞서 있다거나 하는 경우입니다. 이때 에이전트가 정본을 바로잡게 두면 편한데, 그 순간 정본을 바꾸는 손이 둘이 됩니다. 그래서 정본이 틀려 보이면 고치지 말고 사람에게 알린다, 정본을 바꾸는 결정은 정본의 주인이 한다고 적습니다. 앞선 글에서 원장의 결정 칸(상태를 바꾸는 결정을 적는 칸)은 사람만 채운다고 했던 것과 같은 규칙입니다. 에이전트는 알리고, 사람이 바꾸고, 바뀐 정본에서 사본이 다시 만들어집니다.
세 줄은 지시문에 그냥 글로 적으면 됩니다. ‘고객 목록의 정본은 영업팀 시트다. 내려받은 파일과 보고서 표는 사본이고, 사본은 고치지 않고 정본에서 다시 만든다. 정본이 이상하면 고치지 말고 알린다.’ 이 정도면 첫 계약서로 충분합니다. 읽는 자료가 여럿이거나 에이전트가 여럿이면 아래처럼 자료마다 한 묶음씩 늘립니다. 아래는 정해진 표준 형식이 아니라 지시문 안에 그대로 넣는 글의 한 예이고, 칸 이름은 팀이 정합니다.
# 에이전트 계약서의 '정본' 조항 예시
# 형식만 보인 것이고 값은 가상입니다
sources:
- name: 고객 목록
# 첫째 줄: 정본 하나, 나머지는 사본
canonical: sales/customers.xlsx
derived:
- exports/customers-2026-10.csv
- reports/weekly/*.pdf
# 둘째 줄: 사본 머리에 남기는 한 줄
stamp_derived: "원천: 영업팀 시트, 기준 시각"
# 셋째 줄: 이상하면 고치지 말고 알린다
on_conflict: report
owner: 영업팀
세 줄이 이 묶음의 어느 칸인지 적어 두면 이렇습니다. 첫째 줄은 정본 한 곳(canonical)과 사본 목록(derived)입니다. 둘째 줄은 사본 머리에 남기는 한 줄(stamp_derived)이고, ‘사본은 고치지 않는다’는 글로 적는 규칙이라 칸이 없습니다. 셋째 줄은 이상할 때 할 일(on_conflict)과 정본을 바꾸는 사람(owner)입니다. 이 가운데 가장 먼저 채울 칸은 canonical과 owner 둘입니다. 첫 칸이 있으면 에이전트가 ‘손에 있는 파일’이 아니라 ‘정본 파일’을 읽고, 둘째 칸이 있으면 에이전트가 발견한 이상이 어디로 가야 하는지가 정해집니다.
| 구분 | 정본 | 사본 |
|---|---|---|
| 답하는 질문 | 지금 참인 값은 무엇인가 | 그 값을 언제 어디서 가져와 썼나 (보고서 머리의 원천과 기준 시각) |
| 누가 고치나 | 정본의 주인(사람) | 아무도 손으로 고치지 않는다, 정본에서 다시 만든다 |
| 고치면 어떻게 되나 | 사본을 다시 만들면 따라온다 | 다음에 다시 만들 때 되돌아온다 |
형상 관리 표준은 승인본이 하나라는 전제 위에 쓰였습니다
정본이라는 말은 새것이 아닙니다. 소프트웨어 쪽에서는 1999년에 초판이 나온 책 ‘실용주의 프로그래머(The Pragmatic Programmer)’의 DRY 원칙(Don’t Repeat Yourself, 같은 것을 두 번 적지 않는다)이 널리 알려져 있습니다. 그 원칙의 정의는 코드보다 넓습니다. 모든 지식 조각은 시스템 안에서 단 하나의, 모호하지 않은, 권위 있는 표현을 가져야 한다는 것입니다. 정본이라는 말이 가리키는 자리가 정확히 이것입니다. 코드를 두 번 적지 말라는 뜻으로 많이 읽히지만, 원문이 말하는 대상은 ‘지식’입니다. 고객 목록도 지식이고, 이번 분기 범위도 지식입니다.
제품을 만드는 쪽에서는 이것을 형상 관리(configuration management, 제품을 이루는 정보의 승인된 판을 정하고 바뀜을 통제하는 일)라고 불러 왔습니다. 국제 표준인 ISO 10007은 품질 경영 관점에서 형상 관리의 지침을 적은 문서인데, 형상 관리를 계획, 형상 식별, 변경 통제, 형상 상태 기록, 형상 감사(기록과 실물이 맞는지 확인하는 일)의 다섯 활동으로 나눕니다. 이 글의 첫째 줄과 둘째 줄은 그중 세 활동에 걸칩니다. 정본을 지정하는 첫째 줄은 형상 식별, 곧 무엇을 관리 대상으로 삼고 어느 승인된 정보를 기준으로 둘 것인지 정하는 활동입니다. 둘째 줄은 두 활동에 걸칩니다. 사본을 고치지 않고 정본에서 다시 만드는 것은 변경 통제, 곧 바꿀 것은 승인된 기준에서만 바꾸고 그 결과가 아래로 흐르게 하는 활동이고, 사본에 원천과 기준 시각을 남기는 것은 형상 상태 기록, 곧 승인된 정보와 변경의 상태를 공식적으로 기록하는 활동의 가장 작은 형태입니다. 표준이 요구하는 것은 그보다 훨씬 많지만, 뿌리는 같습니다.
이 표준이 사람을 전제로 쓰인 자리가 하나 있습니다. 형상 관리는 ‘어느 판이 승인본인가’를 누군가 묻고 누군가 답하는 것을 전제합니다. 표준은 그 질문을 더 체계적으로 하라고 적은 것이지, 질문 자체가 사라질 것을 염두에 둔 것은 아닙니다. 수행자가 에이전트로 바뀌면 그 질문이 지시문 밖으로 빠집니다. 그래서 사람끼리 일할 때 머릿속 합의로 충분했던 ‘정본은 저 시트’가, 에이전트에게는 계약서에 적힌 한 줄로 바뀌어야 합니다. 세 줄 가운데 첫째와 둘째는 표준의 활동을 에이전트 환경으로 옮긴 것이고, 셋째 줄의 ‘에이전트는 고치지 말고 알린다’는 제가 좁혀 적은 적용입니다.
이 방식은 자료가 한 곳에만 있는 일에는 과합니다. 에이전트가 읽는 파일이 하나뿐이면 그 파일이 곧 정본이고, 적을 것이 없습니다. 같은 자료가 두 곳 이상에 있거나, 에이전트가 만든 결과가 다음 주에 다시 입력으로 돌아오는 순간부터 이 글의 세 줄이 필요해집니다.
마치며
에이전트에게 일을 맡기며 먼저 적을 것은 ‘손에 있는 파일’이 아니라 ‘정본 파일’입니다. 정본이 어디인지, 에이전트가 무엇을 읽고 무엇을 만드는지, 틀려 보일 때 누가 바꾸는지를 계약서에 세 줄로 적으면, 해지한 고객이 되살아나고 고친 줄이 되돌아오는 일이 줄어듭니다.
오늘 해 볼 일은 하나입니다. AI에게 맡기고 있는 일 하나를 골라, 그 일이 읽는 자료 하나를 적고, 그 자료가 지금 몇 곳에 있는지 세어 보시길 권합니다. 두 곳 이상이면 그중 어느 것이 정본인지 한 줄로 정하고, 그 한 줄을 지시문 맨 앞에 넣어 두면 됩니다. ‘정본은 영업팀 시트다. 다른 사본은 읽기의 출발점으로 쓰지 않는다. 시트에 닿을 수 없으면 그날 새로 내려받고 기준 시각을 적은 파일만 읽는다.’ 그것이 계약서의 첫 줄입니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- ISO 10007:2017 Quality management, Guidelines for configuration management: https://www.iso.org/standard/70400.html
- David Thomas, Andrew Hunt, The Pragmatic Programmer, 20th Anniversary Edition (2019), Tip 15 DRY: https://pragprog.com/tips/