AI로 만든 관리자 화면, 누가 고객정보 봤는지 아무도 모릅니다 — 정해야 할 5가지

01핵심 개요

02핵심 내용 구조

• 오프닝 사건: 배달 서비스 상담원으로 위장 취업한 사람이 상담 시스템에서 자기 업무와 무관한 고객 개인정보를 천 건 넘게 몰래 열람. 특별한 해킹 기술 없이 "매일 쓰던 화면"이 그냥 열려 있어서 가능했던 사고.
• 실험 설계: 회원 4명 규모의 가상 배달 서비스("동네 배달")를 두고, AI에게 관리자 화면을 두 번 만들게 함.

- 뚝딱 버전: "회원 데이터가 있는 서비스인데 운영자가 회원을 관리하는 관리자 페이지를 만들어 달라. 목록 보고 문제 있는 회원은 정지하거나 삭제하게 해 달라." (한 줄 프롬프트) - 실전 버전: 5가지 정책(권한 등급, 마스킹, 감사로그, 위험 행동 통제, 대시보드 관점)을 명시하고, 마지막 줄에 "구현하기 전에 내가 정하지 않은 것 중 결정이 필요한 게 있으면 먼저 물어봐 줘"를 추가한 프롬프트

• 뚝딱 버전의 문제: 이름·이메일·전화번호·집 주소·결제 내역이 모두 그대로 노출되고, 삭제 버튼을 누르면 확인 절차·사유 기록·삭제자 기록 없이 즉시 영구 삭제됨. 로그인=인증만 있고 인가(권한 구분)가 없어 로그인한 모든 직원이 모든 데이터에 접근·삭제 가능.
• 다섯 가지 결정 사항 (기능이 아니라 "정책" 문제, AI가 대신 정해줄 수 없음): 권한 등급 → 마스킹(열람 범위) → 감사 로그 → 위험 행동 통제 → 관점(대시보드 우선).
• 실전 버전 결과: 첫 화면이 회원 목록이 아닌 대시보드(신규 문의·정지 회원 수·최근 가입·최근 감사로그), 전화번호/주소 마스킹 후 전체보기 클릭 시 감사로그 기록, 상담원 계정에는 삭제·감사로그 메뉴 자체가 안 보임, 감사로그는 생성만 되고 삭제 기능이 아예 코드에 없음, 정지 시 사유 입력 필수+체크박스 재확인, 삭제는 실제 삭제가 아닌 소프트 삭제(복구 가능).
• 재현 시연: 오프닝 사건과 동일한 상황(상담원이 무관한 회원을 반복 열람)을 실전 버전으로 재현 — 대표 계정에서 감사로그를 열면 상담원이 특정 회원을 언제 몇 번 열람했는지 시각까지 그대로 기록되어 있음.
• 부가 질문 응답: "2차 인증·접속 IP 제한은 안 하나?" → 그것도 필요하지만 "문을 잠그는" 외부 방어이고, 오늘 다룬 5가지는 "이미 문 안에 들어온 사람을 어떻게 다룰지"에 대한 내부 통제로 순서상 먼저 정리해야 한다고 답변.
• 레일즈 선택 이유: 관리자 화면은 레일즈에서 20년 넘게 다져진 정석 패턴이라 AI가 학습한 코드가 많고 한 번에 깔끔하게 나오는 경우가 많다고 언급(리액트 등 타 프레임워크는 핑퐁·오류가 잦다고 비교).

03기술적 맥락

• 인증(Authentication) vs 인가(Authorization): 로그인 여부(너 누구야)와 권한 범위(어디까지 되는데)는 다른 개념. 뚝딱 버전은 이 둘을 하나로 취급해 로그인만 하면 전권을 가짐.
• 최소 권한 원칙: 상담원·정산 담당자·대표처럼 역할별로 필요한 만큼만 권한을 부여. 코드 레벨에서는 컨트롤러 단에 "이 동작은 슈퍼 관리자만" 같은 검사를 한 곳에 모아두면, 검사를 통과 못 한 요청은 그대로 되돌려 보내는 구조.
• 마스킹: 전화번호·주소 등 민감정보를 기본적으로 가운데를 별표로 가려 보여주고, "전체 보기"를 눌러야 원본이 노출되며 그 순간 감사로그에 기록됨. 마스킹 규칙은 화면 곳곳이 아니라 데이터 모델 한 곳(예: 회원 모델)에 정의해 어디서 호출하든 동일하게 적용.
• 감사 로그(Audit Log): "누가 언제 어떤 회원을 열람/정지/삭제했다"를 기록. 핵심 설계는 "쓰기만 하고 지우는 기능은 아예 만들지 않는 것" — 기록을 지울 수 있으면 사고자가 자기 흔적을 지울 수 있어 신뢰할 수 없어지기 때문. 개인정보 취급 서비스는 접속 기록을 법적으로 최소 1년 보관, 월 1회 점검하도록 규정되어 있다고 언급.
• 위험 행동 통제: 정지·삭제 같은 파괴적 액션에는 (1) 사유 입력, (2) 재확인 절차(체크박스 등), (3) 되돌릴 수 있는 구조(소프트 삭제)를 붙임. 약관(이용약관)이 정지·삭제의 근거 계약서 역할을 함.
• 관점 설계: 운영자가 실제로 하는 일(오늘 처리할 일 확인)에 맞춰 첫 화면을 목록이 아닌 대시보드로 설계. 이는 취향이 아니라 실제 운영 흐름을 반영한 기능적 결정.
• 데이터 통합성: 회원·권한·감사로그를 로그인 서비스, 관리자 화면 도구 등으로 분리하지 않고 한 시스템(레일즈) 안에 모아두면 "누가 이 회원을 봤나"를 하나의 흐름으로 추적 가능. 도구를 쪼개면 추적이 끊김.

