독립 개발자로서 이미 여러분에게 적용되고 있는 보안 의무 사항

독립 개발자들 사이에는 보안 및 개인정보보호 규제가 기업에게만 해당되는 것이라는 뿌리 깊은 믿음이 존재합니다 — 즉, 법인을 설립하거나 DPO를 채용하거나 엔터프라이즈 계약을 체결할 때 비로소 의무가 시작된다는 생각입니다. 이는 사실이 아니며, 수년 전부터 사실이 아니었습니다. 만약 여러분이 프리랜서 또는 인디 개발자로서 클라이언트 데이터를 다루고 있다면, 여러 의무가 이미 오늘 이 순간, 현재의 규모 그대로, 여러분 개인에게 적용되고 있습니다. 이 글에서는 그러한 의무가 무엇인지, 어떤 규정에서 비롯되는지 살펴보고, 마지막으로 정말 중요한 실질적인 질문으로 마무리합니다: 지금 여러분의 계정에는 구체적으로 무엇이 노출되어 있습니까?

이 글이 다루지 않는 한 가지는, 어떤 법률이 보안 도구 구매를 의무화한다고 말하는 것입니다. 그런 법률은 없습니다. 법이 실제로 요구하는 것은 여러분이 처리하는 데이터로 무엇을 하고 있는지 파악하고 이를 적절히 보호하는 것이며, 이를 위한 정직한 출발점은 클라이언트 업무가 존재하는 계정에 어떤 접근 권한이 있는지 파악하는 것입니다.

GDPR 하에서, 클라이언트 데이터를 처리하는 프리랜서는 처리자이며 — 직접적인 의무를 집니다

EU 내 클라이언트(또는 사용자가 EU에 있는 클라이언트)가 여러분에게 개인정보를 넘긴다면 — 마이그레이션할 사용자 데이터베이스, 디버깅할 프로덕션 시스템, 분석할 익스포트 파일 등 — 여러분은 거의 항상 GDPR 상의 개인정보처리자(data processor)로서 행동하고 있는 것이며, 일부 업무(무엇을, 왜 수집할지 여러분이 결정하는 경우)에서는 개인정보관리자(controller)로서 행동합니다. 어느 지위든 회사 설립을 요구하지 않습니다. GDPR 제4조의 정의는 "자연인 또는 법인"에 적용되며 — 노트북을 가진 개인도 이에 해당합니다.

이러한 지위에는 직접적이고 개인적인 의무가 따릅니다:

• 제28조는 클라이언트를 위한 처리 업무가 계약에 의해 규율되어야 함을 요구합니다 — 여러분의 엔터프라이즈 클라이언트가 계속 보내오는 데이터 처리 계약(DPA)은 관료적 형식이 아니라, 양측 모두에게 부과되는 법적 요구사항이며, 이는 여러분을 특정 보안 약속에 구속시킵니다.
• 제32조는 여러분이 처리하는 개인정보를 보호하기 위해 "적절한 기술적·조직적 조치"를 이행할 것을 요구합니다 — 이는 위험 수준에 상응해야 하며, 누가, 무엇이 해당 데이터에 접근할 수 있는지 통제하는 것을 포함합니다.
• 제33조는 처리자가 개인정보 침해를 인지한 후 "부당한 지연 없이" 관리자에게 통지할 것을 요구합니다 — 이는 여러분이 침해 사실을 인지할 수 있는 위치에 있어야 함을 전제로 합니다.
• 제82조는 규정을 위반한 처리로 인한 피해에 대해 정보주체가 처리자로부터 보상받을 권리를 부여하며, 제83조는 가장 심각한 위반의 경우 2천만 유로 또는 전 세계 연간 매출액의 4% 중 더 높은 금액에 이를 수 있는 행정 과징금으로 이 체계 전체를 뒷받침합니다.

어느 감독 당국이 프리랜서를 상대로 취하는 첫 조치가 법정 최고액이 될 것이라고 주장하려는 것은 아닙니다. 요점은 더 단순합니다: 이러한 의무는 실제로 존재하며, 여러분에게 직접 적용되고, "나는 그저 한 사람일 뿐이다"라는 사실은 규정 문언 어디에도 인정된 예외 사유로 규정되어 있지 않다는 것입니다.

EU AI Act는 AI 시스템 배포자(deployer)에게 의무를 추가합니다

