법, 라이선스, 개인정보

이 장은 한국 법령을 기준으로 한 일반 안내입니다. 법률 자문이 아니에요. 실제 사고나 분쟁 상황이 생기면 변호사 상담을 받으세요.

1. 코드는 잘 짰는데 사업이 멈추는 이유

앞의 세 장(01-1, 01-2, 01-3)에서 사고가 날 만한 자리를 짚을 때마다, 항목 끝에 "법적 위험 한 줄" 을 같이 적어두었습니다. "이건 개인정보보호법 위반으로 이어진다", "이건 안전성 확보조치 의무 위반이다" 같은 한 문장들이요. 이 장은 그 한 줄들을 자세히 풀어쓰는 자리입니다.

그리고 한 가지가 더 있습니다. 앞에서 다룬 사고는 코드 안의 구멍이었는데, 코드를 아무리 안전하게 짜도 법을 모르고 한 행동 한 번에 사업이 통째로 멈출 수 있습니다. 저작권, 라이선스, 약관, 결제 처리 같은 자리입니다.

바이브 코딩으로 만든 사이트를 친구들과만 쓴다면 큰 문제는 없습니다. 그런데 외부에서 단 한 명이라도 가입하는 순간, 다음 세 영역의 법이 동시에 작동하기 시작합니다.

세 가지 모두 "몰라서 그랬어요"가 면책 사유가 되지 않습니다. 그래서 이 장은 길지 않게, 바이브 코더가 가장 자주 걸려 넘어지는 함정만 골라 짚어드리겠습니다.

2. 정보통신망법

코드를 아무리 잘 짜도 사고는 납니다. 정보통신망법 제48조의3은 정보통신서비스 제공자에게 침해사고가 발생하면 즉시 과학기술정보통신부장관이나 한국인터넷진흥원(KISA)에 신고하도록 정하고 있습니다.

"침해사고"는 범위가 넓습니다. 해킹, 악성코드 감염, DDoS, 시스템 마비 같은 사건이 모두 들어갑니다. 그리고 정보통신서비스 제공자는 우리가 흔히 떠올리는 통신사만이 아닙니다. 웹사이트나 앱으로 외부 사용자에게 서비스를 제공하는 곳은 대부분 여기 해당합니다. 토이 프로젝트라도 외부 가입을 받고 있다면 적용 대상이라고 보는 게 안전해요.

여기서 한 가지 자주 헷갈리는 자리가 있습니다. 사고에 개인정보 유출이 같이 있었다면, 뒤에서 다루는 개인정보보호법 신고(제34조)와는 별건으로 둘 다 챙겨야 합니다. 신고처도, 시한도, 양식도 다릅니다.

사고 종류	신고처	시한	근거
해킹, 악성코드, DDoS 같은 침해사고	KISA, 과기정통부	즉시	정보통신망법 제48조의3
회원 개인정보 유출	개인정보보호위원회, 정보주체	72시간 이내	개인정보보호법 제34조

해킹으로 회원 정보까지 새어 나갔다면 두 신고를 모두 해야 하고, 한쪽만 했다고 다른 쪽이 면제되지 않습니다. 신고를 늦추거나 누락하면 그 자체가 추가 과태료 사유입니다.

3. 개인정보보호법

"회원이 100명도 안 되니까 우리한텐 적용 안 되겠지." 틀렸습니다. 한국 개인정보보호법은 사업자 규모와 무관하게 적용됩니다. 무료 서비스든, 토이 프로젝트든, 단 한 명의 사용자 정보라도 받는 순간 사업자가 됩니다.

3.1 개인정보의 범위는 생각보다 넓습니다

이름, 이메일, 전화번호처럼 직관적인 것 외에도 다음이 모두 개인정보로 취급될 수 있는 가능성이 있습니다. 핵심은 둘 이상을 합쳐서 "이 사람이 누구인지 알아낼 수 있는 조합"이 되는지입니다.

IP 주소
쿠키 식별자
회원 ID
위치 정보
사진(얼굴이 식별 가능한 경우)

"닉네임만 받으니까 괜찮아요"라고 해도, 그 닉네임에 가입일과 IP가 같이 붙어 있으면 그 사람이 누구인지 추적이 가능해서 개인정보로 봅니다.

3.2 최소한 갖춰야 하는 것

상용이든 베타든 외부에 공개해 운영한다면 법적으로 반드시 게시해야 하는 항목들입니다. 빠뜨리면 과태료 대상입니다.

개인정보 처리방침 (Privacy Policy) - 어떤 정보를 왜, 얼마나 보관하는지 적은 글
이용약관 (Terms of Service)
수집과 이용 동의 절차 - 회원가입 시 체크박스.
만 14세 미만 가입 시 법정대리인 동의 절차 - 13살까지는 부모 동의 필요
개인정보 보호책임자(DPO) - 1인 개발자라면 본인을 지정해 사이트에 명시

