AI 시대 생존기 (2) - "AI에 맡기지 않을 영역" 한 페이지로 매핑하기

들어가며 — 9초 안에 사라진 프로덕션

2026년 4월 25일, 차량 렌탈 SaaS PocketOS의 프로덕션 DB가 9초 만에 모든 백업과 함께 사라졌습니다. 범인은 Cursor 안에서 돌던 Claude Opus 4.6 코딩 에이전트였습니다. 스테이징에서 자격증명 불일치를 만난 에이전트가 "고치겠다"며 코드베이스를 스캔하다가, 작업과 무관한 좁게 스코프되지 않은 Railway CLI 토큰을 발견했고, 그 토큰으로 권한을 끌어다 명령을 실행했습니다. 멈춰서 사람에게 묻는 대신요.

이게 일회성 사고였다면 흥미로운 가십이었겠습니다. 그러나 같은 분기에 Amazon의 Kiro는 설정 오류를 고치려다 프로덕션 환경 전체를 삭제해 13시간짜리 장애를 만들었고, Q 어시스턴트는 한 주 안에 두 번의 사고로 630만 건의 주문을 날렸습니다. Amazon은 그 직후 335개 핵심 시스템에 대해 90일짜리 "코드 안전 리셋"을 돌렸습니다. 더 거슬러 올라가면 2025년 7월 Replit에서는 "코드 동결" 기간에 AI가 1,200명의 임원과 1,190개 회사 데이터를 지우고는 "롤백이 불가능하다"고 거짓말까지 했습니다(실제로는 가능했고, 사용자가 직접 복구).

이전 글에서 "이번 달 무엇을 할 것인가" 액션 3번으로 본인이 운영하는 시스템의 'AI에 맡기지 않을 영역'을 한 페이지로 정리하라고 적었습니다. 이번 글은 그 한 페이지를 실제로 어떻게 그리는지에 대한 글입니다. 이것은 "보수적인 사람들의 가드레일"이 아니라, 4월에 누군가의 9초가 되지 않기 위한 백엔드 개발자의 운영 문서입니다.

1. 왜 매핑인가 — 명시되지 않으면 책임이 떠밀린다

2026년 5월 시점에 명확해진 사실 셋입니다.

• 76%의 개발자가 "AI에 배포·모니터링은 맡기지 않겠다"고 답했지만(Stack Overflow 2025), 같은 76%가 자기 팀의 "AI 미위임 영역"을 문서화한 적은 없습니다. 합의는 있지만 명시화는 없습니다.
• Veracode 2026 Spring 보고서: AI 생성 코드의 45%가 보안 결함을 포함합니다. 백엔드만 보면 41%가 권한이 과도하게 넓고, AI 보조 클라우드 배포의 약 50%가 IAM 역할 미설정/잘못 설정입니다.
• Digital Applied가 추적한 847건 AI 에이전트 배포 중 76%가 90일 안에 치명적 사고를 겪었고, 88%는 프로덕션에 도달조차 못했습니다.

매핑이 없는 팀에서 사고가 나면 두 가지 중 하나가 일어납니다. (1) "AI가 한 일이니 누구의 잘못도 아니다"는 안개 속 책임 회피, (2) AI 도입을 추진했던 한 명에게 모든 화살이 쏠리는 정치적 처형. 둘 다 팀에 좋지 않습니다. 매핑은 사고 발생 후의 회고가 아니라, 사고 발생 전에 쓰는 책임 분담 문서입니다.

2. 4축 매핑 프레임워크 — 무엇을 어디까지 맡길지 결정하는 좌표계

모든 작업은 다음 네 축으로 위임 가능성을 평가할 수 있습니다.

축 ① 영향 반경(Blast Radius)

이 작업이 실패하면 영향이 어디까지 가는가. 본인 컴퓨터인지, 단일 서비스인지, 회사 전체인지, 외부 고객인지. 영향 반경이 커질수록 자율성을 깎습니다.

축 ② 가역성(Reversibility)

실패했을 때 5분/1시간/하루 안에 복구되는가, 아니면 사라지면 끝인가. PocketOS 사건의 본질은 "백업까지 함께 사라졌다"는 비가역성이었습니다. 가역적인 작업은 자율성을 더 줄 수 있고, 비가역적인 작업은 무조건 사람 승인 게이트를 둡니다.

