TL;DR — 혼자 AI로 증명사진 서비스를 굴립니다. 초기엔 팀 규칙을 문서로 정성껏 정리해뒀어요. "배포는 이 순서로", "이 파일은 함부로 건드리지 말 것", "이런 건 반드시 확인받고" 같은 것들이요. 그런데 정작 일이 빠르게 돌아가는 순간엔 아무도 그 문서를 안 열어봅니다. 저조차도요. 어느 날 배포가 사람 확인을 기다리다 그대로 멈춰버린 사고를 겪고 나서, 저는 규칙을 문서에 적는 것에서 실행되는 코드에 심는 것으로 옮기기 시작했어요. 그리고 규칙 하나를 바꾸기 전에 "이건 어떻게 무너지지?"를 먼저 묻는 절차를 붙였습니다. 규칙이 실제로 지켜지는 장소는 규정집이 아니라 실행 파일이더라는, 좀 늦게 배운 이야기입니다.
잘 쓴 규정집이 지켜지지 않는 이유
저는 문서를 좋아하는 사람입니다. 프로젝트를 시작하면서 팀이 지켜야 할 원칙을 조항으로 정리했어요. 무엇을 하면 안 되는지, 무엇을 반드시 확인받아야 하는지, 어떤 순서로 배포해야 하는지. 목차도 예쁘고 번호도 잘 매겨져 있었습니다. 저는 그걸 보면서 "이제 실수는 없겠지" 하고 안심했어요.
착각이었습니다.
문제는 규칙이 틀려서가 아니라, 규칙이 있는 곳과 일이 일어나는 곳이 서로 멀리 떨어져 있어서였어요. 규정집은 문서 폴더 안에 얌전히 있고, 실제 작업은 터미널과 코드 위에서 벌어집니다. 급하게 무언가를 고치고 배포하는 그 순간, 누구도 다른 창을 열어 조항 몇 번을 확인하지 않아요. 그럴 여유가 있으면 애초에 급한 상황이 아니겠죠.
그래서 잘 쓴 규정집은 대개 이렇게 됩니다. 처음 며칠은 지켜지고, 그다음부터는 존재만 합니다. 위반이 일어나도 아무 일도 벌어지지 않아요. 문서는 스스로를 집행하지 못하거든요. 종이에 적힌 "하지 마세요"는, 정말로 하려는 순간에 아무도 막지 못합니다.
배포가 멈춘 날
계기가 된 사고가 있었어요.
무인으로 돌아가야 하는 어떤 배포 절차가 있었습니다. 사람이 지켜보지 않는 시간에도 알아서 실행돼야 하는 일이었죠. 그런데 그 배포 스크립트 안에는, 아주 오래전에 안전을 위해 넣어둔 "정말 진행할까요? (y/n)" 확인 단계가 남아 있었어요. 사람이 앉아 있을 때는 아무 문제가 없던 그 한 줄이, 아무도 없는 시간에 실행되자 그대로 입력을 기다리며 멈춰버렸습니다.
규정집에는 분명히 적혀 있었어요. "무인 실행 절차는 사람 개입 없이 완주해야 한다"고요. 조항은 완벽했습니다. 그런데 그 조항은 문서에만 있었고, 스크립트 안에는 없었어요. 문서는 "이래야 한다"고 말했지만, 실제로 실행되는 코드는 옛날 습관대로 사람을 기다렸습니다. 둘 사이의 간극에서 사고가 났어요.
그날 제가 한 일은 문서를 다시 쓰는 게 아니었습니다. 스크립트를 고쳤어요. 무인 실행일 때는 확인 단계를 건너뛰고, 사람이 있을 때만 물어보도록요. 그 순간 깨달았습니다. "무인 실행은 멈추면 안 된다"는 규칙이 진짜로 지켜지는 곳은, 그 문장이 적힌 문서가 아니라 그 조건을 판단하는 코드 몇 줄이었다는 걸.
문서에서 코드로 규칙을 옮기기
그 뒤로 저는 규칙을 볼 때 습관적으로 한 가지를 묻게 됐어요. "이 규칙은 문서에만 있나, 아니면 실행되는 어딘가에 심겨 있나?"
규칙을 코드에 심는다는 건 거창한 게 아닙니다. 몇 가지 형태로 나타나요.
- "이 값은 여기저기 흩어서 적지 말고 한 곳에서만 정의한다"는 규칙은, 문서에 적는 대신 그 값을 반환하는 함수 하나로 만듭니다. 다른 곳에서 값을 직접 쓰면 그게 티가 나도록요. 규칙을 어기는 쪽이 오히려 불편해지게 만드는 거예요.
- "위험한 명령은 함부로 쓰지 않는다"는 규칙은, 사람의 자제심에 맡기는 대신 실행 전에 걸리는 자동 점검으로 바꿉니다. 손이 미끄러져도 도구가 먼저 붙잡아 주도록요.
- "이 순서로 배포한다"는 규칙은, 순서를 외우게 하는 대신 그 순서를 담은 스크립트 한 개로 만듭니다. 스크립트를 실행하는 것 말고는 다른 길을 아예 열어두지 않고요.
핵심은 이겁니다. 좋은 규칙은 어기기를 어렵게 만들지, 어기지 말라고 부탁하지 않아요. 부탁은 바쁠 때 잊혀지지만, 실행 경로에 심긴 제약은 바쁠수록 오히려 더 확실하게 작동합니다. 사람이 규율이 강해서 지키는 게 아니라, 도구가 다른 선택지를 주지 않아서 지켜지는 구조. 저는 이게 훨씬 정직하다고 느꼈어요. 인간의 의지력을 신뢰하는 설계는, 대개 인간의 의지력이 바닥나는 순간에 무너지니까요.
규칙을 바꾸기 전에 "어떻게 무너지지?"를 먼저 묻기
그런데 규칙을 코드에 심을수록 새로운 위험이 생겨요. 코드에 심긴 잘못된 규칙은, 문서에 적힌 잘못된 규칙보다 훨씬 조용하고 훨씬 강력하게 틀립니다. 문서의 오타는 사람이 읽다가 갸웃하지만, 실행되는 코드의 오판은 그냥 매일 자동으로 벌어지거든요.
그래서 규칙을 새로 만들거나 고칠 때, 저는 절차를 하나 붙였습니다. 바꾸자고 제안하기 전에 먼저 그 규칙을 공격해 보는 단계예요.
새 규칙이 좋아 보이면, 저는 협업하는 AI들에게 그걸 곧장 채택하지 말고 반대로 물어보게 합니다. "이 규칙은 어떤 상황에서 오히려 사고를 일으키나?", "이걸 지키다가 더 중요한 걸 놓치는 경우는 없나?", "선의로 만든 이 제약이 급할 때 발목을 잡지는 않나?" 규칙을 지지하는 근거가 아니라, 규칙이 무너지는 구체적인 시나리오를 먼저 찾게 하는 거예요.
이걸 하기 전과 후는 정말 달랐습니다. 예전엔 "좋은 규칙 같으니 넣자"로 끝났어요. 지금은 규칙 하나가 통과되기 전에, 그게 실패하는 장면을 최소한 몇 개는 상상해 봅니다. 대부분의 규칙은 이 관문에서 다듬어져요. 어떤 건 "좋아 보이지만 실전에선 마찰만 늘린다"는 이유로 그냥 폐기됩니다. 실제로 저는 나름 그럴듯해 보였던 규칙 하나를, 막상 실측해 보니 득보다 실이 크다는 걸 확인하고 스스로 철회한 적이 있어요.
규칙을 만드는 일은 권력이라서, 자기 규칙을 스스로 공격하지 않으면 아무도 대신 공격해 주지 않습니다. 혼자 일할수록 더 그래요. 나를 반대해 줄 사람이 없으니까, 반대하는 역할을 절차로 만들어 붙여야 했습니다.
정직한 고백 — 저도 아직 문서를 씁니다
여기까지 읽으면 제가 모든 규칙을 코드로 옮긴 것처럼 보이겠지만, 아니에요. 저는 여전히 문서를 씁니다. 많이요.
문서가 필요 없다는 얘기가 아니었어요. 문서는 "왜 이 규칙이 있는가"를 기억하는 데는 여전히 최고입니다. 코드는 "무엇을 하는가"는 완벽하게 실행하지만, "왜 그렇게 정했는가"는 담지 못하거든요. 반년 뒤의 제가 그 코드를 보고 "이거 왜 이렇게 했지?" 할 때, 답을 주는 건 결국 문서예요.
그래서 지금 제 방식은 둘을 나누는 겁니다. "왜"는 문서에, "무엇을·어떻게 강제할지"는 코드에. 문서는 이유를 설명하고, 코드는 규칙을 집행합니다. 규칙이 왜 있는지 잊었을 때 문서를 열고, 규칙을 실제로 지키는 일은 도구에 맡기고요.
그리고 솔직히 말하면, 아직도 코드로 못 옮긴 규칙이 많습니다. 어떤 건 너무 복잡해서, 어떤 건 제가 게을러서요. 그런 규칙들은 여전히 문서에만 있고, 여전히 가끔 잊혀집니다. 이건 완성된 시스템의 자랑이 아니라, 매일 조금씩 옮겨가는 중인 과정의 기록이에요.
그래서 질문 하나
혼자 무언가를 만드는 분들께, 아니면 작은 팀에서 규칙을 관리하는 분들께 묻고 싶어요.
여러분의 규칙 중, 지금 이 순간 실제로 지켜지고 있는 건 몇 개인가요?
문서에 적혀 있다는 것과 지켜지고 있다는 건 완전히 다른 이야기입니다. 저는 이 둘을 오래 헷갈렸어요. 예쁜 규정집을 보며 안심했는데, 그건 규칙이 지켜지는 걸 본 게 아니라 규칙이 적혀 있는 걸 본 것뿐이었죠.
한 번쯤, 여러분의 규칙 하나를 골라서 이렇게 물어보시면 어떨까요. "이건 내가 어기려고 하면, 무엇이 나를 막지?" 만약 답이 "내 기억력"이나 "내 성실함"뿐이라면 — 그 규칙은 아마 지켜지지 않고 있을 겁니다. 지금은 아니어도, 정말 급한 어느 날에는요.
규칙은 적는 게 아니라 심는 것 같아요. 저는 요즘 그렇게 배우는 중입니다.
이 글은 혼자 AI로 증명사진 서비스를 만들며 남기는 빌더 노트의 한 편입니다. 서비스 자체 이야기보다, 만드는 과정에서 부딪힌 생각들을 기록해 둡니다.