개발 외주 보안·개인정보 요건, 계약 전에 정할 7가지
개인정보 보호법 26조는 처리 업무를 위탁할 때 문서로 정하고 수탁자를 교육·감독하도록 해요. 재위탁도 위탁자 동의가 있어야 하고요. 개발 외주에서 보안 요건을 어디까지 요구해야 하는지 자체 SaaS 4종을 운영해온 개발사 기준으로 정리했어요.

핵심 요약 — 개발사에 일을 맡겨도 개인정보에 대한 책임은 발주자에게 남아요. 개인정보 보호법은 위탁할 때 문서로 정하고, 맡긴 쪽이 교육하고 감독하도록 정하고 있어요. 그런데 실제 외주 계약서에는 보안 항목이 “관계 법령을 준수한다” 한 줄로만 들어가는 경우가 많아요. 계약 전에 정해두면 설계에 반영되고, 착수 뒤에 꺼내면 추가 공수가 돼요. 직접 만들고 운영해온 개발사 기준으로 정리했어요.
“저희는 개인정보 거의 안 다뤄요. 이름이랑 연락처 정도예요.”
발주 상담에서 자주 듣는 말이에요. 그런데 이름과 연락처가 바로 개인정보예요. 회원가입이 있는 서비스, 문의 폼이 있는 홈페이지, 주문을 받는 쇼핑몰은 대부분 여기에 해당해요.
문제는 사고가 났을 때 누가 답하느냐예요. 개발은 외주로 맡겼어도, 그 데이터를 모으기로 결정한 건 발주자거든요. 개발외주계약서에 보안 항목이 비어 있으면 그 공백은 대부분 발주자 쪽으로 돌아와요.
1. 보안 요건을 안 적으면 왜 발주자 책임이 될까요

법이 그렇게 짜여 있어서예요.
개인정보 보호법은 처리 업무를 남에게 맡기는 상황을 따로 다뤄요. 맡기는 쪽을 위탁자, 맡는 쪽을 수탁자라고 부르는데, 위탁했다고 책임이 넘어가지 않아요. 오히려 맡긴 쪽에 교육과 감독 의무를 지워요. 수탁자가 안전하게 처리하는지 업무 처리 현황을 점검하라는 식이에요.
그래서 “개발사가 알아서 하겠지”라는 전제는 법적으로 성립하지 않아요. 개발사가 실수해도 관리를 안 한 책임은 발주자에게 남아요.
용어 정리 — 위탁과 수탁 우리 회사가 모은 고객 정보를 다른 회사가 대신 다루게 하는 걸 위탁이라고 해요. 맡기는 쪽이 위탁자, 맡는 쪽이 수탁자예요. 개발사가 서버를 운영하거나 데이터를 옮기는 작업을 한다면 대개 수탁자에 해당해요. 실무에선 “위탁 계약서 썼어요?”라는 질문으로 이 관계가 문서화됐는지를 확인해요.
2. 개인정보 위탁, 계약서에 무엇이 들어가야 하나요

법에서 문서에 담으라고 정한 항목이 있어요. 크게 세 갈래예요.
- 범위를 넘는 처리 금지 — 맡긴 일 외에 그 데이터를 쓰지 않는다는 내용
- 기술적·관리적 보호조치 — 암호화, 접근 통제, 접속 기록 같은 구체적 조치
- 안전한 관리를 위한 사항 — 시행령이 정하는 나머지 항목들
여기에 실무에서 반드시 덧붙이는 게 하나 더 있어요. 재위탁 제한이에요. 수탁자가 그 일을 또 다른 회사에 넘기려면 위탁자 동의를 받아야 해요. 개발사가 특정 기능만 프리랜서나 다른 업체에 맡기는 일은 흔한데, 이걸 모르고 있으면 우리 데이터가 어디까지 갔는지 파악이 안 돼요.
한 가지 실무 팁을 더하면, 이 문서는 개발 계약서와 따로 만드는 게 관리하기 편해요. 개발 계약은 납품하면 끝나지만 데이터를 다루는 관계는 운영하는 내내 이어지거든요.
3. 개발 중에 실데이터를 넘기고 있진 않나요

