혼자 일하는 개발자와 1인 사업자를 위한 사이버보안

혼자 일하는 프리랜서나 1인 사업자에게 보안 이야기를 꺼내면 대개 반응이 비슷하다. 당장 마감 맞추고 거래처 메일 답장하기도 바쁜데 거창한 보안 솔루션을 도입하거나 규정을 따로 만들 여유가 어디 있느냐는 거고, 사실 그 말이 맞기도 하지만 보안에 대해서 잘 모른다. 나도 OWASP 참고하지만 아는 게 얼마 없다.

그러는 와중에 이번에 사이버 보안 잘 하는 법에 대한 미국 백서가 나왔다.

미국 국립표준기술연구소(NIST)가 2026년 11월 2일에 펴낸 백서 NIST CSWP 50(Small Business Cybersecurity: Non-Employer Firms, 저자 Daniel Eliot·Jeffrey A. Marron·Savann Thorn)가 바로 그것이다.

미국 중소기업청(SBA) 통계를 보면 전체 소기업 3,480만 개 가운데 81.9%가 소유자 외에 유급 직원을 두지 않는 '무고용 사업체(non-employer firms)', 즉 1인 사업자와 프리랜서, 독립 계약자, 1인 유한책임회사(LLC), 긱 워커들이다(p.ii, 1).

사실 예전 보안 관련 문서를 찾아보면 2009년에 나온 NIST IR 7621과 2016년 개정판 IR 7621r1이 중소기업 정보보안 전반을 한데 묶어 다뤘는데, 2024년 의견 수렴과 IR 7621r2 초안을 거치면서 아예 문서 번호를 CSWP 50으로 바꾸고 IT 구성이 단순한 1인·무고용 사업자의 사이버보안으로 초점을 확 좁혔다(부록 C, p.27). 직원이 아주 적고 전산 환경이 단출한 소규모 팀에서도 그대로 가져다 쓸 만한 분량과 난이도다.

사실 개인 개발자의 코드보안 보다는 의식적 점검 위주의 체크리스트라 대부분의 개발자에게는 어쩌면 필요 없을 수 있지만 나도 시간 내서 읽어보았으니, 얼추 몇가지 적어본다.

• 원문 링크: 공식 PDF · DOI

무엇을 지킬 것인가

보안의 기본 목표라고 하면 흔히 기밀성(Confidentiality)·무결성(Integrity)·가용성(Availability) 세 단어를 꼽는다.

허가받지 않은 사람에게 자료가 새지 않게 막고, 데이터가 몰래 바뀌지 않게 지키며, 내가 써야 할 때 언제든 열어볼 수 있게 해 둔다는 뜻인데, 1인 사업장에서는 이 세 가지가 곧장 내일 일을 계속할 수 있느냐의 문제로 번역된다.

은행 계좌나 클라우드 저장소에 로그인이 안 되면 당장 업무가 멈추고(가용성), 설계 문서나 코드가 나도 모르게 바뀌어 있으면 납품 사고가 나며(무결성), 고객 정보가 유출되면 위약금과 평판 하락을 떠안게 된다(기밀성).

그렇다면 어디서부터 손을 대야 할까?

취약점 개수나 보안 프로그램 숫자부터 세기 시작하면 끝이 없다. 위험은 위협(Threat), 취약점(Vulnerability), 발생 가능성(Likelihood), 피해 규모(Impact)가 맞물려 돌아가는 결과라서, 똑같은 취약점이라도 거기에 어떤 자료와 거래가 걸려 있는지에 따라 우선순위가 전혀 달라진다

모든 사업장에 똑같이 대입할 산술 공식이 있는 게 아니니, 결국 잃거나 멈추면 내 업무에 가장 치명적인 자산이 무엇인지 추려내는 일이 첫걸음이 된다.

(원문 출처) NIST CSWP 50, Table 2, p.4 / PDF 8쪽. 위험을 구성하는 네 요소의 정의와 예시를 담은 원문 표다.

여기서 말하는 자산에는 고객 데이터, 소프트웨어, 이메일과 도메인 계정, 클라우드 서비스, 외주 공급자까지 내 사업이 돌아가는 데 기대고 있는 유무형의 요소가 모두 자산인데, 어떤 자료를 받아서 어디에 저장하고 누구에게 전송하는지, 누가 접근할 수 있고 기기들이 서로 어떻게 연결되어 있는지를 한 번쯤 체크할 것을 권고한다.

