STUDIO 침해 사고 이후: 직접 운영하는 WordPress로 사이트 옮기기

게시일 2026-11-10

STUDIO가 제3자가 자사 클라우드 환경에 침입했다고 밝힌 지 4주가 지났습니다. 대응은 아직 이어지고 있고, 영향을 받은 조직 중 상당수는 애초에 웹사이트를 호스팅형 빌더에 계속 두어야 하는지 고민하고 있습니다. 이 글에서는 일본 언론이 보도한 내용, 무엇보다 먼저 해야 할 일, 그리고 FrontierStack의 새 STUDIO 가져오기로 STUDIO 사이트를 직접 운영하는 WordPress 사이트로 옮기는 방법을 정리합니다.

무슨 일이 있었나

2026년 10월 16일, 일본에서 널리 쓰이는 노코드 웹사이트 빌더 STUDIO(studio.design)가 무단 접근에 관한 안내를 발표했습니다(영어판도 있습니다). 제3자가 STUDIO 일부 기능의 취약점을 악용해 2026년 9월 30일부터 10월 1일(일본 시간)까지 클라우드 환경의 데이터에 접근할 수 있었습니다. STUDIO는 10월 13일에 접근을 확인하고 13~14일에 경로를 막았습니다. 모든 등록 고객의 정보가 노출됐을 수 있다고 밝히며, 데이터가 탈취된 것으로 간주하고 대응하고 있습니다. 니혼게이자이신문은 같은 날 이 서비스를 3만 개가 넘는 기업이 쓰고 있다고 보도했습니다.

가장 중요한 사실은 그 뒤에 드러났습니다. 양식 제출 내용과 고객이 저장한 API 키는 암호화돼 있었지만, ScanNetSecurity 보도대로 이를 복호화하는 키도 함께 읽혔습니다. 영향은 STUDIO 고객에서 그치지 않았습니다. 10월 22일 일본 디지털청은 STUDIO로 만든 페이지의 문의 양식으로 보낸 내용이 유출됐을 수 있다고 발표했고(ScanNetSecurity), 10월 27일 기준으로 보안 블로그 piyolog는 영향을 받았거나 조사 중이라고 밝힌 조직 192곳을 정리했습니다.

옮기기 전에 키부터

사이트를 옮겨도 이미 복사된 것은 되돌릴 수 없습니다. microCMS, OpenAI, Google 스프레드시트 등 Data Connect나 API Connect로 연동하려고 STUDIO에 API 키나 토큰을 저장했다면, 먼저 각 공급업체에서 교체하고 9월 30일 이후의 사용 내역과 로그를 확인하십시오. STUDIO가 고객에게 요청한 10가지 조치는 유출 뉴스의 STUDIO 항목에 정리했고, STUDIO 암호를 바꿔도 이 키들이 보호되지 않는 이유는 웹사이트 빌더가 API 키를 보관하고 있을 때에서 설명했습니다.

양식으로 개인정보를 받았다면, 일본 개인정보보호위원회에 보고하는 방법(단독 또는 STUDIO와 공동)도 STUDIO의 안내에 나와 있습니다. 공동 보고 신청은 11월 18일 23:59(일본 시간)에 마감됩니다.

왜 직접 운영하나

호스팅형 빌더가 편리한 것은 페이지도, 양식 제출 내용도, 사이트가 연결하는 모든 서비스의 키도 다른 누군가가 맡아 주기 때문입니다. 이번 사고는 그 편리함의 이면을 보여 주었습니다. 서로 관계없는 수천 개의 사이트가 하나의 환경과 하나의 복호화 키를 공유했고, 소유자들은 안내문을 보고서야 무슨 일이 있었는지 알았습니다. 사이트를 직접 운영하면 그런 것들이 내가 고른 서버에 있고, 백업은 내 손에 있으며, 로그는 직접 읽을 수 있고, 키는 내가 아는 한 곳에 있습니다.

그렇다고 저절로 더 안전해지는 것은 아닙니다. 업데이트, 백업, 인증서, 서버 자체의 보안을 직접 맡아야 하고, 방치된 WordPress 사이트도 공격 대상입니다. 키 교체를 마친 작은 소개 사이트라면 STUDIO를 계속 쓰는 것도 합리적인 선택입니다. 이미 서버를 운영하고 있거나 운영할 사람이 있는 경우, 문의나 개인정보를 직접 관리하고 싶은 경우, 또는 콘텐츠를 어디로든 가져갈 수 있는 형태로 갖고 싶은 경우라면 직접 운영이 잘 맞습니다.

STUDIO에는 내보내기가 없으므로 FrontierStack이 사이트를 읽습니다

