출시하고 나서야 어디서 깨지는지 안다 - 배포 전 점검을 프로세스로 옮긴 이유

배포 전 점검은 지금 사람 시간에 값이 붙어 있다. 그 값을 프로세스로 옮기면 남는 것은 무엇을 볼지 정한 표와 언제 멈출지 정한 게이트다. AI 워크플로가 어디서 깨지는지는 대개 출시 후에 드러난다. 배포 전에 노드 단위로 짚는 작업은 존재하지만 컨설팅 계약 형태로만 있고, 워크플로 하나에 시니어 1~2주가 들며, 워크플로가 바뀌면 다시 돌릴 수 없다. 이 글은 그 점검이 왜 비어 있는 자리인지, 규제 시한이 실제로 언제인지, 그리고 점검을 재실행 가능한 실행 한 번으로 옮기면 무엇이 남는지 정리한다.

FDE는 Forward Deployed Engineer의 약자다. Palantir가 만든 직군으로, 제품 엔지니어가 고객사에 들어가 그 회사의 실제 데이터와 업무에 맞게 제품을 붙이고 고치는 일을 한다. 본사에서 만든 것을 그대로 파는 대신 현장에서 마지막 한 겹을 짜맞추는 자리이고, 요즘은 AI 회사들이 같은 이름으로 사람을 뽑는다.

이 프로젝트는 그 일 전체를 옮긴 게 아니다. FDE가 현장에서 하는 일 중 한 조각, 붙이기 전에 무엇이 깨질지 짚어보는 부분만 떼어 에이전트로 만들었다. 2026년 UiPath AgentHack에 제출해 104개국 333편 이상의 제출작 중 Maestro BPMN 부문 3위를 받았고, 코드와 온톨로지는 공개 저장소에 있다.

수상은 이 시리즈의 소재가 아니다. 소재는 그 과정에서 만든 채점 규칙과, 그 규칙이 실제 실행에서 어떻게 작동했는지다.

배포 전 워크플로 점검은 지도 위의 빈칸이다

AI 도입 실패 통계는 이미 익숙하다. MIT NANDA의 「State of AI in Business 2025」는 인터뷰 150건, 설문 350건, 실제 배포 사례 300건을 놓고 생성형 AI 파일럿의 95%가 프로덕션에 도달하지 못한다고 봤다. RAND는 AI 프로젝트의 80.3%가 목표한 비즈니스 가치에 못 미친다고 보고했고, Gartner는 2025년 말까지 생성형 AI 프로젝트의 30%가 개념검증 단계 이후 폐기될 것으로 예측했다.

숫자가 가리키는 것은 실패율이 아니라 실패가 드러나는 시점이다. 파일럿을 돌릴 때는 아무 일도 안 일어난다. 프로덕션에 붙이고 나서 나타나고, 그때가 고치는 값이 가장 비싼 시점이다.

배포 전에 짚는 도구가 없지는 않다. 다만 전부 다른 칸에 있다.

도구 유형	대표 사례	보는 층위	시점
인시던트 데이터베이스	AIID, OECD AIM, MIT AI Risk Repository	사건 사례	사후
거버넌스 SaaS	Credo AI, Holistic AI	도입된 시스템 모니터링	배포 후
프로세스 마이닝	Celonis 계열	프로세스 효율	상시
AI 레드팀	Lakera 계열	모델과 프롬프트	배포 전
컨설팅 진단	Big 4, McKinsey QuantumBlack 계열	워크플로	배포 전