개인정보 처리방침의 표준 양식은 개인정보보호위원회 공식 사이트(www.pipc.go.kr)에서 무료로 받을 수 있습니다. AI에게 처음부터 짜달라고 시키지 마세요. 법적 양식이 매년 조금씩 바뀌고 빠뜨리면 안 되는 항목이 있어서, 공식 양식을 가져와 채우는 게 안전합니다.

3.3 회원이 탈퇴하면 진짜로 지워야 합니다

사용자가 탈퇴하면 그 사용자의 정보는 파기해야 합니다. (개인정보보호법 제21조)

"백업본은요?", "통계용으로 익명화해서 남겨도 될까요?"는 모두 별도로 동의를 받아야 합니다. 동의 없이 통계용으로 남기는 것도 위법이에요.

토이 프로젝트라도 회원 탈퇴 기능을 만들었다면, 그 기능이 정말로 데이터를 지우는지 한 번 확인하세요. AI가 만들어준 코드에서 is_deleted = true만 찍고 끝나는 패턴이 자주 보입니다. 그건 파기가 아니라 숨기기일 뿐입니다.

이 점검은 AI에게 시키는 게 가장 빠릅니다.

이 프로젝트의 회원 탈퇴(또는 사용자 삭제) 기능을 찾아줘.
다음을 점검해줘.

1. 실제로 DB에서 사용자 정보를 DELETE 하는지, 아니면 is_deleted 같은 플래그만 바꾸는지
2. 그 사용자가 남긴 글, 댓글, 업로드 파일도 함께 처리되는지
3. 백업 테이블, 로그, 통계 테이블에 사본이 남는지

파기가 아닌 자리는 "숨기기 처리"라고 표시하고, 진짜로 지우는 코드로 바꾸는 수정안을 같이 제안해줘.

예외 - 다른 법령이 보존을 명령하는 경우

"무조건 즉시 다 지워야 한다"는 아닙니다. 같은 제21조는 다른 법령에 따라 보존해야 하는 경우에는 그러하지 아니하다고 단서를 두고 있습니다. 대표적인 게 전자상거래법입니다. 결제·환불이 오가는 쇼핑몰이라면 시행령 제6조가 다음 기록을 일정 기간 의무 보존하도록 정하고 있어서, 회원이 탈퇴했다고 이런 정보까지 즉시 파기하면 오히려 다른 법을 어기게 됩니다.

보존 대상 기록	보존 기간
계약 또는 청약철회 등에 관한 기록	5년
대금결제 및 재화 등의 공급에 관한 기록	5년
소비자의 불만 또는 분쟁처리에 관한 기록	3년

단, 이렇게 남기는 정보는 딱 그 법이 요구하는 항목만, 그 기간만 보존해야 하고, 운영 중인 회원 테이블과 섞어두면 안 됩니다. 별도 DB나 분리된 테이블로 옮겨 "보존용"으로만 두는 게 원칙이에요. "혹시 몰라서 일단 다 남겨두자"는 이 예외에 해당하지 않습니다.

3.4 사고가 나면 72시간

개인정보가 유출되면 72시간 안에 개인정보보호위원회와 정보주체에게 통지해야 합니다. (제34조)

해킹이나 악성코드 같은 침해사고가 함께 일어났다면 앞에서 본 정보통신망법 즉시 신고도 별건으로 같이 해야 합니다. 두 신고는 신고처와 시한이 다르고, 한쪽만 했다고 다른 쪽이 면제되지 않습니다.

"몇 명 안 되니까 그냥 넘어가자"는 그 자체로 추가 위법입니다. 사고가 났으면 늦더라도 신고하는 쪽이 항상 안전해요.

해외 사용자도 받을 거라면 GDPR

서비스가 한국에서만 굴러간다면 위 한국 법령만 챙기면 됩니다. 그런데 EU 거주자가 한 명이라도 가입할 수 있는 구조라면 그 순간 GDPR(EU 일반 개인정보보호법)이 같이 따라옵니다. 영어 페이지 한 장만 있어도 적용 대상으로 봅니다.

가장 자주 걸리는 자리는 트래커 동의입니다. 구글 애널리틱스, Meta Pixel, Hotjar, Mixpanel 같은 분석·광고 도구는 페이지 로드와 동시에 쿠키를 넣는데, GDPR은 이걸 사용자가 "동의"를 누르기 전까지는 켜지 말 것을 요구합니다. 흔히 보는 "이 사이트는 쿠키를 사용합니다" 한 줄짜리 배너로는 부족하고, 필수와 선택을 구분해서 거절 버튼도 같은 자리에 둬야 합니다.

