4장. 조직 정책과 통제

학습 목표

• AI 사용 현황 등록부를 만들고, 그것을 출발점으로 정책·표준·절차·안내문을 층위별로 설계한다.
• 데이터 등급, 도구, 용도의 영향, 실행 권한을 조합해 허용·조건부·금지 범주를 설계한다.
• 위험에 비례하는 승인 절차와 만료일이 있는 예외 절차를 만든다.
• 규정의 조건을 관리자 제어(계정, 보존, 피드백, 조직 단위, 웹 검색, 에이전트)로 구현하고 동작을 확인한다.
• 에이전트와 연결 기능의 권한을 나누고, 교육과 대체 도구로 섀도 AI를 줄인다.

들어가며

보안팀이 프록시 기록을 들여다보다가 직원 다수가 승인되지 않은 AI 사이트에 접속한다는 사실을 발견했다고 합시다. 가장 빠른 대응은 차단입니다. 그런데 차단 다음 주에 직원들은 개인 휴대폰으로 같은 사이트를 쓰기 시작하고, 회사는 이제 그 사용을 볼 수조차 없게 됩니다. 직원들이 원한 것은 규정 위반이 아니라 마감을 맞추는 일이었고, 회사는 그 필요를 채울 승인된 길을 주지 않았습니다. 문제는 사람이 아니라 설계에 있었던 셈입니다. 이 장은 그 설계를 다룹니다.

조직의 AI 규정은 금지 목록이 아니라 "이렇게 하면 된다"는 안내서여야 합니다. 쓸 수 있는 도구와 방법을 분명히 열어 주고, 위험이 큰 곳에만 문턱을 높이고, 그 조건을 사람의 기억이 아니라 시스템 설정으로 지키게 하는 것이 목표입니다.

이 장은 거버넌스의 첫 단추인 사용 현황 파악에서 시작합니다. 이어서 규정의 층위와 뼈대, 범주 설계, 승인과 예외, 책임 구조를 다루고, 관리자 제어와 권한 정리, 에이전트 통제, 교육, 공급망 관리로 넘어갑니다. 1장에서 읽은 벤더 조건과 2·3장의 법적 요구가 여기서 규정의 재료가 됩니다. 예시는 그대로 베껴 쓰기보다 조직의 데이터 등급과 업무에 맞게 고쳐 쓰도록 만들었습니다.

핵심 개념

거버넌스의 첫 단추: AI 사용 현황 등록부

무엇을 쓰는지 모르면 규정을 만들 수 없습니다. NIST AI RMF는 AI 시스템을 목록화하는 체계를 갖추고 조직의 위험 우선순위에 맞게 자원을 배정하라고 합니다(GOVERN 1.6). AI 사용 현황 등록부는 조직이 쓰는 AI를 한곳에 모은 표입니다.

등록부를 만들 때는 새로 산 AI 도구뿐 아니라 이미 쓰는 SaaS에 추가된 AI 기능도 찾아야 합니다. 업무 도구의 업데이트로 조용히 켜진 요약·생성 기능이 가장 흔한 사각지대입니다. 처음부터 완벽할 필요는 없습니다. 부서별 설문, 구매 기록, 네트워크 기록을 겹쳐 보며 채워 나가고, 신청 절차를 등록부 갱신과 연결하면 저절로 최신 상태가 유지됩니다.

정책, 표준, 절차, 안내문

모든 내용을 한 문서에 넣으면 고치기도 읽기도 어렵습니다. 층을 나누면 원칙은 오래 유지하면서 제품 변화에는 빠르게 대응할 수 있습니다.

예를 들어 "개인정보는 승인된 도구에서만 처리한다"는 정책, "승인 도구는 학습 미사용·정해진 보존 기간·피드백 제한을 갖춘다"는 표준, "새 도구는 신청 후 5영업일 안에 검토한다"는 절차, "고객 이름은 지우고 붙여 넣으세요"는 안내문입니다.

AI 사용 규정의 뼈대

AI 사용 규정에는 최소한 다음 다섯 부분이 있어야 합니다.

