앱 유지보수 범위, 오류 수정과 기능 추가를 어떻게 나눌까

납품받은 신청 앱에서 저장한 값이 보이지 않는다. 이때 “유지보수 포함이니 고쳐주세요”만 보내면, 어떤 결과를 기대했고 어디에서 어긋났는지 다시 설명해야 한다.

합의한 기능과 현재 증상을 먼저 연결하자. 새 기능인지, 원래 기능의 문제인지, 외부 환경 변화인지는 그 근거를 보고 구분한다. 실제 지원 여부와 비용은 계약과 서비스 설명을 확인한다.

이 글에서는 가상의 신청 앱 요청 한 건을 적어본다. 유형을 나누는 데서 그치지 않고, 담당자에게 보낼 내용과 수정 뒤 확인할 결과까지 연결한다. 실제 고객의 접수나 납품 사례는 아니다.

앱 유지보수 범위는 합의한 결과부터 확인한다

같은 “항목 추가”라도 의미가 다를 수 있다. 처음부터 저장하기로 한 항목이 빠졌다면 합의한 기능과의 차이를 확인할 일이다. 사용해보니 새로운 항목이 필요해졌다면 추가 요구다.

요청 유형	가상 예시	먼저 확인할 근거
합의 기능의 문제	저장하기로 한 희망 시간이 보이지 않음	확정 요구사항·검수 기록과 현재 화면
새 요구	월별 신청 통계 화면 추가	기존 범위에 있던 기능인지
환경 변화	외부 서비스 변경 뒤 연결 실패	변경 공지·발생 시점·지원 조건
운영 문의	담당자가 실행 방법을 모름	인계 설명서·교육 및 지원 범위

이 표는 비용을 자동 판정하는 기준이 아니다. 화면에 값이 없다고 저장 오류로 확정할 수도 없다. 저장은 됐지만 표시가 잘못됐거나, 다른 조회 조건을 보고 있을 수 있다.

합의 자료가 없다면 어느 유형인지 먼저 단정하지 않는다. “이 기능을 어디까지 제공하기로 했는지 함께 확인하고 싶습니다”라고 범위 확인을 요청하는 편이 낫다.

앱코모의 수정·유지보수 안내도 요청 위치와 변경 내용을 받은 뒤 범위·비용·일정을 안내하는 순서다. 해당 업체의 절차이며 모든 업체의 요금이나 지원 조건을 뜻하지 않는다.

지원 요청에는 기대한 결과와 현재 증상을 같이 적는다

담당자가 확인할 수 있는 정보부터 정리한다. 재현 방법에는 시작 화면, 입력, 누른 버튼과 도착한 화면을 적는다. 원인을 모르겠다면 추측으로 채우지 않는다.

요청 항목	가상의 작성 예시
합의한 완료 기준	신청 때 입력한 희망 시간이 관리자 목록에 표시된다. 확정 요구사항의 해당 문장을 첨부한다.
확인한 증상	테스트 신청 뒤 관리자 목록의 희망 시간 칸이 비어 있다. 원본 저장 상태는 확인하지 못했다.
재현 조건	별도 테스트 환경에서 가상 신청을 입력하고 저장한 뒤 관리자 목록을 새로 연다. 같은 입력에서 두 번 관찰했다고 가정한다.
환경·변경 이력	사용한 브라우저 버전·발생 시각을 적는다. 배포나 외부 서비스 변경 여부는 담당자 확인이 필요하다.
이번 요청 범위	약속한 희망 시간 표시를 확인하고 싶다. 통계 화면 추가는 이번 요청에서 제외한다.
첨부·회신 요청	개인정보를 지운 화면과 요구사항을 보낸다. 확인에 필요한 자료, 지원 범위와 가능한 일정을 먼저 알려달라고 요청한다.

위의 두 번 관찰은 작성법을 보여주기 위한 가정이다. 이 글에서 앱을 실행해 얻은 결과가 아니다. 실제 요청에는 직접 확인한 횟수와 결과만 넣으면 된다.

