블럭스의 SOC 2 보안 여정과 우리가 남긴 기록

B2B SaaS 기업에게 보안 검증은 이제 선택이 아니라 필수에 가깝습니다. 특히 엔터프라이즈 기업과 미팅을 하다 보면 제품의 기능이나 성능보다 먼저 보안 관련 질문이 나오는 경우도 많습니다.

블럭스(Blux)도 영업 미팅 중 보안의 중요성을 실감했고, 이를 개선하기 위해 국제 보안 인증 중 하나인 ‘Service Organization Control 2(이하 SOC 2)’를 검토하게 되었습니다.

작년 하반기부터 본격적으로 준비를 시작했고, 처음엔 문서 몇 개만 제출하면 되는 간단한 절차일 거라 생각했습니다. 그러나 막상 시작해 보니 검색만으로는 알 수 없는 요구사항, 해석이 분분한 기준, 팀 내 보안 인식 차이 등 생각보다 많은 벽에 부딪혔습니다.

아마 많은 SaaS 기업이 비슷한 상황에서 같은 고민을 하고 있을 겁니다. 이번 글에서는 SOC 2를 중심으로 보안 표준 검증 과정에서 흔히 생기는 오해를 짚어보고, 블럭스가 SOC 2 검증을 통과하기까지의 여정과 그 안에서 얻은 인사이트를 진솔하게 공유하고자 합니다.

보안 표준 검증을 둘러싼 오해

많은 기업이 보안 표준 심사를 준비하면서 몇 가지 잘못된 오해를 하는 경우가 많습니다. 보통 이러한 오해로 인해 실제 보안 표준 검증 프로세스를 이해하는 데 방해가 됩니다.

대표적인 오해들은 다음과 같습니다.

1. 보안 표준 검증은 1개월만 준비하면 통과할 수 있다.

2. 보안 표준 검증은 외부 업체에 전부 맡기면 된다.

3. 한 번 보안 표준 검증을 통과하면 평생 유효하다.

4. 보안 표준 검증을 통과하려면 대규모 보안 팀이 필요하다.

5. 보안 표준 검증을 통과하려면 보안 전문가를 반드시 채용해야 한다.

지금 돌이켜보면, 당시 우리가 가졌던 불안과 고민은 대부분 근거 없는 오해에서 비롯된 것이었습니다. 하지만 보안 표준 심사를 준비하기 시작했을 때는 이런 잘못된 정보들 앞에서 시작도 하기 전에 많은 고민에 빠질 수밖에 없었습니다.

블럭스는 준비 과정에서 이러한 오해를 하나씩 바로잡아 나갔고, SOC 2 검증을 단순히 통과하는 것을 넘어 보안 체계를 근본적으로 점검하고 개선하는 기회로 활용했습니다.

보안 표준 검증을 둘러싼 여러 오해는 여전히 존재합니다. 많은 SaaS 기업이 비슷한 시행착오를 겪고 있다는 점에서 우리가 겪은 경험은 개인적인 고생담을 넘어 실질적인 참고가 될 수 있다고 생각합니다.

SOC 2란 무엇이고, 왜 주목받을까?

‘SOC 2’는 미국공인회계사협회(AICPA)에서 제정한 서비스 조직 통제(System and Organization Controls) 보고서 중 하나로, 특히 클라우드 서비스 제공업체나 데이터를 처리하는 서비스 조직의 데이터 보안 및 프라이버시 준수 여부를 평가하기 위한 자발적 준수 표준입니다.

오늘날 B2B SaaS 기업들에게 SOC 2는 단순한 선택이 아니라 미국 및 글로벌 시장 진출을 위한 사실상의 필수 보안 표준이 되었습니다. 기업 고객들이 외부 서비스를 도입할 때 해당 서비스가 신뢰할 만한 수준의 고객 정보 보호 체계를 갖추고 있는지를 객관적으로 검증할 수 있는 기준으로 SOC 2를 요구하는 경우가 많기 때문입니다.