GDPR은 위반 시 전 세계 매출의 4% 또는 2천만 유로 중 큰 금액까지 과징금이 나옵니다. 토이 프로젝트 규모라도 실제 제재 사례가 늘고 있어서, 해외 노출을 염두에 두는 순간 처음부터 같이 설계하는 게 안전합니다.

4. 저작권

바이브 코더가 가장 자주 걸리는 저작권 사고가 여기 있습니다. "이 사이트 디자인 좋네, AI에게 비슷하게 만들어달라 해야지" 하고 다른 회사 페이지를 그대로 따라 만드는 자리예요. 디자인이나 콘텐츠가 마음에 들면 그대로 가져오기 쉽거든요.

자주 걸리는 행동들입니다.

콘텐츠 그대로 복사: 다른 사이트의 글, 사진, 동영상, 일러스트를 그대로 가져다 쓰면 저작권법 위반입니다. 출처를 표시해도 무단 복제는 면책되지 않아요.
HTML/CSS 코드 통째로 가져오기: 개발자 도구로 코드를 그대로 뽑아 쓰는 것도 저작권법 위반에 해당합니다. 비슷하게 보이는 화면을 직접 다시 짜는 것과는 다른 행동이에요.
로고나 브랜드 이름 비슷하게 만들기: 로고는 저작권과 상표권으로 이중 보호됩니다. 픽셀 단위로 비슷하게만 만들어도 상표법 위반 여지가 있어요.
AI에게 "이 사이트랑 똑같이 만들어줘": AI는 명령대로 짜줍니다. 그런데 결과물에 대한 책임은 시킨 사람에게 남아요.

영감과 모방의 경계가 실무에서 헷갈리는데, 다음이 기준입니다.

영감(OK): 색감이나 분위기 참고, 일반적인 레이아웃(헤더-히어로-카드그리드-푸터), 같은 종류의 기능(로그인 폼, 결제 흐름 등)을 갖추는 것
모방(위법 영역): 픽셀 단위로 똑같은 디자인, 같은 사진·일러스트·카피라이팅, 코드를 그대로 복사한 것

같은 업계라면 상대방이 우리 사이트를 발견하는 데 오래 걸리지 않습니다.

5. 오픈소스 라이선스

앞 절이 "남의 것을 몰래 베끼는" 사고였다면, 이번엔 정반대입니다. 누구나 가져다 쓰라고 공개해 둔 코드인데도, 붙어 있는 조건을 안 지키면 위반이 되는 자리예요. 바이브 코딩은 npm·pip 패키지를 수십 개씩 끌어오고 AI가 추천한 라이브러리를 그대로 붙입니다. 그 하나하나에 "이렇게 쓰면 된다"는 라이선스가 달려 있는데, 대부분 읽지 않고 넘어가죠.

라이선스는 크게 두 부류로 나뉩니다.

카피레프트(copyleft) 라이선스 - GPL, AGPL: "가져다 쓰는 건 좋은데, 너도 똑같이 공개해라"가 조건입니다. 바로 여기서 사업이 멈출 수 있습니다.

라이선스	부류	상업적 사용	소스 공개 의무
MIT	관대	가능	없음 (고지문 유지)
Apache 2.0	관대	가능	없음 (고지문·변경표시 유지, 특허 조항 포함)
GPL	카피레프트	가능	배포할 때 공개
AGPL	카피레프트	가능	네트워크로 제공만 해도 공개

바이브 코더가 모르고 밟는 지뢰 - AGPL

GPL은 보통 코드를 배포(distribution)할 때 공개 의무가 생깁니다. 그런데 웹 서비스는 코드를 사용자에게 나눠 주는 게 아니라 서버에서 돌려 화면만 보여주죠. 그래서 GPL 코드를 SaaS에 써도 공개 의무를 피해 가는 "구멍"이 있었습니다.

AGPL은 바로 그 구멍을 막은 라이선스예요. 네트워크 너머로 서비스만 제공해도 — 즉 그냥 웹사이트에 올려 두기만 해도 — 수정한 소스 전체를 사용자가 받아 갈 수 있게 공개해야 합니다. 멋진 AGPL 라이브러리 하나를 깔아 서비스에 엮었다면, 내 코드 전체가 공개 대상이 될 수 있다는 뜻입니다. 그래서 많은 회사가 아예 "AGPL 의존성은 법무 검토 없이 금지"로 못 박아 둡니다.

라이선스를 섞을 때 기억할 원칙이 하나 더 있습니다. 합치면 가장 빡빡한 쪽을 따라갑니다. MIT 코드에 GPL 코드를 한 조각 엮으면 결과물 전체가 GPL이 돼요.

