이제 1인 기업은 20명 규모의 팀처럼 제품을 출시합니다. 이것이 바로 이 문제가 존재하는 근본적인 이유입니다. 당신은 조달 프로세스(procurement process)를 갖출 만큼 규모가 큰 기업들을 대상으로 영업하고 있는데, 그 기업들의 인원수는 과거라면 당신이 협상 테이블에 앉을 수도 없었을 수준입니다. 그래서 설문지가 도착하고, 그 안에는 SOC 2 항목이 포함되어 있으며, 당신이 읽게 되는 모든 통제 항목(control)은 당신에게 없는 팀이 있다는 것을 전제로 합니다.

저는 Deloitte에서 5년 동안 미국과 캐나다 전역의 기술 기업들을 대상으로 SOC 2 감사를 수행했습니다. LinkedIn, Affirm, Ripple과 같은 기업들을 포함하여 30개 이상의 기업을 담당했습니다.

그 모든 현장 실사 과정에서 저는 "인원이 너무 적음"이 감사 실패 사유로 기록된 것을 단 한 번도 본 적이 없습니다. 제가 본 것은 대기업의 통제 언어를 소규모 기업에 맞게 번역하는 법을 배우지 못한 감사자들이었습니다. 그래서 그들은 불필요한 업무를 만들어내거나, 존재할 필요가 없는 지적 사항(finding)을 작성하곤 했습니다.

따라서 여기 유용한 관점의 질문이 있습니다. "통과할 수 있을까?"가 아니라, "회사가 한 명의 개인과 에이전트(agent)로 구성되어 있을 때 감사인이 실제로 무엇을 확인하는가?"입니다.

변경 관리 (Change management): 저는 당신의 브랜치 보호(branch protection) 설정을 확인합니다

모두가 실패할 것이라고 가정하는 통제 항목입니다. 대기업의 가이드라인은 모든 변경 사항이 배포되기 전에 두 번째 엔지니어가 검토해야 한다고 말합니다. 하지만 당신은 자신의 코드를 직접 머지(merge)합니다.

하지만 이제는 상황이 조금 다릅니다. 당신의 에이전트가 변경 사항을 작성하고 당신이 이를 검토합니다. 이것이 당신에게 무엇을 제공하고 무엇을 제공하지 못하는지에 대해 솔직해질 필요가 있습니다. 이것은 직무 분리(separation of duties)를 만들어내지는 못합니다. 왜냐하면 에이전트가 당신의 지시와 당신의 자격 증명(credentials) 하에 실행되기 때문에, 감사인은 당신과 에이전트를 하나의 주체(principal)로 간주하기 때문입니다. 하지만 이것이 제공하는 가치는 기록을 남기는 실제적인 검토(review)이며, 이는 1인 개발자가 직접 작성한 코드를 스스로 머지하던 시절보다 훨씬 나은 수준입니다.

제가 확인하는 것은 커밋(commit)부터 프로덕션(production)까지의 경로가 제한되고 기록되는지 여부입니다. 기본 브랜치(default branch)에 대한 브랜치 보호(Branch protection). 반드시 통과해야 하는 필수 상태 체크(Required status checks). 자동으로 실행되는 테스트. 그리고 아무도 수동으로 입력하지 않은, 무엇이 언제 배포되었는지 보여주는 배포 이력(deploy history)입니다.

자동화된 통제(automated control)가 잘 설계되어 기록을 남긴다면, 두 번째 검토자(second reviewer)를 대신할 수 있습니다. 이것은 허점이 아니라 보완 통제(compensating control)이며, 보호 조치가 실질적이고 추적 경로(trail)가 존재하는 한 작업 문서(working papers)에서도 유효하게 인정됩니다.

오늘 확인해야 할 한 가지: 만약 당신의 에이전트(agent)가 리포지토리(repo)에 대한 푸시(push) 권한을 가지고 있다면, 당신이 그 출력물을 읽었는지 여부보다 해당 에이전트가 기본 브랜치(default branch)에 접근할 수 있는지 여부가 더 중요합니다. 대부분의 사람들은 이를 확인해 본 적이 없습니다.