특히 클라우드 기반 서비스 제공업체나 고객 데이터를 처리하는 기업들은 SOC 2를 통해 보안 수준을 입증하고, 대기업 및 해외 고객과의 신뢰를 확보할 수 있습니다.

SOC 2의 5가지 신뢰 서비스 기준

SOC 2는 기업의 보안 및 데이터 보호 수준을 다음 5가지 신뢰 서비스 기준(Trust Services Criteria, TSC)에 따라 검증합니다.

1. 보안 (Security) – 시스템 보호, 접근 통제, 보안 사고 대응

2. 가용성 (Availability) – 서비스 성능, 모니터링, 재해 복구

3. 처리 무결성 (Processing Integrity) – 데이터 처리 정확성 및 오류 관리

4. 기밀성 (Confidentiality) – 민감 정보 보호, 데이터 접근 제한, 암호화

5. 개인정보보호 (Privacy) – 개인정보 수집, 보관, 파기 및 정책 준수

이 중 ‘보안’은 필수 요소이고, 나머지는 조직의 필요에 따라 선택적으로 적용됩니다. 블럭스는 이번 검증에서 ‘보안’, ‘가용성’, ‘기밀성’을 선택하였습니다.

SOC 2 보고서 유형

SOC 2는 3~12개월간의 실제 운영 데이터를 기반으로 검증하며, Type I과 Type II 두 가지 유형으로 나뉩니다.

SOC 2 Type I와 Type II의 비교 (출처: 본인)

흔히 ‘SOC 2를 통과했다’고 말하는 것은 ‘SOC 2 Type II를 통과했다’는 것을 의미합니다. SOC 2 Type II는 조직이 보안 통제를 지속적으로 유지하고 있는지를 입증하는 기준이자 대기업 및 해외 고객이 요구하는 핵심 표준입니다.

이처럼 SOC 2는 조직이 데이터 보안, 가용성, 기밀성, 개인정보 보호 등의 측면에서 적절한 내부 통제를 갖추고 있음을 입증하는 역할을 합니다. 이는 고객에게 서비스의 신뢰성을 보장하며, 비즈니스 파트너십이나 계약 체결 시 중요한 요소로 작용합니다.

B2B SaaS 기업에게 SOC 2가 필요한 이유

B2B SaaS 기업에게 있어 보안 표준 검증 통과는 더 이상 ‘하면 좋은 것’이 아닌, 하지 않으면 기회조차 얻기 어려운 ‘필수 요건’이 되어가고 있습니다. 특히 SOC 2는 글로벌 시장에서 신뢰를 확보하고, 대기업과의 비즈니스를 성장시키기 위한 핵심 기반으로 작용합니다. 저는 이러한 관점에서 B2B SaaS 기업에게 SOC 2가 필요한 이유를 다음과 같이 세 가지로 정리해 보았습니다.

고객 신뢰 확보와 글로벌 시장 진출

많은 기업 고객, 특히 대기업 및 글로벌 기업들은 SaaS 제품을 도입할 때 SOC 2 혹은 동급의 보안 표준 검증 통과를 필수 요건으로 요구합니다.

리턴제로 사업 총괄을 맡고 있는 최승호님의 링크드인 게시물에서 확인할 수 있듯, 통과한 보안 표준이 없다는 이유로 도입 검토 단계에서 탈락하는 사례가 실제로 존재합니다.

블럭스 역시 보안 표준 심사 준비 초기, 대기업과의 파트너십을 위해 SOC 2 등 보안 표준 검증 통과가 선제 조건으로 요청된 경험이 있습니다. 이는 보안 표준 검증 통과가 단순한 내부 만족이 아니라, 외부 고객과의 신뢰 형성에 핵심적인 역할을 한다는 사실을 명확히 보여줍니다.

비즈니스 성장의 핵심 동력

SOC 2는 단순히 보안을 입증하는 역할을 넘어 세일즈 프로세스를 가속화하고 경쟁사 대비 우위를 확보하는 중요한 수단이 됩니다.

