10110010011101001011001101101110101018200.devFrom Enterprise.Systems

독립 개발자 및 프리랜서

이미 귀하에게 적용되는 보안 의무

고객 데이터를 다루는 프리랜서 또는 독립 개발자라면, 규모가 작다는 이유로 보안 규제에서 벗어날 수 없습니다. GDPR상의 처리자 의무, EU AI Act상의 배포자 의무, 그리고 고객의 계약상 보안 요구사항은 모두 지금, 현재의 규모 그대로 귀하에게 직접 적용됩니다. 규정별로 명시하여 이미 적용되는 사항과 귀하 본인의 계정에서 현재 노출된 사항을 아래에 정리합니다.

이미 귀하에게 적용되는 사항

GDPR: 귀하는 개인적으로 데이터 처리자입니다

고객이 귀하에게 개인 데이터 — 사용자 데이터베이스, 프로덕션 시스템, 내보내기 파일 — 를 넘길 때, 귀하는 GDPR상의 데이터 처리자(때로는 관리자)로서 행동하는 것입니다. 이 지위는 회사를 요구하지 않으며, “자연인 또는 법인”에 부여됩니다. 이에 따라 귀하는 계약에 근거하여 처리하고, 보유한 데이터에 적절한 보안 조치를 시행하며, 침해 발생 시 부당한 지연 없이 고객에게 통지할 의무가 있습니다. 또한 이는 배상 청구와 행정 과징금의 대상이 됩니다.

근거: GDPR 제4조(정의), 제28조(계약에 따른 처리), 제32조(처리의 보안), 제33조(침해 통지), 제82~83조(책임 및 최대 2천만 유로 또는 연간 전 세계 매출의 4% 중 더 높은 금액의 행정 과징금).

EU AI Act: 고객을 위한 AI 배포에는 의무가 따릅니다

고객 업무에 AI 시스템을 프로덕션에 투입하는 작업 — 고객 제품 내 어시스턴트, 워크플로를 자동화하는 AI 에이전트 — 이 포함된다면, EU AI Act는 배포자에게 의무를 부과합니다. 배포자란 전문적 맥락에서 자신의 권한 하에 AI 시스템을 사용하는 자를 말합니다. 어떤 의무가 적용되는지는 시스템의 위험 등급에 따라 달라지지만, “저는 통합만 했을 뿐입니다”라는 역할이 바로 배포자 범주가 다루는 것입니다.

근거: EU AI Act 제26조(고위험 AI 시스템 배포자의 의무), 제4조(AI 리터러시), 제99조(벌칙).

귀하의 기업 고객은 귀하로부터 보안 증빙을 수집해야 합니다

SOC 2, ISO 27001 또는 GDPR 제28조에 따라 운영하는 기업들은 감사자가 실제로 확인하는 공급업체 관리 프로그램을 운영하며, 이러한 프로그램은 500명 규모의 공급업체와 1인 공급업체를 구분하지 않습니다. 그래서 계약보다 보안 설문지가 먼저 도착하는 것입니다. 증빙으로 답할 수 있는 프리랜서는 즉흥적으로 대응하는 프리랜서보다 더 빨리 계약을 성사시킵니다.

근거: 계약상 — 데이터 처리 계약 및 고객이 데이터를 넘기는 모든 대상(개인 포함)에게 부과할 의무가 있는 공급업체 보안 요구사항.

침해된 고객 프로젝트는 실제 비즈니스 리스크입니다

고객 프로젝트의 보안 사고는 계약의 면책 조항에 따른 직접 책임을 의미할 수 있고, 개인 데이터가 관련된 경우 GDPR 제82조에 따른 처리자 책임을 의미할 수 있으며, 고객과 그에 따른 추천 기회를 잃는 것을 의미할 수 있습니다. 1인 사업에서 평판이라는 자산은 곧 사업 그 자체입니다. 이는 확정이 아닌 리스크이지만, 잊혀진 자격 증명이 사고로 이어질 때 발생하는 일반적인 결과의 연쇄입니다.

근거: GDPR 제82조(배상 청구권); 귀하 자신의 서비스 계약.

현재 귀하의 계정에서 노출된 사항

위의 모든 의무는 동일한 첫 질문을 내포합니다. 귀하의 고객 업무가 존재하는 곳에 무엇이 접근할 수 있는가? 대부분의 독립 개발자에게 그곳은 개인 GitHub 계정이며, 수년간 접근 권한이 누적되어 왔습니다. 다음 사항은 모두 GitHub 자체 API에서 기계 판독이 가능합니다:

설치된 GitHub App

배포 봇, CI 도구, AI 어시스턴트 — 각각 귀하가 한 번 승인한 권한 부여를 보유하고 있습니다. 일부는 귀하가 소유한 모든 것에 대한 쓰기 또는 관리 권한을 보유하고, 일부는 오래전 종료된 프로젝트에 속해 있습니다.

배포 키

서버에 방치된 SSH 자격 증명입니다. 읽기만 필요했던 저장소에 있는 읽기-쓰기 키는 해당 서버가 침해될 경우 코드 삽입 경로가 됩니다.

협업자

이미 종료된 협업 과정에서 추가되었으나 여전히 쓰기 권한을 보유한 사람들 — 공개 저장소도 포함됩니다.

공개 저장소

어떤 저장소가 공개 상태이고 누가 푸시할 수 있는지는 대부분의 개발자가 기억만으로는 답할 수 없는 인벤토리 문제입니다.

프로젝트보다 오래 남는 AI 공급업체 키

사이드 프로젝트를 뒷받침하는 OpenAI, Anthropic, Mistral 또는 Cursor 계정에는 프로젝트가 끝난 뒤에도 오랫동안 API 키와 시트가 쌓입니다. 8200.dev의 AI 거버넌스 뷰는 오래된 키와 조직 전체 키, 역할 변경 이후에도 남아 있는 키, 아무도 사용하지 않는 시트를 공급업체 자체 관리자 API에서 읽기 전용으로 표시합니다.

먼저 확인하고, 그다음 결정하십시오

개인 GitHub 계정을 읽기 전용으로 연결하고 인벤토리를 받아 보십시오. 설치된 모든 앱과 해당 권한, 모든 배포 키와 읽기 전용 여부, 모든 협업자, 모든 공개 저장소를 심각도 순으로 정렬된 결과와 함께 확인할 수 있습니다. 무료 등급에서는 상위 3개 결과를 전체적으로 보여드립니다. 스캔을 실행하도록 요구하는 법률은 없으며, 위의 의무는 어느 쪽이든 동일하게 적용됩니다. 스캔이 바꾸는 것은 그러한 의무가 함의하는 질문에 답할 수 있는지 여부입니다.

읽기 전용 범위. 소스 코드는 절대 수집하지 않습니다. 신용카드 불필요.

이 페이지는 독립 개발자와 프리랜서에게 일반적으로 적용되는 규정에 관한 일반 정보이며, 법률 자문이 아닙니다. 각 규정이 귀하의 특정 상황에 어떻게 적용되는지는 귀하에게 고유한 사실관계에 따라 달라집니다. 이에 대해서는 변호사와 상담하십시오.