AI로 직접 만들다 막혔습니다 — 이 코드 이어서 개발할 수 있나요

저희가 받은 문의 중에는 이렇게 시작하는 것들이 있습니다. "제가 AI로 직접 만들어봤는데요." 그다음에 따라오는 이야기는 이런 쪽입니다.

화면은 다 나왔는데 인터넷에 올리는 방법을 모르겠다. 남한테 보여줄 주소가 없고, 내 노트북을 켜둬야만 돌아간다.

어제까지 되던 게 오늘 안 된다. 한 군데 고쳐 달라고 시켰더니 다른 화면이 깨졌고, 되돌리는 방법을 모른다.

로그인을 붙이다 멈췄다. 가입까지는 되는데 비밀번호 찾기, 로그인 유지, 남의 글이 보이는 문제에서 진도가 안 나간다.

결제를 붙이다 멈췄다. 테스트 결제는 되는데 실제 심사와 취소·환불 처리를 어디서부터 손대야 할지 모르겠다.

이 밖에도 있고, 두세 개가 겹쳐서 오는 경우도 있습니다.

막힌 지점에는 공통점이 있습니다. 화면을 만드는 일은 끝났고, 그 화면 뒤에 붙는 일이 시작된 상태입니다. 서버에 올려서 계속 켜두는 일, 누가 누구 데이터를 볼 수 있는지 정하는 일, 실패했을 때 무엇을 보여줄지 정하는 일. 이쪽은 프롬프트를 더 자세히 쓴다고 넘어가지지 않습니다. 도구를 바꿔도 같은 자리에서 멈춥니다.

문의 끝에 이런 말을 덧붙이시는 분들이 있습니다. "코드가 엉망일 텐데 보여드리기 좀 그렇습니다." 넘겨받는 쪽이 먼저 확인하는 건 무엇이 이미 결정돼 있느냐입니다. 화면이 몇 개고 이름이 뭔지, 어떤 항목을 저장하기로 했는지, 처리 순서를 어떻게 잡았는지. 코드 스타일은 넘겨받은 뒤 손대면서 정리합니다.

판정을 미루면 나중에 시간이 더 듭니다. 막힌 채로 몇 주 더 붙잡고 있다가 넘기면, 그동안 AI에게 시킨 수정이 층층이 쌓여서 어디까지가 원래 설계였는지 만든 본인도 설명하기 어려워집니다. 막혔다고 느낀 시점에 한 번 정리해두는 편이 낫습니다.

개발사에 물어보기 전에 본인만 아는 정보를 적어두시면, 열어보지도 않고 "다시 만들죠"라는 답이 돌아올 여지가 줄어듭니다.

먼저 동작하는 화면 목록입니다. 완전히 되는 것, 반만 되는 것, 만들다 만 것으로 나눠서 화면 이름 그대로 적으세요. 반만 되는 목록이 판정에 특히 쓰입니다. 어디까지 갔고 어디서 멈췄는지가 그 줄에 다 들어 있습니다.

코드가 있는 위치도 적어두세요. 깃허브 같은 저장소에 올라가 있는지, 내 컴퓨터 폴더에만 있는지, 노코드 도구 안에만 있고 내보내기가 안 되는지. 폴더가 여러 개면 어느 것이 최신인지 한 줄 붙이세요. 이 줄이 없으면 첫 미팅이 최신본 찾기부터 시작됩니다. 백업본, 수정본, 최종본 같은 이름이 섞여 있으면 만든 본인도 며칠 지나면 헷갈립니다.

쓰고 있는 외부 서비스와 계정도 정리 대상입니다. 데이터베이스, 로그인, 메일 발송, 결제, AI API처럼 가입해둔 것을 전부 적고, 계정 명의가 본인인지 확인하세요. 명의가 다른 사람이면 이관 단계에서 막힙니다. 다만 키와 비밀번호는 이 단계에서 보내지 마세요. 서비스 이름만으로 판정이 됩니다.

마지막은 데이터가 쌓이는 곳입니다. 브라우저 안에만 있는지, 외부 데이터베이스인지, 구글 시트인지. 그리고 지금까지 쌓인 데이터를 살려야 하는지 버려도 되는지. 살려야 한다면 옮기는 작업이 별도로 붙고, 버려도 된다면 그만큼 빠집니다. 이 한 줄이 견적을 크게 바꿉니다.

그대로 복사해서 쓰실 수 있게 정리하면 이 정도입니다.

만든 것:

되는 화면 / 반만 되는 화면 / 못 만든 화면:

코드 위치, 최신본이 어느 것인지:

쓰는 외부 서비스와 계정 명의:

데이터 위치, 살려야 하는지:

막힌 지점 한 문장:

