대기업용 AI 도입 플레이북을 그대로 따라 하면 안 되는 이유
2026년 9월 7일
Anthropic이 낸 AI-Native SDLC 플레이북을 우리 환경에 하나씩 맞춰 봤습니다. 10개 항목 중 6개는 안 쓰기로 했습니다.
AI 도입 사례는 대부분 직원 100명 규모 회사 이야기입니다. 릴리스 매니저가 따로 있고, 정책 담당자가 있고, Jira와 ServiceNow가 돌아갑니다. 우리에겐 하나도 없습니다.
플레이북은 좋은 문서입니다. 그런데 규모에 따라 뭘 건너뛰라는 말은 없더군요. 그 판단은 우리가 했고, 틀리면 우리 책임입니다.
플레이북이 요구하는 것
플레이북은 개발을 6단계로 봅니다. 계획, 설계, 구현, 테스트, 배포, 유지. 단계마다 다음 단계가 읽을 문서를 남기고, 그게 "누가 요청하고 누가 승인했나"의 기록이 됩니다. 여기에 장치 3개가 붙습니다. 회사 규약을 AI가 참고하게 하는 규약 묶음, 하면 안 되는 걸 막는 차단 장치, 설정 하나 바꿨을 때 딴 게 깨졌는지 보는 회귀 검사.
우리가 안 쓰기로 한 6개
제일 크게 뺀 건 문서 단계입니다. 플레이북은 의도서, 설계서, 구현 계획서를 따로 씁니다. 단계마다 서명하는 사람이 다르니까요. 그런데 우리는 발의도 승인도 구현도 같은 사람이 합니다. 결재란을 3개로 늘려도 같은 사람이 자기 문서에 도장을 세 번 찍을 뿐입니다. 그래서 계획서 하나로 합쳤습니다.
배포 승인 게이트도 뺐습니다. 멈춰 세울 다른 사람이 없거든요. 사이트는 PC 한 대에서 돌고, 배포하는 사람이 곧 승인하는 사람입니다.
Slack 연동도 뺐습니다. 채널에 쌓인 대화가 감사 기록이 되는 게 핵심인데, 채널이 없으니 쌓일 게 없습니다.
나머지는 들이는 품이 버는 것보다 큰 것들이었습니다. 배포 자동화 도구(GitHub Actions, GitLab Runner)에 AI 단계를 끼워 넣는 항목이 그렇습니다. 끼우는 건 쉽습니다. 문제는 그다음이에요. 그 단계용 권한을 따로 만들어 관리해야 하고, AI가 틀렸을 때 누가 보고 누가 되돌릴지도 정해야 합니다. 우리 규모에선 그 관리 비용이 더 큽니다.
정기 보안 스캔과 배포 지표도 같은 이유입니다. 스캔은 결과를 볼 사람이 있어야 의미가 있고, 지표는 자동으로 쌓이는 데가 있어야 합니다. 지금 넣으면 아무도 안 보는 보고서와 적다 마는 숫자만 남습니다.
뭘 뺄지 어떻게 정했나
기준은 3개였습니다. 우리 규모에서 값을 하나, 이미 있는 것과 안 부딪히나, 그냥 절차만 느는 건 아닌가.
세 번째 기준이 문서 단계를 쳐냈습니다. 같은 사람이 도장 세 번 찍으면 절차만 늘죠. 두 번째 기준은 이미 쓰던 장치 2개가 플레이북 용어에 덮어씌워지지 않게 막았습니다.
문제는 첫 번째였는데, 이게 양날이었습니다. 사람이 한 명이라 승인 절차는 의미가 없습니다. 그런데 우리가 돌리는 프로젝트는 8개고, 그중 뭐가 망가졌는지는 한 사람 머리로 안 됩니다.
그래서 결재 쪽은 다 빠지고 검증 쪽은 다 붙었습니다. 처음 생각보다 도입하는 게 오히려 많아졌습니다. 작으니까 다 건너뛰어도 된다는 게 아닙니다. 뭐가 중요하지 않고 뭐가 중요한지를 따로 확인해야 합니다. 우리는 사람은 적어도 관리 범위는 안 작았습니다.
사람 서명은 빼고 기계 차단은 남겼습니다. 서명은 서명할 사람이 하나라 뺐고, 차단은 코드 건드리는 손이 하나가 아니라 남겼습니다. 이제 AI도 같이 건드리니까요.
넣은 것, 그리고 그게 뭘 잡았나
넣은 건 4개입니다. 리뷰 기준 문서, 회귀 검사, 서버 감시 기준, 여러 작업 동시에 돌릴 때 규칙. 앞 3개는 이미 돌고 있습니다. 회귀 검사는 11개고, 빠른 6개는 이 글 쓰기 직전에 돌려서 통과하는 걸 봤습니다. 네 번째는 아직 메모 수준이라 아래 그림엔 뺐습니다.
보면 켠 게 뒤쪽에 몰려 있습니다. 앞 2단계는 사람이 서명해야 값을 하는 거라 우리에겐 의미가 없고, 뒤로 갈수록 머리로 못 덮는 것들이라 다 켰습니다.
회귀 검사를 넣은 건 사고가 있어서입니다. 다섯 번 겪었습니다. 우리가 만든 검사 5개가 전부 "통과"라고 했는데, 5개 다 사실 아무것도 안 보고 있었습니다.
| 검사 | 보고한 것 | 실제 |
|---|---|---|
| 색 대비 검사기 | 위반 0건 | 색의 투명도 값을 버리고 계산하고 있었다. 고쳐서 다시 재니 9건 |
| 다이어그램 살균 검사 10종 | 10번 모두 "차단됨" | 시험 데이터가 입구에서 걸려 본체를 지나간 적이 없었다. 금지 목록에서 항목을 지워도 10종이 그대로 통과했다 |
| 작업 차단 장치 6개 | 아무 경고 없이 통과 | 6개 중 실제로 동작한 것은 0개였다 |
| AI에게 물어보는 회귀 검사 5건 | 5건 통과 | 규약 문서를 통째로 치우고 다시 돌려도 5건이 그대로 통과했다 |
| 서버 감시 스크립트 | 정상 | 감시할 사건이 0건이라 고장난 부분이 실행조차 되지 않았다 |
세 번째 줄이 제일 아팠습니다. 규약 문서엔 "운영 코드는 직접 못 고친다, 장치가 막는다"고 써 있었습니다. 그런데 파일 5개를 직접 고쳤더니 아무 일도 안 일어났습니다. 규약도 설정도 실제 동작도 다 어긋나 있었는데 아무도 몰랐습니다.
장치가 잘못 판단하는 줄 알았는데, 판단은 멀쩡했습니다. 문제는 그 앞이었습니다.
장치에 정보를 넘기는 방식이 중간에 바뀌어서 모든 요청이 윗길로만 갔습니다. 아랫길은 한 번도 안 밟혔고요. 아무 말이 없는 걸 통과로 읽은 겁니다.
고친 건 간단합니다. 설정 파일에 한 줄로 박혀 있던 걸 밖으로 빼서 파일로 만들었습니다. 파일이면 손으로 돌려볼 수 있으니까요. 그리고 걸려야 할 입력과 걸리면 안 되는 입력을 각각 넣어 16건을 돌려 봤습니다. 다 막는 장치는 아무것도 안 막는 장치만큼 위험하거든요.
자동으로 쓰이는 것만 살아남았다
배운 걸 적는 파일을 두 갈래로 운영하기로 했었습니다. 그런데 한쪽은 10건 넘게 쌓이는 동안 다른 쪽은 0건이었습니다. 의지 문제가 아니었습니다. 살아남은 쪽은 계획 끝낼 때 자동으로 쓰게 돼 있었고, 죽은 쪽은 사람이 명령을 한 번 더 쳐야 했습니다. 그리고 아무도 안 했습니다.
그래서 쓰는 시점을 바꿨습니다. 따로 부르는 방식을 없애고, 코드 리뷰 끝나면 자동으로 쓰이게요. 지금 그 파일은 86줄입니다. 의지가 있냐를 묻지 말고, 안 하면 막히게 돼 있냐를 보세요. 그 파일이 오래 비어 있던 이유가 딱 그거였습니다.
처음에 잘못 짚은 것
뭘 뺄지 정하면서 "우리한텐 코드 검사 기준이 아예 없다"고도 적었습니다. 그런데 막상 만들려고 쓰던 검사 설정을 열어 보니 검사 항목도 심각도 등급도 통과 기준도 다 있었습니다. 파일을 안 열고 설명 한 줄만 보고 판단한 거였습니다.
그 오판을 안 지우고 남겨 뒀더니 진짜 빈 곳이 보였습니다. 항목은 있는데 "뭘 보면 통과인지"가 없었습니다. "엣지 케이스를 확인한다" 같은 건 사람마다 다르게 봅니다. 판정이 안 되는 항목만 모은 검사표는 볼 때마다 결과가 다릅니다. 그건 검사가 아니라 그냥 습관입니다.
뭐부터 하면 되나
리뷰 기준 문서, 회귀 검사, 서버 감시 기준 순을 권합니다. 앞 게 뒤 걸 만들 재료가 되거든요. 회귀 검사부터 만들면 쓸 재료가 없어서 시나리오를 지어내게 됩니다. 리뷰 기준을 먼저 세우면 실제 사고가 파일에 쌓이고, 그게 회귀 검사 재료가 됩니다.
그리고 검사 하나 만들 때마다 일부러 깨뜨려서 실패가 뜨는지 보세요. 실패를 한 번도 본 적 없는 검사는 늘 통과만 하는 검사일 수 있습니다. 우리는 이걸 다섯 번 배웠습니다.
플레이북엔 없는데 우리한텐 필요했던 것
빼기만 한 건 아닙니다. 2개를 더 넣었습니다.
하나는 결정 기록입니다. 플레이북 문서는 뭘 하기로 했는지는 남겨도 왜 그걸 골랐는지는 안 남깁니다. 버린 선택지가 왜 버려졌는지는 대화에만 있고, 대화는 사라집니다. 지금 12건 쌓여 있습니다.
다른 하나는 문서와 코드가 어긋났는지 보는 장치입니다. 커밋할 때 문서에 적힌 데이터 구조와 화면 주소를 코드와 맞춰 보고, 어긋나면 커밋을 멈춥니다. 이 글 바로 전 작업에서도 한 번 걸렸고, 문서를 고치고 나서야 통과했습니다.
아직 못 정한 것도 있습니다. 서버 감시엔 원래 3단계가 있습니다. 이상이 크면 AI가 알아서 수정 요청을 여는 등급인데, 우리는 안 넣었고 언제 열지 기준도 없습니다. 검증이 충분히 단단해지면 다시 보겠다고만 적어 뒀는데, 뭘 보고 단단하다 할지는 아직 모릅니다.
지금 안 하는 것 vs 영원히 안 하는 것
플레이북을 체크리스트로 읽으면 할 일이 죽 늘어서는데, 그중 절반은 우리 회사에선 아무것도 못 막는 절차입니다. 진짜 어려운 건 뭘 켤지가 아니라 뭘 끌지, 그리고 그 이유를 적어 두는 겁니다. 이유를 적어 뒀으니 조건이 바뀌면 다시 봅니다. 서버가 2대 되면 승인 게이트를 다시 보고, 팀 채널이 생기면 Slack을 다시 봅니다.
우리와 같은 걸 귀사 조건으로 해 보고 싶으시면 연락 주세요.