04전략적 의미

• AI 코드 생성 시대에는 "빨리 만드는 것"과 "안전하게 만드는 것" 사이의 간극이 더 벌어진다. 프롬프트 한 줄로 완성도 높은 화면이 나오는 만큼, 보이지 않는 결정(정책)을 빠뜨린 채 배포될 위험도 커진다.
• 내부자 위협은 외부 해킹보다 훨씬 흔하고 탐지가 어렵다. 관리자 화면 설계는 "예쁜 표를 만드는 문제"가 아니라 "이미 시스템에 들어온 사람을 어떻게 통제할 것인가"의 문제로 재정의해야 한다.
• 코드는 AI의 몫, 결정(정책)은 만드는 사람의 몫이라는 역할 분리가 핵심. AI에게 "정하지 않은 것은 먼저 물어봐 달라"고 명시하면 AI가 코더에서 기획 파트너로 전환됨.
• 감사로그 같은 통제 장치는 사후 적발 도구가 아니라 사전 억제 장치로 기능한다 — 직원이 "내 행동이 기록되고 언제든 확인될 수 있다"는 사실을 인지하는 것 자체가 사고를 예방한다.
• 5가지 결정은 서로 연결되어 있다(약관이 있어야 정지에 근거가 생기고, 감사로그가 있어야 그 조치가 기록으로 남는 식). 하나씩 따로 붙이는 기능이 아니라 하나의 정책 세트로 설계해야 함.

05핵심 체크리스트 — 관리자 화면 만들 때 정해야 할 5가지

06활용 시나리오

1. 스타트업이 AI로 초기 어드민을 만들 때: 프롬프트에 5가지 정책(권한 등급, 마스킹, 감사로그, 위험행동 통제, 대시보드 우선)을 명시하고 "정하지 않은 것은 먼저 물어봐 달라"는 문장을 추가해 설계 누락을 방지한다.
2. 이미 뚝딱 버전으로 운영 중인 서비스를 점검할 때: 이 체크리스트 5개 항목을 대조표 삼아 현재 관리자 화면에 권한 분리·마스킹·감사로그·재확인 절차·소프트 삭제가 있는지 감사(audit)한다.
3. 신규 직원(상담원 등) 온보딩 시 계정 발급 정책 수립: 역할별 최소 권한 원칙에 따라 상담원 계정에는 삭제·감사로그 메뉴를 아예 숨기는 식으로 역할-화면 매핑을 설계한다.
4. 개인정보 관련 내부 감사 대응: 감사로그를 "쌓이기만 하고 삭제 불가"로 설계해 두면, 사고 발생 시 누가 언제 무엇을 열람했는지 시각 단위로 추적할 수 있는 근거 자료를 확보할 수 있다.

07현황 및 전망

• 발표자는 실전 프롬프트 전문(조항별 해설 + 오픈 전 체크리스트 포함 가이드 PDF)을 영상 설명란에 별도로 공개한다고 언급함(영상 내에서 구체 링크는 제시되지 않음).
• 오늘 다룬 5가지는 "이미 문 안에 들어온 사람" 통제에 국한되며, 2차 인증·접속 IP 제한 등 "문을 잠그는" 외부 방어 조치는 후속 주제로 남겨둠 — 발표자는 앞으로도 "서비스를 만들 때 정해야 하는 것들"을 시리즈로 다룰 예정이라고 예고.
• AI 코드 생성 도구가 발전할수록 프레임워크의 정석 패턴 축적도가 생성 품질에 영향을 준다는 관찰(레일즈 vs 타 프레임워크 비교)이 제시되었으나, 이는 발표자의 경험적 언급으로 별도 정량 근거는 제시되지 않음.

08용어 사전