몇 년 전 담당했던 프로젝트에서 요구사항 정의를 제대로 안 하고 비딩부터 진행했다가 계약 직전에 스펙이 통째로 바뀐 적이 있습니다. 그때 처음부터 다시 검토서를 써야 했던 기억이 아직도 선명합니다. 이런 시행착오, 보안 솔루션 도입을 담당해본 사람이라면 한 번쯤 겪어보셨을 겁니다.
첫 프로젝트를 진행할 때가 생각이 나는데요, 처음 하는 경우 전체적인 느낌이 오지 않아 당황스러울 때가 있습니다. 그럴 때에는 기업의 이전의 프로젝트를 참고해서 진행하거나 선배들에 조언을 구하는 수 밖에 없습니다. 처음부터 이 모든걸 아는 사람은 인생 2회차 밖에 없으니까요
이번 글에서는 필요성 검토부터 요구사항 정리, 업체 비딩, POC, BMT, 계약, 구축 완료까지 실무에서 실제로 진행되는 순서를 정리해 보겠습니다.
보안 솔루션 도입은 필요성 검토 → 요구사항 정의 → 업체 비딩 → POC → BMT → 계약 → 구축이라는 일곱 단계로 진행됩니다. 각 단계마다 검증 목적이 다르기 때문에 순서를 건너뛰면 계약 이후 분쟁으로 이어지기 쉽습니다. 특히 POC와 BMT를 혼동하는 경우가 많아 이 부분만 잘 구분해도 절반은 성공입니다.
도입 필요성 검토, 왜 먼저 해야 하는가
보안 솔루션 도입은 단순히 신규 제품을 들여오는 작업이 아닙니다. 기존 인프라와의 연동, 운영 인력의 숙련도, 예산 승인 절차까지 함께 검토해야 하는 조직 차원의 결정입니다.
실무에서 보면 필요성 검토 단계를 형식적으로 처리하고 넘어가는 경우가 의외로 많습니다. 그런데 이 단계에서 문제 정의가 흐릿하면 뒤에 나오는 요구사항 정의서도 부실해지고, 결국 비딩 단계에서 업체마다 서로 다른 해석을 하게 됩니다.
필요성 검토서에는 보통 다음 내용이 들어갑니다.
- 현재 보안 체계의 취약점 또는 미비점
- 규제 대응 요건 (개인정보보호법, ISMS-P 등)
- 기존 시스템과의 연동 가능성
- 예상 도입 효과 및 리스크 감소 수준
- 예산 및 일정 범위
요구사항 정의서 작성 방법
필요성 검토가 끝나면 요구사항 정의서(RFP, Request for Proposal)를 작성합니다. 이 문서가 부실하면 업체들이 제안서를 각기 다른 기준으로 작성해오기 때문에, 비교 자체가 무의미해지는 상황이 벌어집니다.
이건 직접 겪어보면 체감되는데, 요구사항을 “탐지 기능 우수”, “관리 편의성 높음” 같은 추상적인 문장으로 적으면 업체 입장에서도 무엇을 기준으로 제안해야 할지 모릅니다. 반대로 기능 단위, 성능 수치, 연동 대상 시스템까지 구체적으로 명시하면 제안서 품질이 확연히 달라집니다.
요구사항 정의서에는 기능 요구사항과 비기능 요구사항을 나눠서 작성하는 것이 좋습니다. 기능 요구사항은 탐지, 차단, 로깅, 리포팅 같은 실제 동작 항목이고, 비기능 요구사항은 성능, 확장성, 유지보수성, 지원 체계 같은 항목입니다.
요구사항 정의서 필수 포함 항목
- 도입 목적 및 배경
- 기능 요구사항 (필수 / 선택 구분)
- 비기능 요구사항 (성능, 가용성, 확장성)
- 연동 대상 시스템 목록
- 평가 기준 및 배점 방식
- 제출 마감일 및 제안서 형식
실무 팁: 평가 기준과 배점을 요구사항 정의서 단계에서 미리 정해두지 않으면, 비딩 이후 내부 평가 과정에서 부서 간 이견이 생기기 쉽습니다. 배점표는 최대한 초기에 확정해두는 것이 좋습니다.
업체 비딩 및 제안요청 프로세스
요구사항 정의서가 완성되면 후보 업체들에게 제안요청서를 배포하고 비딩을 진행합니다. 공공기관은 나라장터 같은 공식 입찰 시스템을 거치는 경우가 많고, 민간기업은 내부 구매 프로세스에 따라 지명경쟁 방식으로 진행하는 경우가 흔합니다.
이 부분이 핵심입니다. 비딩 단계에서는 단순히 가격만 비교하는 것이 아니라, 제안 내용이 요구사항 정의서와 얼마나 정합성 있게 매칭되는지를 봐야 합니다. 가격이 낮은데 요구사항 충족률이 떨어지는 제안서를 선택했다가 나중에 추가 비용이 발생하는 사례를 여러 번 봤습니다.
비딩 과정에서 보통 진행되는 절차입니다.
- 제안요청서(RFP) 배포
- 업체 질의응답(Q&A) 접수 및 답변
- 제안서 접수
- 제안서 평가 (기술 평가 + 가격 평가)
- 우선협상대상자 선정
많이들 여기서 막히더라고요. 특히 질의응답 단계를 생략하고 바로 제안서를 받는 경우, 업체가 요구사항을 잘못 해석한 채로 제안서를 제출하는 일이 자주 발생합니다. Q&A 기간을 충분히 두는 것만으로도 뒤 단계의 혼선이 크게 줄어듭니다.
POC와 BMT, 무엇이 다른가
우선협상대상자가 정해지면 본계약 전에 POC(Proof of Concept, 개념검증) 또는 BMT(Bench Mark Test, 성능검증)를 진행합니다. 두 절차의 목적이 다른데, 이름이 비슷해서인지 두 개를 같은 절차로 오해하는 경우가 정말 많습니다.
POC는 “이 솔루션이 우리 환경에서 실제로 동작하는가”를 확인하는 단계입니다. 개념적으로 가능한지, 기존 인프라와 충돌 없이 붙는지를 소규모로 테스트합니다. 반면 BMT는 “이 솔루션이 요구 성능을 실제로 만족하는가”를 수치로 검증하는 단계입니다. 처리량, 지연시간, 오탐률 같은 항목을 정량적으로 측정합니다.
| 구분 | POC | BMT |
|---|---|---|
| 목적 | 동작 가능성 확인 | 성능 수치 검증 |
| 진행 시점 | 비딩 직후 또는 비딩 이전 | 우선협상대상자 선정 이후 |
| 평가 방식 | 정성적 (동작 여부, 호환성) | 정량적 (처리속도, 오탐률, 안정성) |
| 테스트 규모 | 소규모, 제한된 환경 | 실제 운영 환경과 유사한 규모 |
| 참여 업체 수 | 다수 업체 병행 가능 | 보통 1~2개 업체로 압축된 상태 |
실무에서 보면 POC 단계에서 이미 절반 이상의 업체가 걸러집니다. 기존 시스템과 충돌이 나거나, 관리 콘솔이 요구사항과 맞지 않는 경우가 이 단계에서 드러나기 때문입니다. BMT는 그 이후 남은 후보군을 대상으로 실제 트래픽에 가까운 조건에서 정밀하게 검증하는 절차입니다.
실무 팁: BMT 시나리오는 반드시 실제 운영 트래픽 패턴을 반영해서 설계해야 합니다. 벤더가 제시하는 기본 테스트 시나리오만 따라가면 실제 환경에서 발생하는 오탐이나 병목 현상을 못 잡아내는 경우가 많습니다.
계약 체결 시 확인해야 할 사항
POC와 BMT를 통과하면 계약 단계로 넘어갑니다. 계약서에는 도입 비용뿐 아니라 유지보수 조건, SLA(서비스 수준 협약), 라이선스 갱신 조건까지 명시되어야 합니다.
초보 담당자와 실무자의 차이가 가장 크게 드러나는 부분이 바로 이 계약 검토 단계입니다. 초보자는 도입 가격과 기능 목록에만 집중하는 경향이 있는데, 실무자는 장애 발생 시 대응 시간, 패치 및 업데이트 주기, 계약 종료 시 데이터 이관 조건까지 꼼꼼히 확인합니다.
- SLA 응답시간 및 장애 대응 등급
- 유지보수 기간 및 갱신 조건
- 라이선스 산정 방식 (사용자 수, 트래픽 기준 등)
- 업데이트 및 패치 정책
- 계약 종료 시 데이터 반환 및 삭제 절차
이 항목들이 왜 실제로 더 중요하게 작용하는지는 도입 이후 1~2년이 지나야 체감되는 경우가 많습니다. 초기 도입 비용보다 운영 기간 동안의 유지보수 대응력이 전체 만족도를 좌우하기 때문입니다.
구축 및 안정화 단계
계약이 체결되면 실제 구축 작업이 시작합니다. 구축은 보통 설치 및 초기 설정, 정책 튜닝, 시범 운영(파일럿), 전체 확산 순서로 진행됩니다.
정책을 처음부터 완벽하게 세팅하려는 경우가 많은데, 실무에서는 오히려 초기에는 느슨한 정책으로 시작해서 오탐 로그를 분석하며 점진적으로 정책을 강화하는 방식이 더 안정적입니다. 처음부터 엄격하게 적용하면 정상 업무가 차단되는 사례가 발생해서 오히려 신뢰도가 떨어집니다.
구축 완료 체크리스트는 아래와 같이 정리해두면 누락 없이 진행할 수 있습니다.
- 초기 설치 및 에이전트 배포 완료 여부
- 정책 튜닝 및 오탐률 검증
- 관제 연동(SIEM, SOC 등) 여부 확인
- 운영 매뉴얼 및 장애 대응 프로세스 문서화
- 담당자 교육 및 인수인계 완료
많이들 여기서 막히더라고요. 특히 정책 튜닝 단계를 짧게 잡고 바로 전체 확산으로 넘어가는 경우, 확산 이후에 오탐이 대량 발생해서 운영팀이 초기 몇 주간 시달리는 경우를 종종 봅니다. 파일럿 운영 기간은 최소 2~4주 정도는 확보하는 것이 안전합니다.
흔한 오해와 교정
보안 솔루션 도입 과정에서 자주 발생하는 오해들을 정리해보겠습니다.
오해 1. POC를 통과했으니 BMT는 형식적인 절차다.
POC는 동작 여부만 확인하는 단계입니다. 실제 운영 환경의 트래픽량과 부하 조건에서는 전혀 다른 결과가 나올 수 있기 때문에 BMT를 생략하거나 형식적으로 진행하면 도입 이후 성능 문제로 이어질 수 있습니다.
오해 2. 가격이 가장 낮은 업체가 가장 합리적인 선택이다.
초기 도입 비용만 보고 결정하면 유지보수 비용, SLA 대응 수준에서 오히려 총소유비용(TCO)이 더 높아지는 경우가 있습니다.
오해 3. 구축이 끝나면 프로젝트가 종료된 것이다.
구축 완료 이후에도 정책 튜닝, 로그 분석, 예외 처리 등 안정화 작업이 최소 한 달 이상 필요합니다.
이 부분이 핵심입니다. 도입 프로젝트는 계약 체결이 끝이 아니라, 안정화까지 마쳐야 실제로 완료된 것입니다.
지금 진행 중인 보안 솔루션 도입 프로젝트가 있다면, 현재 어느 단계에 있는지 먼저 체크해보시길 권합니다. 요구사항 정의서가 구체적으로 작성되어 있는지부터 다시 점검하는 것이 가장 빠른 시작점입니다.
여러분은 POC와 BMT 단계에서 어떤 어려움을 겪으셨나요? 계약 조건 중 놓치기 쉬웠던 항목이 있다면 댓글로 공유해주시면 좋겠습니다.
본 포스팅은 정보 전달 목적이며, 실제 적용 시 발생하는 책임은 사용자에게 있습니다.