가능하면 개인용 기기·계정과 업무용 자산을 한데 섞어 쓰는 일도 이때부터 줄여 나가는 편이 낫다.(사실 그런면에서 나처럼 구글 gmail로 사업과 개인 사적인 계정을 함께 처리하는 사례가 좋지 않다고 할 수 있다)

위 그림은 NIST CSWP 50, Fig. 2, p.3 / PDF 7쪽에 실린 가상 1인 사업장의 연결 예시다. 이 그림은 기본적으로 혼자 일하는 조그만 사무실에서 주로 사용되는 장비들을 보여준다.

공유기와 모뎀 주변으로 데스크톱·노트북·휴대전화·무선 프린터·보안 카메라·외장 백업 드라이브가 물려 있고, 인터넷 건너편으로는 회사 웹사이트·온라인 뱅킹·소셜 미디어·이메일·회계 도구·AI 도구 같은 클라우드 서비스가 줄줄이 이어져 있다는 걸 눈으로 확인시켜 주는 그림이다. 공유기 기본 비밀번호가 출고 상태 그대로이거나, 문자·이메일로 날아온 피싱 링크 하나를 무심코 눌렀거나, 업데이트를 미룬 웹사이트 취약점 하나가 뚫리는 것만으로도 저 연결망 전체가 흔들릴 수 있다는 걸 보여준다.

그렇기떄문에 우선 이러한 연결망을 안전하게 유지하기 위해서, 기본적으로 아래로 정리할 것을 주문한다.

(원문 출처) NIST CSWP 50, Table 1, p.3 / PDF 7쪽. 직접 기입할 수 있게 빈 행을 둔 원문 양식이며, 각 열은 아래 항목에 대응한다.

• 하드웨어·소프트웨어 이름(시리얼 번호나 서비스 ID 등 식별 정보)

• 자산·계정 소유자

• 데이터 민감도 분류

• 위치(집 사무실, 모바일, 클라우드 등)

• 침해 시 예상 타격(심각, 보통, 경미)

• 강하고 고유한 비밀번호 설정 여부(Yes / No)

• 다중 인증(MFA) 활성화 여부(Yes / No)

• 계정 복구용 이메일 또는 전화번호

여기서 한 가지 꼭 짚고 넘어갈 점은, 비밀번호 칸에 Yes나 No로 설정 여부만 적어야지 실제 비밀번호 문자열을 자산 목록 파일에 적어 두어서는 절대 하면 안된다. 보안을 챙기겠다고 만든 엑셀 파일이 공격자에게는 보물지도가 되어 버리기 때문이다.

(사실 뭐 늘 그렇다. csv,xlsx로 한 곳에 저장하는 경향이 있는데, 보안에서 디지털 데이터로 암호를 저장하는 행위 자체에 대해서 어느정도 위험을 동반한다. 오히려 이 경우에는 사실 물리적 노트에 기록하는 편이 더 안전하다. 물론 그 물리적 노트도 잃어버릴 수 있지만, 대부분의 경우에 물리적 노트에 자기만 알아볼 수 있는 식으로 적어두는게 안전하다)

(원문 출처) NIST CSWP 50, Table 6, p.12 / PDF 16쪽. Identify 표의 첫 페이지로, 자산 목록뿐 아니라 사고 대응 계획과 자산 폐기, 개선 활동도 함께 다룬다.

(원문 출처) NIST CSWP 50, Table 6

그리고 여기에 자산 관리는 기기를 한창 쓸 때만 하는 일이 아니고, 오래된 PC나 외장 하드를 처분하거나 클라우드 서비스를 해지할 때 파일을 그냥 휴지통에 넣고 비우는 것만으로는 데이터가 매체에 그대로 남아 있으니, 운영체제의 디스크 초기화(전자적 완전 삭제)나 원격 삭제 기능을 써서 민감 정보를 완전히 지워야 하고, 클라우드 저장소에 남은 자료와 더 이상 쓰지 않는 온라인 계정도 찾아서 깔끔하게 닫아야 하는 것을 권장한다. 그러니까 중고 장터에 올리거나 팔때 장비에 대해서도 초기화가 필요하다는 것이다.

CSF 2.0의 여섯 기둥 예제

