안녕하세요, 사계 대광장이에요.
지난 2026-09-05 02:09부터 2026-09-10 22:41에 이르기까지, 약 6일 동안 사계 대광장 서비스가 장애를 겪었어요. API부터 웹 페이지 전반에 이르기까지 거의 모든 서비스가 중단되어 구성원 여러분들께 상당한 불편을 끼쳐드렸어요. 정말 죄송해요.
아울러 이번 서비스 장애를 복구하고 점검하는 과정 중에, 여러분께서 계정에 업로드하신 미디어 파일들이 상당수 영구 손실되었다는 점을 발견했어요. 이 미디어 파일의 손실은 외부 공격에 의한 유출이 아닌, 사전에 발견되지 못한 소프트웨어 상의 문제에 의해 파일들이 자동 삭제되면서 벌어졌어요. 대광장에 저장된 여러분의 계정 이미지와 헤더 이미지를 포함해, 작성하신 글과 답글, DM은 이번 사고와 무관히 안전하게 보존되어 있어요. 여러분이 작성하신 글에 첨부된 미디어 파일들만이 이번 사고에 의해 영향을 받았어요.
대광장 관리자는 대광장이 목표하는 바인 작성하신 글의 원활한 공유와 사람들과의 즐거운 소통에 중대한 영향을 미친 이번 사고의 중대성을 엄중하게 인식하고 있어요. 특히 업로드하신 미디어 파일들이 제대로 보호되지 못했다는 사실은 대광장 구성원 여러분들의 플랫폼에 대한 신뢰를 해친다는 점에서 특히 엄중하게 받아들이고 있어요. 이와 같은 사건이 재발하지 않고 여러분의 데이터를 안전하게 보호하기 위하여 관리자는 발견된 문제점에 대응하기 위한 필요 조치들을 추가하고, 백업 계획을 더 꼼꼼히 수립했어요. 이번 사고에 대한 원인 분석을 포함해, 관리자가 어떤 대응책과 방침들을 추가했는지는 아래에 이어지는 상세한 내용들을 참고해주세요.
아울러 이번 미디어 파일 손실 사고에 따라, 손실된 미디어 파일이 첨부된 게시글에 대해서는 관리자가 기술적인 방식으로 삭제된 미디어 파일을 게시글이 참고하지 않도록 약 2주 뒤인 2026-09-26 (GMT+9)에 조치할 예정이에요. 즉, 이번 사고에 의해 영향받은 미디어 파일이 계속 흐리게 표시되는 경우를 막기 위해, 게시글에 첨부된 미디어 파일 기록을 데이터베이스에서 직접 삭제할 예정이에요. 이렇게 하면 손실된 파일이 더 이상 게시글에서 보이지 않게 될 것이고, 또한 프로필의 '미디어' 탭에서도 손실된 파일들이 더 이상 보이지 않게 될 거에요.
하지만 경우에 따라서는 흐리게라도 이미지 보기를 유지하고 싶으실 수도 있고, 또 원본 파일을 가지고 있는 경우는 직접 파일을 다시 재첨부하여 게시글을 갱신하고 싶으신 구성원이 있을 수 있을 것 같아요. 그런 분들께서는 대광장 운영자 계정 @sakyey 또는 sakyey.official@gmail.com을 통해 자신의 계정 전체, 또는 특정한 게시물(게시물을 볼 수 있는 URL을 꼭 첨부해주세요!)들의 목록에 대해 미디어 삭제 조치를 원하지 않으신다는 의사를 보내주세요. 그 경우 관리자가 작업을 진행할 때, 해당 게시물이나 계정은 제외하도록 할게요.
이번 서비스 장애와 미디어 파일 손실 사고로 불편과 심려를 끼쳐드려 다시 한 번 진심으로 여러분께 죄송해요. 관련하여 문의하실 것이 있거나, 도움이 필요하신 경우에는 대광장 운영자 계정 @sakyey 또는 sakyey.official@gmail.com으로 연락해주시면 최대한 빠르게 도와드릴게요.
이하에는 이번 서비스 장애 및 미디어 파일 손실 사고와 관련해 다음과 같은 내용들을 여러분께 상세히 설명드리려고 해요.
- 대광장 서비스 중단 장애
- 구체적인 장애 내역
- 중단 장애를 인지한 이후 관리자가 취한 조치
- 장애가 발생한 원인
- 장애 재발을 막기 위해 보완된 점들과 향후 계획
- 대광장 게시글 미디어 파일 손실 사고
- 구체적인 사고 내역과 영향 범위
- 손실 사고를 인지한 이후 관리자가 취한 조치
- 손실 사고가 발생한 원인
- 손실 사고에도 불구하고 여전히 대광장에서 미디어들이 '흐리게' 보이고 있는 이유
- 사고 재발을 막기 위해 보완된 점들과 향후 계획
대광장 서비스 중단 장애
구체적으로 무슨 일이 일어났던 건가요?
한국 시간(GMT+9)으로 2026년 9월 5일, 2026년 9월 정기 대광장 서버 점검을 진행하던 도중인 2시 9분부터 다시 서비스가 복구된 2026년 9월 10일 22시 41분까지, 약 6일(140시간 32분)동안 사계 대광장의 모든 서비스가 중단되는 장애가 일어났어요. 이 기간 동안 대광장에 대한 글 작성 · 다른 사람들의 글 확인 · 계정 정보 변경 등, 대광장과 관련된 모든 서비스들을 사용할 수 없었고, 다른 연합우주 인스턴스들 또한 대광장으로 새로운 글을 전달하거나 대광장에 공개된 새로운 글들의 정보를 얻을 수 없었어요.
중단 장애를 인지한 이후, 대광장 관리자는 어떤 조치를 취했나요?
대광장 접속이 불가하다는 사실을 발견한 즉시, 관리자는 사계 디스코드와 사계 대광장 실시간 상태 페이지를 통해 장애 사실을 알렸어요.
이번 장애는 외부에서 아예 서버에 접속할 수 없는 장애였기 때문에, 필요한 조치를 취하기 위해서는 관리자가 서버를 물리적으로 직접 확인해야 했어요. 다만 장애가 발생하였던 당시 관리자가 장기 출장 중이었기 때문에 곧바로 서버를 확인할 수 없었어요. 장애의 원인을 확인할 방법이 없었던 관리자는 혹여 서버 접속 시도에 따른 데이터 손실이나 기타 부가 효과를 우려하여, 출장에서 돌아와 조치를 취하기 전까지 서버 접속을 전면 차단해두었어요.
관리자는 출장을 단축하여 2026년 9월 10일 오후에 서버를 물리적으로 다시 확인하였고, 이후 서버 재부팅과 복구 작업을 통해 당일 22시 41분경 대광장 서비스를 다시 재개하였어요.
이번 서비스 장애는 왜 발생한 건가요?
이번 장애는 정기 대광장 서비스 점검 절차 중 하나였던 서버 재부팅 단계에서 프록시 서버가 제대로 종료되지 못하고 예기치 못하게 응답없음 상태에 진입하면서 발생했어요.
프록시 서버의 시스템 로그를 분석해본 결과, 재부팅을 위한 시스템 종료 절차가 OS 레벨까지는 정상적으로 이루어졌는데, 일부 입출력 하드웨어에 종료 신호가 제대로 전달되지 못하여 무한 대기상태에 빠지면서 전원이 종료되지 못했고, 따라서 재부팅이 정상적으로 이루어지지 못한 것이 이번 장애의 직접적인 원인이었어요.
관리자가 물리적으로 프록시 서버를 재시작하면서 장애가 해결되었고, 이후 점검을 통해 이번 서비스 중단이 데이터 유출 등의 보안 사고가 아니라는 점을 확인할 수 있었어요.
향후 비슷한 장애의 재발을 막기 위해 어떤 점들이 보완되었나요? 향후 어떤 점들을 개선할 계획인가요?
이번 장애가 예상하지 못한 프록시 서버의 재부팅 실패에 의해 발생하였다는 점, 관리자가 물리적으로 서버를 확인할 수 없는 기간 중에 점검에 따른 장애가 발생하였다는 점을 고려하여, 향후 대광장 서버 점검에서는 다음과 같은 점을 보완하기로 결정했어요.
첫째, 앞으로는 대광장 서버의 재부팅을 최소화할 거에요. 지금까지는 한 달에 한 번씩 점검마다 필수적으로 서버를 다시 재시작하고 있었어요. 이는 불필요한 메모리 · 디스크 임시 파일 등의 자원을 회수하는 등의 효과로 서버가 쾌적하게 동작하는데 긍정적인 영향을 미치지만, 이번 장애와 같이 재부팅이 실패하는 경우에 서비스 중단으로 이어질 위험이 있어요. 앞으로는 서버 정기 점검 과정 중에서 소프트웨어 업데이트 등으로 꼭 필요한 경우에만 서버 재부팅을 실시함으로써 이러한 위험을 최소화할 거에요.
둘째, 앞으로는 대광장 서버의 점검일에는 물리적으로 서버에 접근할 수 있는 인원을 최소한 한 명은 확보해둘 거에요. 이번 장애는 물리적으로 서버를 재시작하면 손쉽게 해결될 수 있었지만, 관리자의 장기 출장과 사정으로 인하여 출장에서 돌아오는 경우 외에는 그렇게 할 수 없었기 때문에 장기화되었어요. 때문에 앞으로는 서버 점검일을 관리자가 서버에 물리적으로 접근할 수 있는 날짜나, 최소한 관리자가 신뢰할 수 있는 인원이 서버에 물리적으로 접근할 수 있는 날짜로 지정하여 진행할 거에요.
이번 장애가 하드웨어 및 커널 소프트웨어와 관련된 복합적인 재부팅 실패에서 일어난만큼, 하드웨어의 교체도 충분히 고려할 수 있어요. 하지만 하드웨어의 교체는 진행하지 않기로 결정했어요. 복구 이후 점검 및 진단 과정에서 하드웨어의 손상이나 오류를 발견할 수 없었다는 점, 또 근래 하드웨어 교체 비용이 상당히 높게 형성되었다는 점을 고려했어요.
정리하자면, 이번 장애가 재발하거나 재발하는 경우라 하더라도 서비스 중단이 장기화되지 않도록 하기 위해, 앞으로는 ① 대광장 서버의 재부팅을 최소화하고, ② 서버 점검일에는 물리적으로 서버에 접근할 수 있는 인원을 최소한 한 명 확보한 뒤에 점검을 진행할 거에요.
대광장 게시글 미디어 파일 손실 사고
구체적으로 무슨 일이 일어났던 건가요? 어떤 미디어 파일들이 영향을 받은 건가요? 제 데이터는 어떻게 된 거죠?
한국 시간(GMT+9)으로 2026년 9월 1일 즈음부터, 대광장 게시글에 첨부된 미디어 파일과 사용자 프로필 페이지의 '미디어' 탭에서 모아볼 수 있는 미디어 파일들이 모두 흐리게 보일 뿐 제대로 보이지 않는 문제들이 발생하기 시작했어요.
관리자가 이 문제를 인지한 것은 서비스 중단 장애를 복구시킨 이후 중단되었던 정기 서버 점검을 계속 진행하던 2026년 9월 11일 자정 경이었어요. 이후 관리자가 로그 분석을 통해 원인을 파악하고 미디어 저장소를 확인한 결과, 상당수의 로컬 미디어 파일들이 서버 디스크에서 소프트웨어적 오류로 인해 영구 삭제되면서 손실되었음을 발견할 수 있었어요.
이번 사고로 인해 영향을 받은 미디어(이미지, 동영상 등) 파일은 총 208개에요. 이들 중 111개의 파일(약 53.4%)은 대광장 구성원들이 업로드한 게시글에 첨부된 미디어 파일이고, 나머지 97개의 파일(약 46.6%)은 대광장과 연합된 외부 인스턴스에서 가져온 미디어 캐시 파일이에요. 여러분의 데이터와 관계되는 파일은 전자인 111개의 파일이에요.
이번 사고에서는 오직 대광장에서 볼 수 있는 게시글에 첨부된 미디어 파일들만이 영향을 받았어요. 여러분의 프로필 이미지, 프로필 헤더 이미지 등과 같이 게시글에 첨부되는 미디어를 제외한 다른 미디어들은 이번 사고의 영향권에 들지 않았고, 안전하게 보존되어 있어요.
이번 사고는 외부 공격 등 보안과 관련된 문제로 인해 발생한 것이 아니에요. 여러분의 데이터는 외부로 유출되지 않았으며, 내부적인 문제로 인해 대광장 내 서버에서 게시글에 첨부된 미디어 파일들이 잘못 삭제되면서 발생했어요.
손실 사고를 인지한 이후, 대광장 관리자는 어떤 조치를 취했나요?
관리자는 이 문제를 인지한 즉시 대광장 서버의 로그를 분석하여 손실 사고의 원인을 분석했고, 그 원인이 외부 공격이나 유출이 아닌 미디어 저장소를 자동으로 정리해주는 스크립트임을 발견했어요. 원인을 발견한 즉시 관리자는 이 스크립트의 자동 실행을 비활성화해두었어요.
이번 손실 사고는 왜 발생한 건가요?
이번 손실 사고는 매월 정기적으로 대광장의 미디어 저장소를 자동으로 정리해주는 스크립트의 중대한 소프트웨어적 오류로 인해 발생했어요.
사계 대광장은 매월 1일, 대부분의 디스크 용량을 차지하는 미디어 저장소가 불필요하게 늘어나는 것을 방지하기 위해 미디어 저장소 자동 정리 스크립트인 bin/tootctl media remove-orphans를 실행하고 있었어요. 이 스크립트는 내부 데이터를 확인하여 그 어떠한 게시물에도 첨부되지 않아 더 이상 불필요한, 즉 '고립된' 미디어 파일들을 자동으로 검출하고 삭제함으로써 불필요하게 저장 공간을 차지하고 있는 미디어 파일들을 정리해주고 있었어요.
이 스크립트의 실행은 기존 Mastodon 버전에서는 별다른 문제가 없이 정상적으로 이루어지지만, 몇 가지 기능을 자체적으로 추가하거나 변경한 사계 대광장의 mastodon-sakyey에서는 이 스크립트가 고립된 미디어 파일들을 검출하는데 쓰는 로직과 호환되지 않는 방식으로 미디어 파일들을 저장하는 방식을 채택해왔어요. 때문에 정상적으로 저장된 미디어 파일들이 이 스크립트에서는 고립된 미디어 파일들로 잘못 인식되었고, 스크립트의 실행에 따라 삭제된 것이 이번 손실 사고의 직접적인 원인이에요.
구체적으로 설명하면 아래와 같아요.
Mastodon 소프트웨어에서는 사용자가 게시글에 첨부한 미디어 파일에 대해 데이터베이스에 다음과 같은 두 개의 Key를 사용하여 파일을 저장하고 관리하고 있어요.
file_file_name: 첨부된 미디어 파일의 난수화된 이름file_meta (JSON): 첨부된 미디어 파일의 메타데이터 (가로/세로 해상도 등)
기존 Mastodon 소프트웨어의 경우, 사용자가 업로드한 미디어 파일이 안전하게 보관될 수 있도록, 업로드된 미디어 파일의 이름을 SecureRandom.hex(8) 함수를 사용해 고정 길이의 난수화된 이름으로 변경하고, 이를 데이터베이스의 file_file_name에 기록한 뒤 같은 이름으로 디스크의 저장소에 저장하는 방식을 취해요.
그런데 이와 같은 방식은 원본 파일 이름을 전혀 보존할 수 없는 문제가 있어요. 사계 대광장의 경우 PDF 첨부 파일을 지원하면서, 가독성을 위해 PDF 첨부 파일의 경우 원본 이름을 보존하여 다운로드시 원본 이름으로 받을 수 있도록 하면서도, 보안을 위해 디스크에는 난수화된 이름으로 저장하는 기존 방식을 유지하기 위해 2026-08-03에 배포된 mastodon-sakyey v2.0.0부터 다음과 같이 Mastodon과 조금 다른 방식으로 첨부된 미디어를 저장해왔어요.
file_file_name: 첨부된 미디어 파일의 원본 이름file_meta (JSON): 기존 메타데이터 + obfuscated_filename (난수화된 미디어 파일의 이름)
디스크에는 obfuscated_filename에 기록된 난수화된 미디어 파일의 이름으로 첨부된 미디어 파일을 저장하고, PDF 파일을 사용자가 다운로드 받는 경우는 데이터베이스의 file_file_name 값을 참고하여 첨부된 미디어 파일의 원본 이름으로 다운로드 받을 수 있도록 변경했어요.
그런데 이와 같은 변경은 미디어 저장소 자동 정리 스크립트인 bin/tootctl media remove-orphans의 동작 방식과 결부되면 다음과 같은 치명적인 문제를 발생시켰어요.
bin/tootctl media remove-orphans 스크립트는 Paperclip 모듈의 기본 검증 기능인 attachment.original_filename을 사용해 디스크에 있는 미디어 파일들이 데이터베이스에 있는 파일인지의 여부를 파일명 비교를 통해 하나씩 검사해요. 그런데 이 함수는 데이터베이스의 file_file_name 값만을 읽어올 뿐, file_meta JSON 값은 읽지 않아요.
기존 Mastodon 소프트웨어의 경우 데이터베이스의 file_file_name의 값과 실제 디스크에 저장된 파일 이름이 일치하기 때문에 자동 스크립트의 동작 과정에서의 파일명 비교가 정상적으로 이루어지지만, mastodon-sakyey의 경우 앞서 설명드렸던 것처럼 데이터베이스의 file_file_name에는 디스크에 저장된 난수화된 파일 이름과는 다른 원본 파일 이름이 저장되어 있어요. 때문에 자동 스크립트의 동작 과정에서 정상적인 파일도 파일명 비교의 실패로 '상응하는 게시글이 없는 고립된 미디어'로 분류되었고, 결과적으로는 상당수의 정상적인 파일들이 고립된 미디어로 분류되어 자동으로 삭제되었어요.
기존에 관리자는 사계 대광장에서 미디어 파일들이 상당한 저장소 용량을 차지한다는 점을 고려해 미디어 파일들에 대한 별도의 백업은 구성하지 않고 있었어요. 미디어 파일들이 대규모로 잘못 삭제되는 경우는 발생하지 않을 것이라는 잘못된 확신이 이 같은 치명적인 관리 오류가 일어나도록 했고요. 때문에 이번 소프트웨어 오류로 로컬 미디어 파일들이 대다수 삭제되었지만 별도의 백업이 없어 복구할 방법이 없고, 따라서 이번 사고에 영향을 받은 미디어 파일들은 영구 손실되게 되었어요.
미디어 파일들이 삭제되었는데, 왜 여전히 대광장에서는 이들 미디어가 '흐리게' 계속 보이는 건가요?
Mastodon 소프트웨어는 미디어를 업로드할 때, 미디어를 숨기거나 흐리게 처리하는 경우를 대비하기 위해 미디어 이미지를 대표하는 색상과 형상 정보를 수십 자의 텍스트 문자열로 인코딩하여 데이터베이스의 blurhash 값으로 저장해둬요.
웹 브라우저나 어플리케이션에서는 이미지를 띄울 때, 대광장 서버에서 디스크에 있는 실물 이미지 파일을 요청하기 전 미리 데이터베이스에서 전달받은 이 blurhash 값을 사용해 화면에 흐릿한 '가리기' 이미지를 미리 렌더링해요.
이번 사고에서는 미디어 파일들은 삭제되었지만, 그 미디어 파일들에 대해 데이터베이스에 저장되어 있는 blurhash 값들은 그대로 보존되었기 때문에 여전히 '흐린 가리기 이미지'는 계속 정상적으로 표시되고 있어요.
향후 비슷한 사고의 재발을 막기 위해 어떤 점들이 보완되었나요? 향후 어떤 점들을 개선할 계획인가요?
관리자는 이번 사고가 미디어 파일에 대한 백업의 부재, 소프트웨어적 오류에 대한 검수 실패 등 안일함으로 인해 발생한 중대한 사고임을 고려하여, 다음과 같이 관리 계획을 철저히 보완하고 소프트웨어적 문제들을 수정하기로 결정했어요.
첫째, 모든 로컬 미디어 파일들에 대해서는 최소 1회분의 백업 파일을 마련해두기로 했어요. 사계 대광장이 관리자의 개인적인 비용 부담으로 운영되고 있는 작은 서버라는 점을 고려하면 총량이 꽤 큰 편인 미디어 파일을 데이터베이스 등 다른 백업 파일처럼 1달 분량을 1주일 간격으로 보관하는 것은 현실적으로 어렵지만, 이번과 같은 사고가 발생하였을 경우 최소한 모든 미디어 파일들이 영구 손실되는 경우를 막기 위해서 앞으로는 1주일 간격으로 모든 로컬 미디어 파일들에 대한 백업 파일을 생성해 최소 1개 이상을 분리 보관하여 유지할 거에요. 원격 미디어 파일, 즉 사계 대광장이 아닌 다른 서버에 원본이 있는 미디어 파일들의 경우 다시 해당 서버에 요청하는 과정을 통해 받아올 수 있으므로 로컬 미디어 파일들을 백업하여 분리 보관하면, 최소한 미디어 파일과 관련된 사고가 일어나더라도 백업본을 이용해 상당수는 복구할 수 있을 거에요.
둘째, 이번 사고의 원인이 된 미디어 자동 정리 스크립트와 mastodon-sakyey의 미디어 파일 저장 방식의 차이에 의한 버그를 최우선 순위에 올려놓고 다음 mastodon-sakyey의 릴리즈에서 수정해 배포 · 적용할 거에요. 구체적으로는 데이터베이스 file_file_name 키에 업로드한 미디어의 원본 파일 이름을 저장해두는 방식을 원래 Mastodon처럼 난수화된 파일 이름, 즉 디스크에 저장된 파일 이름과 일치하는 파일 이름과 같은 것으로 저장하도록 변경하고, 원본 파일 이름은 file_meta의 JSON 데이터에 키를 추가하여 저장, PDF 첨부파일의 다운로드 시에는 이 file_meta에 저장된 원본 파일 이름을 참조하도록 변경할 거에요. 이렇게 하면 미디어 자동 정리 스크립트가 고립된 파일을 판별하기 위해 사용하는 파일 이름의 비교가 원래대로 정상적으로 이루어질 것이기 때문에 이번과 같은 문제가 재발하지 않을 거에요.
셋째, 이번 사고의 직접 원인이 된 미디어 자동 정리 스크립트, 즉 bin/tootctl media remove-orphans의 월별 자동 실행을 문제가 완전히 해결되었음이 검증될 때까지 중단할 거에요. 이렇게 하면 당분간 지속적으로 미디어 저장소 부담이 늘어나는 문제가 있지만, 여러분의 데이터를 안전하게 보존함으로써 서비스에 대한 신뢰를 지키는 것이 증가한 저장 비용 부담보다 우선한다고 판단했어요. 추후 오류를 수정한 mastodon-sakyey 버전을 철저하게 검증하여 같은 문제가 재발되지 않는다고 판단될 때만, 사계 대광장을 수정 버전으로 업그레이드한 뒤 다시 이 미디어 자동 정리 스크립트를 활성화할 거에요.
이번 사고를 통해 미디어 파일이 삭제된 게시글들은 어떻게 처리할 계획인가요?
이번 미디어 파일 손실 사고에 따라, 손실된 미디어 파일이 첨부된 게시글에 대해서는 관리자가 기술적인 방식으로 삭제된 미디어 파일을 게시글이 참고하지 않도록 약 2주 뒤인 2026-09-26 (GMT+9)에 조치할 예정이에요. 즉, 이번 사고에 의해 영향받은 미디어 파일이 계속 흐리게 표시되는 경우를 막기 위해, 게시글에 첨부된 미디어 파일 기록을 데이터베이스에서 직접 삭제할 예정이에요. 이렇게 하면 손실된 파일이 더 이상 게시글에서 보이지 않게 될 것이고, 또한 프로필의 '미디어' 탭에서도 손실된 파일들이 더 이상 보이지 않게 될 거에요.
하지만 경우에 따라서는 흐리게라도 이미지 보기를 유지하고 싶으실 수도 있고, 또 원본 파일을 가지고 있는 경우는 직접 파일을 다시 재첨부하여 게시글을 갱신하고 싶으신 구성원이 있을 수 있을 것 같아요. 그런 분들께서는 대광장 운영자 계정 @sakyey 또는 sakyey.official@gmail.com을 통해 자신의 계정 전체, 또는 특정한 게시물(게시물을 볼 수 있는 URL을 꼭 첨부해주세요!)들의 목록에 대해 미디어 삭제 조치를 원하지 않으신다는 의사를 보내주세요. 그 경우 관리자가 작업을 진행할 때, 해당 게시물이나 계정은 제외하도록 할게요.