직무 분리 (Separation of duties): 사후에 당신을 잡아내는 것을 찾습니다

역할을 나눌 수는 없으며, 에이전트를 추가한다고 해서 역할이 분리되는 것도 아닙니다. 따라서 질문은 잘못된 변경이 발생한 후 무엇이 이를 잡아낼 수 있는가로 옮겨갑니다.

이것은 중요성이 줄어든 것이 아니라 오히려 더 커졌습니다. 에이전트는 많은 변경 사항을 빠르게 실행하며, 잘못된 명령 하나가 미치는 영향 범위(blast radius)는 사람이 모든 명령을 직접 입력했을 때보다 훨씬 넓습니다. 중요한 통제는 당신 없이도 작동하는 통제입니다.

이력을 유지하는 어딘가에 게시되는 배포 알림(deploy notifications). 활성화되고 보관되는 클라우드 감사 로그(Cloud audit logs). 그리고 실제로 피해를 줄 수 있는 사항들에 대한 알림: 새로운 IAM 주체(principal), 전 세계에 개방된 보안 그룹(security group), 배포 외 시간에 접근한 운영 데이터베이스(production database). 그리고 정기적으로 수행하고 기록으로 남기는 셀프 리뷰(self-review)입니다.

기준은 리스크를 줄이는 것에 있습니다. 머릿수를 세는 것이 아닙니다. 한 사람이 하나의 계정을 검토하더라도, 그것이 기록되고 날짜가 기입되어 있다면 유효한 검토입니다.

액세스 검토 (Access review): 아무도 가지고 있지 않은 단 하나의 산출물

당신은 유일한 관리자(admin)입니다. 하지만 실제로는 그렇지 않으며, 이 부분이 조용히 변화해 온 지점입니다.

당신의 에이전트는 자격 증명(credentials)을 가지고 있습니다. 당신의 MCP 서버는 토큰(tokens)을 보유하고 있습니다. 당신의 CI는 배포 키(deploy key)를 가지고 있습니다. 이들 각각은 당신의 시스템에 상시 접근 권한을 가진 주체(principal)이며, 제품을 출시하는 동안 하나씩 추가되었기 때문에 거의 아무도 이들을 검토한 적이 없습니다. 비인간 정체성(Non-human identities)은 현재 액세스 검토의 핵심이며, 대부분의 1인 설정(solo setups)에는 사람보다 더 많은 비인간 정체성이 존재합니다.

해당 통제 항목(control)은 정해진 일정에 따라 귀하가 직접 수행하는 서면 검토이며, 무엇이 존재하는지 명시하고 그것이 존재해야 하는 상태인지 확인하는 과정입니다. 프로덕션 액세스(production access) 권한이 있는 계정들을 나열하세요. 귀하의 에이전트(agent)와 CI(지속적 통합)가 보유한 토큰(token)들과 각 토큰이 접근할 수 있는 범위를 나열하세요. 고객 데이터를 보유한 SaaS 도구들을 나열하세요. 각 도구가 현재 보유한 권한이 여전히 필요한지 확인하세요. 날짜를 기입하세요. 그리고 저장하세요.

자기 자신에게 메모를 쓰는 것이 황당하게 느껴질 수 있습니다. 그래도 작성하세요. 분기당 15분만 투자하면, 단순히 존재하는 통제 항목과 귀하가 신뢰할 수 있는 통제 항목 사이의 차이를 만들 수 있습니다.

제공되는 모든 곳에 MFA(다요소 인증)를 적용한 SSO(단일 로그인)를 사용하고, 하드웨어 키나 비밀번호 관리자(password manager)를 사용하세요. 그것들이 바로 통제 항목(controls)입니다. 검토(review)는 이러한 항목들이 제대로 작동하고 있다는 증거입니다.

벤더(Vendors): 보고서를 수집하는 것이지, 프로그램을 운영하는 것이 아닙니다

