대기업용 AI 도입 플레이북을 그대로 따라 하면 안 되는 이유

플레이북 항목 열 개 가운데 여섯을 안 하기로 했습니다. 그 여섯의 이유를 적었습니다.

AI 도입 사례를 찾아보면 대부분 사람이 백 명쯤 되는 회사 이야기입니다. 릴리스 매니저가 따로 있고, 정책을 관리하는 담당자가 있고, Jira와 ServiceNow가 돌아갑니다.

우리 회사에는 그중 하나도 없습니다.

얼마 전 우리는 Anthropic이 낸 AI-Native SDLC Playbook을 펴 놓고, 거기 나온 항목을 우리 작업 환경과 하나씩 맞춰 봤습니다. 항목마다 할지 말지를 정했더니 열 개 중 여섯 개가 "안 한다"로 나왔습니다. 이 글은 그 여섯 개의 이유에 관한 것입니다.

플레이북이 요구하는 것

플레이북은 소프트웨어를 만드는 과정을 여섯 단계로 나눕니다. 계획, 설계, 구현, 테스트, 배포, 유지. 각 단계가 다음 단계에서 읽을 문서를 하나씩 남기고, 그 문서가 이어지면서 누가 무엇을 요청했고 누가 승인했는지의 기록이 됩니다.

여기에 장치가 붙습니다. 회사 규약을 담아 두면 AI가 알아서 참고하는 규약 묶음 (스킬), 하면 안 되는 일을 기계적으로 막는 차단 장치(훅), 그리고 설정을 하나 고쳤을 때 나머지가 망가졌는지 확인하는 회귀 검사(evals)입니다.

좋은 문서입니다. 문제는 규모에 따라 무엇을 건너뛰라는 말이 없다는 것입니다. 적어도 우리가 읽은 판본에는 없었습니다. 아래 판단은 모두 우리 것이고, 틀리면 우리 책임입니다.

우리가 안 하기로 한 여섯 개

가장 크게 뺀 것은 문서 단계입니다. 플레이북은 의도서와 설계서와 구현 계획서를 따로 씁니다. 단계마다 서명하는 사람이 다르기 때문입니다. 기획 담당이 의도서를 받고, 기술 책임자가 설계서에 서명합니다.

우리는 발의하는 사람과 승인하는 사람과 만드는 사람이 같습니다. 결재란을 셋으로 늘려 봐야 같은 사람이 자기 문서에 도장을 세 번 찍습니다. 그래서 계획서 하나로 합쳤습니다.

배포 승인 게이트도 뺐습니다. 게이트는 다른 사람의 행동을 멈춰 세우는 장치인데, 멈춰 세울 다른 사람이 없습니다. 우리 사이트는 개발 PC 한 대에서 돕니다. 배포하는 사람이 곧 승인하는 사람입니다.

Slack 연동은 채널이 없어서 뺐습니다. 붙이면 값이 나는 이유는 채널에 오간 대화가 그대로 감사 기록이 된다는 데 있는데, 채널이 없으면 그 값이 0입니다.

남은 것들은 배보다 배꼽이 큰 쪽이었습니다. 대표적인 것이 배포 자동화 도구 (GitHub Actions, GitLab Runner 같은 것) 안에 AI 단계를 따로 끼워 넣는 항목입니다.

끼우는 일 자체는 어렵지 않습니다. 어려운 것은 그다음입니다. 그 단계만 쓸 권한을 따로 만들어 관리해야 하고, AI가 내놓은 결과가 틀렸을 때 누가 보고 누가 되돌릴지를 정해 둬야 합니다. 우리 규모에서는 그 관리 비용이 AI가 거기서 벌어 주는 것보다 큽니다.

정기 보안 스캔과 배포 지표 측정도 같은 계산이었습니다. 스캔은 결과를 볼 사람이 있어야 살아 있고, 지표는 자동으로 기록되는 곳이 있어야 쌓입니다. 지금 넣으면 아무도 안 보는 보고서와 손으로 적다 마는 숫자가 됩니다.

무엇을 뺄지 정한 기준

기준을 셋 세웠습니다. 우리 규모에서 값이 나는가. 이미 있는 것과 부딪히지 않는가. 절차만 늘어나는 것은 아닌가.

셋째가 방금 그 문서 단계를 떨어뜨렸습니다. 같은 사람이 도장을 세 번 찍으면 일은 그대로고 절차만 늡니다. 둘째는 글 끝에 한 번 더 나옵니다. 우리가 이미 쓰고 있던 장치 둘을 플레이북 용어로 덮어쓰지 않게 막았습니다.

크게 갈라 놓은 것은 첫째였고, 그 첫째가 양날이었습니다.

