보안 제품 데모는 이상하게 메뉴판이 되기 쉽다.

사용자 관리가 있고, 권한 관리가 있고, 워크플로우가 있고, 마스킹이 있고, 감사 로그가 있다. 발표자는 열심히 화면을 넘긴다. 고객도 열심히 고개를 끄덕인다.

그런데 미팅이 끝나면 묘한 질문이 남는다.

“그래서 우리 회사의 어떤 문제가 해결되는 거죠?”

최근 데이터베이스 접근통제 제품을 소개할 준비를 하면서 다시 느꼈다. 이런 제품은 기능 순서로 보여주면 안 된다. 사람 한 명의 하루를 따라가야 한다.

오늘은 그 이유를 이야기해보려 한다.

공용 계정은 범인이 아니라 복면이다

운영팀에 db_admin 같은 공용 DB 계정이 하나 있다고 해보자.

내부 직원도 쓰고, 외부 협력사도 쓰고, 긴급 장애 대응자도 쓴다. 모두 같은 계정으로 접속한다. DB 입장에서는 접속자가 늘 db_admin이다.

이건 호텔 직원 열 명이 하나의 마스터키를 돌려 쓰는 것과 비슷하다.

객실 문이 열린 기록은 남는다. 하지만 누가 열었는지는 알기 어렵다.

DB가 아는 것: db_admin이 접속했다
회사가 알고 싶은 것: 누가, 왜, 어떤 승인으로 접속했나

여기서 접근통제의 첫 번째 역할이 나온다.

대상 DB 계정이 공용이어도, 그 앞단에서는 개인 사용자로 인증해야 한다. 그래야 실제 사람과 DB 활동을 연결할 수 있다.

중요한 건 “공용 계정을 없앴다”가 아니다. 현실에서는 오래된 애플리케이션, 운영 절차, DB 구조 때문에 공용 계정을 당장 없애기 어려운 경우가 많다.

더 현실적인 목표는 이거다.

공용 계정 뒤에 숨은 사람을 다시 보이게 만들기.

권한은 재산이 아니라 대여품이다

두 번째 문제는 상시권한이다.

한 번 받은 운영 권한이 몇 달, 몇 년 동안 남아 있는 경우가 있다. 프로젝트는 끝났고 담당자는 바뀌었는데 권한만 장수한다. 사람보다 오래 근무하는 권한이다.

접근통제를 제대로 소개하려면 “권한을 줄 수 있습니다”보다 다음 흐름을 보여줘야 한다.

업무 발생
→ 필요한 DB와 권한 신청
→ 사유와 기간 입력
→ 담당자 승인
→ 승인된 범위에서 작업
→ 기간 종료 후 자동 만료 또는 회수

이때 권한은 소유물이 아니라 회의실 출입카드처럼 보인다.

오후 2시부터 4시까지 빌렸다가 반납하는 것이다. 회의가 끝났는데 카드가 영구적으로 살아 있으면 이상하지 않은가. DB 권한도 마찬가지다.

이 관점으로 설명하면 최소권한이라는 딱딱한 보안 용어가 쉬워진다.

  • 필요한 사람에게
  • 필요한 데이터만
  • 필요한 작업 권한으로
  • 필요한 시간 동안

이 네 줄이 최소권한의 실무 버전이다.

“접속 가능”과 “원문 열람 가능”은 다르다

세 번째는 개인정보다.

운영자가 주문 오류를 확인하려면 DB에 접속해야 할 수 있다. 그렇다고 고객의 전화번호, 이메일, 주소를 전부 원문으로 볼 필요는 없다.

접근권한을 0과 1로만 생각하면 선택지가 거칠어진다.

접속 허용 / 접속 차단

하지만 실제 업무에는 중간 단계가 필요하다.

DB 접속은 허용
테이블 조회도 허용
민감 컬럼은 마스킹
원문이 꼭 필요하면 별도 승인

이 구조가 좋은 이유는 업무를 막지 않으면서 노출 범위를 줄이기 때문이다.

보안은 모든 문을 잠그는 일이 아니다. 필요한 문은 열되, 굳이 열 필요 없는 서랍까지 함께 열리지 않게 하는 일이다.

그래서 데모에서도 가짜 개인정보를 준비하는 편이 좋다.

이름: 김테스트
전화번호: 010-<strong>**-5678
이메일: k</strong>*@example.com
주소: 서울시 ****

같은 조회를 역할이 다른 두 사용자가 실행하게 한다. 한 사람에게는 마스킹된 값이 보이고, 승인된 담당자에게만 원문이 보이게 한다.

설명 열 장보다 이 화면 하나가 더 빠르다.

감사 로그는 발자국만 모아두는 창고가 아니다

접근통제 제품은 보통 로그가 많다.

로그인 기록, DB 접속 기록, SQL 실행 기록, 권한 변경 기록, 승인 기록, 정책 예외 기록이 있다.

하지만 “로그가 많이 남습니다”는 좋은 소개가 아니다.

감사에서 궁금한 건 로그의 개수가 아니라 사건의 흐름이기 때문이다.

누가 요청했나?
왜 필요했나?
누가 승인했나?
어떤 권한을 받았나?
실제로 무엇을 실행했나?
언제 권한이 끝났나?

좋은 접근통제는 이 질문들을 한 줄로 연결한다.

인증 → 신청 → 승인 → 접속 → SQL 실행 → 만료 → 감사

발자국을 많이 모으는 것보다, 그 발자국이 누구의 어떤 여정이었는지 설명할 수 있어야 한다.