STUDIO에는 사이트를 내려받는 방법도, 콘텐츠용 공개 API도 없습니다. 최신 FrontierStack 업데이트에서는 셋업 마이그레이션 ▸ 사이트 빌더에 STUDIO에서 가져오기가 추가되었습니다. 사이트 주소를 입력하면 FrontierStack이 사이트가 모든 방문자에게 보여 주는 내용을 읽고(STUDIO 로그인이나 API 키 불필요), Mac에서 WordPress 사이트로 다시 만듭니다.

• 페이지: 텍스트, 제목, 목록, 링크, 이미지. STUDIO 홈 페이지는 첫 페이지가 됩니다.
• CMS 항목은 글이 되며 게시일과 커버 이미지가 붙고, 연결된 항목은 카테고리와 태그가 됩니다.
• 이미지는 WordPress 미디어 라이브러리에 들어갑니다. YouTube와 Vimeo 임베드도 유지됩니다.
• 예전 주소는 새 페이지로 리디렉션되므로, 도메인을 옮긴 뒤에도 기존 링크와 검색 결과가 그대로 작동합니다.
• 새 사이트: FrontierStack이 WordPress를 내려받고, 전용 MySQL 사용자가 있는 데이터베이스를 만들고, Apache 사이트를 추가해 WordPress를 설치하는 데까지 한 번에 처리합니다. WordPress 패널에 있는 기존 사이트를 선택할 수도 있습니다.

복사할 수 없는 것도 있으며, 가져오기가 끝나면 체크리스트로 표시됩니다. 디자인과 레이아웃, 애니메이션, 페이지 사이에 공유하는 머리글·바닥글·메뉴, 배경 이미지, 동영상 이외의 임베드, 그리고 글꼴입니다(TypeSquare나 FONTPLUS처럼 STUDIO가 제공하는 웹 글꼴은 STUDIO에 딸린 것입니다). 양식은 양식 플러그인으로 다시 만들어야 합니다. 이번 사고에서 데이터가 모인 곳이 바로 양식이므로, 새 제출 내용을 어디에 저장하고 누가 읽을 수 있게 할지 지금 정해 두는 것이 좋습니다.

최신 STUDIO 사이트는 완성된 페이지를 보내므로 그것을 읽습니다. 예전 사이트는 빈 페이지를 보낸 뒤 브라우저에서 내용을 채우므로, FrontierStack은 방문자의 브라우저와 같은 요청으로 STUDIO의 게시 저장소에서 페이지 레이아웃을, STUDIO의 CMS 서비스에서 CMS 항목을 읽습니다. 내 사이트에 사용하십시오.

Mac에서 호스트로

Mac에서 새 사이트를 확인했다면, 호스트에 게시…가 사이트 복제를 열어 사이트와 데이터베이스를 내 서버나 호스팅 계정에 복사하도록 설정합니다. 사본에는 그 위치 전용 데이터베이스 로그인이 적힌 wp-config.php가 만들어지고, 지금 쓰는 주소로 응답하도록 설정됩니다. 새 사이트를 공개할 때까지 STUDIO 사이트는 그대로 두고, 그 뒤 도메인을 새 사이트로 연결하십시오. 예전 주소는 리디렉션이 처리합니다.

Mac App Store 앱 Pancake Stack에도 같은 가져오기가 새 사이트 ▸ STUDIO에서로 추가되었습니다.

이전 체크리스트

1. STUDIO에 저장한 모든 키를 교체하고, 각 공급업체의 9월 30일 이후 로그를 확인합니다.
2. 사이트를 가져오고, 가져오기가 보여 주는 체크리스트를 처리합니다.
3. 양식을 다시 만들고, 제출 내용을 저장할 곳과 읽을 수 있는 사람을 정합니다.
4. 공개하기 전에 백업과 업데이트를 갖춰 둡니다.
5. 호스트에 게시하고 임시 주소에서 동작을 확인합니다.
6. 도메인을 새 사이트로 연결하고, 예전 주소의 리디렉션을 확인한 뒤 STUDIO 프로젝트를 닫습니다.

출처

• Studio: Studioにおける不正アクセスに関するご案内(일본어, 2026년 11월 4일 기준), 영어 안내
• 니혼게이자이신문(2026년 10월 16일): Web制作ツールのStudioに不正アクセス　顧客情報流出か(일본어, 일부 유료)
• ScanNetSecurity(2026년 10월 28일): Studio が利用するクラウド環境に不正アクセス、復号に必要な鍵も読み出される(일본어)
• ScanNetSecurity(2026년 10월 28일): デジタル庁ホームページの問い合せフォームの情報が漏えい、Studio のクラウド環境への不正アクセス(일본어)
• piyolog(2026년 10월 20일, 27일 업데이트): Studioへの不正アクセスについてまとめてみた(일본어)
• FrontierStack 유출 뉴스: STUDIO 무단 접근(2026년 10월)