AI와 함께 일하기 ② — Rule에 넣어야 하는 것과 넣지 말아야 하는 것
2026-08-29
저는 지난 편에서 업무 규칙을 대화가 아니라 파일에 저장한다고 말씀드렸고, 그 파일을 "Rule"이라고 부릅니다.
그런데 Rule을 만들고 나서도 같은 문제가 한 번 더 왔습니다. 적어 두었는데 지켜지지 않았습니다.
저는 문장이 모호해서라고 판단하여 더 또렷하게 다시 썼습니다. 예를 들어 "값을 함부로 바꾸지 않는다"를 "값을 바꾸기 전에 그 값이 적힌 다른 자리를 먼저 찾는다"로 고치는 식이었습니다.
그래도 같은 일이 되풀이됐습니다. 한번은 같은 날짜가 네 군데에 적혀 있었는데 그중 두 곳만 고쳐진 채로 하루가 지나갔고, 규칙에는 "먼저 찾는다"고 분명히 적혀 있었는데도 그랬습니다.
그러다 다섯 번째로 같은 계열의 문제를 겪고 나서야 이유가 보였습니다. Rule이 지켜지지 않아도 아무 일이 일어나지 않았기 때문입니다. 규칙은 있었는데 어긴 것을 잡아내는 장치가 없었던 것입니다.
그때부터 저는 규칙을 적을 때 세 가지를 함께 적습니다.
발동 지점 — 언제 이 규칙이 걸리는가를 적습니다. "항상"은 발동 지점이 아니며, "값을 바꾸기 직전"처럼 시점이 분명해야 합니다.
멈추는 것 — 어기면 무엇이 실제로 멈추는가를 적습니다. 사람이 알아채는 것 말고, AI 검증을 통해 멈추게 하는 것을 적어야 합니다.
양성 대조 — 일부러 어겨 보고 정말 멈추는지 확인합니다. 이 절차를 생략하면 "통과"의 뜻이 두 가지가 되어, 위반이 없어서 통과인지 그 검증이 아무것도 못 재서 통과인지 구분할 수 없습니다.
예를 들면 이렇게 적습니다.
규칙 — 값을 바꾸기 전에 그 값이 적힌 다른 자리를 먼저 찾는다
발동 지점 — 숫자·날짜·이름을 고치려고 파일을 여는 순간
멈추는 것 — 같은 값을 찾는 검증이 두 곳 이상에서 다른 값을 보면 선다
양성 대조 — 한 곳만 일부러 고쳐 두고 검증을 돌려, 정말 서는지 본다
세 가지가 채워지고 나서야 이 규칙이 실제로 지켜지기 시작했는데, 문장 자체는 그 전과 거의 같았습니다.
나중에 알았는데 제가 새로 생각해 낸 방식이 아니었습니다. 소프트웨어 쪽에는 지켜야 할 조건을 주석이 아니라 실행 중에 검사되는 문장으로 적고, 어긋나면 프로그램을 그 자리에서 멈추게 하는 계약에 의한 설계(Design by Contract)가 1992년에 이미 정리되어 있었습니다(Bertrand Meyer, IEEE Computer). 제가 한 일은 그것을 코드가 아니라 업무 규칙에 옮겨 적은 것이었습니다.
실제로 이렇게 걸린 적이 있습니다. 제가 싫어해서 쓰지 말자고 정해 둔 낱말이 하나 있었는데, 그 목록이 다른 문서에 따로 있다 보니 문안을 짓는 쪽에서 그 목록을 열지 않았고, 그 낱말은 시안과 검토와 승인을 차례로 지나 홈페이지 화면에까지 올라갔습니다. 규칙은 진작 있었고 아무도 어긴 적이 없다고 여겼는데, 실은 아무도 그것을 재지 않았을 뿐이었습니다. 그래서 목록을 한곳으로 모으고, 배포본을 만들 때 사람이 보게 될 화면에서 그 낱말을 세게 한 다음, 하나라도 나오면 만들기가 서게 했습니다. 일부러 그 낱말을 넣어 정말 서는지 보았고, 대신 쓰기로 한 말은 걸리지 않는지도 함께 보았습니다 — 그것까지 막으면 고칠 길이 없어지기 때문입니다.
그리고 이 세 가지를 함께 적을 수 없을 때는 규칙을 적지 않습니다. 대신 검증 규칙을 먼저 만들고, 그것도 지금 못 만들면 "못 만들었다"를 미해결로 남겨 둡니다. 규칙을 어겼을 때 아무 일도 일어나지 않으면, 그건 사람이 잘못 작성한 규칙입니다.
적지 않는 것도 정했습니다. 한 번만 쓰는 지시는 Rule에 넣지 않는데, 지시는 그 일이 끝나면 낡는 반면 파일에 들어간 문장은 낡아도 계속 읽히기 때문입니다. 되풀이되는 판단만 Rule로 등록합니다.
지금 AI에게 주고 계신 지시문에서 한 줄을 골라, 그 아래에 세 가지를 채워 보십시오. 발동 지점은 언제이고, 어기면 무엇이 멈추며, 일부러 어겨 보면 정말 멈추는가.
세 번째에서 막히면 그 줄은 아직 규칙이 아닙니다. 저는 그런 줄을 지우지 않고 "미해결"로 표시해 두는데, 표시해 두면 다음에 방법이 생겼을 때 그 자리에 채워 넣게 되기 때문입니다.
이 규칙을 세운 것도 PG 북스튜디오를 개발하면서였습니다.
다음 편에서는 창을 오래 열어 둘 때 무엇이 흐려지는지 적겠습니다.
출처 — Bertrand Meyer, Applying "Design by Contract" (IEEE Computer, 1992) · https://se.inf.ethz.ch/~meyer/publications/computer/contract.pdf