“무엇이든 빨리 수정해도 좋다”는 뜻으로 읽히지 않도록, 추가 작업이 필요할 때 확인할 사람도 적어둔다. 점검에 필요한 접근 권한은 담당자와 별도 경로로 조율한다. 비밀번호나 실제 신청자의 정보는 공개 게시판·공유 양식에 넣지 않는다.

응답 시간과 수정 완료 기준을 나눠 확인한다

요청에 답한 시각과 문제가 해결된 시각은 다르다. 접수 확인, 추가 자료 요청, 지원 범위 안내, 수정 일정, 결과 확인을 나눠 보면 지금 어느 단계인지 알 수 있다.

제로백의 운영 안내도 응답 시간과 수정 완료 기준을 함께 확인할 항목으로 다룬다. 글에 나온 기간·계약 방식이 내 서비스에도 적용된다고 가정하지 않는다.

앞의 신청 앱이라면 이렇게 회신을 요청할 수 있다. “희망 시간 표시가 기존 지원 범위에 포함되는지 확인 부탁드립니다. 별도 비용이나 작업이 필요하면 시작 전에 범위와 일정을 알려주세요.” 희망 마감일은 요청이고, 담당자가 수락한 완료일과는 구분한다.

운영 데이터가 계속 사라지는 상황이라면 확인 횟수를 채우려고 반복 입력하지 않는다. 영향받는 업무와 마지막 정상 시점을 전달하고 담당자에게 우선 연락한다. 데이터 손상 위험이 있는 시험은 안전한 환경과 처리 방법부터 확인한다.

수정됐다는 회신 뒤에는 같은 조건의 결과를 확인한다

“수정했습니다”라는 답만으로 끝내기보다 처음 적은 완료 기준으로 돌아가면 된다. 신청 앱 예시에서는 같은 테스트 입력 뒤 희망 시간이 표시되는지, 새로고침 후에도 남는지 확인한다.

그다음 변경과 가까운 기존 기능을 본다. 다른 신청 항목이 사라지지 않았는지, 저장하지 못한 상황을 성공으로 안내하지 않는지처럼 이번 수정과 관련된 범위다. 작은 문구 교체에도 앱 전체를 시험하라는 뜻은 아니다.

결과에는 확인일과 사용 환경, 기대한 결과와 실제 결과를 남긴다. 확인하지 못한 부분은 따로 적는다. 기존 값을 복구해야 하는 문제와 앞으로의 입력을 고치는 문제도 같은 완료로 묶지 않는다.

“오류면 무조건 무료 아닌가요?”

오류라는 이름만으로 이 글에서 비용을 확정할 수는 없다. 하자보수와 유지보수를 설명한 제로백 글처럼 구분을 다루는 자료도 있지만, 내 요청의 작업 영역·지원 기간·제외 조건은 실제 합의 내용을 대조해야 한다.

요청 한 건을 작성해보기

유지보수 요청 기록표 PDF는 빈 요청 양식, 수정 결과 기록란, 별도 가상 작성 예시로 구성했다. 인쇄해서 쓰는 필기용 자료이며 입력 가능한 PDF는 아니다.

먼저 합의한 결과 한 문장과 지금 확인한 증상 한 문장만 적어보자. 두 문장을 연결할 자료가 없으면 그 자료를 찾는 일이 다음 행동이다. 지원 종료나 담당자 변경을 앞뒀다면 개발자에게 프로젝트를 넘길 때 정리할 자료도 함께 확인할 수 있다.

바이브코딩 가이드에서 제작과 운영의 다른 단계도 이어볼 수 있다.

검증 기준

• 마지막 업데이트일: 2026-09-08
• 확인 환경: 앱코모의 실제 지원 절차와 제로백의 구분·운영 안내 본문을 대조했다. 가상 신청 앱의 요청·수정 확인 예시는 문서의 일관성을 검수했으며 실제 앱 실행·고객 납품·계약 판정 결과는 아니다.
• 주요 근거: 앱코모 수정·유지보수 안내, 제로백 하자보수와 유지보수 설명, 제로백 앱 운영 안내