기업 고객은 신규 솔루션을 도입할 때 보안 검토 과정을 반드시 거치고 있습니다. 이때 SOC 2는 그 자체로 신뢰할 수 있는 검증된 기업임을 입증하는 강력한 증거가 됩니다. 특히 보안 표준 검증 통과 여부가 실제 계약 성사 여부를 좌우할 정도로 고객사의 기준이 높아지고 있습니다.

경쟁이 치열한 B2B SaaS 시장에서 SOC 2를 통해 보안 수준의 차별화와 더불어 고객사와의 신뢰 구축 속도를 단축할 수 있습니다.

실질적인 보안 수준 강화

이와 함께 SOC 2를 준비하는 과정은 조직 전체의 보안 수준을 실질적으로 높이는 계기가 됩니다.

단순히 외부 감사를 위한 준비에 그치는 것이 아니라, 내부적으로는 보안 정책의 정비, 위험 평가 체계 수립, 클라우드 인프라 내 기술적 조치 수행 등까지 이어지기 때문입니다. 이러한 노력의 결실은 단기적인 보안 표준 검증 통과에 그치지 않고, 지속 가능한 보안 운영 체계의 초석을 마련하는 데까지 이릅니다.

이처럼 B2B SaaS 기업에게 SOC 2는 단순한 ‘보안 표준 검증 통과’ 이상의 의미를 지니며, 신뢰, 성장, 보안 강화라는 세 가지 축을 동시에 달성하기 위한 전략적 수단이라고 볼 수 있습니다.

블럭스의 SOC 2 검증 통과 여정

저희는 2024년 8월부터 본격적으로 SOC 2를 준비하기 시작했고, 2025년 3월에 Type I 및 Type II까지 전부 마무리하였습니다. 약 7개월에 걸친 이 보안 여정을 SOC 2를 준비하는 기업들에게 조금이나마 도움이 되기를 바라는 마음으로 정리했습니다. 어떤 일이 있었고 어떤 결정을 내렸는지를 타임라인에 따라 가능한 한 상세하고 사실 중심으로 담았습니다.

2024년 8월 – 보안 컴플라이언스 SaaS 선정

SOC 2를 위해 저희가 가장 먼저 수행한 작업은 이를 효과적으로 도와줄 보안 컴플라이언스(Compliance, 관련 법률이나 규정을 준수하는 것) SaaS 도구를 선정하는 것이었습니다.

보안 관리와 감사 대응을 수작업으로 수행하기에는 인력 자원이 제한적이었기 때문에 효율적이고 체계적인 컴플라이언스 운영을 위해 SaaS 도구의 도입이 큰 도움이 될 것이라고 판단했기 때문입니다.

저희는 총 3곳의 업체와 미팅을 진행하며 아래와 같은 기준으로 비교 분석했습니다.

1. 스타트업 친화성: Slack Connect 등 실시간 지원 채널 보유 여부

2. 도입 속도: 업체에서 제시한 전체적인 타임라인, 고객 대응 속도

3. 가격의 합리성: 예산 내에서 지속 운영이 가능한 구조인지

이 과정에서 ‘드라타(Drata)’라는 글로벌 업체가 제공하는 자동화 수준, UI/UX, 그리고 전문 컨설턴트와의 실시간 소통 환경이 특히 뛰어나다고 느꼈고, 최종적으로 선택하게 되었습니다.

2024년 8월 29일 – Drata와 킥오프 미팅

Drata는 보안 및 컴플라이언스 전문가들이 설계한 GRC(Governance, Risk, Compliance, 조직의 지배 구조, 위험, 규제 준수를 통합적으로 관리하는 프레임워크) 플랫폼으로 AI 기반 자동화를 통해 기업이 감사 대응이 가능한(audit-ready) 보안 조직을 운영할 수 있도록 지원합니다.

Drata의 주요 기능은 크게 세 가지로 정리할 수 있습니다.

• 컴플라이언스 자동화: AI를 활용해 SOC 2, ISO 27001 등 보안 프레임워크의 최대 90% 업무 자동화