대기업의 가이드라인은 벤더 리스크 프로그램(vendor risk program)과 연례 재평가를 수행하는 조달 팀이 있다는 것을 전제로 합니다. 귀하는 클라우드 제공업체, 수십 개의 SaaS 도구, 그리고 이제는 모델 제공업체(model provider)를 가지고 있습니다.

마지막 항목은 새로운 것이며 창업자들이 놓치기 쉽습니다. 만약 고객 데이터가 모델 제공업체에 도달한다면, 그들은 다른 벤더와 마찬가지로 귀하의 범위(scope) 내에 있는 벤더입니다. 클라우드 제공업체의 보고서를 수집하는 것과 동일한 방식으로 그들의 보고서를 수집하세요.

업무는 구축하는 것이 아니라 읽는 것입니다. 귀하의 클라우드 제공업체는 감사인들이 하위 서비스 조직(subservice organization)이라고 부르는 대상이며, 이는 귀하 보안의 일부가 실제로 그들의 시스템 내에 존재함을 의미합니다. 귀하는 그들의 SOC 2 보고서를 수집합니다. 귀하가 AWS를 감사하는 것이 아닙니다. 고객 데이터에 접촉하는 벤더 목록을 짧게 유지하고, 귀하 보안의 어느 부분이 각 벤더에 의존하는지 기록하며, 그들의 최신 보고서를 보유하세요.

배경 조사(Background checks): 모집단이 0명이라도 여전히 모집단입니다

직원이 없다는 것은 검사할 대상이 없다는 뜻입니다. 그것은 결함(gap)이 아니라 빈 모집단(empty population)이며, 모집단이 없는 상태로 기록됩니다.

에이전트(agent)는 직원이 아니므로 배경 조사를 받지 않습니다. 에이전트는 액세스(access) 권한을 가지므로, HR(인사) 항목이 아닌 액세스 통제(access control) 항목에 포함됩니다. 이 둘을 명확히 구분하면 감사(audit)의 HR 섹션은 약 10분 정도면 끝납니다.

이 구분은 첫 번째 계약직(contractor)을 고용할 때부터 중요해집니다. 그때부터 통제(control) 항목은 서명된 계약서와 더불어, 권한을 부여하고 업무가 종료되었을 때 이를 회수하기 위해 따르는 절차로 구성됩니다. 이 절차를 필요로 하기 전에 미리 문서화해 두십시오. 나중에 처리하려고 하면 사소한 일이 감사 지적 사항(finding)으로 변하게 됩니다.

실제로 사람들을 당황하게 만드는 부분

거의 대부분의 경우 통제(control) 자체가 문제는 아닙니다. 현대적인 인프라를 사용하는 1인 창업자들은 보통 생각보다 더 나은 보안 수준을 갖추고 있습니다. 기본 설정(defaults)이 개선되었고, 레거시 확산(legacy sprawl)이 없기 때문입니다.

문제는 증거(evidence)입니다. 누군가가 3주 전에 찍은 스크린샷은 이미 지나간 순간의 기록일 뿐입니다. 실제 통제 상태가 무엇인지 보여주는 것은 라이브 시스템에서 직접 추출한 설정(configuration)입니다. 이 두 가지 사이의 간극이 첫 감사(audit)에서 고통이 발생하는 지점입니다.

여기 좋은 소식이 있습니다. 이는 여러분이 20명 규모의 팀처럼 빠르게 제품을 출시할 수 있는 이유와도 같습니다. 증거를 추적하는 작업이 고통스러웠던 이유는 이를 수행하는 사람이 주의력(attention)이라는 속도 제한(rate limit)에 걸려 있었기 때문입니다. 하지만 여러분의 에이전트(agent)는 그렇지 않습니다. 에이전트는 이미 여러분의 클라우드, ID 제공자(identity provider), 그리고 리포지토리(repo)에 접근 권한을 가지고 있으며, 사진을 찍는 대신 현재 상태(current state)를 직접 가져올 수 있습니다. 과거에 엔지니어링 시간 한 달을 잡아먹던 작업이 바로 에이전트가 가장 잘하는 작업입니다.