코드가 정리되지 않은 상태로 오는 건 정상입니다. AI에게 시켜서 만들면 같은 로직이 여러 군데 흩어지고 이름 규칙도 섞입니다. 판정에서 보는 건 그 결과물이 어느 쪽 용도로 만들어졌느냐입니다. 혼자 한 번 돌려보는 용도인지, 여러 명이 매일 쓰는 용도인지. 이 경계선을 기준으로 남는 부분과 새로 만드는 부분이 갈립니다.

남는 쪽부터 보겠습니다.

화면 구성과 흐름은 그대로 씁니다. 무엇이 몇 단계로 이어지는지, 어느 화면에서 어느 화면으로 넘어가는지가 이미 정해져 있습니다.

데이터 모델도 남습니다. 어떤 항목을 저장하기로 했는지, 표 이름과 칸 이름이 붙어 있으면 설계에서 정할 것이 상당 부분 정해져 있는 상태입니다.

요구사항이 가장 크게 남습니다. 직접 만들면서 내린 판단에는 기획서에 잘 안 적히는 것들이 들어 있습니다. 화면에 박아둔 문구, 업무에서 쓰는 용어, 예외 상황을 어떻게 처리하기로 했는지 같은 것들입니다.

새로 만드는 쪽은 이렇습니다.

배포가 첫 번째입니다. 서버, 도메인, HTTPS, 죽었을 때 다시 뜨게 하는 설정은 내 컴퓨터에서 돌리던 것과 다른 작업입니다. 테스트용 환경과 실제 운영 환경을 따로 두는 일도 여기서 시작됩니다.

인증과 권한이 그다음입니다. 로그인 화면 자체는 금방 만들지만 로그인 유지, 비밀번호 재설정, 소셜 계정과 기존 회원 연결, 남의 데이터가 안 보이게 막는 규칙은 따로 붙여야 합니다. 권한 단계를 하나 늘리면 확인해야 할 화면과 역할 조합이 그만큼 늘어납니다.

에러 처리도 새로 짭니다. 성공했을 때만 돌아가는 코드는 시연까지는 통과합니다. 실패했을 때 무엇을 보여주고 무엇을 되돌릴지가 비어 있으면 운영에서 걸립니다. 결제 중간에 창을 닫았을 때, 파일 업로드가 끊겼을 때, 외부 API가 응답을 안 줄 때 각각 정해둘 게 있습니다.

입력값 검증, 로그, 백업이 남습니다. 없어도 화면은 돌아갑니다. 사고가 났을 때 무엇이 언제 잘못됐는지 찾을 근거가 여기서 나옵니다.

직접 판정해보시려면 화면 하나를 붙잡고 물어보세요. 이 화면이 실패하면 어떻게 되나. 답이 "모르겠다"거나 "그냥 멈춘다"면 그 화면은 새로 만드는 쪽에 들어갑니다.

기존 시스템을 손볼 때 기본값은 점진적 개선입니다. 전면 재개발은 비용이 신규 개발 수준으로 올라가고, 전환 시점에 문제가 생길 위험도 따라옵니다. 그래서 문제가 되는 부분부터 순차적으로 고치는 쪽을 먼저 검토합니다.

AI로 만든 결과물에도 같은 순서로 접근합니다. 다만 이어붙이기 쪽 비용이 빠르게 올라가는 신호가 있습니다. 아래에 해당하면 인수 견적과 재개발 견적을 같이 받아보시는 편이 판단에 도움이 됩니다.

같은 코드가 화면마다 복사돼 있고, 한 곳을 고치면 다른 곳이 깨지는 일이 이미 반복됐다. 고칠 자리를 찾는 데 시간이 계속 쌓입니다.

데이터가 화면에 맞춰 저장돼 있다. 화면마다 표가 따로 있고 같은 정보가 여러 곳에 중복돼 있으면, 정리하는 일이 곧 재설계입니다.

노코드 도구 안에서만 돌아가고 코드 내보내기가 안 된다. 옮길 코드 자체가 없는 상태입니다. 이때 살리는 것은 화면 구성과 쌓인 데이터고, 코드는 새로 씁니다.

받은 그대로는 실행조차 안 된다. 패키지 버전이 엉켜서 켜지지도 않으면, 켜지는 상태로 되돌리는 일부터 분석 공수에 들어갑니다.

만들다가 방향이 바뀌었다. 이 경우엔 코드를 열기 전에 무엇을 만들 것인지부터 다시 정리해야 합니다. 코드만 보고 살릴지 말지를 정하면 어차피 안 쓸 화면까지 살리게 됩니다.

재개발 판정이 나와도 그동안 쓴 시간이 사라지지는 않습니다. 직접 만들어본 사람은 화면이 몇 개 필요한지, 어떤 항목을 저장해야 하는지, 어디서 예외가 나는지를 이미 알고 있습니다. 요구사항을 처음부터 캐묻는 단계가 짧아지고, 회의에서 "이건 어떻게 하실 건가요"라고 되묻는 횟수가 줄어듭니다. 만들어둔 것을 열어서 보여주면 됩니다.

