활용 가이드
담당자가 바뀌는데 구현 범위를 모를 때. 기획 메모와 코드를 대조해 완료 기능과 미구현 요청을 구분합니다. 실행 방법과 다음 담당자의 확인 목록을 남깁니다.
담당자가 바뀌어 프로젝트를 넘겨야 한다면, 기획 메모와 실제 코드를 대조해 다음 사람이 바로 확인할 인수인계 문서를 만드세요.
이런 문제가 있다면
이전 담당자의 메모에는 요청과 완료된 일이 섞여 있고, 새 담당자는 어디까지 구현됐는지 알기 어렵습니다. 실행 방법과 운영 정보까지 여러 곳에 흩어져 있으면 같은 질문을 반복하고 미완료 요청을 놓치기 쉽습니다.
Specify로 해결하기
- 프로젝트 메모와 버전을 표시한 코드 스냅샷을 Specify에 준비합니다.
- AI에게 요청과 구현을 대조해 완료 기능, 한도, 미구현 항목과 근거를 구분하도록 요청합니다.
- 실행 방법과 다음 담당자의 확인 목록을 문서로 저장하고, 운영처럼 코드로 알 수 없는 정보는 담당자가 보완합니다.
얻는 결과
개발팀·외주사·유지보수 담당자가 검토할 인수인계 문서를 만듭니다. RelayDesk Demo는 가상 프로젝트이며, 이 예제는 업로드한 코드 스냅샷과 프로젝트 메모를 실제로 읽어 대조합니다.
준비할 자료
예제 자료와 코드 내려받기 후 다음 두 문서를 워크스페이스에 올립니다.
| 자료 | 역할 |
|---|---|
relaydesk-project-brief.md | 기획 요청, 결정 기록, 담당 역할, 미확인 운영 정보 |
relaydesk-code-snapshot.md | 고정된 버전의 구현 코드·테스트·실행 명령 |
스냅샷은 저장소의 실시간 상태가 아닙니다. 실무에서는 버전·커밋과 대상 범위를 기록하고 변경되면 자료를 갱신하세요. GitHub 브랜치를 직접 연결하는 방식은 문서 프로젝트에서 시작할 수 있습니다.
따라 하기
메모와 코드 범위를 함께 준비하기
요구사항 메모, 코드 사본, 실행 안내를 모으고 각 자료의 버전을 명시합니다. 예제의 보안 정책을 실제 코드의 구현 증거로 사용하지 않습니다.새 채팅에서 인계받을 사람 정하기
새 채팅에서 신규 개발자나 유지보수 담당자 등 독자를 지정하고, 읽을 자료 이름을 적습니다.요청과 구현을 대조하기
완료 기능, 구현 한도, 후속 요청, 확인 불가 항목을 나누게 합니다. 각 판단에 원문 문서 ID와 코드 파일 경로를 요구합니다.실행 방법과 인계 항목 검토하기
문서를 저장한 뒤 명령을 직접 확인하고 미확인 운영 항목의 담당자를 정합니다. 테스트 파일이 있다는 이유만으로 시험 수행이나 성능 검증이 완료됐다고 판단하지 않습니다.
RelayDesk Demo 프로젝트 인수인계 메모와 코드 스냅샷 1.4를 읽어 대조해 주세요.
한눈에 보기 / 요청과 구현 대조표 / 실행·검증 방법 / 인수인계 확인 목록으로 작성하세요.
코드에서 확인한 기능과 한도, 기획 요청, 아직 없는 기능을 구분해 주세요.
문서 ID와 실제 파일 경로를 근거로 남기고, 없는 운영·배포 정보는 미확인으로 표시하세요.
코드 스냅샷은 고정된 사본임을 표시하고 라이브 저장소를 조사했다고 쓰지 마세요.
결과를 '프로젝트 인수인계' 문서로 저장하고 원문은 수정하지 마세요.이 예제에서 확인할 차이
- 기획 요청은 10,000건이지만 코드의 내보내기 한도는 1,000건입니다.
- 역할 매개변수를 검사하는 코드와 실제 로그인·권한 발급 시스템을 구분합니다.
- ZIP 기능과 실제 배포·복구 절차는 이 예제에 없습니다. 출시 일정이나 운영 담당자 실명을 추측해 채우지 않습니다.
최신 상태로 유지하기
이 실행은 업로드한 원문과 코드 스냅샷을 직접 참조한 사례입니다. 검색 색인에 아직 반영되지 않은 자료는 원문을 지정해 확인할 수 있습니다. 스냅샷 이후의 변경은 이 결과에 포함되지 않습니다.
새 버전의 자료를 준비한 뒤 같은 요청으로 차이를 다시 검토하세요. 자동으로 모든 운영 문서를 갱신한다고 가정하지 말고, 생성한 결과와 팀의 실제 인계 절차를 대조합니다.