버지니아주 애나데일, 센터빌, 챈틸리 일대 — 미국에서 한인 소유 IT 인력공급·시스템 통합·전문 서비스 업체가 가장 밀집된 지역 중 하나입니다 — 에는 조용히 많은 가족 자산을 일궈온 특정 비즈니스 모델이 있습니다. 대형 국방 원청이나 연방 시스템 통합업체 아래 하도급을 따내고, 숙련된 엔지니어를 파견하거나 서비스를 제공하며, 좋은 실적과 좋은 관계를 바탕으로 매년 갱신하는 모델입니다. 그 모델은 여전히 통합니다. 그런데 그 밑에서 바뀐 것이 있습니다 — 이제 "일을 잘하는 것"만으로는 충분하지 않다는 점입니다. 모든 원청 업체는 이제 사이버보안 요구사항을 하도급 업체에게 전달해야 하고, 점점 더 많은 원청이 실제로 이를 확인하고 있습니다. 즉, 하도급 업체의 사람뿐 아니라 IT 환경 자체가 갱신 심사의 대상이 되었다는 뜻입니다.
무엇이 바뀌었나: CMMC는 더 이상 대형 원청만의 문제가 아닙니다
사이버보안 성숙도 모델 인증(CMMC) 프로그램이 생긴 이유는, 국방부가 반복적으로 민감 정보가 원청 자체가 아니라 길게 이어진 하도급 체인의 가장 약한 고리를 통해 새어나가는 걸 발견했기 때문입니다. 해법은 요구사항을 아래로 내려보내는 것이었습니다 — FCI(연방계약정보)를 다루는 모든 회사는 기본 보호조치(자가진단하는 CMMC Level 1)가 필요하고, CUI(통제 비분류 정보)를 다루는 모든 회사는 NIST SP 800-171에 맞춘 더 엄격한 통제(제3자 평가가 필요한 경우가 많은 CMMC Level 2)가 필요합니다. 작은 한인 하도급 업체에게 이 변화는 조용히 나타납니다 — 원청의 연례 벤더 설문지가 갑자기 없는 시스템 보안 계획서(SSP)를 요구하거나, 새 태스크 오더가 지금 환경으로는 감당할 수 없는 확인서를 요구합니다. 이것 때문에 하도급이 갱신되지 않았다고 아무도 말해주지 않습니다. 그냥 갱신이 안 되고, 그 이유는 사장님이 참여한 적 없는 컴플라이언스 심사 안에 묻혀 있습니다.
실제 하도급 업체 환경을 들여다보면 흔히 발견되는 것들
CMMC·NIST SP 800-171이 요구하는 것과 성장 중인 하도급 업체가 실제로 운영하는 방식 사이의 흔한 격차:
- 문서화된 시스템 보안 계획서(SSP)나 조치 계획 및 이정표(POA&M)가 없음 — 모든 평가가 시작되는 이 두 문서가, 지금까지 아무도 요구한 적이 없어서 아예 존재하지 않는 경우가 많습니다.
- CUI가 다른 모든 것과 섞여 있음 — 계약 결과물, 이메일, 일반 회사 파일이 실제로 통제된 방식으로 다뤄야 하는 데이터와 같은 공유 드라이브나 편지함에 있습니다.
- 전사적으로 다단계 인증(MFA)이 강제되지 않거나, 일부 시스템에는 있지만 정작 계약 데이터를 다루는 시스템에는 없습니다.
- 배정이 끝난 뒤에도 남아 있는 접근 권한 — 8개월 전에 그 계약에서 빠진 엔지니어가 그 계약의 공유 자료에 대한 접근 권한을 여전히 회수당하지 않았습니다.
- 실질적인 사고 대응 계획이 없음 — 노트북을 잃어버리거나 피싱 이메일을 클릭했을 때 문서화되고 리허설된 절차가 없는데, 이것 자체가 평가자들이 확인하는 구체적인 통제 항목입니다.
CMMC 준수 AWS 아키텍처에 실제로 포함되는 것
이건 인증서를 사는 게 아닙니다 — 저희를 포함해 어떤 업체도 CMMC 인증서를 판매하지 않습니다. 제대로 설계된 AWS 환경이 하는 일은, 시스템 보안 계획서가 문서화하고 Level 2 평가가 필요한 경우 공인 제3자 평가 기관(C3PAO)이 검증하는 기술적 통제를 실제로 갖추는 것입니다.
컴플라이언스에 맞춘 AWS 구성의 구체적인 요소들과, 각각이 뒷받침하는 통제:
- 데이터 분류와 경계 설계 — 어떤 인프라 결정을 내리기 전에 CUI, FCI, 제한 없는 회사 데이터를 먼저 식별하고 분리합니다. GovCloud가 정말 필요한지, 적절한 통제를 갖춘 상업용 AWS로 충분한지가 여기서 결정됩니다.
- CUI 워크로드를 위한 AWS GovCloud(US) — CUI가 실제로 대상에 포함될 때 DFARS 252.204-7012가 요구하는 FedRAMP Moderate 수준의 기준과 데이터 소재지 요건을 충족합니다.
- 필수 MFA와 최소 권한 원칙이 적용된 IAM — 모든 사용자의 접근 권한이 현재 맡은 계약 역할에 정확히 필요한 만큼으로 제한되고, 일정에 따라 검토되며, 역할이나 배정이 끝나면 즉시 회수됩니다.
- 저장·전송 시 암호화(KMS 관리형 키) — NIST SP 800-171 하에서 구체적으로 확인 가능한 통제 항목이지, 대충 넘어가는 일반적인 모범 사례가 아닙니다.
- CloudTrail 로깅과 중앙 모니터링 — 누가 무엇에 언제 접근했는지 감사 가능한 기록이며, 필수 통제이자 사고 대응 계획을 실제로 실행 가능하게 만드는 요소입니다.
- 문서화된 시스템 보안 계획서와 POA&M — AWS 아키텍처는 요구사항의 절반일 뿐입니다. 그걸 설명하고 최신 상태로 유지하는 문서가, 평가자가 실제로 가장 먼저 검토하는 것입니다.
컴플라이언스 언어와 사장님의 언어를 둘 다 하는 파트너가 필요한 이유
CMMC와 NIST SP 800-171 작업은 충분히 복잡해서 대부분의 하도급 업체가 합리적으로 외부 도움을 받습니다 — 문제는 그 도움이, 연방 컴플라이언스로 커리어를 쌓지 않은 사업주에게 특정 통제가 왜 중요한지 필요할 때 한국어로도 설명해줄 수 있느냐입니다. 큰 컴플라이언스 전문 업체는 통제 매트릭스와 청구서를 건네줄 뿐입니다. 애나데일이나 센터빌의 작은 한인 소유 업체에게 실제로 필요한 건, 마주 앉아서 지금 하고 있는 특정 계약에 CUI가 무엇을 의미하는지 쉬운 말로 설명해주고, 보고서만 던지고 사라지는 게 아니라 AWS 환경과 문서를 함께 만들어가는 사람인 경우가 많습니다. 저희는 이 일도 다른 모든 프로젝트와 똑같이 다룹니다 — 초기 데이터 분류 대화부터 지속 모니터링까지 한 명의 담당자가, 한국어든 영어든, 카카오톡으로 바로 연락 가능하게.
실제 진행은 어떻게 이뤄지나
저희는 데이터 분류와 갭 평가로 시작합니다 — 실제 계약들을 하나씩 살펴보며 어떤 데이터를 다루는지(FCI, CUI, 혹은 둘 다 아닌지) 파악한 뒤, 현재 환경을 NIST SP 800-171과 대조해 이미 갖춰진 것과 부족한 것을 가려냅니다. 여기서부터 가장 비싼 옵션을 기본값으로 삼는 대신 실제 대상 범위에 맞춰 아키텍처를 설계하고, 단계적으로 개선합니다 — 가장 위험한 격차를 가장 빨리 막아주고 데이터 이전이 필요 없는 접근 권한 관리와 MFA부터 시작해서, 암호화와 로깅으로 이어지고, 데이터 분류 결과 필요하다고 나오면 CUI 워크로드의 GovCloud 이전으로, 마지막으로 평가자가 실제로 읽게 될 시스템 보안 계획서와 POA&M 문서 작업으로 마무리합니다. 그 기간 내내 팀은 계속 일합니다 — 이건 주말 몰아치기 전환이 아니라 단계적 개선입니다. 구축이 끝나면 모니터링, 접근 권한 검토, 문서 갱신이 지속 서비스로 이어집니다. CMMC 준수는 일회성 프로젝트가 아니라 매년 다시 확인해야 하는 것이니까요.