2026년 6월 28일 새벽 3시경에 발생한 아주 따끈따끈한 일입니다.

개요

팀원(서여라고 부르겠습니다)은 우테코를 하고 있고, 저 또한 긴 취준으로 무료함을 느끼던 차에 같이 프로젝트를 시작하게 되었습니다.

현재는 서여씨가 운영 중인 개인 블로그 서버에 같이 올리는 방식으로 진행되고 있었습니다.

저는 AWS EC2로 서버를 운영해본 경험이 있었고, 어차피 추후 EC2로 옮길 예정이라면 지금 미리 옮겨도 나쁠 게 없지 않을까? + CI/CD 코드도 어차피 수정해야 한다는 이유로 이전을 제안했습니다.

하지만 여러 이유를 고려한 끝에 일단은 서여씨의 개인 서버에서 함께 개발하기로 합의를 봤습니다.

---

사건의 발단

권한이 필요했습니다

저는 CI/CD를 구축하고, 개인 서버에 MySQL 설치를 시도했습니다.

하지만 서여씨는 저에게 제한된 권한만 준 상태였기 때문에 sudo 명령어가 실행되지 않았고, 저는 권한을 달라고 요청했습니다.

큰 문제가 없을 것이라고 생각했던 서여씨는 저에게 sudo 권한을 주게 됩니다.

이상한데...?

하지만 이미 개인 블로그가 운영 중인 서버였기 때문에 MySQL은 이미 설치되어 있는 상태였습니다.

당연히 root 비밀번호도 이미 설정되어 있었겠죠.

그런데 저는 같이 사용하는 서버라는 사실을 잠시 망각한 채,

“왜 새로 설치했는데 root 설정이 안 되지…?”

라는 생각만 하고 있었습니다.

그리고...

하면 안 되는 일을 저질러버립니다.

이때까지만 해도 아무 문제를 느끼지 못했습니다. (약 새벽 3시)

오히려 "오? 이제 된다" 이러고 앉아있었습니다 ㅋㅋ

짜잔, 블로그가 있었는데요 없었습니다

그러다가 갑자기 서여씨가 본인의 개인 블로그가 이상하다고 말을 합니다...

개인 블로그 글들이 모두 사라졌다고..

(소오름)

원인을 파악해보니 Vercel은 정상적으로 동작하고 있었고, 서버에서 MySQL에 문제가 생긴 것 같았습니다.

어라...? 지금 MySQL 만진게 나밖에 없을텐데...?

등골이 서늘해지고 서여씨의 목소리는 떨리기 시작했습니다.

MySQL 뭐 만진거 아니지...?

저는 이제야 퍼즐이 맞춰지기 시작했습니다.

왜 MySQL을 새로 설치했는데도 root 초기 설정이 나오지 않았는지

하하…

타자와 심장박동 모두 빨라졌습니다.

???

예름이는 정신이 완전히 나가버렸습니다.

어떻게든 문제를 해결하기 위해 초당 300타 수준으로 Codex에게 질문을 쏟아붓기 시작했습니다.

일단 할 수 있는걸 다 해보던 도중 무언가를 발견합니다.

무슨 백업이 보입니다..!! 여기서 정말 사막의 오아시스 마냥 약간의 희망을 발견합니다.

알고보니 작년 8월 경 서여씨가 데이터베이스 자동 백업을 설정한 것이었습니다.

(출처: 서여씨 블로그)

그 뒤부터는 백업 파일을 이용해 데이터베이스를 복구했고,

다행히 개인 블로그도 정상적으로 살아났습니다!!! ㅜㅜ

---

이번 사건을 통해 배운 것

약 3시간 동안 정말 멘붕, 공포, 안도 등 온갖 감정을 다 느꼈던 것 같습니다.

무엇보다 서여씨가 이 블로그를 얼마나 아끼고, 글 하나를 쓰기 위해 얼마나 많은 시간을 투자하는지 옆에서 계속 봐왔기 때문에 저도 정말 많이 놀랐습니다.

그래도 정말 다행이었던 건, 예전에 서여씨가 자동 백업을 설정해둔 덕분에 데이터를 전부 복구할 수 있었다는 점입니다.