• GRC 관리: 리스크 평가 및 자동화된 감사 대응

• 보안 검증: 실시간 모니터링 및 증빙 자동 수집

실제로 Drata 플랫폼을 활용해 SOC 2 검증을 준비하면서 많은 부분이 자동화되어 편리하다고 느꼈습니다. 그리고 실시간 모니터링을 통해 특이사항이 감지되면 회사의 슬랙(Slack) 채널에 알림을 보내게끔 설정할 수도 있어서 문제가 생겼을 시 빠르게 대처할 수 있는 점도 마음에 들었습니다.

2024년 9월 ~ 10월 – 보안 관련 필수 요건 수행

블럭스는 이 기간 동안 SOC 2 요구 사항에 기반해 보안 정책 수립, 기술적 통제 적용, 내부 보안 수준 점검 및 개선 등 다양한 작업을 수행했습니다. 구체적으로 어떤 작업을 수행했는지 요약하자면 다음과 같습니다.

우선 슬랙(Slack), 구글 워크스페이스(Google Workspace), AWS, 몽고DB 아틀라스(MongoDB Atlas), 깃허브(GitHub) 등 저희가 사용하는 다양한 업무 협업 서비스를 Drata와 연결하였습니다. 이후에는 Drata의 모니터링 탭을 통해 자동화 기능도 활용할 수 있게 되었습니다.

예를 들어, 모든 AWS 사용자의 MFA(Multi-factor Authentication, 사용자 인증 시 두 가지 이상의 서로 다른 인증 요소를 요구하여 보안성을 높이는 방식) 설정이 잘 되어 있는지 Drata의 모니터링 탭을 통해 자동으로 파악할 수 있게 되었습니다.

두 번째로 각 구성원의 장치(컴퓨터)에 Drata 에이전트를 설치하고 구성원의 보안 환경을 점검하였습니다. Drata 에이전트는 각 구성원의 장치에 (1) 비밀번호 관리자가 설치되어 있는지, (2) 하드 디스크가 암호화되어 있는지, (3) 안티바이러스 소프트웨어가 설치되어 있는지, (4) 자동 업데이트가 설정되어 있는지, (5) 화면 보호기가 설정되어 있는지를 자동으로 검증하는 프로그램입니다.

이를 활용해 각 구성원의 장치가 적절한 조치에 의해 보호되고 있는지 실시간으로 추적 및 관찰할 수 있습니다. 특정 구성원의 장치에 대한 보호가 미흡한 경우 슬랙 채널에 알림이 오게끔 하여 빠른 조치가 가능하도록 하였습니다.

세 번째로 필수적인 보안 정책을 작성하고 정리하였습니다. 보안 정책에는 조직 내 자산(기기, 소프트웨어 등)의 관리 기준과 책임을 정의한 ‘Asset Management Policy’, 문제 상황이 발생할 경우 백업 절차와 복구 기준을 명시한 ‘Backup Policy’, 장애, 재해 등 비상 상황에서도 비즈니스 연속성을 유지하기 위한 계획을 담은 ‘Business Continuity Plan’ 등이 포함되어 있습니다.

앞서 소개한 5가지 신뢰 서비스 기준 중 어떤 것을 선택하느냐에 따라 필수적으로 준비해야 하는 정책이 달라집니다. 저희는 '보안', '가용성', '기밀성'의 세 가지 신뢰 서비스 기준을 선택했으며, 총 약 23개의 정책을 정비하였습니다.

DoS 공격에 대한 위험 및 대응 방안 평가 (출처: 본인)

네 번째로 각종 위험과 그에 대한 대응 방안을 평가하는 작업을 수행했습니다. 여기서 위험이란 회사에 잠재적으로 (혹은 당장) 위협이 될 수 있는 모든 상황을 뜻하는데, 이런 여러 위험을 나열하고 각 위험에 대한 대응 방안까지 함께 평가할 필요가 있었습니다. 