인시던트 데이터베이스는 정책 결정자와 연구자를 위한 것이라 “우리가 이 개념검증을 해도 되나”에 바로 답하지 않는다. 거버넌스 SaaS는 이미 돌아가는 시스템을 관측한다. 레드팀은 모델과 프롬프트를 때리지 워크플로를 보지 않는다. 배포 전에 워크플로 층위를 짚는 칸은 컨설팅 하나가 채우고 있다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    subgraph Pre["배포 전"]
      A["모델·프롬프트<br/>레드팀"]
      B["워크플로 층위<br/>컨설팅 진단만"]
    end
    subgraph Post["배포 후"]
      C["시스템 모니터링<br/>거버넌스 SaaS"]
      D["사건 기록<br/>인시던트 DB"]
    end
    A --> C
    B --> C
    C --> D

이 칸이 오래 비어 있던 이유

칸이 비어 있는 것과 아무도 시도하지 않은 것은 다르다. 이 자리를 채우려면 세 가지가 동시에 필요한데, 각각 주인이 다르다.

첫째, 판단 규칙이 문서로 나와야 한다. 컨설턴트가 워크플로를 보고 “이 노드가 위험하다”고 말할 때 쓰는 기준은 대개 머릿속에 있다. 표로 만들면 다시 돌릴 수 있게 되지만 동시에 청구 근거가 사라진다. 규칙을 가진 쪽에 규칙을 꺼낼 이유가 없다.

둘째, 사고 데이터가 노드 단위로 정리된 적이 없다. AIID는 사건 단위로, OWASP Top 10은 취약점 유형 단위로, MITRE ATLAS는 공격 기법 단위로 쌓인다. “문서 추출 노드”나 “자동 승인 노드” 같은 워크플로 구성 요소를 기준으로 정렬된 것은 없다. 노드 단위로 쓰려면 세 체계를 각각 노드 유형에 다시 붙여야 하고, 이 작업이 이 프로젝트에서 실제로 가장 오래 걸렸다.

셋째, 규제 해석과 워크플로 설계가 만나는 자리다. 규제 자문은 조항을 읽고 아키텍트는 노드를 그린다. 둘을 같은 표에 올려야 “이 노드가 어느 조항에 걸린다”가 나오는데, 그 표를 누가 유지할지가 애매하다. 규제는 계속 바뀌고, 바뀔 때마다 표를 손봐야 한다.

사고는 공격자 없이 난다

빈칸을 채우려면 무엇을 기준으로 채점할지부터 정해야 한다. 그래서 2025년 12월부터 2026년 6월 사이에 확인된 사건을 모아 각 셀에 붙였다. 여섯 건이 남았고, 그중 다섯 건에 공격자가 없었다.

아마존웹서비스의 코딩 에이전트 Kiro가 라이브 환경을 삭제 후 재생성해야 한다고 판단하고 실행해 중국 리전 Cost Explorer가 약 13시간 멈췄다. 아마존은 “AI가 아니라 잘못 설정된 접근 권한, 즉 사용자 실수”라고 반박했지만, 사후 조치로 AI 보조 변경 작업에 시니어 엔지니어 승인 절차를 붙였다. AIID 사건번호 1442.
웨이모는 정지한 스쿨버스를 지나칠 수 있는 소프트웨어 결함으로 차량 3,067대를 리콜했다. 오스틴 교육구는 2025~2026학년도에 불법 추월 약 20건을 기록했는데, 그중 한 건은 웨이모가 문제를 고쳤다고 밝힌 뒤에 났다.
아마존 리테일에서는 내부 위키의 운영 지침을 꺼내주는 AI 에이전트가 오래된 참조를 물어왔고, 3월 한 주에 고심각도 사고 네 건이 났다. 하나는 여섯 시간 이어졌다. 사람이 루프 안에 있었는데도 그 조언대로 움직였다.
바이두 아폴로 고는 2026년 3월 31일 우한에서 규제 당국이 확인한 사고를 냈고, 4월 29일 전국 운행 허가가 정지됐다.
시어스 홈 서비스에서는 AI 어시스턴트의 대화 로그와 통화 녹음 370만 레코드, 4.3TB가 노출됐다. AI 노드의 로그가 그 노드를 지나간 모든 입력의 민감도를 그대로 물려받는다는 걸 보여준 사건이다.
PocketOS에서는 코딩 에이전트가 9초 만에 프로덕션 데이터베이스를 지웠다. 같은 볼륨에 있던 백업까지 함께 날아갔고, 사용된 것은 커스텀 도메인 관리용으로 발급된 토큰이었다.