계약서를 아무리 잘 써도 여기서 새면 소용이 없어요.
가장 흔한 장면은 이래요. 기존 시스템을 새로 만드는 프로젝트에서 “데이터 옮겨야 하니까 지금 쓰는 데이터베이스 한 벌 주세요”라는 요청이 와요. 편하니까 통째로 복사해서 보내요. 그 파일이 개발자 노트북에 몇 달 남아 있어요.
이걸 줄이는 방법은 세 가지예요.
- 가짜 데이터로 개발하기 — 대부분의 기능은 실제 이름과 번호가 없어도 만들 수 있어요.
- 식별 정보만 지우고 주기 — 구조는 그대로 두고 이름·연락처·주소만 바꿔요.
- 꼭 필요한 구간만 열기 — 데이터 이전 작업 같은 특정 단계에서만, 기간을 정해서요.
그리고 어느 방식이든 작업이 끝난 뒤 삭제했다는 확인을 받아두세요. 말로 하지 말고 한 줄이라도 남기는 게 좋아요.
4. 접근 권한과 계정은 어디까지 열어야 할까요

권한은 사람 단위가 아니라 역할 단위로 여는 게 기본이에요.
개발사에 계정을 하나 만들어주고 그걸 팀 전체가 돌려 쓰는 구조가 아직도 흔해요. 이러면 누가 무엇을 했는지 기록이 남지 않아요. 사고가 났을 때 원인을 못 찾는 건 물론이고, 그 사람이 프로젝트에서 빠져도 접근이 계속 살아 있어요.
정해둘 건 네 가지예요.
- 계정을 개인별로 만드나요
- 운영 서버에 누가 들어갈 수 있나요
- 들어간 기록이 남나요
- 프로젝트가 끝나면 언제 닫나요
특히 마지막이 자주 비어 있어요. 검수가 끝나고도 개발사 계정이 몇 년째 살아 있는 경우를 여러 번 봤어요. 계약서에 “검수 완료 후 ○일 이내 접근 권한 회수”를 한 줄 넣어두면 그 일이 실제로 일어나요.
지금 준비 중인 프로젝트에서 어디까지 요구해야 할지 감이 안 잡히신다면, 요건 정리부터 함께 짚어드릴게요 →
5. 재하청이 있으면 무엇이 달라지나요

우리가 계약한 회사와 실제로 코드를 만지는 회사가 다를 수 있어요.
이 구조 자체가 문제는 아니에요. 특정 기술이 필요할 때 전문 인력을 붙이는 건 자연스러운 일이고요. 문제는 모르고 있는 경우예요. 데이터를 다루는 사람이 계약 관계 밖에 있으면 감독할 방법이 없어요.
그래서 외주업체를 고를 때 이 질문을 넣어보세요. “이 프로젝트에 우리 회사와 계약하지 않은 인력이 참여하나요?” 답이 “있다”여도 괜찮아요. 그때 필요한 건 명단과 동의 절차지 거절이 아니에요.
소프트웨어개발외주에서 재하청이 흔한 유형은 디자인, 특정 기기 연동, 데이터 이전 작업이에요. 이 세 구간에서 특히 확인해두면 좋아요.
6. 망 구성과 보안 요건이 비용을 얼마나 바꿀까요

요건에 따라 성격이 완전히 달라져요.
접근 권한을 나누고 기록을 남기는 정도는 처음부터 설계에 넣으면 개발외주비용이 크게 오르지 않아요. 반면 환경 자체를 바꾸는 요건은 다른 이야기예요. 외부 인터넷과 끊긴 폐쇄망에서 돌아야 한다거나, 별도 인증 체계를 붙여야 한다면 개발 기간과 시험 공수가 함께 늘어나요.
저희가 진행한 롯데백화점 수원 푸드홀 실시간 혼잡도 시스템도 그랬어요. 보안 요건 때문에 내부·사설 네트워크로 구성해야 했고, 그 조건이 개발 방식과 시험 방법을 처음부터 바꿔놨어요. 이런 요건은 견적서를 받기 전에 말해야 제대로 반영돼요. 나중에 나오면 이미 만든 것을 다시 손봐야 해서 훨씬 비싸져요.
7. 계약 전에 정할 7가지

