프리랜서 1인 의존이 위험한 이유 — 인수인계·장애 대응

실력 좋은 프리랜서 한 명에게 앱·웹·쇼핑몰을 맡기면 초반 소통이 빠릅니다. 의사결정 경로가 짧고, 중간 관리 비용도 적어 보입니다. “이 분이 우리 서비스를 다 알고 있다”는 안심도 생깁니다.

문제는 그 안심이 한 사람에게 모든 것이 매달린 상태라는 점입니다. 아프거나, 다른 프로젝트가 겹치거나, 연락이 끊기거나, 계약이 끝나면 지식·접속 권한·암묵지가 함께 사라질 수 있습니다.

이 글은 프리랜서 협업 자체를 부정하지 않습니다. 1인 의존 구조를 방치한 채 핵심 서비스를 올리는 위험과, 그 위험을 줄이는 방법을 다룹니다.

어떻게 1인 의존이 만들어지나요?

1. 빠른 시제품 성공으로 신뢰가 쌓인다
2. 문서보다 채팅·구두 합의가 편해진다
3. 서버·저장소·결제 계정이 개인 명의 또는 개인 관리로 남는다
4. “나중에 정리하자”가 오픈 이후까지 이어진다
5. 장애가 나면 그 사람만 알고, 그 사람만 고칠 수 있다

초기의 효율이 중기의 취약함이 되는 전형적인 경로입니다.

위험은 어디에 쌓이나요?

인수인계가 안 된다

코드 파일이 있어도 실행 방법, 배포 순서, 예외를 둔 이유, “절대 건드리면 안 되는 부분”이 머릿속에만 있으면 인수인계가 아닙니다. 후임 업체나 내부 담당자가 오면, 현황 파악 비용이 신규 개발에 가깝게 나옵니다.

장애 대응 약속이 없다

야간 결제 오류, 알림 장애, 서버 용량 부족 같은 일은 업무 시간에만 오지 않습니다. 1인 체계에서는 응답 가능 시간이 개인의 생활 리듬에 묶입니다. 휴가·병가·출장과 서비스 가동이 충돌합니다.

계정과 보안이 끊긴다

개인 이메일로 연 클라우드, 개인 카드로 묶인 도메인 자동결제, 공유되지 않은 2단계 인증 기기. 계약 종료 후 접근을 잃거나, 반대로 접근이 남은 채 권한이 정리되지 않는 양방향 위험이 있습니다.

서로 검토하는 눈이 없다

혼자 설계·구현·배포하면 빠른 대신 교차 검증이 없습니다. 결제·권한·개인정보처럼 실수 비용이 큰 영역에서 리뷰 부재는 리스크를 키웁니다.

규모가 커지면 병목이 된다

사용자가 늘고 기능 요청이 겹치면 1인의 처리량이 천장입니다. 일정을 늘리거나 품질을 희생하거나, 급히 다른 사람을 투입해 더 큰 혼선이 납니다.

1인 의존과 최소 팀, 무엇이 다른가

팀이 크면 무조건 좋다는 뜻이 아닙니다. 백업 가능한 최소 단위가 있느냐가 핵심입니다.

프리랜서와 안전하게 일하는 규칙

프리랜서를 배제하라는 뜻이 아닙니다. 아래를 계약과 운영에 넣으면 위험이 줄어듭니다.

1. 저장소·클라우드·도메인·스토어·결제는 발주자 조직 계정으로 열고, 수행자에게는 역할에 맞는 권한만 준다
2. 주 1회 이상 문서화된 진척(무엇을 배포했는지, 미결 결정이 무엇인지)을 남긴다
3. 핵심 경로 시나리오 점검표를 검수 산출물로 받는다
4. 휴가·연락 불가 시 대체 연락과 임시 조치 안내를 계약에 넣는다
5. 종료 시 권한 회수 목록을 잔금 조건에 연결한다
6. 가능하면 짧은 시간이라도 코드·구조 2차 의견을 외부나 내부에 맡긴다
7. 유지보수 계약에 응답 시간·범위·백업 인력 여부를 적는다

1인을 유지하면서 팀 효과를 만드는 중간 형태

예산 때문에 바로 팀 계약을 하기 어렵다면, 1인 실행에 부분 이중화를 더할 수 있습니다.

• 월 수 시간 단위의 코드 리뷰 파트너를 둔다
• 인프라·계정은 내부 IT 또는 별도 관리 계약으로 분리한다
• 결제·인증 같은 핵심만 문서화 의무를 강화한다
• 분기 1회 복구 연습(시험 환경에서 되돌리기·백업 복원)을 한다
• 휴가 시즌 전 지식 이전 시간을 캘린더에 고정한다

이 중간 형태는 비용이 들지만, 전면 재구축·장기 장애에 비하면 작습니다. 목표는 “신뢰하는 1인”을 “신뢰 + 검증 가능한 산출물 + 백업 경로”로 바꾸는 일입니다.

채팅으로만 일하던 방식을 이슈 기록으로 옮길 때 저항이 있다면, 처음에는 “배포할 때만 기록 남기기”처럼 최소 규칙부터 적용합니다. 완벽한 프로세스보다 끊기지 않는 기록이 우선입니다.

의존이 깨질 때 비용은 어떻게 오나

1인 의존이 깨지는 순간 비용은 감정적 배신감보다, 복구가 어려운 지연으로 나타납니다.

• 소스·서버 접근 불가로 긴급 재구축
• 결제·회원 데이터는 있으나 업무 규칙을 복원할 수 없음
• 스토어 계정·인증서·푸시 키 재발급으로 앱 업데이트 공백
• 대체 업체 온보딩에 수 주, 그동안 고객 이탈

“그분이 성실해서 괜찮다”는 과거 경험이지, 미래 리스크 통제가 아닙니다. 리스크 통제는 신뢰와 별개로 구조로 합니다.

이렇게 준비하면 좋아요

• □ 핵심 계정이 개인 명의가 아닌지 확인한다
• □ 저장소에 빌드·배포 설명이 있는지 본다
• □ 장애 시 24~72시간 안 대응 경로가 문서에 있는지 묻는다
• □ 알려진 이슈와 임시 우회가 기록으로 남아 있는지 본다
• □ 계약 종료 시 권한 회수 항목이 있는지 확인한다
• □ 1인 외에도 코드·인프라를 읽을 수 있는 접점이 있는지 본다
• □ 결제·개인정보 경로는 점검표를 거친다
• □ 유지보수에서 기능 추가와 장애 대응을 구분해 합의한다

사람이 떠나도 서비스가 남으려면, 지식은 사람 머리가 아니라 저장소와 운영 문서에 살아야 합니다.

LB Contents는 앱·홈페이지·쇼핑몰 제작과 운영 구조를 함께 설계합니다. 1인 외주에서 팀 체계·인수인계로 전환을 고민하는 단계의 상담도 가능합니다.