1. 목적과 적용 범위: 누구에게(임직원, 파견·협력사 직원 포함 여부), 어떤 도구와 업무에 적용하는가.
2. 데이터 등급: 공개, 내부, 기밀, 개인정보, 민감정보 등. 기존 정보보호 규정의 등급을 그대로 쓰는 것이 좋습니다.
3. 승인 도구 목록: 데이터 조건이 확인된 제품과 플랜, 허용 기능.
4. 사용 범주: 데이터 등급, 도구, 용도의 조합별로 허용·조건부·금지.
5. 책임과 절차: 결과물 검토 책임, 신청·예외 승인, 사고 신고, 위반 시 조치.

규정 문장마다 이유와 대안을 붙이면 지키는 비율이 높아집니다. "고객 정보를 넣지 마세요" 뒤에 "대화가 학습에 쓰일 수 있기 때문입니다. 필요하면 승인 도구 A를 쓰세요"를 붙이는 식입니다.

허용·조건부·금지 범주 설계

이 장의 기술 목표는 "허용·조건부·금지 사용 범주 설계"입니다. 도구 이름만으로 범주를 정하면 빈틈이 생깁니다. 같은 도구라도 넣는 데이터와 쓰는 용도에 따라 위험이 다르기 때문입니다. 네 가지 축을 함께 봅니다.

먼저 데이터와 도구의 조합으로 기본 범주를 정합니다.

그다음 용도와 실행 권한으로 범주를 한 단계씩 올립니다. 결과가 고객에게 그대로 나가면 사람 검토 조건을 붙이고, 채용·평가·대출처럼 사람에 대한 판단에 쓰이면 사전 위험 평가와 2장의 고영향 검토, 3장의 자동화된 결정 검토를 조건으로 붙입니다. AI가 외부로 보내거나 되돌리기 어려운 행동을 하면 행동 전 승인을 조건으로 둡니다. 범주가 바뀌는 조건을 예시로 함께 적어 두면 직원이 스스로 판단할 수 있습니다.

위험에 비례하는 승인 절차

모든 신청을 같은 서면 결재로 처리하면 단순한 요청까지 몇 주씩 걸리고, 그 지연이 섀도 AI를 키웁니다. 경로를 셋으로 나누는 방식이 흔합니다.

승인 단계는 앞 단계의 결과가 다음 단계의 입력이 되도록 설계합니다. 목적과 데이터 등급을 정하고, 그 등급에 맞춰 벤더 조건과 위험을 평가하고, 평가 결과로 승인 조건을 정하고, 조건을 관리자 설정으로 구현하고, 사용자를 교육한 뒤 배포하고, 운영 기록으로 재평가합니다. 승인서에는 승인 범위(업무, 데이터, 사용자, 기능, 기간)를 적어, 한 번의 승인이 다른 데이터나 용도로 슬그머니 넓어지지 않게 합니다.

예외 관리

규정에 맞지 않지만 필요한 사용은 반드시 생깁니다. 예외를 막으면 몰래 쓰고, 예외를 쉽게 주면 규정이 무너집니다. 좋은 예외 절차는 네 가지를 갖춥니다.

1. 신청 내용: 요청자, 목적, 데이터 등급, 기간, 대안 검토 결과.
2. 보완 통제: 예외로 커진 위험을 줄이는 조치(데이터 가림, 사용자 한정, 로그 점검).
3. 만료와 회수: 끝나는 날짜, 만료 시 계정·데이터 회수 방법, 연장 심사 조건.
4. 반복 예외의 환류: 같은 예외가 반복되면 규정이나 승인 도구 목록을 고칠 신호로 봅니다.

만료일이 없는 예외는 예외가 아니라 규정 밖의 영구 허용입니다.

책임 구조: 누가 결정하고 누가 검토하는가

관련 부서가 많을수록 책임이 흐려집니다. NIST AI RMF는 위험의 매핑·측정·관리에 관한 역할과 책임, 소통 경로를 문서화하고(GOVERN 2.1), 경영진이 AI 시스템의 개발·배포에 따른 위험 결정에 책임을 지라고 합니다(GOVERN 2.3).

실무에서는 두 가지 원칙을 지킵니다. 첫째, 만든 사람과 위험을 수용하는 사람을 나눕니다. 개발팀이 가장 잘 알기 때문에 평가 자료는 개발팀이 만들지만, 위험을 받아들일지는 독립된 검토를 거친 상위 권한자가 정합니다. 둘째, 위험 등급에 따라 수용 권한을 올립니다. 낮은 위험은 부서장, 중간은 위원회, 높은 위험은 경영진처럼 정해 두면 판단이 빨라지고 기록이 남습니다. 검토 부서(법무, 개인정보, 정보보호)는 의견을 내고, 결정과 그 근거는 승인권자의 이름으로 남깁니다.