싸이버 시큐리티 코어, 그러니까 사이버 보안 핵심에서, NIST CSF 2.0이 제시하는 여섯 가지 핵심 기능(Functions)을 따라가며 빈칸을 메우는 식으로 점검해보자.

NIST CSWP 50, Fig. 4, p.9 / PDF 13쪽에 나오는 이 구조도는 큰 기능(Functions) 아래로 범주(Categories)와 세부 범주(Subcategories)가 가지를 치는 모양을 보여 준다.

분류 코드를 외울 필요는 없고, 각 기능이 내 사업에서 어떤 질문에 답하는지만 잡아 두면 충분하다.

(원문 번역)

(원문 출처) NIST CSWP 50, Table 3, p.9

기본적으로 6가지를 점검해서 하나하나 전부 체크해야하는데, 여기서 사실 개인 사업자로써의 관점을 볼때 '책임(Govern)'의 부분이 가장 중요하다. 1인 사업자는 뒤에서 방어해 줄 법무팀이나 IT 보안팀이 없다. 사고가 터지면 모든 법적, 재정적 책임은 대표인 나에게 고스란히 돌아온다. 애초에 기업들 의뢰는 나에게서 책임을 사가는 것이니까.

기본적으로 첫번째는 이 백서에서는 안나오지만 보안 사고는 반드시 터질 것이라는 감안 해서, 어떤 규제와 사고시 배상 책임과 보험에 대한 거버넌스 수립이 중요하다. 어차피 인간의 일이라는 것은 기본적으로 터질 것을 상정하는 게 편하다.

그렇기때문에 내 책임 요소를 줄이는 것이 중요하다. 최근의 보안의 기본 요소는 검증된 외부 솔루션에 위임해야하는 것이다.

기본적으로 OAuth를 구글, 깃허브와 같은 검증된 인증 서비스를 쓰는 게 안전하고, AWS, GCP 같은 대형 클라우드 보안 기능을 쓰는 게 홈 서버보다 안전한 것과 같은 이치다.(세계 최고의 수재들이 매번 업데이트 해주니까)

당장 내 손으로 잠그고 확인해야 할 다섯 가지

다만 그렇다고해도, 돈 안 들이고 오늘 바로 설정할 수 있는 실무 수칙들을 점검 할 수 있다..

(원문 출처) NIST CSWP 50, Table 4, p.10 / PDF 14쪽.

1. 계정은 피싱 저항성 MFA와 최소 권한부터 잠근다

MFA(다중 인증)를 지원하는 계정은 전부 켜는 게 원칙이지만, 당장 손이 모자란다면 이메일, 온라인 뱅킹, 민감한 파일 저장소, 비밀번호 관리자, 핵심 클라우드 서비스, 그리고 백업 데이터에 접근하는 계정부터 최우선으로 잠근다.

비밀번호 하나만 쓰는 계정은 공격자가 자동화 도구로 쉽게 뚫어낼 수 있어서, 알고 있는 것(비밀번호·PIN), 가지고 있는 것(스마트카드·보안 키), 생체 정보(지문·얼굴) 가운데 두 가지 이상을 묶어야 두 번째 벽이 생긴다. 원문은 그중에서도 피싱 사이트에 속아 넘어가도 인증이 뚫리지 않는 피싱 저항성 MFA를 강조하며, 아이디·비밀번호 입력 없이 지문이나 PIN과 결합해 로그인하는 패스키(passkey)를 널리 쓸 수 있는 대안으로 소개한다(p.2, 15).

(개인적으로 요즘 YubiKey와 같은 패스키를 사용해야하는 업체가 늘어나는 것에도 이게 크다고 생각한다)

비밀번호를 써야 하는 곳에는 비밀번호 관리자를 써서 계정마다 서로 다른 강한 패스프레이즈를 만들고, 입문 가이드 기준으로 최소 15자 이상의 길이를 권한다(p.2).

권한을 줄이는 습관(최소 권한 원칙, PR.AA-05)도 계정 보호와 함께 진행되어야 한다고 문서는 설명한다. 내 PC라고 해서 평소 웹 서핑이나 문서 작업까지 관리자(admin) 계정으로 하고 있으면 악성코드가 실행됐을 때 시스템 전체 권한을 그대로 넘겨주게 되니, 일상 업무는 표준 사용자 계정으로 처리해야 한다고 한다.

