# 다 날아가도 다시 세우는 사람: 비개발자 1인이 운영하며 배우는 속도 > 출처: https://retn.kr/blog/solo-operator-learning-through-failures/ · 수정 2026-04-16 · 리텐션 주식회사 retn.kr 해킹 복구부터 부트캠프 결제 장애, 광고 오판, 그리고 소수 인원 운영에서 배우는 리질리언스까지. 운영자가 문제를 감지하고 복구하며 성장하는 과정을 정리했습니다. ## 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](http://ai.retn.kr/leaders?ref=retn.kr)로 바꿨다. 그 뒤 광고 성과가 체감상 무너지는 것처럼 보였다. 가장 먼저 든 가설은 이거였다. > “랜딩을 바꿔서 learning phase가 다시 시작된 건가?” 충분히 그럴듯한 가설이었다. 실제 퍼포먼스 마케팅에서는 랜딩 변경이나 구조 변경 뒤 성과가 흔들리는 일이 흔하다. 그런데 어떤 분이 문자로 결제 에러 코드를 보내주셨다. 그걸 보고 보니 문제는 광고가 아니라 **결제**였다. 기존에 20만 원에 바인딩돼 있던 값으로 토스페이먼츠 쪽 로직이 남아 있었는데, 실제로는 25만 원을 내려 하니 값이 맞지 않았다. 광고는 돈을 쓰고 있었고, 유입도 들어오고 있었지만, 정작 결제가 막혀 있었던 것이다. 광고비는 버렸다. 하지만 동시에 중요한 걸 배웠다. > “광고 성과가 이상해 보일 때, 광고부터 의심하면 늦을 수 있다.” 실제로는 더 아래 레이어를 먼저 봐야 할 때가 많다. 결제 성공률, 에러 코드, 웹훅, 가격 파라미터, 재고/좌석 수, API 응답, form submit 같은 것들 말이다. 이번에 다행이었던 건 피드백이 빨리 왔다는 점이다. 고객이 직접 에러 코드를 보여주셨고, 덕분에 바로 수정할 수 있었다. 하지만 동시에 더 분명해진 것도 있었다. **이걸 더 빨리 알 수 있는 구조가 필요하다.** 광고 유입은 있는데 결제 완료가 0으로 떨어지면 알림이 와야 하고, 가격 변경 뒤 결제 파라미터 mismatch가 생기면 배포 단계에서 잡혀야 한다. 운영은 판단력도 중요하지만, 그보다 먼저 **관측 가능성**이 중요하다. ## 3. 예전에는 누가 옆에서 알려줬고, 지금은 내가 다 알아내야 한다 예전 회사에서는 이런 문제를 내가 다 들고 있지 않았다. 누군가는 서버를 봤고, 누군가는 결제를 봤고, 누군가는 광고를 봤고, 누군가는 고객 반응을 먼저 감지했다. 나는 내 역할에 더 집중할 수 있었고, 다른 팀이 “이거 이상한데요?”라고 먼저 말해주는 구조 안에 있었다. 지금은 그 구조가 없다. 문제가 생기면 내가 보고, 내가 의심하고, 내가 고친다. 이건 동시에 자유롭고 무섭다. 특히 제일 스트레스 받는 건 “내가 모르는 것 중 무엇이 진짜 위험한지”를 모른다는 점이다. 나는 지금 꽤 빨리 배우고 있는 것 같지만, 그 속도가 객관적으로 빠른 건지 느린 건지 잘 모른다. 또 지금 당장 모르고 있는 unknown unknown 중 어떤 게 다음 장애로 터질지, 우선순위를 어떻게 둬야 할지도 항상 선명하지는 않다. 이 감각은 소수 인원으로 운영하면서 여러 역할을 동시에 떠안는 사람을 많이 지치게 만든다. “내가 너무 많은 걸 모르는 것 같은데, 이 상태로 계속 가도 되나?” 이 질문은 매우 정상적이다. 오히려 실제 운영을 해보는 사람일수록 자주 하게 된다. ## 4. 그래도 계속 이 방식을 유지하는 이유 그럼에도 불구하고 나는 지금 이 구조를 감수하고 있다. 왜냐하면 지금 내 실수의 하방은, 적어도 아직은 내가 감당 가능한 수준 안에 있기 때문이다. 장애가 나도, 광고비를 조금 태워도, 페이지가 깨져도, 복구 비용과 타격은 대부분 나에게만 온다. 좋다는 뜻은 아니다. 다만 이 구조에서는 **실수의 비용이 곧 학습의 재료**가 된다. 실제로 한 번 터진 문제는 다음에는 훨씬 빨리 보인다. - 사이트가 날아가면 스냅샷과 복구 절차의 중요성을 배운다 - 결제가 막히면 퍼널보다 결제 레이어를 먼저 보게 된다 - 키가 꼬이면 연동 시스템 전체를 함께 점검하게 된다 - 캐시 때문에 이상한 응답이 나오면, 애플리케이션과 CDN을 분리해서 본다 이게 반복되면서 리질리언스가 생긴다. 리질리언스는 “문제가 안 생기게 만드는 능력”만이 아니라, **문제가 생겼을 때 덜 흔들리고 더 빨리 복구하는 능력**이다. 그리고 이상하게도, 그게 쌓일수록 배우는 속도도 빨라진다. ## 5. 지금 나에게 필요한 건 ‘더 열심히’가 아니라 ‘더 빨리 알기’ 이번 두 사건을 지나고 나서, 내 운영 시스템에서 다음 단계는 명확해졌다. ### 1. 감지 구조 - 결제 실패 알림 - 유입 대비 결제 급락 알림 - 주요 페이지/폼/API 장애 알림 - 발송/웹훅 실패 알림 ### 2. 복구 구조 - 스냅샷/백업 정책 문서화 - 키 회전 프로토콜 정리 - 장애 복구 런북 정리 - 배포 전 체크리스트 표준화 ### 3. 학습 구조 - 장애를 감정적으로만 소비하지 않고 패턴으로 남기기 - “왜 틀렸는가”보다 “다음엔 어디서 먼저 감지할 것인가” 기록하기 - unknown unknown을 없애려 하기보다, unknown이 터졌을 때 대응 속도를 높이기 지금의 나는 여전히 모든 걸 알지 못한다. 하지만 모르는 상태에서도 운영을 계속하고, 문제를 고치고, 다음 시스템으로 반영하는 쪽으로는 분명히 나아가고 있다. 예전엔 이런 것들을 누가 옆에 딱 붙어서 알려줬어야 했다. 지금은 역할을 나눠도 내가 직접 붙어서 처리해야 하는 영역이 훨씬 많아졌고, 그 과정에서 스스로 알아내는 비중이 커졌다. 그게 더 비효율적인 것처럼 보여도, 실제로는 엄청 높은 밀도의 학습이 일어난다. 사이트가 털리면 복구를 배우고, 결제가 막히면 퍼널보다 관측 구조를 배우고, 광고가 흔들리면 랜딩보다 더 아래 레이어를 먼저 보게 된다. 이건 예전 같으면 각기 다른 팀이 나눠서 했을 일들이다. 지금은 소수 인원으로 그 경계를 훨씬 많이 넘나들면서 더 많이 틀리고, 더 많이 고치고, 더 빨리 배우고 있다. 혹시 지금 소수 인원으로 운영하면서 “내가 너무 많은 걸 모르고 있는 것 같은데, 이게 맞나?” 라는 스트레스를 받고 있다면, 그 감각은 아주 정상적이다. 오히려 그 감각이 있다는 건 이미 운영자의 시야로 세상을 보고 있다는 뜻일 수도 있다. 문제는 앞으로도 생길 것이다. 중요한 건 그걸 얼마나 빨리 감지하고, 얼마나 덜 흔들리며, 얼마나 다음 구조로 바꿔놓느냐다. 그리고 그건, 생각보다 작은 팀 안에서도 충분히 배울 수 있다. ## 다음 단계 ### 직접 적용해 보기 이 글을 읽고 바로 점검해볼 수 있는 건 아래 네 가지입니다. 1. 결제 실패를 즉시 감지하는 알림이 있는가 1. 운영 사이트를 되살릴 수 있는 스냅샷/백업이 있는가 1. 키 회전이 문서화돼 있는가 1. 광고, 결제, 발송, 웹훅 장애를 한 화면에서 볼 수 있는가 이 네 가지 중 하나라도 비어 있다면, 다음 장애는 “왜 터졌는가”보다 “왜 이렇게 늦게 알았는가”가 더 큰 문제가 될 가능성이 높습니다. ### 이런 팀에 특히 필요합니다 - 창업자나 초기 팀이 제품, 마케팅, 결제, 운영을 동시에 보고 있는 경우 - 개발자 없이 광고/랜딩/결제/CRM 자동화를 직접 붙이고 있는 경우 - 장애가 날 때마다 사람 갈아넣기로 복구하고 있는 경우 - 백업은 있는데 복구 런북은 없는 경우 ## 📞 운영 자동화·복구 구조 무료 상담 사이트 복구, 결제 장애 감지, 광고-랜딩-결제 연결, 키 회전 같은 운영 구조를 더 단단하게 만들고 싶다면 30분 무료 상담에서 현재 구조를 같이 진단해 드립니다. **상담에서 다루는 내용** - 현재 운영 구조의 단일 장애점 진단 - 결제/광고/발송/웹훅 알림 구조 설계 - 스냅샷/복구/키 회전 프로토콜 정리 - 소수 인원 팀에 맞는 AI 기반 운영 자동화 우선순위 **상담 예약** - 📧 [문의하기](/contact/?utm_source=blog&utm_medium=cta&utm_campaign=solo-operator-learning-through-failures) - 📅 [30분 무료 상담 예약](https://tidycal.com/simgyusup/30m?utm_source=blog&utm_medium=cta&utm_campaign=solo-operator-learning-through-failures) 운영은 결국 “안 터지게 하는 것”보다 “터졌을 때 빨리 감지하고, 빨리 복구하고, 다시는 같은 비용으로 틀리지 않게 만드는 것”에 가깝습니다. 그 구조를 함께 잡고 싶다면, 위 링크로 연락 주세요.