개발자에게 넘기기

만든 서비스를 개발자나 업체에 맡길 때 코드와 연결 정보와 계정 권한을 함께 건네는 일이에요. 잘 넘기면 사람만 바뀌고, 잘못 넘기면 가게가 통째로 남의 손으로 가요.

쉽게 말하면

가게 주방을 새 주방장에게 넘긴다고 생각해 보세요. 건넬 게 세 가지예요. 레시피 노트(코드), 거래처 목록(연결 정보), 가게 열쇠(계정 권한)이에요. 여기까지는 다들 잘해요. 문제는 그다음이에요. 임대차 계약과 사업자등록까지 주방장 이름으로 해 두면, 그 사람이 그만두는 날 가게도 같이 나가요. 넘기는 것은 일이지 가게가 아니에요.

그래서 넘기기는 파일 하나 보내는 일이 아니에요. 성격이 서로 다른 세 묶음을 각각 다른 방식으로 건네는 일이에요.

위험한 넘기기

코드 = 개발자 저장소 도메인 = 개발자 계정 서버 = 개발자 카드로 결제

그 사람과 연락이 끊기면 내 서비스를 내가 못 만져요. 값을 부르면 낼 수밖에 없어요.

안전한 넘기기

코드 = 내 저장소 도메인 = 내 계정 서버 = 내 카드 개발자 = 담당자로 초대

사람이 바뀌어도 자리는 그대로예요. 일이 끝나면 초대만 끊으면 돼요.

무엇을 넘기나

무엇을 보내야 할지 헷갈릴 때는 이 표를 위에서부터 하나씩 지워 나가면 돼요.

묶음	안에 든 것	어떻게 건네나
코드	화면·디자인·동작이 담긴 완성품 파일과, 이 결과물이 지키던 규칙을 적은 안내문	파일로 내려받아 통째로 건네요. 압축 파일 하나면 끝이에요
연결 정보	어떤 데이터베이스를 쓰는지, 어떤 결제사를 붙였는지, 도메인은 어디서 샀는지	값이 아니라 지도예요. 어디에 무엇이 있는지 목록으로 적어서 문서로 건네요
계정 권한	도메인·호스팅·데이터베이스·결제사 계정에 들어갈 수 있는 자격	비밀번호를 알려주는 게 아니라, 그 사람 계정을 담당자로 초대해요
열쇠(비밀키)	결제사·문자·AI 서비스가 발급해 준 비밀값	나머지와 같은 봉투에 넣지 않아요. 아래에서 따로 다뤄요

가장 많이 빠뜨리는 건 두 번째예요

코드는 다들 챙기고 계정도 어떻게든 넘겨요. 그런데 어디에 무엇이 있는지 적은 지도가 없어서 새로 온 사람이 첫 2주를 탐색에만 써요. 그 시간도 사장님이 돈으로 내요. A4 한 장이면 충분해요.

바이브캠퍼스에서 만든 결과물이라면 첫 묶음은 버튼 하나로 해결돼요. 스튜디오 도구 막대의 핸드오프 팩을 누르면 완성품 파일(index.html), 실행하고 올리는 법을 적은 README.md, AI 코딩 도구에게 이 결과물의 규칙을 알려 주는 AGENTS.md 가 압축 파일 한 묶음으로 저장돼요. 자세한 건 내 것을 가지고 나가기에 있어요.

열쇠는 같은 봉투에 넣지 않아요

코드와 문서는 넉넉히 보내도 괜찮아요. 하지만 열쇠는 다르게 다뤄요. 결제사 비밀키, 데이터베이스 접속 정보 같은 것들이에요.

이유는 단순해요. 코드는 복사되라고 만든 것이고, 열쇠는 복사되면 안 되는 것이에요. 성격이 반대인 둘을 같은 봉투에 넣으면 안전한 쪽이 위험한 쪽을 따라가요.

1단체 대화방과 메일로 보내지 않아요. 한 번 올라간 비밀키는 그 방 기록에 영구히 남아요. 나중에 새 사람이 그 방에 들어와도 스크롤만 올리면 보여요.
2가장 좋은 방법은 아예 안 보내는 거예요. 결제사나 데이터베이스 계정에 그 개발자를 담당자로 초대하고, 키는 본인이 직접 발급받게 해요. 내 손을 거치지 않으니 샐 곳도 없어요.
3꼭 보내야 하면 1대1로, 그리고 짧게. 보낸 뒤 지우고, 일이 끝나면 그 키를 폐기하고 새로 발급받아요.
4끝나면 회수해요. 초대했던 담당자 권한을 끊고, 그 사람이 발급한 키를 죽여요. 열쇠공에게 맡겼던 여벌 열쇠를 돌려받는 것과 같아요.

새 키를 만들어도 옛 키는 살아 있어요