여섯 건이 남기까지의 과정을 숫자로 적으면 이렇다. 2023년 9월부터 2026년 5월 사이에 공개 채널에 보고된 AI 인시던트는 7,246건이다. 그중 프로덕션 시스템의 실제 피해로 검증된 것은 344건, 4.7%다. 그 344건 중 188건에 공격자가 없었다. 검증된 사고의 절반이 넘는다. 마지막으로 1차 보도와 AIID 등재를 기준으로 개별 재검증해 셀에 붙인 것이 여섯 건이다. 손해는 에이전트가 시킨 일을 사람이 개입할 수 있는 속도보다 빠르게, 되돌릴 수 없을 만큼 넓은 권한으로 수행하면서 났다. OWASP와 MITRE ATLAS는 둘 다 공격자를 전제하고 만든 체계다. 과도한 권한 문제를 보안 축에 두면 완화책이 적대적 통제 쪽으로 잘못 배정된다.

검증에서 떨어뜨린 것도 적어 둔다. “에어캐나다 AI 예약 에이전트가 2026년 1월 승객 약 1,247명을 잘못된 항공편으로 재예약했다”, “클라르나 AI 환불 사고 2026년 2월”, “스텝 파이낸스 AI 트레이딩 에이전트의 무단 이체”. 확인하러 갔더니 넷 다 같은 벤더 마케팅 블로그 한 곳으로 수렴했고 규제기관 기록도 AIID 등재도 언론 보도도 없었다. 에어캐나다에서 실제로 인용 가능한 것은 2024년 2월 브리티시컬럼비아 민사분쟁해결심판소의 Moffatt v. Air Canada 판결(AIID 639)이고, 클라르나는 2025년 5월 사람 상담원 재고용으로 방향을 튼 2024~2025년 이야기다. 비용관리 벤더 블로그에 실린 “폭주 루프로 달러가 샜다”는 사례 네 건도 같은 이유로 뺐다. 피해자가 특정되지 않고 1차 보도가 없다. 패턴 자체는 위 검증 집계로 대체할 수 있으니 굳이 약한 출처를 끌어올 이유가 없다. 전부 저장소에 “확인 실패, 인용 금지”로 사유와 함께 남겼다.

게이트가 아예 없는 조직이 다수다

이 시리즈 전체가 게이트 얘기인데, 그 게이트가 현장에 얼마나 있는지를 잰 조사가 있다. 클라우드 시큐리티 얼라이언스와 Token Security가 2026년 4월에 418개 조직을 대상으로 물었다.

에이전트가 권한 범위를 벗어날 때 사람 승인을 요구하는 조직은 38%다. 나머지 62%에는 그 게이트가 없다. 무단 액션을 자동으로 차단하는 조직은 11%에 그친다.

앞의 사고들과 이 숫자를 겹쳐 놓으면 그림이 맞는다. 아마존웹서비스 사례의 사후 조치가 승인 절차 추가였고, 검증된 사고의 절반 이상에 공격자가 없었다. 막을 수 있었던 것은 방어가 아니라 게이트였는데, 열 곳 중 여섯 곳에는 그 게이트가 없다.

이 점검은 지금 얼마이고, 왜 한 번 쓰고 버려지나

배포 전 워크플로 점검을 실제로 수행하는 쪽은 컨설팅이다. 방식도 정해져 있다. 시니어 컨설턴트가 워크플로 하나를 붙잡고 1~2주를 쓰고, 산출물은 슬라이드 묶음으로 나온다.

