소프트웨어 서비스의 가용성을 이야기할 때 '99.9%'라는 숫자가 자주 등장합니다. 연간 기준으로 계산하면 약 8.7시간의 다운타임이 허용되는 수치입니다. 시스템이 1년에 8.7시간 동안 멈출 수 있다는 뜻인데, 이것이 "세 개의 9"라고 불리는 업계 기본 기준입니다.
그런데 옥수가 구축한 자동화 시스템 중 하나는 2023년 말 납품 이후 2년 8개월이 지난 지금까지 "고장 났다"는 연락이 온 적이 없습니다. 담당자가 바뀌었고, 그 담당자가 다시 바뀌었는데도 시스템은 계속 돌아가고 있습니다. 그 연락의 내용은 유지보수 요청이 아니라 재구매 의사와 추가 의뢰였습니다.
자동화 시스템은 도입 직후보다 6개월, 1년 이후가 더 중요합니다. 처음 설정이 잘 됐더라도 환경 변화에 버티지 못하는 시스템은 결국 방치되거나 다시 손을 봐야 합니다. 2년 8개월 동안 연락이 없었다는 것은 그 동안 아무 일도 없었다는 뜻이 아닙니다. 담당자가 바뀌었고, 업무 방식이 조금씩 달라졌을 것입니다. 그럼에도 시스템이 계속 돌아간 것은 변화에 흔들리지 않는 구조로 만들었기 때문입니다.
이 글은 그 이유를 설명하는 글입니다. 기술 자랑이 아닙니다. 왜 특정 방식으로 설계하는지, 그 선택이 왜 장기 운영에서 차이를 만드는지를 씁니다.
무중단이 실제로 어떤 의미인가
무중단이라는 말을 쉽게 씁니다. 그런데 이것이 얼마나 어려운 일인지 먼저 정리합니다.
소프트웨어 시스템은 외부 환경에 의존합니다. 외부 API가 변경되거나, 구독 중인 플랫폼이 정책을 바꾸거나, 사용 중인 도구가 업데이트되면서 기존 동작과 충돌이 생깁니다. 플랫폼 자체는 잘 돌아가지만 연결된 외부 서비스가 변경되면 전체 흐름이 끊깁니다.
99.9% 가용성을 달성하더라도 연간 약 8.7시간은 서비스가 멈출 수 있습니다. 의존하는 외부 서비스가 많을수록 그 다운타임이 예측 불가능한 시점에 찾아옵니다. 어느 날 아침 자동화가 작동하지 않아 확인해보니 어제부터 멈춰 있었던 상황 — 이것이 의존성이 높은 시스템에서 흔히 겪는 장애 패턴입니다.
무중단 운영을 위한 설계에서 핵심 원칙 중 하나가 의존성 최소화입니다. 외부 서비스와의 연결 지점을 줄이고, 연결이 필요할 때는 연결이 끊기더라도 전체가 멈추지 않도록 처리하는 구조를 설계하는 것입니다. 고가용성 시스템 설계에서 서킷 브레이커 패턴과 큐 기반 비동기 처리가 이를 위한 대표적인 방법으로 꼽히는 이유도 같습니다. 외부 연결이 반복 실패할 때 일시적으로 연결 시도를 중단하고 나머지 흐름은 계속 돌아가게 하는 것, 즉각적인 처리가 필요하지 않은 작업은 큐에 넣고 비동기로 처리하는 것이 각각의 역할입니다.
그러나 기술적 설계만으로는 충분하지 않습니다. 더 근본적인 선택이 있습니다.
우리가 선택한 설계 방향
옥수가 구축하는 자동화에는 반복되는 패턴이 있습니다. 고객이 이미 쓰고 있는 도구 위에서 만드는 것입니다.
처음에 상담을 받으면 이런 질문을 드립니다. "지금 어떤 도구를 쓰고 있나요?" 엑셀인지, 구글 스프레드시트인지, WordPress인지. 그리고 대부분의 경우 그 도구 위에서 자동화를 구성합니다. 새 플랫폼을 구독하게 하지 않습니다.
이 선택이 무중단 운영과 직결됩니다.
외부 자동화 플랫폼 위에 구축하면 해당 플랫폼의 정책 변화가 곧 고객 시스템의 영향으로 이어집니다. 플랫폼 요금제가 바뀌거나 특정 기능이 유료로 전환되는 순간, 그 위에 구축된 자동화도 함께 영향을 받습니다. 구독을 중단하면 시스템도 멈춥니다.
구글 스프레드시트나 WordPress는 다릅니다. 구글이 스프레드시트 서비스를 급격히 변경하거나 중단하는 일은 거의 없습니다. WordPress는 2003년부터 운영되어온 플랫폼입니다. 이미 쓰고 있는 도구 위에 구축하면, 의존하는 외부 변수가 처음부터 줄어듭니다.
두 방식의 차이를 정리하면 이렇습니다.
| 구분 | 외부 플랫폼 구독 방식 | 기존 도구 위 구축 방식 |
|---|---|---|
| 장애 원인 | 플랫폼 정책·요금 변경 | 도구 사용 오류 (직접 대응 가능) |
| 운영 지속 조건 | 구독 유지 필요 | 기존 도구 수명에 의존 |
| 장기 안정성 | 플랫폼 존속에 의존 | 담당자 운영 역량에 의존 |
어느 방식이 절대적으로 좋다는 것이 아닙니다. 지속적인 기능 추가가 필요하거나 외부 연동이 복잡한 시스템은 전문 플랫폼 위에 구축하는 것이 맞을 수 있습니다. 그러나 중소기업의 반복 업무 자동화는 대부분 "있는 도구를 잘 연결하면 해결된다"는 범위 안에 있습니다. 이 경우에는 기존 도구 위의 구축이 장기 안정성에서 유리합니다.
설계 선택이 운영에서 만드는 차이
비교표에 정리된 두 방식의 차이는 추상적인 구분이 아닙니다. 실제 운영 환경에서 어떤 형태로 나타나는지 구체적으로 설명합니다.
외부 플랫폼 위에 구축된 자동화는 특정한 패턴으로 문제가 생깁니다. 플랫폼이 요금제를 개편하면서 무료로 사용하던 기능이 유료로 전환됩니다. 연동하던 API의 호출 한도나 응답 방식이 변경되면서 자동화 흐름이 끊깁니다. 대시보드 UI가 전면 개편되면서 담당자가 알던 설정 위치가 사라집니다. 이런 변화들은 예고가 있는 경우가 많습니다. 그러나 여러 개의 자동화가 여러 개의 외부 서비스에 각각 의존하고 있다면, 그 중 하나의 예고를 놓치는 것은 시간 문제입니다.
기존 도구 위에 구축된 시스템에서도 문제는 생깁니다. 차이는 원인의 성격입니다. 파일이나 시트의 구조가 바뀌었거나, 설정값이 수정되었거나, 계정 권한이 변경된 경우가 대부분입니다. 이런 변화는 직접 확인하고 되돌릴 수 있습니다. 외부 서비스의 정책 결정을 기다릴 필요가 없습니다. 담당자 수준에서 원인을 찾고 조치할 수 있다는 것이 핵심 차이입니다. 어느 날 아침 자동화가 작동하지 않아 확인해보니 며칠 전부터 멈춰 있었던 상황과, 설정 한 곳을 수정하면 즉시 복구되는 상황은 운영 부담이 전혀 다릅니다.
자동화에서 변경 지점이란 외부에서 일방적으로 바꿀 수 있는 모든 요소를 말합니다. 의존하는 외부 플랫폼의 정책, 사용 중인 API의 사양, 연동된 서드파티 서비스의 존속 여부가 여기에 해당합니다. 이 변경 지점을 줄이는 것이 장기 안정성의 실질적인 방법입니다.
의존성을 완전히 없앨 수는 없습니다. 구글 스프레드시트도 외부 서비스이고, Claude API도 외부 서비스입니다. 중요한 것은 의존 대상의 안정성을 선택 기준으로 삼는 것입니다. 수십 년간 서비스를 유지해온 도구, 갑작스러운 정책 변경 가능성이 낮은 기반을 선택하는 것이 장기 운영에서 현실적인 방법입니다. WordPress가 2003년부터 운영되어온 플랫폼이라는 사실, 구글이 스프레드시트 서비스를 급격히 중단하거나 변경하는 시나리오가 현실적으로 낮다는 사실이 이 선택의 근거입니다.
실제 장기 안정성은 단일 요소가 아니라 여러 선택이 겹쳐서 만들어집니다. 어떤 도구 위에 구축하는지, 외부 의존을 어디서 끊는지, 운영자가 직접 다룰 수 있는 범위를 어디까지 설계하는지, 납품 후 운영자가 시스템 내부를 얼마나 이해하게 되는지. 이 선택들이 2년 8개월이라는 기간을 만들었고, 앞으로도 그 기간이 늘어나는 구조의 근거입니다.
실제로 구축하고 운영 중인 세 가지 사례
지금까지 납품한 시스템들이 어떻게 운영되고 있는지 구체적으로 설명합니다.
보험설계사 PDF 입력 자동화
보험사에서 오는 견적 PDF를 설계사 본인이 직접 만들어 쓰는 엑셀 템플릿에 자동으로 입력하는 시스템입니다. 기존 엑셀 템플릿을 그대로 유지했습니다. 새 도구를 구독하지 않았습니다. Claude와 프롬프트 설계를 통해 PDF 내용이 기존 템플릿 구조에 맞게 추출되는 흐름을 만들었고, 구축 후 설계사 본인이 혼자서도 계속 사용할 수 있도록 인수인계했습니다.
컨설팅은 구글 미트 원격으로 진행했고, 납품 이후 유지보수 연락이 없습니다. 만족도가 높아 재구매 의사와 함께 지금도 연락이 이어지고 있습니다. PDF를 열어놓고 엑셀에 한 칸씩 옮기던 수작업이 사라진 결과입니다.
업무 지시 자동 기록 체계
대표의 업무 지시를 스프레드시트에 자동으로 기록·정리하는 시스템입니다. 회사에서 이미 쓰던 스프레드시트를 그대로 유지했습니다. 새 업무관리 툴을 도입하지 않았습니다. ChatGPT와 Claude를 기존 스프레드시트에 연결해 지시사항이 자동으로 구조화되어 기록되는 흐름을 만들었습니다. 대표와 직원 모두 기존 방식대로 메신저에 지시를 보내면 시스템이 담당자·기한·내용을 정리해 시트에 기록합니다.
납품 이후 담당자가 교체되었지만 시스템은 중단 없이 운영되고 있습니다. 추가 자동화 의뢰로 협업이 이어지고 있습니다.
블로그 콘텐츠 자동화
기술 서비스 업체 T사의 현장 경험이 블로그 글로 자동 발행되는 시스템입니다. 기존 WordPress를 그대로 유지했습니다. 대표가 현장 경험을 말로 풀면 그 내용이 초안이 되어 기존 WordPress에 자동 발행되는 흐름을 만들었습니다. Claude와 WordPress를 직접 연결해 검토를 마친 글이 자동으로 발행되도록 연동했습니다.
납품 이후에도 추가 개선 요청으로 협업이 이어지고 있으며, 시스템 자체는 변경 없이 계속 운영 중입니다. "블로그 해야 하는데"가 "말만 하면 올라가는데"로 바뀐 결과입니다.
세 사례의 공통점은 하나입니다. 고객이 이미 쓰고 있던 도구를 그대로 뒀습니다. 새 플랫폼을 배우게 하지 않았고, 새 구독 요금이 생기지 않았습니다. 그리고 세 경우 모두 납품 이후에도 연락이 이어졌습니다. 기존 도구 위에 구축한다는 원칙이 실제로 어떤 결과를 만드는지 보여주는 세 가지 사례들입니다.
인수인계까지가 무중단 구조의 완성
유지보수 연락이 오지 않는 또 다른 이유가 있습니다. 인수인계입니다.
구축을 완료한 뒤 고객에게 넘겨드리는 것들이 있습니다. 시스템 작동 원리를 이해하기 쉬운 말로 설명합니다. 어떤 상황에서 어떻게 쓰면 되는지 실제로 해보면서 확인합니다. 자주 생길 수 있는 문제와 해결 방법을 미리 안내합니다. 프롬프트나 설정을 직접 조정할 수 있는 변경 지점을 알려드립니다.
기술을 잘 모르는 분이라도 일상적인 운영은 직접 할 수 있는 수준으로 넘겨드리는 것이 목표입니다. "고장 났을 때 어디에 연락하면 되나요?"보다 "이런 상황에서는 이렇게 하면 됩니다"를 알고 계신 상태가 되는 것이 진짜 인수인계입니다.
인수인계 과정에서 전달하는 것들이 있습니다. 시스템이 어떤 순서로 작동하는지 흐름을 이해하기 쉬운 방식으로 설명합니다. 가장 자주 생길 수 있는 상황과 그때의 대응 방법을 실제로 해보면서 확인합니다. 직접 조정 가능한 설정 지점과 건드리면 안 되는 부분을 구분해서 안내합니다. 처음 설계할 때의 의도를 전달합니다. 나중에 운영 방식이 바뀌거나 부분 수정이 필요할 때 그 의도를 알고 있어야 방향이 유지됩니다.
인수인계가 끝난 뒤에도 첫 한 달은 운영 중 발생하는 질문에 응답합니다. 실제로 쓰면서 생기는 상황과 준비 중에 예상한 상황이 다를 수 있기 때문입니다. 이 기간이 지나면 시스템은 독립적으로 돌아갑니다. 이것이 유지보수 연락이 오지 않는 두 번째 이유입니다.
담당자가 바뀌더라도 다음 담당자가 큰 어려움 없이 운영을 이어받을 수 있는 구조를 만드는 것 — 이것이 무중단 운영의 가장 사람 중심적인 측면입니다. 시스템이 기술적으로 안정적이어도 운영하는 사람이 바뀔 때마다 멈추는 시스템은 장기적으로 안정적이지 않습니다.
만든 사람이 계속 붙어있어야 돌아가는 구조로 만들지 않는 것이 원칙입니다. 그래야 납품 이후 월 이용료 없이도 끝낼 수 있고, 고객이 독립적으로 운영할 수 있습니다. 보험설계사 사례에서 납품 이후에도 연락이 이어지는 것은 의존 때문이 아니라 신뢰 때문입니다.
고객 입장에서 무중단의 의미
기술적 안정성 이야기를 고객 입장에서 번역하면 이렇습니다.
자동화를 도입하고 몇 달이 지나면 담당자는 그 자동화가 존재했다는 사실도 잊어버립니다. 매일 반복하던 수작업이 사라졌고, 그 빈자리에 다른 일이 채워집니다. 시스템이 조용히 돌아가고 있으니 챙길 이유가 없습니다. 이것이 잘 만들어진 자동화의 특징입니다.
반대의 경우도 있습니다. 자동화를 도입했는데 한 달에 한 번씩 "오늘 안 돌아가요"라는 상황이 생기면, 그 자동화는 수작업을 없앤 것이 아니라 새로운 수작업을 만든 것입니다. 자동화가 멈출 때마다 원인을 확인하고 재시작하는 것도 업무입니다. 이것은 자동화의 실패입니다. 시스템이 오히려 짐이 되는 상태입니다.
"만든 뒤 연락이 없다"는 것은 제품이 잘 돌아가고 있다는 신호입니다. 납품 이후 추가 의뢰로 연락이 오는 것은 첫 번째 시스템에 대한 신뢰 때문입니다.
자동화 도입 전 가장 많이 받는 질문 중 하나가 "잘 작동하다가 갑자기 멈추면 어떻게 하나요?"입니다. 좋은 질문입니다. 그 걱정을 설계 단계에서 줄이는 방향으로 구조를 짜는 것이 첫 번째 답이고, 담당자가 직접 원인을 확인할 수 있도록 인수인계하는 것이 두 번째 답입니다. "고장 났을 때 연락처"가 아니라 "고장 났을 때 스스로 확인하는 방법"을 아는 상태로 만드는 것이 목표입니다. 그 목표가 달성되면 연락이 오지 않습니다. 그 대신 추가 의뢰로 연락이 옵니다.
자동화 안정성을 진단하는 질문들
현재 운영 중인 자동화가 있거나, 새로 구축을 고려하고 있다면 아래 질문들이 판단에 도움이 됩니다.
이 자동화가 의존하는 외부 서비스는 몇 개인가요? 서비스 하나가 변경될 때 전체 흐름이 멈추는 구조인지, 일부만 영향을 받는 구조인지 확인합니다.
담당자가 바뀌었을 때 새 담당자가 운영을 이어받을 수 있나요? 기술 이해가 없는 사람도 일상적인 운영이 가능한 수준인지가 기준입니다.
한 달에 몇 번이나 자동화 관련 문제를 처리하고 있나요? 월 1회 이상이라면 그 자동화는 수작업을 없앤 것이 아니라 다른 형태의 수작업을 만든 것일 수 있습니다.
문제가 생겼을 때 원인을 직접 확인할 수 있나요? 외부 서비스 지원팀에 먼저 연락해야 한다면 외부 의존이 높은 구조입니다.
이 질문들에 명확히 답할 수 없는 상황이라면, 지금 운영 중인 자동화의 구조를 한 번 검토해보는 것이 도움이 됩니다. 새로 구축을 준비 중이라면 처음 설계 단계에서 이 기준을 반영하는 것이 나중에 고치는 것보다 훨씬 낫습니다.
이 구조가 맞지 않는 경우
솔직하게 말씀드립니다. 모든 상황에 이 방식이 맞지는 않습니다.
지속적인 기능 추가가 필요한 경우입니다. 구축 이후에도 매달 새 기능을 붙여야 한다면 유지보수 계약이 있는 방식이 더 효율적입니다. 옥수의 구조는 완성 이후 변화가 적은 반복 업무 자동화에 가장 잘 맞습니다.
외부 서비스 연동이 복잡한 경우입니다. 실시간으로 데이터가 오가는 외부 API가 여러 개 얽히거나, 높은 빈도의 트랜잭션을 처리해야 하는 구조는 단순 구축·인수인계로 끝내기 어렵습니다. 이런 경우에는 처음 상담에서 솔직하게 말씀드립니다.
내부 운영 담당자가 전혀 없는 경우입니다. 구축 후 아무도 관리하지 않는 환경이라면 문제가 생겼을 때 대응할 수 없습니다. 이 경우에는 오히려 유지보수 계약이 있는 구조가 더 맞을 수 있습니다.
진단에서 "이 경우엔 우리가 맞지 않는 것 같습니다"라고 말씀드린 경우가 있습니다. 맞지 않는 상황을 억지로 진행하면 결국 양쪽이 고생합니다. 그 선택이 장기적으로는 신뢰로 이어진다고 생각합니다.
비슷한 상황의 독자에게
자동화를 도입하고 싶은데 "나중에 안 쓰게 되면 어떡하지", "담당자가 바뀌면 누가 관리하지", "고장 나면 어떡하지"가 걱정이신 분들이 있을 것입니다. 그 걱정이 도입을 미루는 이유가 되기도 합니다.
설계 단계에서 그 걱정을 줄이는 구조를 만드는 것이 가능합니다. 외부 서비스에 과도하게 의존하지 않는 설계, 기존 도구를 유지하는 설계, 담당자가 직접 운영할 수 있는 수준까지 인수인계하는 것 — 이 세 가지가 2년 8개월 무중단 운영의 실제 이유입니다.
30분 무료 진단에서 지금 구축하려는 자동화가 이런 방향으로 설계 가능한지를 함께 확인합니다. 가능하다면 어떻게 접근할 수 있는지, 가능하지 않다면 왜 그런지를 솔직하게 말씀드립니다. 진단 이후 의뢰 결정을 바로 하지 않아도 됩니다. 영업 전화는 드리지 않습니다.