자커마스 블로그

서버 접속 불가 장애 원인 분석 및 재발 방지 대책

2026-04-24T15:00:00.000Z

먼저 사과의 말씀부터

안녕하세요. 자커마스를 운영하고 있는 유메카입니다.

2026년 4월 21일과 4월 25일, 총 세 차례에 걸쳐 자커마스를 포함한 서버 전체가 응답 불가 상태가 되어 강제 재부팅을 해야 했습니다. 이용하시던 분들께 불편을 드린 점 진심으로 사과드립니다.

이 글에서는 무슨 일이 있었는지, 왜 일어났는지, 앞으로 어떻게 방지할 것인지를 최대한 알기 쉽게 설명드리겠습니다.

장애 발생 일시

횟차	장애 인지 시각 (한국 시간)	복구 시각
1차	2026년 4월 21일 (화) 오전 5시 03분	오전 5시 12분 (재부팅 후 복구)
2차	2026년 4월 25일 (토) 오전 6시 19분	오전 6시 25분 (재부팅 후 복구)
3차	2026년 4월 25일 (토) 오전 10시 43분	오전 10시 48분 (재부팅 후 복구)

세 번 모두 SSH 접속(서버에 원격으로 접속하는 방법)이 완전히 차단되었고, 웹 서비스도 전부 응답하지 않았습니다. 서버가 켜져 있어도 아무것도 할 수 없는 상태였기 때문에 불가피하게 강제 재부팅을 진행했습니다.

원인: 서버의 메모리가 한계를 넘었습니다

메모리란 무엇인가요?

컴퓨터에는 저장 공간(하드디스크/SSD)과는 별개로 메모리(RAM) 라는 것이 있습니다. 하드디스크가 책장이라면, 메모리는 책상 위 공간입니다. 프로그램이 실행될 때는 반드시 메모리 위에 올라와야 하고, 책상이 가득 차면 아무것도 더 꺼낼 수 없게 됩니다.

이 서버의 메모리는 총 32GB입니다. 넉넉해 보이지만, 실제로는 그렇지 않았습니다.

서버에서 동시에 돌아가던 것들

이 서버 하나에는 단순히 마스토돈만 올라가 있는 게 아닙니다.

프로그램	역할	차지하는 메모리
Elasticsearch	마스토돈 검색 기능 담당	약 9 GB (고정)
Mastodon Puma (8개)	마스토돈 웹 서비스 처리	약 3.4 GB
Mastodon Sidekiq (2개)	마스토돈 백그라운드 작업	약 0.9 GB
Node.js (스트리밍)	실시간 타임라인 갱신	약 0.9 GB
Redis	임시 데이터 캐시	약 0.3 GB
authentik	로그인 인증 서비스	약 0.6 GB
기타 Python 서비스	부가 기능	약 0.4 GB
합계	ㅤ	약 16 GB 이상

여기에 운영체제 자체가 사용하는 메모리까지 더해지면, 여유 공간이 생각보다 훨씬 빠르게 줄어듭니다.

예비 메모리(스왑)도 너무 작았습니다

메모리가 부족해질 때를 대비해 하드디스크의 일부를 임시 메모리처럼 쓰는 방법이 있습니다. 이것을 스왑(Swap) 이라고 합니다. 그런데 이 서버의 스왑은 고작 2GB로 설정되어 있었습니다. 메모리가 한계에 달했을 때 2GB로는 버티기에 턱없이 부족했습니다.

실제로 얼마나 위험한 상태였나

서버 로그를 분석한 결과, 장애 당시 서버가 프로그램들에게 약속한 메모리 총량이 실제 처리 가능한 한계를 약 10.8GB 초과한 상태였습니다.

실제 처리 가능한 한계: 약 17.4 GB / 프로그램들에게 약속한 총량: 약 28.2 GB / 초과량: +10.8 GB

이 상태에서 프로그램들이 실제로 그 메모리를 전부 사용하려 하면, 운영체제는 공간이 없으니 강제로 프로그램을 종료시킵니다. 이것을 OOM Killer(메모리 부족 강제 종료) 라고 합니다. 이번 장애는 이 OOM Killer가 SSH나 마스토돈 같은 핵심 프로그램들까지 강제로 꺼버려 서버 전체가 응답 불가 상태가 된 것입니다.

로그가 남지 않은 이유(장애 분석까지 오래 걸린 이유)

"OOM Killer가 발동했다면 기록이 남아야 하지 않나?" 하고 의문을 가지실 수 있습니다. 맞는 말이지만, 이번처럼 극단적으로 메모리가 부족한 상황에서는 로그를 기록하는 프로그램(journald) 자체도 메모리 부족으로 종료되어버립니다. 그래서 장애 순간의 기록이 거의 남지 않습니다.

