새로운 솔루션이나 시스템을 도입할 때 제품의 기능과 가격만 확인하고 넘어가면 실제 운영 단계에서 보안 문제가 발생할 수 있습니다. 실무에서는 도입 전에 데이터 흐름과 접근권한, 네트워크 구성, 암호화, 로그, 취약점 등을 함께 확인해야 합니다. 이 글에서는 신규 시스템 도입 시 보안성 검토를 어떤 순서로 진행하고 어떤 자료를 참고하면 되는지 실무 관점에서 정리합니다.
보안성 검토는 제품 자체만 보는 작업이 아닙니다.
무슨 데이터를 처리하는지 → 어디로 전송되는지 → 누가 접근하는지 → 어떻게 보호하는지를 순서대로 확인하면 됩니다.
보안성 검토란 무엇인가
보안성 검토는 신규 시스템이나 솔루션을 도입하기 전에 해당 시스템에서 발생할 수 있는 보안 위험을 확인하고 필요한 보호조치를 마련하는 과정입니다.
예를 들어 사내에 새로운 SaaS 서비스를 도입한다고 가정해보겠습니다. 단순히 해당 서비스에 보안 기능이 있는지만 확인해서는 부족합니다.
- 회사 내부 정보가 외부 서비스로 전송되는가?
- 개인정보나 금융정보가 포함되는가?
- 관리자 계정은 어떻게 관리되는가?
- 외부에서 관리자 페이지에 접근할 수 있는가?
- 데이터는 어느 국가 또는 어느 리전에 저장되는가?
- 접속기록과 관리자 행위가 로그로 남는가?
- 장애나 침해사고가 발생했을 때 어떻게 대응하는가?
이런 질문에 답하면서 위험을 찾아내는 것이 기본적인 보안성 검토입니다.
실무에서 보면 제품 설명서만 가지고 검토를 시작하면 시간이 상당히 오래 걸립니다. 먼저 시스템의 전체 구조와 데이터 흐름을 파악한 다음 세부 보안 항목으로 내려가는 방식이 효율적입니다.
보안성 검토의 기본 흐름
- 도입 목적과 시스템 개요 확인
- 처리 데이터와 중요도 확인
- 데이터 흐름과 연계 시스템 확인
- 네트워크 및 접속 구조 확인
- 계정과 권한 관리 확인
- 암호화 및 키 관리 확인
- 취약점 및 보안 설정 확인
- 로그 및 모니터링 확인
- 백업과 장애 대응 확인
- 미흡사항에 대한 조치계획 작성
- 조치 결과 확인 후 도입 승인
이 부분이 핵심입니다. 보안성 검토 결과가 단순한 체크리스트로 끝나면 안 되고, 발견된 위험과 조치 결과까지 추적할 수 있어야 합니다.
신규 시스템 도입 시 실제 검토 방법
처음 검토를 맡았다면 바로 취약점 항목부터 확인하지 않는 것이 좋습니다. 먼저 담당 부서에 시스템 구성과 데이터 흐름을 요청하는 것이 시작입니다.
1. 도입 정보부터 받기
최소한 다음 자료를 요청합니다.
- 제품명 및 버전
- 도입 목적
- 제품 구성도
- 네트워크 구성도
- 데이터 흐름도
- 서버 및 DB 구성정보
- 연계 시스템 목록
- 사용자 및 관리자 계정 목록
- 처리하는 정보의 종류
- 외부업체 유지보수 여부
- 클라우드 또는 SaaS 사용 여부
- 보안기능 및 제품 보안설정 자료
여기서 담당자가 “그냥 사내 업무용 프로그램입니다”라고 설명하더라도 실제 데이터 흐름을 확인해야 합니다.
혹시 시스템에서 개인정보를 입력받거나 기존 DB와 연동한다면 이야기가 달라집니다. 단순한 업무 프로그램이 아니라 중요정보를 처리하는 시스템이 될 수 있기 때문입니다.
2. 데이터부터 확인하기
보안성 검토에서 가장 먼저 확인할 항목 중 하나가 데이터입니다.
| 확인 항목 | 검토 내용 | 확인 자료 |
|---|---|---|
| 개인정보 | 이름, 연락처, 계정정보 등 처리 여부 | 데이터 항목 목록 |
| 민감정보 | 민감한 업무정보 포함 여부 | 데이터 정의서 |
| 금융정보 | 계좌, 거래, 고객 관련 정보 처리 여부 | 업무 흐름도 |
| 인증정보 | 비밀번호, 인증서, 토큰 등의 저장 여부 | 시스템 설계서 |
| 로그정보 | 접속기록 및 관리자 행위 기록 여부 | 로그 설계서 |
데이터를 확인한 뒤에는 반드시 저장 위치와 전송 경로까지 확인합니다.
예를 들어 “고객정보를 처리하지 않습니다”라는 답변을 받았더라도 API 호출 과정에서 고객 식별자나 계정정보가 외부 서버로 전송될 수 있습니다.
3. 네트워크 구성 확인하기
네트워크 검토에서는 시스템이 어디에 위치하고 어떤 구간을 통해 통신하는지를 확인합니다.
- 인터넷에서 직접 접근 가능한지 확인합니다.
- 내부망과 외부망의 통신 경로를 확인합니다.
- 방화벽 정책과 허용 포트를 확인합니다.
- 서버 간 통신 방향을 확인합니다.
- 관리자 접속 경로를 확인합니다.
- VPN이나 별도의 접근통제가 필요한지 확인합니다.
- 외부 유지보수 업체가 접속할 수 있는지 확인합니다.
네트워크 구성도에서 서버 하나만 확인하고 끝내면 안 됩니다. 실제 운영환경에서는 API 서버, WAS, DB, 인증서버, 로그 서버, 백업 시스템 등이 서로 연결되어 있기 때문입니다.
4. 계정과 권한 확인하기
계정 관리는 실제 운영에서 사고가 발생하기 쉬운 영역입니다.
- 관리자 계정과 일반 사용자 계정을 분리합니다.
- 공용 계정 사용 여부를 확인합니다.
- 최소권한 원칙이 적용되는지 확인합니다.
- 퇴직자 및 전보자의 계정이 즉시 회수되는지 확인합니다.
- 관리자 권한 부여 및 변경 절차를 확인합니다.
- 다중인증 적용 가능 여부를 확인합니다.
- 비밀번호 정책을 확인합니다.
- 관리자 접속기록을 남기는지 확인합니다.
특히 외부 업체의 유지보수 계정은 별도로 확인하는 것이 좋습니다.
“업체에서 접속해야 하니까 계정을 하나 만들어주세요”라는 요청이 들어오면 계정 하나를 만들어주는 것으로 끝내지 말고, 접속시간 제한과 권한 제한, 접속기록, 승인 절차까지 함께 검토해야 합니다.
보안성 검토 체크리스트
아래 항목을 엑셀이나 내부 검토 양식으로 옮겨서 사용하는 방법이 편합니다.
| 분야 | 체크 항목 | 검토 결과 |
|---|---|---|
| 시스템 | 시스템 구성도와 실제 구축환경이 일치하는가 | 적합 / 미흡 |
| 데이터 | 처리 데이터와 중요정보 종류가 식별되어 있는가 | 적합 / 미흡 |
| 데이터 | 데이터 저장 위치와 보관기간이 확인되는가 | 적합 / 미흡 |
| 네트워크 | 필요한 통신 포트만 허용되어 있는가 | 적합 / 미흡 |
| 네트워크 | 외부 접속 경로가 통제되는가 | 적합 / 미흡 |
| 접근통제 | 관리자와 일반 사용자 권한이 분리되어 있는가 | 적합 / 미흡 |
| 접근통제 | 최소권한 원칙이 적용되는가 | 적합 / 미흡 |
| 인증 | 비밀번호 정책 또는 다중인증이 적용되는가 | 적합 / 미흡 |
| 암호화 | 중요정보 전송구간이 암호화되는가 | 적합 / 미흡 |
| 암호화 | 중요정보 저장 시 암호화가 적용되는가 | 적합 / 미흡 |
| 로그 | 로그인 및 관리자 행위가 기록되는가 | 적합 / 미흡 |
| 로그 | 로그 위변조 방지와 보관정책이 존재하는가 | 적합 / 미흡 |
| 취약점 | 최신 보안패치가 적용되는가 | 적합 / 미흡 |
| 취약점 | 취약점 점검 또는 진단이 수행되었는가 | 적합 / 미흡 |
| 백업 | 중요 데이터의 백업 및 복구 절차가 존재하는가 | 적합 / 미흡 |
| 외부업체 | 유지보수 업체의 접근권한이 통제되는가 | 적합 / 미흡 |
| 사고대응 | 침해사고 발생 시 대응 및 연락체계가 마련되어 있는가 | 적합 / 미흡 |
검토 결과는 단순히 “적합” 또는 “미흡”으로 끝내지 않는 것이 좋습니다.
미흡사항 → 위험도 → 개선방안 → 담당자 → 조치기한 → 조치결과까지 관리하면 실제 보안성 검토 문서로 활용하기 좋습니다.
실무 팁: 검토표에 “근거자료” 항목을 하나 더 만들어두세요.
예를 들어 “TLS 적용”이라고 적는 대신 설정 화면, 구성파일, 제품 보안문서 등 실제 확인 근거를 연결해두면 나중에 재검토하기 훨씬 편합니다.
보안성 검토 자료는 어디서 찾을까
보안성 검토를 할 때 인터넷에서 무작정 검색하기보다 법령 → 감독규정 → 기관 가이드 → 취약점 평가기준 → 제품 보안자료 순서로 자료를 찾는 편이 좋습니다.
금융회사라면 금융보안원을 먼저 확인
금융권에서 근무한다면 금융보안원 자료를 우선적으로 확인하는 습관을 들이는 것이 좋습니다. 금융보안원은 보안성 검토 관련 업무를 별도로 운영하고 있으며 금융권의 취약점 분석·평가 기준과 각종 보안 가이드를 제공합니다.
금융보안원의 금융보안 레그테크 포털에서는 금융보안 관련 규제와 가이드를 검색할 수 있습니다. 규정이 변경되는 경우도 있기 때문에 오래된 블로그 글 하나만 보고 판단하기보다는 최신 규정과 가이드를 다시 확인하는 것이 좋습니다.
ISMS-P 자료도 체크리스트 작성에 활용
정보보호 관리체계(ISMS)와 개인정보보호 관리체계(ISMS-P)의 인증기준은 접근통제, 보호대책, 개인정보 보호 등 보안관리 항목을 체계적으로 확인할 때 참고하기 좋습니다. KISA의 인증 관련 자료에서도 인증기준과 세부 점검항목을 확인할 수 있습니다.
다만 ISMS-P 체크리스트를 그대로 신규 시스템 도입 심사표로 사용하는 것은 적절하지 않을 수 있습니다. ISMS-P는 조직의 정보보호 및 개인정보보호 관리체계를 평가하는 목적이 있기 때문입니다.
실무에서는 ISMS-P 항목을 참고해서 조직의 내부 보안성 검토 체크리스트를 만드는 방식이 더 적합합니다.
금융 관련 규정은 반드시 최신본 확인
금융권에서는 전자금융 관련 법령과 감독규정, 시행세칙 등도 함께 확인해야 합니다.
특히 클라우드나 SaaS처럼 외부 서비스를 사용하는 경우에는 현재 적용되는 망분리 및 클라우드 관련 규정을 별도로 확인해야 합니다. 금융위원회는 2026년에도 금융회사의 SaaS 활용과 관련한 전자금융감독규정시행세칙 개정 내용을 발표한 바 있으므로, 과거 자료만 보고 현재 기준을 판단해서는 안 됩니다.
제품 자체 자료도 요청하기
법령과 가이드만으로는 특정 솔루션의 실제 설정을 확인할 수 없습니다.
따라서 업체에 다음 자료를 요청하는 것이 좋습니다.
- 제품 보안기능 설명서
- 제품 구성도
- 데이터 흐름도
- 지원 암호화 방식
- 인증 및 권한관리 기능
- 로그 관리 기능
- 취약점 조치 내역
- 보안취약점 점검 결과
- 침해사고 대응 절차
- 개인정보 처리 관련 자료
- 클라우드 사용 시 데이터 저장 위치
- 외부 유지보수 접근 방식
제품 설명서에 “보안이 강화되어 있습니다”라고 적혀 있는 것보다 실제로 어떤 설정이 가능하고 어떤 로그가 남는지를 확인하는 것이 훨씬 중요합니다.
미흡사항이 발견됐을 때 처리하는 방법
보안성 검토에서 모든 항목을 100% 만족시키기는 현실적으로 어렵습니다. 중요한 것은 미흡사항을 발견했을 때 그냥 승인하거나 무조건 도입을 막는 것이 아닙니다.
위험도를 판단하고 적절한 보완책을 정해야 합니다.
| 위험도 | 예시 | 대응 방식 |
|---|---|---|
| 높음 | 중요정보 외부 평문 전송 | 도입 전 조치 |
| 높음 | 관리자 계정 무제한 외부접속 | 접근통제 후 진행 |
| 중간 | 일부 로그 항목 부족 | 보완계획 및 기한 설정 |
| 낮음 | 운영 편의성 관련 설정 미흡 | 운영계획에 반영 |
여기서 중요한 것은 위험도를 결정하는 기준입니다.
단순히 “보안상 위험함”이라고 적는 것보다 정보의 중요도 × 노출 가능성 × 영향도 × 기존 통제수단을 함께 고려하면 판단 근거를 설명하기 쉬워집니다.
예를 들어 관리자 페이지가 외부에 노출되어 있더라도 VPN, MFA, IP 제한, 관리자 접근 로그가 모두 적용되어 있다면 위험 수준은 달라질 수 있습니다.
실무 팁: 미흡사항을 발견했다면 “안 됩니다”로 끝내지 말고 “현재 위험은 무엇이고, 어떤 통제로 낮출 수 있는가”를 같이 제시하세요.
보안팀과 현업 사이에서 가장 많이 필요한 것이 바로 이 부분입니다.
보안성 검토에서 자주 하는 실수와 오해
오해 1. 보안성 검토는 취약점 점검과 같은 작업이다
그렇지 않습니다.
취약점 점검은 시스템의 취약한 설정이나 알려진 취약점 등을 확인하는 활동이고, 보안성 검토는 시스템 도입 과정에서 발생할 수 있는 보안 위험을 폭넓게 검토하는 활동입니다.
따라서 보안성 검토 과정에서 취약점 점검 결과를 활용할 수 있지만 두 업무를 완전히 같은 것으로 보면 안 됩니다.
오해 2. 보안 솔루션을 도입하면 보안성 검토가 필요 없다
보안 솔루션 역시 하나의 시스템입니다.
DLP, NAC, DRM, WAF, IPS, DB 접근통제 같은 보안제품도 관리자 계정과 네트워크 연결, 로그, 데이터 처리, 유지보수 접속 등이 발생합니다.
보안제품이라고 해서 자동으로 안전하다고 가정하면 안 됩니다.
오해 3. 체크리스트에 전부 체크하면 검토가 끝난다
체크리스트는 검토를 빠뜨리지 않기 위한 도구입니다.
실제 보안성 검토에서는 시스템의 특성에 따라 위험도가 달라지기 때문에 체크 결과에 대한 근거와 위험 판단이 함께 필요합니다.
특히 금융권처럼 규제와 내부통제가 중요한 환경에서는 “무엇을 확인했는가”뿐 아니라 “왜 그렇게 판단했는가”를 설명할 수 있어야 합니다.
그렇다면 실제로 새로운 솔루션을 하나 도입한다고 가정해볼까요?
가장 먼저 시스템 구성도와 데이터 흐름도부터 받아보는 것이 좋습니다.
그다음 데이터, 네트워크, 접근통제, 암호화, 로그, 취약점, 백업, 외부업체 접근 순서로 확인하면 검토 범위를 놓치기 어렵습니다.
오늘 실제 업무에서 보안성 검토를 맡게 된다면, 기존 회사의 검토 양식이 있는지부터 확인하고 그 양식에 법령과 최신 가이드의 요구사항을 추가하는 방식으로 시작하는 것이 현실적입니다.
오늘 바로 사용할 수 있는 보안성 검토 순서
- 현업 담당자에게 시스템 구성도와 데이터 흐름도를 요청합니다.
- 처리하는 개인정보 및 중요정보를 목록화합니다.
- 내부망, 외부망, 인터넷 및 클라우드 연결구간을 표시합니다.
- 사용자와 관리자 계정을 구분합니다.
- 관리자 외부접속 방식을 확인합니다.
- 저장 및 전송 데이터의 암호화 여부를 확인합니다.
- 로그 생성과 보관 방법을 확인합니다.
- 취약점 점검 및 패치 방법을 확인합니다.
- 외부 유지보수 업체의 접근방법을 확인합니다.
- 백업과 장애복구 방법을 확인합니다.
- 미흡사항에 위험도와 조치기한을 지정합니다.
- 조치 완료 후 증빙자료를 확인하고 최종 검토합니다.
이 정도의 흐름을 익혀두면 면접에서 “보안성 검토를 어떻게 하겠습니까?”라는 질문을 받았을 때도 단순히 보안 항목을 나열하지 않고 실제 업무 프로세스처럼 설명할 수 있습니다.
특히 금융권 면접에서는 “규정 확인 → 시스템 및 데이터 파악 → 위험 식별 → 보완대책 → 조치 확인 → 승인 및 사후관리”라는 흐름으로 설명하면 자신의 실무 경험과 연결하기 좋습니다.
오늘 바로 해볼 수 있는 한 가지
엑셀 파일을 하나 만들고 분야 / 점검항목 / 확인자료 / 결과 / 위험도 / 조치방안 / 담당자 / 조치기한 / 조치결과 열을 만들어보세요. 실제 보안성 검토 업무를 이해하는 데 가장 빠른 연습 방법입니다.
여러분의 회사에서는 신규 솔루션 도입 시 어떤 보안성 검토 항목을 가장 중요하게 보고 있나요?
실제 면접에서 보안성 검토 질문을 받았다면 어떤 질문이 가장 어려웠는지도 댓글로 공유해보세요.
다음 글에서는 금융권 보안성 심의 보고서 작성 방법과 보안성 검토 면접 질문과 모범 답변을 함께 정리해보면 좋습니다.
본 포스팅은 정보 전달 목적이며, 실제 적용 시 발생하는 책임은 사용자에게 있습니다.