AI로 만든 앱, 수정할까 다시 만들까? 판단 기준

AI로 만든 앱은 원인이 한 구간으로 좁혀지면 수정부터, 핵심 이용 흐름이 달라졌다면 재개발안까지 비교한다. 원인이나 기존 데이터의 위치를 모르면 진단이 먼저다. 오류 개수만으로 전체 코드를 버릴 이유는 정할 수 없다.

먼저 이번에 꼭 끝낼 동작을 한 문장으로 적는다. 기존 코드에 쓴 시간보다 그 동작을 확인하는 데 필요한 작업을 비교하는 편이 낫다. 아래 기준과 3쪽 PDF로 수정·재개발·진단 중 다음 단계를 정리할 수 있다.

어떤 상황에서 수정과 재개발을 비교할까?

현재 기능이 필요한 결과를 얼마나 충족하는지부터 본다. 다음 표는 선택할 조사 방향이다. 앱을 직접 진단한 결과나 자동 점수표는 아니다.

확인된 상태	다음에 비교할 것
필요한 기능은 작동하고, 실패 원인이 한 구간으로 좁혀졌다	그 구간의 수정과 기존 기능 유지 여부
사용자 역할·저장 규칙 등 핵심 이용 흐름이 달라졌다	새 요구에 맞춘 수정안과 재개발안
실패를 재현하지 못했거나 데이터 위치를 모른다	원인과 자료 위치를 확인할 진단 범위

가상 예약 페이지를 생각해보자. 날짜 선택은 되지만 관리자 목록에 신청이 없다. 이것만으로 저장 오류인지, 전송 실패인지, 아직 만들지 않은 기능인지 알 수 없다. 이때는 ‘재개발 필요’보다 ‘진단 먼저’가 맞는 기록이다.

반대로 혼자 쓰던 메모 앱을 여러 직원의 예약 시스템으로 바꾸려 한다면 어떨까. 직원별 권한과 예약 충돌 처리는 새 요구다. 이 작업을 기존 오류 수정에 묶지 않고 따로 비교해야 한다.

현재 되는 기능과 실패하는 기능은 어떻게 나눌까?

오류 목록 옆에 작동 목록을 적는다. 한 번도 만든 적 없는 기능은 미구현으로 분리한다. 모르는 항목은 실패로 단정하지 않고 미확인으로 남긴다.

상태	확인할 질문
현재 작동	같은 환경과 입력으로 다시 실행해도 되는가?
실패	어떤 순서에서 기대한 결과와 달라지는가?
미구현·미확인	화면만 있는가, 저장·외부 연결도 확인했는가?

화면 생성과 외부 서비스 연결은 다를 수 있다. Jform 공식 FAQ는 타사 도구를 앱 빌더에서 수동으로 통합한다고 안내한다. 해당 제품의 설명이다. 지금 만든 앱의 오류 원인은 별도로 확인해야 한다.

두 견적을 비교하기 전에 무엇을 맞춰야 할까?

두 안에서 끝낼 결과를 같게 맞춘다. 수정안은 예약 전달만, 재개발안은 로그인과 통계까지 포함한다면 금액만 비교하기 어렵다. 새 기능은 별도 항목으로 빼고 같은 완료 결과의 범위를 확인한다.

가상 예시라면 다음처럼 적을 수 있다. “신청 1건을 보내면 관리자가 같은 신청번호와 날짜를 확인한다. 새로고침한 뒤에도 해당 신청이 남아 있다.” 날짜 선택 화면이 열렸다는 사실과 저장 결과를 구분하는 기준이다.

비교에는 코드 작업 밖의 범위도 들어간다. 기존 자료의 이전과 확인, 계정·배포 환경, 인수 자료, 문제가 생겼을 때 되돌릴 방법이다. 이 항목이 빠진 재개발안은 전체 작업 범위를 아직 알 수 없는 안이다.

진단에서 어떤 결과를 받아야 결정할 수 있을까?

전체 수리 가능성을 약속받기보다 실패 한 구간의 설명을 받는다. 같은 순서로 재현한 동작, 확인된 원인과 아직 추정인 원인, 다음에 확인할 항목이 구분돼야 한다. 조사 비용과 받을 결과물의 범위도 시작 전에 확인한다.

부분 수정 서비스 설명은 상황 파악·원인 분석·후속 안내를 나눈다. 같은 페이지에서 전체 개발 대행은 제외하고 있다. 서비스 이름만 보고 재개발까지 포함된다고 해석하면 안 되는 이유다. 판매자의 해결 시간이나 후기가 내 앱의 수리 가능성을 증명하지도 않는다.

진단 뒤에는 세 가지를 정리한다. 실패 지점을 어디까지 확인했는지, 이번에 끝낼 동작은 무엇인지, 각 안의 포함·제외가 무엇인지다. 이 정보로 두 안을 비교할 수 있으면 다음 견적 단계로 넘어간다. 원인이 남아 있다면 추정을 확정으로 바꾸지 말고 추가 조사 한 구간을 정한다.

새로 만들면 같은 문제가 사라질까?

요구사항의 빈칸은 새 코드만으로 채워지지 않는다. 기획자·개발자 부부의 제작 회고는 기획 검토를 충분히 하지 않아 수정이 쌓였던 과정을 설명한다. 이후 기획 문서를 다시 검토하고 재개발했다. 작성자의 한 프로젝트 경험이다.

따라서 재개발안을 받을 때에도 달라질 동작과 확인 방법을 묻는다. 가상 예약 페이지라면 화면을 다시 그리는 일과 저장·전달 규칙을 바꾸는 일을 나눠 적는다. 새 기능까지 넣어 완료 결과가 달라졌다면 비교 범위를 다시 맞춘다.

PDF 판단표는 어떻게 채울까?

1쪽에는 확인 환경과 기능 상태, 2쪽에는 두 안의 포함 범위를 적는다. 3쪽은 가상 예약 페이지로 채운 예시다. 인쇄하거나 PDF 주석으로 적는 필기용 양식이며 입력 폼은 아니다.

예시에서는 저장·관리자 목록의 원인을 아직 모른다. 여러 직원의 권한과 통계는 이번 완료 범위에서 제외했다. 그래서 선택도 ‘진단 먼저’로 남겼다. 실제 앱 수리나 고객 납품 사례가 아니다.

항목이 비어 있으면 ‘미확인’과 확인 담당·날짜를 적는다. 체크 수보다 선택 이유가 남아야 한다. 나중에 새 요구가 생겼을 때 어떤 조건이 달라져 결정을 바꾸는지도 알 수 있다.

현재 기능과 두 안의 완료 결과는 수정·재개발 판단표 PDF에 정리할 수 있다. 작성 예시는 PDF 3쪽에 있다.

실패 한 구간만 맡길 준비는 부분 수정 의뢰 가이드에서 이어갈 수 있다. 앱을 처음 만들거나 공개하는 순서는 바이브코딩 실습 안내에서 필요한 단계를 고르면 된다.

검증 기준

• 마지막 업데이트일: 2026-09-08
• 확인 환경: Orca 브라우저에서 아래 원문과 PDF의 기능 상태·비교 범위·가상 예시를 대조했다. 제품으로 실제 앱을 수정하거나 재개발하는 실험은 하지 않았다.
• 주요 근거: Jform 공식 FAQ, 제작자가 쓴 프로젝트 회고, 판매자의 부분 수정 서비스 범위