집에서 가족과 컴퓨터를 같이 쓴다면 가족용 계정을 따로 만들어 업무 폴더에 접근하지 못하게 막고, 외부 업체나 협업자에게 클라우드 접근 권한을 열어 줄 때도 필요한 작업과 기간만 한시적으로 허용한 뒤 주기적으로 권한 목록을 훑어본다. 사무실 공유기, 무선 프린터, 스마트 카메라 같은 IoT 장비에 붙어 나오는 제조사 기본 관리자 비밀번호를 바꾸고 대장에 기록해 두는 것도 잊기 쉬운 기본기다(PR.AA-01, p.14).

((원문 출처) NIST CSWP 50, Table 7, p.14 / PDF 18쪽. 앞서 설명한 계정·권한 관리에 더해 업데이트와 교육까지 묶은 Protect 표의 첫 페이지다.)

즉 개인 사업자는 사적 공간과 공적인 장비를 따로 구분하고, 계정의 권한을 따로 두라는 것이다. 물론 나는 그렇게까진 하지 않았다.(애초에 나는 털릴 게 없다. 솔루션 납품 업자니까.)

2. 백업은 '있느냐'가 아니라 '살아 돌아오느냐'를 본다

하드웨어가 고장 나거나 랜섬웨어에 걸렸을 때 기댈 곳은 결국 백업뿐이다(PR.DS-11, p.15). 중요한 자료는 정기적으로 여러 사본을 떠 두되, 최소 한 벌은 외장 하드 드라이브나 분리된 클라우드처럼 평소 작업 기기와 상시 연결되지 않은 매체에 격리해 두어야 본체가 감염됐을 때 백업까지 나란히 암호화되는 참사를 피할 수 있다.

클라우드 서비스를 쓰고 있다면 그 업체가 자체적으로 어떤 백업 정책과 복구 옵션을 제공하는지도 미리 알아두어야 하고, 무엇보다 주기적으로 백업 파일을 실제로 복원해 볼 것을 추천한다. 그래야 실제 동작하는 지 알 수 있으니까.

사고가 난 뒤 백업을 되돌리는 복구 단계(RC.RP.01, p.20)에서도 순서가 중요하다. 백업 파일 자체가 오염되지 않았는지 무결성을 먼저 확인하고, 파일만 예전 상태로 덮어쓴 채 공격자가 파 놓은 뒷문을 그대로 두면 곧바로 재감염되므로 계정의 MFA 설정, 추가된 사용자 계정, 파일 공유 범위, 살아 있는 활성 세션이메일 자동 전달(포워딩) 규칙까지 싹 점검하는 것을 추천한다.

(원문 출처) NIST CSWP 50, Table 7 계속, p.15 / PDF 19쪽. 백업과 MFA에 관한 나머지 행이며, 바로 아래의 MFA·패스키 설명 상자도 함께 담았다.

즉 백업 테스트는 자주 실행하고, 데이터는 가급적 자주 백업하는 것이 좋다는 것이다.

3. 피싱과 랜섬웨어는 '급하다'는 말에서 한 박자 멈춘다

랜섬웨어가 사업장으로 들어오는 가장 흔한 통로가 피싱이라고 말하는데, 요즘은 생성형 AI(원문 표기로는 SI 트럼프 행정부에서 AI를 SI로 표기하자고 한 것을 충실히 지키고 있나본데, 대체 무슨 행정 낭비인지 모르겠다.)를 동원해 문맥과 말투까지 그럴듯하게 꾸민 피싱 이메일·문자·소셜 미디어 메시지가 날아온다는 것을 가정해야한다고 말한다, 공격자들의 공통된 수법은 생각할 틈을 주지 않고 당장 행동하게 재촉한다는 점이다. 링크를 누르라거나 첨부 파일을 열라고 독촉하고, 거래처나 은행 이름을 빌려 송금 계좌번호·청구서 정보·라우팅 번호가 바뀌었으니 급히 처리해 달라고 몰아붙인다.

이럴 때는 아무리 아는 사람이나 거래처에서 온 메시지처럼 보여도 일단 손을 멈추고 발신자 이메일 주소(공식 도메인 대신 무료 상용 메일을 쓰지 않았는지)를 살핀 뒤, 메시지 안에 적힌 전화번호나 답장 주소가 아니라 내가 원래 가지고 있던 연락처나 공식 번호로 직접 연락해 사실 여부를 확인해야 한다.