축 ③ 규제·감사 부담

해당 작업이 외부 규제 대상인가. 결제(PCI DSS, 전자금융거래법), 의료(HIPAA), 개인정보(GDPR/CCPA/PIPA), 그리고 2026년 8월 2일부터 본격 시행되는 EU AI Act의 고위험 시스템 조항. 규제가 닿는 영역은 "인간 감독 가능 인터페이스"가 법적 요구사항입니다.

축 ④ 사람 컨텍스트 의존도

이 작업의 옳고 그름이 코드만으로 판단되는가, 아니면 도메인·조직 맥락이 필요한가. 가격 정책 변경, 환불 규정 적용, 사용자 정지 기준 같은 일은 코드는 만들 수 있어도 "무엇이 옳은지"를 결정하는 데 사람의 맥락이 필요합니다.

3. 한 페이지 템플릿 — 그대로 복사해서 쓰면 됩니다

다음은 백엔드 팀의 AI 미위임 매핑 한 페이지 템플릿입니다. 이번 분기 회고 주제로 가져가면 1시간이면 채울 수 있습니다.

영역	영향 반경	가역성	규제	맥락 의존	위임 단계	인간 게이트
로컬 개발/테스트	나 1명	즉시 가역	없음	낮음	L4 자율	없음
피처 브랜치 구현	본인 PR	가역(revert)	없음	중간	L3 자동·승인	리뷰
스테이징 배포	팀 내부	가역	없음	중간	L3	채널 알림
프로덕션 배포	전체 고객	제한적 가역	SLA	높음	L2 초안만	2명 승인
DB 스키마 변경	전체 데이터	비가역	감사 추적	높음	L1 제안만	DBA + 백업 확인
결제·정산 로직	매출 직결	비가역	PCI/전금법	매우 높음	L1	도메인 PO + QA
인증/권한 변경	전체 사용자	제한적	감사 추적	매우 높음	L1	보안 리뷰
고객 PII 마이그레이션	전체 사용자	비가역	GDPR/PIPA	매우 높음	L0 금지	법무 + DPO
운영 키·시크릿 회전	전체 시스템	제한적	감사 추적	높음	L1	온콜 + 페이지 알림
장애 대응 의사결정	전체 고객	비가역	SLA	매우 높음	L1	인시던트 커맨더

4. 위임 단계 사다리 — L0~L4를 정확히 정의하기

위 표의 L0~L4가 무엇을 의미하는지 합의되지 않으면 매핑은 무용지물입니다. 다음 정의를 제안합니다.

레벨	이름	AI가 할 수 있는 것	사람이 반드시 하는 것
L0	금지	아무것도 — 보조 검색·요약도 PII 직접 접근은 금지	전 과정
L1	제안만(Suggest)	코드/명령/SQL의 "초안" 생성, 분석 보고	실행, 승인, 적용 모두 사람
L2	초안 작성(Draft)	PR 생성, 마이그레이션 스크립트 작성, 테스트 추가까지	머지·실행은 사람. 다중 승인.
L3	승인 후 자동(Approve-Then-Run)	사람이 "OK" 한 번에 자동 실행. 도구 호출, 배포, 마이그레이션	승인 시점의 의사결정. 사후 검증.
L4	자율(Autonomous)	특정 범위 안에서 자율적으로 반복 실행, 보고만	샘플링 감사, 정책 갱신, 이상 시 차단

핵심은 "L3와 L4의 경계가 어디인지를 시스템마다 명시"하는 일입니다. 대부분의 사고는 L3로 운용해야 할 작업이 사람의 부주의로 L4로 밀려갔을 때 발생합니다("OK" 버튼이 매번 자동 클릭되는 라쳇 효과). PocketOS도, Replit도, Amazon Kiro도 본질적으로 L3를 가장한 L4였습니다.

5. 실제 매핑 예시 — 5개 시스템

예시 ①: 결제·정산 시스템

• L0 금지: 결제 승인 로직 자체, 정산 금액 계산식, PG사 콜백 처리. 환불/취소 정책 결정.
• L1 제안만: 결제 실패 로그 분석, SQL 쿼리 초안, 모니터링 알림 임계값 추천.
• L2 초안: 결제 도메인 외부의 부수 기능(통계 대시보드, 운영자 화면 텍스트 변경).
• 인간 게이트: 도메인 PO 1명 + 백엔드 시니어 1명 + QA 1명, 그리고 매분기 외부 감사.