발급 화면에서 옛 키를 따로 지워야 죽어요. 새로 만들었다고 자동으로 꺼지지 않아요. 이 부분은 API 키에 더 자세히 있어요.

넘기기 전에 종이에 적을 네 가지

말로만 정하면 두 달 뒤에 서로 다르게 기억해요. 넘기기 전에 이 넷만 한 줄씩 적어 두면 분쟁의 대부분이 사라져요.

정할 것	안 정하면 생기는 일	이렇게 한 줄로 적어요
소유권	완성된 코드가 누구 것인지 애매해져요. 만든 쪽이 권리를 주장하면 나중에 서비스를 팔거나 다른 사람에게 맡길 때 막혀요	결과물의 모든 권리는 대금 완납과 동시에 발주자에게 넘어온다
넘기는 범위	코드만 주고 계정은 안 넘기거나, 문서 없이 파일만 던지고 끝나요	인수인계는 코드와 설정 문서와 계정 권한 이전을 모두 포함한다
이후 연락	다 끝난 줄 알았는데 한 달 뒤 화면이 깨지고, 연락하면 새 견적이 와요	납품 후 30일간 발생한 하자는 무상으로 수정한다
기록 남기기	무엇을 언제 넘겼는지 아무도 몰라서, 빠진 게 있어도 증명할 방법이 없어요	인수인계 완료일과 전달 목록을 문서로 남기고 양측이 확인한다

네 줄 다 계약서에 들어갈 문장이에요

어렵게 쓸 필요 없어요. 표에 적힌 그대로 넣어도 돼요. 도장을 찍기 전에 무엇을 봐야 하는지는 계약서 읽는 법에, 맡기는 요령 전반은 외주 맡기기에 있어요.

사장님이 실제로 겪는 장면

장면 1 · 외주 개발자가 편하게 제안한다

“제 계정으로 도메인 사고 서버도 올려 둘게요. 사장님은 신경 안 쓰셔도 돼요.”

친절한 제안이고 실제로 편해요. 그런데 그 순간부터 내 가게 주소가 남의 이름으로 등록돼요. 나중에 헤어지면 주소를 되찾는 게 일이고, 갱신일에 연락이 안 되면 주소를 통째로 잃기도 해요. 답은 간단해요. "결제는 제 카드로 할게요. 계정 주인은 저로 두고 담당자로 초대해 주세요." 대부분의 개발자는 흔쾌히 그렇게 해 줘요. 도메인은 특히 이걸 지켜야 하는 항목이에요.

장면 2 · 넘긴 지 반년, 연락이 닿지 않는다

“홈페이지가 안 열려요. 만들어 준 업체는 문을 닫았대요.”

이때 결과를 가르는 건 실력이 아니라 명의예요. 도메인·호스팅·데이터베이스가 내 계정에 있었다면 다른 사람에게 열쇠만 주면 하루 만에 되살아나요. 전부 그 업체 계정에 있었다면 되찾는 데 몇 달이 걸리고, 못 찾기도 해요. 그래서 넘기기의 핵심은 잘 주는 게 아니라 줄 수 없는 것을 안 주는 것이에요.

넘긴 뒤에도 내 것이 남는 구조

정리하면 원칙은 하나예요. 자리는 내 이름으로 두고, 사람은 초대해서 들여보내요.

1계정은 전부 내 이름으로 만들어요. 도메인·호스팅·데이터베이스·결제사 모두요. 결제 카드도 내 것으로요. 귀찮은 절차가 아니라 이게 소유권이에요.
2개발자는 담당자로 초대해요. 요즘 서비스는 대부분 사람마다 계정을 만들고 권한을 나눠 주는 기능이 있어요. 비밀번호를 공유하지 않아도 일이 돼요.
3코드는 내 저장소에 둬요. 바이브캠퍼스에서는 결과물을 내 깃허브 계정 저장소로 저장할 수 있어요. 수정 기록이 남으니 누가 언제 무엇을 바꿨는지도 보여요.
4손님 기록은 내 계정 데이터베이스에 쌓이게 해요. 이건 넘기고 말고의 문제가 아니라 처음부터 내 것이어야 하는 항목이에요. 손님 정보 다루기에서 다뤄요.
5떠날 때는 초대를 끊어요. 잘 헤어졌더라도 권한 정리는 그날 해요. 감정 문제가 아니라 절차예요.

권한을 끊는 날짜를 미리 적어 두세요

계약이 끝나는 날 달력에 "권한 회수"를 적어 두면 잊지 않아요. 이걸 안 해서 몇 년째 남의 계정이 살아 있는 곳이 정말 많아요.

자주 묻는 것