랜섬웨어 방어 역시 백신 하나나 백업 하나만 믿고 끝낼 수 있는 문제가 아니다. 로컬 파일과 네트워크뿐 아니라 클라우드 계정과 SaaS 데이터까지 암호화·협박 대상이 되기 때문에, 정기 업데이트(PR.PS-02), 백신의 상시 감시와 이메일 첨부·이동식 드라이브 자동 검사, 허가된 프로그램만 실행되도록 운영체제 제한 걸기, 비밀번호 무차별 대입을 막는 로그인 지연·계정 잠금 설정, 알려진 악성 도메인·IP·포트 차단과 도메인 무결성 보호, 그리고 격리된 백업과 비상 연락망이 한 세트로 돌아가야 한다.

실제로 이러한 공격은 내 홈페이지에도 자주 온다. 여기에 개인적으로 덧붙이자면 기본적으로 회사 공적 이메일과 연동하는 것이 좋다. 나의 경우 해외 에이전시 요청이 가끔 오는데, 이때 gmail로 오는 것들은 pdf에 스크립트를 포함한 사기 요청이 꽤 있다. 기본적으로 사업의 가장 기본 요건은 공적 이메일이고, 상대의 공적 이메일을 신뢰할 수 있는지가 중요하다.

그런면에서 아직도 gmail로 모든 것을 처리하고 있는 내 자신에 대해서 모순을 느끼긴한다. 도메인을 구매한 후 구글 Gsuite를 가입하는 것은 보안 문서에 없는 내 팁이다. 왜냐하면 구글의 스팸 필터와 보안은 세계 최고 수준이라 실제 사기꾼 메일을 생각보다 잘 걸러주기때문이다. 어쨌건 반성하고 기존에 사둔 도메인을 활성화 시킬 생각이다.

4. 탐지는 거창한 것이 아니다.

이상 징후를 잡아내는 일(DE.CM, p.18)이라고 하면 흔히 대기업의 24시간 보안 관제 화면을 떠올리지만, 1인 사업장에서는 백신을 켜 두고 각 서비스가 기본 제공하는 로그 기록과 알림 기능을 빠짐없이 켜는 것만으로도 훌륭한 출발점이 된다라고 설명한다.

새로운 기기에서의 로그인 시도 알림, 비밀번호 재설정 알림, 은행·결제 거래 알림, 그리고 내 도메인 레코드가 바뀌었을 때 날아오는 알림을 켜 두면 누군가 내 계정을 건드리는 순간 바로 알아차릴 수 있다.

사이버보안이 인터넷선 안에만 갇혀 있는 것도 아니다(DE.CM-02, p.18). 집, 카페, 공유 오피스, 이동 중인 차량 등 내가 노트북을 펴고 일하는 물리적 공간마다 도난이나 엿보기 위험이 다르다. 서류함을 잠그고 기기를 안전하게 보관하는 것부터 자리 비울 때 화면 자동 잠금 걸기, 기기를 잃어버렸을 때 위치를 추적하고 원격으로 데이터를 밀어버리는(remote wipe) 기능을 미리 켜 두는 것까지 모두 탐지와 보호의 일부다.

(원문 출처) NIST CSWP 50, Table 8, p.18 / PDF 22쪽.

5. 사고 연락망은 종이에 적어 두고, 사고가 터졌을때 격리한다.

막상 침해 사고가 터지면 머리가 하얘지고, 설상가상으로 업무용 PC나 클라우드 계정이 잠겨 버리면 그 안에 적어 둔 비상 연락처조차 열어볼 수 없다. 그래서 수사기관, 법률 자문, 사고 대응 전문가, 주요 거래처와 보험사 등을 묶은 비상 연락망과 사고 대응 계획은 평소에 미리 만들어 종이 인쇄본이나 오프라인 사본으로 따로 보관해 두어야 한다(ID.IM-04, p.12).

실제 사고를 발견했을 때는 처음 인지한 시각과 증상, 보안 로그, 화면 캡처, 그때까지 취한 조치를 꼼꼼히 기록하고 계획에 적힌 전문가에게 연락한다(RS.MA-01, p.19). 피해가 더 번지지 않게 막는 봉쇄·격리 조치(RS.MI-01, p.19)로는 네트워크 선 뽑기(와이파이 끊기), 감염된 기기·시스템 분리, 로그인 세션 강제 취소가 기본이며, 침해가 의심되는 기기나 계정은 복구 작업에 절대 다시 쓰지 않는다.