관리자 제어

규정의 조건은 가능하면 관리자 설정으로 구현합니다. 사람의 기억보다 시스템 설정이 확실하기 때문입니다. 공식 문서에 나온 예는 다음과 같습니다.

설정을 바꾼 뒤에는 일반 사용자 계정으로 실제 동작을 확인하고, 변경 일시와 변경자를 기록합니다. Gemini 앱처럼 그룹과 조직 단위 설정이 겹칠 때는 우선순위 규칙 때문에 의도와 다른 결과가 나올 수 있습니다. 관리자 권한 자체도 최소한의 인원에게만 주고, 관리자 활동 기록을 정기적으로 봅니다.

권한 정리와 오버셰어링

사내 데이터를 검색해 답하는 AI는 사용자가 볼 수 있는 모든 것을 찾아냅니다. Microsoft는 Copilot이 사용자에게 최소한 보기 권한이 있는 조직 데이터만 보여 준다고 설명하면서, SharePoint 같은 서비스의 권한 모델을 올바르게 쓰라고 권합니다. 문제는 "권한은 있지만 아무도 찾아보지 않던" 파일입니다. 전사 공유로 잘못 열린 폴더는 지금까지 숨어 있었을 뿐, AI 검색이 들어오면 바로 답에 등장합니다.

그래서 AI 검색 도구를 배포하기 전에는 권한 정리를 선행 조건으로 둡니다. 전사 공유 링크와 "모든 사용자" 권한이 걸린 위치를 찾고, 민감한 위치에는 민감도 레이블(문서에 등급을 붙여 접근·암호화를 적용하는 표시)이나 접근 제한을 적용하고, 사내 검색 색인이 원본 권한을 따르는지도 확인하고(3장 깊이 읽기), 배포 후에도 정기적으로 점검합니다. 이 작업은 AI 통제이면서 동시에 오래된 정보보호 부채를 갚는 일입니다.

에이전트와 연결 기능 통제

에이전트는 답을 생성하는 데 그치지 않고 도구를 호출해 조회·수정·발송·결제 같은 행동을 하는 AI입니다. OWASP Top 10 for LLM Applications(2025)는 주요 위험으로 프롬프트 인젝션(LLM01)과 과도한 권한(Excessive Agency, LLM06)을 듭니다. 외부 문서나 메일에 숨은 지시가 AI의 행동을 바꾸는 간접 프롬프트 인젝션이 대표적이고, AI에 필요 이상의 권한이 있으면 그 피해가 커집니다.

통제는 다섯 가지로 정리됩니다.

1. 최소 권한: 업무에 필요한 도구와 범위만 연결합니다. 읽기와 쓰기를 분리합니다.
2. 행동 전 확인: 외부 발송, 결제, 삭제, 권한 변경처럼 되돌리기 어려운 행동은 사람이 승인한 뒤 실행합니다.
3. 한도: 금액, 건수, 대상 범위의 상한을 시스템이 모델과 독립적으로 강제합니다.
4. 기록: 어떤 입력으로 어떤 도구를 어떤 인자로 호출했는지 남깁니다.
5. 중단과 복구: 이상 행동을 발견하면 즉시 멈출 수 있는 스위치와 되돌리는 절차를 둡니다.

벤더 사용 정책도 같은 방향입니다. Anthropic의 현행 사용 정책은 에이전틱 사용도 정책을 준수해야 한다고 정하고, 2026년 11월 12일 시행 개정본은 에이전트를 만들거나 배포하는 사용자가 도구, 브라우저, 연결된 시스템을 통한 행동까지 포함해 책임을 진다고 밝힙니다.

교육과 섀도 AI

섀도 AI는 조직이 승인하지 않은 AI 계정·도구로 업무 데이터를 처리하는 현상입니다. 직원이 섀도 AI를 쓰는 이유는 대개 악의가 아니라 편의입니다. 승인 도구가 없거나, 신청 절차가 느리거나, 무엇이 허용되는지 모르기 때문입니다.