Q. 개발자에게 제 바이브캠퍼스 계정을 통째로 빌려주면 안 되나요?: 권하지 않아요. 계정 하나를 나눠 쓰면 누가 무엇을 했는지 구분이 안 되고, 헤어질 때 비밀번호를 통째로 바꿔야 해요. 결과물을 넘기는 게 목적이라면 핸드오프 팩을 내려받아 파일로 건네는 쪽이 훨씬 깔끔해요.
Q. 넘기고 나면 바이브캠퍼스에서 만든 건 못 쓰게 되나요?: 그렇지 않아요. 내려받는 건 복사본이에요. 스튜디오의 결과물도 게시해 둔 주소도 그대로 살아 있어요. 다만 밖에서 고친 내용은 바이브캠퍼스 쪽에 없으니, 어느 쪽이 원본인지 하나만 정해 두세요. 두 곳을 동시에 고치는 게 사고의 시작이에요.
Q. 코드를 넘기면 그대로 베껴서 다른 데 팔 수도 있잖아요?: 그래서 소유권 문장을 계약서에 넣는 거예요. 결과물의 권리는 발주자에게 있고 만든 쪽은 재사용하지 않는다는 한 줄이면 돼요. 다만 흔한 화면 구조나 누구나 쓰는 공개 도구까지 막을 수는 없어요.
Q. 인수인계 문서는 제가 써야 하나요, 개발자가 써야 하나요?: 만든 사람이 쓰는 게 맞아요. 넘기는 일에 문서 작성이 포함된다고 계약할 때 적어 두면 자연스럽게 따라와요. 다 끝난 뒤에 부탁하면 추가 비용 얘기가 나와요.
Q. 새로 온 개발자가 처음부터 다시 만들어야 한대요.: 절반은 사실이고 절반은 습관이에요. 남의 코드를 읽는 것보다 새로 쓰는 게 편하거든요. 판단 기준은 하나예요. 지금 서비스가 손님에게 돌아가고 있나요. 돌아가고 있다면 먼저 고쳐 보고 정말 안 되는 부분만 다시 만드는 게 싸요. 바이브캠퍼스 결과물에는 AGENTS.md 가 함께 들어 있어서, 처음 보는 사람도 구조를 부수지 않고 시작할 수 있어요.

확인해 보세요

외주 개발자가 "도메인이랑 서버는 제 계정으로 잡아 둘게요"라고 해요. 어떻게 답하는 게 좋을까요?

하나 더

핸드오프 팩을 개발자에게 보냈어요. 결제 비밀키는 어떻게 전달할까요?

직접 해보기

지금 무엇이 누구 이름으로 걸려 있는지 보세요

데이터베이스·결제사·깃허브처럼 내 서비스에 붙은 것들을 한 화면에서 볼 수 있어요. 넘기기 전에 한 번 훑어보면 어떤 계정이 내 것이고 어떤 게 아직 비어 있는지 정리돼요. 지금 연결하지 않아도 괜찮아요.

연결 센터 열기

더 깊이 (안 읽어도 괜찮아요)

인수인계 문서에 꼭 들어갈 다섯 줄 · 첫째, 이 서비스가 무엇을 하는지 두 문장. 둘째, 어떤 외부 서비스를 붙였는지 목록(결제사·문자·지도). 셋째, 각 계정이 누구 이름으로 되어 있는지. 넷째, 정기 결제가 나가는 항목과 금액과 결제일. 다섯째, 문제가 생겼을 때 가장 먼저 볼 화면. 다섯 줄이면 A4 한 장을 안 넘어요. 이 종이가 있는 곳과 없는 곳의 차이가 아주 커요.

정기 결제 목록을 왜 따로 적나 · 도메인은 보통 1년, 호스팅은 한 달이나 1년 단위로 자동 결제돼요. 개발자 카드로 걸려 있으면 그 카드가 만료되는 날 서비스가 조용히 멈춰요. 미리 알려 주고 멈추는 게 아니라서, 손님이 먼저 알아차려요. 결제 수단을 내 것으로 바꾸는 일은 넘기는 날 같이 해야 해요.

넘기기와 백업은 다른 일이에요 · 넘기기는 사람을 바꾸는 일이고 백업은 시간을 되돌리는 일이에요. 다만 넘기기 직전 상태를 파일로 한 벌 챙겨 두면 둘 다 돼요. 새 사람이 첫 수정을 하기 전의 모습이라, 나중에 뭔가 어긋났을 때 비교할 기준이 생겨요.

이것만 기억하세요

·넘기는 것은 코드·연결 정보·계정 권한 세 묶음이에요
·열쇠는 같은 봉투에 넣지 않아요. 직접 발급받게 하는 게 가장 안전해요
·계정 주인은 내 이름으로, 개발자는 담당자로 초대해요
·소유권·범위·이후 연락·기록, 네 줄은 넘기기 전에 종이에 적어요
·일이 끝나는 날 권한 회수도 같은 날 해요