여기서 개인적으로 보안 문서가 잘 못된 지점이 있다 생각하는게, 표에 기록(RS.MA-01)과 연락(RS.CO)이 격리(RS.MI-01)보다 위 칸에 적혀 있기에 독자는 이것을 순서대로 진행한다라고 착각할 수 있는데,

랜섬웨어가 한창 파일을 잠그고 있는데 기록 다 적고 전화 다 돌릴 때까지 랜선을 꽂아 두라는 뜻으로 오인 될 수 있다. 확산이 의심되는 상황에서는 필요한 네트워크 분리부터 지체 없이 실행해야한다. 어디까지 끊을지와 후속 조치를 대응 계획 및 전문가 지원과 연결해야 한다(추가 확인: CISA 랜섬웨어 가이드, Part 2). 시스템이 멈춘 동안 수작업이나 임시 서비스, 예비 연락 채널로 급한 불을 끌 업무 지속 방안도 미리 생각해 두고, 사태가 수습된 뒤에는 사고 원인과 대응 과정, 배운 교훈을 사후 보고서(after-action report)로 남겨 다음 계획에 반영한다(RC.RP-06, p.19-20).

(원문 출처) NIST CSWP 50, Table 9, p.19 / PDF 23쪽.

(원문 출처) NIST CSWP 50, Table 10, p.20 / PDF 24쪽. 백업과 계정 상태를 확인한 뒤 업무를 복구하고, 관계자에게 알리며 교훈을 남기는 활동이다. 원문의 추가 대응·복구 자료 안내도 함께 보존했다.

외주, 클라우드, 보험, 그리고 AI 도구를 쓸 때 놓치기 쉬운 것

1인 사업자일수록 회계, 웹사이트 호스팅, 클라우드 저장소, 심지어 보안 관리 자체를 외부 업체나 SaaS에 맡기는 비중이 높다.

원문은 외주 업체를 고를 때 "내가 이 서비스로 얻으려는 보안 결과가 무엇인지"부터 명확히 적은 뒤, 여러 업체의 평판과 소기업 지원 경험을 비교하고, 계약서(MSA 등)에 서비스 수준과 양쪽의 역할·책임·기대치를 또렷이 문서화하라고 조언한다(p.5-6, GV.SC p.11). 무엇보다 중요한 문장은 "보안 업무를 외부 공급자에게 외주 주더라도 내 시스템과 데이터를 지킬 최종 책임(accountability and responsibility)까지 넘어가는 것은 아니다"라는 대목이다(p.6). 공급자의 보안·개인정보 설정과 계약 조건도 한 번 맺고 끝내지 말고 주기적으로 다시 봐야할 것이다.

사이버 배상 책임 보험(GV.RM, p.11)도 비슷하다. 사고가 났을 때 재정적 타격을 덜어 주고 보험사 쪽 보안 전문가 지원을 받을 수 있어 도움이 되지만, 보험 증권이 보안 대책을 대신해 주지는 않는다. 계약상 보험 가입이 필요한지 따져 보고, 가입했다면 보장 요건·면책 사유·보상 한도·보험 효력을 유지하기 위해 내가 지켜야 할 최소 보안 통제 기준을 따로 적어 둔다. 특히 사업을 하다 업무 영역이 넓어지거나 다루는 자산·공급자가 바뀌어 위험도가 달라졌다면 보험사에 그 변경 사항을 알려야 나중에 약관 문제로 낭패를 보지 않는다(Table 5, p.11; 구체적인 통지 의무와 보상 범위는 해당 약관과 적용 법령을 따른다).

(원문 출처) NIST CSWP 50, Table 5, p.11 / PDF 15쪽. 법적·계약상 요구사항, 보험, 외부 공급자에 관한 Govern 활동이며 개인적으로 가장 중요하다고 봤다.

요즘 1인 사업자와 개발자들이 손발처럼 쓰는 생성형 AI 도구에 대해서도 1.9절(p.7)이 별도 항목으로 다룬다. 흥미롭게도 원문 제목은 AI가 아니라 Super Intelligence (SI)라고 적혀 있는데, 이름은 거창해졌지만 본문이 다루는 알맹이는 우리가 매일 쓰는 코드 작성·업무 자동화·콘텐츠 생성·고객 응대용 AI 도구들의 실무 보안 수칙이다

