TLDR
- 운영하던 retn.kr가 해킹으로 훼손됐지만, AWS Lightsail 자동 스냅샷으로 복구했다. 핵심 교훈은 “문제가 안 생기게 하는 것”보다 문제가 생겼을 때 얼마나 빨리 복구하느냐가 더 중요하다는 점이었다.
- AI coding bootcamp 운영 중 결제 금액 mismatch 때문에 전환이 막혔고, 처음에는 메타 광고 learning phase를 의심했지만 실제 원인은 더 기초적인 레이어에 있었다. 이 경험은 광고 성과보다 먼저 봐야 할 운영 관측 지표가 있다는 걸 알려줬다.
- 예전엔 이런 문제를 옆에서 알려주는 사람이 있었지만, 지금은 소수 인원으로 역할을 나눠도 내가 보고, 추론하고, 고쳐야 하는 범위가 훨씬 넓다. unknown unknown이 많다는 불안은 크지만, 실수의 하방이 감당 가능한 환경에서는 망가뜨리고 복구하는 경험 자체가 학습 속도와 리질리언스를 끌어올린다.
1. 사이트가 털리고, 그래도 다시 살릴 수 있다는 걸 알게 됐다
운영하는 사이트 retn.kr가 해커에게 털려서 글이 거의 다 날아갔다.
이건 “사이트가 잠깐 이상하다” 수준이 아니었다. 콘텐츠가 사라졌고, 관리 화면과 설정, 키, 연동 상태까지 한 번에 의심해야 하는 상황이었다. 당장 해야 하는 일도 많았다. 지금 손상이 어디까지 퍼졌는지, 뭘 먼저 막아야 하는지, 무엇을 살릴 수 있는지 판단해야 했다.
결론적으로는 AWS Lightsail 자동 스냅샷 덕분에 사이트를 다시 살렸다.
그런데 여기서 중요한 건 “복구했다”는 결과보다, 그 복구를 비개발자 1인이 끝까지 해냈다는 사실이었다.
물론 단순하지 않았다. 스냅샷 인스턴스를 올리고, 정적 IP를 옮기고, Ghost 키를 다시 발급하고, Mailgun과 DB 비밀번호를 돌리고, Cloudflare 캐시까지 만져야 했다. 데이터는 살아났지만, 운영 환경은 그대로 되돌아오지 않았다. 되돌려야 했다.
이 과정을 겪고 나서 제일 크게 남은 문장은 하나였다.
운영에서 중요한 건 “절대 안 망하는 시스템”이 아니라, “망가졌을 때 빠르게 돌아오는 시스템”이다.
예전에는 백업이나 스냅샷을 “혹시 모를 대비책” 정도로 생각했다. 이번에는 그게 아니라 사업을 다시 켜는 레버라는 걸 몸으로 배웠다.
2. 광고가 무너진 줄 알았는데, 사실 결제가 먼저 무너지고 있었다
나는 AI coding bootcamp도 사실상 소수 인원 체제로 운영하고 있다.
에릭은 현재 강의와 B2B 리드 생성 및 nurture를 맡고 있고, 제품 수정, 인프라, 결제, 광고 랜딩, 사이트 운영 같은 나머지 실행은 대부분 내가 맡고 있다.
원래는 일요일 6시간짜리 20만 원, 월요일 3.5시간짜리 10만 원으로 두 개를 나눠 운영했는데, 월요일 반은 잘 차지 않아서 폐강시키고 일요일 정원과 총 러닝 타임을 늘렸다. 그리고 이 변경에 맞춰 랜딩, 가격, 결제 플로우, 광고 유입 경로도 직접 손봤다.
그 과정에서 메타 광고 랜딩을 홈이 아니라 ai.retn.kr/leaders로 바꿨다. 그 뒤 광고 성과가 체감상 무너지는 것처럼 보였다. 가장 먼저 든 가설은 이거였다.
“랜딩을 바꿔서 learning phase가 다시 시작된 건가?”
충분히 그럴듯한 가설이었다. 실제 퍼포먼스 마케팅에서는 랜딩 변경이나 구조 변경 뒤 성과가 흔들리는 일이 흔하다.
그런데 어떤 분이 문자로 결제 에러 코드를 보내주셨다. 그걸 보고 보니 문제는 광고가 아니라 결제였다.
기존에 20만 원에 바인딩돼 있던 값으로 토스페이먼츠 쪽 로직이 남아 있었는데, 실제로는 25만 원을 내려 하니 값이 맞지 않았다. 광고는 돈을 쓰고 있었고, 유입도 들어오고 있었지만, 정작 결제가 막혀 있었던 것이다.
광고비는 버렸다. 하지만 동시에 중요한 걸 배웠다.
“광고 성과가 이상해 보일 때, 광고부터 의심하면 늦을 수 있다.”
실제로는 더 아래 레이어를 먼저 봐야 할 때가 많다. 결제 성공률, 에러 코드, 웹훅, 가격 파라미터, 재고/좌석 수, API 응답, form submit 같은 것들 말이다.
이번에 다행이었던 건 피드백이 빨리 왔다는 점이다. 고객이 직접 에러 코드를 보여주셨고, 덕분에 바로 수정할 수 있었다. 하지만 동시에 더 분명해진 것도 있었다.
이걸 더 빨리 알 수 있는 구조가 필요하다.
광고 유입은 있는데 결제 완료가 0으로 떨어지면 알림이 와야 하고, 가격 변경 뒤 결제 파라미터 mismatch가 생기면 배포 단계에서 잡혀야 한다. 운영은 판단력도 중요하지만, 그보다 먼저 관측 가능성이 중요하다.
3. 예전에는 누가 옆에서 알려줬고, 지금은 내가 다 알아내야 한다
예전 회사에서는 이런 문제를 내가 다 들고 있지 않았다.
누군가는 서버를 봤고, 누군가는 결제를 봤고, 누군가는 광고를 봤고, 누군가는 고객 반응을 먼저 감지했다. 나는 내 역할에 더 집중할 수 있었고, 다른 팀이 “이거 이상한데요?”라고 먼저 말해주는 구조 안에 있었다.
지금은 그 구조가 없다.
문제가 생기면 내가 보고, 내가 의심하고, 내가 고친다. 이건 동시에 자유롭고 무섭다.
특히 제일 스트레스 받는 건 “내가 모르는 것 중 무엇이 진짜 위험한지”를 모른다는 점이다.
나는 지금 꽤 빨리 배우고 있는 것 같지만, 그 속도가 객관적으로 빠른 건지 느린 건지 잘 모른다.
또 지금 당장 모르고 있는 unknown unknown 중 어떤 게 다음 장애로 터질지, 우선순위를 어떻게 둬야 할지도 항상 선명하지는 않다.
이 감각은 소수 인원으로 운영하면서 여러 역할을 동시에 떠안는 사람을 많이 지치게 만든다.
“내가 너무 많은 걸 모르는 것 같은데, 이 상태로 계속 가도 되나?”
이 질문은 매우 정상적이다. 오히려 실제 운영을 해보는 사람일수록 자주 하게 된다.
4. 그래도 계속 이 방식을 유지하는 이유
그럼에도 불구하고 나는 지금 이 구조를 감수하고 있다.
왜냐하면 지금 내 실수의 하방은, 적어도 아직은 내가 감당 가능한 수준 안에 있기 때문이다. 장애가 나도, 광고비를 조금 태워도, 페이지가 깨져도, 복구 비용과 타격은 대부분 나에게만 온다. 좋다는 뜻은 아니다. 다만 이 구조에서는 실수의 비용이 곧 학습의 재료가 된다.
실제로 한 번 터진 문제는 다음에는 훨씬 빨리 보인다.
- 사이트가 날아가면 스냅샷과 복구 절차의 중요성을 배운다
- 결제가 막히면 퍼널보다 결제 레이어를 먼저 보게 된다
- 키가 꼬이면 연동 시스템 전체를 함께 점검하게 된다
- 캐시 때문에 이상한 응답이 나오면, 애플리케이션과 CDN을 분리해서 본다
이게 반복되면서 리질리언스가 생긴다.
리질리언스는 “문제가 안 생기게 만드는 능력”만이 아니라, 문제가 생겼을 때 덜 흔들리고 더 빨리 복구하는 능력이다.
그리고 이상하게도, 그게 쌓일수록 배우는 속도도 빨라진다.
5. 지금 나에게 필요한 건 ‘더 열심히’가 아니라 ‘더 빨리 알기’
이번 두 사건을 지나고 나서, 내 운영 시스템에서 다음 단계는 명확해졌다.
1. 감지 구조
- 결제 실패 알림
- 유입 대비 결제 급락 알림
- 주요 페이지/폼/API 장애 알림
- 발송/웹훅 실패 알림
2. 복구 구조
- 스냅샷/백업 정책 문서화
- 키 회전 프로토콜 정리
- 장애 복구 런북 정리
- 배포 전 체크리스트 표준화
3. 학습 구조
- 장애를 감정적으로만 소비하지 않고 패턴으로 남기기
- “왜 틀렸는가”보다 “다음엔 어디서 먼저 감지할 것인가” 기록하기
- unknown unknown을 없애려 하기보다, unknown이 터졌을 때 대응 속도를 높이기
지금의 나는 여전히 모든 걸 알지 못한다.
하지만 모르는 상태에서도 운영을 계속하고, 문제를 고치고, 다음 시스템으로 반영하는 쪽으로는 분명히 나아가고 있다.
예전엔 이런 것들을 누가 옆에 딱 붙어서 알려줬어야 했다.
지금은 역할을 나눠도 내가 직접 붙어서 처리해야 하는 영역이 훨씬 많아졌고, 그 과정에서 스스로 알아내는 비중이 커졌다.
그게 더 비효율적인 것처럼 보여도, 실제로는 엄청 높은 밀도의 학습이 일어난다.
사이트가 털리면 복구를 배우고,
결제가 막히면 퍼널보다 관측 구조를 배우고,
광고가 흔들리면 랜딩보다 더 아래 레이어를 먼저 보게 된다.
이건 예전 같으면 각기 다른 팀이 나눠서 했을 일들이다.
지금은 소수 인원으로 그 경계를 훨씬 많이 넘나들면서 더 많이 틀리고, 더 많이 고치고, 더 빨리 배우고 있다.
혹시 지금 소수 인원으로 운영하면서
“내가 너무 많은 걸 모르고 있는 것 같은데, 이게 맞나?”
라는 스트레스를 받고 있다면, 그 감각은 아주 정상적이다.
오히려 그 감각이 있다는 건 이미 운영자의 시야로 세상을 보고 있다는 뜻일 수도 있다.
문제는 앞으로도 생길 것이다.
중요한 건 그걸 얼마나 빨리 감지하고, 얼마나 덜 흔들리며, 얼마나 다음 구조로 바꿔놓느냐다.
그리고 그건, 생각보다 작은 팀 안에서도 충분히 배울 수 있다.
다음 단계
직접 적용해 보기
이 글을 읽고 바로 점검해볼 수 있는 건 아래 네 가지입니다.
- 결제 실패를 즉시 감지하는 알림이 있는가
- 운영 사이트를 되살릴 수 있는 스냅샷/백업이 있는가
- 키 회전이 문서화돼 있는가
- 광고, 결제, 발송, 웹훅 장애를 한 화면에서 볼 수 있는가
이 네 가지 중 하나라도 비어 있다면, 다음 장애는 “왜 터졌는가”보다 “왜 이렇게 늦게 알았는가”가 더 큰 문제가 될 가능성이 높습니다.
이런 팀에 특히 필요합니다
- 창업자나 초기 팀이 제품, 마케팅, 결제, 운영을 동시에 보고 있는 경우
- 개발자 없이 광고/랜딩/결제/CRM 자동화를 직접 붙이고 있는 경우
- 장애가 날 때마다 사람 갈아넣기로 복구하고 있는 경우
- 백업은 있는데 복구 런북은 없는 경우
📞 운영 자동화·복구 구조 무료 상담
사이트 복구, 결제 장애 감지, 광고-랜딩-결제 연결, 키 회전 같은 운영 구조를 더 단단하게 만들고 싶다면 30분 무료 상담에서 현재 구조를 같이 진단해 드립니다.
상담에서 다루는 내용
- 현재 운영 구조의 단일 장애점 진단
- 결제/광고/발송/웹훅 알림 구조 설계
- 스냅샷/복구/키 회전 프로토콜 정리
- 소수 인원 팀에 맞는 AI 기반 운영 자동화 우선순위
상담 예약
- 📧 문의하기
- 📅 30분 무료 상담 예약
운영은 결국 “안 터지게 하는 것”보다 “터졌을 때 빨리 감지하고, 빨리 복구하고, 다시는 같은 비용으로 틀리지 않게 만드는 것”에 가깝습니다.
그 구조를 함께 잡고 싶다면, 위 링크로 연락 주세요.