항목	지금의 컨설팅 진단	프로세스로 옮겼을 때
시간	워크플로당 시니어 1~2주	실행 1회, 에이전트 구간 약 33초
비용	계약당 수만 달러 단위로 알려져 있음	재실행 한계비용이 0에 가까움
재실행	일회성 산출물, 시간이 지나면 상함	워크플로가 바뀔 때마다 다시 돌림
표준화	컨설턴트마다 다른 기준	같은 입력이면 같은 진단

값은 판단의 정확도가 아니라 사람의 시간에 붙어 있다. 그래서 산출물은 계약이 끝나는 순간 갱신이 멈춘다. 그런데 AI 워크플로는 계약보다 자주 바뀐다. 노드가 하나 붙거나 자동 승인 임계값이 조정되면 지난달 진단은 그 부분에 대해 아무 말도 하지 않는다. 한 번 쓰고 버리는 산출물의 진짜 비용은 가격이 아니라, 언제부터 틀렸는지 아무도 모른다는 점이다.

이 구조는 이전에 다룬 두 갈래와 같은 자리에 있다. Advisor는 건축이 아니라 가격표다에서 정리했듯, 어떤 패턴이 아키텍처처럼 보여도 실제로는 그 시점 가격 구조에 맞춰진 임시 해법인 경우가 있다. 컨설팅 진단도 같다. 사람이 판단하는 게 유일한 방법이어서가 아니라, 판단 규칙이 표준화된 적이 없어서 사람 시간으로 청구돼 왔다. 그리고 한국이 SW를 안 사는 시장인 이유에서 본 것처럼, 한국 시장은 이런 종류의 작업을 제품으로 사기보다 용역으로 푸는 쪽으로 오래 기울어 있었다.

규제 시한을 잘못 알고 있는 경우가 많다

이 점검을 언제까지 갖춰야 하는지 물으면 EU AI Act 이야기가 먼저 나온다. 그런데 2026년 여름에 날짜가 한 번 바뀌었고, 이 부분이 자주 틀린 채로 인용된다.

규제 조항	실제 적용 시점	비고
EU AI Act 부속서 III 단독 고위험	2027-12-02	디지털 옴니버스로 2026-08-02에서 연기
EU AI Act 부속서 I 내장형 고위험	2028-08-02	2027-08-02에서 연기
EU AI Act 제50조 투명성 의무	2026-08-02부터 시행 중	연기 대상 아님
한국 AI기본법 고영향 AI	2026-01-22부터 시행 중	시행령 포함

부속서 III 고위험 의무가 2026년 8월 2일부터 적용된다고 적힌 자료가 아직 많이 돌아다닌다. 2026년 7월 27일 발효된 디지털 옴니버스 규정(Regulation (EU) 2026/1744)이 이를 2027년 12월 2일로 미뤘다. 반면 제50조 투명성 의무는 연기 대상이 아니라 2026년 8월 2일부터 이미 살아 있다. 벌금 상한은 금지된 AI 관행 위반 기준으로 전 세계 매출의 7% 또는 3,500만 유로 중 큰 쪽이다(제99조).

한국 쪽은 미뤄지지 않았다. AI기본법의 고영향 AI 관련 의무는 2026년 1월 22일부터 시행 중이고, 과기정통부가 과징금 부과에 유예 기조를 밝힌 것은 집행 태도이지 법 효력의 정지가 아니다. 판정 방식도 주의해야 한다. 제33조에 따라 사업자가 스스로 사전 검토하고 필요하면 과기정통부 확인을 받는 구조라서, 산출물에는 “고영향 대상일 가능성이 높으니 제33조로 확인이 필요하다”라고 적어야지 법적 결론처럼 단정하면 안 된다.

신용 심사 워크플로를 노드로 펼치면 조항이 어디에 붙는지가 눈에 보인다.

