AI 코드 개발자 인계에 필요한 자료

AI 코드 개발자 인계의 기본 자료는 현재 소스, 같은 버전의 실행 안내, 오류를 다시 만드는 순서다. 같은 입력에서 원하는 결과와 이번에 제외할 작업도 함께 적는다.

직접 실행하지 못했다면 성공한 것처럼 안내를 채우지 않는다. 어디까지 해봤고 어느 단계에서 막혔는지 전달하면 된다. 아래 4쪽 PDF로 보내는 자료와 수정 후 받을 결과를 정리할 수 있다.

어제 잘 되던 압축 파일과 오늘 실패한 화면을 함께 보내면 서로 다른 상태를 비교하게 된다. 자료를 많이 모으기보다 받는 사람이 같은 상태를 확인하도록 맞추는 일이 먼저다.

보내는 사람의 준비표, 받는 사람의 확인표와 가상 작성 예시를 담은 4쪽 필기용 PDF예요. PDF 입력칸은 없습니다.

코드 인계 준비표 PDF 받기 · 작성 예시 보기

코드와 실행 안내는 어떤 버전으로 맞춰야 할까?

전달할 버전을 하나 정하고 프로젝트 이름, 전달 날짜, ZIP 파일명이나 저장소 버전을 적는다. 오류 화면과 실행 안내에도 같은 표시를 붙인다.

저장소를 쓴다면 전달할 시점의 커밋이나 태그처럼 버전을 구분할 정보를 남긴다. 커밋은 코드 변경 시점을 가리키는 기록이고, 태그는 그 버전에 붙인 이름이다. ‘마지막 파일’이라는 이름만으로는 다음 수정본과 구분하기 어렵다.

시작 폴더와 파일, 필요한 도구 버전, 설치·실행 순서, 성공하면 보일 화면도 적는다.

실행 상태에 따라 적을 내용은 달라진다.

지금 확인한 상태	전달할 내용	아직 확인하지 못한 것
앱은 열리지만 한 동작이 실패함	같은 버전의 입력·실행 순서·실제 결과	실패 원인과 수정 방법
설치나 실행부터 막힘	마지막 성공 단계·실패한 명령·오류 화면	앱이 열린 뒤의 기능 동작
코드 공유 전 상담 단계	막힌 상황·화면·사용 도구·원하는 결과	개발자가 같은 코드로 재현했는지

인터넷에서 찾은 명령을 확인 없이 내 프로젝트의 실행 방법으로 적지 않는다. 코드 공유 전에는 상황을 상담할 수 있지만, 그 상담만으로 실행 확인까지 끝난 것은 아니다.

GitHub의 README 안내는 프로젝트의 목적과 시작 방법, 도움을 받을 곳, 관리 담당을 설명하는 문서의 역할을 다룬다.

이 자료에서는 그 구성을 인계 안내의 질문으로 옮겼다. 특정 양식을 쓰면 어떤 코드든 실행된다는 뜻은 아니다.

자료	적을 내용	비어 있으면 확인할 질문
현재 소스	ZIP 파일명 또는 저장소 버전·날짜	오류 화면도 이 버전인가요?
실행 안내	시작 위치·도구 버전·명령·확인 화면	별도 설치나 외부 계정이 필요한가요?
재현 정보	가상 입력 → 실행 순서 → 실제 결과	같은 순서로 다시 나타나나요?
기대 결과	같은 입력에서 원하는 동작	이번 수정이 끝났다는 기준은 무엇인가요?
최근 변경	문제 직전 바꾼 파일·설정·이유	유지할 결정과 취소한 시도는 무엇인가요?

계정과 배포 권한도 함께 준비해야 할까?

부분 수정 서비스의 준비사항에는 막힌 상황, 오류 화면, 사용 도구, 코드 공유 방법이 나온다. 앱 배포 서비스는 소스뿐 아니라 작업에 쓸 계정을 준비사항으로 설명한다. 두 서비스가 받으려는 정보가 같지는 않다.

내가 맡길 일이 코드 수정인지, 서버 배포까지인지 먼저 구분한다. 코드 수정 상담을 시작하는 데 모든 배포 계정이 필요한 것은 아니다.

