TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 22 READS

1인 개발자의 공개 사과문 — 데이터를 지운 건 버그였지만, 복구 기회를 지운 건 나였다

1인 개발자의 공개 사과문 — 데이터를 지운 건 버그였지만, 복구 기회를 지운 건 나였다
SOURCE IMAGE · HACKER NEWS
1인 개발자의 공개 사과문 — 데이터를 지운 건 버그였지만, 복구 기회를 지운 건 나였다

수면 추적 앱 '다크 아워스(Dark Hours)'를 3년째 혼자 운영하는 개발자 테리 고디어가 공개 사과문을 올렸어요. 4만 명이 쓰는 앱의 서버 운영, 고객 응대, 업데이트를 전부 혼자 하는 전형적인 1인 개발인데요. 이 글이 인상적인 이유는, 흔한 장애 보고서가 아니라 '내가 왜 잘못된 판단을 내렸는가'를 정면으로 해부하는 글이기 때문이에요.

무슨 일이 있었나

지난 3월, 그는 동기화 방식을 자체 프로토콜에서 CRDT로 갈아타는 업데이트를 배포했어요. CRDT가 뭐냐면 '충돌 없는 복제 데이터 타입'이라고 해서, 여러 기기가 오프라인에서 제각각 수정해도 나중에 합칠 때 충돌 없이 자동으로 병합되는 자료구조예요. 요즘 로컬 퍼스트 앱이나 협업 도구에서 많이 쓰죠. 문제는 업데이트 후 첫 실행 때 도는 마이그레이션에 버그가 있었다는 거예요. iOS는 백그라운드로 내려간 앱을 수시로 강제 종료하는데, 하필 첫 동기화 중에 앱이 죽으면 로컬 DB에 톰스톤(어떤 데이터가 삭제됐다는 표시)이 그 데이터의 삽입보다 먼저 적용될 수 있었어요. 그러면 앱은 그 망가진 상태를 성실하게 서버로 올리고, 서버는 사용자의 다른 기기로 퍼뜨렸죠. 결과적으로 약 1,800명이 하루치에서 최대 11개월치의 수면 기록을 잃었어요.

진짜 사과해야 했던 부분

그런데 글쓴이가 정말로 사과하는 대상은 버그가 아니에요. 첫 제보는 3월 14일에 들어왔는데, 그는 1년간 준비한 리디자인 출시를 앞두고 있었고, 재현이 안 된다는 이유로 '사용자 문제일 것'이라고 스스로를 설득했대요. iCloud 설정을 확인해 보라는 정중한 답장을 보내면서요. 본인 표현으로는 '더 많은 정보를 기다린 게 아니라, 그냥 멈추기를 바랐다'는 거죠. 4월 중순까지 제보가 61건으로 늘었고, 마르타라는 사용자가 기기 모델, 앱 버전, 데이터가 사라진 정확한 타임스탬프를 폰과 아이패드에 걸쳐 정리한 스프레드시트를 보내왔어요. 개발자가 해야 할 일을 사용자가 대신 한 거예요. 그런데 그때는 이미 늦었어요. 백업 보존 기간이 30일이었는데 그 사용자의 손실은 43일 전이었거든요. 3월의 제보를 진지하게 받았다면 피해자 전원을 복구할 수 있었던 창이 한 달 동안 열려 있었고, 그는 그 한 달을 리디자인에 썼던 거죠. 본인이 계속 곱씹게 되는 문장이라고 해요.

그 이후의 조치

기술적으로는 2단계 마이그레이션으로 고쳤어요. 톰스톤을 격리해 뒀다가 대응하는 삽입이 확인된 뒤에만 적용하고, 로컬 상태가 서버로 올라가기 전에 전체 DB 체크섬을 서버와 대조하는 방식이에요. 백업 보존은 30일에서 18개월로 늘렸는데 스토리지 비용이 9배가 됐대요. 1인 개발 매출에는 뼈아프지만 '당연히 치러야 할 비용'이라고요. 30일 창 안에 있던 1,100명은 복구했고, 데이터가 영구히 사라진 나머지 700명에게는 이 글을 올리기 전에 개별 이메일을 보내고 그동안 낸 돈 전액을 환불했어요. 일하는 방식도 바꿨어요. 데이터 손실 관련 제보는 그럴듯한지 따지지 않고 무조건 기능 개발보다 앞에 두고, 사용자 환경을 재현하기 전까지는 '사용자 문제'로 결론 낼 권한이 자신에게 없다고 정했고, 마이그레이션은 앱 강제 종료를 시뮬레이션하는 스테이징을 통과해야 배포되게 했어요. 상태 페이지도 만들어서 창피한 장애일수록 더 공개하기로 했고요.

우리가 배울 것

큰 회사들은 장애 후 '비난 없는 포스트모템'을 쓰는 문화가 정착돼 있지만, 1인 개발이나 작은 팀은 이걸 강제할 조직이 없어요. 그래서 이 글의 규율이 더 값진데요, 몇 가지는 규모와 무관하게 바로 가져갈 수 있어요. 첫째, 백업 보존 기간은 '버그를 발견하는 데 걸리는 시간'보다 길어야 의미가 있어요. 30일 백업은 30일 안에 알아챈 버그만 구해줘요. 둘째, 데이터 손실 제보가 들어오면 재현이 안 되더라도 일단 해당 사용자의 백업 스냅샷부터 따로 보존해 두는 게 순서예요. 판단은 그다음이고요. 셋째, 마이그레이션 코드는 '중간에 죽는 경우'가 예외가 아니라 기본 시나리오예요. 특히 OS가 앱을 수시로 죽이는 모바일에서는요.

한 줄 정리: 데이터를 지운 건 버그였지만, 복구 가능성을 지운 건 한 달간의 외면이었다. 여러분의 서비스는 백업 보존 기간이 며칠인가요? 그리고 '재현 안 되는 제보'가 들어왔을 때, 여러분 팀은 어떤 기준으로 사용자 문제와 우리 문제를 가르고 있나요?


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://blog.terrygodier.com/2026/08/09/mea-culpa-dark-hours...
SHARE
처리 중...