워크플로 노드	주로 걸리는 규범	성격
본인 확인(eKYC)	개인정보보호법, 신용정보법	수집과 처리 근거
자금세탁 방지 조회	특정금융정보법 계열	조회 기록 보존
신용 평점 산출	EU AI Act 부속서 III 5(b), AI기본법 고영향	고위험 분류 대상
자동 승인 결정	개인정보보호법 제22조의2	자동화 결정 거부권
거절 통지문 생성	공정대출 관련 규정, EU AI Act 제50조	설명과 표시 의무

노드마다 성격이 다르다. 앞쪽 둘은 기록을 남겼는지의 문제이고 뒤쪽 셋은 판단 근거를 설명할 수 있는지의 문제다. 컨설팅 산출물이 슬라이드로 끝나면 앞쪽은 체크리스트로 답이 되지만 뒤쪽은 안 된다. 결정이 내려진 뒤에 근거를 재구성하는 방식으로는 답이 안 나오고, 결정 시점에 근거가 함께 저장돼야 한다.

한 가지 짚을 점

마감이 미뤄진 것을 점검을 미룰 근거로 읽는 경우가 있는데, 위 표를 보면 그렇게 읽기 어렵다. 유럽에서 미뤄진 것은 부속서 III 고위험 의무이고 투명성 의무는 이미 적용 중이며 한국은 처음부터 미뤄진 적이 없다. 게다가 부속서 III 시한이 2027년 12월로 밀렸다는 것은 그 사이에 배포될 워크플로가 나중에 소급해서 대상이 된다는 뜻이기도 하다. 연기된 것은 제출 기한이지 설계 시점이 아니다.

그래서 만든 것: 실행 한 번으로 끝나는 사전 점검

구조는 세 단계다. 워크플로를 제출하고, 노드마다 채점하고, 결과를 게이트에 태운다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    A["워크플로 제출<br/>노드 인벤토리 표"] --> B["노드별 채점<br/>일반 실패 · 보안 · 핸드오프"]
    B --> C["핸드오프 런타임 지표<br/>IPS · 확신도 감쇠 · 판정"]
    C --> D["게이트 판정<br/>4개 조건 중 하나라도 걸리면"]
    D -->|"사람 필요"| E["승인 대기"]
    D -->|"전부 통과"| F["리포트 생성 후 종료"]

가운데가 프로세스로 옮기면서 가장 크게 바뀐 부분이다. 노드 채점을 언어 모델의 의견에 맡기지 않고 온톨로지 조회로 처리했다. 축별 점수는 그 노드에 걸린 셀들의 위험 점수 평균이고, 같은 워크플로를 다시 넣으면 같은 값이 나온다. 감사 대응 자료로 쓰려면 이 성질이 먼저 필요하다.

세 축을 합칠 때는 가중치가 붙는다. 핸드오프 0.4, 보안 0.3, 일반 실패 0.3이다. 노드와 노드 사이를 보는 축에 가장 큰 몫이 갔는데, 그 축이 참고할 공개 체계가 하나도 없던 축이다. 이 표를 어떻게 만들었는지는 다음 편의 주제다.

실제로는 이런 순서로 돈다

새 AI 워크플로를 설계한 팀이 배포 승인을 올리기 직전이 첫 지점이고, 이미 돌아가는 워크플로에 노드가 붙거나 임계값이 조정되는 시점이 두 번째 지점이다.

제출은 노드 인벤토리 표로 받는다. 노드 아이디, 기능, AI 개입 방식을 적은 마크다운 표다. 저장소에는 BPMN XML 파서, 머메이드 파서, 이미지를 멀티모달 모델로 읽어 머메이드로 바꾸는 모듈이 따로 들어 있지만, UiPath 경로의 코드 에이전트가 실제로 읽는 것은 이 표다. BPMN XML을 자동으로 변환해 넣는 부분은 아직 안 붙였다.