위험의 종류는 다양합니다. 회사에 불이 나서 자산이 손실되는 상황이 있을 수도 있고, 비밀번호 등 중요한 정보가 악성 사용자에 의해 탈취되는 상황도 위험으로 취급할 수 있습니다. 위의 표는 SaaS 기업의 위험 중 하나인 DoS 공격에 대한 위험 및 대응 방안을 나타낸 것입니다. 이와 같이 저희는 다양한 범주에 걸친 총 약 60여 개에 이르는 위험과 그에 대한 대응 방안을 평가했습니다.

주요 AWS 보안 서비스 비교 (출처: 본인)

다음으로 클라우드 보안과 관련해 필요한 여러 조치들을 수행했습니다. 대표적인 AWS의 보안 서비스인 AWS CloudTrail, Amazon Inspector, Amazon GuardDuty, AWS WAF를 활용한 것은 물론이고, 백업을 위해 모든 S3 버킷에 버저닝(Versioning, 시스템이나 파일의 변경 이력을 관리하기 위해 각 버전에 번호를 부여하고 이를 기록 및 관리하는 것) 조치를 취했습니다.

위의 표는 이 중 AWS CloudTrail, Amazon Inspector, Amazon GuardDuty에 대한 설명과 저희가 이 서비스들을 어떻게 활용하고 있는지 정리한 것입니다. 이 셋을 한꺼번에 AWS의 보안 서비스라고 지칭하는 경우가 많은데, 각 기능이 엄밀히 다르기 때문에 실제 활용을 위해서는 차이점을 알아두는 것이 중요합니다.

또한 AWS WAF(Web Application Firewall, 이하 WAF)를 통해 블럭스의 여러 웹 애플리케이션을 보호하기 위해 힘썼습니다. WAF는 악성 트래픽 및 보안 위협으로부터 웹 애플리케이션을 보호하는 방화벽 서비스로 ALB, API Gateway, CloudFront 등을 보호할 수 있습니다.

블럭스는 WAF의 여러 기능 중에서도 AWS Managed Rule Groups, 특정 IP 제한, Rate Limiting 기능을 적극적으로 활용하고 있습니다. AWS Managed Rule Groups는 다양한 일반적인 위협으로부터 애플리케이션을 보호하기 위해 AWS에서 기본적으로 제공하는 규칙의 모음인데, Core Rule Set, Known Bad Inputs, Anonymous IP List 등이 있습니다.

Rate Limiting 기능에서는 ‘단위 시간 동안 일정 수준 이상의 요청이 들어올 경우 이를 차단한다’는 규칙을 활용해 과도하고 악의적인 요청으로부터 애플리케이션을 보호하고 있습니다. 이와 같은 WAF의 다양한 기능은 WAF 워크숍을 통해서 효과적으로 알아볼 수 있으며, 저희도 실제 운영 환경에 적용하기 전에 많은 도움이 되었습니다.

2024년 11월 13일 – Drata와 사전 감사(Pre-audit) 진행

10월까지 대부분의 필수적인 보안 관련 조치들을 마친 후 본격적으로 감사 기간에 돌입하기 전에 Drata와 사전 감사를 진행하였습니다. 사전 감사는 실제 감사 직전에 내부적으로 모든 항목이 준비되었는지를 점검하는 단계입니다.

이때 Drata 플랫폼의 모니터링 탭의 커버리지가 100%에 근접했는지, 주요 벤더(Vendor, 제품이나 서비스를 제공하는 외부 공급업체 또는 판매자)가 잘 정의되어 있는지, 아키텍처 다이어그램(Architecture Diagram, 시스템의 구성 요소와 그들 간의 관계를 시각적으로 표현한 도식)이 잘 갖춰져 있는지 등을 확인하게 됩니다.

이 사전 점검을 통해 저희는 이후 진행된 감사 기관과의 본 감사에서 불필요한 반복 작업을 줄이고, 여러 항목에 대해 선제적인 대응을 할 수 있었습니다.

