이미 운영하던 플랫폼의 오류를 고치는 일은 새 기능을 만드는 일과 달랐습니다. 주유 배달 플랫폼 N사에서 QA, 보완 개발, 클라우드 운영을 연결해 개선을 이어가고 그 위에서 다음 결제 기능을 준비한 과정을 소개합니다.
만들어진 서비스가 있다는 것과 안정적으로 운영할 수 있다는 것은 다른 이야기입니다. 화면이 있고 주요 기능을 실행할 수 있어도 일상적인 업무에서 오류가 반복되면 운영자는 시스템 밖에서 문제를 메워야 합니다.
주유 배달 플랫폼 N사의 과제도 여기서 시작됐습니다. 기존 서비스를 인수한 뒤 잦은 오류로 정상적인 운영에 어려움을 겪고 있었습니다. 새로운 서비스를 기다릴 여유가 없어 지금의 서비스를 다루면서 개선을 이어가야 하는 프로젝트였습니다.
IXC는 2025년 7월부터 QA와 보완 개발, 클라우드 운영을 함께 맡았습니다. 이 사례의 중심은 기능을 얼마나 많이 추가했는지가 아닙니다. 무엇을 먼저 고치고 어떻게 공개하며 다음 변경까지 누가 책임질지를 연결한 것입니다.
수정보다 수정할 순서를 먼저 정했습니다
눈에 띄는 오류부터 고치면 빠르게 움직이는 것처럼 보일 수 있습니다. 그러나 제보가 들어오는 순서와 사업에 미치는 영향의 크기는 같지 않습니다. 불편한 화면 하나를 고치는 동안 거래를 막는 문제가 남아 있을 수도 있습니다.
인수 단계에서는 전반적인 기능 검증으로 결함을 확인하고 심각도를 정리했습니다. 발견한 문제는 결함 대장으로 모아 보완 개발의 기준으로 삼았습니다.
결함 대장은 오류를 모아 놓는 문서에 그치지 않습니다. 운영에서 겪는 문제를 개발이 다룰 수 있는 작업으로 바꾸는 연결점입니다. 문제가 있다는 이야기와 어떤 조건에서 문제가 생기는지 설명할 수 있다는 것 사이에는 차이가 있습니다.
이 프로젝트를 이해하는 데 중요한 순서도 여기에 있습니다. 수정을 많이 하는 것보다 서비스에 영향을 주는 문제를 파악하고 개선의 순서를 정하는 일이 먼저였습니다.
큰 교체 한 번 대신 주 단위 개선을 이어갔습니다
운영 중인 서비스를 한꺼번에 바꾸는 방식에는 부담이 있습니다. 변경 범위가 넓어질수록 문제가 생겼을 때 어느 수정의 영향인지 구분하기 어려워지고 운영자가 익혀야 할 변화도 커질 수 있습니다.
N사에서는 고정 투입으로 보완 개발을 이어가며 수정 사항을 주 단위로 배포했습니다. 검증에서 발견한 문제를 개발로 넘기고 그 변경이 실제 서비스에 반영되는 흐름을 반복했습니다.
여기서 주 단위라는 주기 자체가 모든 프로젝트의 정답은 아닙니다. 수정이 장기간 쌓인 채 대기하지 않고 운영 개선으로 이어지는 경로가 더 중요합니다. 다음 배포에서 무엇을 바꿀지 설명할 수 있어야 하고 배포 뒤에도 그 변경을 다룰 팀이 있어야 합니다.
서비스 정상화는 한 번의 완료 선언보다 이런 반복에 가깝습니다. 오류를 발견한 다음 누군가의 답을 기다리는 시간이 아니라 확인한 문제를 실제 변경으로 이어가는 과정이 필요했습니다.
QA와 개발 사이에 운영을 남겨두지 않았습니다
코드를 고친 사람이 있어도 배포 경로를 다루는 사람이 다르면 작업은 다시 멈출 수 있습니다. 운영에서 발견한 문제를 전달할 때도 같은 설명이 여러 번 반복될 수 있습니다.
IXC는 보완 개발과 함께 클라우드 운영을 맡았습니다. 배포와 장애 대응을 개발·검증과 같은 팀 안에서 연결했습니다.
같은 팀이 맡는다는 사실만으로 오류가 사라지는 것은 아닙니다. 이 구성의 의미는 책임의 연결에 있습니다. 검증에서 드러난 문제를 누가 수정하고 수정된 결과를 어디에 반영하며 운영 중 추가 문제가 생기면 누가 다시 확인하는지가 이어집니다.
기능 개발만 발주할지, 기존 서비스의 유지보수까지 맡길지 고민하는 조직이라면 구분해야 할 지점입니다. 기능을 하나 더 만드는 역량과 이미 돌아가는 서비스를 계속 바꾸는 역량은 겹치지만 같은 범위의 일은 아닙니다.
안정화 다음의 과제는 반복 결제였습니다
서비스 정상화 이후에는 카드 자동결제 기반 빌링을 준비하고 있습니다. 정기적으로 발생하는 거래를 처리하기 위해 요금제, 결제 실패 뒤의 재시도, 고객 안내를 먼저 정하는 작업입니다.
반복 결제는 카드를 한 번 더 승인하는 기능으로만 보기 어렵습니다. 고객에게 청구한 상태와 서비스가 인식하는 상태가 어긋나지 않아야 하고 실패했을 때 다음 행동도 정해져야 합니다.
예를 들어 결제 응답을 받지 못했다는 사실만으로 실패를 확정할 수는 없습니다. 이미 처리된 거래를 다시 청구하지 않도록 확인하는 절차가 필요합니다. 이런 예외를 함께 고려해야 빌링이 운영 가능한 기능이 됩니다.
현재 빌링 구축은 진행 중입니다. 정상화 과정에서 마련한 개발·검증·운영의 흐름을 바탕으로 요금제와 결제 예외 조건을 다음 기능에 반영하고 있습니다.
이번 프로젝트가 바꾼 것은 오류 목록의 다음 단계였습니다
N사에서는 전반적인 QA 결과가 보완 개발의 순서로 이어졌고 주 단위 배포와 클라우드 운영을 통해 서비스 정상화를 진행했습니다. 검증, 수정, 배포를 별개 작업으로 남겨두지 않았다는 점이 이 프로젝트의 핵심입니다.
기존 서비스를 인수하는 조직에 필요한 것은 소스코드만이 아닙니다. 현재 상태를 설명할 수 있는 기록, 무엇을 먼저 바꿀지 정하는 기준, 변경을 운영에 반영할 수 있는 팀이 함께 필요합니다.
이 사례에서 확인한 접근은 이렇습니다. 서비스를 다시 세운다는 것은 처음부터 다시 만드는 일만을 뜻하지 않습니다. 지금의 문제를 확인하고 고쳐서 운영에 반영하는 과정을 지속 가능하게 만드는 일이기도 합니다.