어린이집을 비롯한 고객의 급식 주문과 식수 관리를 위한 시스템을 구축했습니다. 서비스 개발과 함께 클라우드 환경, 배포 경로, 백업 기준을 준비하고 핵심 업무 흐름을 검증했습니다.
급식 주문 시스템에서 화면에 입력되는 수량은 실제 운영에서 사용할 정보입니다. 주문을 받는 기능과 식수를 관리하는 기능은 따로 보일 수 있지만 이용자에게는 하나의 업무로 이어져야 합니다.
K사는 이 업무를 처리할 새 시스템이 필요했습니다. 무엇을 만들지 정하는 일과 완성된 시스템을 어디에서 운영할지 정하는 일이 함께 진행돼야 했습니다.
IXC는 개발과 QA, 클라우드 환경을 하나의 프로젝트로 맡았습니다. 이 사례의 출발점은 기능이 완성된 다음 서버를 구하는 것이 아니라, 실제 운영 조건을 개발과 함께 준비하는 것이었습니다.
업무의 사용 패턴이 인프라 설계의 기준이 됐습니다
서버 구성을 고를 때 기능 목록만으로는 충분하지 않습니다. 사용이 하루 동안 고르게 발생하는지, 특정 시간에 몰리는지에 따라 준비해야 할 조건이 달라질 수 있습니다.
K사에서는 주문이 집중되는 시간대를 고려해 서버 구성을 정했습니다. 주문이라는 기능의 존재뿐 아니라 실제로 사용하는 상황을 기반 환경에 반영한 것입니다.
인프라 설계에서는 서버의 사양보다 서비스가 사용되는 조건을 먼저 정리해야 합니다. 어느 시간대에 요청이 모이고 그때 어떤 작업이 실행되는지를 알아야 규모와 운영 기준을 판단할 수 있습니다.
구축 단계부터 사용 패턴을 함께 살펴야 합니다. 업무의 리듬을 모르면 평균적인 이용량만 보고 환경을 판단하기 쉽습니다.
개발 뒤에 배포 준비를 남겨두지 않았습니다
클라우드 환경을 먼저 준비하고 개발을 같은 일정에서 진행했습니다. 코드 변경이 배포로 이어지는 경로를 갖춰 기능을 만들고 실제 환경에 올리는 과정이 연결되도록 했습니다.
개발 환경에서 동작하는 기능을 운영에 반영하려면 또 다른 작업이 필요합니다. 환경이 준비되지 않았다면 코드가 완성돼도 이용자가 사용할 수 없습니다.
자동 배포의 의미도 버튼을 줄이는 데만 있지 않습니다. 변경을 반영하는 경로를 일관되게 유지할 수 있다는 점이 중요합니다. 다음 기능을 추가할 때도 이전에 사용하던 방식을 참조할 수 있습니다.
배포 경로를 정리한 뒤에도 공개할 기능의 확인은 필요합니다. 환경을 갱신하는 과정과 주문·식수의 동작을 검증하는 과정을 함께 다뤄야 다음 변경을 운영에 반영할 수 있습니다.
주문과 식수 관리가 이어지는 흐름을 확인했습니다
개발과 함께 QA를 수행하며 주문과 식수 관리의 핵심 흐름을 실행해 검증했습니다. 기능이 각각 존재하는지보다 업무로 사용할 수 있는지를 확인하는 과정입니다.
업무 시스템에서는 버튼을 눌렀을 때 반응하는 것과 사용자가 목적을 달성하는 것이 다를 수 있습니다. 저장은 됐지만 다음 단계에서 필요한 정보가 없다면 업무는 화면 밖에서 다시 이어져야 합니다.
그래서 검증의 단위를 개별 화면에만 둘 수 없습니다. 앞의 동작이 뒤에서 사용할 결과를 남기는지까지 생각해야 합니다. 주문 기능과 식수 관리 기능을 같은 업무 흐름으로 보는 이유입니다.
이 사례의 QA 결과는 서비스가 운영으로 넘어가는 과정에 포함됐습니다. 시스템을 만든 다음 검증할 주체를 별도로 찾는 방식과 달리, 구축 범위 안에서 핵심 동작을 확인했습니다.
백업과 운영 기준도 함께 정리했습니다
환경 구성에서는 배포 경로뿐 아니라 백업 주기와 운영 기준을 문서로 남겼습니다. 서비스 공개 이후에 반복할 일을 구축 단계에서 함께 준비한 것입니다.
백업 주기를 정하는 것은 데이터를 보호하기 위한 준비에 해당합니다. 다만 백업 설정만으로 어떤 장애에서도 바로 복구할 수 있다고 말할 수는 없습니다. 복구 수준을 설명하려면 실제 복원 검증과 운영 조건을 별도로 확인해야 합니다.
이 구분은 운영 범위를 정할 때 중요합니다. 무엇이 설정돼 있는지, 무엇을 시험했는지, 문제가 생겼을 때 무엇을 할 수 있는지는 서로 다른 정보이기 때문입니다.
K사에서는 개발 결과물에 기반 환경과 운영 문서를 더해 다음 변경을 이어갈 수 있도록 했습니다.
고객이 주문하는 시스템으로 운영을 이어갑니다
구축한 플랫폼에서는 어린이집을 비롯한 고객이 급식을 주문하고 식수를 관리하고 있습니다. 이후 기능을 추가할 때도 마련된 배포 경로를 사용하며 운영을 이어가고 있습니다.
이 프로젝트의 결과는 주문 화면을 새로 만든 일보다 넓습니다. 업무 기능, 검증, 서비스가 올라갈 환경, 이후 변경 경로를 함께 마련했습니다.
처음 시스템을 구축하는 조직이라면 개발과 운영을 별도 단계로만 보기 쉽습니다. 하지만 공개 이후에도 사용할 서비스라면 첫날의 기능과 다음 달의 변경을 함께 준비해야 합니다.
K사 사례는 업무에 필요한 소프트웨어를 만드는 일과 그 소프트웨어를 계속 운영할 환경을 갖추는 일을 연결한 프로젝트입니다.