해당 배포 서비스도 상담 전에는 계정을 미리 준비할 필요가 없고, 작업 착수 전에는 준비해야 한다고 설명한다. 내 작업의 접근 방식과 준비 시점은 선택한 범위에 맞춰 확인한다.

배포가 포함된다면 외부 서비스 이름, 계정 소유자, 필요한 접근 범위와 준비 담당을 적는다.

비밀번호나 API 키의 실제 값은 PDF와 공개 ZIP에 넣지 않는다. 필요한 접근 방식과 작업 후 권한을 정리할 방법을 따로 협의한다.

배포 서비스 소개에 접속 가이드, 구조도, 자동 배포가 함께 나와도 선택한 견적에 모두 포함되는지는 다시 물어야 한다. PDF 2쪽에는 제공받을 자료와 제외할 작업을 적는 칸을 따로 두었다.

대화 기록은 현재 버전을 설명하는 부분만 고른다

오류 직전의 요청과 변경 이유는 도움이 될 수 있다. 수백 줄의 대화가 현재 소스를 대신하지는 않는다. 오래된 코드, 취소한 설계, 다른 문제의 로그를 섞으면 어떤 결정을 유지해야 하는지 흐려진다.

현재 요구사항과 폐기한 시도를 나누고, 캡처나 대화가 어느 코드 버전에서 나온 것인지 표시한다. 회사 코드나 고객 자료는 전달 가능한 범위를 확인한다.

가상 데이터로도 같은 문제가 나면 그 예제를 먼저 준비한다. 화면과 로그에 남은 이메일, 토큰, 고객 정보도 공유 대상인지 확인해야 한다.

가상 신청 페이지로 인계 메모를 써보면

아래는 양식 작성법을 보여주는 가상 예시다. 실행한 앱이나 실제 고객 납품 사례가 아니다.

• 전달 버전: 상담 신청 연습 앱, practice-v1.zip, 예시 버전 v1
• 시작 방법: 압축을 푼 폴더의 index.html을 브라우저로 연다고 가정
• 입력과 순서: ‘연습 사용자’, ‘테스트 신청’을 넣고 신청 버튼 선택
• 현재 결과: 완료 문구는 보이나 새로고침하면 기록이 사라진다고 가정
• 기대 결과: 같은 브라우저에서 새로고침한 뒤 테스트 신청 1건 확인
• 이번에 제외할 일: 여러 기기 공유, 관리자 계정, 이메일 발송, 공개 서버 배포

이렇게 적으면 ‘신청 앱을 완성해 주세요’보다 확인할 범위가 구체적이다.

다만 저장 방식과 실패 원인은 실제 코드를 보고 결정할 일이다. 가상 예시의 실행 방식이나 결과를 모든 프로젝트의 정답으로 쓰지는 않는다.

수정 후 받을 자료도 먼저 정해둔다

받는 사람이 전달된 버전으로 문제를 재현했는지, 수정한 버전에서 같은 입력의 결과가 달라졌는지 나눠 기록한다.

바꾸면 안 되는 기존 기능도 함께 확인한다. 첫 화면이 열린 것만으로 저장, 배포, 보안까지 확인한 것으로 적지 않는다.

인수할 때는 바뀐 코드, 같은 버전의 실행 안내, 바꾼 파일과 이유, 확인한 결과와 남은 문제를 요청한다.

확인하지 못한 항목은 담당과 다음 확인 날짜를 남긴다. PDF 2쪽을 처음 받을 때와 수정 후에 각각 한 장씩 사용하면 두 상태를 구분하기 좋다.

아직 무엇을 맡길지 정하지 못했다면 막힌 부분만 의뢰하는 기준에서 범위를 먼저 좁혀보면 좋다.

실제 자체 제작 묶음의 구성이 궁금하면 CSV 업무 자동화 프로젝트의 설명서·예제·검사 파일을 참고할 수 있다.

처음부터 실습하려면 바이브코딩 시작 가이드로 이어진다.

검증 기준

• 마지막 업데이트일: 2026-09-08
• 확인 환경: 공개 서비스의 설명·준비사항과 GitHub 공식 문서 본문을 대조한 인계 자료다. 별도 가상 예시는 실행 결과나 고객 납품 실적이 아니다. 양식은 필기용이며 PDF 입력칸은 없다.
• 주요 근거: 부분 수정 서비스의 준비사항, 앱 배포 서비스의 준비사항, GitHub README 안내