2024년 11월 29일 – AssuranceLab과 킥오프 미팅

Drata로부터 파트너 감사 기관으로 소개받은 ‘AssuranceLab’은 전 세계 30개국 이상의 기술 기업 800곳 이상의 보안 검증 심사를 진행해 온 신뢰할 수 있는 감사 파트너입니다.

SOC 2 외에도 ISO 27001, ISO 42001, CSA STAR, HIPAA 등 다양한 국제 보안 표준에 대한 감사를 지원하며, AWS 기반의 클라우드 인프라 환경에 익숙한 기관입니다. 특히 호주에 팀이 있어서 저희와 시간대가 잘 맞아 커뮤니케이션이 상당히 원활했습니다.

2024년 11월 29일 ~ 12월 18일 – SOC 2 Type I 감사(Audit) 진행

AssuranceLab은 감사 개시 후 블럭스의 현재 보안 통제 상태를 진단하고 개선이 필요한 영역을 상세히 설명했습니다. 저희도 본격적인 감사를 받기 전까지는 미처 알지 못했지만, SOC 2와 같은 국제 보안 표준은 단순히 적합·부적합을 판정하는 일회성 평가에 그치지 않습니다. 감사 기관이 기준을 충족할 수 있도록 함께 고민하고, 구체적인 개선 방향을 제시해 주는 점이 인상적이었습니다.

위에 보이는 구글 시트를 AssuranceLab 측에서 제공했는데, 이를 기반으로 항목별 요구사항, 질의 내용, 증빙 자료 제출 상태 등을 실시간으로 소통하며 확인할 수 있었습니다. 10번째 행을 보면, CI/CD 환경 구축에 대한 증빙을 감사 기관에서 요청하였고, 이에 따라 저희는 GitHub Actions와 ArgoCD를 활용한 CI/CD 사용 사례를 화면 캡처하여 제출하였습니다.

이런 식으로 모든 필수 항목이 하나의 시트로 관리되어 감사 기관과 명료하면서도 효율적인 의사소통을 할 수 있었습니다.

2024년 12월 18일 – SOC 2 Type I 보고서 발급

약 4개월의 준비 끝에 저희는 Type I 검증을 성공적으로 통과했습니다.

SOC 2 Type I 보고서는 보안 통제의 설계가 적절하게 이루어졌는지를 평가합니다. 이 보고서 발급 이후에는 곧바로 Type II 감사를 시작했습니다.

2024년 12월 19일 ~ 2025년 3월 19일 – SOC 2 Type II 감사(Audit) 진행

Type II 감사는 Type I과 동일한 통제 항목을 기준으로 하면서, 그 통제들이 최소 3개월 이상 실제로 잘 운영되었는지를 평가하는 과정입니다.

저희는 이 기간 동안 인시던트 대응(Incident Response, 보안 사고 발생 시 이를 탐지·대응·복구하기 위한 조직의 절차 및 활동) 시나리오나 비즈니스 연속성 및 재해 복구 테스트(BC/DR 테스트, Business Continuity and Disaster Recovery Test, 시스템 장애나 재해 상황을 가정하여 실제로 비즈니스 연속성 및 복구 절차가 정상적으로 작동하는지 검증하는 테스트)와 같은 각종 대응 및 테스트를 점검하고 미비한 부분을 추가로 보완했습니다.

이 과정은 단지 문서를 준비하는 데 그치는 것이 아니라 실제 조직 내 보안 프로토콜과 문화를 점검하고 전체적인 보안 수준을 높이는 계기가 되었습니다.

2025년 3월 21일 – SOC 2 Type II 보고서 발급

SOC 2 Type II 검증을 성공적으로 통과하고 나면 보고서가 발급되고, 위와 같이 웹사이트 및 제안서 등 다양한 채널에서 마케팅 자산으로 활용할 수 있는 배지도 제공됩니다.

블럭스는 약 7개월에 걸친 SOC 2 보안 여정을 거쳐, Type II 검증까지 무사히 통과하며 모든 과정을 마무리했습니다.

