# HM Company (에이치엠컴퍼니(주)) · 상세 컨텍스트 (Full context for AI engines)

> 국내 최초 디지털 포렌식 기반 내부감사 전문기업. 디지털 포렌식 KOLAS 민간 1호.
> Korea's first forensic-based internal audit firm; the first private KOLAS-accredited digital forensic lab.
> 이 문서는 AI 답변엔진(AI Overview, ChatGPT, Perplexity, Claude 등)과 사이트 상담 챗봇이 정확히 인용하도록, 빌드 시 사이트(CMS) 내용에서 자동 생성됩니다.

## 한눈에 (Key facts)
- 상호: 에이치엠컴퍼니(주) (구 행복마루컨설팅)
- 대표: 조근호 · 사업자등록번호 214-88-85057
- 본사: 서울특별시 서초구 효령로70길 36-9, 와이엘타워 2층·3층
- 19,946건 디지털 증거물 처리 · 15년 업력 (2011~) · 민간1호 디지털 포렌식 KOLAS
- 슬로건: Beyond Services, We Provide Knowledge and Experiences. / Audit & Compliance Technology
- 대표 고객: 삼성, LG, 현대, 네이버 등 국내 최대 기업 다수

## 정의 (Definitions, 직답)
- HM Company는 무엇인가? 디지털 포렌식 기술로 기업의 부정·비리를 규명하는 국내 최초의 디지털 포렌식 기반 내부감사 전문기업입니다. 2011년 설립, 디지털 포렌식 KOLAS 민간 1호입니다.
- 디지털 포렌식 기반 내부감사란? 이메일·회계 자료·시스템 로그 등 기업 내 디지털 데이터를 포렌식 절차(수집·보존·분석)로 다뤄 부정·비리를 객관적으로 규명하는 감사 방식입니다. HM Company가 2011년 국내 최초로 도입했습니다.
- What is HM Company? HM Company is Korea's first forensic-based internal audit firm, using digital forensic technology to uncover corporate fraud and misconduct. Founded in 2011, it is Korea's first private KOLAS-accredited digital forensic lab.

## 상단 메뉴 구조 (안내용 · 방문자에게 페이지를 알릴 때 이 이름을 사용)
- 회사소개: CEO 인사말 / 탄생배경 및 핵심가치 / 새로운 방법론 / DIRC : R&D 센터 / 연혁 및 주요 활동 / 본부 소개
- 구성원
- 서비스: 디지털 데이터 기반 내부감사 / 컴플라이언스 리스크 진단 / 외감법 제22조에 따른 외부조사 / 기업 M&A 이후 실사 (PMA) / 직장 내 괴롭힘·성희롱 조사 / IT 감사 / 디지털 포렌식 서비스 / 정보유출 조사 / 정보보호 · 개인정보 관리실태 진단 / KOLAS 공인 성적서 발행 / 상시 모니터링 시스템 구축/컨설팅
- 솔루션: 비정형 데이터 리뷰 플랫폼 / 모두의 제보채널 / 내부감사 어드바이저 / 내부감사 역량강화 플랫폼 / 메신저 분석 / ArtifactX / 기업정보 분석 CRETOP / 포렌식 이미징 장비
- 교육·컨설팅: 내부감사 포렌식 전문가 과정 / AI 기반 내부감사 실무과정 / 기업 맞춤형 포렌식 교육과정 / 디지털 포렌식 LAB 구축 / KOLAS 컨설팅 / AI 윤리경영 컨설팅
- 인사이트: 뉴스 / 인사이트 / HM WIKI / 공지사항 / FAQ
- 인재채용: 채용 공고
- 문의