이것도 사람이 일일이 확인하기 어려우니 AI에게 시키는 게 빠릅니다.

이 프로젝트의 의존성(package.json / requirements.txt 등)을 전부 훑어서 각 라이브러리의 라이선스를 정리해줘.

1. GPL, AGPL 같은 카피레프트 라이선스가 있으면 따로 표시
2. 특히 AGPL이 있으면 "소스 공개 의무 위험"이라고 강조
3. MIT, Apache처럼 고지문을 남겨야 하는 라이브러리 목록과, 지금 프로젝트에 그 고지가 빠져 있지는 않은지

상업적으로 서비스할 때 문제가 될 만한 항목을 위험도 순으로 정리해줘.

6. AI 기본법

2026년 1월, 한국은 인공지능 기본법(정식 명칭: 인공지능 발전과 신뢰 기반 조성 등에 관한 기본법)을 시행했습니다. EU에 이어 세계에서 손꼽히게 빠른 포괄 AI 법이에요. 바이브 코더가 만든 서비스에 AI가 들어가는 일이 점점 많아지니, 이 법도 한 번은 짚어야 합니다.

다행히 무거운 의무는 대부분 고영향(high-impact) AI에 걸립니다. 보건·의료, 채용·인사 평가, 금융 신용 판단, 교통·에너지 같은 핵심 인프라, 수사·재판 지원처럼 사람의 삶을 크게 좌우하는 분야예요. 토이 프로젝트로 이런 걸 만들 일은 드뭅니다. 다만 이 분야를 건드린다면 영향평가·안전성·투명성 같은 별도 책무가 생기니, 그땐 반드시 전문가 상담이 필요합니다.

대신 규모와 무관하게, 생성형 AI를 쓰는 거의 모든 서비스에 걸리는 의무가 하나 있습니다.

AI가 만든 결과물은 "AI가 만들었다"고 표시해야 합니다

챗봇이 쓴 글, AI가 생성한 이미지·영상·음성을 사용자에게 내보낸다면, 그것이 사람이 아니라 AI의 결과물임을 알 수 있게 표시(워터마크 등)해야 합니다. 특히 진짜 사람처럼 보이는 딥페이크 영상에는 처음부터 끝까지 'AI 생성물' 표식을 붙여야 하고, 어기면 과태료 대상입니다.

바이브 코딩으로 "AI가 답해 주는 상담 봇", "프로필 이미지를 AI로 만들어 주는 기능" 같은 걸 붙였다면 이미 해당될 수 있습니다. "AI가 생성한 내용입니다" 한 줄, 생성 이미지에 표식 하나를 처음부터 같이 설계해 두세요.

시행 초기에는 계도·유예 기간이 운영되지만, "아직 단속 안 하니까"는 안전한 태도가 아닙니다. 표시 의무처럼 손이 거의 안 드는 건 처음부터 지켜 두는 쪽이 항상 낫습니다. 해외 사용자가 있다면 EU AI Act도 함께 봐야 하는데(GDPR과 같은 결이에요), 핵심 감각은 똑같습니다 — AI가 한 일은 AI가 했다고 밝혀라.

7. 사고가 났을 때의 순서

위에서 다 막았어도 사고는 납니다. 사고가 났을 때 순서가 사고 자체보다 더 중요합니다.

특히 2번을 지키세요. 로그를 섣불리 지우지 마세요. "지저분하니까 정리하자"고 서버 로그를 날리면 나중에 사고 원인을 추적할 때 아무것도 못 합니다. 법적으로도 "은폐 시도"로 해석될 수 있어요.

3번과 5번은 신고 대상이 다른 별건의 의무라는 점도 기억해 두세요. 침해사고(해킹·악성코드 등)는 KISA·과기정통부, 개인정보 유출은 개인정보보호위원회로 가고, 사고에 둘 다 있다면 둘 다 신고해야 합니다.

8. 마무리하며

01-1 왜 보안부터인가 - 이 책의 대상, 사고가 곧 법적 책임으로 이어지는 이유
01-2 가장 많이 실수하는 자리 - 회원가입 동의, 관리자 노출, 에러 메시지, 시크릿, BaaS 권한, 임시 계정, HTTPS
01-3 AI 코드의 단골 취약점 - SQL 인젝션, XSS, CSRF, 남의 데이터 조작, 의존성

이 책이 모든 답을 다 주지는 않습니다. 그건 한 권짜리 책의 몫이 아니에요. 다만 AI에게 코드를 시키면서 "이 부분 보안은 어떻게 되는 거지?", "이거 법적으로 괜찮은 건가?" 같은 질문을 던질 줄 아는 감각은 만들어졌을 겁니다. 그 감각이 바이브 코더의 가장 큰 자산입니다.