업무에 AI를 쓸 때의 기준과, AI로 서비스를 만들 때의 규제 — 두 관점을 사례로 익히고, 마지막엔 우리 팀의 가상 거버넌스 초안(v0.1)까지 만드는 8주입니다. 법 용어는 최대한 풀어서 설명합니다.
첫 시간. 우리가 왜 모였는지, AI 거버넌스가 무엇인지, 기준이 없으면 어떤 일이 생기는지를 실제 사례로 봅니다.
90분 — 오리엔테이션 15′ · 발제 45′ · 사례 토론 20′ · 정리 10′
업무에 AI를 쓰기 시작했습니다. 그런데 회사엔 아직 공식 기준이 없어요. "이 문서, 챗봇에 넣어도 되나?" "AI가 짜준 코드, 그대로 반영해도 되나?" — 매번 각자 감으로 판단합니다.
→ 이 불안함의 정체는 뭘까요?
기준의 부재입니다. AI 거버넌스는 그 판단을 각자의 감에 맡기지 않게 하는 규칙(정책) + 절차(검토·승인) + 도구(점검·기록)의 총합이에요. 못 쓰게 막는 장치가 아니라, 안심하고 쓰게 해주는 장치입니다.
코드리뷰·CI/CD·장애대응 프로세스가 있어서 배포가 두렵지 않죠. 소프트웨어 품질에 거버넌스가 있듯, AI에도 같은 장치가 필요할 뿐입니다.
셋 다 악의가 아니라 기준의 부재에서 비롯됐습니다. 쓰는 쪽이든 만드는 쪽이든 — 거버넌스가 없으면 성실한 직원도 사고의 당사자가 될 수 있어요.
여기까지는 '쓸 때' 이야기였습니다. 그런데 우리는 만드는 팀이기도 하죠 — 만들 때는 법이 직접 우리를 지목합니다.
우리 팀이 ChatGPT API를 붙여서 사내 문서 요약 챗봇을 하나 만들었습니다. "모델은 OpenAI가 만든 거고, 우리는 그냥 갖다 쓴 건데?"
→ 그럼 규제랑 상관없을까요?
아니요. 남이 만든 모델을 가져다 서비스로 제공하는 순간, 우리도 법의 대상('이용사업자')이 됩니다. "갖다 썼을 뿐"은 통하지 않아요. 그리고 영향평가·편향 점검·기록 남기기 같은 의무는 결국 코드와 파이프라인에서 개발자가 하는 일이라, 법무팀이 대신 못 합니다.
마지막 두 회차(워크숍)에서 배운 것을 모아 우리 회사의 가상 AI 거버넌스 v0.1을 직접 만들어봅니다. 그 초안이 전사 거버넌스 논의의 포문이 됩니다.
우리는 두 입장을 오갑니다. 이 지도만 기억하면 8주가 헷갈리지 않습니다.
1·2회차(문제의식·원칙)는 두 관점의 공통 토대입니다. 그 위에서 3~6회차에 배우는 법이 곧 7·8회차에 만들 우리 기준(가상 거버넌스 v0.1)의 재료가 됩니다 — 배우는 이유가 곧 만들기 위해서죠.
복잡해 보이지만 결국 3층입니다. 위에서 아래로 내려올수록 구체적이 됩니다.
8주가 끝나면 "우리 서비스가 규제 대상인지, 뭘 해야 하는지"를 스스로 판단하고, 우리 팀의 기준(가상 거버넌스 초안)까지 갖게 됩니다.
주 1회 90분 × 8회. 매회 복습 10분 → 발제 45분 → 퀴즈·토론 25분 → 정리 10분으로 진행합니다.
| 회차 | 관점 | 주제 | 범위 · 함께 하는 것 |
|---|---|---|---|
| 1 | 공통 | 오리엔테이션 · AI 거버넌스란 무엇인가 | 1–9쪽 · 사고 사례 토론 |
| 2 | 공통 | 책임있는 AI 원칙 | 10–14쪽 · 퀴즈 ① |
| 3 | 만들 때 | 글로벌 법제 — EU AI Act | 15–19쪽 · 퀴즈 ② |
| 4 | 만들 때 | 한국 AI기본법 ① 지위·고영향 판정 | 20–24쪽 · 시나리오 실습 |
| 5 | 만들 때 | 한국 AI기본법 ② 의무·중복규제 갈음 | 25–29쪽 · 퀴즈 ③ |
| 6 | 만들 때 | 실무 프레임워크 — NIST·ISO·검증 분리 | 30–35쪽 · 퀴즈 ④ |
| 7 | 쓸 때 | 워크숍 ① 가상 거버넌스 초안 만들기 | 36–40쪽 · 퀴즈 ⑤ + 워크시트 |
| 8 | 쓸 때 | 워크숍 ② 초안 완성 · 전사 제안 방향 | 41–46쪽 · 결과 공유 |
법 이야기 전에 원칙부터. 이걸 잡아두면, 앞으로 어떤 규제가 새로 나와도 "아 이거 그 얘기구나" 하고 알아듣게 됩니다.
90분 — 복습 10′ · 발제 40′ · 퀴즈와 토론 30′ · 정리 10′
대출 심사 AI를 만들면서 인종·성별·소득 같은 민감 정보는 아예 입력에서 뺐습니다. "이러면 차별할 수가 없지" 하고 안심했죠. 그런데 우편번호(주소)는 넣었습니다.
→ 이 AI는 공정할까요?
특정 동네에 특정 계층이 몰려 살면, AI는 우편번호만 보고도 그 사람의 소득·계층을 눈치챕니다. 소득을 직접 안 봐도, 주소가 소득을 대신(대리) 알려주는 셈이죠. 결국 "그 동네 사람은 거절" 하는 패턴이 생기면 — 민감정보를 뺐어도 결과는 차별입니다.
이런 걸 대리변수(proxy) 문제라고 합니다. 우편번호 말고도 이름, 출신학교, 자주 가는 매장까지 — 무심코 넣은 변수가 민감정보의 대리인 노릇을 할 수 있어요.
스스로 도구를 쓰는 에이전트(파일 삭제, 메일 발송, 결제까지 자율 실행)는 잘못 풀리면 피해가 큽니다. 그래서 ① 꼭 필요한 권한만 주고 ② 전송·삭제·결제 같은 위험한 행동엔 사람 확인을 거치게 하고 ③ 무슨 도구를 언제 썼는지 전부 기록 — 이 셋은 설계 단계에서 원칙으로 정해두어야 합니다.
"우린 한국 회산데 남의 나라 법이 왜?" 싶겠지만, EU 법은 국경을 넘어옵니다. 왜 그런지 사례로 봅니다.
90분 — 복습 10′ · 발제 40′ · 퀴즈와 토론 30′ · 정리 10′
식당이 해외에 지점이 없어도, 그 나라 손님에게 음식을 팔면 그 나라 위생법을 지켜야 하죠. EU AI Act도 똑같습니다.
→ 우리 서비스를 EU 사용자가 쓴다면?
회사가 한국에 있어도 EU 사용자에게 영향을 주면 EU AI Act가 적용됩니다(이걸 '역외 적용'이라 부릅니다). 글로벌 서비스를 생각한다면 미리 알아둬야 하고, 무엇보다 세계 규제가 대체로 EU를 따라오기 때문에 한발 앞서 보는 셈이 됩니다.
위험한 순서대로 규제 강도가 다릅니다. 신호등처럼 생각하면 쉬워요.
외부 모델(GPT 등)을 그냥 갖다 쓰거나 RAG로 지식만 붙이면 → 우리는 '쓰는 쪽(deployer)'. 그런데 데이터를 잔뜩 넣어 대규모로 파인튜닝해서 모델을 바꿔버리면?
→ 이때 우리는 '만든 쪽'이 됩니다.
많이 손대면 '만든 쪽(provider)'으로 재분류되어 의무가 훨씬 무거워집니다. "얼마나 손댔는가"가 기준이에요. 파인튜닝 규모가 커질수록 우리 책임도 커진다는 것만 기억하면 됩니다.
2026년 1월 시행. 가장 실무에 직접 닿는 부분이라 두 회차에 나눠 봅니다. 이번 시간은 "우리는 누구이고(지위), 이건 고영향인가(등급)"까지.
90분 — 복습 10′ · 발제 50′ · 토론 20′ · 정리 10′
법은 회사를 두 종류로 나눕니다. 우리가 어느 쪽인지에 따라 의무가 달라져요.
"생성형 AI를 직접 만들어서 대출심사에 쓴다"면 → 만든 쪽 + 쓰는 쪽 + 생성형 + 고영향, 네 가지에 한꺼번에 해당합니다. 그래서 "우린 어느 하나"가 아니라 "몇 개나 겹치나"를 서비스별로 따져봐야 해요.
'고영향 AI'로 판정되면 의무가 크게 늘어납니다. 판단은 딱 2단계예요.
EU는 신용평가·보험료 계산·자산관리까지 폭넓게 고위험으로 봅니다. 그럼 한국도 금융이면 다 고영향일까요?
→ 아닙니다. 한국은 '대출심사'로 좁게 봅니다.
대출을 승인/거절 판단하는 데 AI를 쓰면 → 일단 고영향으로 봅니다. (약관대출처럼 대출 성격이면 보험사도 포함)
자산관리·투자권유·로보어드바이저는 한국법상 고영향 규제 밖. 단, 개인에게 유리하게 쓰는 데이터는 기준이 완화되기도.
모기업에서 "개인사업자 대출 심사를 돕는 AI 모델" 구축 과제가 내려왔습니다. 외부 LLM에 내부 신용 데이터를 결합할 계획입니다.
→ 오늘 배운 2단계로 직접 판정해봅시다.
지난 시간에 지위와 등급을 판정했으니, 이번엔 그래서 붙는 의무와 이미 지키는 금융법으로 갈음되는 부분을 봅니다.
90분 — 복습 10′ · 발제 45′ · 퀴즈와 토론 25′ · 정리 10′
의무마다 대상이 다릅니다. "우리 해당?" 칸을 먼저 보세요.
| 의무 (쉽게 말하면) | 누가? | 우리? |
|---|---|---|
| ① "이거 AI예요" 알리기 + 생성물·딥페이크 표시 | 고영향·생성형 쓰는 곳 전부 | 대부분 O |
| ② 초거대 AI 안전관리 | 초거대 모델 만드는 곳 | 보통 X |
| ③ 고영향이면 특별관리 위험·설명·감독·기록 | 고영향 쓰는 곳 | 대출심사 O |
| ④ 영향평가 (미리 점검) | 고영향 (노력의무) | 강제 아니나 권장 |
| ⑤ 국내대리인 두기 | 큰 해외 회사 | X (국내사) |
그리고 이걸 했다는 증거 문서를 5년간 보관하고, 요지는 홈페이지에 공개합니다.
"AI기본법 의무 + 신용정보법 + 금융소비자보호법… 이걸 다 따로따로 해야 하나?" 부담스럽죠.
→ 다행히 겹치는 건 한 번만 하면 됩니다.
| AI기본법이 요구하는 것 | 이미 지키는 금융법으로 갈음 |
|---|---|
| 설명할 수 있게 하기 | 신용정보법 (자동화평가 대응권) |
| 이용자 보호 | 금융소비자보호법 |
| 개인정보 관리 | 개인정보보호법 |
→ "AI기본법 의무 ↔ 이미 지키는 금융법" 대응표를 한 장 만들면, 중복을 피하고 그 표가 곧 감사 대응 자료가 됩니다.
원칙·법을 배웠으니 이제 실전. 이미 있는 프레임워크를 가져다 쓰고, 개발 단계마다 증거를 남기는 법을 봅니다.
90분 — 복습 10′ · 발제 45′ · 퀴즈와 토론 25′ · 정리 10′
"AI 관리 어떻게 하지?"는 이미 전 세계가 고민해서 매뉴얼을 만들어놨습니다. 갖다 쓰면 됩니다.
위험 관리를 4단계로 돌리는 체크리스트: 총괄(GOVERN) → 위험 찾기(MAP) → 재보기(MEASURE) → 대응(MANAGE). 생성형 AI 전용 부록도 있어 LLM 서비스 점검표로 바로 활용.
"AI판 ISO 27001". 인증을 받을 수 있어 대외적으로 "우리 AI 제대로 관리한다"를 증명하는 데 유리.
실무 조합: NIST로 굴리고, ISO로 인증받기.
의무를 "법무 숙제"로 미루지 말고, 개발하면서 자연스럽게 남기면 됩니다.
| 언제 | 뭘 남기나 |
|---|---|
| 기획할 때 | 이 서비스가 고영향인지 판정, 우리 지위 태그 |
| 데이터 준비 | 어디서 적법하게 가져왔는지, 데이터 출처 기록 |
| 학습·테스트 | 편향 테스트 결과, 성능 검증 기록 |
| 배포 전 | 모델 설명서(Model Card), "AI예요" 표시 UI, 비상정지 |
| 운영 중 | 성능 저하 감시, 사고 기록 |
PR 템플릿에 "고영향 판정 ☐ / 편향 테스트 ☐ / 설명방안 ☐" 체크박스를 넣어두면, 개발하다 보면 증거가 저절로 쌓입니다. 나중에 몰아서 문서 만드는 것보다 훨씬 안전해요.
☐ 고영향 여부 판정 (결과: __)
☐ 데이터 출처 기록
☐ 편향 테스트 결과 첨부
☐ "AI 사용" 표시 UI 반영
☐ 비상정지 경로 확인
코드가 머지될 때마다 증거가 저절로 쌓입니다.
모델이 무엇을 하는지 · 어떤 데이터로 학습했는지 · 어디에 쓰면 안 되는지 · 성능과 한계를 한 장으로 정리한 문서.
사고 시 "우리는 알고 있었고, 관리하고 있었다"를 보여주는 1차 증거. 주요 AI 기업들이 형식을 공개하고 있어 그대로 빌려오면 됩니다.
모델을 만든 개발자가 성능 검증까지 직접 하고 "문제없음" 보고서를 올렸습니다. 일정도 빠듯한데, 만든 사람이 제일 잘 아니까 효율적인 것 아닐까요?
→ 이 검증, 믿을 수 있을까요?
본인이 짠 코드를 본인이 리뷰 승인하지 않는 것과 같은 이유로, 안 됩니다. 자기 모델의 약점은 자기 눈에 잘 안 보입니다. 그래서 금융권 모델 관리의 기본 원칙이 개발과 독립 검증의 분리이고, 마지막 체크리스트에도 "만든 사람 ≠ 검증한 사람"이 들어갑니다.
우리 회사의 가상 AI 거버넌스 v0.1. 정해진 게 없다는 건 불안이기도 하지만, 우리가 초안을 쓸 수 있다는 기회이기도 합니다.
90분 — 복습 10′ · 발제 35′ · 워크시트 실습 35′ · 정리 10′
거창할 필요 없습니다. 이 다섯 질문에 답하는 문서면 이미 거버넌스입니다.
1번은 2회차의 원칙, 2번은 4·5회차의 데이터 의무, 3~5번은 6회차의 프레임워크가 그대로 재료입니다. 국제 표준(NIST의 '총괄(GOVERN)' 기능)도 같은 구조예요.
가장 먼저 만들 한 장. 삼성 사고가 터진 곳이 바로 이 표가 없던 자리입니다.
| 데이터 등급 | 예시 | 외부 AI 입력 |
|---|---|---|
| 공개 | 보도자료, 공개된 기술 문서 | 가능 |
| 사내 일반 | 회의록, 업무 매뉴얼 | 조건부 — 회사 승인 도구만 |
| 고객·개인정보 | 고객 상담 내용, 계좌·신용 정보 | 금지 (가명처리·법 검토 전엔) |
| 소스코드·인증정보 | 내부 코드, 설정값, 접속 키 | 금지 또는 승인 도구만 |
→ 금융 IT의 이점: 고객정보는 신용정보법·개인정보보호법 기준을 이미 지키고 있음. 5회차의 '갈음' 논리처럼 기존 기준을 AI 규칙으로 확장하면 됩니다.
처음엔 신고 양식 1장 + 승인 도구 목록 1개면 충분합니다. 완벽한 체계보다 돌아가는 절차가 먼저예요.
마지막 시간. 지난주 시작한 워크시트를 v0.1 초안으로 완성하고, 이 초안을 회사에 어떻게 제안할지 방향을 정합니다.
90분 — 복습 10′ · 토론·초안 완성 55′ · 결과 공유 15′ · 정리 10′
정답 없음. 아래 질문에 팀의 답을 채우면 그게 곧 v0.1 초안입니다. (기록용 워크시트 별도 제공)
완벽한 정책보다, 오늘 시작한 초안이 회사를 움직입니다.
"사고가 났을 때, 누가·왜·언제·무엇을 근거로 그렇게 했는지 보여줄 수 있는가."
거창한 정책보다, 개발하면서 남긴 증거 한 줄이 우리를 지킵니다.
그리고 오늘 함께 만든 가상 거버넌스 v0.1이, 우리 회사 AI 거버넌스의 첫 문장이 됩니다.
본 자료는 교육용 요약입니다. 개별 서비스의 판단은 법무·컴플라이언스 검토가 필요하며, 하위 규정은 계속 바뀌므로 최신본을 확인하세요.