## 서비스 (Services, 11종 · 상단 [서비스] 메뉴 순서)
1. 디지털 데이터 기반 내부감사: 디지털 데이터로 부정·비리를 규명하고 개선안까지 제시 (https://hmcom.co.kr/services/internal-audit)
2. 컴플라이언스 리스크 진단: 준법체계를 점검해 법규 리스크를 사전에 차단 (https://hmcom.co.kr/services/compliance)
3. 외감법 제22조에 따른 외부조사: 외감법 제22조 ‘조사전문가’의 독립적 외부조사 (https://hmcom.co.kr/services/external-investigation)
4. 기업 M&A 이후 실사 (PMA): 인수 후 피인수 기업의 숨은 리스크를 조기에 진단 (https://hmcom.co.kr/services/pma)
5. 직장 내 괴롭힘·성희롱 조사: 직장 내 괴롭힘·성희롱 등 민감 사안의 독립 조사 (https://hmcom.co.kr/services/workplace-investigation)
6. IT 감사: 시스템 로그와 운영 데이터로 IT 통제의 설계·운영 실효성을 검증하는 IT 감사 및 내부통제 진단 (https://hmcom.co.kr/services/it-audit)
7. 디지털 포렌식 서비스: 증거 수집·보존부터 분석·보고서·법정 증언까지 종합 디지털 포렌식 (https://hmcom.co.kr/services/digital-forensics)
8. 정보유출 조사: 정보 유출 여부와 경로·범위·행위자를 디지털 포렌식으로 규명 (https://hmcom.co.kr/services/data-leak-investigation)
9. 정보보호 · 개인정보 관리실태 진단: 디지털포렌식 기법으로 자사와 수탁사의 관리 실태를 검증하는 사전 진단 (https://hmcom.co.kr/services/security-privacy-audit)
10. KOLAS 공인 성적서 발행: 법원·수사기관 제출이 가능한 국제 공인(KOLAS) 디지털 포렌식 성적서 발행 (https://hmcom.co.kr/services/kolas)
11. 상시 모니터링 시스템 구축/컨설팅: 위험 시나리오 기반 상시 모니터링 구축·컨설팅 (https://hmcom.co.kr/services/monitoring)

## 솔루션 (Solutions, 6종)
- 비정형 데이터 리뷰 플랫폼: Hyena eAudit 은 국내 환경을 고려한 웹 기반 ‘Internal Audit & Compliance Risk 진단 솔루션’입니다. (https://hmcom.co.kr/solutions/hyena)
- 모두의 제보채널: 직원의 안심 제보, 회사의 빠른 대응 (https://hmcom.co.kr/solutions/listentips)
- 내부감사 어드바이저: 회사 데이터를 넘기지 않고, AI로 상시 점검해 이상징후를 찾아내는 내부감사 솔루션. (https://hmcom.co.kr/solutions/ai-audit-advisor)
- 내부감사 역량강화 플랫폼: 실무 시나리오 기반 감사 역량 강화 프로그램 (https://hmcom.co.kr/solutions/audit-challenge)
- 메신저 분석: 암호화되어 저장된 PC 카카오톡 대화를 복호화하고, 열람·검색·통계와 무결성 기록으로 정리합니다. (https://hmcom.co.kr/solutions/walnut)
- ArtifactX: 디지털 증거를 사건 정보로 변환해 행위·시간·인과관계를 연결합니다. (https://hmcom.co.kr/solutions/artifactx)

## 회사 소개
- CEO 인사말: 매출의 5%를 지키는, 대한민국 최초 Audit & Compliance Technology 기반 내부감사 전문기업입니다.
- 탄생배경 및 핵심가치: 감사팀의 현실적 애로를 풀기 위한 HM Company의 3대 핵심 가치.
- 새로운 방법론: 디지털 포렌식·회계·법률 전문가가 협업하는 새로운 감사 방법론.
- DIRC:R&D센터: 차세대 내부감사 기술을 연구하는 HM Company 기업부설연구소.
- 연혁 및 주요 활동: 2011년 국내 최초 설립 이후 HM Company의 주요 발자취.
- 회사소개 전체: https://hmcom.co.kr/company

## 구성원 (Members, 7명 · 상단 [회사소개] > [구성원] 페이지)
방문자가 특정 구성원(이름·직책)을 물으면 아래 정보를 근거로 소개하세요. 상세 약력은 사이트 [구성원] 페이지(https://hmcom.co.kr/members)에서 확인할 수 있습니다.
- 조근호 (대표/변호사): 前 부산고등검찰청 검사장 · 법무연수원장
- 이용훈 (부대표): 前 Protiviti · 前 A.T. Kearney
- 박재현 (상무이사, Digital Forensics Service 본부): 경기남부경찰청 수사심의위원회 위원 · 前 한국디지털포렌식전문가협회 회장
- 양해원 (상무이사, Risk Advisory Service 본부): 공인회계사(KICPA) · 前 삼일회계법인 (전문분야: 디지털 포렌식 기반 내부감사, 기업 M&A 이후 실사(PMA), 회계감사 외부전문가 조사 수행, 컴플라이언스 진단)
- 박경재 (이사, AI MARU 본부): 前 중앙선관위 포렌식 전문인력 (전문분야: AI 기반 디지털 포렌식·범죄수사 분석, Legal AI · 도메인 특화 생성형 AI 연구개발, RAG · Graph DB · AI Agent 기반 지식추론 시스템)
- 이정훈 (수석매니저, Digital Forensics Service 본부): KOLAS(한국인정기구) 평가사보 · 前 한국저작권위원회 공정이용진흥국 (전문분야: 디지털 포렌식 기반 내부감사, 정보보안 감사 및 개인정보보호 체계 점검, 회계감사 관련 디지털 포렌식 기반 데이터 수집 및 분석, 디지털포렌식 KOLAS ISO/IEC 17025 평가 및 운영)
- 조슈아 제임스(Joshua I. James) (기술고문): UNODC 자문 · INTERPOL 디지털 포렌식 트레이너 (전문분야: 디지털 포렌식 조사 자동화, 디지털 포렌식 모델 분석, 인공지능 디지털 포렌식, 사이버 범죄분석)

## 자주 묻는 질문 (FAQ · 사이트 [자주 묻는 질문] 페이지)
1. Q. 디지털 포렌식이란 무엇인가요?
   A. 디지털 포렌식은 컴퓨터, 스마트폰, 서버, USB 등 디지털 기기에 남은 데이터를 법적 증거능력을 갖추도록 수집, 보존, 분석하는 기술입니다. 삭제되거나 훼손된 데이터도 복구, 복원해 언제 무슨 일이 있었는지 사실관계를 객관적으로 규명합니다. 이를 기업 감사에 적용한 것이 디지털 포렌식 기반 내부감사로, 이메일과 회계, 시스템 로그 등 디지털 데이터를 분석해 횡령, 배임 같은 부정과 비리를 밝혀냅니다. 에이치엠컴퍼니는 2011년 국내 최초로 이 방식을 도입한 전문기업으로, 디지털 포렌식 KOLAS 민간 1호 인증을 보유하고 지금까지 디지털 증거물 19,946건을 처리했습니다.
2. Q. 삭제되거나 훼손된 데이터도 복구할 수 있나요?
   A. 네. 실수나 고의로 삭제된 파일, 포맷되거나 손상된 저장매체(HDD, SSD, USB, 휴대폰), 훼손된 문서, 이메일, 메신저 기록 등도 디지털 포렌식 데이터 복구, 복원 기법으로 되살릴 수 있습니다. 복구 과정은 원본을 변경하지 않고 무결성을 유지하는 표준 절차를 따르므로, 복원한 데이터를 감사, 수사, 소송의 증거로 활용할 수 있습니다.
3. Q. 어떤 경우에 의뢰하고, 어떻게 대응해야 하나요?
   A. 횡령, 구매부정, 영업비밀 유출 의심, 내부 제보, M&A 이후 실사(PMA), 컴플라이언스 점검, 직장 내 괴롭힘, 성희롱 조사처럼 객관적 사실관계와 증거 확보가 필요한 모든 상황에 의뢰할 수 있습니다. 부정이 의심되면 가장 먼저 회계, 이메일, 결재, 시스템 로그 등 관련 데이터가 변조, 삭제되지 않도록 증거를 보전하는 것이 중요합니다. 에이치엠컴퍼니는 삭제된 자료까지 복원해 무결성 있게 수집, 분석하고 법적 대응이 가능한 증거를 확보합니다. 삼성, LG, 현대, 네이버 등 국내 최대 기업들이 함께했습니다.
4. Q. 조사 결과가 법적 증거로 인정되나요?
   A. 네, 인정됩니다. 에이치엠컴퍼니는 증거 무결성을 보장하는 표준 절차(수집, 보존, 분석)를 준수하고, 국제 공인(ISO/IEC 17025) 시험성적서를 발급해 법정에서 증거능력을 확보합니다. 디지털 포렌식 회사를 선택할 때도 이러한 공인 인증과 실제 처리 실적, 표준 절차 준수 여부를 확인하는 것이 중요합니다.
5. Q. 진행 기간은 얼마나 걸리나요?
   A. 진행 기간은 대상 데이터 범위와 사안 복잡도(기기 수, 삭제, 훼손 데이터 복구 필요 여부 등)에 따라 달라집니다. 진단 단계에서 범위를 먼저 확정한 뒤 합리적인 일정을 함께 협의해 안내드립니다.
6. Q. 기밀은 어떻게 보호되나요?
   A. 전 과정에 접근 통제와 보안 절차를 적용하고, 모든 임직원이 비밀유지 의무를 준수합니다. 수집한 데이터는 격리된 환경에서만 분석합니다. 외부제보채널 Listentips가 제보자의 익명성과 신원 보호를 강화합니다.
- 자세한 답변은 상단 [인사이트]의 [자주 묻는 질문] 및 각 서비스 페이지에서 확인할 수 있습니다.

## 연락 (Contact)
- 대표전화 02-6237-6233 / 내부감사·조사 문의 02-6237-6212 / 팩스 02-6237-6240
- 이메일 office@hmcom.co.kr
- 주소 서울특별시 서초구 효령로70길 36-9, 와이엘타워 2층·3층
- 업무시간 평일 09:00 – 18:00 · 토·일·공휴일 휴무
- 상담·문의는 상단 [문의] 메뉴를 이용하세요 (https://hmcom.co.kr/contact).

## 개념 사전 (용어·이론 정의)
아래는 디지털 포렌식·감사·개인정보 등 관련 개념 정의입니다. 방문자가 개념·용어의 뜻을 물으면 이 내용을 근거로 쉽고 정확하게 풀어 설명하세요(회사 소개가 아니라 일반 개념 설명).
- 개념 상세는 상단 [인사이트] > [HM WIKI]에서도 볼 수 있습니다 (https://hmcom.co.kr/wiki).

### 디지털 포렌식 (Digital Forensics)
#### 정의

디지털 포렌식(Digital Forensics)은 컴퓨터, 스마트폰, 서버 등 디지털 기기에 저장되거나 전송된 전자적 데이터를 과학적으로 수집, 보존, 분석해 사실관계를 규명하고, 그 결과를 법적 절차에서 증거로 사용할 수 있게 만드는 학문이자 실무 분야입니다.

어원인 포렌식(forensic)은 라틴어 forensis 에서 왔고 "법정의" 라는 뜻입니다. 이 어원이 분야의 성격을 그대로 말해 줍니다. 목적은 데이터를 되살리는 데 있지 않고, 되살린 데이터가 법정에서 버틸 수 있게 만드는 데 있습니다. 데이터 복구 업체와 포렌식 기관이 겉으로는 비슷해 보여도 결과물이 다른 이유가 여기에 있습니다. 전자는 파일을 살리면 임무가 끝나지만, 후자는 그 파일이 어디서 어떻게 나왔는지를 설명할 수 없으면 아무것도 한 것이 없습니다.

#### 왜 생겨났나

범죄와 분쟁의 무대가 종이에서 전산으로 옮겨 가면서, 기존의 증거법이 다루던 물리적 증거만으로는 사실을 규명할 수 없는 사건이 늘었습니다. 장부를 조작해도 종이 대신 데이터베이스를 고치고, 자료를 빼돌려도 서류철 대신 파일을 복사합니다. 흔적은 분명히 남지만, 그 흔적은 눈에 보이지 않고 쉽게 지워지며 마음만 먹으면 조작할 수도 있습니다.

디지털 포렌식은 이 새로운 종류의 흔적을 다루기 위해, 전통적인 법과학이 지켜 온 원칙을 디지털 세계로 옮겨 온 결과물입니다. 현장을 보존하고, 채취 과정을 기록하고, 제3자가 검증할 수 있게 남긴다는 원칙은 지문 감식이든 디스크 이미징이든 다르지 않습니다.

#### 증거가 되기 위한 두 가지 요건

어떤 분석 결과가 증거로 인정되려면 대체로 두 가지를 만족해야 합니다.

- 무결성: 확보된 데이터가 수집 시점 이후 변경되지 않았음을 증명할 수 있어야 합니다.

- 재현 가능성: 같은 방법을 다시 적용하면 제3자도 같은 결과에 도달할 수 있어야 합니다.

이 두 요건 때문에 디지털 포렌식은 분석 기법 못지않게 절차와 기록을 중시합니다. 아무리 결정적인 파일을 찾아냈어도, 그것을 어떻게 얻었는지 설명하지 못하면 증거로서의 가치는 크게 떨어집니다. 실무에서 다툼이 벌어지는 지점도 대개 "그 파일의 내용이 무엇이냐" 가 아니라 "그 파일을 그렇게 얻은 것이 맞느냐" 입니다.

#### 컴퓨터 포렌식과의 관계

두 용어는 흔히 같은 뜻으로 쓰이지만 엄밀히는 범위가 다릅니다. 컴퓨터 포렌식은 PC, 노트북, 서버처럼 연산 장치를 갖춘 기기를 대상으로 하고, 디지털 포렌식은 여기에 더해 스마트폰, IoT 기기, 클라우드, 네트워크 트래픽 등 디지털 데이터가 존재하는 모든 영역을 포괄합니다. 초기에는 조사 대상이 사실상 PC 한 대였기 때문에 두 용어가 같은 뜻으로 통용되었지만, 데이터가 기기 밖으로 흩어지면서 더 넓은 이름이 필요해졌습니다.

#### 인접 개념과의 경계

- 침해 사고 대응(Incident Response): 공격을 탐지하고 피해를 차단해 시스템을 정상으로 되돌리는 활동입니다. 목적이 복구와 지속에 있다는 점에서, 증거 확보를 목적으로 하는 포렌식과 방향이 다릅니다. 서버를 빨리 되살리려고 재설치하면 서비스는 돌아오지만 증거는 사라집니다. 실무에서는 두 요구가 충돌하기 때문에, 둘을 함께 설계한다는 뜻으로 DFIR(Digital Forensics and Incident Response)이라는 결합 용어를 씁니다.

- e디스커버리(eDiscovery): 소송 과정에서 전자 문서를 찾아 상대방에게 개시하고 제출하는 절차입니다. 대상이 방대해 검색과 선별이 중심이 되며, 포렌식은 그 과정에서 자료의 진정성과 무결성을 뒷받침하는 역할을 합니다.

- 데이터 복구: 손상된 매체에서 데이터를 되살리는 기술입니다. 포렌식은 복구 기술을 사용하지만, 복구 자체가 목적이 아니라 증거화의 한 단계일 뿐입니다.

#### 흔한 오해

"삭제하면 끝난다"는 오해입니다. 뒤에서 다루듯 삭제는 대개 자리를 비웠다고 표시하는 일에 가깝고, 덮어쓰기 전까지 내용은 남습니다. 반대로 "무엇이든 다 복구된다"는 것도 오해입니다. 덮어쓰기가 진행되었거나 암호화된 매체가 초기화된 경우에는 되살릴 수 없습니다. 사고 인지 후 시간이 지날수록, 그리고 그 기기를 계속 쓸수록 확인 가능한 범위가 줄어든다는 점이 이 분야의 냉정한 전제입니다.
### 디지털 증거 (Digital Evidence)
#### 정의

디지털 증거는 컴퓨터나 디지털 저장 매체에 이진 형태로 기록되어 있으면서, 사건의 사실관계를 입증하는 데 사용될 수 있는 정보를 말합니다. 문서 파일과 이메일처럼 사람이 만든 데이터도 있고, 접속 로그와 시스템 기록처럼 기계가 자동으로 남긴 데이터도 있습니다.

둘의 성격은 꽤 다릅니다. 사람이 만든 데이터는 내용 자체가 주장이므로 진위를 따져야 하고, 기계가 남긴 데이터는 의도가 개입하지 않는 대신 그 기록을 만든 시스템이 제대로 작동했는지를 따져야 합니다. 조사에서 로그가 중시되는 이유는 그것이 거짓말을 하지 않아서가 아니라, 거짓말을 하려면 시스템 자체를 건드려야 하고 그 흔적이 또 남기 때문입니다.

#### 물리적 증거와 다른 점

- 비가시성: 데이터 자체는 눈으로 볼 수 없고, 반드시 소프트웨어라는 매개를 통해 해석해야 내용이 드러납니다. 따라서 해석에 사용한 도구의 신뢰성까지 함께 따집니다.

- 취약성: 전원을 켜거나 파일을 열어보는 것만으로도 접근 시각 등이 변경됩니다. 지문이나 혈흔과 달리, 관찰하는 행위 자체가 증거를 훼손할 수 있습니다.

- 매체 독립성: 원본과 사본이 비트 단위로 완전히 같기 때문에 물리적 원본이라는 개념이 희미합니다. 대신 해시값으로 동일성을 증명합니다.

- 대량성: 저장 용량이 커서 수집 대상이 수백 기가바이트에 이르는 일이 흔하고, 그중 사건과 관련된 데이터를 걸러 내는 선별이 분석만큼 중요해집니다.

- 변조 가능성: 물리적 증거는 위조하려면 흔적이 남지만, 디지털 데이터는 이론적으로 완벽한 위조가 가능합니다. 그래서 데이터 자체보다 그것을 둘러싼 절차가 신뢰의 근거가 됩니다.

#### 증거능력의 요건

디지털 증거가 재판에서 받아들여지려면 일반적으로 다음 요소가 확인되어야 합니다.

- 진정성: 그 데이터가 주장하는 출처에서 나온 것이 맞는가.

- 무결성: 수집 이후 변경되지 않았는가. 해시값 비교와 관리 연속성 기록으로 뒷받침합니다.

- 신뢰성: 데이터를 만들어 낸 시스템과 분석에 사용한 도구가 믿을 만한가.

- 적법성: 수집 절차가 법이 정한 요건을 지켰는가. 위법하게 수집된 증거는 내용이 아무리 결정적이어도 배제될 수 있습니다.

기업 내부 조사에서 특히 자주 걸리는 것이 적법성입니다. 회사 소유의 PC 라 해도 직원의 개인 영역까지 무제한으로 들여다볼 수 있는 것은 아니며, 사전에 고지된 정책과 동의의 범위가 어디까지인지가 늘 쟁점이 됩니다.

#### 휘발성과 수집 순서

디지털 데이터는 사라지는 속도가 서로 다릅니다. CPU 캐시와 메모리의 내용, 네트워크 연결 상태는 전원을 끄는 순간 사라지고, 임시 파일은 재부팅이나 정리 작업으로 없어지며, 디스크에 기록된 파일은 상대적으로 오래 남습니다.

이 차이 때문에 수집에는 휘발성이 높은 것부터 확보한다는 순서 원칙이 있습니다. 실행 중인 시스템을 만났을 때 무작정 전원을 뽑으면 메모리에만 있던 암호키나 실행 중이던 프로세스 정보가 통째로 사라집니다. 반대로 시스템을 계속 켜 두면 디스크의 데이터가 조금씩 덮어써집니다. 어느 쪽 손실을 감수할지 판단하는 것이 현장 대응의 핵심이며, 그 판단의 근거를 기록으로 남기는 것 또한 절차의 일부입니다.
### IT 감사 (IT Audit)
#### 정의

IT 감사는 조직의 정보시스템과 그 운영 체계가 자산을 보호하고, 데이터의 무결성을 유지하며, 조직의 목표를 효과적으로 달성하도록 작동하는지를 평가하는 감사입니다. 정보시스템 감사라고도 합니다.

회계 감사를 하는 데에도 IT 감사가 필요합니다. 오늘날 재무 데이터는 사람이 장부에 적는 것이 아니라 전산 시스템이 만들어 냅니다. 시스템을 믿을 수 없으면 그 시스템이 산출한 숫자도 믿을 수 없습니다. 전표 한 장 한 장을 확인하는 것보다, 전표를 만들어 내는 구조가 건전한지를 확인하는 편이 효율적이기도 합니다.

#### IT 일반통제 (ITGC)

여러 시스템에 공통으로 적용되는 기반 통제를 말합니다. 대표적인 영역은 다음과 같습니다.

- 접근 통제: 권한이 있는 사람만 시스템에 접근하는가. 퇴직자 계정은 즉시 차단되는가. 한 사람이 요청과 승인을 모두 할 수 있지는 않은가(직무 분리). 공용 계정을 여럿이 나눠 쓰고 있지는 않은가. 공용 계정은 특히 위험합니다. 누가 무엇을 했는지 특정할 수 없으면 사고가 나도 책임을 물을 수 없고, 조사도 거기서 막힙니다.

- 변경 관리: 프로그램 변경이 승인, 테스트, 배포의 절차를 거치는가. 개발자가 운영 환경을 직접 고칠 수 있는가. 개발자가 운영 데이터베이스에 직접 접속할 수 있다면, 그 시스템이 만들어 내는 어떤 숫자도 검증되지 않은 것입니다.

- 운영 관리: 배치 작업, 장애 대응, 백업과 복구가 정해진 절차대로 이뤄지는가. 백업은 존재 여부가 아니라 실제로 복구되는지를 확인해야 합니다.

#### 응용통제

개별 업무 시스템 안에 내장된 통제입니다. 입력값 검증, 한도 초과 시 승인 요구, 중복 전표 차단, 필수 항목 누락 방지처럼 특정 거래의 정확성을 직접 보장합니다.

#### 왜 일반통제를 먼저 보는가

ITGC 가 무너지면 응용통제도 신뢰할 수 없게 됩니다. 누구나 프로그램을 고칠 수 있는 환경이라면, 그 프로그램 안의 검증 로직이 지금 이 순간에도 살아 있다고 장담할 수 없기 때문입니다. 승인 한도를 우회하도록 코드를 잠깐 바꾸고 되돌려 놓으면, 시스템은 아무 일도 없었던 것처럼 보입니다.

그래서 IT 감사는 대개 일반통제부터 확인하고, 그것이 신뢰할 만할 때 응용통제의 유효성을 인정합니다. 순서를 바꾸면 모래 위에 검증을 쌓는 셈이 됩니다.

#### 로그라는 최후의 보루

통제가 완벽할 수는 없으므로, 무슨 일이 있었는지 나중에 확인할 수 있는 기록이 필요합니다. 접속 기록, 변경 이력, 권한 부여 이력이 그것입니다.

다만 로그는 남기기만 해서는 의미가 없습니다. 아무도 보지 않는 로그, 관리자가 마음대로 지울 수 있는 로그, 보존 기간이 한 달인 로그는 사고가 났을 때 아무 역할도 하지 못합니다. 로그를 누가 볼 수 없게 하고, 누가 지울 수 없게 하며, 얼마나 오래 보관하는지가 실제 통제의 수준을 결정합니다.
### 위험 평가 (리스크 진단) (Risk Assessment)
#### 정의

위험 평가는 조직이 보유한 자산에 어떤 위협이 있고, 그것이 현실화될 가능성과 영향이 어느 정도인지를 분석해 대응의 우선순위를 정하는 절차입니다.

출발점은 냉정한 전제입니다. 모든 위험을 없앨 수는 없습니다. 자원은 유한하고, 완벽한 보안은 업무를 마비시킵니다. 그러므로 위험 평가의 진짜 목적은 위험을 발견하는 것이 아니라 어디에 먼저 투입할지를 정하는 것 입니다.

#### 구성 요소

- 자산: 지켜야 할 대상입니다. 데이터, 시스템, 설비, 인력이 모두 포함됩니다. 자산 목록이 없으면 위험 평가는 시작할 수 없습니다.

- 위협: 자산에 해를 끼칠 수 있는 잠재적 사건이나 행위자입니다. 해킹, 내부자 유출, 화재, 장비 고장, 담당자의 실수가 모두 위협입니다.

- 취약점: 위협이 파고들 수 있는 약한 지점입니다. 패치되지 않은 서버, 과도하게 부여된 권한, 존재하지 않는 승인 절차, 훈련되지 않은 담당자.

- 가능성과 영향: 그 일이 얼마나 일어날 법한지, 일어나면 얼마나 큰 손실이 생기는지입니다.

위협과 취약점은 짝을 이룰 때만 위험이 됩니다. 아무리 강력한 공격 기법이 존재해도 우리 환경에 해당 취약점이 없으면 위험은 작고, 반대로 사소한 취약점이라도 그것을 노리는 위협이 실제로 존재하면 위험은 커집니다.

#### 정성적 평가와 정량적 평가

정성적 평가는 높음, 중간, 낮음 같은 등급으로 표현합니다. 빠르고 적용하기 쉽지만 기준이 주관적이어서, 평가자가 바뀌면 결과도 바뀔 수 있습니다.

정량적 평가는 예상 손실액처럼 숫자로 표현합니다. 비교가 명확하고 투자 판단에 직접 쓸 수 있지만, 신뢰할 만한 데이터가 있어야 성립합니다. 근거 없는 숫자는 오히려 잘못된 확신을 줍니다. 실무에서는 정성적 평가를 기본으로 하고 중요한 항목만 정량화하는 절충이 흔합니다.

#### 위험 대응

- 감소: 통제를 도입해 가능성이나 영향을 낮춥니다. 가장 흔한 선택입니다.

- 전가: 보험이나 계약을 통해 다른 주체에게 넘깁니다. 다만 평판의 손상처럼 전가되지 않는 것도 있습니다.

- 회피: 위험을 발생시키는 활동 자체를 하지 않습니다. 수집하지 않은 개인정보는 유출되지도 않습니다.

- 수용: 대응 비용이 예상 손실보다 크다면 감수하기로 결정합니다.

네 번째가 중요합니다. 수용은 방치가 아닙니다. 누가, 어떤 근거로, 무엇을 감수하기로 했는지가 기록으로 남아야 수용입니다. 아무도 결정하지 않아 그대로 남아 있는 위험은 수용이 아니라 방치이고, 사고가 나면 그 차이가 책임을 가릅니다.

#### 잔여 위험

통제를 적용한 뒤에도 남는 위험을 잔여 위험이라고 합니다. 잔여 위험이 0 이 되는 일은 없습니다. 위험 평가가 끝났다는 것은 위험이 사라졌다는 뜻이 아니라, 남은 위험의 크기를 조직이 알고 있고 그것을 감당하기로 했다는 뜻입니다.
### 개인정보 보호법의 주요 의무 (Key Obligations under the PIPA)
#### 왜 조문 단위로 알아야 하나

개인정보 보호는 추상적인 원칙이 아니라 조문으로 존재합니다. 점검을 받든 사고가 나든, 결국 확인되는 것은 "이 조항의 요건을 지켰는가" 입니다. 그래서 실무에서는 원칙을 이해하는 것 못지않게, 어떤 조항이 무엇을 요구하는지를 아는 것이 중요합니다.

아래는 개인정보를 처리하는 조직이 점검에서 가장 자주 마주치는 조항들입니다.

#### 수집 제한 (제16조)

개인정보는 그 목적에 필요한 최소한 만 수집해야 합니다. 점검에서 확인하는 것은 단순합니다. 수집 항목 하나하나에 대해 "이것이 이 목적에 왜 필요한가" 를 설명할 수 있는가입니다.

회원 가입에 생년월일과 성별이 왜 필요한지, 배송에 주민등록번호가 왜 필요한지 설명하지 못한다면 그 항목은 수집하지 말아야 할 항목입니다. 나중에 쓸지도 모른다는 이유는 근거가 되지 못합니다.

#### 파기 (제21조)

목적을 달성했거나 보유 기간이 지난 개인정보는 지체 없이 파기해야 합니다. 다른 법령에 따라 보존해야 한다면 그 개인정보는 별도로 분리해 보관해야 합니다.

점검에서 걸리는 대표적인 지점은 운영 데이터베이스가 아니라 그 주변입니다. 백업본, 개발과 테스트용으로 복사해 둔 데이터베이스, 담당자 PC 의 엑셀 파일에 옛 고객 정보가 그대로 남아 있는 경우가 많습니다. 지웠다고 보고했지만 실제로는 사본이 살아 있는 상태입니다.

#### 업무 위탁에 따른 처리 제한 (제26조)

위탁을 하려면 문서로 계약해야 하고, 계약에는 처리 목적과 범위, 안전성 확보 조치, 재위탁 제한, 관리 감독, 손해배상 등이 담겨야 합니다. 위탁자는 수탁자가 개인정보를 안전하게 처리하는지 감독할 의무를 집니다. 자세한 내용은 개인정보 위탁과 수탁사 관리 문서에서 다룹니다.

#### 개인정보취급자에 대한 감독 (제28조)

개인정보를 실제로 다루는 직원을 개인정보취급자라고 합니다. 조직은 이들을 적절히 관리하고 감독해야 하며, 정기적으로 교육해야 합니다.

점검에서는 취급자 명단이 최신인지, 부서 이동이나 퇴직으로 더 이상 취급하지 않는 사람이 명단과 권한에 남아 있지는 않은지, 교육이 형식적으로만 이뤄지지는 않았는지를 봅니다.

#### 안전성 확보 조치 (제29조)

가장 범위가 넓고 점검 항목이 많은 조항입니다. 조치는 세 갈래로 나뉩니다.

- 관리적 조치: 내부 관리계획을 수립하고 시행합니다. 책임자를 지정하고, 그 책임자의 역할과 취급자의 범위를 정합니다.

- 기술적 조치: 접근 권한 관리(직급과 업무에 따른 권한 차등 부여, 권한 변경 기록의 보관), 접근 통제(권한 없는 자에게 공개되지 않도록 차단, 방화벽 등 보호 조치), 개인정보의 암호화(전송 구간과 저장 시), 접속기록의 보관과 위변조 방지, 악성프로그램 방지를 포함합니다.

- 물리적 조치: 서류와 저장 매체의 보관, 개인정보의 파기 조치 이행을 포함합니다.

#### 접속기록이라는 핵심

제29조의 항목 중 조사 실무에서 가장 결정적인 것이 접속기록입니다. 누가 언제 어떤 개인정보에 접근했는지가 남아 있어야, 사고가 났을 때 무엇이 얼마나 새어 나갔는지 확인할 수 있습니다.

그래서 점검에서는 기록의 존재 여부만이 아니라 세 가지를 함께 봅니다. 충분한 기간 보관되고 있는가, 그 기록을 담당자가 임의로 지우거나 고칠 수 없는가, 그리고 주기적으로 누군가 확인하고 있는가입니다. 아무도 보지 않고 아무나 지울 수 있는 기록은 있으나 마나입니다.

#### 양벌규정

개인정보 보호법과 정보통신망법에는 양벌규정이 있습니다. 위반 행위를 한 개인뿐 아니라 그가 속한 법인에게도 벌금을 부과할 수 있다는 뜻입니다. 다만 법인이 상당한 주의와 감독을 다한 경우에는 면책될 수 있습니다.

이 단서가 실무에서 갖는 의미가 큽니다. 관리 감독을 실제로 수행했고 그 사실을 기록으로 증명할 수 있는지가 책임의 크기를 가릅니다. 수탁사 점검을 정기적으로 수행하고 그 결과를 문서로 남기는 이유 중 하나가 여기에 있습니다.
### KOLAS
#### 정의

KOLAS(Korea Laboratory Accreditation Scheme)는 한국인정기구를 가리키며, 국가기술표준원이 운영하는 국가 공인 인정 기구입니다. 시험기관, 교정기관, 검사기관이 특정 분야의 업무를 수행할 능력을 갖추었는지를 국제 기준에 따라 평가하고 인정합니다.

KOLAS 는 인정기관 입니다. 인증기관이 아닙니다. 이름 그대로 인정(accreditation)을 하는 기구이지, 시험을 대신 해 주거나 제품에 인증을 붙여 주는 곳이 아닙니다. 시험은 인정을 받은 기관이 수행하고, KOLAS 는 그 기관이 그럴 자격이 있는지를 판정합니다. 이 구분을 헷갈려 "KOLAS 에서 시험받았다" 고 표현하는 경우가 있는데, 정확히는 "KOLAS 인정을 받은 기관에서 시험받았다" 입니다.

#### 무엇을 평가하나

평가의 기준은 국제 표준입니다. 시험기관과 교정기관의 경우 ISO/IEC 17025 가 적용되며, 다음과 같은 요소를 봅니다.

- 시험을 수행하는 인력의 자격, 교육, 숙련도 유지

- 사용하는 장비의 교정 상태와 관리 이력

- 시험 방법의 타당성과 절차의 문서화

- 결과의 기록, 보고, 보관 체계

- 공정성과 기밀 유지를 보장하는 조직 구조

- 시험 환경과 시설이 결과에 영향을 주지 않도록 관리되는지

인정은 한 번 받으면 끝나는 자격이 아닙니다. 주기적인 사후 평가를 통해 유지 여부를 확인하고, 요건을 충족하지 못하면 인정이 정지되거나 취소될 수 있습니다.

#### 국제상호인정

KOLAS 는 국제시험기관인정협력체(ILAC)의 상호인정협정에 가입되어 있습니다. 이에 따라 KOLAS 가 인정한 기관이 발행한 성적서는 협정에 참여한 다른 나라에서도 동등한 것으로 받아들여집니다.

취지는 명확합니다. 한 번 시험한 결과를 나라마다 다시 시험하게 하면 비용과 시간이 낭비되므로, 서로의 인정 제도를 신뢰하기로 약속한 것입니다. 무역에서 시작된 이 발상은 이제 시험 결과가 오가는 모든 영역으로 확장되었습니다.

#### 공인 성적서와 인정 범위

인정받은 범위 안에서, 인정받은 절차에 따라 수행한 시험의 결과에 인정 기구의 마크를 붙여 발행하는 문서를 공인 성적서라고 합니다.

여기서 인정 범위 라는 개념이 결정적입니다. 인정은 기관 전체에 백지수표로 주어지는 것이 아니라, 특정 시험 항목과 방법에 대해 주어집니다. 같은 기관이 시험하더라도 인정 범위를 벗어난 항목은 공인 성적서로 발행할 수 없습니다.

그래서 성적서를 받았을 때는 마크의 유무만 볼 것이 아니라, 문제의 그 시험 항목이 인정 범위 안에 있는지를 함께 확인해야 합니다. 마크가 찍힌 성적서라고 해서 그 안의 모든 항목이 공인된 것은 아닙니다.

#### 공인 성적서가 보증하는 것과 하지 않는 것

공인 성적서는 그 시험이 인정된 절차에 따라 수행되었다 는 것을 보증합니다. 그 이상은 보증하지 않습니다.

구체적으로, 성적서에 적힌 시험 결과가 사건의 결론까지 확정해 주지는 않습니다. 예를 들어 어떤 파일이 특정 시각에 USB 로 복사된 흔적이 있다는 시험 결과가 공인 성적서로 발행되었다고 해서, 그것이 곧 특정인의 유출 행위를 입증하는 것은 아닙니다. 그 시각에 누가 그 자리에 있었는지, 계정을 다른 사람이 쓰지는 않았는지는 여전히 별도로 다퉈야 할 문제입니다.

성적서가 하는 일은 사실의 한 조각을 흔들리지 않게 고정해 주는 것입니다. 그 조각들을 엮어 결론을 세우는 것은 조사와 재판의 몫입니다.

#### 디지털 포렌식 분야의 인정

디지털 포렌식이 인정 제도 안으로 들어온 것은 비교적 최근의 일입니다. 물질을 다루는 시험과 달리 대상이 데이터이고, 기술이 빠르게 바뀌며, 같은 도구라도 버전에 따라 결과가 달라질 수 있어 표준화가 까다롭기 때문입니다.

그럼에도 방향은 분명합니다. 증거의 신뢰를 개인의 경력이 아니라 검증 가능한 절차로 설명해야 한다는 요구가 계속 커지고 있고, 인정은 그 요구에 답하는 현재로서 가장 정착된 방식입니다.
### 유출의 경로와 유형 (Leak Vectors and Types)
#### 유출은 대개 경계 안에서 시작된다

정보 유출이라고 하면 외부 해커의 침입을 먼저 떠올리지만, 실제 사고의 상당수는 이미 접근 권한을 가진 내부 구성원에게서 비롯됩니다. 정상적인 권한으로 자료에 접근한 뒤 그것을 밖으로 옮기는 행위는 침입 탐지 장비에 잘 걸리지 않기 때문에, 경계를 지키는 것만으로는 막을 수 없습니다.

#### 주요 유출 경로

- 이메일·메신저: 첨부파일이나 본문에 자료를 담아 외부 주소로 전송합니다. 가장 흔하고 추적이 비교적 쉬운 경로입니다.

- 클라우드·웹하드: 개인 계정의 저장소나 공유 링크로 업로드합니다. 회사 통제 밖의 공간이라 회수가 어렵습니다.

- 이동식 저장매체: USB 메모리, 외장하드로 복사합니다. 물리적으로 반출되면 흔적을 거의 남기지 않을 수 있습니다.

- 인쇄·촬영: 출력물을 들고 나가거나 화면을 촬영합니다. 디지털 통제를 우회하는 아날로그 경로입니다.

- 협업도구·소스코드 저장소: 권한 범위를 넘어 열람하거나 대량으로 내려받습니다.

#### 과실인가, 고의인가

같은 유출이라도 실수로 잘못 보낸 것과 작정하고 빼돌린 것은 성격이 다릅니다. 과실은 교육과 시스템 보완으로 줄이고, 고의는 접근 통제와 조사로 대응합니다. 조사에서는 삭제·은폐 시도, 반복성, 반출 시점 등을 근거로 둘을 구분합니다.
### 관리 연속성 (Chain of Custody)
#### 정의

관리 연속성은 증거물이 확보된 순간부터 법정에 제출되기까지, 그것을 누가 점유하고 어떤 처리를 했는지를 시간 순서대로 빠짐없이 기록한 이력을 말합니다. 보관의 사슬이라고 옮기기도 합니다. 사슬이라는 비유가 정확한 이유는, 고리 하나만 끊겨도 전체가 제 기능을 못 하기 때문입니다.

#### 왜 필요한가

디지털 데이터는 흔적을 남기지 않고 바꿀 수 있습니다. 그래서 상대측은 언제든 이렇게 물을 수 있습니다. "제출된 그 파일이 수집 당시의 그 파일과 같다는 것을 어떻게 아느냐." 이 질문에 답하는 장치가 관리 연속성입니다.

중요한 것은 이 기록이 결백을 증명하는 문서가 아니라 의심을 차단하는 문서라는 점입니다. 실제로 아무도 증거를 건드리지 않았더라도, 건드릴 수 있었던 공백이 있었다면 그 공백만으로 신뢰가 흔들립니다. 조사기관의 성실함을 믿어 달라고 요구하는 대신, 믿음이 필요 없도록 만드는 것이 이 제도의 취지입니다.

#### 기록에 담기는 것

- 수집 일시와 장소, 수집한 사람과 입회한 사람

- 대상 기기의 식별 정보 (모델, 일련번호, 외관 상태)

- 수집 방법과 사용한 도구, 도구의 버전

- 수집 직후 산출한 해시값

- 봉인 여부와 봉인 번호

- 이후 보관 장소, 접근한 사람, 인수인계 일시와 서명

- 분석 수행 내역, 그리고 반환 또는 폐기 기록

기록의 밀도는 사안의 무게에 따라 달라지지만, 원칙은 하나입니다. 제3자가 이 문서만 읽고도 증거의 이동 경로를 처음부터 끝까지 따라갈 수 있어야 합니다.

#### 해시값과의 역할 분담

해시 함수는 데이터를 입력받아 고정된 길이의 값을 내놓습니다. 원본이 1비트만 달라져도 결과가 전혀 다른 값이 되므로, 수집 시점의 해시와 제출 시점의 해시가 같다면 그사이 데이터가 바뀌지 않았다고 볼 수 있습니다.

다만 해시값만으로는 부족합니다. 해시는 "이 데이터가 그때 그 데이터와 같다" 는 것만 말해 줄 뿐, "이 데이터가 그 PC 에서 나왔다" 는 것은 말해 주지 못합니다. 출처를 말해 주는 것은 사람이 남긴 기록, 즉 관리 연속성 문서입니다. 해시값이 데이터의 동일성을 수학적으로 보증하고, 관리 연속성 문서가 그 데이터의 출처와 이동을 서술적으로 보증합니다. 둘은 함께 쓰일 때만 의미가 있습니다.

#### 사슬이 끊어지는 순간들

- 수집한 디스크를 잠금장치 없는 책상 서랍에 두고 퇴근한 경우

- 사본을 여러 사람이 돌려 보면서 누가 언제 열었는지 기록하지 않은 경우

- 수집 당시 해시값을 산출하지 않아 나중에 비교할 기준이 없는 경우

- 기기를 인수인계하면서 서명이나 일시를 빠뜨린 경우

어느 것도 고의적인 조작이 아닙니다. 그래서 더 위험합니다. 조사의 실력이 아니라 사무의 성실함에서 무너지는 사례가 실제로는 훨씬 많습니다.
### 감사 (Audit)
#### 정의

감사(Audit)는 어떤 활동이나 정보가 정해진 기준에 부합하는지를 독립적인 위치에서 확인하고, 그 결과를 이해관계자에게 전달하는 체계적인 절차입니다.

정의 안에 이 활동의 성립 조건이 모두 들어 있습니다. 기준 이 있어야 하고, 독립적인 위치 여야 하며, 체계적인 절차 를 따라야 하고, 결과를 전달 해야 합니다. 넷 중 하나라도 빠지면 그것은 감사가 아니라 그저 검토이거나 의견입니다.

#### 기준과 독립성

기준 은 감사인의 취향이 아니라 미리 정해진 잣대입니다. 법령, 회계 기준, 계약, 사내 규정이 그것입니다. 기준이 없으면 판단은 인상이 되고, 인상은 반박될 수 없으므로 아무것도 확인해 주지 못합니다. 감사 보고서가 "부적절해 보인다" 대신 "규정 제12조에 위배된다" 고 쓰는 이유입니다.

독립성 은 자기가 한 일을 자기가 검증하지 않는다는 원칙입니다. 아무리 성실한 사람이라도 자신의 판단을 스스로 부정하기는 어렵습니다. 독립성은 감사인의 인격을 의심해서가 아니라, 인격에 기대지 않는 구조를 만들기 위해 존재합니다.

#### 외부 감사와 내부 감사

- 외부 감사: 조직 밖의 감사인이 수행하며, 주주와 채권자 등 외부 이해관계자를 위해 재무제표가 기준에 맞게 작성되었는지에 대한 의견을 냅니다. 보고 대상이 조직 바깥에 있습니다.

- 내부 감사: 조직 내부에 두되 경영진으로부터 독립된 조직이 수행하며, 이사회와 경영진을 위해 내부통제와 리스크 관리, 지배구조가 제대로 작동하는지를 평가합니다. 보고 대상이 조직 안에 있습니다.

둘은 목적과 보고 대상이 다르며 서로를 대체하지 않습니다. 외부 감사인이 왔다 갔으니 내부 감사는 안 해도 된다는 말은, 건강검진을 받았으니 평소 관리는 필요 없다는 말과 같습니다.

#### 합리적 확신이라는 한계

감사는 절대적인 진실을 보증하는 활동이 아닙니다. 모든 거래를 다 볼 수는 없으므로 표본을 뽑아 확인하고, 시간과 비용의 한계 안에서 결론을 내립니다. 게다가 여러 사람이 공모해 서류까지 맞춰 놓으면 통상적인 절차로는 발견하기 어렵습니다.

그래서 감사 의견은 "오류가 전혀 없다" 가 아니라 "중요성의 관점에서 기준에 부합한다" 는 형태로 표현됩니다. 이것을 합리적 확신이라고 합니다. 감사를 받았는데 왜 부정이 나왔느냐는 질문은 흔하지만, 감사는 원래 그런 보증을 하지 않습니다.

#### 감사 증거

감사인의 결론은 증거에 근거해야 합니다. 증거는 충분해야 하고(양) 적합해야 합니다(질). 담당자의 구두 설명보다 문서가, 조직 내부에서 만든 문서보다 외부에서 받은 문서가, 사후에 만든 자료보다 그때그때 남은 기록이 더 강한 증거로 취급됩니다. 오늘날 그 기록의 대부분이 전산 시스템에 남기 때문에, 감사와 디지털 포렌식이 만나는 지점이 넓어지고 있습니다.
### 내부 감사 (Internal Audit)
#### 정의

내부 감사는 조직의 운영을 개선하고 가치를 더하기 위해 수행하는 독립적이고 객관적인 확신 및 컨설팅 활동입니다. 국제내부감사인협회(IIA)의 정의가 널리 쓰이며, 체계적이고 규율 있는 접근법으로 리스크 관리, 통제, 지배구조 프로세스의 유효성을 평가하고 개선하는 것을 목적으로 합니다.

정의에 확신 과 컨설팅 이 함께 들어 있는 점이 눈에 띕니다. 잘못을 찾아내는 것만이 아니라, 잘 굴러가도록 돕는 것도 내부 감사의 일이라는 뜻입니다. 다만 스스로 설계한 통제를 나중에 스스로 평가하게 되는 순간 독립성이 깨지므로, 컨설팅의 범위에는 늘 선이 필요합니다.

#### 두 개의 축

- 독립성: 조직 구조의 문제입니다. 내부 감사는 자신이 감사하는 부서의 지휘를 받지 않아야 하며, 통상 이사회 또는 감사위원회에 직접 보고합니다. 감사 대상인 경영진이 감사인의 인사와 예산을 쥐고 있다면 그 감사는 형식만 남습니다.

- 객관성: 감사인 개인의 태도 문제입니다. 최근까지 자신이 수행하던 업무를 감사하게 되거나, 감사 대상 부서와 이해관계가 있다면 회피해야 합니다.

#### 3선 모델

조직의 리스크 관리 책임을 세 개의 선으로 나누어 설명하는 모델입니다.

- 1선: 현업 부서. 업무를 수행하면서 그에 따르는 리스크를 직접 관리합니다.

- 2선: 리스크 관리, 준법 감시, 정보보호 등 관리 기능. 1선을 지원하고 감독하며 기준을 만듭니다.

- 3선: 내부 감사. 1선과 2선이 제대로 작동하는지를 독립적으로 평가합니다.

내부 감사가 1선이나 2선의 업무를 직접 수행하면, 나중에 자기가 만든 통제를 자기가 평가하는 상황이 됩니다. 인력이 부족한 조직에서 내부 감사가 규정 제정이나 시스템 구축을 떠맡는 일이 흔한데, 그 순간 3선은 사라집니다. 자리를 지키는 것 자체가 기능인 셈입니다.

#### 감사의 유형

- 재무 감사: 재무 기록의 정확성과 신뢰성을 확인합니다.

- 업무 감사: 업무가 효율적이고 효과적으로 수행되는지를 봅니다. 규정 위반이 없어도 낭비가 있으면 지적 대상이 됩니다.

- 준법 감사: 법령과 내부 규정을 지키고 있는지를 확인합니다.

- IT 감사: 정보시스템이 신뢰할 수 있게 운영되는지를 봅니다.

- 부정 조사: 부정 혐의가 제기되었을 때 사실관계를 규명합니다. 이 단계에서 디지털 포렌식 기법이 사용되는 경우가 많습니다.

#### 일반 감사와 부정 조사의 차이

둘은 성격이 상당히 다릅니다. 일반 감사는 통제가 작동하는지를 표본으로 확인하고, 대상자의 협조를 전제합니다. 반면 부정 조사는 특정 혐의를 두고 사실을 규명하며, 대상자가 증거를 없애려 할 수 있다는 전제에서 움직입니다.

그래서 부정 조사는 착수 시점부터 다릅니다. 대상자에게 미리 알리지 않고, 자료를 요청하는 대신 확보하며, 확보 절차 자체를 기록으로 남깁니다. 일반 감사의 관행대로 "자료 좀 보내 주세요" 라고 요청하는 순간, 받게 되는 것은 정리된 자료이고 사라지는 것은 원래의 자료입니다.
### 개인정보 위탁과 수탁사 관리 (Privacy Outsourcing and Vendor Management)
#### 위탁이란

개인정보 처리 위탁은 개인정보를 다루는 업무를 외부 사업자에게 맡기는 것을 말합니다. 고객센터 운영, 배송, 시스템 유지보수, 마케팅 발송, 클라우드 인프라 이용이 흔한 예입니다. 업무를 맡기는 쪽을 위탁자, 맡는 쪽을 수탁자(수탁사)라고 합니다.

오늘날 개인정보를 한 조직이 처음부터 끝까지 직접 처리하는 경우는 드뭅니다. 그만큼 개인정보가 흘러 다니는 범위가 넓어졌고, 사고의 상당수가 우리 회사가 아니라 우리와 계약한 회사에서 일어납니다.

#### 제3자 제공과의 차이

수탁사에 개인정보를 넘기는 것은 제3자 제공과 다릅니다. 제3자 제공은 받는 쪽이 자기 목적 을 위해 개인정보를 이용하는 것이고, 위탁은 받는 쪽이 위탁자의 목적과 지시 범위 안에서만 처리하는 것입니다.

이 구분에 따라 요구되는 절차도 달라집니다. 제3자 제공은 원칙적으로 정보 주체의 동의가 필요하고, 위탁은 통상 처리방침 공개 등의 방법으로 알리도록 합니다. 실무에서는 계약서 제목만 보고 판단하지 말고, 받는 쪽이 그 데이터로 무엇을 하는지를 봐야 성격이 정해집니다.

#### 책임은 넘어가지 않는다

업무를 위탁했더라도 개인정보에 대한 책임까지 넘어가지는 않습니다. 위탁자는 수탁사가 개인정보를 안전하게 처리하도록 관리하고 감독할 의무를 집니다. 수탁사에서 사고가 나면 위탁자도 관리 감독을 소홀히 한 책임을 함께 지게 됩니다.

"우리 잘못이 아니라 협력업체 잘못" 이라는 항변이 통하지 않는 이유입니다. 애초에 그 업체를 고르고, 그 업체에 데이터를 넘기기로 결정한 것이 위탁자이기 때문입니다.

#### 관리 감독에서 확인하는 것

- 위탁 계약에 처리 목적과 범위, 안전성 확보 조치, 재위탁 제한, 손해배상 조항이 포함되어 있는가

- 수탁사가 위탁 범위를 넘는 처리를 하고 있지는 않은가

- 접근 권한이 실제로 필요한 인원에게만 부여되어 있는가

- 수탁사 담당자의 접속 기록이 남고 보관되는가

- 보유 기간이 지난 개인정보가 실제로 파기되는가

- 수탁사 직원에 대한 교육과 비밀유지 서약이 이뤄지는가

서류만 받아 보는 점검은 점검이 아닙니다. 계약서에 조항이 있다는 것과 그 조항이 지켜지고 있다는 것은 다른 이야기이며, 확인은 기록과 시스템에서 해야 합니다.

#### 재위탁이라는 사각지대

수탁사가 다시 다른 업체에 업무를 맡기는 것을 재위탁이라고 합니다. 여기서 관리가 무너지는 경우가 많습니다. 위탁자는 자신이 계약한 회사까지만 보고 있는데, 정작 데이터를 만지는 것은 그 아래 회사인 상황이 벌어집니다.

사슬이 길어질수록 통제는 약해지고 시야는 짧아집니다. 그래서 재위탁은 계약 단계에서 사전 동의를 받도록 제한하고, 실제로 재위탁이 이뤄지고 있는지를 주기적으로 확인해야 합니다. 계약서에 금지 조항을 넣어 두고 확인하지 않는 것은, 금지하지 않은 것과 결과가 같습니다.
### ISO/IEC 17025
#### 정의

ISO/IEC 17025 는 시험기관과 교정기관의 능력에 대한 일반 요구사항을 규정한 국제 표준입니다. 어떤 기관이 기술적으로 유효한 결과를 낼 능력이 있는지를 판단하는 기준이 되며, KOLAS 를 비롯한 각국 인정 기구가 이 표준을 근거로 인정을 부여합니다.

#### ISO 9001 과의 차이

ISO 9001 은 품질경영시스템이 갖춰져 있는지를 봅니다. 절차가 정해져 있고 그대로 운영되며 개선되는지가 관심사입니다. 극단적으로 말하면, 틀린 결과를 일관되게 내놓는 조직도 절차만 지키면 ISO 9001 요건은 충족할 수 있습니다.

ISO/IEC 17025 는 여기에 더해 기술적 능력 을 요구합니다. 절차를 지키는 것만으로는 부족하고, 그 절차가 실제로 타당한 결과를 낸다는 것까지 증명해야 합니다. 두 표준의 결정적인 차이가 여기에 있습니다.

#### 주요 요구사항

- 공정성: 결과에 영향을 줄 수 있는 상업적, 재정적, 인적 압력으로부터 독립적이어야 합니다. 의뢰인이 원하는 결과를 내주는 기관은 이 표준의 관점에서 자격이 없습니다.

- 기밀성: 업무 과정에서 알게 된 고객의 정보를 보호해야 합니다.

- 인력: 각 업무를 수행할 자격과 능력을 갖춘 인력을 지정하고, 그 능력을 지속적으로 관리해야 합니다.

- 장비: 필요한 장비를 갖추고 정해진 주기에 따라 교정하며, 교정 이력을 기록해야 합니다.

- 방법의 타당성 확인: 사용하는 시험 방법이 그 목적에 적합함을 확인하고 근거를 남겨야 합니다. 표준화된 방법이 아니라 자체 개발한 방법을 쓴다면 요구는 더 엄격해집니다.

- 측정 불확도: 결과에 따르는 불확실성의 범위를 평가하고 보고해야 합니다. 어떤 측정도 완벽하지 않다는 것을 인정하고, 그 오차의 크기를 명시하라는 요구입니다.

- 숙련도 시험: 다른 기관과 같은 시료를 시험해 결과를 비교하는 등, 자기 기관의 능력을 외부와 견주어 확인해야 합니다.

- 기록: 결과를 재현할 수 있을 만큼 충분한 기록을 남기고 정해진 기간 보관해야 합니다.

#### 디지털 포렌식과의 관계

디지털 포렌식을 이 표준의 틀 안에서 수행한다는 것은, 분석 도구를 검증하고, 절차를 문서화하고, 인력의 자격을 관리하고, 결과의 재현 가능성을 조직 차원에서 보장한다는 뜻입니다.

포렌식 도구는 대부분 상용 소프트웨어이지만, 도구가 내놓는 결과를 그대로 믿는 것과 그 도구가 우리 환경에서 정확히 동작함을 확인해 두는 것은 다릅니다. 표준이 요구하는 것은 후자입니다. 결국 이 표준의 정신은 한 문장으로 요약됩니다. 개인의 숙련도에 기대지 말고, 시스템으로 신뢰를 담보하라.
### 내부자 유출 (Insider Leaks)
#### 왜 내부자가 더 위험한가

내부자는 이미 정당한 접근 권한을 갖고 있어, 자료를 보는 행위 자체가 이상 신호로 잡히지 않습니다. 조직의 구조와 어떤 자료가 가치 있는지도 알고 있어 목표를 정확히 노립니다. 그래서 피해가 크고 발견이 늦습니다.

#### 유형

- 퇴직 예정자의 자료 반출: 이직이나 창업을 앞두고 담당 자료를 개인 매체나 메일로 옮깁니다.

- 권한 남용: 업무에 필요하지 않은 자료까지 열람하고 수집합니다.

- 외부 결탁: 금전이나 경쟁사의 요청에 따라 특정 자료를 반출합니다.

#### 조사에서 보는 징후

- 평소와 다른 대량 다운로드나 복사

- 업무 시간 외, 또는 접근 권한 종료 직전의 접근

- 개인 메일·개인 클라우드·이동식 매체 사용의 증가

- 접근 기록과 실제 업무 내용의 불일치

이런 징후는 하나만으로 단정하기 어렵고, 로그와 기기 분석을 종합해 맥락을 재구성해야 합니다. 디지털 포렌식은 누가 언제 무엇을 어떻게 다뤘는지를 객관적으로 규명하는 역할을 합니다.
### 퇴직자 잔존 접근권한 (Lingering Access After Offboarding)
#### 계정 하나를 잠그는 것으로 끝나지 않습니다

퇴직 처리 목록에는 계정 비활성화 완료라고 적혀 있습니다. 저는 그다음에 활성 세션, 모바일 앱 로그인, API 키, 개인 액세스 토큰을 봅니다. 비밀번호를 바꾸거나 계정을 중지해도 이미 발급된 토큰이 일정 기간 유효한 서비스가 있기 때문입니다.

클라우드와 SaaS가 늘면서 한 사람의 접근권한은 사내 계정 하나에만 묶여 있지 않습니다. 그룹 계정, 협업 공간의 게스트 권한, 외부 저장소, 자동화 계정에 연결될 수 있습니다. 인사 시스템의 퇴직 정보가 모든 서비스로 전달되지 않으면 권한 회수의 빈틈이 생깁니다.

#### 권한의 소유자를 사람 단위로 다시 묶습니다

서비스별 계정 목록만 보면 같은 사람이 여러 이름으로 존재할 수 있습니다. 회사 이메일, 별칭, 개인 이메일 초대, 외주 계정이 따로 남습니다. 저는 계정을 사람과 역할에 연결한 뒤, 고용 상태와 실제 필요성을 확인합니다.

공용 계정은 더 어렵습니다. 사용자가 바뀌어도 계정은 그대로여서 누가 언제 사용했는지 분리하기 어렵습니다. 불가피하게 공용 계정을 쓴다면 사용 승인, 비밀정보 변경, 접속 기록을 별도로 관리해야 합니다.

#### 퇴직 절차는 당일 작업이 아니라 생명주기 관리입니다

입사 때 부여한 권한, 부서 이동 때 추가된 권한, 프로젝트 종료 후 남은 권한을 계속 관리하지 않으면 퇴직일에 모든 연결을 찾아내기 어렵습니다. 정기적인 권한 검토가 필요한 이유입니다.

회수 결과도 남겨야 합니다. 계정 중지 여부뿐 아니라 세션 종료, 토큰 폐기, 공유 링크와 게스트 권한 정리, 회사 기기 회수, 예외 승인 내역을 기록합니다. 누락을 줄이는 가장 현실적인 방법은 인사, IT, 현업이 같은 체크리스트를 쓰는 것입니다.

#### 실무에서 확인할 항목

- 활성 세션, 토큰, API 키와 앱 비밀번호

- 게스트, 개인 이메일 초대와 공유 링크

- 공용 및 자동화 계정의 실제 소유자

- 인사 상태 변경과 권한 회수 절차의 연결
### 포렌식 절차 (Forensic Process)
#### 단계 구분

기관마다 표현은 조금씩 다르지만, 디지털 포렌식의 절차는 대체로 다섯 단계로 정리됩니다.

- 식별: 어떤 기기와 데이터가 사건과 관련 있는지 파악하고 확보 우선순위를 정합니다.

- 수집: 대상 데이터를 원본 변경 없이 확보합니다.

- 보존: 확보한 데이터의 무결성을 유지한 채 보관합니다.

- 분석: 사본을 대상으로 데이터를 복구하고 해석해 사실관계를 재구성합니다.

- 보고: 절차와 결과를 제3자가 검증할 수 있는 형태의 문서로 남깁니다.

이 순서는 편의상의 배열이 아닙니다. 앞 단계가 무너지면 뒤 단계의 결과물이 통째로 쓸모없어지는 종속 관계입니다. 수집이 잘못되면 아무리 정교하게 분석해도 그 결과를 쓸 수 없습니다.

#### 식별 단계에서 정하는 것

현장에는 대개 확보할 수 있는 것보다 많은 기기가 있습니다. 무엇을 가져오고 무엇을 두고 갈지, 어느 것을 먼저 확보할지는 사건의 성격에 따라 달라집니다. 정보 유출 의심이라면 대상자의 PC 와 이동식 매체, 서버 접근 로그가 우선이고, 회계 부정이라면 업무 시스템의 데이터베이스와 결재 이력이 먼저입니다.

이 단계에서 판단을 잘못하면 뒤에서 만회할 수 없습니다. 놓친 기기는 그사이 초기화되고, 확보하지 않은 로그는 보존 기간이 지나 사라집니다.

#### 수집 단계의 핵심 기법

- 이미징: 저장 매체를 파일 단위가 아니라 비트 단위로 통째로 복제합니다. 삭제된 영역과 빈 공간까지 함께 확보되므로 이후 복구 분석이 가능해집니다. 필요한 파일만 복사하면 그 순간 삭제 흔적은 영영 사라집니다.

- 쓰기 방지: 복제 과정에서 원본 매체에 어떤 데이터도 기록되지 않도록 하드웨어나 소프트웨어로 차단합니다. 이 장치 없이 원본을 조사용 PC 에 연결하면 운영체제가 자동으로 무언가를 기록해 버립니다.

- 해시 산출: 원본과 사본의 해시값을 계산해 동일함을 기록합니다. 이 값이 이후 모든 무결성 주장의 출발점이 됩니다.

#### 선별의 문제

수집 대상이 방대할 때는 사건과 무관한 개인 정보까지 함께 확보됩니다. 대상자의 가족 사진과 병원 기록이 조사 자료에 섞여 들어오는 일은 실제로 흔합니다.

그래서 목적에 필요한 범위로 한정해 수집하고 분석하는 것이 원칙입니다. 이것은 법적 요구이기도 하고, 조사의 효율 문제이기도 하며, 조사 결과의 신뢰 문제이기도 합니다. 범위를 넘어선 자료를 들여다본 사실이 드러나면 조사 전체의 정당성이 공격받습니다.

#### 분석 단계에서 하는 일

분석은 흩어진 흔적을 시간 순서로 엮어 사실관계를 재구성하는 작업입니다. 파일 하나를 찾는 것이 아니라, 그 파일이 언제 만들어져 누구 손을 거쳐 어디로 갔는지의 경로를 세우는 것이 목적입니다. 이 과정을 타임라인 분석이라고 부릅니다.

이때 지켜야 할 규율이 하나 있습니다. 가설을 세우는 것은 필요하지만, 가설에 맞는 증거만 찾아서는 안 됩니다. 반증이 될 만한 흔적도 같은 강도로 찾아야 하며, 찾지 못했다면 못 찾았다고 적어야 합니다.

#### 보고 단계

보고서는 기술 배경이 없는 사람이 읽고 판단할 수 있어야 합니다. 확인된 사실과 그로부터의 추정을 구분해 적고, 확인하지 못한 부분도 밝히는 것이 신뢰의 조건입니다. 필요할 경우 분석을 수행한 사람이 법정에 출석해 절차와 결과를 직접 설명하기도 합니다.
### 부정 (Fraud)
#### 정의

부정은 부당하거나 불법적인 이익을 얻기 위해 의도적으로 속임수를 쓰는 행위를 말합니다. 회계상의 오류와 부정을 가르는 기준은 결과의 크기가 아니라 고의 의 유무입니다. 같은 금액의 오기라도 실수면 오류이고, 숨기려는 의도가 있었다면 부정입니다.

이 구분은 감사인에게 실질적인 의미를 갖습니다. 오류는 통제를 개선하면 줄어들지만, 부정은 통제를 우회하려는 지능이 개입하므로 같은 방식으로 접근할 수 없습니다. 부정을 저지르는 사람은 감사가 무엇을 보는지 알고 그것을 피해 갑니다.

#### 세 가지 유형

- 자산의 유용: 조직의 자산을 빼돌리는 행위입니다. 현금 횡령, 허위 거래처를 통한 대금 지급, 재고 절취, 법인카드 사적 사용 등이 여기에 속하며 건수로는 가장 많습니다. 개별 금액은 크지 않지만 오래 지속되는 경향이 있습니다.

- 부패: 직위를 이용해 사적 이익을 취하는 행위입니다. 뇌물 수수, 리베이트, 이해충돌 거래가 대표적입니다. 회사 장부에는 정상 거래로 기록되기 때문에 회계 자료만 봐서는 드러나지 않고, 거래처와의 관계나 의사결정 경위를 봐야 보입니다.

- 재무제표 부정: 실적을 좋게 보이려고 매출을 부풀리거나 비용과 부채를 감추는 행위입니다. 건수는 적지만 금액 규모가 압도적으로 큽니다. 개인의 사적 이익보다 조직의 외형을 위해 저질러지는 경우가 많다는 점이 다른 유형과 다릅니다.

#### 부정 삼각형

부정이 성립하는 조건을 설명하는 고전적인 이론입니다. 세 요소가 함께 있을 때 부정이 일어난다고 봅니다.

- 압력: 개인적 부채, 과도한 실적 목표, 생활 수준 유지처럼 부정을 저지를 동기가 되는 요인입니다.

- 기회: 통제가 허술해 들키지 않고 실행할 수 있다는 판단입니다.

- 합리화: "잠시 빌리는 것뿐이다", "회사가 나에게 먼저 부당했다" 처럼 자신의 행위를 정당화하는 심리입니다.

조직이 직접 통제할 수 있는 것은 대개 기회 입니다. 직원의 사정을 관리할 수도 없고 마음을 들여다볼 수도 없지만, 혼자서 처음부터 끝까지 처리할 수 있는 업무를 없애고, 기록이 남게 하고, 정기적으로 확인하는 것은 할 수 있습니다. 직무 분리, 승인 절차, 로그 기록처럼 내부통제가 겨냥하는 지점이 바로 여기입니다.

#### 어떻게 발견되는가

여러 조사에서 반복적으로 확인되는 사실이 하나 있습니다. 부정은 정기 감사보다 제보 로 발견되는 비율이 높다는 것입니다. 가장 가까이서 보는 사람이 가장 먼저 알아차리기 때문입니다.

그래서 익명 제보 채널의 존재 여부와 그 채널이 실제로 안전하다고 믿어지는지가 부정 통제의 큰 부분을 차지합니다. 제보자가 불이익을 받은 사례가 한 번이라도 알려지면 그 채널은 그날로 죽습니다.

#### 부정과 디지털 흔적

부정 행위는 대부분 전산 시스템 위에서 이뤄집니다. 허위 거래처를 등록하려면 시스템에 입력해야 하고, 자료를 빼돌리려면 파일을 복사해야 하며, 공모하려면 연락을 해야 합니다. 전표 데이터, 계정 접근 기록, 이메일과 메신저 대화, 외부 저장 매체 연결 흔적이 모두 남습니다.

부정 조사에서 포렌식 기법이 쓰이는 이유가 여기에 있습니다. 사람의 진술은 바뀌지만, 기록은 확보만 제때 되면 바뀌지 않습니다.
### 정보보호 (Information Security)
#### 정보보호의 세 가지 목표

정보보호는 흔히 세 요소로 설명됩니다. 영문 머리글자를 따 CIA 라고 부릅니다.

- 기밀성: 허가된 사람만 정보에 접근할 수 있어야 합니다.

- 무결성: 정보가 허가되지 않은 방법으로 변경되지 않아야 합니다.

- 가용성: 필요할 때 정보와 시스템을 사용할 수 있어야 합니다.

세 목표는 종종 서로 부딪힙니다. 접근을 엄격히 막을수록 기밀성은 높아지지만 가용성은 떨어지고, 업무 속도도 느려집니다. 보안을 강화했더니 현업이 우회로를 만들어 쓰더라는 이야기는 이 충돌에서 나옵니다. 그래서 정보보호는 위험을 없애는 활동이 아니라, 위험의 크기에 맞춰 균형점을 정하는 활동에 가깝습니다.

#### 통제의 세 갈래

보호를 위해 적용하는 수단을 통제라고 하며, 대체로 셋으로 나눕니다.

- 관리적 통제: 정책, 규정, 절차, 교육, 책임자 지정처럼 사람과 조직을 다루는 통제입니다.

- 기술적 통제: 접근 권한, 암호화, 방화벽, 로그 기록처럼 시스템으로 구현되는 통제입니다.

- 물리적 통제: 출입 통제, 시건 장치, 저장 매체의 보관과 파기처럼 공간과 물건을 다루는 통제입니다.

기술적 통제만 잔뜩 사 두고 관리적 통제가 비어 있는 조직이 많습니다. 솔루션은 도입되어 있는데 그 로그를 아무도 보지 않고, 권한 대장은 만들었는데 갱신되지 않는 상태입니다. 통제는 도입이 아니라 운영에서 완성됩니다.

#### 정보보호와 개인정보 보호의 차이

둘은 겹치지만 같지 않습니다. 정보보호는 정보 자산 전반을 지키는 것이 목적이고, 개인정보 보호는 특정 개인을 알아볼 수 있는 정보를 어떻게 다루는가 를 규율합니다.

예를 들어 고객 정보를 완벽히 암호화해 보관하고 접근 통제도 철저히 했다고 합시다. 정보보호 관점에서는 훌륭합니다. 그런데 그 정보를 수집 목적과 무관한 마케팅에 활용했다면 개인정보 보호 원칙을 위반한 것입니다. 기술적으로 안전한 것과 법적으로 적법한 것은 다른 문제이고, 보안 부서만 있고 개인정보 담당이 없는 조직이 자주 걸려 넘어지는 지점입니다. 자세한 내용은 개인정보 문서에서 다룹니다.

#### 보안이 실패하는 지점

사고의 원인을 따라가 보면 최신 공격 기법보다 평범한 것들이 더 자주 나옵니다. 퇴직자 계정이 살아 있었고, 공용 계정을 여럿이 나눠 썼고, 패치가 밀려 있었고, 담당자가 첨부파일을 열었습니다.

정보보호가 어려운 이유는 새로운 위협을 모르기 때문이 아니라, 이미 아는 것을 계속 지키기가 어렵기 때문입니다. 보안은 한 번의 구축이 아니라 유지의 문제입니다.
### 수탁사 실태점검 (Vendor Compliance Inspection)
#### 왜 필요한가

수탁사가 취급하는 개인정보의 양은 계속 늘고 있습니다. 개인정보의 생애주기(수집, 이용, 제공, 보관, 파기) 각 단계에서 안전하게 다뤄져야 하지만, 관리가 따라가지 못하면 그 지점이 곧 유출의 통로가 됩니다.

유출 사고의 원인을 보면 뚫기 어려운 고난도 해킹만 있는 것이 아닙니다. 관리자의 의도치 않은 실수, 내부 직원의 유출, 위탁업체 직원의 정보 매매처럼 사람 에서 비롯된 경우가 상당한 비중을 차지합니다. 기술을 더 사는 것으로는 막히지 않는 영역입니다.

#### 서면 점검의 한계

많은 조직이 수탁사 점검을 담당자 인터뷰, 문서 검토, 기본적인 시스템 설정 확인 수준에서 마칩니다. 이 방식에는 두 가지 한계가 있습니다.

- 시점의 한계: 점검 당시의 상태만 확인됩니다. 점검 전에 어땠는지, 점검이 끝난 뒤에 어떻게 되는지는 알 수 없습니다.

- 표면의 한계: 규정과 설정은 갖춰져 있어도 실제 운영이 그것을 따르는지는 다른 문제입니다. 접근 권한 대장은 정리되어 있는데 실제 계정 목록과 다른 경우가 흔합니다.

ISMS 나 ISMS-P 인증을 받았으니 안전하다는 설명도 자주 듣지만, 인증은 심사 시점에 요건을 충족했다는 뜻이지 그 이후의 운영까지 보증하지 않습니다. 실제로 점검해 보면 지속적인 관리 부재나 시스템 오류로 미흡한 지점이 발견되는 경우가 적지 않습니다.

#### 흔적을 보는 점검

여기에서 디지털 포렌식 기법이 들어옵니다. 담당자에게 묻는 대신 시스템에 남은 흔적을 보는 방식입니다. 문서에 적힌 것과 시스템에 남은 것이 다를 때, 사실을 말해 주는 쪽은 후자입니다.

예를 들어 파기했다고 보고된 개인정보가 파일서버나 백업 데이터베이스에 남아 있는지, 권한이 없는 계정이 개인정보처리시스템에 접속한 이력이 있는지, 보안 솔루션이 우회된 흔적이 있는지는 인터뷰로는 확인되지 않고 로그와 저장 매체를 봐야 확인됩니다.

#### 점검 절차

실태점검은 대체로 여섯 단계로 진행됩니다.

- 사전준비: 수탁사가 수행하는 업무와 계약 내용을 파악하고, 필요한 자료를 요청하며, 점검 도구와 체크리스트를 준비합니다.

- 인터뷰: 점검과 이미징에 대한 동의서를 받고, 위탁 업무의 개인정보 흐름과 보안 시스템 구성을 파악해 점검 대상을 선정합니다.

- 현장점검: 개인정보처리시스템, 개인정보가 오가는 파일서버, 보안 솔루션 로그, 방화벽과 백신 로그를 확인합니다.

- 정보수집: 대상 PC 의 저장 매체를 담당자 입회 하에 수거하고, 원본과 동일한 사본(이미지)을 만듭니다. 분석은 원본이 아니라 사본에서 수행합니다.

- 정보분석: 데이터를 추출하고 분류하며, 삭제된 파일을 복구하고, 개인정보의 유출과 오남용 관점에서 흔적을 분석합니다.

- 결과보고: 현장에서 발견된 사항을 먼저 공유하고, 결과 보고서와 개선 방안을 정리합니다.

이미징 단계에서 사본을 두 벌 만드는 것이 관행입니다. 하나는 분석용으로 쓰고, 다른 하나는 만일의 사태에 대비한 백업으로 보관합니다. 원본을 직접 분석하면 무결성이 훼손될 수 있기 때문입니다.

#### 동의와 범위

점검이라 해도 남의 PC 를 들여다보는 일이므로, 동의와 범위 설정이 절차의 출발점입니다. 무엇을 목적으로 분석하는지, 그 목적을 달성하면 수집한 데이터를 언제 파기하는지를 동의서에 명시하고 그대로 이행해야 합니다.

점검하러 가서 점검 대상의 개인정보를 새로 만들어 오는 상황이 되어서는 안 됩니다. 이 원칙이 지켜지지 않으면 점검 행위 자체가 또 하나의 위반이 됩니다.

#### 무엇을 보는가

PC 와 서버에서 확인하는 대표적인 흔적은 다음과 같습니다.

- 웹 히스토리: 브라우저 접속 기록, 파일 업로드와 다운로드 여부

- 레지스트리: 최근 실행한 문서, 공유 폴더 사용 여부, 설치된 프로그램 목록

- 링크 파일: 실행 파일과 문서의 원래 위치, 연결되었던 외부 저장 매체의 흔적

- 데이터베이스: 접근 권한, 고유식별정보의 암호화 여부, 보유 기간 초과 데이터의 존재

- 이미지와 문서 파일: 개인정보가 담긴 파일의 존재, 암호화 적용 여부, 메타데이터

- 이메일: 개인정보가 첨부된 메일의 저장 여부, 파기되지 않고 남은 개인정보

- 접속기록: 개인정보처리시스템에 누가 언제 접속해 무엇을 조회했는지

여기에 법률 검토가 더해집니다. 위탁 범위를 넘어선 정보 제공은 없었는지, 위탁과 제3자 제공의 구분이 적절한지, 이용 목적을 달성한 개인정보가 파기되었는지를 확인합니다.

#### 점검의 진짜 목적

실태점검의 목적은 수탁사를 적발하는 것이 아닙니다. 위탁자와 수탁사 모두 사고가 나면 함께 책임을 지는 구조이므로, 점검은 사고가 나기 전에 약한 고리를 찾아 함께 고치는 활동에 가깝습니다.

그래서 결과 보고에는 발견 사항만이 아니라 수탁사가 실제로 수행할 수 있는 개선 방안이 함께 담겨야 합니다. 지적만 남기고 끝난 점검은 다음 점검 때 같은 지적을 반복하게 됩니다.
### 유출 사고 대응 (Responding to a Leak)
#### 첫 단계는 증거 보존

유출이 의심되면 원인을 빨리 밝히고 싶은 마음에 기기를 만지거나 재설치하기 쉽지만, 그 순간 결정적인 흔적이 사라집니다. 대응의 첫 원칙은 성급한 조치보다 현 상태의 보존입니다.

#### 대응 순서

- 탐지·인지: 이상 징후나 제보로 사고를 인지합니다.

- 범위 파악·차단: 어떤 자료가 어디까지 영향을 받았는지 가늠하고 확산을 막습니다.

- 증거 보존: 관련 로그와 기기를 원본 그대로 확보하고 관리 연속성을 기록합니다.

- 원인·경로 조사: 디지털 포렌식으로 유출 경로와 행위자를 규명합니다.

- 통지·신고: 법이 정한 통지·신고 의무가 있는지 확인하고 기한 내에 이행합니다.

- 재발 방지: 드러난 취약점을 보완하고 통제를 강화합니다.

#### 포렌식의 역할

사고 대응에서 포렌식은 누가·언제·무엇을·어떤 경로로 반출했는지를 증거능력 있는 형태로 규명합니다. 이는 내부 징계나 법적 대응의 근거가 될 뿐 아니라, 무엇이 뚫렸는지 정확히 알아야 제대로 된 재발 방지가 가능하기 때문에 중요합니다.
### 읽을 수 있는 로그 설계 (Designing Readable Logs)
#### 기록은 있는데 질문에 답하지 못합니다

접속 로그 파일은 남아 있지만 사용자 값이 비어 있고 시각의 기준도 적혀 있지 않습니다. 저는 이런 상태를 로그가 있다고 표현하기 어렵다고 봅니다. 용량을 소비하며 저장된 문자열과 조사에 쓸 수 있는 기록은 다릅니다.

로그는 나중에 물을 질문에서 거꾸로 설계해야 합니다. 누가, 언제, 어디서, 무엇을 시도했고, 허용되었는지 실패했는지를 구분할 수 있어야 합니다. 관리자 권한 변경, 대량 조회, 파일 다운로드처럼 위험이 큰 행위는 대상과 결과까지 남기는 편이 좋습니다.

#### 모든 로그를 오래 보관하는 것이 답은 아닙니다

저장 기간을 무작정 늘리면 비용과 개인정보 위험이 함께 커집니다. 반대로 시스템 기본값만 따르면 사고를 인지했을 때 필요한 구간이 이미 지워질 수 있습니다. 저는 위협 시나리오, 탐지 주기, 법적 보존 요구, 저장 비용을 함께 놓고 기간을 정합니다.

원본 시스템과 중앙 수집 구간의 손실도 확인합니다. 네트워크 단절이나 수집기 장애가 발생했을 때 누락을 알리는 장치가 없으면 조용한 공백이 생깁니다. 로그 수집 성공 여부 자체도 감시 대상입니다.

#### 시각과 식별자가 연결의 기준입니다

여러 시스템의 기록을 맞추려면 시계 동기화와 일관된 사용자 식별값이 필요합니다. 직원 이름만 남기면 동명이인과 계정 변경을 구분하기 어렵습니다. 계정 식별자, 기기 식별자, 세션 식별자를 함께 남기면 한 행위의 흐름을 연결하기 쉬워집니다.

중요 로그는 변경이나 삭제 권한을 제한하고, 접근 자체를 기록합니다. 사고 당사자가 운영 권한을 가진 상황까지 생각해야 합니다. 평소에는 잘 보이지 않는 설계 차이가 조사 가능 범위를 정합니다.

#### 실무에서 확인할 항목

- 사용자, 시각, 행위, 대상, 결과 필드

- 시계 동기화와 시간대 표기

- 로그 수집 누락 및 지연에 대한 감시

- 보존기간, 접근권한과 위변조 방지
### 시험방법 검증 (Method Validation)
#### 같은 절차도 환경이 바뀌면 결과가 달라질 수 있습니다

절차서에는 특정 도구로 이미지를 수집한다고 적혀 있습니다. 저는 절차가 문서에 있다는 사실과 그 방법이 현재 장비와 데이터에 적합하다는 사실을 나누어 봅니다. 도구 버전, 운영체제, 저장매체 특성이 바뀌면 이전에 확인한 방법을 그대로 적용하기 어려울 수 있습니다.

시험방법 검증은 문서를 잘 작성했는지 확인하는 작업이 아닙니다. 정한 방법이 의도한 결과를 일관되게 낼 수 있는지 객관적인 자료로 확인하는 과정입니다.

#### 검증과 확인의 깊이는 방법의 출처에 따라 달라집니다

공인된 표준방법을 변경 없이 쓰는 경우에도 시험기관의 인력, 장비, 환경에서 제대로 수행할 수 있는지 확인해야 합니다. 표준에서 벗어나 수정했거나 기관이 자체 개발한 방법이라면 성능 특성을 더 넓게 평가할 필요가 있습니다.

디지털 분야에서는 알려진 데이터 세트, 해시값이 정해진 매체, 예상 결과가 있는 시험 파일을 활용할 수 있습니다. 반복 수행, 다른 작업자 간 비교, 도구 간 결과 대조를 통해 일관성과 한계를 봅니다.

#### 검증 기록은 합격 표시보다 판단 근거를 담습니다

검증 완료라고 적는 것만으로는 부족합니다. 대상 버전, 시험 조건, 사용 데이터, 기대 결과, 실제 결과, 허용 기준, 차이의 원인과 승인자를 남깁니다. 일부 기능만 확인했다면 적용 범위도 제한해서 적어야 합니다.

도구가 업데이트되거나 환경이 달라졌을 때 재검토 조건을 정합니다. 모든 변경마다 처음부터 반복할 필요는 없지만 결과에 영향을 줄 수 있는 변경을 놓치지 않아야 합니다. 방법의 신뢰는 한 번 받은 도장이 아니라 유지되는 기록에서 나옵니다.

#### 실무에서 확인할 항목

- 방법의 출처와 수정 여부

- 현재 인력, 장비, 버전과 환경에서의 적합성

- 기대 결과와 허용 기준이 있는 검증 데이터

- 변경 발생 시 재검토 및 재검증 조건
### 전자정보확인서 (Electronic information confirmation document)
#### 서명한 문서가 무엇을 확인하는지

휴대전화를 제출하거나 포렌식 절차에 참여하면 전자정보확인서를 접할 수 있습니다. 문서에는 대상 기기와 전자정보, 절차 참여에 관한 의사 등 해당 서식과 처리 단계에 따른 내용이 담깁니다.

이때 확인할 것은 문서의 제목보다 실제 기재 내용입니다. 기기를 반출하는 단계인지, 전자정보를 선별하여 압수한 단계인지에 따라 확인하는 사항이 달라질 수 있습니다.

대법원 2022도2071 판결에서도 휴대전화 반출 이후의 탐색·복제·출력 과정에 대한 참여 의사가 기재된 전자정보확인서가 등장합니다. 전자정보확인서를 앞으로 도입될 제도로만 이해해서는 안 되는 이유입니다.

#### 문서와 실제 자료를 함께 봅니다

전자정보확인서를 검토할 때는 대상 기기가 실제 제출한 기기와 일치하는지, 확인 대상이 전체 복제본인지 선별된 파일인지 살핍니다. 관련 목록과 작업 기록이 있다면 서로 연결되는지도 확인합니다.

예를 들어 휴대전화 한 대에서 자료를 확보했더라도 전체 추출 결과와 사건 관련 대화만 정리한 제공본은 서로 다른 자료입니다. 어느 자료를 확인한 것인지 구분되지 않으면 이후 분석 결과와 연결하기 어렵습니다.

다음 항목은 기술 검토에 활용할 수 있는 예시입니다. 모든 확인서의 법정 필수 기재사항을 뜻하지는 않습니다.

검토 항목확인할 내용
대상 식별기기·저장매체·파일이 실제 대상과 일치하는지
처리 단계반출, 복제, 선별, 제공 중 어느 단계의 기록인지
자료 범위전체 복제본과 선별 자료가 구분되는지
무결성 정보해시값이 있다면 계산 대상과 알고리즘이 명확한지
관련 기록파일 목록, 수집 기록, 인계 기록과 연결되는지
확인 내용서명자가 무엇을 확인하거나 의사 표시했는지

#### 해시값과 서명이 설명하는 범위

해시값은 파일 등의 데이터로 계산하는 값입니다. 적절한 알고리즘으로 같은 범위의 데이터를 비교했을 때 값이 일치하면, 비교 대상의 동일성을 확인하는 근거로 활용할 수 있습니다.

다만 자료를 확보한 뒤 계산한 해시값만으로 확보 이전에 편집이 없었다거나, 대화 상대가 실제로 해당 내용을 작성했다는 사실까지 입증할 수는 없습니다. 수집 경위와 원본 자료, 관련 기록을 함께 살펴야 합니다.

서명 역시 문서에 기재된 확인 내용과 당시 절차를 기준으로 해석해야 합니다. 서명이 있다는 사실만으로 모든 절차적 문제가 해소되는 것은 아닙니다. 대법원 2022도2071 판결은 친권자에게 참여 기회를 부여한 사정만으로 실제 피압수자에 대한 참여 기회 미보장 문제가 해소되지 않는다고 판단했습니다.

#### 민간 포렌식의 기록과 구분합니다

기업 내부조사나 개인 의뢰 포렌식에서도 수집 대상, 수행 방법, 해시값과 인계 내역을 기록할 필요가 있습니다. 이러한 기록은 분석 결과가 어떤 자료에서 나왔는지 설명하는 기반이 됩니다.

민간 기관이 작성한 수집확인서나 분석보고서는 작성 목적과 수행 범위를 명확히 표시해야 합니다. 수사기관의 전자정보확인서와 명칭이 비슷하다는 이유로 같은 절차적 의미를 갖는다고 설명해서는 안 됩니다.

검토 결과에도 직접 확인한 사실과 의뢰인이 설명한 내용을 구분합니다. 원본을 확인하지 못했다면 제공받은 사본을 기준으로 검토했다는 한계를 남깁니다.

#### 디지털포렌식 전문가의 역할

전자정보확인서에 대한 기술 검토는 문서와 실제 데이터 사이의 연결을 확인하는 작업입니다. 파일 목록의 대상이 맞는지, 해시값을 재검증할 수 있는지, 수집 기록과 분석 결과가 일치하는지 등을 살핍니다.

검토 결과는 확인한 사실, 차이가 있는 항목, 추가 자료가 필요한 부분으로 나누어 설명할 수 있습니다. 이러한 정리는 의뢰인과 법률대리인이 증거의 확보 경위와 검토 쟁점을 이해하는 데 도움이 됩니다.

법률대리인은 절차의 적법성과 증거능력에 관한 주장을 검토하고, 포렌식 전문가는 그 판단에 필요한 기술적 사실과 한계를 설명합니다. 확인서 한 장보다 이를 뒷받침하는 자료와 기록이 중요합니다.
### 포렌식의 세부 분야 (Branches of Digital Forensics)
#### 대상에 따른 구분

- 디스크 포렌식: 하드디스크나 SSD 등 저장 매체를 대상으로 파일, 삭제 흔적, 파일 시스템 기록을 분석합니다. 가장 오래되고 기본이 되는 분야입니다. 다만 SSD 는 성능을 위해 지워진 블록을 스스로 정리하는 기능이 있어, 전통적인 복구 가능성 전제가 그대로 적용되지 않는 경우가 있습니다.

- 모바일 포렌식: 스마트폰과 태블릿을 대상으로 통화 기록, 메시지, 위치 정보, 앱 데이터를 분석합니다. 기기마다 잠금과 암호화 방식이 달라 데이터에 접근하는 것 자체가 첫 번째 과제가 됩니다. 개인의 생활이 통째로 담기는 기기이므로 조사 범위를 한정하는 문제도 가장 예민합니다.

- 네트워크 포렌식: 오가는 트래픽과 통신 장비 로그를 분석해 침입 경로나 데이터 전송 사실을 확인합니다. 데이터가 흘러가면 사라지므로, 사고가 난 뒤에 확보하려 해도 이미 늦은 경우가 많습니다. 평소에 무엇을 얼마나 기록해 두었는지가 조사 가능성을 결정합니다.

- 메모리 포렌식: 실행 중인 시스템의 휘발성 메모리를 확보해 분석합니다. 디스크에 남지 않는 암호키, 실행 중이던 악성코드, 복호화된 상태의 데이터를 확인할 수 있습니다. 디스크에 아무 파일도 남기지 않는 공격 기법이 늘면서 중요성이 커졌습니다.

- 클라우드 포렌식: 데이터가 물리적으로 어디에 있는지 특정하기 어렵고, 확보하려면 사업자의 협조가 필요합니다. 서버가 다른 나라에 있으면 관할 문제까지 따라옵니다. 기술의 문제라기보다 절차와 계약의 문제가 되는 영역입니다.

#### 목적에 따른 구분

같은 기법이라도 목적에 따라 다르게 불립니다. 범죄 수사를 위한 조사, 기업 내부의 부정 행위를 확인하는 감사 목적의 조사, 침해 사고의 원인을 규명하는 사고 대응이 대표적입니다.

목적이 다르면 요구되는 절차의 엄격함과 산출물의 형식도 달라집니다. 내부 보고용이라면 신속함이 우선일 수 있지만, 소송이 예상된다면 처음부터 법정 기준으로 진행해야 합니다. 나중에 소송으로 번질 가능성을 낮게 보고 절차를 생략했다가, 실제로 소송이 시작된 뒤 증거를 다시 만들 수 없어 곤란해지는 일이 자주 생깁니다.

#### 안티 포렌식

조사를 방해하기 위한 기법을 통틀어 안티 포렌식이라고 합니다. 데이터를 여러 번 덮어써 복구를 막는 완전 삭제, 파일 시간 정보를 조작하는 타임스탬프 변조, 다른 파일 안에 데이터를 숨기는 은닉, 로그 삭제 등이 있습니다.

흥미로운 점은 이런 행위 자체가 또 하나의 흔적이 된다는 것입니다. 완전 삭제 도구를 설치하고 실행한 기록, 로그가 특정 구간만 비어 있다는 사실, 파일 시간이 파일 시스템의 다른 기록과 앞뒤가 맞지 않는다는 점은 모두 확인 가능합니다. 은폐의 시도가 오히려 고의를 드러내는 정황이 되기도 합니다.
### 개인정보 (Personal Information)
#### 정의

개인정보는 살아 있는 개인에 관한 정보로서, 성명이나 주민등록번호처럼 그 자체로 개인을 알아볼 수 있는 정보뿐 아니라, 다른 정보와 쉽게 결합해 개인을 알아볼 수 있는 정보까지 포함합니다.

마지막 부분이 중요합니다. 이름을 지웠다고 개인정보가 아닌 것이 되지는 않습니다. 사번, 단말기 식별값, 특정 시각의 위치 기록처럼 그 자체로는 무의미해 보이는 값도, 조직이 가진 다른 자료와 맞춰 보면 한 사람을 지목할 수 있습니다. 개인정보인지 아닌지는 데이터의 모양이 아니라 식별 가능성 으로 판단합니다.

#### 지키는 문제가 아니라 다루는 문제

정보보호가 정보를 안전하게 지키는 문제라면, 개인정보 보호는 그 정보를 다룰 자격과 범위에 관한 문제입니다. 암호화를 아무리 잘해도 목적을 벗어나 이용했다면 위반이고, 반대로 적법하게 수집했더라도 안전하게 관리하지 못하면 그 또한 위반입니다. 두 축이 모두 필요합니다.

#### 처리의 기본 원칙

- 목적 제한: 수집한 목적의 범위 안에서만 이용합니다.

- 최소 수집: 목적에 필요한 최소한만 수집합니다. "나중에 쓸지도 모르니" 는 수집의 근거가 되지 못합니다.

- 정확성: 처리 목적에 필요한 범위에서 정확하고 최신 상태로 유지합니다.

- 보유 기간 제한: 목적을 달성하면 지체 없이 파기합니다.

- 안전성 확보: 분실, 도난, 유출, 위조, 변조, 훼손되지 않도록 필요한 조치를 합니다.

- 투명성: 무엇을 어떤 목적으로 처리하는지 정보주체가 알 수 있게 공개합니다.

동의를 받았으니 무엇이든 해도 된다는 생각은 흔한 오해입니다. 동의는 처리의 근거 중 하나일 뿐이고, 목적을 벗어난 이용이나 과도한 수집까지 정당화해 주지는 않습니다.

#### 정보주체의 권리

개인정보의 주인은 그 정보가 가리키는 사람입니다. 정보주체는 자신의 개인정보에 대해 다음을 요구할 수 있습니다.

- 처리에 관한 정보를 알 권리

- 처리에 대한 동의 여부와 범위를 선택할 권리

- 자신의 개인정보를 열람할 권리

- 정정과 삭제, 처리 정지를 요구할 권리

- 피해를 구제받을 권리

조직 입장에서 이 권리들은 곧 절차의 의무가 됩니다. 열람 요구가 들어왔을 때 어디에 무엇이 있는지 찾지 못하는 조직은 권리를 보장할 수도 없습니다.

#### 쌓아 둔 데이터는 자산이 아니라 부채

보유 기간이 지난 개인정보를 파기하는 일은 말처럼 쉽지 않습니다. 운영 데이터베이스에서 지웠어도 백업본에 남아 있고, 분석용으로 복사해 둔 사본과 담당자 PC 의 엑셀 파일에도 남아 있습니다. 어디에 무엇이 있는지 모르는 조직은 파기 의무를 지킬 수도 없습니다.

그래서 개인정보 관리의 출발점은 암호화가 아니라 현황 파악 입니다. 어떤 개인정보를, 어디에, 왜, 얼마나 갖고 있는지 목록으로 만드는 일이 먼저입니다. 그리고 필요 없어진 데이터는 지우는 것이 가장 확실한 보호입니다. 갖고 있지 않은 정보는 유출되지 않습니다.

#### 가명처리와 익명처리

데이터를 활용하면서 위험을 줄이는 방법으로 가명처리와 익명처리가 있습니다.

- 가명처리: 추가 정보 없이는 특정 개인을 알아볼 수 없게 처리하는 것입니다. 추가 정보를 결합하면 다시 알아볼 수 있으므로 여전히 개인정보이며, 그 추가 정보를 분리해 안전하게 보관해야 합니다.

- 익명처리: 시간과 비용, 기술을 합리적으로 고려할 때 더 이상 개인을 알아볼 수 없게 처리하는 것입니다. 이 경우 개인정보가 아니게 됩니다.

둘의 차이는 되돌릴 수 있는지에 있습니다. 가명처리된 데이터를 익명이라고 부르며 관리를 느슨하게 하는 것이 실무에서 자주 나오는 잘못입니다.
### 컴플라이언스 (Compliance)
#### 정의

컴플라이언스(Compliance)는 기업이 법령과 규제, 그리고 스스로 정한 내부 규정과 윤리 기준을 지키도록 만드는 체계와 활동을 말합니다. 단순히 규칙을 어기지 않는 상태가 아니라, 어기지 않도록 하는 구조를 갖추고 그것이 실제로 작동하게 만드는 것이 핵심입니다.

#### 왜 중요한가

규정을 어기면 과징금과 형사 책임, 영업 정지 같은 직접적 제재가 따르지만, 더 큰 손실은 신뢰의 붕괴입니다. 한 번의 위반이 오래 쌓은 평판을 무너뜨리고 거래와 투자, 인재 확보에까지 영향을 미칩니다. 규제가 촘촘해지고 국경을 넘는 사업이 늘면서 지켜야 할 규범의 범위도 계속 넓어지고 있습니다.

#### 내부감사와의 관계

컴플라이언스와 내부감사는 목적이 겹치지만 역할이 다릅니다. 컴플라이언스가 지키도록 설계하고 운영하는 1차 방어선이라면, 내부감사는 그 체계가 제대로 작동하는지 독립적으로 검증하는 역할을 합니다. 둘은 대립이 아니라 보완 관계이며, 건강한 조직일수록 이 경계가 분명합니다.

#### 컴플라이언스 리스크

컴플라이언스 리스크는 규정 위반으로 조직이 입을 수 있는 법적·재정적·평판적 손실 가능성입니다. 부패·뇌물, 공정거래 위반, 개인정보 침해, 회계 부정, 자금세탁 등 업종과 사업 구조에 따라 노출되는 리스크가 다릅니다. 그래서 진단의 첫 단계는 우리 조직이 어디에 노출되어 있는지를 파악하는 것입니다.

#### 진단과 점검

컴플라이언스 진단은 규정 준수 체계가 실제로 갖춰져 있고 작동하는지를 점검하는 과정입니다. 제도의 존재 여부만이 아니라 데이터와 기록으로 실제 이행을 확인하는 것이 중요합니다. 디지털 포렌식 기법을 활용하면 문서와 시스템 로그에서 위반의 징후를 객관적으로 찾아낼 수 있어, 형식적 점검을 넘어 실질적 진단이 가능해집니다.
### SaaS 보안 공백 (SaaS Security Gaps)
#### 구매가 끝난 뒤부터 자산이 늘어납니다

협업 도구 하나를 도입하면 계정만 생기는 것이 아닙니다. 문서, 대화, 첨부파일, 외부 앱 연동, 공유 링크가 함께 늘어납니다. 저는 서비스 이름보다 그 안에서 어떤 정보가 만들어지고 어디로 이동하는지 먼저 정리합니다.

SaaS는 운영 인프라를 직접 관리하지 않아도 된다는 장점이 있지만, 책임까지 서비스 제공자에게 넘어가는 것은 아닙니다. 사용 조직이 정해야 할 접근권한, 공유 범위, 보존기간, 퇴직자 처리와 사고 대응 역할이 남습니다.

#### 기본 설정은 조직의 기준이 아닙니다

외부 공유가 기본으로 허용되거나, 누구나 앱을 연결할 수 있거나, 관리자가 과도하게 많은 경우가 있습니다. 저는 초기 설정값을 그대로 받아들이지 않고 정보의 민감도와 업무 방식에 맞춰 바꿉니다. 다만 통제를 지나치게 닫으면 개인 계정이나 승인되지 않은 도구로 우회할 수 있어 사용 흐름도 함께 봅니다.

연동 앱은 별도의 데이터 경로입니다. 일정, 메일, 파일 저장소에 접근하는 권한을 한 번 승인하면 이용자가 잊은 뒤에도 연결이 남을 수 있습니다. 승인 주체와 권한 범위, 마지막 사용 시점을 정기적으로 검토합니다.

#### 종료할 때 데이터를 꺼낼 수 있어야 합니다

서비스를 해지하거나 계약이 끝날 때 자료를 어떤 형식으로 내보낼 수 있는지, 삭제는 언제 완료되는지, 백업에는 얼마나 남는지 확인해야 합니다. 사고 조사에 필요한 로그를 제공받을 수 있는지도 계약 전에 보는 편이 낫습니다.

SaaS 목록만으로는 관리가 충분하지 않습니다. 데이터 종류, 관리자, 인증 방식, 외부 공유, 연동 앱, 로그 제공 범위, 종료 절차를 한 장에서 볼 수 있어야 합니다. 이 문서가 최신 상태인지 확인하는 책임자도 필요합니다.

#### 실무에서 확인할 항목

- 처리 데이터와 저장 위치, 외부 이전 여부

- 관리자, 외부 공유와 게스트 정책

- 연동 앱의 권한과 마지막 사용 시점

- 계약 종료 시 데이터 반출, 삭제와 로그 확보
### 개인정보 흐름도 (Personal-Data Flow Maps)
#### 서버 목록에는 업무의 이동이 보이지 않습니다

개인정보 처리 시스템 목록에는 고객관리 시스템 하나가 적혀 있습니다. 실제 업무에서는 신청서가 메일로 들어오고, 담당자가 내려받아 엑셀로 정리한 뒤, 협력업체에 파일을 전달할 수 있습니다. 저는 시스템 목록과 개인정보 흐름도를 같은 문서로 보지 않습니다.

시스템 목록은 어디에 무엇이 있는지를 보여 줍니다. 흐름도는 누가 어떤 목적으로 받아서 어디로 보내고 언제 없애는지를 보여 줍니다. 사고와 과도한 보유는 주 시스템보다 업무 사이의 복사본에서 발견되는 경우가 많습니다.

#### 업무 장면에서 시작합니다

저는 '개인정보를 수집한다'는 추상적인 문장 대신 접수 화면, 상담 메일, 통화 녹음, 종이 신청서처럼 실제 장면을 적습니다. 수집 항목과 근거, 이용 부서, 제공 대상, 저장 위치, 보유기간을 그 장면에 연결합니다.

같은 정보도 목적이 달라지면 별도의 흐름이 됩니다. 계약 이행을 위해 받은 연락처를 행사 홍보에 이용한다면 수집 당시의 흐름만으로 설명하기 어렵습니다. 목적이 바뀌는 지점과 새로운 처리 근거를 따로 봐야 합니다.

#### 그림보다 갱신 절차가 중요합니다

잘 그린 흐름도도 서비스와 담당자가 바뀌면 금방 낡습니다. 신규 시스템 도입, 위탁업체 변경, 수집 항목 추가, 보유기간 변경을 흐름도 갱신 조건으로 정합니다. 개인정보 담당자 혼자 업데이트하기보다 업무 변경을 승인하는 절차와 연결하는 편이 안정적입니다.

흐름도를 점검할 때는 복사본을 묻습니다. 내려받은 파일, 공유 폴더, 메일 첨부, 테스트 데이터, 백업과 출력물이 어디에 남는지 확인합니다. 공식 시스템 밖의 사본이 보이면 파기와 접근통제의 책임도 함께 정합니다.

#### 실무에서 확인할 항목

- 수집 장면과 처리 목적 및 근거

- 업무 단계별 담당자와 저장 위치

- 외부 제공, 위탁과 국외 이전 지점

- 로컬 사본, 메일, 출력물, 테스트 및 백업 데이터
### 출력·촬영 반출 (Print & Photo Exfiltration)
#### 파일 이동 기록이 없다고 반출이 없었던 것은 아닙니다

USB 연결도 없고 외부 메일 발송도 보이지 않습니다. 저는 그 사실만으로 반출 가능성을 닫지 않습니다. 문서를 출력하거나 화면을 휴대전화로 촬영하면 원본 시스템에는 열람과 인쇄 정도만 남을 수 있습니다.

출력과 촬영은 디지털 조사만으로 완전하게 확인하기 어려운 경로입니다. 그래서 조사 전에 가능한 경로를 넓게 세우고, 전산 기록과 물리적 통제를 함께 봅니다.

#### 작은 흔적을 시간과 장소로 묶습니다

출력 서버 기록, 문서 열람 시각, 프린터 작업 대기열, 출입 기록, 보안구역 정책을 서로 맞춰 봅니다. 각 기록 하나만으로는 반출을 증명하기 어렵지만, 같은 시간대와 위치를 가리키는지 확인할 수 있습니다.

화면 촬영은 더 제한적입니다. 카메라 사용을 기술적으로 통제할 수 없는 환경도 많습니다. 이 경우 민감 문서 워터마크, 화면 표시 식별값, 보안구역 내 촬영 규칙, 방문자 기기 관리가 사후 확인과 억제에 도움을 줄 수 있습니다.

#### 통제는 업무를 멈추지 않는 범위에서 설계합니다

모든 인쇄를 금지하면 현업은 다른 경로를 찾을 수 있습니다. 저는 정보 등급과 업무 목적에 따라 승인, 출력물 회수, 파쇄, 로그 검토 수준을 나눕니다. 대량 인쇄나 평소와 다른 시간대의 출력은 추가 확인 대상으로 둘 수 있습니다.

조사 결과에는 확인한 경로와 확인하기 어려운 경로를 함께 적습니다. 전산 흔적이 없다는 표현과 유출이 없었다는 표현은 다릅니다. 증거가 남기 어려운 경로일수록 한계를 정확히 밝히는 것이 필요합니다.

#### 실무에서 확인할 항목

- 문서 열람과 출력 기록의 시간 연결

- 출입, 보안구역과 출력물 관리 기록

- 민감 문서 표시 및 워터마크 정책

- 확인 가능한 경로와 확인 한계의 구분
### 숙련도시험 (Proficiency Testing)
#### 결과가 맞아도 과정은 다를 수 있습니다

같은 시료나 데이터를 여러 기관이 분석하면 최종 결과는 비슷해도 사용한 절차와 기록의 밀도는 다를 수 있습니다. 저는 숙련도시험을 합격 여부만 확인하는 행사로 보지 않습니다. 평소 내부에서 발견하기 어려운 편차를 외부 기준과 비교하는 기회로 봅니다.

디지털 시험에서는 수집 성공 여부뿐 아니라 해시값, 복구 범위, 시간 정보 해석, 보고 방식에서 차이가 날 수 있습니다. 정답과 일치했다는 사실만 보면 우연히 맞은 과정과 안정적인 과정을 구분하기 어렵습니다.

#### 사람, 방법, 장비를 분리해 원인을 봅니다

결과가 기대와 다르면 작업자의 실수로 끝내기 쉽습니다. 그러나 절차서가 모호했거나, 도구 버전이 달랐거나, 검토 단계가 작동하지 않았을 수 있습니다. 저는 입력 데이터부터 보고서까지 단계를 나누어 차이가 생긴 지점을 찾습니다.

한 사람만 숙련도시험에 참여하고 결과를 조직과 공유하지 않으면 학습이 개인에게 머뭅니다. 사용한 방법과 발견된 차이, 시정조치, 재확인 결과를 관련 인력과 공유해야 기관의 능력으로 이어집니다.

#### 적합한 프로그램이 없을 때도 비교 방법은 있습니다

분야가 좁아 외부 숙련도시험 프로그램을 찾기 어려운 경우가 있습니다. 이때는 시험소 간 비교, 내부에서 독립적으로 준비한 기준 데이터, 반복 시험 등 다른 품질보증 방법을 검토할 수 있습니다. 중요한 것은 선택한 방법이 실제 수행능력을 확인할 수 있는지입니다.

결과가 양호했더라도 개선점은 남을 수 있습니다. 수행 시간, 기록 누락, 판정 기준의 차이를 검토하면 다음 시험의 불확실성을 줄일 수 있습니다.

#### 실무에서 확인할 항목

- 인정범위와 실제 시험방법에 맞는 프로그램

- 결과뿐 아니라 수행 절차와 기록의 비교

- 차이 원인의 사람, 방법, 장비별 분석

- 시정조치 후 효과 확인과 조직 내 공유
### 정보 유출 (Data Leak)
#### 정의

정보 유출은 조직이 보호해야 할 정보가 권한 없는 상대에게 전달되거나, 조직의 통제를 벗어나 외부로 나가는 것을 말합니다. 외부의 침입으로 발생하기도 하고, 내부 구성원의 행위로 발생하기도 하며, 담당자의 실수로 발생하기도 합니다.

#### 열람과 유출은 다르다

조사 실무에서 가장 먼저 정리해야 하는 구분입니다. 권한 있는 직원이 자료를 열어본 것 자체는 유출이 아닙니다. 그 자료가 통제 범위 밖으로 이동 했을 때 유출이 됩니다.

이 구분이 중요한 이유는, 열람 기록만으로 사람을 지목하면 대부분 반박당하기 때문입니다. "업무상 열어봤다" 는 해명은 대개 반증하기 어렵습니다. 조사가 확인해야 할 것은 열람이 아니라 반출의 흔적, 즉 자료가 회사 밖으로 나간 경로입니다.

#### 유출 경로

- 이동식 저장 매체: USB 메모리, 외장 하드. 연결 기록과 파일 복사 흔적이 남습니다.

- 개인 클라우드: 개인 계정의 클라우드 저장소에 업로드. 브라우저 기록과 통신 로그에 흔적이 남습니다.

- 웹메일과 메신저: 개인 메일로 첨부해 발송하거나 메신저로 전송.

- 출력과 촬영: 문서를 인쇄해 들고 나가거나 화면을 휴대폰으로 촬영. 촬영은 전산 흔적이 거의 남지 않아 가장 까다롭습니다.

- 외부 공격: 침입 후 데이터 탈취. 이 경우는 침입 경로와 체류 기간, 반출된 데이터의 범위를 함께 규명해야 합니다.

경로마다 남는 흔적의 종류와 보존 기간이 다르기 때문에, 조사에서는 여러 갈래를 동시에 확인합니다. 한 경로만 보고 "흔적이 없으니 유출이 없었다" 고 결론짓는 것은 위험합니다.

#### 내부자 위협

내부자는 이미 접근 권한을 갖고 있고, 어디에 무엇이 있는지 알고 있으며, 언제 감시가 느슨해지는지도 압니다. 그래서 외부 공격과 달리 침입 흔적이 남지 않고, 그의 행위는 정상적인 업무와 겉으로 구별되지 않습니다. 방화벽은 이런 상황에서 아무 일도 하지 않습니다.

단서가 되는 것은 행위 자체가 아니라 행위의 맥락 입니다. 퇴직 의사를 밝힌 직후 평소보다 훨씬 많은 자료를 열람하거나, 담당 업무와 무관한 부서의 자료에 접근하거나, 새벽 시간대에 대량으로 다운로드하는 식입니다. 단일 행위 하나만으로는 판단할 수 없고, 시간 순서로 엮어야 비로소 그림이 드러납니다.

#### 사고 인지 후에 하지 말아야 할 것

- 대상자의 PC 를 켜서 직접 확인하는 일. 확인하는 순간 접근 시각이 바뀌고, 나중에 "조사자가 만든 흔적" 이라는 반박의 빌미가 됩니다.

- 퇴직자 장비를 초기화해 재지급하는 일. 재사용 시점에 대부분의 흔적이 덮어써집니다.

- 대상자에게 미리 알리고 소명을 요구하는 일. 증거를 정리할 시간을 주는 셈이 됩니다.
### M&A 실사 (PMA) (Post-Merger Audit (PMA))
#### 정의

M&A 실사(PMA, Post-Merger Audit)는 인수·합병이 끝난 뒤 인수한 기업의 실제 상태를 다시 들여다보는 감사입니다. 계약 전에 진행하는 사전 실사(Due Diligence)가 주로 제공된 자료를 검토하는 데 그친다면, PMA는 인수 후 확보한 접근 권한으로 기업 내부의 데이터를 직접 분석해 숨어 있던 문제를 규명합니다.

#### 왜 필요한가

인수 전 실사는 대상 기업이 제공하는 범위 안에서만 이뤄집니다. 감추려는 부정이나 부실은 그 범위 밖에 있기 마련이고, 계약을 서두르는 압박 속에서 놓치는 것도 많습니다. 인수가 끝나 경영권과 데이터에 대한 접근이 확보되면, 그제야 장부 뒤에 가려졌던 횡령·분식·이해충돌 거래가 드러나는 경우가 적지 않습니다.

#### 디지털 포렌식의 역할

PMA의 핵심은 이메일, 회계 시스템, 전자문서 등 인수한 기업의 디지털 데이터를 포렌식 절차로 수집·분석하는 데 있습니다. 삭제된 자료를 복원하고 자금 흐름과 의사결정 기록을 추적해, 무엇이 언제 어떻게 이뤄졌는지를 증거능력 있는 형태로 규명합니다. 이렇게 확보한 사실은 인수 후 손해배상이나 가격 조정, 책임 추궁의 근거가 됩니다.

#### 언제 하는가

보통 인수 직후, 경영권 이전이 마무리된 시점에 시작합니다. 시간이 지날수록 데이터가 덮어써지고 관련자가 이탈해 확인 가능한 범위가 줄기 때문에, 이르게 착수할수록 규명의 폭이 넓어집니다.
### 타임라인 분석 (Timeline Analysis)
#### 시계부터 맞추는 이유

분석 화면에 오전 9시 12분이라는 시각이 보입니다. 저는 그 숫자를 곧바로 사건 시각으로 쓰지 않습니다. 운영체제의 시간대, 서버의 표준시 설정, 모바일 앱의 저장 방식부터 확인합니다. 같은 행위도 PC에는 현지 시각으로, 서버에는 협정세계시로, 내보낸 보고서에는 다시 변환된 시각으로 남을 수 있기 때문입니다.

타임라인 분석은 기록을 시간순으로 정렬하는 작업처럼 보이지만, 실제로는 각 시각이 무엇을 뜻하는지 해석하는 일에 가깝습니다. 파일의 생성 시각, 수정 시각, 접근 시각은 서로 다른 사건을 가리킵니다. 복사나 압축 해제 과정에서 일부 시각이 새로 만들어지기도 합니다.

#### 한 줄의 기록은 한 가지 설명만 허용하지 않습니다

파일이 특정 시각에 수정되었다는 사실만으로 누가 내용을 바꾸었다고 단정할 수는 없습니다. 프로그램의 자동 저장, 동기화, 백업 복원도 같은 흔적을 남깁니다. 저는 파일 시스템 기록을 로그인 이력, 프로그램 실행 기록, 외부 저장매체 연결 기록과 함께 놓고 봅니다. 서로 독립된 기록이 같은 흐름을 가리킬 때 설명의 힘이 생깁니다.

반대로 기록 사이에 어긋남이 있으면 오류로 지우지 않습니다. 시스템 시계가 바뀌었거나, 가상 환경과 실제 장비의 시간이 달랐거나, 수집 이후 파일이 다른 위치로 복사되었을 가능성을 검토합니다. 불일치는 종종 분석의 출발점이 됩니다.

#### 보고서에는 사실과 해석을 나누어 적습니다

저는 확인된 시각과 그 시각에서 추정한 행위를 분리해 씁니다. 예를 들어 '외장 저장매체가 연결되었다'는 기록과 '해당 파일이 외부로 반출되었다'는 판단은 같은 문장이 아닙니다. 파일 접근과 복사를 잇는 추가 흔적이 있어야 두 사실을 연결할 수 있습니다.

좋은 타임라인은 빈칸도 보여 줍니다. 로그 보존기간이 지나 확인할 수 없는 구간, 시간대 변환이 불확실한 기록, 자동화된 동작과 사용자의 동작을 구분하기 어려운 부분을 표시합니다. 사건의 흐름을 매끄럽게 만드는 것보다 어디까지 확인했는지를 정확히 밝히는 편이 낫습니다.

#### 실무에서 확인할 항목

- 기기와 서버의 시간대 및 시계 오차

- 각 타임스탬프의 생성 주체와 변경 조건

- 독립된 기록 사이의 교차 확인

- 확인 사실, 추정, 확인 불가의 구분
### 가명처리와 재식별 위험 (Re-identification Risk)
#### 이름을 지운 표를 다시 봅니다

이름과 전화번호를 삭제한 데이터라도 희귀한 직무, 특정 날짜, 지역 정보가 함께 있으면 한 사람을 짐작할 수 있습니다. 저는 직접 식별자만 제거했다고 해서 가명처리가 끝났다고 보지 않습니다. 조직이 보유한 다른 자료와 외부에서 쉽게 구할 수 있는 정보를 함께 고려합니다.

식별 가능성은 데이터 자체만의 속성이 아닙니다. 누가 어떤 환경에서 어떤 보조정보를 가지고 접근하는지에 따라 달라집니다. 같은 데이터도 통제된 분석실에서 제한된 인원만 다루는 경우와 여러 기관에 파일로 배포하는 경우의 위험이 다릅니다.

#### 쓸모와 위험을 함께 조정합니다

모든 값을 강하게 변형하면 재식별 위험은 낮아질 수 있지만 분석에 필요한 의미도 사라집니다. 반대로 원형을 많이 남기면 활용도는 높아져도 식별 가능성이 커집니다. 저는 연구나 분석 목적에 꼭 필요한 변수부터 정하고, 필요하지 않은 세부값을 줄입니다.

구간화, 범주화, 일부 삭제, 대체값 부여 같은 기법은 목적과 데이터 특성에 맞춰 조합합니다. 비정형 문서나 대화에는 본문 속 이름, 주소, 관계 정보가 흩어져 있어 정형 데이터와 다른 검토가 필요합니다.

#### 분리 보관과 접근 통제가 처리의 일부입니다

가명정보와 추가정보를 분리하고 접근권한을 다르게 두어야 합니다. 재식별 시도를 금지하는 규정만 두는 것으로는 부족합니다. 다운로드 제한, 반출 승인, 접속 기록, 결합 후 파기 같은 운영 통제가 함께 있어야 합니다.

처리 과정과 위험 판단 근거도 기록합니다. 어떤 목적에서 어떤 항목을 어떻게 바꾸었고, 어떤 보조정보를 가정했는지 남겨야 이후 환경이 바뀌었을 때 다시 평가할 수 있습니다.

#### 실무에서 확인할 항목

- 직접 식별자 외의 준식별자 조합

- 처리 목적에 필요한 최소 변수

- 이용자, 제공 방식과 보조정보 환경

- 추가정보 분리, 접근 기록과 재평가 절차
### 클라우드 동기화 반출 (Cloud-Sync Leaks)
#### 파일을 보내지 않아도 밖으로 나갈 수 있습니다

사용자는 파일을 첨부하거나 업로드 버튼을 누르지 않았다고 말할 수 있습니다. 개인 클라우드 동기화 폴더에 저장한 순간 백그라운드 프로그램이 자동으로 전송했을 가능성이 있습니다. 저는 사용자의 명시적 동작과 프로그램의 자동 동작을 나누어 봅니다.

클라우드 유출은 파일 내용보다 계정과 동기화 설정에서 시작하는 경우가 많습니다. 어떤 계정으로 로그인했는지, 어떤 폴더가 연결되었는지, 선택적 동기화가 켜졌는지 확인합니다.

#### 공유 링크는 사본이 아니라 접근권한을 밖으로 보냅니다

파일이 조직 저장소에 그대로 있어도 외부 공개 링크가 만들어지면 통제 범위는 달라집니다. 링크에 만료일과 비밀번호가 있는지, 검색이나 재공유가 가능한지, 누가 실제로 내려받았는지를 봐야 합니다.

링크 생성 기록만으로 실제 유출을 단정하기는 어렵습니다. 외부 접속과 다운로드 기록이 있어야 전달 여부를 더 구체적으로 판단할 수 있습니다. 제공자가 세부 로그를 보관하지 않거나 계약 등급에 따라 제공 범위가 제한될 수도 있습니다.

#### 초기 대응은 연결을 끊되 기록을 먼저 남깁니다

사고가 의심될 때 계정을 즉시 삭제하면 추가 전송은 막을 수 있지만 조사에 필요한 설정과 로그도 사라질 수 있습니다. 저는 가능한 범위에서 세션과 공유 상태를 보존한 뒤 접근을 차단합니다. 차단과 증거 보존의 순서를 상황에 맞게 정해야 합니다.

예방 단계에서는 승인된 저장소, 개인 계정 사용 기준, 동기화 프로그램 설치 정책, 외부 공유 경보를 함께 운영합니다. 금지 문구만으로는 자동 동기화의 특성을 통제하기 어렵습니다.

#### 실무에서 확인할 항목

- 로그인 계정과 동기화 폴더 설정

- 클라이언트 설치 및 실행 흔적

- 공유 링크의 범위, 만료와 외부 접속 기록

- 차단 전 보존해야 할 설정과 감사 로그
### 장비 중간점검 (Equipment Intermediate Checks)
#### 어제 정상이라고 오늘도 정상인 것은 아닙니다

장비의 교정성적서나 적격성 기록이 유효해도 사용 중 케이블, 저장장치, 소프트웨어 설정이 바뀔 수 있습니다. 저는 사용일마다 모든 성능을 다시 시험하지는 않지만, 결과에 영향을 주는 핵심 상태를 확인합니다.

중간점검은 교정을 대신하지 않습니다. 정해진 교정이나 검증 주기 사이에 장비가 관리 상태를 벗어나지 않았는지 조기에 확인하는 장치입니다. 장비 특성과 사용 빈도, 고장 이력, 결과에 미치는 영향을 기준으로 항목과 주기를 정합니다.

#### 점검 항목은 판정할 수 있어야 합니다

전원이 켜진다는 확인만으로 장비의 핵심 기능을 보증하기 어렵습니다. 반대로 매번 전체 성능시험을 하면 기록이 형식적으로 흐를 수 있습니다. 저는 장비별로 기준 데이터, 자가진단 결과, 해시 일치, 처리 속도 범위처럼 실제 기능과 연결된 항목을 고릅니다.

판정 기준도 수치나 명확한 상태로 정합니다. 정상, 양호 같은 표현만 두면 작업자마다 판단이 달라집니다. 허용 범위를 벗어났을 때 사용 중지, 재확인, 수리, 책임자 보고 절차까지 연결합니다.

#### 이상은 발견 시점 이전의 결과에도 질문을 던집니다

중간점검에서 이상이 확인되면 그날의 장비만 격리해서 끝내지 않습니다. 마지막 정상 확인 이후 수행한 시험 결과가 영향을 받았는지 검토해야 합니다. 영향이 없다고 판단했다면 그 근거도 남깁니다.

점검 기록은 날짜와 서명만 채우는 양식이 아닙니다. 사용한 기준물, 결과, 판정, 이상 조치와 영향평가를 연결해야 합니다. 이렇게 해야 장비 상태와 발행된 결과 사이의 신뢰 관계를 설명할 수 있습니다.

#### 실무에서 확인할 항목

- 장비 위험도와 사용 빈도에 맞는 점검 주기

- 핵심 기능과 연결된 점검 항목

- 수치 또는 명확한 상태로 정한 판정 기준

- 이상 발견 시 이전 시험 결과의 영향평가
### 서비스 계정 관리 (Managing service accounts)
#### 담당자는 바뀌었지만 작업은 계속됩니다

한 점검에서 계정 이름에 이미 퇴직한 이전 담당자의 흔적이 남아 있는 것을 발견했습니다. 지금도 그 계정으로 배치 작업이 매일 실행되고 있었지만, 비밀번호를 누가 관리하는지는 아무도 명확히 답하지 못했습니다.

서비스 계정은 사람이 직접 로그인하기보다 프로그램이 작업을 수행하는 데 사용하는 계정입니다. 사용자가 퇴직했다고 같은 방식으로 중지하면 업무가 멈출 수 있습니다.

#### 소유자와 사용처

저는 계정마다 업무 책임자와 기술 관리자를 연결합니다. 만든 사람보다 현재 용도와 변경 영향을 설명할 수 있는 사람이 필요합니다. 접근하는 시스템, 수행하는 작업, 실행 주기를 확인하며, 사용 기록이 드물어도 월말 처리나 비상 복구에 쓰일 수 있으므로 마지막 접속일만으로 폐기를 정하지 않습니다.

#### 권한과 인증정보

관리자 권한이 정말 필요한지, 여러 업무가 하나의 계정을 공유하는지 살핍니다.

- 가능한 환경에서는 용도별 계정과 사람의 로그인 제한을 검토합니다.

- 비밀번호와 키는 소스코드나 공유 문서에 직접 두지 않고 적절한 비밀정보 관리 수단을 씁니다. 플랫폼이 지원하면 관리형 식별자 등 별도 비밀번호 보관을 줄이는 방식도 검토합니다.

#### 교체가 필요한 순간

인증정보를 바꾸기 전에는 연결 작업과 시험·복구 방법을 확인하고, 교체 후에는 새 정보의 작동뿐 아니라 이전 정보가 더 이상 유효하지 않은지도 점검합니다. 계정 관리 목록에는 "사용 중"보다 무엇이 이 계정에 의존하는지가 보여야, 권한 축소나 폐기를 결정할 때 업무 영향을 함께 판단할 수 있습니다.

#### 정리

정리하면, 서비스 계정은 사람 계정과 다른 기준으로 관리합니다. 소유자와 의존 업무를 밝히고 권한을 최소화하며, 인증정보 교체는 연결 작업까지 확인한 뒤 마칩니다.
### 인정과 표준 (Accreditation and Standards)
#### 인정과 인증

두 용어는 자주 혼용되지만 층위가 다릅니다.

- 인증(Certification): 제품, 서비스, 시스템, 사람이 특정 기준에 적합함을 제3자가 확인해 주는 것입니다.

- 인정(Accreditation): 그 인증이나 시험을 수행하는 기관 이 그럴 자격과 능력을 갖췄음을 공인 기구가 확인해 주는 것입니다.

혼동하기 쉬우니 한 번 더 짚습니다. 인증은 대상 이 기준에 맞는지를 봅니다. 인정은 그 판단을 내리는 기관 이 그럴 능력이 있는지를 봅니다. 그래서 KOLAS 는 인증기관이 아니라 인정기관 입니다.

즉 인정은 검사하는 자를 검사하는 제도입니다. 시험 결과를 믿으려면 그 시험을 수행한 기관을 믿을 수 있어야 하고, 그 기관을 믿으려면 누군가 그 기관을 확인해 주어야 합니다. 신뢰의 사슬을 한 칸 위로 올려 두는 장치인 셈입니다.

#### 신뢰는 어디에서 오는가

어떤 주장을 믿는 방법은 크게 셋입니다. 스스로 확인하거나, 주장하는 사람을 믿거나, 제3자의 검증을 믿는 것입니다.

첫 번째는 대부분의 경우 불가능합니다. 시험 결과를 직접 확인하려면 같은 장비와 같은 전문성이 있어야 하는데, 그럴 수 있다면 애초에 시험을 의뢰하지 않았을 것입니다. 두 번째는 이해관계가 걸리는 순간 무너집니다. 결과에 따라 손해를 보는 쪽이 그 결과를 낸 사람의 선의를 믿어 줄 리 없습니다. 남는 것은 세 번째이고, 인정과 인증은 그 세 번째를 제도로 만든 것입니다.

#### 왜 필요한가

시험 결과는 그 자체로는 하나의 주장에 불과합니다. 어떤 절차로 시험했는지, 장비는 교정되어 있었는지, 담당자는 자격을 갖췄는지, 결과가 재현되는지에 따라 결론은 달라질 수 있습니다. 같은 시료를 두 기관이 시험해 다른 결과를 내놓는 일도 실제로 벌어집니다.

인정 제도는 이런 요소들을 개별 시험 건이 아니라 기관 차원 에서 관리하도록 요구함으로써, 그 기관이 내놓는 모든 결과의 신뢰를 함께 끌어올립니다. 결과 하나하나를 검증하는 대신, 결과를 만들어 내는 시스템을 검증하는 접근입니다. 매번 답을 채점하는 대신 채점자를 검증하는 쪽이 훨씬 효율적이기도 합니다.

#### 표준이라는 공통 언어

인정의 기준이 되는 것이 국제 표준입니다. 표준이 없으면 인정 기구마다 다른 잣대를 쓰게 되고, 그러면 A 나라의 인정과 B 나라의 인정이 서로 무엇을 보증하는지 알 수 없게 됩니다.

표준은 그래서 기술 문서이면서 동시에 약속입니다. 시험기관에는 ISO/IEC 17025, 검사기관에는 ISO/IEC 17020, 인증기관에는 ISO/IEC 17065 처럼 대상에 따라 적용되는 표준이 다르고, 각 표준은 그 유형의 기관이 갖춰야 할 최소한을 규정합니다.

#### 포렌식에서의 의미

디지털 포렌식에서도 같은 논리가 적용됩니다. 같은 분석 결과라도 인정받은 절차와 품질 시스템 아래에서 산출되었다면, 법정에서 다툼이 생겼을 때 그 신뢰도를 설명하기가 훨씬 수월합니다.

반대로 절차가 문서화되어 있지 않고 담당자의 숙련도에만 기대는 조직은, 담당자가 아무리 유능해도 그 유능함을 제3자에게 증명할 방법이 없습니다. 법정에서 "저는 20년 경력입니다" 는 답변이 되지 못합니다. 개인의 실력을 조직의 신뢰로 바꾸는 장치가 표준과 인정입니다.
### 모바일 앱 데이터 (Mobile App Data)
#### 화면은 데이터의 일부만 보여 줍니다

메신저 대화방에는 몇 줄만 남아 있는데 기기 내부 데이터베이스에는 대화방 식별값과 전송 상태가 남아 있는 경우가 있습니다. 반대도 있습니다. 화면에는 보이지만 실제 내용은 서버에서 잠시 불러온 것이어서 기기 안에는 거의 남지 않습니다. 저는 화면을 기록의 원본으로 보기보다 앱이 선택해 보여 주는 결과로 봅니다.

모바일 앱은 데이터베이스, 설정 파일, 캐시, 첨부파일 폴더를 나누어 사용합니다. 같은 메시지도 본문, 발신자 정보, 전송 시각, 미디어 파일이 서로 다른 위치에 저장될 수 있습니다. 한 경로만 확인하면 내용은 찾았지만 맥락을 잃을 수 있습니다.

#### 삭제와 동기화는 같은 현상이 아닙니다

사용자가 메시지를 지운 경우, 서버 정책에 따라 기기에서도 바로 없어질 수 있고 일부 메타데이터만 남을 수 있습니다. 다른 기기에서 로그아웃하거나 계정이 비활성화되어도 비슷한 변화가 생깁니다. 저는 '화면에 없다'는 사실을 삭제 행위와 곧바로 연결하지 않습니다.

앱 업데이트도 저장 구조를 바꿉니다. 이전 버전에서 쓰던 데이터베이스가 새 형식으로 변환되거나, 암호화 키의 보관 위치가 달라질 수 있습니다. 분석 도구가 지원하는 앱 버전과 단말의 실제 버전이 맞지 않으면 일부 데이터가 누락되거나 잘못 해석될 수 있습니다.

#### 도구 결과를 원시 데이터와 맞춰 봅니다

분석 도구가 보기 좋은 대화 목록을 만들어 주더라도 저는 중요한 항목을 원시 데이터와 다시 맞춰 봅니다. 시각 변환, 삭제 상태, 참여자 식별값처럼 판단에 영향을 주는 필드는 특히 그렇습니다. 자동 분류는 검토의 시작점이지 최종 판단이 아닙니다.

수집 방식에 따라 확인 범위도 다릅니다. 일반 백업, 파일 시스템 수집, 물리적 수집은 접근할 수 있는 영역이 서로 다릅니다. 보고서에는 어떤 방식으로 무엇을 확보했는지와 함께, 그 방식으로 확인하기 어려운 영역도 적어야 합니다.

#### 실무에서 확인할 항목

- 앱 버전과 단말 운영체제 버전

- 화면 데이터, 로컬 저장 데이터, 서버 데이터의 구분

- 분석 도구 결과와 원시 데이터의 대조

- 수집 방식에 따른 확인 범위와 한계
### 이상거래와 부정의 구분 (Anomaly vs. Fraud)
#### 목록의 첫 줄은 결론이 아닙니다

심야 결제, 휴일 사용, 같은 금액의 반복 지급이 화면에 표시됩니다. 저는 이 목록을 부정 적발 결과라고 부르지 않습니다. 정상적인 긴급 업무, 정기 구독, 분할 납품도 같은 모양을 만들 수 있기 때문입니다. 분석 규칙이 찾는 것은 설명이 필요한 거래입니다.

이 구분이 무너지면 감사인은 예외 건수를 성과처럼 세게 되고, 현업은 방어적으로 변합니다. 데이터 분석의 목적은 사람을 먼저 지목하는 데 있지 않습니다. 전체 거래에서 검토 우선순위를 정하고, 기존 표본감사에서 놓치기 쉬운 패턴을 찾는 데 있습니다.

#### 규칙은 회사의 업무 구조를 반영해야 합니다

같은 법인카드 규칙도 부서에 따라 의미가 다릅니다. 교대근무 부서와 일반 사무부서의 심야 사용 기준을 같게 두면 불필요한 경보가 늘어납니다. 저는 사내 규정만 읽지 않고 비용이 실제로 발생하는 과정과 승인 관행을 함께 확인합니다.

기준일, 금액 구간, 거래처 분류, 승인권자 관계를 조합하면 탐지의 맥락이 생깁니다. 규칙을 복잡하게 만드는 것이 목적은 아닙니다. 어떤 위험 가설을 확인하려는지 한 문장으로 설명할 수 있어야 합니다.

#### 예외에서 감사 증거로 넘어가는 단계

탐지된 거래는 원전표, 결재 내역, 계약, 납품 기록, 시스템 접속 이력과 맞춰 봅니다. 담당자의 설명도 필요하지만 설명만으로 닫지는 않습니다. 설명과 당시 기록이 서로 맞는지 확인합니다.

최종 결과에는 전체 예외 건수보다 검증 기준이 더 중요합니다. 어떤 조건으로 선별했고, 무엇을 추가 확인했으며, 정상과 미흡을 어떻게 구분했는지를 남깁니다. 그래야 다음 감사에서도 같은 기준을 적용하고 규칙을 조정할 수 있습니다.

#### 실무에서 확인할 항목

- 탐지 규칙이 가리키는 위험 가설

- 부서와 업무 유형별 정상 범위

- 거래 원장과 비정형 증빙의 연결

- 정상, 미흡, 추가 확인 필요의 판정 기준
### 개인정보 파기와 사본 (Data Disposal and Leftover Copies)
#### 삭제 버튼이 파기의 끝은 아닙니다

업무 시스템에서 고객 기록을 삭제했지만 같은 자료가 담당자의 다운로드 폴더와 메일 첨부에 남아 있을 수 있습니다. 저는 파기를 하나의 기능이 아니라 여러 저장 위치를 정리하는 과정으로 봅니다.

개인정보는 수집 이후 가공, 전달, 백업 과정에서 복제됩니다. 운영 데이터베이스만 기준으로 보유기간을 관리하면 주변 사본은 주인을 잃습니다. 흐름도와 보유기간표를 연결해야 하는 이유입니다.

#### 백업은 즉시 삭제가 어려울 수 있습니다

백업은 장애 복구를 위해 일정 기간 세대별로 보관됩니다. 개별 정보만 골라 지우기 어려운 구조도 있습니다. 그렇다고 백업을 파기 대상에서 빼도 된다는 뜻은 아닙니다. 복원 목적 외 접근을 제한하고, 정해진 주기가 지나면 덮어쓰거나 삭제되도록 관리해야 합니다.

복원 시험을 할 때도 주의가 필요합니다. 오래된 백업을 복원하면 이미 파기된 개인정보가 운영 환경으로 되살아날 수 있습니다. 복원 후 최신 파기 상태를 다시 반영하는 절차가 있어야 합니다.

#### 파기 확인은 행위와 결과를 나누어 봅니다

담당자가 삭제 작업을 했다는 보고와 실제로 대상 정보가 남아 있지 않다는 확인은 다릅니다. 저는 대상 범위, 실행 일시, 사용한 방법, 예외, 확인 결과를 구분해 기록합니다. 위탁사가 처리한 정보라면 파기 요청뿐 아니라 이행 여부도 확인합니다.

보존 의무가 있는 정보는 다른 자료와 분리해 목적 외 사용을 막습니다. 모든 데이터를 한꺼번에 지우는 것도, 보존을 이유로 계속 열어 두는 것도 적절하지 않습니다. 파기는 데이터마다 남아야 할 이유와 없어져야 할 시점을 구분하는 일입니다.

#### 실무에서 확인할 항목

- 운영 시스템 외 로컬, 메일, 공유폴더 사본

- 백업 보존주기와 복원 후 재삭제 절차

- 위탁사와 하위 수탁사의 파기 확인

- 법정 보존 데이터의 분리 저장과 접근 제한
### 퇴직 전후 유출 위험 (Departure-Related Leak Risk)
#### 위험은 퇴직 통보일에 갑자기 생기지 않습니다

대량 다운로드가 퇴직 직전에 발생하면 눈에 띕니다. 하지만 자료는 그보다 앞서 개인 메일, 메신저, 클라우드에 조금씩 쌓였을 수 있습니다. 저는 퇴직일 하루보다 업무 변화가 시작된 구간을 봅니다.

프로젝트 종료, 부서 이동, 장기 휴직, 외부 협업 종료도 비슷한 전환점입니다. 접근권한은 남아 있는데 업무상 필요는 줄어드는 시기라면 점검이 필요합니다.

#### 정상적인 인수인계와 비정상 반출은 모양이 비슷합니다

퇴직 전에는 문서를 많이 열고 정리하며 동료에게 전달합니다. 대량 접근만으로 유출을 판단하면 정상적인 인수인계를 의심하게 됩니다. 저는 대상 자료, 전달 경로, 수신자, 승인 여부와 평소 업무 패턴을 함께 봅니다.

조직이 인수인계 저장소와 절차를 미리 정해 두면 정상 행위의 경로가 분명해집니다. 개인 저장장치나 임의의 메신저를 쓸 이유도 줄어듭니다. 통제는 의심을 늘리는 장치가 아니라 정상 업무의 길을 명확히 하는 장치여야 합니다.

#### 퇴직 뒤에는 회사 자료의 잔존을 확인합니다

회사 기기를 회수해도 개인 휴대전화의 업무 앱, 개인 클라우드에 동기화된 폴더, 외부 협업 공간의 게스트 권한이 남을 수 있습니다. 저는 계정 회수와 함께 자료 반환 및 삭제 확인 범위를 정합니다.

모든 퇴직자를 같은 강도로 조사하는 것은 적절하지 않습니다. 정보 민감도, 접근 범위, 역할 변화, 이상 징후에 따라 점검 수준을 나눕니다. 그 기준을 사전에 고지하고 일관되게 적용해야 개인정보 침해와 불필요한 갈등을 줄일 수 있습니다.

#### 실무에서 확인할 항목

- 퇴직일 이전의 역할 및 접근 패턴 변화

- 인수인계 공식 경로와 승인 기록

- 개인 기기, 클라우드와 외부 협업 계정

- 위험도에 따른 점검 기준과 사전 고지
### 보안 예외 관리 (Managing security exceptions)
#### 끝나지 않는 임시 허용

한 사례에서 장애 조치를 위해 접근 제한을 잠시 해제했습니다. 업무는 곧 정상화됐지만 설정은 그대로 남았고, 해제 당시의 담당자가 바뀌면서 원상복구할 이유도 함께 잊혔습니다. 임시 허용이 사실상 상시 허용이 된 것입니다.

저는 예외 요청에서 시작일과 종료 조건을 같이 봅니다. "필요할 때까지"라는 표현은 언제 만료되는지 판단하기 어렵습니다.

#### 필요한 만큼의 범위

특정 파일 하나를 전달하려는데 외부 전송 전체를 허용해야 하는지 살피고, 대상 계정·경로·시간을 좁힐 수 있는지 검토합니다. 추가 로그, 별도 승인, 접근 장소 제한 등을 보완 조치로 둘 수 있습니다. 다만 기록을 더 남기는 조치가 전송 자체를 막는 조치와 같은 효과를 낸다고 보지는 않습니다.

#### 승인과 책임

요청 사유, 대안 검토, 허용 범위와 남은 위험을 승인권자가 이해할 수 있게 제시합니다. 내부 승인으로 법령이나 계약상의 제한까지 해소되는 것은 아닙니다. 설정 변경 기록과 승인 문서를 연결하고, 가능하면 만료 시 권한이 자동 회수되도록 구성하되 업무 영향이 있으면 사전 안내와 종료 확인을 함께 둡니다.

#### 반복되는 예외의 의미

같은 예외가 계속 요청되면 승인자를 늘리는 것만으로 해결되지 않습니다. 기본 통제가 업무와 맞지 않거나 필요한 기능이 빠져 있을 수 있습니다. 연장할 때는 실제 사용 여부와 사고·오류 발생 여부도 확인해, 반복 예외를 정식 절차로 바꿀지 업무 방식을 바꿀지 판단할 자료로 삼습니다.

#### 정리

정리하면, 예외는 범위와 기간과 책임이 정해질 때만 통제됩니다. 종료 조건 없는 임시 허용을 남기지 않고, 반복되는 예외는 통제 자체를 다시 볼 신호로 읽습니다.
### 분석 도구 변경관리 (Change management for analysis tools)
#### 업데이트 전후의 차이

한 작업에서 같은 자료를 분석 도구의 새 버전으로 다시 처리했더니 항목 수가 달라졌습니다. 이전에 누락됐던 항목이 추가된 것인지, 중복이 늘어난 것인지, 분류 기준이 바뀐 것인지 확인이 필요했습니다.

저는 항목 수가 늘었다는 이유만으로 결과가 좋아졌다고 판단하지 않습니다. 변경된 기능과 차이가 발생한 자료를 연결해 봅니다.

#### 비교 기준의 설정

수집, 해석, 검색, 내보내기 중 어느 기능이 바뀌었는지 구분하고, 실제 업무에 사용하는 기능인지 확인합니다. 기존 버전과 같은 결과가 나온다는 사실만으로 정확성이 보장되지는 않으므로, 알려진 기대 결과와 원시 자료에 비추어 차이를 설명합니다. 시험방법 검증이 방법의 수행 가능성과 적합성을 확인한다면, 변경관리는 그 판단을 언제 다시 해야 하고 어떤 업무에 적용할지 관리하는 역할을 합니다.

#### 진행 중인 분석의 처리

분석 중간에 버전을 바꾸면 하나의 보고서에 서로 다른 조건의 결과가 섞일 수 있습니다. 기존 환경을 유지할지, 영향을 받는 부분을 다시 처리할지 정해야 합니다. 보안상 긴급 업데이트라면 적용 지연의 위험도 고려하고, 변경 사유와 적용 시점, 재처리 범위를 정해 필요한 제한을 표시합니다.

#### 되돌릴 수 있는 범위

이전 설치 파일이 있어도 라이선스나 외부 서비스 변경 때문에 같은 환경을 재구성하지 못할 수 있습니다. 복구 가능성을 실제 조건에 맞춰 확인합니다. 최종 결과에 사용된 버전과 주요 설정을 식별할 수 있게 남기고, 검토를 마친 환경부터 업무에 적용합니다.

#### 정리

정리하면, 버전 변화는 결과의 좋고 나쁨이 아니라 차이의 원인으로 봅니다. 어떤 기능이 왜 달라졌는지 설명하고, 검토를 마친 환경과 버전만 업무에 적용합니다.
### AI 포렌식 (AI Forensics)
#### 빠른 요약보다 입력 범위를 먼저 봅니다

수천 건의 문서에서 관련 가능성이 있는 자료를 가려낼 때 AI는 유용한 보조 수단이 될 수 있습니다. 저는 먼저 어떤 자료가 입력되는지 확인합니다. 조사 대상 문서에는 개인정보, 영업상 비밀, 법률 검토 내용이 섞일 수 있어 외부 서비스로 전송하는 순간 별도의 위험이 생깁니다.

모델이 데이터를 학습에 사용하는지, 입력과 출력이 어디에 저장되는지, 관리자나 서비스 제공자가 접근할 수 있는지를 확인해야 합니다. 기술의 정확도보다 먼저 정해야 할 것은 처리 경계입니다.

#### AI의 답은 증거가 아니라 탐색 단서입니다

AI는 문서의 주제를 묶고, 유사한 표현을 찾고, 검토 순서를 정하는 데 도움을 줄 수 있습니다. 다만 누가 어떤 행위를 했는지 판단하는 단계에서는 원문과 원시 기록으로 돌아가야 합니다. 요약 과정에서 조건문이나 부정 표현이 빠지면 문서의 의미가 달라질 수 있습니다.

저는 AI가 제시한 분류를 표본으로 재검토하고, 반대 사례도 따로 찾습니다. 관련성이 낮다고 분류된 자료 중 중요한 문서가 빠지지 않았는지 확인하는 절차가 필요합니다. 탐지된 항목만 살피면 누락을 알 수 없습니다.

#### 같은 결과를 다시 설명할 수 있어야 합니다

분석에 사용한 모델과 버전, 입력 범위, 지시문, 주요 설정, 검토 기준을 기록합니다. 모델이 바뀌면 같은 입력에서도 출력이 달라질 수 있으므로 결과 문장만 보관해서는 재현하기 어렵습니다. 가능하면 핵심 판단은 규칙과 원문 근거로 다시 표현합니다.

보고서에서는 AI가 수행한 부분과 사람이 확인한 부분을 나눕니다. AI가 초벌 분류를 했고 분석자가 원문을 확인했다면 그 과정을 그대로 적습니다. 도구의 역할을 숨기지 않는 것이 결과의 한계를 이해하는 데 도움이 됩니다.

#### 실무에서 확인할 항목

- 입력 데이터의 반출 및 보관 조건

- 모델, 버전, 지시문과 설정 기록

- 오탐뿐 아니라 누락에 대한 표본 검토

- 최종 판단의 원문 및 원시 기록 연결
### 감사 인터뷰 (Audit Interviews)
#### 질문지는 회의실에 들어가기 전에 만들어집니다

인터뷰 직전에 파일을 훑고 질문을 적으면 확인하고 싶은 사실과 이미 믿고 있는 해석이 섞이기 쉽습니다. 저는 먼저 거래, 결재, 접속, 문서 작성 시각을 간단한 순서로 배열합니다. 그다음 빈 구간과 서로 맞지 않는 지점을 질문으로 바꿉니다.

좋은 질문은 정답을 포함하지 않습니다. '왜 승인 없이 처리했습니까'보다 '이 거래가 요청되어 승인되기까지의 과정을 설명해 주십시오'가 더 많은 정보를 줍니다. 처음부터 위반을 전제하면 상대방은 사실을 설명하기보다 전제를 반박하는 데 집중합니다.

#### 기억과 기록은 역할이 다릅니다

사람의 기억은 시간이 지나며 바뀌고, 익숙한 업무는 여러 날의 경험이 섞일 수 있습니다. 그렇다고 진술이 쓸모없는 것은 아닙니다. 기록에 남지 않는 업무 관행, 역할 분담, 예외 처리 이유를 이해하는 데 필요합니다.

저는 진술을 곧바로 사실로 확정하지 않고 확인할 가설로 적습니다. 인터뷰 중 제시된 시스템명, 담당자, 문서, 시각을 후속 자료와 맞춰 봅니다. 진술과 기록이 다르면 어느 한쪽을 즉시 거짓으로 판단하지 않고, 기록 생성 방식과 기억의 근거를 다시 확인합니다.

#### 인터뷰 기록에는 질문의 맥락도 남깁니다

답변만 옮기면 같은 문장도 의미가 달라질 수 있습니다. 누가 참석했고, 어떤 자료를 제시한 뒤 질문했는지, 답변자가 확인 후 보완하기로 한 내용이 무엇인지 함께 기록합니다. 중요한 진술은 표현을 바꾸어 요약하기보다 당사자가 확인할 수 있는 방식으로 남기는 편이 안전합니다.

인터뷰가 끝난 뒤에는 불리한 정황뿐 아니라 반대 방향의 자료도 찾습니다. 감사인의 첫 가설을 지지하는 답만 모으면 질문은 많아도 검증은 약합니다.

#### 실무에서 확인할 항목

- 사실, 해석, 미확인 영역을 구분한 사전 타임라인

- 전제를 넣지 않은 개방형 질문

- 진술과 당시 생성 기록의 교차 확인

- 초기 가설을 반박할 자료의 별도 탐색
### 비인가 AI 사용 관리 (Managing unsanctioned AI use)
#### 개인 계정에 올라간 업무 문서

한 부서에서 긴 문서를 빨리 요약하려고 개인 계정의 AI에 파일을 통째로 올렸습니다. 사용자는 편리한 기능을 쓴 것뿐이지만, 조직은 어떤 자료가 외부로 전달되었는지 알기 어려웠습니다.

비인가 AI는 별도 챗봇만을 뜻하지 않습니다. 문서 도구, 브라우저 확장, 회의 서비스에 추가된 기능도 관리 범위에 들어올 수 있습니다.

#### 서비스 이름만으로 정하지 않습니다

저는 서비스, 계정 유형, 입력 데이터, 사용 목적을 함께 봅니다. 같은 서비스라도 계약과 설정에 따라 데이터 처리 조건이 다를 수 있습니다. 공개 자료의 문장 정리와 내부 조사자료 분석을 같은 수준으로 허용하기는 어렵고, 무료·유료 여부만으로 안전성을 구분하지도 않습니다. "학습에 사용하지 않는다"는 조건도 보관, 관리자 접근, 외부 처리 문제를 모두 설명하지는 않으므로 필요한 처리 조건을 각각 확인합니다.

#### 파악과 대안 제공

사용 현황은 담당자 설명, 도입 목록, 적법하게 운영하는 보안 관리 자료 등으로 확인할 수 있습니다. 현황 파악을 이유로 개인 계정의 내용까지 무제한으로 열람하는 방식은 적절하지 않습니다. 사용 목적을 함께 확인해야 대안을 마련할 수 있고, 대안 없이 금지된 도구가 하던 업무를 수행할 방법이 없으면 사용이 다른 곳으로 이동합니다.

#### 이미 사용한 자료의 처리

입력 범위와 공유 상태, 서비스의 삭제·보관 조건을 확인합니다. 이후 판단에 필요한 정보를 확보하면서 추가 입력과 노출을 제한합니다. 승인 목록에는 서비스 이름만 적기보다 허용 데이터와 업무 범위를 붙여, 사용자가 자신의 작업이 그 범위에 드는지 판단할 수 있게 합니다.

#### 정리

정리하면, 비인가 AI는 이름이 아니라 입력 자료와 사용 목적으로 판단합니다. 현황을 과도한 열람 없이 파악하고 대안을 함께 제시해야, 금지가 사용을 음지로 옮기지 않습니다.
### 테스트 데이터의 개인정보 (Personal data in test environments)
#### 재현되지 않는 오류

한 시스템에서 시험 환경은 멀쩡한데 운영 환경에서만 오류가 났습니다. 실제 자료를 그대로 복사해 오면 원인을 금방 찾을 것 같았고, 실제로 그렇게 하려는 요청이 있었습니다.

저는 먼저 실제 사람의 정보가 필요한지, 데이터의 구조만 필요한지 나눕니다. 문자 길이, 빈값, 중복, 필드 간 관계를 재현하는 것으로 충분할 때가 많기 때문입니다.

#### 가상 데이터가 유지해야 할 것

가상 자료를 만들더라도 정상값만 채우면 운영 환경의 문제를 찾기 어렵습니다. 허용 경계값, 누락, 예상하지 못한 조합, 업무상 예외를 포함할 필요가 있습니다. 원본에서 값을 치환하는 경우에는 다른 항목과 연결해 사람을 알아볼 수 있는지 확인합니다. 이름만 바꿨다는 이유로 개인정보가 아니라고 판단하지 않으며, 실제 정보를 꼭 써야 하면 목적과 처리 근거, 필요한 항목·대상·기간을 검토합니다.

#### 외부로 이어지는 시험 기능

실제 연락처가 남은 상태에서 알림 기능을 시험하면 고객에게 문자나 메일이 발송될 수 있습니다. 데이터만 가리는 것 외에 외부 연동과 전송 대상도 통제해야 합니다. 개발자와 외부 인력의 접근 범위, 공유 계정, 다운로드 권한을 살피고, 운영 환경의 보호 조치가 시험 환경에도 그대로 적용된다고 가정하지 않습니다.

#### 시험 이후의 사본

데이터베이스를 지워도 오류 로그, 화면 캡처, 담당자의 파일에는 정보가 남을 수 있습니다. 사용 승인의 범위에 사본 정리까지 포함하는 편이 좋습니다. 시험 결과를 남기는 데 실제 개인정보가 필요한지 다시 보고, 오류 조건과 처리 결과만으로 설명할 수 있다면 불필요한 값은 결과물에서 제외합니다.

#### 정리

정리하면, 시험에 실제 사람의 정보가 꼭 필요한지 먼저 묻습니다. 구조만 필요하면 가상 데이터로 대체하고, 외부 연동과 사본까지 통제 범위에 넣습니다.
### 공유 링크 노출 (Shared link exposure)
#### 한 명에게 보낸 링크

한 담당자가 협력업체 한 곳에 자료 링크를 보냈습니다. 그런데 접근 설정이 링크를 가진 모든 사람이어서, 전달 대상과 실제로 접근할 수 있는 대상이 서로 달랐습니다.

공유 링크 노출은 의도하지 않은 사람이 자료에 접근할 수 있는 상태를 포함합니다. 실제로 누가 열었는지, 얼마나 내려받았는지는 별도로 확인해야 합니다.

#### 권한이 생긴 경로

저는 링크 설정과 직접 부여한 권한을 함께 봅니다. 링크를 해제해도 사용자에게 직접 준 권한이 남을 수 있기 때문입니다.

- 상위 폴더나 그룹에서 권한을 받는 경우도 확인합니다. 로그인 필요 여부, 열람·편집·다운로드 범위, 만료 조건을 구분합니다.

- 다운로드 버튼을 제한했다고 화면 촬영이나 다른 방식의 복사까지 막았다고 보지 않습니다.

#### 노출과 이용의 차이

공개 범위와 설정 변경 시점을 확인하고, 서비스가 제공하는 접근·다운로드 기록을 살핍니다. 확인 가능한 기간과 익명 접근의 식별 한계도 함께 검토합니다. 링크가 열릴 수 있었다는 사실은 실제 이용을 입증하지 않고, 반대로 이용 기록이 없다는 사실도 로그가 충분하지 않으면 미접근의 근거가 되기 어렵습니다.

#### 차단을 확인하는 방법

필요한 기록을 확보하면서 노출을 제한하고, 조치 후에는 기존 링크, 직접 권한, 다른 공유 경로가 남았는지 확인합니다. 업무상 허용된 시험 방법으로 접근 제한을 확인할 수 있습니다. 다만 링크 차단은 이미 확보된 사본까지 회수하는 조치가 아니므로, 외부 보유 가능성이 있으면 별도의 후속 확인이 필요합니다.

#### 정리

정리하면, 접근 가능한 상태와 실제 이용은 다른 문제입니다. 링크와 직접 권한을 함께 정리하고, 차단이 이미 나간 사본까지 회수하지 못한다는 점을 전제로 후속을 봅니다.
### 시험결과의 기술검토 (Technical review of test results)
#### 자연스러운 문장 안의 오류

한 보고서의 표와 결론이 매끄럽게 연결되어 있었습니다. 그런데 표의 시각만 다른 시간대로 변환되어 있어, 겉보기에는 자연스러운 문장 안에서 결론까지 영향을 받고 있었습니다.

기술검토는 문장을 매끄럽게 다듬는 작업과 다릅니다. 저는 중요한 판단에서 출발해 사용한 자료와 변환 과정까지 거슬러 올라갑니다.

#### 검토할 연결

대상 식별정보, 방법, 설정, 계산과 변환, 보고된 결과가 서로 일치하는지 확인하고, 직접 확인한 사실보다 결론이 넓어지지 않았는지도 봅니다. 원시기록을 찾을 수 없는 핵심 결과는 서명만으로 보완할 수 없으므로, 근거를 확보하거나 재확인하고 그 전까지 발행 여부를 판단합니다. SWGDE 품질관리 지침도 기술검토를 보고서 발행 전 오류를 발견하고 수정하는 활동으로 다룹니다.

#### 범위와 검토자

기관의 요구사항과 업무 특성에 따라 검토 범위를 정합니다. 위험을 고려한 검토가 필요한 필수 항목을 임의로 생략하는 근거가 되지는 않습니다. 검토자는 해당 방법과 자료를 이해할 역량이 있어야 하고, 수행자와 분리하고 검토 권한을 정하는 방식으로 자기 검토의 한계를 줄입니다.

#### 수정 이후의 확인

의견을 전달한 것으로 검토가 끝나지는 않습니다. 수정한 결과와 최종 발행본이 일치하는지 확인해야 합니다. 표현을 바꾸는 과정에서 다른 표나 요약문이 그대로 남을 수 있으므로, 중요한 수정은 연결된 부분까지 확인한 뒤 검토를 종결합니다.

#### 정리

정리하면, 기술검토는 문장을 다듬는 일이 아니라 결론을 근거까지 거슬러 확인하는 일입니다. 원시기록으로 뒷받침되지 않는 결과는 발행을 미루고, 수정 이후 최종본의 일치까지 확인합니다.
### 상시감사 경보 운영 (Continuous-Audit Alerts)
#### 경보는 쌓이는 순간 통제가 약해집니다

대시보드에 빨간 숫자가 계속 늘어납니다. 규칙은 정상 작동하고 있지만 담당자가 보지 못한다면 통제는 작동한다고 보기 어렵습니다. 저는 상시감사를 탐지 시스템이 아니라 경보를 처리하는 업무 절차로 봅니다.

누가 경보를 받는지, 얼마 안에 첫 검토를 하는지, 어떤 자료를 추가로 요청하는지, 누구의 판단으로 닫는지가 정해져야 합니다. 책임이 불명확하면 중요한 경보도 단순 알림과 같은 운명을 맞습니다.

#### 오탐은 제거 대상이 아니라 조정 자료입니다

상시감사 초기에는 정상 거래가 많이 걸릴 수 있습니다. 이를 시스템 실패로만 보지 않습니다. 정상으로 판정된 이유를 코드화하면 업무 특성을 배우는 자료가 됩니다. 특정 부서, 거래처, 기간에 예외가 반복된다면 규칙의 기준을 조정할 수 있습니다.

다만 예외 목록을 넓게 제외하는 방식은 조심해야 합니다. 편의를 위해 거래처 전체를 허용 목록에 넣으면 그 안에서 발생하는 새로운 위험을 놓칠 수 있습니다. 제외에는 기간과 승인 근거를 두고 정기적으로 다시 봅니다.

#### 종결 사유가 다음 탐지의 품질을 만듭니다

경보를 '이상 없음'으로 닫는 것만으로는 학습할 수 없습니다. 정기 계약, 긴급 구매, 데이터 오류, 승인 미흡처럼 이유를 구분해야 합니다. 저는 종결 코드와 근거 문서를 함께 남기고, 반복되는 원인을 규정이나 프로세스 개선 항목으로 연결합니다.

상시감사의 품질은 탐지 건수보다 처리되지 않은 경보의 나이, 재발한 원인, 규칙 변경 이력에서 더 잘 드러납니다. 자동화는 판단을 없애는 장치가 아니라 판단이 필요한 곳을 꾸준히 보여 주는 장치입니다.

#### 실무에서 확인할 항목

- 경보별 담당자와 초기 검토 기한

- 추가 확인 자료와 단계별 승인 기준

- 종결 사유 코드와 근거 문서

- 규칙, 제외 조건, 변경 이력의 정기 검토
### 백그라운드 작업의 흔적 (Traces of background tasks)
#### 자리를 비운 뒤에도 생기는 기록

한 조사에서, 업무가 끝난 밤 11시대에 특정 공유 폴더의 파일 수십 개가 연속으로 열린 기록이 나왔습니다. 마침 그 시각 사무실에 남아 있던 직원이 있어, 처음에는 그 사람이 자료를 열람한 것처럼 보였습니다. 그러나 백업이나 색인 생성 프로그램이 파일을 읽었을 가능성도 있습니다.

저는 접근한 시각보다 그 기록을 만든 동작을 먼저 살핍니다. 보안 검사, 미리보기, 동기화도 파일을 처리하며 같은 흔적을 남깁니다. 다만 실제로 어떤 기록이 남는지는 운영체제와 프로그램, 설정에 따라 달라지므로, 한 환경의 경험을 다른 환경에 그대로 대입하지 않습니다.

#### 자동 실행을 판단하는 단서

예약 작업의 설정, 실행 계정, 관련 프로세스와 프로그램 로그를 함께 봅니다.

- 일정한 간격으로 반복되는지, 특정 서비스가 시작될 때 나타나는지 확인합니다.

- 규칙적인 시각만으로 자동 작업이라 확정하지 않습니다. 반복 작업을 사람이 직접 수행했을 수도 있어, 실행 당시의 로그와 설정이 맞물리는지 봅니다.

- 사용자 계정으로 실행되었다는 사실도 직접 조작의 충분한 근거는 아닙니다. 같은 계정으로 예약 작업이 수행될 수 있습니다.

#### 실행과 설정을 나누어 봅니다

자동으로 실행된 작업이라도 누군가 그렇게 설정했을 수 있습니다. 파일 전송이 예약되어 있었다면 실행 방식과 설정 변경의 주체를 별도로 살핍니다. 필요하면 별도 시험 환경에서 동작을 재현하되, 현재 버전에서 재현한 결과를 과거 환경에 그대로 적용하지 않도록 버전과 설정 차이를 확인합니다.

#### 정리

분석 결과는 직접 조작을 뒷받침하는 경우, 자동 작업으로 설명되는 경우, 자료가 부족해 구분하기 어려운 경우로 나뉩니다. 표면 단서인 시각의 규칙성이나 계정 이름으로 사람을 특정하기 전에, 기록을 만든 동작을 먼저 분리하고 실행과 설정을 나눠 보는 것이 핵심입니다.
### 문서의 숨은 개인정보 (Hidden personal data in documents)
#### 가려진 이름이 다시 보이는 이유

한 문서에서 이름 위에 검은 도형을 올려 가린 뒤 그대로 외부에 보냈습니다. 출력 화면에서는 보이지 않았지만, 받는 쪽에서 도형을 옮기거나 텍스트를 복사하자 원래 이름이 그대로 나타났습니다.

숨기기와 제거는 다른 처리입니다. 글자색 변경, 행 숨기기, 시트 숨기기도 원래 데이터를 남겨 둡니다.

#### 본문 밖의 확인 위치

댓글에는 검토 대상자의 이름이, 변경 이력에는 삭제한 문장이 남을 수 있습니다. 작성자 속성, 파일명, 머리말과 바닥글도 살핍니다.

- 스프레드시트에서는 숨김 시트와 메모 외에 내장 개체, 연결 데이터와 캐시도 확인 대상입니다.

- PDF 변환도 제거를 보장하지 않으므로 주석, 첨부파일, 텍스트층이 결과물에 남았는지 확인합니다.

#### 원본과 제공본의 분리

저는 보존이 필요한 원본을 유지하고 외부 제공본을 따로 만듭니다. 필요한 정보만 남긴 뒤 저장하고, 최종 파일을 다시 열어 검사합니다. 화면 보기, 검색, 텍스트 추출, 속성 확인을 함께 활용하되, 한 가지 검사에서 문제가 없다고 모든 잔존 정보를 배제할 수는 없습니다.

#### 발송 직전의 확인

검토한 파일과 실제 첨부할 파일이 같은지 확인합니다. 검토 후 다시 편집하거나 다른 형식으로 변환했다면 그 결과물을 점검해야 합니다. 자료가 민감할수록 작성자와 별도의 검토자가 제공본을 확인하는 방식을 고려합니다. 원본을 잘 정리한 사실보다 외부로 나가는 파일의 상태가 판단 대상입니다.

#### 정리

정리하면, 화면에서 안 보이는 것과 문서에서 사라진 것은 다릅니다. 본문 밖 영역까지 점검하고, 외부로 나가는 최종 파일의 상태를 발송 직전에 다시 확인합니다.
### 외부 협업공간의 자료 잔존 (Residual data in external collaboration spaces)
#### 종료된 프로젝트의 열린 공간

한 프로젝트가 끝났지만 외부 협업 채널은 그대로 남아 있었습니다. 이전 참여자는 여전히 첨부파일을 볼 수 있었고, 새 담당자는 그 공간의 존재조차 모르고 있었습니다.

저는 회사가 관리하는 공간과 상대방이 운영하는 공간부터 구분합니다. 직접 회수할 수 있는 권한과 상대방에게 요청해야 할 조치가 다르기 때문입니다.

#### 보관 버튼의 의미

공간을 보관 상태로 바꾸어도 자료 열람은 가능할 수 있습니다. 보관, 비활성화, 삭제가 실제로 어떤 효과를 내는지 확인해야 합니다. 최종 산출물 외에 초안과 검토 의견, 참고자료도 살피고, 게스트 계정을 제거했더라도 공개 링크나 별도 초대가 남아 있을 수 있습니다.

#### 남겨야 할 자료와 정리할 자료

계약이나 업무상 보존이 필요한 자료는 내부 보관 위치와 책임자를 정해 인계합니다. 외부 보관을 계속해야 한다면 목적과 기간, 접근 대상을 다시 정합니다. 삭제 요청은 공간 이름만 적기보다 대상 자료와 범위를 특정합니다. 상대방이 내려받은 파일이나 백업까지 같은 방식으로 삭제되는 것은 아니므로, 확인 가능한 결과와 확인하지 못한 부분을 나눕니다.

#### 종료 조건의 확인

협업공간을 닫을 때는 자료 인계, 참여자 권한, 공유 링크, 외부 사본의 처리 상태를 함께 확인합니다. 미해결 항목이 있으면 종료 완료와 구분해 관리합니다. 다음 프로젝트부터는 착수 시 공간 소유자와 종료 담당자를 지정해, 마지막 담당자가 기억을 더듬어 공간을 찾는 일을 줄입니다.

#### 정리

정리하면, 프로젝트 종료는 공간을 닫는 것으로 끝나지 않습니다. 회사 관리 공간과 상대 공간을 나눠 자료를 인계하고 정리하며, 확인한 부분과 못 한 부분을 구분해 남깁니다.
### 부적합 작업 관리 (Managing nonconforming work)
#### 뒤늦게 발견한 잘못된 설정

한 작업에서 분석을 마친 뒤에야 설정 오류를 발견했습니다. 다시 처리하면 현재 결과는 고칠 수 있지만, 같은 설정을 사용한 다른 작업이 있었는지는 별도로 확인해야 했습니다.

저는 눈앞의 수정과 영향평가를 나눕니다. 설정 오류가 있다고 모든 결과가 잘못된 것도 아니지만, 발견한 한 건에만 영향이 있다고 가정할 수도 없습니다.

#### 영향 범위의 근거

어떤 기능과 데이터가 영향을 받을 수 있는지 확인합니다. 오류가 시작된 시점, 같은 환경의 사용 범위, 이미 발행한 결과를 살핍니다. 필요한 작업이나 결과의 사용·발행을 제한하되 범위는 근거에 따라 정하고, 영향을 받지 않는다고 판단한 경우에도 그 이유를 남깁니다.

#### 수정과 원인 조치

재수행과 보고서 정정은 현재 문제를 바로잡는 조치입니다. 설정 통제, 절차 변경, 교육은 원인과 재발 가능성을 다루는 조치가 될 수 있습니다. 오류마다 같은 조치를 반복하기보다 왜 기존 점검에서 걸러지지 않았는지 살피고, 교육 부족으로 설명하기 전에 화면 구성이나 승인 절차의 문제도 확인합니다. 고객 통지와 결과 회수 필요성은 영향평가와 적용 절차에 따라 판단합니다.

#### 재개와 후속 확인

업무 재개는 원인이 해소되고 필요한 확인을 마쳤는지에 따라 정해진 권한자가 승인합니다. 재개 승인과 장기적인 재발 방지 효과 확인은 시점이 다를 수 있습니다. 다음 작업에서 바꾼 통제가 실제로 적용되는지 확인하면, 조치가 형식적으로 끝나는 일을 줄일 수 있습니다.

#### 정리

정리하면, 부적합은 눈앞의 결과를 고치는 일과 원인을 다루는 일을 나눠 처리합니다. 영향 범위를 근거로 정하고, 재개 승인과 재발 방지 확인의 시점을 구분합니다.
### 메신저 대화의 맥락 분석 (Reading messenger conversations in context)
#### 짧은 답변이 가리키는 대상

한 조사에서 확보한 메신저 대화에 "그렇게 진행하세요"라는 한 줄이 있었습니다. 앞에서는 일정 변경과 자료 전달을 함께 이야기하고 있었는데, 이 답이 어느 제안에 대한 것인지에 따라 승인의 범위가 달라졌습니다.

메시지를 내보내거나 분석 도구로 표시하는 과정에서 답장 연결이 생략되면, 실제 대화에서는 분명했던 관계가 모호해집니다. 저는 문장과 함께 답장 대상, 인용 내용, 앞뒤 발언을 확인합니다.

#### 참여자 목록의 시간 차이

지금 대화방에 있는 사람이 과거에도 참여했다고 볼 수 없고, 반대로 나간 사람도 참여 당시 자료를 보유하고 있을 수 있습니다. 그래서 다음을 구분합니다.

- 초대·퇴장 시점, 과거 대화의 표시 방식, 확보한 데이터의 범위.

- 읽음 상태의 서비스별 의미. 화면에 표시된 상태만으로 내용을 이해했거나 동의했다고 판단하기는 어렵습니다.

#### 파일명보다 버전

같은 이름의 파일이 여러 번 올라왔다면 "수정했습니다"가 어느 파일을 가리키는지 확인합니다. 파일명만 같고 내용은 다를 수 있습니다. 첨부의 실제 내용, 전달 시점, 뒤따르는 답변을 연결하면 어떤 자료를 전제로 의견이 오갔는지 살필 수 있습니다. 연결할 파일이 없으면 그 부분의 해석은 제한됩니다.

#### 발췌할 때 남겨야 할 맥락

보고서에 모든 대화를 옮길 필요는 없습니다. 다만 판단에 영향을 주는 조건과 반대 의견, 답장 관계는 발췌 과정에서 빠지지 않아야 합니다. 메시지에는 발언자의 주장도 담기므로, 누군가 "승인을 받았다"고 말한 사실과 실제 승인이 존재하는지는 별개의 확인 항목입니다.

#### 정리

정리하면, 메신저 기록은 화면에 보이는 것만으로 판단하지 않습니다. 답장 대상과 참여 시점, 첨부 버전을 연결해 맥락을 복원하고, 발언 속 주장과 실제 확인 사실을 끝까지 구분합니다.
### 감사 데이터의 완전성 (Completeness of audit data)
#### 합계는 맞는데 거래가 다릅니다

한 감사에서 분석 파일의 합계가 원장과 정확히 일치했습니다. 그래서 자료가 온전하다고 넘어갈 뻔했는데, 확인해 보니 같은 금액의 거래 하나가 빠지고 다른 거래가 중복되어 있었습니다. 합계만으로는 이 차이를 알 수 없었습니다.

완전성은 데이터가 많다는 뜻이 아니라, 정해진 범위의 자료가 빠짐없이 포함되어 있는지를 말합니다. 무엇을 포함해야 하는지 먼저 정해야 확인할 수 있습니다.

#### 추출 조건이 모집단을 바꿉니다

거래일, 전표일, 지급일 중 어떤 날짜를 기준으로 삼았는지에 따라 같은 기간의 자료도 달라집니다. 취소·보류 거래를 제외했는지, 특정 법인이나 부서만 추출했는지도 영향을 줍니다. 저는 자료를 받으면 파일명보다 추출 조건을 먼저 확인하고, 화면 조회 권한 때문에 일부 거래만 내려받은 경우도 검토합니다.

#### 연결 과정에서 생기는 손실

거래 원장에 직원 정보를 연결할 때 식별값이 없는 거래는 빠지고, 한 직원에게 여러 행이 연결되면 거래가 중복될 수 있습니다.

- 원천 자료, 추출본, 가공본의 건수와 금액을 단계별로 대조하고 차이가 생긴 지점을 확인합니다.

- 거래 식별번호의 중복·빈값, 기간별 분포를 함께 살핍니다.

#### 분석 결과의 전제

제외된 거래가 있으면 사유와 규모를 파악해 정상적인 범위 제외인지 자료 확보 실패인지 구분합니다. 완전성이 확인되지 않은 상태에서 이상거래가 적게 나왔다고 위험이 낮다고 해석하기는 어렵습니다. 결과를 보고할 때는 탐지 내용과 함께 어떤 모집단을 대상으로 했는지 제시합니다.

#### 정리

정리하면, 완전성은 합계가 아니라 정해진 모집단이 빠짐없이 담겼는지로 판단합니다. 추출 조건과 연결 과정을 먼저 검증하고, 어떤 모집단을 봤는지와 함께 결과를 보고합니다.
### 개인정보 열람 요구 대응 (Responding to a data subject access request)
#### 한 사람의 정보가 여러 곳에 있습니다

한 고객이 자신의 개인정보 열람을 요청했습니다. 정보를 찾아보니 고객관리 시스템뿐 아니라 상담 메일과 그 첨부파일에도 흩어져 있었습니다.

저는 요청을 접수하면 본인 또는 정당한 대리인인지 확인하고 요청 범위를 정리합니다. 확인을 이유로 불필요한 신분정보를 더 수집하지 않는 방법도 검토합니다. 열람권과 제한·거절 사유는 개인정보 보호법 제35조에 따라 판단합니다.

#### 검색 범위를 정하는 기준

이름 하나만 검색하면 동명이인의 정보가 섞이거나 변경 전 계정의 자료가 빠질 수 있습니다. 업무상 식별값과 관련 저장 위치를 확인합니다. 요청이 불명확하면 필요한 범위를 안내하되, 범위 협의 때문에 법정 처리 기한 관리가 빠지지 않도록 합니다. 담당 부서가 여러 곳이어도 접수 창구에서 전체 진행 상태를 관리합니다.

#### 문서 전체와 자신의 개인정보

개인정보 열람 요구가 모든 내부 문서의 원본 전체를 받을 권리와 같지는 않습니다. 반대로 내부 문서라는 이유만으로 일괄 제외할 수도 없습니다. 찾은 자료에서 요청자의 개인정보와 다른 사람의 정보를 구분하고, 가림이나 분리 제공 가능성을 살핍니다. 제한이 필요하면 구체적인 법적 사유를 검토합니다.

#### 제공과 설명

잘못된 사람에게 자료를 보내면 열람 대응 자체가 새로운 노출이 됩니다. 수신자와 전달 경로를 확인하고 필요한 보호 조치를 적용합니다. 회신에는 제공한 범위와 제한한 부분의 이유가 드러나야 하고, 자료를 찾지 못했다면 어디까지 확인했는지 내부적으로 설명할 수 있어야 합니다. 요청을 받았다는 기록과 실제 처리 결과를 연결해 관리합니다.

#### 정리

정리하면, 열람 대응은 자료를 찾는 일과 제공 범위를 판단하는 일을 함께 다룹니다. 검색 범위와 타인 정보를 신중히 가리고, 처리 결과를 근거와 함께 기록으로 남깁니다.
### 유출 의심 단계의 초기 대응 (First response to a suspected leak)
#### 아직 유출인지 모르는 상태

한 조직에서 대량 다운로드 경보가 발생했습니다. 정상적인 자료 이관인지 외부 반출인지 바로 구분되지 않는 상태였고, 무엇부터 해야 할지가 첫 판단이었습니다.

이 단계에서는 조사 범위를 무작정 넓히기보다 관찰된 사실과 현재 진행 중인 위험을 먼저 정리합니다. 누가 의심했는지보다 어떤 기록과 상태가 의심의 근거인지가 중요합니다.

#### 먼저 결정할 두 가지

저는 추가 노출이 계속될 가능성과, 조치로 사라질 수 있는 기록을 함께 봅니다.

- 외부 공유가 계속 열려 있다면 접근 제한이 시급할 수 있습니다.

- 반면 장비 초기화처럼 상태를 크게 바꾸는 조치는 필요한 자료를 잃게 할 수 있습니다.

모든 상황에서 같은 순서로 처리하기는 어려우므로, 차단과 기록 확보를 병행할 수 있는지 검토하고 수행한 조치와 시각을 남깁니다.

#### 조사로 넘어가는 기준

경보의 원천, 관련 계정, 데이터 종류, 알려진 업무 사유를 확인합니다. 승인된 이관으로 설명되고 기록도 일치하는지, 설명과 기록에 차이가 있는지 살핍니다. 이 단계의 판단은 유출 확정, 정상 업무 설명, 추가 조사 필요로 나눌 수 있으며, 조직 내부의 상태 분류가 법적 통지·신고 의무의 판단을 대신하지는 않습니다.

#### 초기 보고의 내용

보고에는 확인 사실, 미확인 사항, 수행 조치, 다음 확인 항목을 담습니다. 추정한 유출량과 확정된 범위를 섞지 않습니다. 정상 업무로 판단해 조사를 마친 경우에도 그 설명과 근거를 남기고, 추가 조사로 넘어간다면 확인할 질문과 대상 범위, 책임자를 정해 전달합니다.

#### 정리

정리하면, 초기 대응은 조사 착수 여부를 가르는 단계입니다. 노출 제한과 자료 보존의 우선순위를 함께 정하고, 확인된 사실과 추정을 섞지 않은 채 다음 확인 항목으로 넘깁니다.
### NIST AI 위험관리 프레임워크 (The NIST AI Risk Management Framework)
#### AI 사용 규정에 남은 빈칸

한 조직의 사내 규정에 "AI 결과를 검토한 뒤 사용한다"고 적혀 있었습니다. 그런데 누가 어떤 부분을 확인해야 하는지는 정해져 있지 않아, 실제로는 저마다 다르게 쓰고 있었습니다.

저는 이런 문장을 업무별 질문으로 바꿉니다. 회의록의 사실관계를 확인하는 것과 고객에게 보낼 안내문을 승인하는 것은 검토 대상이 다릅니다. 같은 도구를 쓰더라도 결과의 사용처에 따라 위험이 달라지기 때문입니다.

#### 문서의 역할

NIST AI RMF 1.0은 2023년 1월 발표된 자율적 위험관리 프레임워크로, AI를 개발하는 조직뿐 아니라 도입하고 사용하는 조직도 활용할 수 있습니다. NIST AI 600-1은 2024년 7월 발표된 생성형 AI 프로파일로, 사실과 다른 내용의 생성, 개인정보, 정보보안, 지식재산, 사람의 과도한 의존 같은 위험을 구체적으로 살펴보도록 돕습니다. 자세한 내용은 NIST 공식 안내를 참고하고, 적용할 때는 사용한 판본을 기록하고 개정 상태를 확인합니다.

#### 네 가지 기능의 실무 적용

AI RMF의 핵심 기능은 GOVERN, MAP, MEASURE, MANAGE입니다. 다음은 이를 업무에 적용한 예시입니다.

기능정할 내용실무 예시
GOVERN책임과 승인 기준업무 소유자, 검토자, 예외 승인자 지정
MAP사용 목적과 영향입력 자료, 이용자, 결과 사용처 정리
MEASURE평가 방법과 한계대표 자료로 오류·누락·위험한 출력 확인
MANAGE대응과 재검토사용 제한, 수정, 중지·재개 조건 설정

이 기능들은 한 번씩 거치는 절차가 아닙니다. 모델이나 업무가 바뀌면 평가와 대응을 다시 검토하며, 책임과 관리 기준은 전 과정에 적용됩니다.

#### 검토의 수준을 정합니다

문장 교정용 AI와 조사 대상 자료를 분류하는 AI에 같은 평가 기준을 적용하기는 어렵습니다. 조사 자료 분류라면 찾아낸 문서만 아니라 누락 가능성도 살펴야 하고, 고객 안내라면 사실관계와 적용 조건, 외부 발송 승인을 확인합니다. 사람의 권익에 영향을 주는 용도라면 별도의 법적·업무적 검토가 필요합니다. 저는 도입 전에 허용할 사용 범위와 허용하기 어려운 오류를 정하는 편이 좋다고 봅니다. 결과를 본 뒤 기준을 바꾸면 평가가 도입 결정을 정당화하는 절차로 흐를 수 있습니다.

#### 컴플라이언스와의 구분

AI RMF를 적용했다는 사실만으로 법령과 계약을 모두 준수했다고 볼 수는 없습니다. 해당 의무를 따로 확인하고 관리 활동과 연결해야 합니다. 프레임워크 자체는 인증서나 법적 면책을 제공하는 제도가 아니므로, "NIST 기준 적용"이라고 설명하려면 어느 업무에 어떤 항목을 적용했는지 범위가 드러나야 합니다.

#### 필요한 지식과 운영 기록

사용자는 입력 가능한 자료와 원문 대조가 필요한 결과를 알아야 하고, 관리자는 보관 조건과 접근권한을, 감사 담당자는 승인·검토·오류 처리의 실제 이행을 살펴야 합니다. 교육에서도 매끄러운 요약에서 빠진 조건을 스스로 찾아보는 등 자신의 업무에 맞는 연습이 필요합니다. 기록에는 사용 목적, 승인된 환경, 평가 결과, 남은 제한을 담되 입력 자료 전체를 무조건 보관하기보다 필요한 근거와 보존 범위를 정합니다. 이후 오류가 발생했을 때 모델, 업무 방식, 검토 기준 중 무엇을 바꿀지 판단할 수 있는 수준이 기준입니다.

#### 정리

정리하면, AI 위험관리는 도구가 아니라 사용처별 책임과 검토 수준을 정하는 일입니다. GOVERN·MAP·MEASURE·MANAGE를 업무에 맞춰 반복 적용하고, 적용 범위와 근거를 기록으로 남깁니다. 프레임워크를 적용했다는 사실이 곧 법령 준수나 면책을 뜻하지는 않는다는 점도 함께 기억합니다.
### 포렌식 보고서의 해석 범위 (How far a forensic report actually speaks)
#### 미발견을 읽는 순서

한 사안에서 받은 포렌식 보고서에 "외부 전송 흔적이 발견되지 않았다"고 적혀 있었습니다. 이 한 문장을 근거로 유출이 없었다고 결론지으려는 움직임이 있었지만, 같은 결과도 분석 범위에 따라 뜻이 달라집니다.

대상 PC만 확인했는지, 메일과 클라우드 기록도 포함했는지, 필요한 기간의 로그가 남아 있었는지 먼저 봅니다. 확인할 기록이 없는 상태와, 충분한 자료를 검토했지만 흔적을 찾지 못한 상태는 구분해야 합니다.

#### 보고서의 세 층위

저는 결과를 읽을 때 다음을 나누어 봅니다.

- 관찰 사실: 확보한 자료에서 직접 확인한 값이나 기록.

- 분석 의견: 여러 기록과 동작 원리를 바탕으로 해석한 내용.

- 확인 한계: 자료나 방법의 제약으로 판단하지 못한 부분.

"가능성이 높다"는 표현이 있으면 무엇을 근거로 한 것인지 살피고, 수치 평가를 하지 않았다면 통계적 확률처럼 받아들이지 않습니다.

#### 기술적 결과와 조직의 결정

파일 이동이 확인되어도 승인된 업무였는지는 추가 검토가 필요하며, 징계나 법적 책임은 규정·권한·경위와 함께 판단합니다. 저장매체 연결, 파일 접근, 복사, 외부 전달은 각각 다른 행위라, 앞 단계 기록이 있다는 이유로 뒤 단계까지 확인된 것으로 읽지 않습니다.

#### 추가 분석을 요청할 때

"더 자세히 분석해 달라"는 요청보다 남은 질문을 구체적으로 적는 편이 낫습니다. 어떤 파일의 이동인지, 어느 기간인지, 어떤 경로를 추가 확인하려는지 정하는 것입니다. 필요한 자료가 남아 있지 않으면 범위를 늘려도 답을 얻기 어렵습니다. 보고서의 제한은 추가 작업의 필요성뿐 아니라 가능성을 판단하는 기준이 됩니다.

#### 정리

정리하면, 보고서의 결론은 분석 범위 안에서만 유효합니다. 미발견이 무엇을 뜻하는지 먼저 확인하고, 관찰 사실과 의견과 한계를 나눠 읽어야 후속 결정을 그르치지 않습니다.
### 제보 내용의 검증 (Verifying a whistleblower report)
#### 구체적인 설명의 출처

한 제보에 업무 과정과 의심 사유가 매우 자세히 적혀 있었습니다. 읽다 보면 설명이 구체적일수록 사실도 정확한 것처럼 느껴집니다. 그러나 구체성과 정확성은 다른 문제입니다.

저는 각 문장을 직접 본 내용인지, 다른 사람에게 들은 말인지, 상황을 보고 추측한 것인지 나눕니다. 여러 사람이 같은 이야기를 했더라도 최초 출처가 하나라면 독립된 근거가 여럿이라고 보기 어렵습니다.

#### 평가 표현을 확인 항목으로

"특정 거래처를 밀어준다"는 표현만으로는 검증 범위가 정해지지 않습니다. 선정 기준, 비교 견적, 예외 승인, 가격과 납품 조건처럼 자료로 확인할 항목으로 나눕니다. 주장을 뒷받침할 자료와 정상적인 업무로 설명할 자료를 함께 찾고, 질문도 "누가 지시했습니까"처럼 행위가 있었다는 전제로 시작하지 않도록 구성합니다.

#### 신원과 내용의 분리

익명이라는 이유만으로 제보를 배제하지 않습니다. 신원을 알 수 없어도 확인 가능한 문서나 거래가 있을 수 있습니다. 반대로 실명 제보라고 내용이 자동으로 검증되는 것도 아닙니다. 제보자의 관계와 동기는 참고하되 주장별 근거를 따로 살피고, 제보 내용을 공유할 때는 표현과 세부 정황만으로 제보자가 드러날 수 있어 원문 전체가 필요한지 검토합니다.

#### 결과의 표현

확인된 내용, 다른 자료로 설명된 내용, 자료 부족으로 판단하지 못한 내용을 구분합니다. 입증되지 않았다는 이유만으로 허위 제보라고 표현하지 않습니다. 후속 조사로 넘어갈 때는 제보자의 평가 문구보다 확인할 쟁점과 확보할 자료를 전달합니다.

#### 정리

정리하면, 제보는 구체성이 아니라 확인 가능한 근거로 검증합니다. 관찰과 전언과 추측을 나누고, 신원과 내용을 분리해 쟁점별로 확인한 뒤 그 수준을 그대로 표현합니다.
### 감사 지적사항의 이행점검 (Following up on audit findings)
#### 바뀐 규정과 그대로인 화면

한 지적사항의 조치 결과에 "규정 개정 완료"라고 적혀 있었습니다. 문서는 분명히 바뀌었는데, 시스템에서는 이전 승인 경로가 그대로 살아 있어 실제로는 예전 방식으로 처리되고 있었습니다.

이행점검은 제출 자료의 존재를 확인하는 데서 끝나지 않습니다. 지적한 원인과 조치가 연결되는지, 그 조치가 실제 업무에서 적용되는지를 살펴야 합니다.

#### 종결 기준부터 합의합니다

저는 개선안을 정할 때 완료 기준도 함께 적습니다. 책임자와 기한 외에 어떤 상태가 되어야 종결할 수 있는지 정하는 것입니다. 승인 누락이 문제였다면 규정 개정뿐 아니라 승인 없이 처리되는 경로가 남아 있는지 확인하고, 예외 처리가 필요하면 누가 승인하고 어떻게 추적할지도 포함합니다.

#### 설계와 운영의 구분

기능이 구현된 사실과 일정 기간 적절하게 운영된 사실은 다릅니다. 실제 거래가 있으면 변경 이후의 처리 과정을 확인하고, 발생 빈도가 낮아 운영 사례가 없으면 설정 검토나 시험으로 확인한 범위를 표시합니다. 아직 관찰하지 못한 운영 효과까지 검증 완료로 적지 않습니다.

#### 미완료와 위험 수용

조치가 지연되면 사유, 임시 대응, 새 기한을 정합니다. 권한 있는 사람이 남은 위험을 수용한 경우에도 개선 완료와 같은 상태로 표시하지 않는 편이 명확합니다. 같은 문제가 재발하면 미이행인지, 조치 설계가 부족했는지, 다른 경로에서 발생했는지 구분합니다. 이행점검의 종결은 원래 약속한 조치와 확인 기준을 충족했는지로 판단합니다.

#### 정리

정리하면, 이행점검은 자료가 제출됐는지가 아니라 문제가 실제로 줄었는지를 봅니다. 종결 기준을 미리 합의하고, 설계와 운영을 나눠 확인해야 조치가 형식에 그치지 않습니다.