사람이 하나뿐이라 승인 절차는 값이 나지 않습니다. 그런데 우리가 관리하는 프로젝트는 여덟 개입니다. 여덟 개 중 무엇이 망가졌는지는 사람이 기억으로 덮을 수 있는 범위를 넘습니다.

그래서 결과가 갈렸습니다. 결재에 관한 항목은 전부 떨어지고, 검증에 관한 항목은 전부 붙었습니다. 처음 세운 가설보다 도입하는 쪽이 오히려 많아졌습니다.

작은 회사니까 다 건너뛰어도 된다는 뜻이 아닙니다. 무엇이 작고 무엇이 안 작은지를 따로 세어 봐야 합니다. 우리는 사람 수는 작았지만 관리 범위는 작지 않았습니다.

한 줄로 줄이면 이렇습니다. 사람의 서명은 뺐고, 기계의 차단은 남겼습니다.

승인 절차를 뺀 이유가 서명할 사람이 하나라서였다면, 차단 장치를 남긴 이유는 코드를 건드리는 손이 하나가 아니기 때문입니다. 이제는 AI도 같이 건드립니다. 결재판은 한 사람 몫이면 충분해도, 막아야 할 손은 둘입니다.

넣기로 한 것, 그리고 그게 잡은 것

넣기로 한 것은 넷입니다. 리뷰 기준 문서, 회귀 검사, 서버 감시 기준, 그리고 여러 작업을 동시에 돌릴 때의 규칙. 앞의 셋은 만들어서 돌고 있습니다. 회귀 검사는 지금 열한 개고, 그중 빠른 여섯 건은 이 글을 쓰기 직전에 돌려서 통과하는 것을 봤습니다. 넷째는 아직 문장 하나 적어 둔 수준이라 아래 그림에도 셋만 있습니다.

여섯 단계 위에 얹어 보면 이렇게 갈립니다.

켠 것이 한쪽으로 몰려 있습니다. 앞의 두 단계는 사람이 서명해야 값이 나는 항목이라 우리한테는 의미가 없었고, 뒤로 갈수록 사람이 기억으로 덮을 수 없는 것들이라 전부 붙었습니다.

회귀 검사를 넣은 데에는 앞선 사고가 있었습니다. 다섯 번입니다.

우리가 만든 검사 다섯 개가 전부 "통과"를 보고했고, 다섯 다 아무것도 검사하고 있지 않았습니다.

검사	보고한 것	실제
색 대비 검사기	위반 0건	색의 투명도 값을 버리고 계산하고 있었다. 고쳐서 다시 재니 9건
다이어그램 살균 검사 10종	열 번 모두 "차단됨"	시험 데이터가 입구에서 걸려 본체를 지나간 적이 없었다. 금지 목록에서 항목을 지워도 10종이 그대로 통과했다
작업 차단 장치 6개	아무 경고 없이 통과	6개 중 실제로 동작한 것은 0개였다
AI에게 물어보는 회귀 검사 5건	5건 통과	규약 문서를 통째로 치우고 다시 돌려도 5건이 그대로 통과했다
서버 감시 스크립트	정상	감시할 사건이 0건이라 고장난 부분이 실행조차 되지 않았다

세 번째 줄이 제일 뼈아팠습니다. 우리 규약 문서에는 "운영에 나가 있는 코드는 직접 못 고친다, 장치가 막는다"고 적혀 있었습니다. 그런데 실제로 파일 다섯 개를 직접 고쳤는데 아무 일도 일어나지 않았습니다. 규약과 설정과 실제 동작이 셋 다 어긋난 채로 있었는데 아무도 몰랐습니다.

장치가 잘못 판단하는 줄 알았는데 판단 부분은 멀쩡했습니다. 문제는 그 앞이었습니다.

장치에 정보를 넘기는 방식이 그사이 바뀌어서, 모든 요청이 위쪽 길로만 가고 있었습니다. 아래쪽 길은 한 번도 밟히지 않았습니다. 침묵이 통과로 읽힌 것입니다.

고친 방식은 단순합니다. 설정 파일 안에 한 줄로 박아 뒀던 것을 밖으로 빼서 파일로 만들었습니다. 파일이면 손으로 돌려볼 수 있습니다. 그다음에 걸려야 할 입력과 걸리면 안 되는 입력을 각각 넣어 열여섯 건을 확인했습니다. 무엇이든 막고 보는 장치는 아무것도 안 막는 장치만큼 나쁘기 때문입니다.

자동으로 쓰이는 것만 살아남았습니다