실제로 재부팅 후 서버 기록 파일이 "비정상 종료로 인해 손상됨" 이라는 메시지와 함께 교체된 것이 확인되었습니다. 이것이 서버가 정상적으로 종료된 게 아니라 갑자기 쓰러진 증거입니다.

장애가 하드웨어 문제는 아닌가요?

이번 분석에서 다음 항목들은 모두 정상임을 확인했습니다.

디스크 오류 없음 — 저장장치에 이상 없음 (디스크 사용량 61%, 여유 충분)

디스크 아이노드 정상 — 파일 개수도 여유 있음

커널 패닉 없음 — 운영체제 핵심 오류가 아님

하드웨어 오류 없음 — 메모리 칩 오류(MCE), CPU 과열 등 없음

네트워크 오류 없음 — 회선이나 네트워크 카드 문제 아님

자동 업데이트 연관성 없음 — 장애 당일 패키지 업데이트 기록 없음

원인은 순수하게 소프트웨어(메모리 관리) 문제였습니다.

재발 방지 대책

1. 스왑 공간 대폭 확장 ✅ 적용 완료

2GB에 불과했던 스왑을 16GB로 늘렸습니다. 메모리가 부족해지기 시작하면 하드디스크를 임시 메모리로 활용해 버틸 수 있는 시간이 확보됩니다. 속도는 다소 느려질 수 있지만, 서버가 완전히 쓰러지는 최악의 상황을 막는 데 중요한 역할을 합니다.

2. Elasticsearch 메모리 사용량 조정 ✅ 적용 완료

검색 담당 프로그램인 Elasticsearch가 기존에는 최소 9GB를 항상 독점하고 있었습니다. 32GB 서버에서 다른 서비스들과 함께 운영하기에는 과도한 양이었기 때문에, 이를 3~4GB 수준으로 낮춰 다른 프로그램들이 사용할 여유 공간을 확보했습니다.

3. 메모리 부족 경보 시스템 도입 ✅ 적용 완료

메모리 사용량이 일정 수준을 넘으면 관리자에게 자동으로 알림이 오는 시스템을 구축했습니다. 서버가 위험한 상태에 접어들기 전에 미리 조치를 취할 수 있게 됩니다.

4. 서버 모니터링 강화 ✅ 적용 완료

10분 단위로 CPU/메모리 사용량을 기록하는 시스템을 정기적으로 검토하는 체계를 갖췄습니다. 이상 징후를 조기에 발견해 장애로 이어지기 전에 대응할 수 있도록 했습니다.

마치며

이번 장애는 서버 관리자인 제가 서버 전체의 메모리 사용량 합계를 충분히 점검하지 않은 채 새로운 서비스들을 올린 결과입니다. 특히 4월 25일 하루에 두 번이나 장애가 발생한 것은, 첫 번째 재부팅 후에도 근본 원인이 해결되지 않았기 때문입니다.

위에서 말씀드린 대책들은 모두 이미 적용을 완료했습니다. 자커마스를 믿고 이용해 주시는 분들께 다시 한번 사과드리며, 더 안정적인 서비스를 제공할 수 있도록 노력하겠습니다.

감사합니다.

— 유메카

자캐커뮤용 마스토돈 운영하기 (1) - 타 서버 이용하기

2023-08-27T15:00:00.000Z

뭔가 이상하다고 생각하셨다면 정상입니다.

“자커마스”를 두고 굳이 다른 서버를 이용하는 가이드를, 그것도 “자커마스” 블로그에서 다룬다니요.

하지만, 잘못 보신게 아닙니다. 여긴 자커마스 블로그가 맞고 타 서버를 이용하는 가이드를 작성중인것도 맞습니다.

이 가이드는, 자커마스 서버의 불안정성으로 타 서버를 이용하시려는 분들께 도움이 되고자 작성되었습니다.

어느 서버로 가지?

어떤 이유에서건, 자커마스 서버를 이용하지 않기로 결정하셨다면 다른 서버로 가야 하는것은 당연합니다. 하지만, 무턱대고 아무 서버에나 들어갈 수는 없습니다. 만약 서버가 자커마스보다 작은 규모의 서버라면? 자캐커뮤 여러개가 몰려가면 예전 자커마스마냥 터져나갈수도 있습니다. 그 와중 서버 관리자분이 힘들어지는건 덤이고요.

특정 서버를 추천하기에는 해당 서버에게 민폐가 될 수 있으므로(자칫하다간 제2, 제3의 자커마스가 될수도) 커뮤니티 러닝에 적합한 서버를 찾는 방법만 알려드리겠습니다.

한국 마스토돈 연합위키나 나무위키 문서 참고해서 서버 찾기(p.s. 나무위키 문서중 나머지 부분은 부정확한 부분이 많으니 참고하지 않으시는걸 추천드립니다)