견적 요청서를 보내기 전에 아래 일곱 칸을 채워보세요.
| # | 정할 것 | 확인 방식 |
|---|---|---|
| 1 | 다루는 개인정보 항목 | 이름·연락처·결제 정보 등 목록으로 |
| 2 | 위탁 문서 작성 여부 | 개발 계약서와 별도로 만들지 |
| 3 | 개발 중 실데이터 사용 | 가짜 데이터 원칙, 예외 구간과 기간 |
| 4 | 접근 권한 | 개인별 계정, 기록 보관, 회수 시점 |
| 5 | 재위탁 | 참여 조직 명단과 사전 동의 절차 |
| 6 | 망·인증 요건 | 폐쇄망 여부를 견적 전에 명시 |
| 7 | 계약 종료 시 데이터 | 반환할지 삭제할지, 확인 방법 |
흔히 놓치는 지점도 짚어둘게요. 첫째, 보안 항목이 “관계 법령을 준수한다” 한 줄로 끝나는 경우예요. 지켜야 할 대상이 특정되지 않아서 나중에 기준이 안 돼요. 둘째, 위탁 문서를 만들어놓고 한 번도 점검하지 않는 경우예요. 법이 요구하는 건 문서 보관이 아니라 감독이에요. 셋째, 마지막 칸을 안 정해서 계약이 끝난 뒤에도 데이터가 개발사 쪽에 남아 있는 경우고요.
8. 자주 묻는 질문 (FAQ)
작은 홈페이지에도 위탁 문서가 필요할까요
문의 폼으로 이름과 연락처를 받고 있다면 필요해요. 규모가 아니라 개인정보를 다루느냐가 기준이에요. 다만 분량이 클 필요는 없어요. 위탁 범위, 목적 외 사용 금지, 보호 조치, 재위탁, 종료 시 처리. 이 다섯 가지가 들어간 한두 장짜리 문서면 충분한 경우가 많아요.
개발사가 보안 요건을 부담스러워하면 어떻게 하나요
요건을 나눠서 이야기해보세요. 대부분의 부담은 폐쇄망이나 별도 인증처럼 환경을 바꾸는 항목에서 나와요. 권한 분리나 기록 보관은 오히려 개발사에도 유리한 조건이에요. 무슨 일이 있었는지 증명할 수 있으니까요. 전부 아니면 전무로 물어보지 말고 항목별로 짚으면 대화가 훨씬 쉬워져요.
클라우드를 쓰면 보안은 알아서 되는 거 아닌가요
인프라 수준의 보안은 상당 부분 제공되지만, 우리 서비스 안에서 누가 어떤 데이터를 볼 수 있는지는 여전히 우리가 정해야 해요. 권한 설정을 잘못 해서 데이터가 외부에 열려 있는 사고는 대부분 이 구간에서 생겨요. 클라우드 계약이 위탁 문서를 대신해주지도 않고요.
9. 마무리 — 요건은 견적서보다 먼저 나와야 해요
정리하면 이래요. 개발을 맡겨도 개인정보 책임은 발주자에게 남고, 법은 문서화와 감독을 요구해요. 그래서 계약서에 한 줄 적는 것으로는 부족하고, 다루는 항목·권한·재위탁·종료 처리를 구체적으로 정해둬야 해요. 그리고 이 요건들은 견적 전에 나올수록 싸요. 나중에 붙이면 이미 만든 구조를 다시 손봐야 하니까요.
저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 폐쇄망 조건에서 실시간 시스템을 만들어본 적도 있고, 저희 서비스 사용자의 데이터를 매일 직접 다루고 있기도 해요. 그래서 보안 요건이 개발 일정과 비용을 어디서 바꾸는지 실무 감각으로 말씀드릴 수 있어요.
지금 준비 중인 프로젝트에서 어디까지 요구해야 할지, 그게 비용에 얼마나 반영될지 궁금하시다면 요건을 정리하는 것부터 같이 시작해요 →
관련 글