효과적인 대응은 네 가지의 조합입니다. 승인 도구를 쉽게 쓸 수 있게 열고, 짧고 구체적인 기준을 알리고, 직무별 사례로 교육하고, 사용 현황을 다시 측정합니다. 교육에는 데이터 등급 구분법, 승인 도구와 그 이유, 결과물 검증 책임, 피드백 버튼의 의미, 실수했을 때의 신고 방법이 들어가야 합니다. 자진 신고한 실수에는 불이익을 줄이는 원칙을 두면 사고를 빨리 알 수 있습니다. 도구와 약관이 자주 바뀌므로 연 1회 집합 교육보다 도입·변경 때마다 짧은 교육이 효과적입니다. 사용 현황을 조사할 때는 직원의 프롬프트 내용까지 과도하게 수집하지 않도록 범위를 정하세요. 그것도 개인정보 처리입니다.

공급망과 서드파티 관리

AI는 대부분 외부에서 옵니다. 모델, API, 데이터셋, 그리고 SaaS 안에 들어간 AI 기능까지 모두 공급망입니다. NIST AI RMF는 서드파티와 관련된 AI 위험을 다루는 정책과 절차를 두고(GOVERN 6.1), 서드파티 자원의 위험과 이익을 정기적으로 모니터링하라고 합니다(MANAGE 3.1).

공급자 실사에서 볼 것은 1장의 다섯 질문, 보안 인증, 사고 통지 조건, 하위 처리자 변경 통지, 모델 변경·지원 종료 공지 방식, 계약 종료 시 데이터 반환·삭제입니다. 공급자가 ISO/IEC 42001 같은 경영시스템 인증을 받았다는 사실은 공급자의 관리 체계에 대한 정보일 뿐, 우리 조직이 자기 사용 사례의 위험을 평가할 책임을 대신하지 않습니다(5장).

깊이 읽기

형식적 승인과 자동화 편향

"사람이 최종 검토한다"는 조건은 많은 규정에 들어가지만, 그 검토가 실제로 작동하는지는 따로 확인해야 합니다. 사람이 AI의 제안을 지나치게 신뢰해 검토 없이 받아들이는 경향을 **자동화 편향(automation bias)**이라고 합니다. NIST 생성형 AI 프로파일은 사람과 AI의 상호작용에서 생기는 과신, 자동화 편향, 과도한 의존을 "인간-AI 구성(Human-AI Configuration)" 위험으로 따로 듭니다.

실효성 있는 검토는 검토자에게 판단에 필요한 정보와 시간, 결과를 바꿀 권한과 책임이 있고, 검토가 실제로 이루어지는지 측정합니다. 수정 없이 승인되는 비율, 검토 시간, 검토 후 발견된 오류율이 이상하면 위험이 큰 건만 깊게 보거나 무작위 표본을 이중 검토하도록 다시 설계합니다. 형식적인 클릭은 3장의 자동화된 결정에서도 실질적 개입으로 인정받기 어렵습니다.

AI 시스템의 변경과 종료

AI 시스템은 도입보다 바뀌고 끝날 때 사고가 잘 납니다. 벤더가 모델 버전의 지원 종료를 공지하거나, 새 모델로 자동 업데이트되거나, 서비스를 접기로 하는 경우입니다. NIST AI RMF는 AI 시스템을 안전하게 퇴역시키는 절차를 두고(GOVERN 1.7), 의도와 다른 성능이나 결과를 보이는 시스템을 대체·분리·비활성화하는 장치와 책임을 정하라고 합니다(MANAGE 2.4).

변경 때는 기존 평가가 새 버전에도 유효한지 묻고, 공개 벤치마크 점수가 우리 업무 성능을 보장하지 않으므로 위험 등급이 높은 시스템은 자체 업무 데이터로 다시 검증합니다. 종료 때는 연결 권한 회수, 사용자 안내, 보존과 파기 구분(다른 법령상 보존 기록은 분리 보관), 대체 업무 절차를 점검표로 관리합니다.

실무 장면

청람대학교: 교직원 AI 사용 규정을 만들 때

재학생 1만 2천 명 규모의 '청람대학교'는 교직원 AI 사용 규정을 만들기로 했다. 교무처는 성적 처리와 강의 계획서 작성에, 연구처는 연구 과제 보고서에, 입학처는 입시 안내 상담에 AI를 쓰고 싶어 했다. 정보화본부가 한 달간 조사하니 학교가 계약한 업무용 플랜 외에도 개인 계정이 널리 쓰이고 있었고, 일부 강사는 학생 과제 파일을 통째로 붙여 넣어 채점 의견을 받고 있었다.

