개인 프로젝트를 계속 맡기 어려워져 다른 개발자에게 넘기기로 했습니다. 코드는 저장소에 있고 설치 방법도 적혀 있으니 소유자를 바꾸면 끝날 것 같습니다. 그런데 며칠 뒤 배포 오류 알림은 여전히 이전 담당자에게 오고, 새 담당자는 서버 요금이 누구에게 청구되는지 모릅니다.이는 설명을 위한 가상 상황입니다. 혼자 만든 서비스에는 코드 밖의 결정이 많이 쌓입니다. 어디서 배포하는지, 어떤 계정으로 결제하는지, 장애가 나면 누구에게 연락하는지를 한 사람이 알고 있으면 평소에는 편하지만 인계할 때 빈틈이 드러납니다.이 글은 2026년 11월 1일 확인한 GitHub 공식 문서와 인계 절차 제안을 구분해 정리합니다. 실제 저장소 이전이나 배포를 실행한 후기가 아닙니다. 다른 서비스의 소유권 변경 조건까지 같다고 ..

혼자 만든 서비스를 운영하다 보면 새 기능을 만드는 일보다 이미 있는 기능을 설명하고 고치는 일이 더 많은 날이 옵니다. 저는 한동안 이 일을 모두 호의로 처리했습니다. 그러다 보니 사용자 한 명의 요청이 다음 주의 약속이 되고, 약속이 쌓일수록 정작 제품을 개선할 시간이 사라졌습니다.이번 글에서는 서비스를 접을지 말지의 문제가 아니라, 어떤 일만 남기고 어떤 요청은 계약 밖으로 둘지 정리한 과정을 적어보겠습니다. 금액을 정답처럼 제시하기보다 범위와 응답 기준을 먼저 세우는 방법에 집중합니다.유지보수와 신규 개발을 먼저 나눴습니다같은 코드베이스에서 나온 요청이라도 성격은 다릅니다. 오류를 원래 동작으로 되돌리는 일은 유지보수이고, 새로운 화면이나 업무 규칙을 추가하는 일은 신규 개발입니다. 둘을 같은 창..