창업을 준비하면서 정부 지원으로 AI 서비스를 써 보신 분, 꽤 많으실 거예요. 계약서 초안을 AI가 써 주고, 사업계획서를 다듬어 주고… 요즘 창업 준비의 든든한 도우미죠. 그런데 이번 주, 그 도우미 가운데 한 곳이 해킹을 당했다는 소식이 나왔습니다.
중소벤처기업부(중기부)는 11월 13일, 정부 창업 지원사업 ‘모두의 창업’ 2차에 AI 솔루션을 공급하는 기업 아미쿠스렉스(서비스명 ‘로폼’)가 외부 해킹을 당해 이용자 2만 28명의 이름·전화번호·이메일 주소가 유출됐고, 이 가운데 모두의 창업 참가자 818명이 포함됐다고 밝혔습니다. 지난 6월 1차 사업에서 약 5,000명의 정보가 샌 지 다섯 달 만이라 참가자들의 불만도 커지고 있어요.
오늘은 ① 무슨 일이 있었는지, ② 공격 수법으로 지목된 ‘SQL 인젝션’이 대체 무엇인지(그림 그리듯 쉽게), ③ “정부 사업인데 왜 민간 회사에서 샜지?”라는 구조 문제, ④ 내 정보가 포함됐다면 오늘 할 일까지 차근차근 정리해 드릴게요.
한눈에 보는 요약
| 항목 | 내용 |
|---|---|
| 무슨 일? | AI 법률문서 서비스 ‘로폼’ 운영사 아미쿠스렉스 시스템이 해킹돼 이용자 개인정보 유출 |
| 언제? | 11월 11일 오전 5시 38분 공격 발생(신고서 기준) → 같은 날 오전 8시 30분 인지 → 11월 13일 중기부 발표 |
| 규모 | 로폼 이용자 2만 28명 (이 중 ‘모두의 창업’ 2차 참가자 818명) |
| 무엇이? | 이름, 전화번호, 이메일 주소 (발표된 유출 항목 3가지) |
| 수법 | 침해사고 신고서상 관리자 페이지 대상 SQL 인젝션 공격, 취약한 API 코드 삭제 조치 |
| 회사 조치 | 해외 IP 접속 차단 등 긴급 보안 조치, 11월 13일 오후 3시 유출 대상자 개별 통지 |
| 정부 조치 | 참가자에게 경위·스미싱 예방법 안내, 나머지 49개 공급기업에 보안 점검 요청 |
| 내가 할 일 | 통지 문자·메일 확인, 사칭 연락 경계, 같은 이메일로 쓰는 계정 점검 |
1. ‘모두의 창업’과 ‘로폼’은 어떤 관계?
먼저 등장인물부터 정리해 볼게요. ‘모두의 창업’은 중기부가 운영하는 창업 지원 프로젝트입니다. 참가자가 아이디어를 검증하고 사업화할 수 있도록, 2차 사업에서는 민간 AI 솔루션 기업 50곳을 골라 참가자가 그중 원하는 서비스를 고르면 정부가 이용료를 대신 내 주는 방식을 씁니다. 2기는 10월 20일 출범했어요.
로폼은 그 50곳 가운데 하나인 아미쿠스렉스가 운영하는 서비스로, 기업이 계약서 같은 법률 문서를 작성하도록 돕는 AI 솔루션입니다. 중요한 점은 로폼이 정부 사이트가 아니라 민간 기업이 자체적으로 운영하는 시스템이라는 것. 참가자는 개인정보 제3자 제공에 동의한 뒤 이 서비스를 이용하게 됩니다.
| 구분 | 모두의 창업 플랫폼 | AI 솔루션(예: 로폼) |
|---|---|---|
| 운영 주체 | 중기부·창업진흥원 | 각 민간 기업(아미쿠스렉스 등) |
| 하는 일 | 참가 신청, 심사, 프로젝트 관리 | 참가자가 고른 AI 서비스 제공 |
| 돈은 누가? | 정부 예산 | 이용료를 정부가 지원 |
| 이번 사고 위치 | 해당 없음 | 여기서 발생 |
| 이용자 범위 | 프로젝트 참가자 | 참가자 + 일반 유료·무료 이용자까지 |
그래서 숫자가 두 개입니다. 로폼이 보유한 전체 이용자 2만 28명이 유출됐고, 그중 정부 사업과 연결된 사람이 818명이에요. 즉 “모두의 창업에 참가하지 않았어도 로폼을 써 본 적이 있다면” 대상일 수 있다는 뜻입니다.
2. 사고는 이렇게 흘러갔습니다
회사가 KISA 등에 낸 침해사고 신고서와 정부 발표, 보도를 시간 순서로 맞춰 보면 다음과 같습니다.
| 날짜·시각(2026년) | 일어난 일 |
|---|---|
| 11월 11일 05:38 | 관리자 페이지 대상 SQL 인젝션 공격으로 유출 발생(신고서 기준) |
| 11월 11일 08:30 | 아미쿠스렉스가 자체 시스템에서 해킹 정황 포착 |
| 11월 11일 15:45 | 한국인터넷진흥원(KISA)에 신고 |
| 11월 12일 18:10 | 창업진흥원에 사고 사실 전달 |
| 11월 13일 15:00 | 유출 확인된 이용자에게 개별 통지 |
| 11월 13일 오후 | 중기부 공식 발표 (공격 발생부터 약 59시간 30분 뒤) |
| 11월 14일 | 참가자들 “경위·보상 대책 공개하라” 요구, 중기부 설명자료 배포 |
회사는 공격 약 3시간 만에 이상을 알아챘고 KISA 신고도 당일에 했습니다. 다만 정부에 전달되기까지 하루 넘게 걸렸고, 정부의 공식 발표는 공격 후 약 2.5일 뒤였어요. 이 ‘알리기까지의 시간’도 이번에 비판받는 지점입니다.
3. SQL 인젝션, 도서관 사서에게 쪽지 내밀기
이번 사고의 핵심 단어인 SQL 인젝션을 쉽게 풀어 볼게요. 웹사이트 뒤편에는 회원 정보를 담은 데이터베이스(DB)가 있고, 웹사이트는 DB에게 SQL이라는 언어로 “이 사람 정보 찾아 줘” 하고 부탁합니다.
도서관에 비유하면 이렇습니다. 이용자가 신청서 빈칸에 “찾을 책: 어린 왕자”라고 적으면, 사서(웹사이트)가 그 빈칸 내용을 그대로 붙여 창고 담당자(DB)에게 전달하죠. 그런데 누군가 빈칸에 “어린 왕자, 그리고 회원 명부 전체도 같이 가져와”라고 적었는데, 사서가 이걸 걸러 내지 않고 그대로 전달한다면? 창고 담당자는 시킨 대로 명부까지 들고 나옵니다. 이것이 SQL 인젝션이에요. 입력칸에 ‘명령’을 끼워 넣어(inject) DB를 속이는 공격입니다.
| 단계 | 정상 이용 | SQL 인젝션 |
|---|---|---|
| 입력 | 검색어·아이디 같은 평범한 값 | 값 뒤에 DB 명령 조각을 몰래 덧붙임 |
| 웹사이트 처리 | 값을 ‘데이터’로만 취급 | 값을 걸러 내지 않고 명령문에 그대로 이어 붙임 |
| DB 반응 | 요청한 한 건만 돌려줌 | 덧붙인 명령까지 실행(목록 전체 조회 등) |
| 결과 | 정상 서비스 | 회원 정보 대량 유출 |
SQL 인젝션은 20년 넘게 알려진 ‘고전 중의 고전’ 공격이라 막는 방법도 잘 정리돼 있습니다. 입력값을 명령이 아닌 데이터로만 다루게 하는 파라미터 바인딩(Prepared Statement), 입력값 검증, DB 계정 권한 최소화, 그리고 관리자 페이지는 아무나 접근하지 못하게 IP·추가 인증으로 묶어 두기가 기본이에요. 이번 사고가 하필 관리자 페이지에서 일어났다는 점이 아쉬운 이유입니다.
| 기본 방어 | 쉽게 말하면 |
|---|---|
| 파라미터 바인딩 | 신청서 빈칸 내용은 “책 이름”으로만 읽고, 절대 명령으로 해석하지 않기 |
| 입력값 검증 | 빈칸에 이상한 기호·명령어가 섞이면 접수 거부 |
| 최소 권한 | 창고 담당자에게 애초에 명부 전체를 꺼낼 권한을 주지 않기 |
| 관리자 페이지 잠금 | 직원 전용 문은 사무실 안에서만, 추가 인증까지 통과해야 열리게 |
| 웹 방화벽(WAF) | 정문에서 수상한 신청서를 미리 걸러 내는 경비원 |
4. 1차 사고와 무엇이 같고 무엇이 다를까
‘모두의 창업’은 지난 6월에도 사고가 있었습니다. 그때는 공식 플랫폼의 일부 API 보안이 미흡해 특정 API 호출·웹 크롤링으로 합격자 약 5,000명의 이메일 주소와 심사평, 창업 아이디어 요약 등이 유출됐어요. 중기부는 7월 말 브리핑에서 개인정보 암호화 강화, API 접근 전체 로그 기록, 웹 크롤링 차단 고도화를 약속했습니다.
| 비교 | 1차 사고 (6월) | 2차 사고 (11월) |
|---|---|---|
| 규모 | 합격자 약 5,000명 | 로폼 이용자 2만 28명(참가자 818명) |
| 유출 항목 | 이메일, 심사평, 창업 아이디어 요약 등 | 이름, 전화번호, 이메일 |
| 발생 위치 | 공식 플랫폼의 비공개 정보가 외부 요청에 노출 | 민간 기업이 자체 운영하는 시스템 |
| 공통점 | API(프로그램끼리 정보를 주고받는 창구) 쪽 보안 허점이 문제로 지목됨 | |
정부는 “이번 시스템은 민간 기업이 자체 운영하는 것”이라고 설명했지만, 해당 기업은 불과 한 달 전 정부의 기술·보안 평가를 통과해 선정된 곳이었습니다. 그래서 “공식 플랫폼만 지킬 게 아니라, 정부 사업에 연결된 협력 기업의 보안 수준까지 확인했어야 했다”는 지적이 나옵니다. 보안 업계에서 말하는 ‘공급망(협력사) 리스크’가 딱 이 상황이에요.
5. ‘이름·전화·이메일만’이면 괜찮을까?
비밀번호나 주민등록번호처럼 무거운 정보는 발표된 유출 항목에 없습니다. 그렇다고 마음을 놓기는 이릅니다. 이 세 가지가 ‘누가 어떤 서비스를 쓰는지’라는 맥락과 합쳐지면 아주 그럴듯한 사칭 연락을 만들 수 있거든요.
| 유출 정보 | 단독으로는 | 맥락과 합쳐지면 |
|---|---|---|
| 이름 | 흔한 정보 | “○○○ 대표님” 하고 이름을 부르며 신뢰 유도 |
| 전화번호 | 스팸 문자 증가 | “로폼·창업진흥원입니다” 사칭 스미싱·전화 |
| 이메일 | 광고 메일 증가 | “유출 보상금 신청” 피싱 메일, 다른 사이트 로그인 시도의 아이디로 악용 |
| ‘창업 준비자’라는 사실 | — | 지원금·대출·법률 서비스 등 창업자 맞춤 미끼 |
예를 들어 이런 문자가 올 수 있어요. “[창업진흥원] 개인정보 유출 피해 보상금 지급 대상입니다. 아래 링크에서 본인 확인 후 신청하세요.” 실제 정부·회사 발표에 보상금 지급 같은 내용은 없습니다. 이런 링크는 누르지 마세요.
6. 오늘 할 일 5가지
| 순서 | 할 일 | 방법 |
|---|---|---|
| 1 | 통지 확인 | 11월 13일 오후 이후 받은 로폼·창업진흥원 문자·메일이 있는지 확인. 단, 그 안의 링크보다 공식 홈페이지를 직접 찾아 들어가기 |
| 2 | 사칭 연락 경계 | “보상금”, “본인 확인”, “계정 정지” 문구 + 링크 = 일단 의심. 기관은 문자로 인증번호·비밀번호를 묻지 않음 |
| 3 | 비밀번호 점검 | 비밀번호 유출은 발표되지 않았지만, 로폼과 같은 이메일·비밀번호를 쓰는 다른 사이트가 있다면 이번 기회에 바꾸기 |
| 4 | 2단계 인증 켜기 | 이메일 계정(네이버·구글 등)에 2단계 인증을 켜 두면 아이디가 알려져도 로그인이 훨씬 어려워짐 |
| 5 | 피해 시 신고 | 개인정보 침해는 국번 없이 118(개인정보침해 신고센터), 금전 피해는 경찰(112·사이버범죄 신고), 손해배상은 개인정보 분쟁조정위원회 |
7. 참가자들은 무엇을 요구하고 있나
11월 14일 연합뉴스 보도에 따르면, 한 2차 참가자는 모두의 창업 게시판에 글을 올려 다음 내용을 공개하라고 요구했습니다. 또 다른 참가자는 “내가 쓴 곳은 아니었지만 나머지 49개 솔루션 기업은 안전한지 걱정”이라고 말했어요.
| 요구 사항 | 쉽게 말하면 |
|---|---|
| 기관별 보안 책임·감독 의무 공개 | 누가 무엇을 지켜야 했는지 |
| 1차 사고 후 재발 방지 조치 이행 결과 | 약속한 대책을 실제로 했는지 |
| 참여기관·AI 공급기업 보안 기준 | 협력사를 어떤 기준으로 걸렀는지 |
| 책임자 의무 이행 여부와 구제 방안 | 피해자는 어떻게 보상받는지 |
| 보험·재원과 피해 보상 절차 | 보상할 돈과 절차가 준비돼 있는지 |
중기부와 창업진흥원은 나머지 49개 공급기업에 자체 시스템 보안과 개인정보 관리 실태를 점검하도록 요청했고, 앞으로 개인정보 접근 권한 관리, 보유기간이 지난 정보의 파기 여부 등을 계속 점검하겠다고 밝혔습니다.
8. 작은 회사·스타트업이라면 꼭 챙길 것
이번 사고는 창업을 준비하는 분들에게 남 일이 아닙니다. 곧 내 서비스도 고객 정보를 받게 되니까요. 거창한 보안팀이 없어도 아래만 챙기면 같은 유형의 사고 확률을 크게 줄일 수 있습니다.
| 체크 항목 | 왜 중요한가 |
|---|---|
| 관리자 페이지 주소·접근 IP 제한 | 공격자가 ‘직원 전용 문’을 아예 못 찾게, 찾아도 못 들어오게 |
| 관리자 계정 2단계 인증 | 비밀번호가 새도 마지막 문이 하나 더 남음 |
| DB 질의는 파라미터 바인딩으로 | SQL 인젝션의 가장 확실한 예방책 |
| 필요 없는 개인정보는 받지 않거나 파기 | 안 갖고 있는 정보는 샐 수도 없음 |
| API 접근 로그 남기기 | 사고가 나도 무엇이 얼마나 나갔는지 빨리 파악 |
| 사고 시 신고·통지 절차 미리 정해 두기 | KISA·개인정보위 신고와 이용자 통지를 늦지 않게 |
마무리: 정부 사업이라도 ‘내 정보가 실제로 어디에 있는지’ 기억하기
이번 사고에서 기억할 점은 세 가지입니다. 첫째, 정부 지원사업이라도 실제 데이터는 여러 민간 협력사 서버에 흩어져 있을 수 있다는 것. 동의서의 ‘제3자 제공’ 항목에 어떤 회사가 적혀 있는지 한 번쯤 보아 두면 좋습니다. 둘째, SQL 인젝션처럼 오래된 공격도 기본을 놓치면 여전히 통한다는 것. 셋째, 유출 자체보다 무서운 건 그다음에 오는 사칭 연락이라는 것이에요.
로폼이나 모두의 창업을 이용하셨다면 오늘 통지 메시지부터 확인해 보시고, 당분간 “보상금”, “본인 확인” 문자는 한 번 더 의심해 주세요. 사고 경위와 보상 방안에 대한 후속 발표가 나오면 또 쉽게 정리해 드리겠습니다.