잘 만든 그림 한 장은 논쟁을 정리한다

AI 개발 라이프사이클(SDLC)을 규제·보안·컴플라이언스 관점에서 한 장에 압축한 인포그래픽을 봤다. STEP 1~4에 걸쳐 28개 활동, 6개 추가 제언, 그리고 적용 법령까지 촘촘하게 박혀 있다. 잘 만든 그림은 그 자체로 하나의 주장이라, 이걸 놓고 “AI를 개발한다는 건 전통적인 소프트웨어 개발과 무엇이 다른가”를 다시 생각해봤다.

안전한 AI 개발 라이프사이클 — 한국 규제 중심의 보안·컴플라이언스 플로우. STEP1 입력 정의 및 거버넌스 수립 / STEP2 개발·테스트 및 모델 보안화 / STEP3 승인 및 배포 관리 / STEP4 거버넌스 및 산출물 관리, 추가 제언 6가지와 적용 법령

이미지 제작: 김진국 (turtle1597@gmail.com). 이 글은 이 그림을 텍스트로 삼아 고찰한 것입니다.

먼저, 그림이 담은 것

네 단계로 흐른다.

  • STEP 1 · 입력 정의 및 거버넌스 수립 — 학습 데이터·데이터셋(개인정보보호법·신용정보법·저작권법), 비즈니스/기술 요구사항(ISMS-P), 적대적 시나리오, 휴먼 피드백 루프, 윤리 가이드라인(OECD·EU AI Act), 위험 식별, 컴플라이언스 규정, 모델 거버넌스 정책. 개발 이전에 “무엇을 지킬지”를 못 박는 단계.
  • STEP 2 · 개발·테스트 및 모델 보안화 — 데이터 검증/비식별화 → 모델 버전 관리 → 자동화 테스트 → 적대적 테스트/레드팀(프롬프트 인젝션·데이터 유출) → 학습/평가 → 편향·공정성 검사 → 의존성·취약점(SBOM) → 보안 컨테이너/레지스트리.
  • STEP 3 · 승인 및 배포 관리 — 승인 게이트(PIA) → CI/CD → 정책 집행 → 전자 서명 승인(전자서명법) → 변경 관리 → 승인된 모델만 배포 → 지속 모니터링 → 24/7 자동 경보.
  • STEP 4 · 거버넌스 및 산출물 관리 — 모델 아티팩트 → 환경 구성정보 → 종합 감사 추적 로그(5년 이상 보관) → 리스크 보고서 → 컴플라이언스 인증(ISMS-P) → 보안 패치 → 사용자/기술 지원.

여기까지가 “무엇이 있는가”다. 내가 흥미로웠던 건 “이것들을 관통하는 축이 무엇인가”였다.

축 ①: 전통 SDLC엔 없던 단계 — 데이터가 코드가 되는 순간

전통적인 소프트웨어는 로직을 사람이 짠다. AI는 로직이 데이터에서 유도된다. 이 한 문장이 라이프사이클을 바꾼다.

그래서 이 그림엔 일반 SDLC에 없던 단계가 1급 시민으로 올라와 있다 — 데이터 검증/비식별화, 편향·공정성 검사, 모델 버전 관리. 코드는 리뷰하면 의도가 보이지만, 학습 데이터의 편향은 눈에 안 보이는 채로 모델 가중치에 스며든다. 그래서 “성별·인종·지역 차별 리스크 점검”이 테스트 항목이 된다. 전통 QA엔 없던 칸이다.

핵심: AI SDLC는 코드 파이프라인 위에 ‘데이터 거버넌스 파이프라인’이 하나 더 겹쳐진 구조다. STEP 1의 절반(데이터·개인정보·저작권), STEP 2의 앞부분(검증·비식별화·편향)은 전부 이 두 번째 파이프라인이다.

축 ②: 불투명함을 다스리는 두 장치 — 추적가능성과 게이트

모델은 근본적으로 불투명하다(왜 그렇게 답했는지 설명이 어렵다). 불투명한 것을 통제 가능하게 만드는 방법은 예나 지금이나 둘이다.