신규 개발 견적은 만들 것의 양으로 나옵니다. 이미 만들어진 것을 넘겨받는 견적에는 앞에 읽을 것의 양이 붙습니다. 견적서 모양이 달라지는 것도 이 때문입니다.

분석 단계에서는 받은 코드를 남의 컴퓨터에서 실행되게 만드는 것부터 시작합니다. 켜지지 않으면 그다음이 없습니다. 그다음 화면과 데이터가 실제로 어떻게 연결돼 있는지 대조합니다. 만든 분의 설명과 코드가 어긋나는 지점이 여기서 나옵니다. 그리고 어디까지 살리고 어디부터 새로 쓸지 선을 긋습니다. 그 선이 그어져야 본 견적 금액이 나옵니다.

분석 없이 본 견적이 먼저 나오는 경우도 있습니다. 그럴 때는 그 금액이 무엇을 전제하고 있는지 물어보세요. 전부 새로 만드는 것을 전제한 금액인지, 기존 코드를 살리는 것을 전제한 금액인지에 따라 열어본 뒤 달라질 여지가 다릅니다. 어떤 조건에서 금액이 바뀌는지를 미리 문서로 받아두시면 됩니다.

기존 시스템 개선 견적이 신규 개발보다 높게 나올 수 있는 이유도 같은 분석 공수 때문입니다. 문서가 없는 코드를 읽는 시간은 신규 개발 견적에는 없는 항목입니다. AI로 만든 결과물이라고 해서 이 구조가 달라지지는 않습니다.

발주자 쪽에서 챙기실 건 분석 결과를 문서로 받기로 하고 시작하는 겁니다. 재개발 판정이 나와도 그 문서는 남고, 다른 곳에 견적을 받을 때 그대로 쓸 수 있습니다. 화면 목록, 데이터 구조, 살릴 범위와 새로 만들 범위가 적혀 있으면 다음 견적은 훨씬 빨리 나옵니다. 분석만 하고 본 개발은 다른 곳에 맡겨도 되는지도 미리 확인해두세요. 계약서에 그 조건을 넣을 수 있는지가 답이 됩니다.

"로그인만 붙여주세요"가 작은 요청으로 안 잡히는 것도 여기서 갈립니다. 소프트웨어 외주 단가표에서 소셜 로그인·지도 수준의 API 연동이 소규모 구간 50만~200만 원(부가세 별도)으로 잡히는 이유는, 그 값이 화면 뒤에 붙는 규칙과 예외 처리까지 세어서 나온 값이기 때문입니다. 같은 표에서 배송·공공데이터·결제 연동은 100만~500만 원 구간으로 올라갑니다.

넘기지 않고 계속 직접 굴리는 선택도 가능합니다. 조건이 맞을 때에 한해서입니다. 쓰는 사람이 본인과 소수 동료뿐이고, 고객 개인정보를 받지 않고, 결제가 없고, 하루쯤 멈춰도 업무가 돌아가는 경우입니다.

이 조건이면 지킬 것이 많지 않습니다.

되던 시점을 저장해두세요. 코드를 저장소에 올리고, 잘 돌던 상태에 표시를 남기세요. AI에게 수정을 시키기 전에 저장해두면 깨졌을 때 돌아갈 곳이 생깁니다. 한 군데 고쳤더니 다른 화면이 깨진 상황에서 원인을 찾느라 붙잡고 있는 대신, 되돌리고 다시 시도할 수 있습니다.

데이터는 주기를 정해서 백업하세요. 자동이든 수동이든 상관없고, 내려받은 파일이 실제로 열리는지 한 번은 확인하세요. 열어보지 않은 백업 파일은 복구해야 하는 시점에 가서야 문제를 드러냅니다. 파일 크기가 0이거나 인코딩이 깨져 있는 경우가 그때 나옵니다.

키는 코드 밖에 두세요. API 키와 비밀번호를 코드 안에 그대로 적어두지 말고, 저장소를 공개로 두지 마세요. 공개 저장소에 올라간 키는 자동 스캔 프로그램이 찾아냅니다. 올린 지 얼마 안 됐다고 안전한 것도 아닙니다.

하나만 고르시겠다면 백업입니다. 지워진 데이터는 되돌릴 경로가 없어서 복구가 가장 어렵습니다.

이 조건이 깨지는 시점은 분명한 편입니다. 고객 데이터가 들어오거나, 돈이 오가거나, 나 말고 다른 사람이 그 화면 없이는 일을 못 하게 될 때입니다. 그 시점부터는 장애가 났을 때 누가 언제까지 고치는지가 정해져 있어야 합니다. 개인정보를 받기 시작하면 개인정보보호법상 지켜야 할 의무도 따라붙습니다.

어디까지 살릴 수 있는지부터 확인하고 시작하시면 됩니다.