해당 서버 규칙을 보고 “자캐커뮤” 관련 규정이 있는지 확인하기. 예를 들어 마스토돈은 아니지만 미스키 기반 페이터는 미리 관리자에게 알려서 초대장 및 계정양식 등을 지정해야 합니다.

만약 관련 공지나 규정이 없다면 해당 서버 관리자에게 문의합니다. 모든 서버 운영자분들은 자발적으로 자원봉사 차원에서 운영하는 것이니 정중히 문의해 주세요.

자캐커뮤 운영 및 러닝이 가능하다면, 계정을 생성합니다. 경우에 따라 초대링크 발급을 위해 추가 문의가 필요할 수 있습니다.

(추가) 아이디는 가급적 (임의의 아이디)_커뮤약칭 등 최대한 추측이 힘든 아이디를 사용합니다. 이는 해당 서버에 아이디를 무의미하게 선점하여 피해를 주는 일을 막기 위함입니다. (예를 들어 일회성 커뮤용으로 @love 같은 아이디를 선점후 버린다면 그 이후 아무도 해당 아이디를 재사용할수 없습니다)

찾기 귀찮은데… 자캐커뮤 러닝이 가능한 서버 목록은 없나요?

자커마스를 제외한, 자캐커뮤 러닝이 가능한 서버는 다음과 같습니다.