우리는 배운 것을 적는 파일을 두 갈래로 운영하기로 규정해 뒀습니다. 한쪽이 열 건 넘게 쌓이는 동안 다른 쪽은 0건이었습니다.

차이는 의지가 아니었습니다. 살아남은 쪽은 계획을 끝낼 때 자동으로 쓰게 되어 있었고, 죽은 쪽은 사람이 명령을 하나 더 불러야 했습니다. 그리고 아무도 부르지 않았습니다.

그래서 쓰는 시점을 옮겼습니다. 사람이 따로 불러야 하는 방식을 없애고, 코드 검토가 끝나면 자동으로 쓰이게 했습니다. 지금 그 파일은 여든여섯 줄입니다.

규칙을 지킬 의지가 있느냐를 묻지 마시고, 안 지키면 진행이 막히는지를 보십시오. 그 파일이 오래 비어 있었던 이유가 그것뿐입니다.

우리가 처음에 잘못 짚은 것

무엇을 뺄지 정하면서 반대쪽도 적었습니다. "우리한테는 코드를 검사하는 기준이 아예 없다"고요.

막상 만들려고 이미 쓰고 있던 검사 설정을 열어 보니 검사 항목도, 심각도 등급도, 통과 기준도 다 있었습니다. 파일을 안 열어 보고 설명 한 줄만 읽고 판단한 것이었습니다.

그 오판을 지우지 않고 문서에 남겨 뒀더니, 진짜 빈 곳이 어디였는지도 같이 드러났습니다. 항목은 있는데 "무엇을 보면 통과인가"가 없었습니다.

"엣지 케이스를 확인한다" 같은 항목은 사람마다 다르게 판단합니다. 판정할 수 없는 항목만 모아 둔 검사표는 볼 때마다 다른 결과를 냅니다. 그러면 그건 검사가 아니라 그냥 습관입니다.

무엇부터 하면 되나

우리가 권하는 순서는 리뷰 기준 문서를 먼저, 그다음 회귀 검사, 마지막에 서버 감시 기준입니다. 가장 싼 것이 다음 것의 재료를 만들기 때문입니다.

회귀 검사부터 만들면 쓸 재료가 없어서 시나리오를 지어내게 됩니다. 리뷰 기준을 먼저 세우면 실제로 겪은 사고가 파일에 적히기 시작하고, 그것이 회귀 검사의 재료입니다.

그리고 검사를 하나 쓸 때마다 일부러 깨뜨려서 실패가 나오는지 보십시오. 실패가 나오는 것을 한 번도 본 적 없는 검사는 통과만 하는 검사일 수 있습니다. 우리는 이걸 다섯 번 배웠습니다.

플레이북에 없는데 우리에게 필요했던 것

빼기만 한 것은 아닙니다. 두 가지를 더했습니다.

하나는 결정 기록입니다. 플레이북의 문서 사슬은 무엇을 하기로 했는지는 남기지만 왜 그쪽을 골랐는지는 남기지 않습니다. 버린 선택지가 왜 버려졌는지는 대화에만 있고, 대화는 사라집니다. 지금 열두 건 쌓여 있습니다.

다른 하나는 문서와 코드가 어긋났는지 보는 장치입니다. 커밋할 때 문서에 적힌 데이터 구조와 화면 주소를 코드와 맞춰 보고, 어긋나면 커밋을 멈춥니다. 이 글 직전 작업에서도 실제로 한 번 막혔고, 문서를 고치고 나서야 통과했습니다.

아직 정하지 못한 것도 하나 있습니다. 서버 감시에는 원문에 3단계가 있습니다. 이상 징후가 크면 AI가 스스로 수정 요청을 여는 등급입니다.

우리는 이 등급을 넣지 않았고, 언제 열어도 되는지의 기준도 없습니다. 검토 쪽이 충분히 단단해지면 다시 보겠다고 적어 두긴 했는데, 무엇을 보고 단단해졌다고 할지 아직 정하지 못했습니다.

지금 안 하는 것과 영원히 안 하는 것

플레이북을 체크리스트로 읽으면 해야 할 항목이 죽 늘어서고, 그중 절반은 우리 회사에서 아무것도 막지 못하는 절차가 됩니다. 도입에서 진짜 어려운 쪽은 무엇을 켤지가 아니라 무엇을 끌지를 정하고 그 이유를 적어 두는 일입니다.

이유를 적어 뒀기 때문에 조건이 바뀌면 다시 열어 볼 수 있습니다. 배포 서버가 두 대가 되면 승인 게이트를 다시 봅니다. 팀 채널이 생기면 Slack 항목을 다시 봅니다.

같은 판단을 귀사 조건으로 해 보고 싶으시면 연락 주십시오.