TF는 기존 정보보호 규정의 데이터 등급을 그대로 가져와 네 단계로 정리하고, 학생 성적·상담 기록을 개인정보 등급으로 분류했다. 범주표에서 학생 과제의 채점 보조는 "승인 플랜에서 학번·이름과 본문 속 식별 정보를 지우고, 최종 점수는 교원이 정한다"는 조건부로 두었다. 이름만 지워도 과제 내용으로 학생을 알아볼 수 있기 때문이다. 입학처의 상담 챗봇은 외부 이용자에게 직접 답하는 서비스이므로 심화 경로로 올리고, AI 상담임을 알리는 문구와 답변 범위 제한, 사람 연결 경로를 조건으로 붙였다.

연구처는 해외 공동연구 과제마다 계약 조건이 다르다며 일괄 규칙에 반대했다. TF는 연구 데이터를 과제별 예외 절차로 처리하되 승인서에 계약 조건과 만료일을 적게 했다. 개인 계정 전면 금지안은 접고, 학교 계정의 승인 도구를 먼저 모든 교직원에게 연 뒤 한 학기 후 개인 계정 사용률을 다시 조사하기로 했다.

관리자 설정으로는 SSO 연동, 보존 기간 설정, 피드백 제출 끄기를 적용했고, 입학처 챗봇은 웹 검색을 끄고 공식 안내 자료만 참조하게 했다. 시행 첫 달에는 학과별 10분짜리 사례 교육을 돌렸다.

도토리게임즈: 환불을 처리하는 상담 에이전트

온라인 게임사 '도토리게임즈'는 고객 문의에 답하는 상담 에이전트에 결제 조회, 환불 실행, 게임 아이템 지급 기능을 붙이려 한다. 고객센터는 상담 대기 시간을 줄이고 싶어 했고, 보안팀은 에이전트가 잘못된 지시를 받아 대량 환불이나 아이템 지급을 하는 상황을 걱정했다.

정보보호 담당자는 기능을 행동 단위로 나누어 권한표를 만들었다. 결제 내역 조회는 질문한 고객 본인 계정으로만, 읽기 전용으로 허용했다. 환불은 규정상 자동 환불 대상인 소액 건만 에이전트가 실행하고, 그 이상과 환불 거절은 상담원이 판단하게 했다. 고객에게 불리한 결정을 사람 없이 내리지 않으려는 것이다(3장 자동화된 결정). 아이템 지급은 장애 보상처럼 미리 정해진 목록 안에서만, 하루 건수와 계정당 수량 상한을 결제 시스템이 직접 강제하게 했다. 상한을 모델 지시문에만 적는 방식은 받아들이지 않았다. 지시문은 프롬프트 인젝션으로 무력화될 수 있기 때문이다.

고객이 보낸 첨부 이미지나 외부 링크의 내용이 에이전트의 행동을 바꾸지 않도록, 그런 입력이 들어온 대화에서는 행동 도구를 쓰지 않고 상담원에게 넘기게 했다. 모든 도구 호출은 입력, 호출한 도구, 인자, 결과와 함께 기록하고, 환불 건수가 평소의 세 배를 넘으면 에이전트의 행동 도구를 자동으로 끄는 스위치를 두었다. 고객에게는 대화 시작 화면에서 AI 상담원이라는 사실을 알렸다.

출시 전 TF는 일부러 악성 지시를 섞은 시험 대화로 권한표가 실제로 막는지 확인했다. 결론은 "조회 허용, 소액 환불 조건부 허용, 그 밖의 금전 행동은 사람 승인"이었고, 3개월 뒤 기록을 보고 범위를 다시 정하기로 했다.

자주 틀리는 지점