만약 여러분의 클라이언트 업무에 이제 AI를 제품에 연동하는 작업이 포함된다면 — 클라이언트 앱 내 어시스턴트, 워크플로를 자동화하는 AI 에이전트, 사람들에게 영향을 미치는 의사결정을 내리는 모델 등 — EU AI Act가 여러분과 관련이 있습니다. 이 법은 모델을 훈련하는 기업만을 규율하는 것이 아니라, 자신의 권한 하에 전문적 맥락에서 AI 시스템을 사용하는 자, 즉 배포자(deployer)에게도 의무를 부과합니다.

제26조는 고위험 AI 시스템에 대한 배포자 의무를 규정하며, 여기에는 시스템을 그 지침에 따라 사용하는 것, 적절한 인적 감독을 보장하는 것, 운영을 모니터링하는 것이 포함됩니다. 제4조는 제공자와 배포자 모두에게 자신을 대신하여 이러한 시스템을 운용하는 사람들이 충분한 수준의 AI 리터러시를 갖추도록 보장할 것을 요구합니다. 그리고 제99조는 미준수에 대한 행정 과징금으로 이 체계를 뒷받침합니다. 특정 업무에 어떤 의무가 적용되는지는 시스템이 무엇을 하는지, 그리고 어떤 위험 범주에 속하는지에 따라 달라집니다 — 하지만 "나는 그저 통합만 했을 뿐, 만든 것이 아니다"라는 상황이야말로 배포자 범주가 정확히 상정하는 역할입니다.

여기에는 AI 에이전트 거버넌스에서 저희가 지속적으로 목격하는 실질적인 아이러니가 있습니다: 독립 개발자들은 AI 코딩 에이전트와 자동화 봇을 가장 활발하게 도입하는 사람들이면서, 동시에 그러한 에이전트가 무엇에 접근할 수 있는지에 대한 목록을 갖추고 있을 가능성이 가장 낮은 사람들이기도 합니다. AI 에이전트가 여러분이 소유한 모든 저장소에 푸시할 수 있다면, 이는 어떤 규제 당국이 이를 묻든 묻지 않든 여러분의 보안 태세에 관한 사실입니다.

여러분의 엔터프라이즈 클라이언트는 이미 규제 대상이며 — 그 의무는 여러분에게로 흘러 내려옵니다

EU 개인정보를 전혀 다루지 않고 AI 시스템을 전혀 배포하지 않더라도, 규모를 막론하고 기업과 협업하는 거의 모든 프리랜서에게 적용되는 보안 의무의 세 번째 원천이 있습니다: 바로 계약입니다. 엔터프라이즈 클라이언트는 SOC 2 보고서, ISO 27001 인증, GDPR 제28조 처리자 요건, 그리고 감사인이 실제로 점검하는 벤더 관리 프로그램 하에서 운영됩니다. 이러한 프로그램은 500명 규모의 벤더와 1인 벤더를 구분하지 않습니다. 벤더는 벤더입니다.

이것이 바로 계약서보다 보안 설문지가 먼저 도착하는 이유입니다. 여러분의 클라이언트는 자신들의 프레임워크, 감사인, 또는 자신들의 고객으로부터 요구받아, 데이터를 넘기는 상대방으로부터 보안 증거를 수집해야 합니다. 여러분도 예외가 아닙니다. 신뢰할 수 있게 답변할 수 있는 프리랜서들 — "제 개발 환경에 무엇이 접근 권한을 가지고 있는지, 이를 어떻게 통제하는지, 그리고 그 증거가 여기 있습니다"라고 말할 수 있는 이들 — 은 즉흥적으로 대응하는 이들보다 더 빠르게 계약을 성사시킵니다. 저희는 이 역학의 조직 측 버전에 대해 2026년 감사인이 AI 거버넌스에 요구하는 것에서 다룬 바 있습니다; 벤더 측 버전은 설문지의 형태로 여러분의 책상에 도착합니다.

침해 사고가 독립 개발자에게 실제로 초래하는 비용

이는 위험을 있는 그대로 정직하게 짚어보는 것입니다: 클라이언트 프로젝트에서 발생한 보안 사고는 계약의 배상 조항에 따른 직접적인 재정적 책임을 의미할 수 있고, 개인정보가 관련되었을 경우 GDPR 제82조에 따른 처리자 책임을 의미할 수 있으며 — 프리랜서에게 가장 구체적으로는 — 클라이언트 관계의 종료와 그에 따른 레퍼런스의 상실을 의미할 수 있습니다. 1인 컨설팅에게 있어 평판이라는 자산은 곧 사업 그 자체입니다. 이 중 어느 것도 가상의 극단적 사례가 아닙니다; 유출된 자격 증명이나 과도한 권한을 가진 통합이 클라이언트 데이터 침해 사고로 이어지는 것은 지극히 일상적인 결과의 연쇄입니다.

