[HowTo] 방법론 · 작성: 2026-07-19 23:05:48 · 수정: 2026-07-20 17:38:00 · 조회 56
이 글은 필자가 기술 보안 컨설턴트로서 현업에 종사해보며 느꼈던 점, 배운 점 등을 나열한 글이다.
버그바운티 글에서 다룬 것처럼 개인이 스코프를 골라 자유롭게 뚫어보는 방식과 컨설팅으로 하는 모의해킹·취약점 진단은 결이 완전히 다르다. 컨설팅은 기간제 계약으로 움직인다. 정해진 기준으로, 정해진 자산을 전부, 정해진 기간 안에 봐야 하고 끝나면 보고서를 낸다. 처음 이 일을 시작했을 땐 "결국 취약점 찾는 건 다 똑같겠지" 싶었는데, 막상 해보니 버그바운티랑은 아예 다른 종류의 일이었다. 이 글에는 그 프로젝트가 실제로 어떤 흐름으로 굴러가고, 뭐가 나와야 끝나는 일인지 정리해봤다.
처음 투입됐을 때 제일 헷갈렸던 게 이 부분이었다. "취약점 진단"이라고만 알고 들어갔는데, 막상 보니 프로젝트마다 근거로 삼는 기준이 다 다르고, 그 기준에 따라 뭘 봐야 하는지도 달라졌다. 이걸 모르고 들어가면 첫 미팅에서부터 뭔 소린지 못 알아듣는다.
**ISMS-P(정보보호 및 개인정보보호 관리체계)**는 정보통신망법 제47조와 시행령 제49조에 근거한다. 원래 정보보호만 보는 ISMS와 개인정보 처리까지 같이 보는 ISMS-P로 나뉘는데, 요즘 새로 인증받는 곳은 거의 다 ISMS-P다. 인증을 반드시 받아야 하는 곳은 기간통신사업자(ISP), IDC 운영사, 그리고 매출이나 이용자 규모가 일정 선을 넘는 곳이다. 대략 연 매출(세입 포함) 1,500억 원 이상이거나, 정보통신서비스 쪽 매출만 따로 100억 원이 넘거나, 전년도 말 기준 하루 평균 이용자가 100만 명이 넘으면 대상이 된다. 상급종합병원이나 재학생 1만 명 넘는 학교도 포함된다. 대상으로 지정되면 KISA가 통보해주고, 다음 해 8월 31일까지 인증을 따야 한다. 컨설팅사가 붙는 시점은 인증 심사 그 자체보다는, 심사 전에 미리 자체적으로 위험분석하고 취약점 진단하는 단계인 경우가 많다. 인증 항목을 그대로 체크리스트처럼 놓고 진단하는 식이다.
전자금융기반시설은 전자금융거래법과 전자금융감독규정을 따른다. 은행이나 카드사, 증권사 같은 데가 대상이다. 대상이 되는 기준은 총자산 2조 원 이상에 상시 직원 300명 이상인 금융회사나 전자금융업자. 여길 넘으면 연 1회 이상 취약점 분석·평가를 해야 하고, 나온 결과로 이행계획도 세워야 한다. 실제로 볼 때는 금융보안원이 만든 안내서를 기준 삼아서 서버(SRV), DBMS(DBM), Web/WAS(WST), 네트워크(NET) 이렇게 네 영역으로 나눠서 본다. 인프라 쪽은 연 1회, 웹이나 모바일 앱 대상 모의해킹은 연 2회가 보통이다. 클라우드나 컨테이너 가상화, 가상자산 거래소처럼 새로 생긴 영역도 계속 기준에 추가되는 중이라 매년 안내서 개정판을 챙겨봐야 한다.
주요정보통신기반시설은 정보통신기반보호법이 근거다. 통신, 에너지, 금융, 교통, 행정처럼 국가 차원에서 중요한 인프라를 지정해서 관리하는 개념인데, 앞의 전자금융기반시설처럼 매출액으로 딱 잘라 정하는 게 아니라 그 업무가 얼마나 중요한지, 다른 시설이랑 얼마나 얽혀있는지를 평가해서 정한다. 소관 부처가 과기정통부나 국정원으로부터 지정 권고를 받으면 60일 안에 지정평가반(반장 1명, 네트워크·시스템·보안 전문가 몇 명)을 꾸려서 자체평가를 하고, 정보통신기반보호위원회 심의를 거쳐 지정되면 관보에 고시된다. 한 번 지정되면 그걸로 끝이 아니라 매년 취약점 분석·평가를 해야 하고, 컨설팅사는 보통 이 연례 평가를 대행하는 역할로 들어간다.
국정원 실태평가는 공공기관 대상으로 보안 수준을 보는 절차인데, 앞의 것들과 다르게 기술적인 부분 말고도 보안 정책이나 조직 체계, 인력 운영 같은 관리적인 부분까지 같이 본다.
같은 "서버 점검"이라도 어느 기준으로 계약된 건지에 따라 봐야 하는 항목도, 판정 방식도 미묘하게 다르다. 매출 100억짜리 쇼핑몰(ISMS-P 대상)이랑 자산 2조짜리 은행(전자금융기반시설 대상)은 둘 다 "웹 서버 취약점 점검"이지만 참고하는 문서 자체가 다르다. 그래서 프로젝트 들어가기 전에 이번 건이 어떤 기준으로 계약된 건지, 그 기준의 최신 버전이 뭔지부터 확인하는 게 진짜 첫 단계다.
규모 있는 진단은 보통 PM(프로젝트 매니저) 밑에 PL(프로젝트 리더) 여럿이 있고, 그 밑에 실제로 손 움직이는 PA들이 붙는 구조다. 역할별로 뭘 하는지는 용어 정리 글에서 따로 다뤘다.
기준서엔 항목마다 양호/취약을 가르는 조건이 적혀있다. "불필요한 서비스 포트가 열려있지 않을 것" 같은 식으로. 근데 현장에서는 이 적힌 기준만 보고 판정이 안 끝나는 경우가 훨씬 많다. 이건 직접 겪어보기 전엔 잘 와닿지 않는 부분이었다.
먼저 범위를 어디까지로 볼지가 애매하다. "불필요한 포트"인지 아닌지는 그 서버가 실제로 뭐하는 서버인지 알아야 판단이 되는데, 문서엔 그냥 "불필요하면 취약"이라고만 써있다. 담당자 인터뷰나 트래픽 로그를 봐야 알 수 있는 경우가 많다. 예외를 인정할지도 애매한 문제다. 기준상으로는 취약해도 방화벽이나 접근 제어 같은 다른 통제가 있어서 실제 위험은 낮다고 보면 양호로 처리하기도 하는데, 이 대체 통제가 충분한지 판단하는 게 결국 컨설턴트 몫이다. 레거시 환경도 골치 아프다. 기준대로 고치면 오래된 장비에서 서비스가 죽을 수도 있는 상황이면, 바로 고치라고 하는 대신 위험을 그냥 감수할지 다른 대안 통제가 있는지를 같이 제시해야 한다. 같은 항목이라도 인터넷에 그대로 노출된 서버랑 내부망에서만 접근되는 서버는 실제 위험도가 다르니, 기준서 판정과 별개로 CVSS 등급을 조정한 근거를 보고서에 남겨두는 경우도 흔하다.
그래서 같은 항목을 두고도 컨설턴트마다 최종 판정이 갈릴 때가 있다. 이 편차를 줄이려고 PL이 PA의 판정 근거를 한 번 더 검수하고, 애매한 건 PM 선에서 고객이랑 다시 얘기하는 절차가 있는 거다. "기준서에 다 나와있으니 그대로 채우면 된다"고 생각하고 들어가면, 정작 판단이 필요한 대목에서 오판이 쌓인다. 나도 초반엔 이걸 몰라서 애먹었다.
짧은 기간에 봐야 할 자산은 많다. 실제 진단은 거의 다 스크립트랑 컨버터로 돌린다. 서버 수천 대를 몇 주 안에 끝내야 하는데 항목마다 사람이 일일이 판단하는 방식은 애초에 답이 안 나온다. 그래서 원래 개별 판단이 필요했던 항목 중에서 담당자 인터뷰로 "이 조건이면 그냥 일괄로 양호/취약 처리해도 된다"는 기준을 따로 세우고, 그걸 스크립트에 반영해서 자동으로 판정되는 범위를 넓히는 게 관건이다.
자동화 진단 솔루션을 도입한 회사도 꽤 있다. 자산이 수천 대면 사람이 서버마다 붙어서 하나하나 확인하는 건 말이 안 되니까, 에이전트를 깔거나 원격으로 명령어를 돌려서 설정값을 긁어오는 솔루션을 쓰는 거다. 근데 이런 솔루션을 쓴다고 사람 손이 안 가는 건 아니다. 솔루션이 해주는 건 값을 긁어와서 기준값이랑 기계적으로 비교하는 데까지고, 그 결과를 실제 엑셀 취약점 상세 보고서나 워드 최종 보고서 양식으로 정리하는 건 여전히 컨설턴트가 손으로 해야 한다. 게다가 솔루션이 "취약"이라고 뱉은 항목 중에서도 그 서버가 실제로 뭘 하는 서버인지 몰라서는 진짜 취약한 건지 판단이 안 서는 항목이 꼭 섞여 있다. 그래서 아무리 자동화를 잘 갖춘 프로젝트라도 인터뷰 자체는 없앨 수가 없다.
인터뷰는 일정 조율부터가 일이다. 담당자 입장에서는 본업이 따로 있는데 며칠씩 시간을 내줘야 하니, 먼저 어떤 서버·솔루션을 관리하는 담당자가 필요한지 추려서 요청하고, 담당자별로 가능한 시간대를 받아서 인터뷰 일정표부터 짜야 한다. 이게 밀리면 그 뒤 판정이랑 보고서 작성 일정까지 그대로 밀린다는 건 앞에서도 얘기한 대로다. 그리고 실제 인터뷰에 들어가면 그냥 궁금한 걸 물어보는 자리가 아니라, 이 자산을 계약된 기준(ISMS-P든 전자금융기반시설이든)으로 봤을 때 취약한지 아닌지를 그 자리에서 설명해주는 자리에 가깝다. 예를 들어 "이 포트가 열려 있는데 기준상으로는 불필요한 서비스면 취약으로 봅니다, 이 서버는 어떤 용도인가요?" 하고 물으면 담당자가 "이건 사내 배치 작업 때문에 꼭 필요하다"고 답하고, 그러면 그 근거를 남기고 양호로 넘긴다. 반대로 담당자도 정확히 모르는 서비스면 그건 그대로 취약 항목으로 남기고 조치 논의로 넘어간다. 이 자리에서 오간 얘기가 그대로 보고서의 판정 근거로 들어가기 때문에, 인터뷰 중에 메모를 얼마나 꼼꼼히 남기느냐가 나중에 보고서 쓸 때 일을 크게 줄여준다는 것도 직접 겪어보고 알았다.
벤더나 OS마다 출력이 다른 것도 은근히 신경 쓰인다. 같은 점검 항목이라도 AIX·Solaris·Linux·Windows가 명령어 출력 구조가 다 달라서, 파싱 로직 하나로 다 처리하려다간 오탐이 늘어난다. 벤더를 먼저 자동으로 구분하고 항목별 판정 기준을 나눠서 대응하는 식으로 갔다. 자동화를 많이 쓸수록 오탐도 같이 늘어나기 쉬워서, 최종 보고서 나가기 전에 사람이 한 번 더 봐주는 단계는 꼭 필요하다.
가장 크게 느낀 건, 취약점을 찾아서 보고하는 것과 그게 실제로 고쳐지게 만드는 건 완전히 다른 일이라는 거다. 담당자랑 같이 조치 방안을 구체화하고 이행점검까지 챙기는 게 결국 이 일의 진짜 가치를 결정한다는 생각이 든다.
결국 이 일을 해보면서 느낀 건, 취약점을 얼마나 많이 찾아주느냐보다 고객사 환경(어떤 솔루션 쓰는지, 서버 종류, 버전)을 제대로 고려해서 취약한지 아닌지를 정확히 판단하는 게 더 중요하다는 거다. 필요하면 직접 재현해서 실제로 어떻게 악용될 수 있는지 보여주고, 어떻게 고쳐야 하는지 제시하고, 이행점검까지 끝까지 챙기는 게 이 일의 본질이 아닐까 싶다.