추적가능성(traceability). 그림 전체에 provenance 장치가 깔려 있다 — 모델 버전 관리, SBOM(모델 공급망), 전자 서명 승인, 그리고 5년 이상 보관하는 감사 추적 로그. 모델 자체를 들여다볼 수 없으니, 대신 그 모델이 어떤 데이터로·누구 승인으로·어떤 변경을 거쳐 여기 왔는지의 사슬을 남긴다. 결과를 못 믿으면 이력을 믿는 것이다.

게이트(gate). 이 그림엔 “게이트”가 반복된다 — 보안/업무 승인 게이트, 추가 제언의 AI 영향평가 게이트, 예외 승인 및 재평가. 게이트는 불투명한 흐름을 이산적인 통과/거부 지점으로 쪼개 사람이 개입할 자리를 만든다. 흐름이 자동일수록 게이트가 통제권을 되찾는 손잡이가 된다.

이 두 장치는 사실 내가 최근에 계속 파던 주제와 정확히 같은 것이다. 이벤트 소싱으로 모든 스텝을 남기는 것 = 추적가능성. 근거 없는 출력을 거부하는 evidence-gate = 게이트. 거버넌스가 “무엇을” 요구하면, 하네스 엔지니어링이 “어떻게”를 준다. 이 인포그래픽의 STEP 2(레드팀·SBOM)와 STEP 4(감사 로그)는, 엔지니어링 레이어에서 보면 measure_drift·evidence-gate·event store로 구현되는 바로 그것들이다.

축 ③: 규제가 ‘나중’이 아니라 ‘입력’이다

가장 눈에 띈 설계 결정은 이거다. 컴플라이언스가 STEP 4(사후 점검)가 아니라 STEP 1(입력 정의)에 들어가 있다.

개인정보보호법·정보통신망법·신용정보법·저작권법·전자서명법, 그리고 AI 기본법(제정안)과 EU AI Act가 개발을 시작하기 전에 이미 제약으로 선언된다. 이건 “shift-left”의 규제 버전이다. 보안 업계가 “보안을 나중에 붙이지 말고 처음부터 설계에 넣어라(shift-left security)”를 배운 것처럼, AI는 규제를 설계 입력으로 당겨오는 중이다.

한국 맥락에서 이게 특히 무겁다. AI 기본법이 제정 단계에 있고, 개인정보 영향평가(PIA)와 ISMS-P가 이미 실효적 게이트다. “일단 만들고 규제는 나중에”가 통하던 시절이 닫히는 중이라는 신호로 읽힌다.

그런데 — 이걸 다 할 수 있나

솔직한 긴장도 적어둔다. 28개 활동 + 6개 제언은 대기업·규제 산업(금융·의료·공공)의 그림이다. 스타트업이나 개인 개발자가 이걸 전부 세우려다간 개발 자체가 질식한다.

그래서 “어디부터”가 진짜 질문이다. 내 답은 이 그림에서 가장 레버리지 높은 최소 셋을 먼저 고르는 것:

  1. 감사 추적 로그(축 ①·②) — 나중에 소급 못 하는 유일한 자산. 처음부터 모든 실행을 이벤트로 남겨라. 이건 엔지니어링 비용이 낮고 회수가 크다.
  2. 승인/영향평가 게이트 1개(축 ②) — 배포 직전 딱 하나의 통과 지점. 완벽한 정책보다 “멈출 자리”가 먼저다.
  3. 데이터·모델 버전 관리(축 ①) — 재현성의 바닥. 이게 없으면 나머지 감사도 공허하다.

나머지(레드팀 자동화, SBOM 전면화, 24/7 SOC)는 규모가 요구할 때 붙이면 된다. 거버넌스는 한 번에 세우는 기념비가 아니라, 감사 로그에서 시작해 게이트를 하나씩 늘려가는 파이프라인이다.

한 줄 요약

AI SDLC는 코드 파이프라인 위에 데이터 거버넌스 파이프라인을 겹치고, 불투명한 모델을 추적가능성과 게이트로 다스리며, 규제를 사후 점검이 아니라 설계 입력으로 당겨오는 흐름이다. 이 그림은 그걸 한국 규제 언어로 번역한 완성도 높은 지도이고, 엔지니어링 관점에서 보면 그 요구의 상당수는 이미 “측정 가능한 하네스”의 도구들 — 이벤트 소싱, evidence-gate, drift 계측 — 로 답할 수 있다. 거버넌스와 하네스는 같은 문제의 앞뒷면이다.