• 내가 쓰고 있는 AI 제품·서비스는 물론이고, 기존 소프트웨어 안에 기본 탑재되거나 연동된 AI 기능까지 전부 목록으로 파악해 검토·설정·비활성화 여부를 정한다.

• 영업비밀, 전략 문서, 건강정보, 소스 코드, 법률 문서 같은 민감한 자료를 프롬프트에 넣기 전에 그 도구의 데이터 보관 기간, 모델 학습 이용 여부, 접근 권한, 기밀 유지 약관을 먼저 확인한다.

• AI가 만들어 준 코드나 문서는 고객·파트너에게 건네거나 중요한 의사결정에 쓰기 전에 반드시 사람이 직접 검토하는 절차를 둔다.

• 내가 쓰는 외부 벤더들이 내부적으로 AI를 어떻게 쓰고 있는지, 특히 벤더 쪽 AI 시스템이 내 업무 시스템이나 데이터에 어디까지 접근하는지도 파악한다.

여기에 더해 1.8절(p.6-7, Fig. 3)은 보안 사고가 한 건도 나지 않아도 개인정보(프라이버시) 위험은 따로 생길 수 있다는 점을 이야기한다.

해커에게 털리지 않았더라도 고객이 애초에 예상했던 목적과 다르게 개인정보를 쓰거나, 원래 목적이 끝났는데도 데이터를 지우지 않고 몇 년씩 쌓아 두는 것만으로 프라이버시 침해가 된다는 뜻이다. 그래서 어떤 개인정보를 수집해 어디에 쓰고 누구와 공유하며 어떻게 보관하다가 언제 폐기하는지 데이터 수명주기 전체의 흐름을 그려 두고, 기기와 앱의 프라이버시 설정도 그에 맞추어야 한다는 것이다.

일단 기본적으로 한국쪽보다 미국 법 조항이 더 까다롭기때문에 이 경우에는 미국쪽 개인정보 보안 점검을 따르는 게 옳다고 보인다.

프리랜서 개발자의 작업 노트로 옮겨 적으면

원문은 변호사, 홈 공방 전자상거래 판매자, 글로벌 마케팅 컨설턴트 세 가지 가상 사례를 별도 엑셀 부록에 담아 두었는데,

이 원칙들을 1인 소프트웨어 개발자·프리랜서 환경에 그대로 대입해 보면 아래 여덟 줄짜리 점검 리스트로 할 수 있다.

처음 시작할 때는 욕심내지 말고 핵심 자산·계정 목록부터 적은 뒤, 주요 계정의 MFA·복구 수단·권한을 잠그고, 백업 복원 시험 한 번과 오프라인 연락망 한 장을 만드는 데서 출발하면 된다. 원드라이브나 구글 드라이브 동기화 폴더를 켜 둔 것만으로 랜섬웨어에 안전한 독립 백업이 있다고 믿거나, 에이전트 설정 파일(AGENT.md 또는 CLAUDE.md)에 "민감 파일 읽지 마라"고 한 줄 적어 둔 것만으로 실제 파일시스템·네트워크 권한이 격리됐다고 착각하지만 않으면 절반은 먹고 들어간다. 중요한 것은 실제 격리 인 것이다.

다만, 개인적으로 너무 이상적으로 생각하는 시나리오라는 생각도 든다. 실제로 정확하게 말해서 유출되도 내가 책임을 크게 지는 부분만 따로 격리시키는 게 맞다. 모든 자료를 격리 시킨다는 것은 사실 일을 할때마다 격리 하는 부분을 따로 체크해야한다는 건데 실상 1인 개발자는 거의 불가능하다.

실제로 이렇게 미국에서 발표한 개인 사업자를 위한 체크리스트를 봤다.

어느정도는 관료주의적으로 안전한 것만 적혀있고, 대부분의 실무자에게 어느정도 유용한 것도 있지만, 이상적이고 불편한 것들도 있다. 사실 보안은 불편한데서 시작하니까 당연한 것이기도 하다. 물론 일부는 도움되는 지점도 있었다. 기본적으로 내가 안다고 해서 실천하는 것은 아니니까, 실천하는 도구로써는 꽤 유용한 백서임이 틀림없다.