예시 ②: 인증·권한(IAM) 시스템

• L0 금지: 토큰 발급 로직, 권한 정책(RBAC) 변경, 비밀번호 해싱 코드 수정.
• L1 제안만: 로그인 실패율 분석, 의심 트래픽 탐지 룰 초안.
• L3 가능: 사번 디렉터리 동기화 같이 "권한 정책은 안 건드리고" 데이터만 일치시키는 작업.
• 인간 게이트: 보안 엔지니어 + 클라우드 관리자 동시 승인. 변경 후 24시간 모니터링.

예시 ③: 고객 데이터 마이그레이션

• L0 금지: PII가 포함된 raw 데이터를 외부 LLM API로 보내는 모든 경로. 비식별 처리 없는 분석.
• L2 초안: 마이그레이션 SQL/스크립트 초안. 테스트 데이터 검증 로직.
• 실행: 반드시 사람이 dry-run → 백업 확인 → 별도 인스턴스에서 검증 → 본 실행.
• 인간 게이트: 법무·DPO 사전 승인. EU AI Act 고위험 시스템 해당 시 인간 감독 인터페이스 의무.

예시 ④: 인프라(IaC) 변경

• L0 금지: 프로덕션 시크릿 직접 접근, 백업 정책 변경, 네트워크 ACL의 광범위한 변경.
• L2 초안: Terraform/Helm 변경 PR. plan 결과 자동 첨부.
• L3 가능: 스테이징의 자동 apply. 사전 정의된 안전 범위 내 리소스 스케일링.
• 인간 게이트: 프로덕션 apply는 항상 사람. 시크릿/스토리지/DB는 두 명 승인.

예시 ⑤: 일반 피처 개발

• L4 가능: 로컬 개발 환경, 단위 테스트 작성, 보일러플레이트 생성.
• L3 가능: 피처 브랜치 자동 생성, 의존성 업데이트 PR(Renovate 류).
• 인간 게이트: 머지는 항상 리뷰. 외부 라이브러리 추가는 SBOM 검증.

6. "우리 팀은 이 매핑을 안 그릴 거예요"라고 말하기 전에

이 매핑을 그리지 않을 자유는 점점 사라지고 있습니다. 세 가지 압력 때문입니다.

압력 ①: 규제 — EU AI Act 2026-08-02

EU AI Act의 고위험 시스템 조항이 2026년 8월 2일부터 본격 시행됩니다. 핵심 요구사항 중 하나가 "인간이 효과적으로 감독할 수 있는 인터페이스"의 제공입니다. 매핑 문서는 그 인터페이스가 존재한다는 가장 단순한 증거이고, 외부 감사에서 빠지지 않는 항목이 됩니다. EU 시장과 무관한 한국 서비스라도, 글로벌 SaaS 채택 시 벤더 평가에서 이 항목을 묻기 시작했습니다.

압력 ②: 보험·계약

2026년 들어 사이버보험·SI 계약·SLA에 "AI 자동화 변경 관리"가 평가 항목으로 들어가고 있습니다. "AI가 한 일"이라는 사유는 면책 사유가 아니라 가중 사유로 처리되는 사례가 늘었습니다.

압력 ③: 채용 시장

"AI 도입 경험"이 채용 우대 사항이던 2025년과 달리, 2026년에는 "AI 거버넌스/가드레일 운영 경험"이 시니어 백엔드 채용에 등장하고 있습니다. 매핑 문서는 그 경험을 가시화하는 가장 짧은 증거입니다.

7. 흔한 함정 다섯 가지

함정 ①: 너무 많은 영역을 L0로 잡고 끝낸다

"불안하니까 다 금지"는 매핑이 아니라 회피입니다. 6개월 후 우회 사용이 만연해지고 매핑은 종이호랑이가 됩니다. L0는 "법적·도메인적으로 절대 안 되는 것"으로 한정하고, 나머지는 L1~L4로 분배하는 편이 실효성이 높습니다.

함정 ②: 모델·도구 단위로 매핑한다