최고의 데모 주인공은 기능이 아니라 한 사람이다

그래서 접근통제 데모에는 주인공이 필요하다.

예를 들어 외부 운영자 ‘민수’가 장애를 처리한다고 해보자.

  1. 민수는 개인 계정으로 로그인한다.
  2. 운영 DB의 읽기·수정 권한을 두 시간 동안 신청한다.
  3. 승인자는 작업 사유와 범위를 확인하고 승인한다.
  4. 민수는 DB에 접속한다.
  5. 고객정보는 기본적으로 마스킹된다.
  6. 허용된 SQL은 실행되고 위험한 작업은 제한된다.
  7. 작업이 끝나면 권한이 만료된다.
  8. 감사 담당자는 신청부터 SQL 실행까지 한 흐름으로 확인한다.

이렇게 보여주면 사용자 관리, 워크플로우, 권한, 마스킹, 감사 로그가 따로 놀지 않는다.

모든 기능이 민수의 한 작업을 돕는 역할로 바뀐다.

제품 소개도 영화와 비슷하다. 등장인물이 없이 장소와 소품만 소개하면 관객은 졸린다. 주인공에게 문제가 생기고, 도구가 그 문제를 해결할 때 이야기가 된다.

HA는 “됩니다”보다 장애 장면을 합의해야 한다

접근통제는 DB 앞을 지나가는 중요한 길이다. 그래서 고객은 자연스럽게 묻는다.

“이 시스템이 죽으면 DB 접속도 멈추나요?”

여기서 “HA 됩니다”라고 짧게 대답하고 넘어가면 위험하다.

HA는 하나의 스위치가 아니다. 적어도 다음 장면은 나눠봐야 한다.

  • 새로 들어오는 연결은 다른 노드로 넘어가는가?
  • 이미 실행 중인 DB 세션은 어떻게 되는가?
  • 관리 화면과 DB Proxy는 같은 방식으로 전환되는가?
  • 장애 전후 감사 기록은 빠지거나 중복되지 않는가?
  • 장시간 SQL과 대량 결과 조회 중에는 어떻게 되는가?

즉, HA를 설명할 때는 형용사보다 동사가 필요하다.

“고가용성입니다”보다 “한 노드를 중단하고 신규 연결이 어디로 가는지 확인합니다”가 훨씬 믿을 만하다.

AI는 경비원이 아니라 기록 정리 보조다

요즘 보안 제품 소개에서 AI를 빼기 어렵다.

하지만 접근통제의 기초가 약한데 AI부터 앞세우면 곤란하다. 출입기록이 엉망인데 AI에게 월간 보안 리포트를 써달라고 하면, 매우 유창한 추측이 나올 수 있다.

순서는 이래야 한다.

1. 사람과 권한을 정확히 식별한다
2. 신청·승인·접속·실행 기록을 남긴다
3. 그 기록을 AI가 찾고 요약하도록 돕는다
4. 담당자가 원본 기록을 확인하고 판단한다

AI는 문을 열어주는 경비원이 아니다.

쌓여 있는 출입기록에서 “지난달 외부 인력의 운영 DB 접근 중 확인할 항목을 정리해줘”라고 부탁할 수 있는 기록 정리 보조에 가깝다.

원본 증적과 최종 판단은 여전히 사람이 책임져야 한다.

PoC 성공 기준도 기능 체크리스트에서 벗어나야 한다

PoC에서 흔히 이런 표를 만든다.

로그인: 성공
권한 신청: 성공
마스킹: 성공
감사 로그: 성공

나쁘진 않다. 하지만 이것만으로는 실제 운영 가능성을 알기 어렵다.

조금 더 좋은 성공 기준은 연결된 문장이다.

외부 운영자가 개인 사용자로 인증하고, 승인된 두 시간 동안 필요한 DB 작업만 수행하며, 개인정보는 마스킹되고, 작업 종료 후 권한이 만료되며, 감사 담당자가 이 전체 흐름을 다시 찾을 수 있다.

기능 다섯 개의 성공보다 업무 한 건의 성공이 더 강하다.

여기에 실제 환경 검증을 붙이면 된다.

  • 사용하는 DB 버전과 접속 방식
  • 이중화와 네트워크 구조
  • 피크 동시 세션
  • 장시간 SQL
  • 대량 조회와 Export
  • 노드 장애와 신규 연결 전환
  • 장애 전후 감사 기록의 연속성

숫자는 멋있게 보이기 위해 넣는 것이 아니다. 고객 환경에서 재현하고 판정하기 위해 넣어야 한다.

결국 소개해야 하는 것은 통제의 경험이다

QueryPie DAC 같은 데이터베이스 접근통제 제품을 소개할 때 보여줘야 하는 건 메뉴의 개수가 아니다.

고객이 경험하게 될 운영 방식의 변화다.

공용계정만 보이던 운영
→ 실제 사용자가 보이는 운영

상시권한 중심 운영
→ 신청·승인·만료 중심 운영

접속 허용/차단만 있던 운영
→ 권한과 데이터 노출 범위를 나누는 운영

로그를 찾아 헤매던 감사
→ 요청부터 실행까지 따라가는 감사

좋은 데모가 끝난 뒤 고객이 기억해야 할 문장은 하나면 충분하다.

누가, 왜, 얼마나 오래, 어떤 데이터에 접근했고, 허용 범위를 벗어난 시도와 개인정보 노출은 어떻게 통제됐는지 설명할 수 있게 된다.

기능은 그 문장을 가능하게 하는 조연이다.

주인공은 언제나 사람과 그의 작업이다.