이번 경험을 통해 크게 세 가지를 몸으로 배웠습니다.

데이터베이스 백업은 반드시 해두자

이번에는 정말 운이 좋았습니다.

서여씨의 자동 백업이 없었다면 그동안 작성한 몇십개의 블로그 글이 모두 사라질 수도 있었습니다.

개인 프로젝트라고 해서 안일하게 생각하는 경우도 많을 것입니다.

하지만 오히려 개인 프로젝트일수록 운영자가 한 명인 경우가 많기 때문에 장애가 발생했을 때 복구할 사람이 없습니다.

그래서 작은 프로젝트라도 최소한 아래 정도는 꼭 준비해야 한다고 생각합니다.

• 주기적인 자동 백업
• 백업 파일이 실제로 생성되고 있는지 확인
• 복구 절차를 한 번쯤 직접 연습해보기

백업은 “혹시 모르니까 해두는 것” 이 아니라

언젠가는 반드시 필요해질 것을 대비하는 것이라는 걸 몸소 깨달았습니다.

권한 분리의 중요성

지금까지 프로젝트를 하면서는 항상 새로운 서버를 만들었고, 그렇기 때문에 자연스럽게 root 계정으로 모든 작업을 진행했습니다.

그래서 권한 분리가 왜 필요한지 크게 와닿지 않았습니다.

하지만 이번 경험을 통해 특정 사용자에게 필요한 권한만 부여하는 이유를 정말 뼈저리게 체감했습니다.

저는 단순히 MySQL을 설치하려고 했을 뿐인데,

sudo 권한 하나 때문에 운영 중이던 서비스의 데이터베이스까지 건드릴 수 있는 상황이 되어버렸습니다.

회사에서 개발자마다 필요한 권한만 부여하고, 운영 서버에서는 최소 권한 원칙(Principle of Least Privilege)을 적용하는 이유를 이번에 제대로 이해하게 되었습니다.

리눅스마스터 2급을 따고 처박아놨던 책을 다시 꺼내봐야겠습니다...

소통의 중요성

이번 일을 돌이켜보니 기술적인 실수도 있었지만, 결국 가장 큰 원인은 소통 부족이었습니다.

제가 sudo 권한을 요청했을 때 “MySQL 설치가 안 돼서 권한이 필요하다” 라고 한마디만 더 설명했더라면,

반대로 서여씨도 “왜 sudo 권한이 필요한데?” 라고 한 번만 더 물어봤더라면, (책임전가 아닙니다 제가 백 번 잘못했습니다)

아마 이 사건은 발생하지 않았을 수도 있습니다.

사건이 끝난 뒤 둘이 이야기를 하면서도 가장 많이 했던 말이 바로 “우리 둘 다 소통이 부족했다” 였습니다.

누군가의 잘못이라기보다 서로 당연하다고 생각했던 부분들이 겹치면서 만들어진 사고였던 것 같습니다.

이게 개인 프로젝트라서 다행이지

만약에 회사였다면...? (시말서 100장 각)

---

그래서 앞으로는

이번 사건을 통해 저희는 몇 가지 원칙을 세우게 되었습니다.

• 프로젝트는 가능한 한 빨리 별도의 EC2 환경으로 마이그레이션하기
• 리눅스 권한 관리를 다시 공부하고, 필요한 권한만 부여하기 (root 무지성 사용 금지)
• 작업을 시작하기 전에 무엇을 하려는지 먼저 공유하기
• 서버 구성과 운영 환경을 조금 더 자세하게 문서화하기

새벽 3시에 정말 식은땀을 흘렸지만, (사실 12시간이 지난 지금도 머리가 뜨겁습니다)

덕분에 백업의 중요성, 권한 관리의 중요성, 그리고 무엇보다 소통의 중요성을 몸으로 배우는 하루였습니다.

긴 글 읽어주셔서 감사합니다.
혹시 진행중인 프로젝트가 있다면 꼬옥 백업해두시길 권장드립니다... 제발...
그리고 너무 심한 말은 삼가 부탁드립니다.. 흑흑

---

번외

sudo 압수당해서 배포 실패

번외 2

ㄷㄷ 트렌딩 감사합니다