SOC 2 준비 과정에서 얻은 인사이트

SOC 2 심사를 준비하면서 블럭스는 보안 프로세스 정비뿐만 아니라, 업무 방식, 보안을 대하는 태도, 커뮤니케이션 방식 등에서 많은 인사이트를 얻었습니다. 그중에서도 두 가지 핵심 교훈을 얻게 되었습니다.

글로벌 감사 기관 및 외부 담당자와의 협업: 성실성과 적극성

SOC 2에서는 글로벌 감사 기관, 보안 컨설팅 업체, AWS 등 다양한 외부 관계자들과의 협업이 필수입니다. 제가 직접 여러 외부 관계자들과 커뮤니케이션을 지속적으로 진행하며 느낀 점은 이 과정이 단거리 질주가 아닌 장기전이라는 점이었습니다.

수많은 커뮤니케이션이 오가는 과정에서 일정이 지연되는 일은 어느 정도 피할 수 없습니다. 중요한 건 그 지연을 얼마나 최소화하느냐입니다. 저는 외부 관계자들의 스케줄 등 제가 컨트롤할 수 없는 부분에 대해서는 마음을 비우고, 최소한 내부 일정만은 반드시 준수하자는 마음가짐으로 임했습니다.

즉, 일정이 지연되더라도 제 쪽에서 책임지는 부분은 성실하게, 제때 대응하는 자세가 전체 흐름을 지켜주는 핵심이었습니다.

또한, 때로는 사소해 보이는 질문이라도 그냥 넘어가지 않고, 모호한 부분은 먼저 묻고 확인하는 자세가 관계자들과의 신뢰를 쌓는 데 도움이 되었습니다.

특히 Drata 사용과 관련해 크고 작은 문제가 있을 때마다 지원팀에 저희의 상황을 최대한 상세히 기술해서 도움을 요청하였는데, 전체 여정 동안 매우 빠르고 꼼꼼하게 대응해 주었습니다.

바로 문제 해결이 어려운 경우에는 원격 접속 활성화와 같이 실시간으로 문제를 해결할 수 있는 방법을 선제적으로 제안하기도 하였습니다. 이러한 과정을 겪으면서 단순한 업무 처리 이상의 적극성이 상대방의 협조를 유도하는 열쇠라는 걸 체감했습니다.

품질과의 타협은 금물

SOC 2를 준비하다 보면 '일단 검증만 통과하자'는 유혹이 생기기 마련입니다. 그러나 SOC 2를 진행하며 블럭스는 실제 보안 수준을 높이는 것이 궁극적으로 더 큰 이점을 가져온다는 점을 다시 확인할 수 있었습니다.

특히 사이버 위협은 최근 들어 전 세계적으로 빠르게 증가하고 있습니다.

기업을 대상으로 한 사이버 위협이 지속적으로 증가하는 환경에서 형식적인 보안 조치는 더 이상 충분하지 않습니다. 저희는 각종 보안 조치를 기준에 맞춰 적용하는 데 그치지 않고, 실제 보안 위협을 줄이기 위한 최선의 방법이 무엇인지 지속적으로 고민했습니다.

외부 위협에 대한 대응을 확인하는 항목에서는 단순히 WAF를 기본 설정으로 적용해도 충분했지만, 실질적인 보호를 위해 다양한 실험과 분석을 거쳐 블럭스의 서비스 환경에 최적화된 WAF 정책을 직접 설계 및 적용했습니다.

단기적으로는 업무 부담이 커질 수 있지만, 장기적으로는 모범 사례 기반의 보안 구조가 우리 제품과 조직을 지켜주는 핵심 자산이 될 것이라고 확신했습니다.

품질을 놓치지 않으면서 이러한 작업들을 수행하는 일은 처음 SOC 2와 같은 글로벌 보안 표준 검증에 도전하는 기업에게 적지 않은 부담이 될 수 있습니다. 이런 기업이라면 본격적인 글로벌 보안 검증에 앞서, AWS FTR 취득부터 먼저 도전해 보기를 권합니다.