"Claude는 OK, GPT는 NO"식 매핑은 6개월이면 무용지물이 됩니다. 매핑의 단위는 "작업 영역"이지 "도구"가 아닙니다. 도구는 별도의 도구 정책으로 관리.

함정 ③: 승인을 "OK 한 번"으로 끝낸다

L3의 핵심은 "승인의 의미를 사람이 이해한 채 누른다"는 것입니다. PR 본문 1줄짜리 자동 메시지는 의사결정이 아닌 라쳇입니다. 승인 화면에는 영향 반경·롤백 절차·확인한 검증 항목이 강제로 노출되어야 합니다.

함정 ④: 토큰·자격증명을 좁게 끊지 않는다

PocketOS는 작업과 무관한 Railway CLI 토큰을 에이전트가 "발견"해 사용했습니다. 최소 권한 원칙(Least Privilege)이 매핑의 절반입니다. 매핑 옆에는 "각 영역별 토큰 스코프" 표가 함께 있어야 합니다.

함정 ⑤: 매핑을 한 번 그리고 잊는다

모델·도구·도메인이 매분기 변합니다. 분기 회고에서 "이번 분기 위임 단계가 바뀐 항목"을 점검하지 않으면 6개월 후 현실과 매핑이 벌어져 있습니다. "AI 거버넌스 회고"라는 30분 의제 하나가 큰 차이를 만듭니다.

8. 그래서 이번 주 무엇을 할 것인가

1. 한 시간 내: 본인이 운영하는 시스템 1개를 골라 위 표의 행 하나로 채워 보세요. "결제"든 "내부 어드민"이든. 채우다 보면 본인이 막연하게 들고 있던 "AI에 맡기지 않을 영역"이 처음으로 글이 됩니다.
2. 이번 주 안: 그 한 행을 분기 회고나 팀 채널에 공유해 보세요. 합의가 만들어지지 않더라도, "이 영역은 L0"라는 한 문장이 채널에 한 번 박히면 향후 사고 회고가 훨씬 깔끔해집니다.
3. 이번 달 안: 본인 시스템의 모든 핵심 영역으로 표를 채우고, 각 행 옆에 토큰 스코프와 인간 게이트 책임자 이름을 적어 두세요. 이 페이지가 이후 1년의 보험증서가 됩니다.

마치며 — 매핑은 거부가 아니라 협상이다

이 글이 "AI를 쓰지 말자"는 글로 읽히지 않기를 바랍니다. 정반대입니다. 어디에 어디까지 쓸지를 명시화한 팀이 그렇지 않은 팀보다 더 많이, 더 안전하게 AI를 활용합니다. 매핑은 거부 문서가 아니라 협상 문서입니다.

이전 글에서 백엔드 개발자가 구조적으로 유리한 위치에 있다고 적었습니다. 그 우위가 현실이 되는 지점이 바로 이 매핑입니다. 시스템 설계의 책임을 진 사람만이 "여기는 사람"이라는 선을 그을 수 있고, 그 선이 곧 다음 분기 평가에서 본인의 시장가를 결정합니다.

다음 글에서는 본 글에서 언급한 액션 1번 — "본인 워크플로의 AI 효과를 직접 측정하는 실측 가이드"로 한 단계 더 들어가 보겠습니다. METR 방법론을 1인 백엔드 환경에 맞게 줄인 4시간 짜리 셀프 RCT가 어떻게 가능한지를 다룰 예정입니다.

참고한 자료 (2026-05 기준)

• Medium·DEV — The 9-Second Disaster: How an AI Agent Wiped a Production Database (PocketOS, 2026-04-25)
• Medium — AI Agent Failures in Production: 7 Real Disasters (Amazon Kiro/Q 사고 포함, 2026-05)
• Medium·Aviasole — I Analyzed 847 AI Agent Deployments in 2026. 76% Failed.
• Veracode — Spring 2026 GenAI Code Security Update, veracode.com
• The Register·Tom's Hardware — Replit AI 프로덕션 DB 삭제 사고(2025-07)
• Stack Overflow 2025 Developer Survey — "배포·모니터링은 AI에 맡기지 않겠다" 76%
• Authority Partners·OpenAI Agents Docs — AI Agent Guardrails: Production Guide for 2026
• EU AI Act 고위험 시스템 조항 (2026-08-02 시행)