그렇다면 지금 여러분의 계정에는 실제로 무엇이 노출되어 있습니까?

다소 불편하지만 구체적인 질문을 던져보겠습니다. 여러분의 클라이언트 업무는 거의 확실히 개인 GitHub 계정에 존재합니다. 그 계정에는 수년간의 프로젝트를 거치며 다음과 같은 것들이 쌓여 있습니다:

• 설치된 GitHub 앱 — 배포 봇, CI 도구, AI 어시스턴트 등 — 각각이 여러분이 한 번 승인한 후 아마도 재검토한 적 없는 권한 부여를 보유하고 있습니다. 일부는 여러분이 소유한 모든 것에 대해 쓰기 또는 관리자 권한을 가지고 있습니다. 일부는 2024년에 종료된 프로젝트에 속한 것들입니다.
• 배포 키(Deploy keys) — 서버에 방치된 무인 SSH 자격 증명으로, 일부는 읽기 전용으로만 설계된 저장소에 쓰기 권한을 가지고 있습니다. 해당 서버가 침해될 경우, 읽기-쓰기 배포 키는 클라이언트 제품으로의 코드 주입 경로가 됩니다.
• 협업자(Collaborators) — 이미 종료된 협업 과정에서 추가했지만 여전히 쓰기 권한을 보유하고 있는 사람들, 심지어 공개 저장소에서도 마찬가지입니다.
• 저장소 노출 — 어떤 저장소가 공개되어 있고 그 안에 무엇이 담겨 있는지는, 대부분의 개발자가 기억만으로는 답할 수 없는 재고 파악의 문제입니다.

이 모든 것은 GitHub 자체의 API를 통해 기계가 읽을 수 있는 형태로 존재하며, 이는 곧 모두 확인 가능하다는 의미입니다 — 기억에 의존하는 것이 아니라, 오늘 현재 실제로 접근 권한을 보유하고 있는 것을 낱낱이 열거함으로써 말입니다. 바로 그 재고 파악을 이제 8200.dev의 GitHub 커넥터가 조직뿐만 아니라 개인 계정에 대해서도 생성해 드립니다: 여러분 자신의 GitHub 로그인을 연결하면, 스캔이 설치된 앱과 그 권한 부여, 배포 키와 각각의 읽기 전용 여부, 저장소별 협업자, 그리고 그 관계도에서 드러나는 발견 사항 — 관리자 권한을 가진 채 잊힌 봇, 쓰기 권한이 있는 배포 키, 1년 넘게 아무도 손대지 않은 오래된 앱 — 을 나열해 드립니다.

무료 개인 티어는 전체 스캔을 실행하고 가장 심각한 발견 사항을 보여드립니다; 유료 개인 티어 — 엔터프라이즈 소프트웨어가 아니라 코드 완성 구독처럼 책정된 가격으로 — 는 지속적인 모니터링과 알림 기능과 함께 전체 목록을 제공합니다. 그리고 여러분이 성장하여 조직 계정을 가진 에이전시가 되더라도, 동일한 스캔, 동일한 규칙, 동일한 증거 추적이 여러분과 함께 확장됩니다 — 이것이 제품의 조직 버전이며, 동일한 커넥터입니다.

위에서 언급한 의무들은 여러분이 스캔을 실행하든 하지 않든 적용됩니다. 스캔이 바꾸는 것은 그러한 의무가 함축하는 질문들 — 무엇이 접근 권한을 가지고 있는지, 왜 가지고 있는지, 정당화할 수 없는 접근에 대해 무엇을 했는지 — 에 답할 수 있는지 여부입니다. 무료 티어부터 시작해서, 여러분의 계정에 조용히 쌓여온 것이 무엇인지 확인하고, 거기서부터 결정하십시오 — 가격 정책은 공개되어 있으며, 셀프서비스 방식이고, 0원부터 시작합니다.

*이 글은 독립 개발자에게 일반적으로 적용되는 규정에 대한 일반 정보이며, 법률 자문이 아닙니다. 각 규정이 여러분의 구체적인 상황에 어떻게 적용되는지는 스캐너가 알 수 없는 사실관계에 따라 달라집니다. 이에 대해서는 변호사와 상담하십시오.*