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

기업 체감경기가 개선됐다는 뉴스를 읽었는데 이번 달 문의함은 조용합니다. 작은 서비스를 운영하거나 외주 개발을 하는 입장에서는 좋아졌다는 숫자보다 다음 계약이 언제 들어오는지가 더 가깝습니다. 이 차이를 보면 통계가 현실과 동떨어졌다고 느끼기 쉽습니다.하지만 지표가 설명하는 범위와 내 일이 생기는 경로를 나눠 보면 다른 질문을 할 수 있습니다. 어떤 기업의 심리가 좋아졌는지, 내 고객도 그 범위에 들어가는지, 문의에서 계약까지 시간이 얼마나 걸리는지 살펴보는 것입니다. 지표를 믿을지 말지 결정하기 전에 무엇을 측정한 숫자인지 확인할 필요가 있습니다.조사 기준일은 2026년 11월 1일입니다. 공식 발표에서 확인한 지표와 개인 사업자가 만들어 볼 수 있는 점검 방식을 구분해 정리했습니다. 아래 영업 사례와..