AWS FTR(Foundational Technical Review, 이하 FTR)은 AWS의 보안 및 아키텍처 모범 사례에 따라 서비스가 안전하게 운영되고 있는지 검토하는 과정입니다. 블럭스는 SOC 2 여정에 돌입하기에 앞선 2024년 4월에 먼저 취득한 바 있습니다.

FTR은 AWS에서 제공하는 클라우드 기반 서비스를 더욱 안전하게 운영하기 위한 표준 중 하나로 블럭스는 이를 통해 이미 AWS의 모범 사례 기반 보안 조치를 정비한 경험이 있어 SOC 2 준비 과정이 더욱 수월했습니다.

SOC 2는 단순한 보안 표준 검증이 아니라 보안 운영 체계를 실질적으로 강화하는 과정입니다.

여러 이해 관계자들과의 적극적인 커뮤니케이션은 보안 표준 검증 프로세스를 원활하게 만드는 핵심 요소였습니다. 또한, 보안 품질을 강화하는 일이 장기적으로 기업 경쟁력 확보로 이어진다는 점도 이번 과정을 통해 몸소 느낄 수 있었습니다.

저희는 FTR과 SOC 2를 준비하면서 얻은 경험을 바탕으로 앞으로도 보안 수준을 꾸준히 끌어올리고, 실질적인 보호 조치를 강화하는 방향으로 나아가려 합니다.

SOC 2 그다음, 블럭스가 이어갈 보안 이야기

블럭스는 단순히 SOC 2 통과에 머물지 않고 실질적인 보안 수준을 지속적으로 강화하는 것을 다음 과제로 삼고 있습니다.

우선, 검증 과정에서 우선순위에 따라 백로그로 미뤄두었던 보안 개선 작업들을 순차적으로 수행해 나갈 예정입니다. 예를 들어, Amazon Inspector에서 발견되었지만 상대적으로 취약도가 낮아 당시에는 즉각 대응하지 않았던 항목들을 선제적으로 개선할 것이며, 내부적으로는 사고 대응 절차를 최적화하는 등 보안 프로세스 전반을 강화할 것입니다.

또한, 블럭스는 곧 국제 정보보호 관리 체계(ISMS) 표준인 ‘ISO 27001’에도 도전할 계획입니다. SOC 2가 주로 B2B SaaS 및 클라우드 서비스 제공 기업의 보안 통제 수준을 검증하는 데 초점을 맞추고 있다면, ISO 27001은 산업과 조직의 구분 없이 전반적인 정보보안 리스크를 식별·평가하고 지속적으로 개선할 수 있도록 돕는 체계적인 관리 기준을 제공합니다.

ISO 27001까지 완료한 이후에는 국내 정보보호 인증인 ISMS-P에도 도전할 계획입니다. ISMS-P(정보보호 및 개인정보보호 관리체계 인증)는 한국인터넷진흥원(KISA) 주관의 국가 공인 인증으로 기업이 고객의 개인정보를 안전하게 보호하고 있다는 것을 공식적으로 입증하는 제도입니다.

정보보호(ISMS)와 개인정보보호(PIMS) 기준이 통합되었으며, 특히 금융, 헬스케어, 공공 분야의 고객을 대상으로 서비스를 제공하려는 SaaS 기업에게는 필수 요건으로 자리 잡고 있습니다.

블럭스는 위 두 가지 추가적인 보안 표준을 통해 규제가 엄격한 산업 분야로 사업 영역을 확장할 수 있는 기반을 마련하고, 국내외 고객 모두에게 신뢰받는 최고 수준의 보안 역량을 갖춘 SaaS 기업으로 지속 성장해 나갈 것입니다.

한정된 자원으로 SOC 2 등 보안 표준 심사를 준비하며 고군분투하고 있는 많은 기업에게, 이 글이 조금이나마 실질적인 인사이트와 방향을 전할 수 있기를 진심으로 바랍니다.