앱 개발 외주 전, 대표가 먼저 정해야 하는 ‘출시 후 30일’ 운영 기준
앱이 스토어에 출시됐습니다. 그런데 첫 문의가 들어오자 답변할 화면이 없고, 오류가 발생해도 어디서 상태를 확인해야 할지 모릅니다. 운영자는 데이터를 개발자에게 요청하고, 개발자는 원인을 찾는 동안 사용자는 같은 문제를 반복해서 겪습니다.
이 상황은 개발자가 부족해서만 생기지 않습니다. 처음 계약할 때 ‘출시’까지만 범위로 잡고, 출시 직후 누가 어떤 업무를 처리할지 정하지 않았기 때문입니다. 초기 스타트업이라면 기능 목록보다 먼저 출시 후 30일의 운영 장면을 그려야 합니다.
출시 후 30일에 실제로 필요한 일부터 적습니다
출시 직후 운영은 거창한 시스템보다 반복되는 작은 업무의 묶음에 가깝습니다. 사용자가 문의를 남겼을 때 내용을 확인하고, 계정이나 주문 같은 상태를 조회하며, 문제가 생긴 기록을 개발자에게 전달해야 합니다. 공지나 약관 변경이 필요할 때 앱 업데이트 없이 처리할 영역도 생깁니다.
먼저 아래 질문에 답해 보세요.
- 문의는 어디로 들어오며, 누가 분류하는가
- 사용자의 계정 상태나 주요 활동을 운영자가 볼 수 있는가
- 오류가 발생했을 때 재현에 필요한 정보를 남길 수 있는가
- 공지, 배너, 이용 안내를 운영자가 직접 바꿀 수 있는가
- 앱 업데이트가 필요한 변경과 관리자 화면에서 처리할 변경은 무엇인가
- 스토어 심사나 배포가 지연될 때 어떤 업무를 유지할 것인가
이 질문의 답이 문서나 화면으로 남아 있지 않으면, 개발 완료 후에도 운영 업무가 개발자에게 몰립니다. 외주 범위를 정할 때는 기능 구현 목록과 함께 ‘출시 후 누가 무엇을 처리하는가’를 적어야 합니다.
관리자 페이지는 기능 수보다 운영 권한이 중요합니다
관리자 페이지가 있다고 해서 운영이 쉬워지는 것은 아닙니다. 필요한 정보가 빠져 있거나 권한이 지나치게 넓으면 담당자가 업무를 처리하기 어렵고, 반대로 모든 변경을 개발자 승인으로 묶으면 작은 공지 하나에도 시간이 걸립니다.
초기 운영에서 관리자 페이지의 우선순위는 다음처럼 잡을 수 있습니다.
첫째, 조회 기능입니다. 회원 상태, 문의 내용, 주요 처리 상태처럼 운영 판단에 필요한 정보가 한곳에 있어야 합니다. 둘째, 제한된 변경 기능입니다. 공지나 안내 문구처럼 자주 바뀌고 영향 범위를 예측할 수 있는 항목은 운영자가 수정할 수 있어야 합니다. 셋째, 이력입니다. 누가 언제 무엇을 바꿨는지 남아야 문제가 발생했을 때 원인을 좁힐 수 있습니다.
모든 데이터를 관리자 화면에 노출할 필요는 없습니다. 오히려 출시 첫 달에 실제로 처리할 업무를 기준으로 화면을 줄이는 편이 낫습니다. 대신 각 화면의 사용 권한과 변경 가능 범위를 계약 전에 정해 두어야 합니다.
오류 대응 범위는 ‘수정’보다 ‘판단 과정’까지 정합니다
개발 외주 계약에서 오류 대응은 자주 짧게 표현됩니다. 예를 들어 ‘버그 수정’이라고만 적으면, 어떤 문제가 운영 이슈에 해당하는지와 대응 순서가 불명확해집니다.
출시 전에 최소한 세 가지를 나눠야 합니다. 앱이 실행되지 않거나 핵심 흐름이 막히는 문제, 특정 조건에서만 발생하는 기능 오류, 문구나 사용성처럼 다음 업데이트로 조정할 수 있는 개선 요청입니다. 세 종류는 영향도와 대응 방식이 다릅니다.
출시 후 지원 기간을 정할 때도 기간만 적지 말고 범위를 나누세요. 기존 기능의 오류 수정인지, 새로운 기능 추가인지, 서버나 데이터베이스 운영 이슈인지에 따라 책임 주체가 달라질 수 있습니다. 이 구분이 없으면 운영 중 요청이 계속 개발 범위로 흘러갑니다.
데이터와 업데이트 승인 절차를 계약에 넣습니다
앱 운영자는 숫자를 보고 다음 행동을 결정합니다. 그런데 필요한 데이터가 없거나, 개발자에게 매번 추출을 요청해야 한다면 운영 속도가 늦어집니다. 출시 첫 달에는 복잡한 분석 도구보다 핵심 상태를 안정적으로 조회할 수 있는 구조가 우선입니다.
대표와 PM은 다음 항목을 미리 정할 수 있습니다.
- 어떤 데이터를 관리자 화면에서 조회할 것인가
- 개인정보나 민감한 값은 누가 볼 수 있는가
- 데이터 삭제나 수정이 필요한 경우 승인 절차는 무엇인가
- 장애나 배포 전후에 어떤 상태를 기록할 것인가
- 앱 업데이트를 요청하고 검토하고 승인하는 사람은 누구인가
업데이트 승인도 기술 작업으로만 보면 놓치는 부분이 생깁니다. 변경 내용, 영향받는 사용자, 배포 시점, 되돌릴 기준을 운영 관점에서 정해야 합니다. 특히 앱과 API가 함께 바뀌는 경우에는 스토어 심사 기간이나 사용 중인 버전의 호환성까지 범위에 넣어야 합니다.
외주 범위 문서는 출시 장면을 기준으로 씁니다
계약서의 기능 목록만 읽고 출시 준비가 끝났다고 판단하기는 어렵습니다. 각 기능이 출시 후 어떤 업무로 이어지는지 연결해 적어야 합니다. 예를 들어 문의 기능은 사용자 화면만이 아니라 관리자 조회, 상태 변경, 담당자 전달 방식까지 포함될 수 있습니다.
외주 미팅에서는 다음 순서로 이야기하면 범위를 좁히기 쉽습니다. 먼저 출시 첫날부터 30일까지 발생할 운영 상황을 적습니다. 그다음 대표가 직접 처리할 업무와 외부 지원이 필요한 업무를 나눕니다. 이후 관리자 페이지, API, 데이터베이스, 스토어 배포 영역에서 필요한 기능을 정하고, 출시 후 지원의 범위와 종료 조건을 문서화합니다.
좋은 출시 기준은 기능이 많다는 뜻이 아닙니다. 문제가 생겼을 때 누가 상태를 보고, 어떤 권한으로 처리하며, 언제 개발 지원을 요청할지 정해져 있다는 뜻에 가깝습니다.
운영 준비가 빠지면 앱은 출시됐지만 서비스는 멈출 수 있습니다. 반대로 30일 동안 반복될 업무를 먼저 골라내면 초기 범위를 줄이면서도 운영 공백을 피할 수 있습니다. 개발사를 선택하기 전에 기능 목록 옆에 ‘출시 후 담당자와 처리 방법’을 한 줄씩 붙여 보세요. 그 문서가 외주 범위와 관리자 기능을 논의하는 출발점이 됩니다.
출시 후 30일에 필요한 관리자 기능과 지원 범위를 아직 나누지 못했다면, 현재 서비스의 운영 흐름을 기준으로 외주 범위를 함께 진단할 수 있습니다. 앱 개발 계약 전에 필요한 화면과 유지보수 기준을 상담받아 보세요. https://www.universoft.kr/contact