1. "전면 금지가 가장 안전하다." 대안 없는 금지는 보이지 않는 곳의 사용을 늘립니다.
2. "모든 사용을 똑같이 조건부로 두면 공평하다." 위험에 비례하지 않는 통제는 막아야 할 것은 놓치고 열어도 될 것은 막습니다.
3. "규정부터 쓰고 현황은 나중에 본다." 무엇을 쓰는지 모르면 규정이 현실과 어긋납니다. 등록부가 먼저입니다.
4. "개발팀이 가장 잘 아니 위험 수용도 개발팀이 정한다." 평가 자료는 개발팀이 만들되, 수용 결정은 독립된 검토를 거친 상위 권한자가 합니다.
5. "조직 단위에서 끄면 무조건 차단된다." Gemini 앱은 구성 그룹 설정이 조직 단위 설정보다 우선합니다.
6. "AI는 권한 있는 것만 보여 주니 권한 정리는 필요 없다." 권한이 잘못 열린 파일이 바로 답에 나옵니다. 배포 전 정리가 필요합니다.
7. "에이전트의 금지 사항은 지시문에 적으면 된다." 한도와 승인은 모델 밖의 시스템이 강제해야 합니다.
8. "사람이 승인 버튼을 누르면 사람의 검토다." 정보, 시간, 권한이 없고 측정도 하지 않는 승인은 형식에 그칩니다.

한눈에 정리

• 거버넌스는 AI 사용 현황 등록부에서 시작한다. SaaS에 추가된 AI 기능도 찾는다.
• 정책·표준·절차·안내문을 나눠 원칙은 느리게, 안내는 빠르게 고친다.
• 범주는 데이터 등급 × 도구 조건 × 용도의 영향 × 실행 권한으로 정한다.
• 승인은 간소·일반·심화로 나누고 승인 범위를 적는다. 예외에는 만료일과 보완 통제를 둔다.
• 만든 사람과 위험을 수용하는 사람을 나누고, 위험 등급별 수용 권한을 정한다.
• 규정 조건은 관리자 설정으로 구현하고 일반 사용자 계정으로 동작을 확인한다.
• AI 검색 배포 전 권한을 정리한다.
• 에이전트는 최소 권한, 행동 전 확인, 시스템이 강제하는 한도, 기록, 중단 스위치.
• 섀도 AI는 승인 도구 제공, 짧은 기준, 직무별 교육, 재측정으로 줄인다.
• 공급자 인증은 우리의 위험 평가를 대신하지 않는다.

공식 문서로 확인하기

• Google Workspace Admin Help — Turn the Gemini app on or off: 조직 단위·그룹 설정과 우선순위, 대화 기록 보존.
• Anthropic — Configure custom data retention controls for Enterprise plans: 맞춤 보존 기간과 권한.
• Microsoft Learn — Data, privacy, and security for web search in Microsoft Copilot: 웹 검색 관리자 정책과 사용자 토글.
• Microsoft Learn — Data, Privacy, and Security for Microsoft Copilot: 권한 모델, 에이전트 관리, Purview 보존.
• NIST AIRC — AI RMF Core: GOVERN 1.6, 1.7, 2.1, 2.3, 6.1과 MANAGE 2.4, 3.1.
• OWASP — Top 10 for LLM Applications: 프롬프트 인젝션, 과도한 권한.

셀프 체크

4-1. AI 사용 현황 등록부에 둘 열을 다섯 개 이상 쓰고, 등록부를 만들 때 가장 놓치기 쉬운 AI 사용이 무엇인지 쓰라.

4-2. 정책, 표준, 절차, 안내문의 차이를 하나의 예(예: 고객 개인정보 입력)로 각각 한 문장씩 써서 보여라.

4-3. 같은 승인 도구를 쓰더라도 사용 범주가 한 단계 올라가야 하는 경우를 용도와 실행 권한 관점에서 두 가지 쓰라.

4-4. 예외 승인서에 반드시 들어가야 할 항목을 다섯 개 이상 쓰고, 같은 예외가 반복될 때 담당자가 할 일을 쓰라.

4-5. 관리자가 AI 서비스 설정을 바꾼 뒤 일반 사용자 계정으로 동작을 다시 확인해야 하는 이유를, 설정이 겹치는 경우를 예로 들어 설명하라.

4-6. 에이전트가 할 수 있는 행동 가운데 사람의 사전 승인을 두어야 할 행동의 특징을 쓰고, 한도를 지시문이 아닌 시스템에 두어야 하는 이유를 쓰라.

4-7. (설계) 직원 300명 규모의 가상 회사를 정하고, 데이터 등급 네 단계와 도구 두 종류로 범주표를 만든 뒤, 조건부 칸마다 관리자 설정으로 구현할 수 있는지 표시하라.

실습 과제