열정적으로 시작한 프로젝트가 중반부터 삐걱댄다. “이 기능도 당연히 포함 아니었어요?”, “처음에 이렇게 말씀하셨잖아요.” 서로 다른 기억, 서로 다른 기대. 결국 분쟁으로 번지고 대금은 밀리고 다음 일정까지 꼬인다. 그런데 이 문제의 90%는 계약서에 사인하기 한참 전, 첫 미팅에서 이미 예고돼 있다. 우리가 그 신호를 못 읽을 뿐이다. 오늘은 프리랜서 개발자 위험 신호를 계약 전과 계약서 단계로 나눠 짚는다.
진짜 원인은 기술이 아니라 ‘동기화의 실패’
많은 개발자가 “내 코딩 실력이 좋으면 프로젝트는 성공한다”고 믿는다. 기술은 중요하다. 하지만 현실에서 프로젝트를 망치는 건 대부분 기술 문제가 아니다. 진짜 원인은 동기화의 실패다.
클라이언트는 A를 기대하고 개발자는 B를 준비한다. 한쪽은 “당연히 이 정도는 포함이지”라 여기고, 다른 쪽은 “이건 추가 과업이니 별도 비용이지”라고 판단한다. 서로 다른 주파수로 대화하는 셈이다. 좋은 미팅이란 이 주파수를 맞추는 과정이고, 그 첫 단계가 위험 신호를 정확히 읽는 것이다.
계약 전에 보이는 프리랜서 개발자 위험 신호 6가지
1. 불분명한 요구사항
“이 사이트랑 똑같이 만들어주세요.” 명확해 보이지만 이만큼 위험한 말도 없다. 그 사이트에 숨은 결제 시스템, 복잡한 쿠폰 로직, 회원 등급별 권한을 다 파악할 수 있나. 기준은 하나다. 서면으로 정리되면 명확한 것이고, 안 되면 불명확한 거다.
“SNS 로그인이 필요할 수도 있어요”라는 한마디는 “필요 없다”와 공수 차이가 크다. OAuth 인증, 사용자 정보 매핑, 보안 처리가 줄줄이 따라오니까. 결제와 쿠폰은 특히 조심해야 한다. 일회성인지 정기 결제인지, 부분 취소가 되는지, 쿠폰이 정액인지 정률인지, 중복과 유효기간은 어떤지에 따라 작업량이 몇 배로 갈린다. 요구사항이 흐릿한 이유는 보통 둘 중 하나다. 바빠서 “알아서 해달라”는 경우와, 정말 몰라서 정리를 못 하는 경우. 후자는 포맷과 예시를 주면 대개 풀린다. 전자는 끝까지 정리를 거부한다면 위험하다. 이건 단순한 취향이 아니라 외주에서 가장 흔한 스코프 크리프(scope creep)의 출발점이다.
2. 낮은 견적 + “하면서 줄이죠”
내가 생각한 적정가는 1,000만 원인데 클라이언트가 800만 원을 부르며 말한다. “일단 800에 시작하고, 가면서 과업을 좀 빼죠.” 이런 구두 합의는 거의 분쟁으로 간다. 서로 빼려는 기능의 공수가 다르기 때문이다. 클라이언트는 ‘SNS 로그인’을, 개발자는 ‘정산 기능’을 빼려 한다. 같은 200만 원어치라도 머릿속 작업이 전혀 다르다. 게다가 외주엔 늘 변수가 생긴다. 합의한 800만 원은 “더 이상 변수 없음”을 가정한 금액인데, 그렇게 흘러가는 프로젝트는 드물다. 하면 손해인 견적이면 차라리 계약하지 않는 게 낫다.
3. 빠듯한 기간과 D-day 압박
요구사항에 비해 기간이 짧고 D-day가 박힌 프로젝트는 특히 위험하다. 개발자는 “시간이 없으니 몇 기능은 빠지겠지”라 가정하고, 클라이언트는 “전부 D-day까지 완성되겠지”라 가정한다. 이 어긋남이 씨앗이다. 그 D-day가 클라이언트 비즈니스의 생사를 가른다면 분쟁의 강도는 더 커진다. 새 학기에 맞춰 출시해야 하는 학생 서비스가 시즌을 놓치면 사업 자체가 흔들리니까. 해법은 단순하다. 계약 전에 ‘디데이 전까지 완성할 것’과 ‘디데이 이후 완성할 것’을 명확히 갈라두면 된다.
4. “이 정도는 쉽잖아요”
“요즘 이런 거 다 하잖아요.” “친구한테 물어보니 안 어렵다던데요.” 난이도를 임의로 낮추는 말은 강한 위험 신호다. 이런 클라이언트와 일하면 나중에 추가 과업이 생겨도 “그것도 쉬운 거잖아요”라며 추가 비용을 인정하지 않는다. 쉬운 일이라 여기니 미팅도 대충, 피드백도 늦다. 소통 자체가 어려워진다.
5. 약속을 안 지키는 클라이언트
첫 미팅 일정을 어기고, 주기로 한 자료를 안 주고, 연락이 잘 안 된다. 계약 전 모습은 계약 후에 반복된다. 오히려 심해진다. “이미 계약했으니까”라는 심리가 약속과 소통을 더 가볍게 만들기 때문이다. 계약 전에 약속을 어긴 클라이언트는 검수를 미루고 대금 지급을 늦출 확률이 높다. 물론 이건 개발자도 똑같다. 약속한 일정과 소통 방식은 나부터 지켜야 한다. 클라이언트도 그걸로 내 신뢰도를 잰다.
6. 사공이 많은 배
공동 창업자 두세 명이 미팅에 함께 들어와 각자 다른 질문을 하고 현장에서 합의가 안 된다. 팀을 꾸린 지 얼마 안 된 초기 스타트업에서 자주 본다. 동등한 결정권자가 많을수록 프로젝트는 산으로 간다. 정중하게 요청하자. “변동성을 낮추기 위해 최종 커뮤니케이션 담당자가 한 분이면 좋겠다.” 대부분 합리적인 요청으로 받아들인다. 어떤 일을 직접 쥐고 어떤 일을 넘길지는 창업자가 절대 위임하면 안 되는 4가지와도 통한다.
계약서 단계에서 만나는 위험 신호 4가지
확인을 다 마치고 계약서를 쓰는 단계다. 여기서도 방심하면 안 된다.
1. 계약서 작성 거부
“금액도 작은데 뭘”, “일정도 짧은데 그냥 하시죠.” 계약서 거부는 가장 심각한 레드 플래그다. 구두나 카톡도 법적 효력은 있지만, 분쟁이 나면 검수 기간, 하자보수 범위, 지적재산권 중 합의된 게 없어 양쪽 다 극도로 불리해진다. 수주가 급한 1인 사업자가 계약서 없이 갔다가 그 뒷수습에 다음 수주까지 놓치는 악순환을 흔히 본다. 계약서는 선택이 아니라 필수다. 막막하다면 과학기술정보통신부가 배포한 SW분야 표준계약서 6종을 기준으로 삼으면 된다. 프리랜서(SW종사자)용 도급계약서가 따로 있다.
2. 이면 계약서 요청
보여주기용 계약서를 하나 쓰고, 실제로는 다른 계약서를 따로 쓰자는 제안. 주로 정부 지원 사업의 자금 집행 마감 탓에 나온다. “정산용 A 계약서를 완료된 것처럼 쓰고 실제 업무는 B로 가죠.” 불법 소지가 있고, 분쟁 때 어떤 계약서가 우선인지 불분명해져 내 권리를 지키기 어렵다. 자금 집행일이 박혀 있다면, 이면 계약 대신 ‘디데이까지 못 끝낸 부분은 하자보수 기간에 진행한다’고 원본 계약서에 명시하면 된다. 이래도 지원에는 문제가 없다.
3. 대금 분할 거부
금액이 1천만 원 이상이거나 기간이 2달 이상이면 과업을 나눠 순차로 가는 게 안전하다. 3천만 원, 6개월짜리를 통으로 묶으면 중간에 분쟁이 났을 때 3천만 원 전체를 두고 다퉈야 한다. 1차·2차로 쪼개면 1차는 완료로 끝내고 2차만 논의하면 된다. 이걸 거부하고 ‘100% 잔금’이나 ‘잔금 비중 80%’를 고집하는 클라이언트는 경계하자. 개발자는 후반부로 갈수록 불리해지고, 추가 과업이 생겨도 전체 대금이 볼모로 잡힌다. 대금은 실제 과업 비중에 맞춰 나누는 게 원칙이다.
4. 현금 대신 지분·수익셰어
“회사 지분을 주겠다”, “오픈하면 수익을 나누겠다”, 혹은 어음으로 주겠다는 제안. 초기 스타트업에서 “우리는 용역이 아니라 동업자를 찾는다”는 말과 함께 자주 나온다. 진심일 수는 있지만 그 미래 수익은 보장되지 않는다. 계약서상의 현금 계약이 원칙이다. 지분과 보상이 실제로 어떻게 움직이는지는 초기 스타트업의 보상 전략을 보면 감이 잡힌다.
위험 신호를 봤다면, 드랍 말고 관리
여기까지 읽고 “신호가 하나라도 보이면 접어야 하나?”라고 생각할 수 있다. 아니다. 위험 신호는 ‘프로젝트를 버려라’가 아니라 ‘더 철저히 준비하고 확인하라’는 뜻이다. 프로젝트의 성공을 단면 하나로 점칠 수는 없다. 신호를 감지했으면 그 부분을 더 꼼꼼히 문서화하고, 더 명확히 합의하고, 더 구체적으로 계약서에 박으면 된다. 위험을 인지했다면 관리 장치를 만들면 그만이다.
첫 미팅 체크리스트
미팅이 끝나기 전에 아래만 점검해도 대부분의 분쟁을 미리 막는다.
- 요구사항을 지금 서면 한 장으로 정리할 수 있는가
- 디데이 전·후로 끝낼 범위를 갈라 적었는가
- 견적이 변수 발생까지 감당하는 금액인가
- 최종 커뮤니케이션 담당자가 한 명으로 정해졌는가
- 계약서에 검수 기간·하자보수·지재권·대금 분할이 들어가는가
코딩 실력보다 리스크 관리
좋은 프로젝트는 코딩만 잘해서 완성되지 않는다. 리스크를 미리 보고 안전하게 끌고 가는 것도 엄연한 역량이다. 첫 미팅은 그 리스크를 다룰 가장 중요한 첫 기회다. 신호를 민감하게 읽고 기대 수준을 꼼꼼히 동기화하는 습관이, 나를 단순한 ‘개발 용역’이 아니라 신뢰할 수 있는 ‘전문 파트너’로 만든다. 기술과 비즈니스를 함께 굴리는 감각이 왜 중요한지는 코딩과 마케팅을 반씩 나눈 1인 개발자 창업 전략이나 대행 서비스로 연 5억을 버는 1인 창업자들에서도 확인할 수 있다.
참고로 외주 제안서나 포트폴리오에 들어갈 깔끔한 비주얼이 필요하다면 Gen Studio로 직접 만들어 신뢰감을 더할 수 있다. 결국 신뢰는 첫 미팅의 디테일에서 시작된다. 다음 프로젝트의 성공도 오늘 이 신호들을 제대로 읽는 데서 출발한다.