주의할 점은, 에이전트를 방치하면 증거처럼 보이지만 검사 과정에서 무너져 내리는 결과물을 가져다줄 수 있다는 것입니다. 아무도 따르지 않는 정책, 통제가 주장하는 바를 증명하지 못하는 설정, 잘못된 기간을 다루는 로그 등이 그 예입니다. 에이전트는 무엇이 유효한지를 알아야 하며, 이는 접근 권한을 갖는 것과는 다른 문제입니다.

딱 한 가지 습관만 바꾸십시오. 스크린샷을 생각하는 것을 멈추고 내보내기(export)를 생각하기 시작하십시오.

Type I부터 시작하기

Type I은 특정 시점에 통제(control)가 올바르게 설계되었는지(designed)를 테스트합니다. Type II는 통제가 일정 기간(보통 3개월에서 12개월) 동안 실제로 운영되었는지(operated)를 테스트합니다.

먼저 Type I을 획득하세요. 범위가 작고, 기다려야 하는 관찰 기간(observation window)이 없으며, 잠재 고객에게 즉시 제시할 수 있는 결과물을 제공합니다. 대부분의 엔터프라이즈 구매자들은 Type I을 먼저 받고, 이후 Type II가 뒤따르는 방식을 수용합니다. 설계를 올바르게 한 다음, 그것이 유지되었음을 증명하세요.

이번 주에 활성화해야 할 사항

다른 것은 하지 않더라도, 다음 사항들은 반드시 수행하세요:

• 기본 브랜치(default branch)에 대한 브랜치 보호(Branch protection) 설정 (필수 체크 항목 설정 및 강제 푸시(force-push) 비활성화 포함)
• 에이전트, MCP 서버 및 CI가 보유한 모든 토큰(token)의 목록과 각 토큰이 접근할 수 있는 범위에 대한 인벤토리 작성
• MFA(다요소 인증)를 지원하는 모든 계정에 MFA 적용, 가능한 경우 SSO(단일 로그인) 적용
• 클라우드 감사 로깅(Cloud audit logging) 활성화 및 감사 대상 기간 이후까지 로그 보관
• 배포 알림(Deploy notifications)이 이력이 남는 곳으로 전송되도록 설정
• 사람과 비인간(non-humans) 모두를 포함하여, 본인이 직접 작성한 날짜가 기입된 액세스 검토(access review)
• 보안의 기반이 되는 벤더들(모델 제공업체 포함)의 최신 SOC 2 보고서 확보

이것이 1인 기업을 위한 보안 전용 범위(Security-only scope)의 대부분입니다. 보안(Security)은 유일한 필수 카테고리입니다. 나머지 네 가지는 선택 사항이며, 계약상 진정으로 필요할 때만 추가하면 됩니다.

AICPA가 소규모 조직을 어떻게 다루는지와 적정 규모화(right-sizing)가 실제로 허용되는 범위를 포함하여, 표준 근거에 대한 더 자세한 내용은 다음을 참조하세요: Can a solo founder pass SOC 2?

실제 질문이 무엇인지 확인하고 싶다면, 제가 테스트에 사용하는 방법론을 통제 항목별로 공개해 두었습니다: github.com/Chiaro-HQ/methodology

출처

• 신뢰 서비스 기준 (Trust Services Criteria)은 기준 (criterion) 수준에서 평가됩니다. 중점 사항 (Points of focus)은 요구 사항이 아닌 예시 가이드라인입니다 (개정된 중점 사항이 포함된 2017 TSC, 2022).
• AICPA 가이드라인은 규모가 작고 구조가 덜 복잡한 조직이 공식적인 구조 대신 소유주의 능동적인 감독을 통해 기준을 충족할 수 있도록 허용합니다.
• AT-C 205에 따라, 질문 (inquiry)만으로는 결코 충분하지 않습니다. 실무자 (practitioner)는 반드시 검사 (inspect), 관찰 (observe) 또는 재수행 (reperform)해야 합니다.
• 1인 창업자 (Solo founders)가 시작한 신규 스타트업은 2019년 23.7%에서 증가하여 2025년 상반기에는 36.3%를 기록했습니다. 미국 기업의 약 82%는 직원이 없습니다.