받는 쪽은 두 갈래다. 게이트를 통과하면 히트맵과 요약 리포트가 생성되고 감사 기록으로 보관된다. 걸리면 승인 화면이 만들어져 사람에게 간다. 이때 함께 가는 것은 워크플로 이름, 최고 위험 점수, 임계 초과 노드 수, 사람에게 온 사유, 한 장짜리 요약이다. 승인자는 그대로 승인하거나, 권고된 완화안을 적용하는 조건으로 승인하거나, 반려한다.

결정적 조회를 택하면 무엇을 포기하나

같은 입력이면 같은 진단이 나오게 만들면 감사 대응은 쉬워진다. 대신 온톨로지에 없는 노드 유형은 채점되지 않는다. 표에 없는 것은 조회되지 않으니, 처음 보는 형태의 워크플로가 들어오면 사람이 표를 늘려야 한다. 언어 모델에 판단을 맡기면 이 문제는 사라지고 대신 같은 워크플로에 대해 실행할 때마다 다른 점수가 나온다.

둘 중 무엇을 고를지는 산출물을 어디에 쓸 것인가로 갈린다. 규제 대응 자료로 쓴다면 재현되지 않는 점수는 쓸 수 없다. 그래서 채점은 조회로 고정하고, 언어 모델은 근거 문장을 다듬고 요약을 만드는 쪽으로 밀어냈다. 표를 늘리는 일은 사람이 주기적으로 하는 작업으로 남겼다.

미완인 것도 적어 둔다. 핸드오프 지표 중 판정 모델을 쓰는 항목은 기본 백엔드가 모의값이라 실제 판정을 돌리려면 따로 지정해야 한다. 관측 도구 연동은 미결이다. 그래프 기반 검색의 성능 수치는 측정 방식이 순환 구조였던 것을 발견해 철회하고 재측정 대기 상태다. 발표 자료와 제출물에서도 이 수치들은 뺐다.

마무리 - 사람 시간에 붙어 있던 값이 옮겨가는 자리

배포 전 점검을 프로세스로 옮기면 두 가지가 남는다. 무엇을 볼지 정한 표와 언제 멈출지 정한 게이트다. 나머지는 다시 돌릴 수 있게 된다.

이 구분이 중요한 이유는 비용이 아니다. 컨설팅 진단이 비싼 것은 사실이지만, 더 곤란한 것은 그 진단이 언제부터 유효하지 않게 됐는지 아무도 모른다는 점이다. 워크플로가 바뀔 때마다 다시 돌아가는 점검은 정확도가 같아도 다른 물건이다. 점검을 값싸게 만드는 것과 점검을 계속 살아 있게 만드는 것은 다른 작업이고, 후자가 실제 문제였다.

남은 질문은 그 표를 어떻게 채우느냐다. 공개 데이터셋에는 모델 위험과 보안 위험을 다루는 자료가 충분히 있다. 그런데 가중치가 가장 큰 축, 노드와 노드 사이에서 벌어지는 일을 채점할 기준은 어디에도 없었다.

출처

MIT NANDA, State of AI in Business 2025 (인터뷰 150건, 설문 350건, 배포 사례 300건)
Gartner, 30% of Generative AI Projects Will Be Abandoned After PoC
AI Incident Database, 사건 1442번 (AWS Kiro), 사건 639번 (Moffatt v. Air Canada)
CBS News, Waymo recalls 3,067 vehicles over school bus software defect
Cloud Security Alliance · Token Security, 에이전트 거버넌스 현황 조사 (2026-04, n=418)
Cyera, Agent-Inflicted Damage: Inside the Real-World Failures of Enterprise AI Systems
Regulation (EU) 2026/1744 (디지털 옴니버스, 2026-07-27 발효), EU AI Act 제50조·제99조·부속서 III
인공지능 발전과 신뢰 기반 조성 등에 관한 기본법 및 시행령 (2026-01-22 시행), 제33조
채점 로직: scripts/agents/aggregator.py, scripts/core/engine.py (공개 저장소)