플래닛(https://planet.moe) - https://planet.moe/@planet/110982616964439643 반드시 링크된 가이드라인을 정독해주세요.

모르겠고 당장 가입이 가능한 곳 없나요?

마스토돈 개발사에서 직접 운영하는 mastodon.social이나 mastodon.online 서버 이용도 방법 중 하나입니다. 단, 다음은 반드시 지켜주셔야 민폐/피해가 되지 않습니다.

계정은 수동으로 팔로워를 받도록 설정해주세요. 베타버전 기준 공개 프로필 → Privacy and reach → Automatically accept new followers를 체크 “해제”하시면 수동으로 팔로워를 승인할 수 있습니다.

기본 공개 범위는 “비공개”로 해주세요. 여러분들의 역극이 불필요하게 다른분에게 노출되는걸 막습니다. 설정은 환경설정 → 기타 → 게시물 프라이버시에서 가능합니다.

두 서버 모두 기본적으로 범용 서버인 만큼, 서버 관리자의 지원은 기대하시면 안됩니다. 서버 사용자가 많지만 개발사 직영인 만큼 제일 안정적입니다. 대신 가끔 가입이 몰리면 가입이 막힐 수 있습니다.(타 서버 분산 유도)

아이디 역시 위 서버를 찾는 방법 5번 참고하여 작성합니다.

서버 접속 불가능 이유, 원인 분석 및 재발 방지 대책

2023-05-29T15:00:00.000Z

안녕하세요. 자커마스/마라탕.인생/스플래터 3개 서버를 운영중인 유메카라고 합니다.

먼저, 29일 오후 9시 30분경 ~ 30일 오전 6시 50분까지 서버에 장애가 생겼던 이유에 대해 자세히 설명드리고자 합니다.

해당 서버는 서버의 안정적인 운영을 위해 실시간 복제와 별개로 한시간 단위 DB 스냅샷도 별도로 보존중입니다. 이는 백업 서버마저 사용 불가능해질 경우를 대비한 2차 백업이자, 작업중 실수로 DB를 지우더라도 손실을 최소화하기 위한 대책입니다.

이 한시간 단위 백업본은 서버 외부에 위치한 백업서버(라즈베리 파이로 구성한 홈서버입니다)로 이동되어 장기간 보관되고 있었습니다. 최근 해당 홈서버를 구동하던 USB 메모리가 과부하로 결국 뻗은 일이 있었습니다. 해당 서버에서 백업 진행과 동시에 오래된 백업본 파일을 삭제하도록 되어 있었는데 백업 자체가 장기간 실시되지 않으며 한시간 단위로 생성되던 백업본이 서버 하드디스크를 가득 채웠고, 서버 장애가 발생하였습니다.

이번 사건은 서버 관리자인 제 부실 관리로 벌어진 일로, 이번 일로 인해 피해를 입으신 모든 분들께 사과드립니다. 해당 백업본 파일로 인해 서버 장애가 발생하지 않도록 현재 백업본 정리 스크립트를 백업과 별개로 분리해 동작하도록 구성하였습니다. 즉 백업서버가 장애로 잠시 다운되어도 메인 서버에 장애가 발생하지 않습니다.

마스토돈에서 도메인을 바꿀 수 없는 이유

2023-03-08T15:00:00.000Z

오늘은 조금 짧은 글입니다. 최근 모 서버가 접속 도메인을 임의로 변경한 것이 밝혀졌습니다. 이 때문에, 해당 서버의 모든 유저는 타 서버와 교류가 끊기게 되었으며, 사실상 고립된 상태가 되어 버렸습니다. 이는, 마스토돈에서 도메인은 절대로 변경해서는 안되는 값이기 때문입니다. 그 이유를 오늘 간략히 알아보겠습니다.

마스토돈에서 아이디는 두가지 부분으로 나뉩니다.

yumeka@occm.cc 예를 들어, 제 아이디를 보면, yumeka와 occm.cc로 나뉜 것을 확인할 수 있습니다. 어딘가 비슷한 것이 보이나요? 네. 맞습니다. 이메일 주소와 완전히 동일한 형식입니다.

이해하기 쉽게 또다시 비유를 해보겠습니다. 지난번 정합성 훼손에 대해 다룬 글에서 비유했던 아파트를 그대로 가져오겠습니다.

트잉여 아파트, 큐돈 아파트, 플래닛 아파트가 있습니다. 그런데, 플래닛 아파트 주인장이 갑자기 플래닛이라는 이름이 마음에 들지 않는다며 아파트 이름을 마스로 변경했습니다. 이 작업은 쉽습니다. 설정 파일에서 플래닛이라 지정한 아파트 이름을 마스로 변경하면 될테니까요. (주: 단순 비유일 뿐 플래닛 서버가 도메인을 바꿀 일은 일어나지 않습니다!)

하지만 진짜 문제점은 지금부터 시작됩니다.

트잉여 아파트는 플래닛이란 이름의 아파트는 알지만, 마스라는 아파트는 알지 못합니다. 플래닛 아파트에서 이름을 바꾼 마스 아파트가 편지를 보내면 트잉여 아파트는 새로운 아파트가 생긴 것으로 알 수밖에 없습니다. 실제로는 플래닛 아파트인데도요. 당연히 트잉여 아파트 내 마스 아파트의 편지를 받아보겠다고 한 사람은 없으니 마스 아파트의 모든 편지는 누군가 “마스 아파트”의 편지를 받아보겠다고 나서기 전까지 전부 버려집니다. 이전에 플래닛 아파트의 편지를 받아보겠다고 한 사람까지 편지를 받아볼 수 없는 것이죠.

반대의 경우도 심각해집니다. 큐돈 아파트에서 편지를 보낼 땐 여전히 플래닛 아파트로 보낼 것입니다. 하지만 플래닛 아파트는 없으니 편지는 보내지지 않고, 마스 아파트(구 플래닛 아파트)의 거주민은 어떠한 편지도 받아볼 수 없게 됩니다.

즉 아파트 이름 하나 바꿨을 뿐인데, 완전히 고립이 되는 것입니다. 더군다나 뒤늦게 실수를 인정하고 되돌리기를 해도 또 문제점이 남습니다.

마스 아파트가 다시 플래닛 아파트가 되었다 해도, 그 사이 처음으로 마스 아파트와 교류한 아파트는 마스 아파트로 이름을 바꾸는 상황이 다시 생기게 됩니다. 서로 편지를 주고받을수 없게 되는것이죠. 또, “마스 아파트”로 이름을 바꾼 동안 교류한 내용은 기존 거주민이 아닌 새로운 거주민과 대화를 나눈것으로 기록되어 버립니다. 파편화가 되어 버리는 것이죠.

따라서, 절대로, 절대로 마스토돈 서버를 연 이상 도메인을 맘대로 바꿔서는 안되겠습니다.

마스토돈에서 “정합성 훼손”이란? (+ 서버 관리자가 명심해야 할 점)

2022-11-06T15:00:00.000Z

https://velog.io/@yangsijun528/무결성과-정합성이란-무엇인가 설명을 시작하기 전 글 하나 보고 가시겠습니다. 무결성과 정합성에 대해 개념을 정리한 글입니다.

해당 글에서 데이터 무결성은 데이터 값이 정확한 상태를, 정합성은 데이터 값이 서로 일치하는 상태를 의미한다고 설명하고 있습니다. 마스토돈을 이용하는 상황을 예로 들어 보겠습니다.

툿을 보낼 때 보낸 툿의 내용은 변경되어서는 안될것입니다. 예를 들어 “생일 축하해”라고 보낸 툿이 생ㅇ리 축하해”가 된다면 오해를 부를 거라는건 불보듯 뻔한 일이죠. 하지만 데이터 정합성은 여기에서 더 나아갑니다. 오늘 다룰 주제가 바로 이 “정합성”에 대해서, 그리고 이게 훼손되면 발생하는 일에 대해서입니다.

먼저, 정합성에 대해 이야기하기 전 마스토돈이 어떻게 다른 서버와 서로 소통하는지부터 간략히 알아봅니다.

이를 위해 아파트를 예시로 들어보겠습니다. 트잉여 아파트와 큐돈 아파트, 플래닛 아파트, 그리고 와르르 맨션이 한 도시에 있습니다. 아파트간 거리는 멀어서 대화할수 없습니다. 같은 아파트내 거주자끼리만 서로 대화할수 있죠. 이러한 서비스 형태의 예로는 기존 SNS 서비스들이 있습니다. 트위터/페이스북/인스타그램 같이요. 인스타그램 계정으로 트위터 계정에게 멘션을 보낼수는 없겠죠?

마스토돈과 같은 분산형 SNS에서는 조금 다릅니다. “편지”라는 것을 이용해서 아파트간 대화를 할 수 있습니다. 이 편지는 받는 아파트가 어떤곳이건(즉 아파트건, 맨션이건, 심지어 단독주택이더라도!) “편지”라는 규격을 이해한다면 내용을 볼수 있도록 해줍니다.

“편지”를 마스토돈에선 ActivityPub라고 부릅니다. ActivityPub를 이해하는 프로그램으로는 마스토돈도 있지만 플레로마나 미스키도 ActivityPub를 이해할수 있습니다. 이를 또다시 아파트에 비유하자면 아파트 단지에 위치한 우편함을 예로 들 수 있습니다.

우선 아파트 단지별로 관리인이 한명씩 존재한다고 가정해 봅니다. 이 관리인은 아파트에 온 편지를 보고 그 편지가 누구에게 보내진 건지 확인합니다.

만약 받는 주소에서 보낸 사람의 편지를 받는다고 미리 이야기해 뒀다면 편지를 받습니다.

하지만 편지를 받는다고 하지 않는 경우 그냥 버립니다.

하지만 그 호수가 반드시 읽어봐야 한다고 표시하면 그냥 보냅니다.(멘션이나 DM)

(덧. 실제로 팔로워가 하나도 없는데 공개툿이 서버로 보내지는 일은 없을겁니다. 하지만 비유를 위해 적습니다)

이 상황에서 트잉여 아파트 101호에 사는 사람이 플래닛 아파트 201호의 사람의 공개 편지(툿)을 받아보고 싶어합니다. 201호가 공개적으로 보내는 편지를 받아보고 싶어해요. 그렇다면, 201호가 편지를 보낼 때 101호한테도 보내달라고 이야기를 해야합니다. 이를 위해 101호는 201호에 편지를 한통 씁니다.

저는 트잉여 아파트 101호입니다. 플래닛 아파트 201호의 공개 편지를 받아보고 싶어요.

201호는 모든 요청을 아무 조건 없이 받아주는 곳이라 바로 답장을 씁니다.

저는 플래닛 아파트 201호입니다. 트잉여 아파트 101호에게도 앞으로 공개 편지를 보낼게요.

그리고 공개 편지를 보낼 대상에 트잉여 아파트 101호도 추가합니다.(팔로워) 트잉여 아파트 101호는 플래닛 아파트 201호에게서 온 공개 편지는 의심하지 않고 받아보기 위해 따로 기록해 두고요.(팔로잉)

플래닛 아파트 201호의 편지만 받는건 지루합니다. 그래서 큐돈 아파트의 303호의 공개 편지도 받아보고 싶어졌습니다.

저는 트잉여 아파트 101호입니다. 큐돈 아파트 303호의 공개 편지를 받아보고 싶어요.

하지만 큐돈 아파트 303호는 조금 까다롭습니다. 좀 더 고민해 보겠다고 답장을 보냅니다.

저는 큐돈 아파트 303호입니다. 트잉여 아파트 101호에게 공개 편지를 보내는건 조금 더 고민해 보겠습니다.(좌물쇠 계정=팔로워 수동 승인)

시간이 조금 지나고, 큐돈 아파트 303호가 결정했습니다. 트잉여 아파트 101호에게도 공개 편지를 보내기로요. 답장을 다시 해줍니다.

저는 큐돈 아파트 303호입니다. 트잉여 아파트 101호의 요청을 허락하니 앞으로 제 공개편지를 받아볼 수 있습니다.

아까와 똑같이 큐돈 아파트 303호는 공개 편지를 보낼 대상에 트잉여 아파트 101호를 추가합니다.(팔로워) 트잉여 아파트 101호도 큐돈 303호의 공개 편지를 의심하지 않고 받아보기 위해 따로 기록해 둡니다.(팔로잉)

여기에서 뭔가 눈치채셨나요? 네. “팔로우”라는 과정을 진행하면서 트잉여 아파트, 플래닛 아파트, 큐돈 아파트가 모두 각각 기록을 따로 남겼습니다. 뭔가 불필요해 보이는데 말이죠. 하지만 이 과정중 하나라도 빠지면 이상한 상태가 됩니다.

이번에는 와르르 맨션이라는, 이상한 아파트를 예로 들어 보겠습니다. 이 아파트의 관리인은 건망증이 심해서 처리해야 하는걸 자꾸 빼먹어 버립니다. 공개 편지를 보낼 대상을 기록하는걸 빼먹은 경우를 예로 보겠습니다.

와르르 맨션의 401호가 트잉여 아파트 201호의 공개 편지를 받기 위해 편지를 쓰고, 승인을 받습니다.(아까 설명했으니 자세히 또 적진 않을게요!) 근데… 하필 와르르 맨션 관리자가 빼먹고 공개 편지를 받아볼 대상(팔로잉)에 트잉여 아파트 201호를 추가하지 않았습니다. 이렇게 되면 나중에 트잉여 아파트 201호에서 공개 편지를 보내도 모르는 사람이 보내는 편지가 되서, 편지를 읽지 않고 버리게 됩니다. 불쌍한 401호는 트잉여 아파트 201호의 편지를 받아보고 싶었는데 못 받아보게 되고요.

반대의 경우도 문제가 됩니다. 이번엔 플래닛 아파트 301호가 와르르 맨션 502호의 공개 편지를 받아보기 위해 요청을 보냈고 승인을 받았습니다. 아뿔싸! 이번에도 와르르 맨션 관리자가 실수해서 502호가 공개 편지를 보낼 대상(팔로워) 목록에 301호를 추가하지 않았습니다. 이렇게 되면 플래닛 아파트 301호는 와르르 맨션 502호의 공개 편지를 받아보겠다고 했지만 아무것도 못 받아보게 됩니다.

이를 보고 “정합성이 훼손되었다”고 표현합니다. 두 아파트 모두가 같은 상태여야 하는데 달라져 버리는거죠. 와르르 맨션의 관리자가 실수를 눈치채고 바로잡지 않는다면 두 아파트간 교류는 일어나지 못할 겁니다.

이러한 일이 일어나는 이유는 주로 다음과 같습니다.

마스토돈 베타 버전에서, 개발자의 실수로 인해

마스토돈 코드를 임의 수정하며, 실수를 해서

첫번째의 경우 보통 해결방법도 같이 제시해줍니다. 마스토돈 개발사에서 운영하는 인스턴스는 개발 중인 버전을 선적용하기 때문입니다. 하지만 두번째 경우, 즉 코드 임의 수정의 경우 임의 수정을 한 본인이 책임져야 합니다. 관리인의 실수가 다른 사람이 잘못 시킨것라면 시킨 사람에게 책임을 물을수 있지만 관리인 본인의 실수라면 스스로 책임을 져야 하는것입니다.

이 글을 통해 당부드리고 싶은 것은, 만약 본인이 위 사례와 같은 일이 생겼을때 바로잡을 수 있는 지식이 없다면 함부로 코드를 수정하거나, 베타버전을 적용해서는 안된다는 것입니다. 정합성이 훼손되면 해당 서버의 유저 뿐만 아니라 다른서버의 사용자까지 피해를 줄수 있으니까요.

자커마스 백업 시스템 소개

2022-10-17T15:00:00.000Z

자커마스는 일본에 위치한 가상서버 업체의 서버를 사용하고 있습니다. 12코어 CPU에 48기가 메모리로 마스토돈 구동 정도에는 충분한 사양이죠. 하지만 서버 제공 업체의 사정으로 얼마든지 서비스가 중단될 수 있습니다. 이번 글에서는 자커마스가 이러한 경우에 어떻게 대비하고 있는지 간략하게 알아보겠습니다.

먼저 자커마스의 사용자 데이터에는 툿이나 계정 정보가 담기는 데이터베이스, 업로드한 이미지나 동영상과 프로필 사진 등으로 구성된 미디어로 나뉩니다.

자커마스의 미디어는 한국에 위치한 서버에 매일 백업되고 있습니다. 여기서 의문점이 생길수 있습니다. 미디어라면 엄청나게 많을 텐데 매일 백업이 가능한가요? 라고요. 새로 생기거나 변경되는 파일만 rsync라는 프로그램으로 동기화하고 있기에 큰 부담 없이 미디어를 백업할 수 있습니다. 추후 미디어 역시 일정 주기로 전체 복제하는 방안을 고민중입니다.

미디어 파일을 별도 백업서버에 저장하고 있는 모습

데이터베이스는 두가지 방식으로 백업되고 있습니다.

첫번째는 데이터베이스 실시간 복제입니다. 자커마스에서 여러분들이 작성하는 툿이나, 설정한 계정 정보 등은 실시간으로 백업서버에 전송됩니다. 백업서버는 평상시에는 아무 역할도 하지 않으며 대기하다, 메인 서버에 장애가 발생하면 곧바로 전환되어 동작하게 됩니다.

실시간 데이터 복제가 이루어지고 있는 모습

두번째는 일반적인 한시간 단위 백업입니다. 설령 자커마스 서버가 서버 제공업체 사정으로 폭발함과 동시에 백업서버마저 사라지더라도 서비스를 재개할수 있게 합니다.

1시간 단위 데이터 백업본을 받아오고 있는 모습

공유 주소 수정하기 - og:url

2022-10-04T15:00:00.000Z

자커마스 블로그 글을 공유하면 아마 다음과 같이 표시되었을 겁니다.

하지만 일부 서비스에서는 블로그 글 대신 블로그 메인 페이지로 이동했을겁니다. 이는 og:url 값이 엉뚱하게도 블로그 메인 주소로 설정되어 있었기 때문입니다.

og:url을 설명하기 전, 대체 “og”가 무엇인지 짧게 짚고 넘어가겠습니다. og는 Open Graph의 약자입니다.

Open Graph Protocol은 어떤 웹 페이지를 소셜 미디어 등에 공유했을때 어떻게 보일 것인지 지정하는 방식을 표준화할 목적으로 만들어졌습니다. 즉 기존에는 트위터면 트위터의 방식으로, 페이스북이면 페이스북의 방식으로 정보를 지정했다면 이것을 하나의 태그 - 제목(og:title), 종류(og:type), 미리보기 이미지(og:image), 주소(og:url)와 같이 - 로 지정할 수 있도록 개발된 것입니다.

위 공유된 모습에서 글 제목과 설명이 표시되고, 이미지가 뜰 수 있는것도 오픈 그래프 규격에 따라 값을 미리 입력해서 가능했습니다.

하지만 일부 서비스에서는 og:url 값을 이용해 링크를 만들었는데, 이 값이 글 주소와 무관하게 같은 블로그 메인을 가리키고 있어 문제가 생겼습니다.

https://github.com/Lastorder-DC/blog.occm.cc/blob/main/components/Container.js#L35-L38 하지만 문제가 생깁니다. 분명 og:url은 slug(글마다 정해진 고유값)에 따라 변경되도록 구성되어 있는데도 주소가 항상 같았던 것이죠. 즉 meta.slug 라는 값이 비어있다는 결론을 내립니다.

https://github.com/Lastorder-DC/blog.occm.cc/blob/main/layouts/layout.js#L29 코드를 따라 가며 근원을 확인해 본 결과, 원인은 의외로 단순했습니다. 글을 읽은 뒤 slug라는 이름으로 값을 보내야 하는데도 title(제목)과 description(설명)와 같은 값만 보낼 뿐 slug를 보내지 않고 있던것입니다. 위 한줄을 추가하자 언제 문제가 있었냐는듯 주소가 잘 설정되기 시작했습니다.

개발중인 마스토돈 그룹 기능 소개

2022-10-03T15:00:00.000Z

마스토돈은 최근 NGI0 Discovery 기금 지원을 받아 여러 새 기능을 추가해가고 있습니다. (NLnet의 마스토돈 페이지)

타 인스턴스의 콘텐츠나 이미지 자동 삭제 기간 설정

다른 인스턴스에서 보낸 툿이나 이미지/동영상은 별도로 삭제하지 않는 한 반영구적으로 보관되었는데 이제 일정 기간이 지나면 자동 삭제할 수 있습니다.

번역 기능 추가

DeepL과 LibreTranslate를 지원하는데 아쉽게도 DeepL은 한국어를 지원하지 않고 LibreTranslate의 한국어 번역 능력은 아직 좋지 못하답니다.

팔로우중인 유저의 툿 중 특정 언어로 된 툿만 볼수 있는 기능 추가

예를 들어 영어, 한국어를 모두 구사하는 사용자라면 한국어 툿만 볼수 있는 기능입니다.

필터 기능 강화

이전에는 단어 하나씩 차단되던 것을, 여러개를 묶어 차단할수 있습니다.
차단시 그냥 필터링되었다고 표시되던 것도 어떤 이유로 차단된 것인지 알 수 있어요.

알림 강화(가입, 신고)

가입시, 새 신고가 들어올시 알림 기능이 추가되었습니다.

오늘은 이 중 그룹 기능에 대해서 알아보겠습니다. 편의상 ~해요 체를 사용하도록 하겠습니다.

타 인스턴스와 소통을 지양하는(그러나 불가능한것은 아닙니다!) 자커마스에는 다른건 큰 변화점이 아니지만, 다음 기능은 큰 변화점이에요.

그룹 기능 추가

그룹을 만들고 그룹 관리자를 지정할 수 있습니다.
그룹에 가입시 승인을 거쳐야 가입되도록 할 수 있습니다.
그룹에서 보낸 툿은 타임라인에 보이지 않습니다.
관리자는 그룹내 유저를 추방할 수 있습니다.

어디서 많이 보던 기능이지 않나요? 네! 트위터의 그룹 DM 기능과 매우 유사한 기능입니다. 차이점이라면 DM과 달리 마스토돈의 그룹 기능은 기본적으로 타임라인 형태로 되어 있을뿐만 아니라 멘션 등 기존 타임라인에서 사용하던 기능도 쓸 수 있다는점이겠네요.

아, 지금 기능을 소개하는 시점에서 그룹 기능은 아직 활발히 개발중인 기능이에요. 여기 소개한 기능이 나중에 적용될때는 없어졌을수도 있어요. 정식 추가되는 시점에서 다시 글을 작성할게요.

이렇게만 보면 이해가 가지 않으니 동영상으로 보여 드리겠습니다. 이 아래 첨부된 이미지나 영상은 모두 기능 추가 PR에 첨부된 것이니 영어를 잘 하신다면 읽어보시는것도 추천드려요.

아직도 이해가 되지 않으시다면… 사진으로도 정리해 봤어요.

로그인하지 않으면 위와 같이 표시됩니다.

그룹에 툿을 보내려면 평상시 지구본/좌물쇠를 선택하던 부분에서 특정 그룹 한정 보이게 합니다! 라고 설정하면 됩니다. 한번 설정해 두면 브라우저를 새로고침하기 전까지 유지도 가능해요.

관리자가 허가해야 툿이 보이게 할 수도 있어요. 관리자가 거부한 툿은 본인만 볼 수 있답니다. 자캐 커뮤니티라면 러너가 보낸 툿이 잘못되었다면 다른 사람에게 보이기 전 거부하고, 잘 작성된 툿만 보이게 설정할수도 있겠죠? 활용도는 무궁무진해요.

이외 관리자는 그룹 구성원을 보거나 가입 대기 사용자를 볼 수 있고요,

사용자를 추방하거나 그룹에 다시는 참여할 수 없도록 할수도 있어요.

굉장히 대단한 기능이죠? 개인적으로 마스토돈에서 자캐 커뮤니티를 진행할때 가장 큰 애로사항이 그룹 DM의 부재였는데 기능이 추가된다면 훨씬 편해질것 같아서 블로그 글을 작성하게 되었어요.

서버 재부팅 예정

2022-10-03T15:00:00.000Z

서버 보안패치 적용과 DB 마이그레이션 작업을 위해 2022년 10월 4일 22시부터 약 10분간 서버 재부팅 예정입니다.

10분간 서버 접속이 불안정할 수 있으며, 해당 시간 동안 발송된 툿은 발행되지 않을 수 있습니다.

양해 부탁드립니다.

OCCM Mastodon 소개

2022-10-03T15:00:00.000Z

OCCM Mastodon은 마스토돈을 자커마스에 맞게 수정한 버전입니다. 소스코드는 이 저장소에서 자유롭게 다운로드하실 수 있습니다.

OCCM Mastodon과 일반 마스토돈 버전의 차이점은 다음과 같습니다.

계정 생성시 기본 프라이버시 옵션이 “타임라인에 비표시”입니다.(모두가 볼 수는 있으나 프로필 페이지, 로컬/연합 타임라인에는 비표시)

한국어 검색 토크나이저가 기본 적용되어 있습니다. 조사가 붙어있어도 잘 인식됩니다.

예를 들어 “마스토돈”을 검색했다면 토크나이저 미적용시 조사 없이 마스토돈이라 작성한 다음 툿만 검색됩니다.

마스토돈 정말 좋아요
저 마스토돈 계정 만들었어요

토크나이저 적용시 조사가 붙은 다음 툿도 검색됩니다.

마스토돈에 계정 만들었어요
저는 마스토돈을 좋아해요

마스토돈 자체 검색 제한으로 내 툿이나, 내가 교류한 상대방의 툿만 찾아볼 수 있습니다. 이외 해시태그를 사용한 검색은 자유롭게 가능합니다. (즉 트친소 해시태그를 사용하면 내가 교류한적이 없는 상대방의 툿도 찾을수 있습니다)

해시태그를 사용한 툿의 예시는 다음과 같습니다

#XX커뮤_트친소 XXX캐릭터 러닝했었던 YYY라고 합니다!
#커뮤홍보 XX커뮤를 홍보합니다!

이외 마스토돈 소스코드 저장소에는 적용되었지만 버전업데이트가 되지 않아 반영되지 않은 중요한 변경사항을 미리 반영하는 경우도 있습니다.

설치 방법은 기본적으로 마스토돈 설치 방법과 같습니다만, 설치시

🐘

git clone https://github.com/tootsuite/mastodon.git live && cd live

대신

🇰🇷

git clone https://github.com/Lastorder-DC/mastodon.git live && cd live

를 사용해주시면 됩니다.

혹시나 특정 버전 설치가 필요하다면 git checkout 명령을

🇰🇷

git checkout v3.5.3-occm1

와 같이 입력해주세요.