많은 프리랜서분들이 미팅을 '프로젝트 수주'만을 위한 관문으로 생각하지만, 사실 미팅은 프로젝트의 성패를 가르는 가장 결정적인 순간일 수 있습니다. 코딩 실력과는 별개로, 프로젝트가 순조롭게 흘러갈지 혹은 분쟁으로 이어질지는 이 첫 만남에서 어떻게 조율하느냐에 달려있거든요.

프로젝트 분쟁은 대부분 '동기화의 실패'에서 비롯됩니다. 클라이언트와 파트너가 서로 다른 기대를 하고, 업무 범위를 다르게 해석하고, 결과물의 수준을 다르게 상상하는 것이죠.

성공적인 미팅이란 이 '동기화 수준'을 최대로 끌어올리는 과정입니다. 이를 위해선 두 가지가 반드시 필요합니다.

첫째, 프로젝트를 위험에 빠뜨릴 수 있는 '위험 신호'를 감지하는 것.
둘째, 애초에 위험이 발생하지 않도록 철저히 '준비하고 확인'하는 것.

이번 편에서는 수많은 프로젝트의 성공과 실패 사례를 바탕으로, 미팅에서 감지해야 할 '위험 신호 체크리스트'를 집중적으로 다루겠습니다. 다음 편에서는 위험을 사전에 방지하는 '필수 준비/확인사항'을 상세히 다룰 예정입니다.

참고로, 위시켓이에서는 프로젝트의 주체를 프로젝트를 의뢰하는 ‘클라이언트’와 이를 수행하는 ‘파트너’로 구분합니다. 하지만 다양한 사업 형태에 있는 개발자 분들이 모두 편히 읽으실 수 있도록 프로젝트를 수행하는 파트너를 ‘개발자’로 표현했습니다.

계약서 작성하기 전 알아야 할 '위험 신호'

프로젝트가 성공적으로 완료되기 위해서는 프로젝트와 클라이언트의 준비 상태를 먼저 파악해야 합니다. 다음은 미팅 전후 단계에서 유심히 살펴봐야 할 대표적인 '위험 신호'들이에요. 계약서 작성 전 단계에 고려할 부분과 계약서 작성 단계에서 고려할 부분이 각각 있습니다. 차례대로 알아보겠습니다.

1. 불분명한 요구사항

가장 흔하고 강력한 위험 신호입니다. '불분명함'의 기준은 '서면으로 정리할 수 있느냐' 여부입니다. 서면으로 정리할 수 있어야 명확한 것이고, 그렇지 않다면 불명확한 것입니다. 물론 문서로 정리된 요구사항이 있더라도 프로젝트의 방향성이 명확하지 않을 수 있지만, 서면으로 만들어진 자료는 추후 프로젝트 진행 간 과업 범위에 변동성에 가장 큰 영향을 미칩니다.

예를 들어, 만약 클라이언트가 "SNS 로그인이 필요할 수도 있어요"라고 말했다면, 이는 "SNS 로그인이 필요 없습니다"라는 말과 과업의 차이가 큽니다. SNS 로그인은 요즘 많이 보편화되어 있는 기술이기는 하지만, 의뢰받은 일을 하는 개발자 입장에서는 이것을 하는 것과 안하는 것의 차이는 크기 때문에 명확하게 확인해야 하죠.

클라이언트들이 당연하고 쉽게 생각하지만 개발자분들이 실제 받아들이기에 난이도가 다른 것 중 대표적인 것은 결제나 쿠폰 기능입니다. 생각보다 결제나 쿠폰 기능 수준에 대한 이해 차이로 많은 견적에서 차이가 발생하거나 분쟁이 나기도 합니다. 클라이언트들은 단순 ‘결제’라고 말하지만, 개발자에게는 정기 결제냐, 단순 결제냐에 따라 기능, 정책 등 다양한 프로세스가 추가되기 때문이죠. 또 쿠폰도 할인의 형태나 유효 기간 등에 따라 기능의 범위가 달라집니다. 따라서 “나중에 정하자”거나 “필요할 수도 있다”라는 불분명한 상태에 두기 보다 꼭 확인해야 합니다.

물론 이러한 부분은 개발자의 경험에 의존할 수밖에 없습니다. 하지만 분명히 쿠폰 기능이 필요할 것 같은데 클라이언트가 말을 하지 않는다거나 쿠폰 기능을 요청하면서 어떤 형태의 쿠폰을 요구하는지를 이야기하지 않는다면, 이는 불확실하고 불분명한 상태라고 판단해볼 수 있습니다.

클라이언트의 요구사항이 불분명한 이유

클라이언트가 요구사항을 명확히 정리하지 않는 이유는 대체로 두 가지 이유입니다.

바빠서(또는 우선순위가 낮아서)
정말 몰라서

'몰라서'는 사실 클라이언트에게 조금만 가이드를 준다면 해결되는 문제입니다. "A의 포맷으로 B의 수준으로 정리해주세요~"라고 요청한다면 대부분의 클라이언트는 명확한 업무 전달을 위한 정리를 시작합니다. 하지만 '바빠서' 안 해주는 건, 사실상 "알아서 해달라"는 말과 같습니다.

이 '알아서’라는 것을 서로 똑같이 이해하고 있다고, 즉 ‘동기화’되어 있다고 생각하면 안 됩니다. 각자 생각하는 것이 다를 수 있습니다. 명확한 정리를 요청했지만 거부한다면, 이 프로젝트를 통해 예상치못한 업무 범위와 퀄리티가 요청될 수 있음을 감안해야합니다.

이같은 불분명한 요구사항은 개발 지식이 없는 클라이언트는 물론, 개발 지식이 있는 클라이언트에게서도 나타납니다. 대표적으로 이런 식으로 요구사항을 전달합니다.

"이 사이트랑 똑같이 만들어주세요."

개발 지식이 없는 클라이언트가 "이 사이트랑 똑같이 만들어주세요."라고 하는 경우, 클라이언트 입장에서는 특정 사이트를 지목했으니 명확하다고 생각할 수 있어요. 하지만 문제는, 계약 전 단계에서 개발자가 그 사이트의 모든 기능을 파악할 수 없고, 막상 예산 제약이 생기면 어떤 기능을 넣고 뺄지 불분명해지는 경우가 많습니다. 명확한 레퍼런스가 있더라도, 계약 진행 중에 생각지도 못했던 거대한 기능이 숨어있을 수 있으니 꼭 확인이 필요합니다.

“넣어도 되고 안 넣어도 되고”

이런 '여지'가 있는 표현은 조심해야 합니다. 클라이언트 입장에서는 "쉽게 합의해서 넣을 수 있다"라는 기대로 남아있는 경우가 많거든요. 이럴 땐 계약서에 '대상 범위'보다 '제외 범위'를 명확히 쓰는 게 과업을 정리하는 데 더 도움이 될 수 있습니다.

"백엔드 몇 개만 하면 돼요." “중간중간 협의하면서 가죠”

개발 지식이 있는 클라이언트 중 "백엔드 몇 개만 하면 돼요." “중간중간 협의하면서 가죠” 라고 불분명하게 이야기하는 분들도 있습니다. 이 경우에는 작업 자체를 너무 쉽게 생각하거나 클라이언트의 일 중 우선순위가 낮아 명확히 정리하지 않는 경우일 수 있습니다.

하지만 작업의 난이도는 클라이언트가 아니라 이 과업을 수행하게 될 개발자가 판단해야 합니다. 심지어 클라이언트가 소스 코드를 주면서 "이 부분만 바꿔주세요"라고 한다 해도, 개발사 입장에선 남의 코드를 분석해야 하니, 클라이언트가 생각하는 것보다 작업 난이도가 올라갈 수 있습니다. 클라이언트가 개발을 잘 안다고 할지라도 과업 범위를 잘 기록해두어야 하는 것은 똑같습니다.

위시켓에서는 클라이언트가 요구사항을 명확하게 정리할 수 있도록 템플릿을 제공해 가이드하고 있습니다.

➡️위시켓 요구사항 정의서 템플릿 보러가기

2. 낮은 견적 요구

파트너가 생각하는 적정가보다 클라이언트 예산이 현저히 낮은 경우도 계약을 진행하는 것을 진지하게 고려해봐야 합니다.

이에 더해 진짜 위험한 상황은 예산이 부족하니 "진행 간에 합의하면서 진행해보자.", "충분히 협조해서 과업 줄여나가겠다"라고 하는 것입니다. 예를 들어 개발자가 생각하는 적정 단가는 1000만원인데, 클라이언트가 800만원을 제안합니다. 그 뒤 "일단 800에 시작하고, 진행하면서 과업을 좀 줄여보시죠" 혹은 "금액에 맞춰 합의하겠다"고 제안하는 상황이겠죠.

이런 식의 구두 합의는 거의 대부분 분쟁으로 이어집니다. 왜냐하면 클라이언트가 업무에서 제외하려고 하는 기능이나 화면이 개발자가 기대했던 수준의 공수가 아닌 경우가 많기 때문이죠. 예를 들어, 클라이언트는 'SNS 로그인' 기능 정도를 합의해서 빼려고했고, 개발자는 '정산' 정도는 제외하겠지라고 생각하는 것과 같습니다.

그래서 '수행하면 손해인데' 싶은 견적의 프로젝트는 계약을 하지 않는 게 나을 수 있습니다. 외주 프로젝트는 항상 변수가 생기는데, 앞서 예로 든 상황에서 합의한 800만원이라는 견적은 더 이상의 변수는 없다고 가정한 것이나 다름없습니다. 하지만, 예상 그대로만 흘러가는 프로젝트는 정말 드뭅니다.

3. 요구사항 대비 짧은 기간(디데이가 명확한 경우)

요구사항 대비 기간이 짧은 프로젝트는 대부분 클라이언트에게 타협할 수 없는 일정이 정해진 프로젝트인 경우가 많습니다. 예를 들어 정해진 날짜까지 서비스를 오픈하거나 프로토타입이 만들어져 있어야 하는 경우입니다. D-day가 명확하게 정해진 경우죠.

이때 파트너는 '시간이 없으니 몇몇 기능과 화면은 빠지겠지'라고 가정하고, 클라이언트는 '모든 기능이 D-day까지 완성되겠지'라고 가정합니다. 이 어긋난 가정이 문제입니다. 대부분 프로젝트는 계약 후에 퀄리티와 업무 범위를 조정하는 것이 어렵습니다. 그래서 이렇게 특정 디데이를 요구하는 프로젝트에서는 계약 전에 그 디데이를 기준으로 디데이 전까지 완성되어야 할 것과 디데이 이후 완성해야 할 것을 명확히 구분해야 합니다.

또 이런 경우, 클라이언트에게 그 D-day가 왜 중요한지도 확인해야 합니다. 예를 들어 학생 대상 서비스를 새 학기 시즌에 맞춰 출시해야 한다면, 그 시즌을 못 맞출 경우 클라이언트의 비즈니스가 실패하는 것이기 때문에, 분쟁이 더 커질 수 있습니다.

4. 클라이언트가 프로젝트를 너무 쉽게 생각하는 경우

"이런 건 요즘 다 하잖아요", "제 친구한테 물어보니 별로 안 어렵다던데요?" "이 정도는 알아서 해주실 수 있죠?" 같은 발언은 위험신호일 수 있습니다. 클라이언트가 프로젝트의 난이도를 낮추는 표현을 하는 경우죠.

이런 클라이언트는 흔한 기술과 자주 보는 기능들은 무조건 쉬울거라고 생각합니다만, 현실은 그렇지 않는 경우도 많습니다. 더 큰 문제는, 나중에 추가 과업이 발생해도 '그것도 쉬운 일'이라고 생각하기 때문에 추가 비용 집행을 설득하는 것 자체가 어려워집니다.

또한, 쉬운 일이라 생각하니 미팅에 잘 참여하지 않거나 피드백을 주지 않는 등 소통이 어려울 수 있으니 경계하는 것이 좋습니다.

5. 약속된 미팅 일자, 소통 방식을 지키지 않는 경우

계약 전 첫 미팅부터 일정을 어기거나 자료를 주기로 한 약속을 지키지 않는 경우도 위험 신호입니다.

계약 전에 보인 모습은 계약 후에도 똑같이, 심지어 더 심하게 반복될 수 있습니다. 계약을 하고 나면 이러한 약속들과 소통을 더 쉽게 생각하는 경우도 있어서 ‘계약 전엔 약속을 어겨도 계약 후엔 달라지겠지’라고 생각하면 안 됩니다. 보통 이런 클라이언트는 프로젝트 진행 중 의사결정을 미루거나, 결과물 검수를 차일피일 미뤄 대금 지급을 지연시킬 가능성도 높습니다.

그런데 약속된 미팅 일자, 소통 방식은 개발자 또한 잘 지켜야 합니다. 클라이언트 또한 약속된 때 제대로 자료를 주는지, 미팅 일정을 지키는지 등을 통해 첫인상을 갖게 되고, 그 첫인상을 신뢰할 만한 곳인지 가늠하는 기준 중 하나로 삼기 때문입니다.

6. 클라이언트의 의사결정권자가 너무 많은 경우

대기업이나 중견기업은 어쩔 수 없지만, 2~3명의 공동 창업자나 친구들이 미팅에 함께 들어와 각자 다른 질문을 하고, 현장에서 의견 합의가 안 되는 경우입니다. 주로 초기 스타트업처럼 팀을 꾸린지 얼마 안 된 곳에서 발생합니다.

이처럼 동등한 레벨의 의사결정권자가 많은 경우는 프로젝트의 안정성을 떨어뜨리기 때문에 경계해야 합니다. '사공이 많으면 배가 산으로 간다'는 말처럼, 요구사항이 계속 바뀌고 프로젝트가 산으로 갈 확률이 높기 때문이죠. 소통해야 할 사람이 한 명으로 특정되지 않으면 리스크가 커집니다. 이는 주로 미팅에서 확인할 수 있습니다. 어떤 기능에 대해 논의하려 하는데, 미팅에 참석한 사람들이 그 자리에서 논의를 시작하고, 서로간에 협의가 되지 않는 모습을 보인다면 그런 경우일 수 있습니다.

이런 경우, 정중하게 "프로젝트의 변동성을 낮추기 위해 최종적으로 커뮤니케이션을 담당할 분이 한 분이면 좋겠다"고 요청하는 게 좋습니다. 이런 요청에 대해서는 대부분 합리적이라고 생각하고 받아들이기 때문에 이런 요청을 하는 것을 주저하실 필요 없습니다.

계약서 작성 단계에서 알아야 할 '위험 신호'

이제 모든 확인을 마치고 계약서를 쓰게 됩니다. 이 단계에서도 프로젝트의 안정성을 떨어뜨리는 위험 신호를 알 수 있습니다. 계약 단계에서 아래 네 가지 사례는 대표적으로 경계해야 하는 사례이므로 꼭 알아두세요.

1. 계약서 작성 거부

가장 심각한 위험 신호 중 하나입니다. "금액도 작은데 뭘", "일정도 짧은데 그냥 하시죠"라며 계약서 작성을 거부하는 경우입니다.

물론 구두 계약, 문자, 카톡도 법적 효력은 있기 때문에 계약서를 쓰지 않더라도 프로젝트 대금을 아예 받지 못하는 건 아닙니다. 하지만 분쟁이 생겼을 때, 검수 기간, 하자보수 범위, 지적재산권 등 아무것도 합의된 것이 없기에 계약 상대자 모두가 극도로 불리해집니다. 돈을 받는 과정에서의 고통이 너무 큽니다.

특히 소규모 개인 사업자분들이 수주가 급해서 계약서 없이 진행하다가 탈이 나는 경우가 있는데, 그 문제 해결하느라 다음 프로젝트 수주를 못하는 악순환이 생길 수 있기 때문에 계약서 작성을 거부하는 프로젝트를 경계해야 합니다.

2. 이면 계약서 작성 요청

보여주기용 계약서를 작성하고 그와 다른 내용의 계약서를 하나 더 쓰는 경우를 말합니다.

이런 요구는 대부분 정부 지원 사업에서 나옵니다. 정부 지원 사업은 '자금 집행 마감일'이 정해져 있기 때문인데요. 그래서 "일단 지원금 정산을 위해 A 계약서(완료된 것처럼)를 쓰고, 실제 업무는 B 계약서(이면 계약)로 따로 진행하죠"라고 제안하는 경우가 있습니다. 정부지원 사업 외에도 보통 자금을 융통하기 위한 목적이 있을 때 이면계약을 쓰는 경우가 많습니다.

이는 불법의 소지가 있으며, 분쟁이 생겼을 때 어떤 계약서가 우선인지 불분명해져 계약 당사자의 권리를 지키기 어려워질 수 있습니다.

사실 이렇게 자금 집행일이 정해져 있는 경우에는 이면 계약을 쓸 것이 아니라, 디데이까지 마저 진행되지 못한 것은 하자 보수 기간에 하는 것으로 원본 계약서에 명시하여 진행하는 것이 낫습니다. 위시켓에서는 이면계약은 절대로 수용하지 않고 있으며, 정식 계약서 상에서 문제를 해결할 수 있도록 가이드하고 있습니다. 그렇게 한다고 해서 자금 지원이 불가능해지는 것은 아니므로 걱정하실 필요 없습니다.

이면계약은 개발자가 큰 리스크를 짊어질 수 있으므로 바로 알고 권리를 지키시면 좋겠습니다.

3. 규모가 크거나 일정이 긴 프로젝트임에도 대금 분할을 거부하는 경우

일반적으로 금액이 1천만 원 이상또는 기간이 2달 이상 되는 프로젝트는 과업을 나눠서 순차적으로 진행하는 게 안전합니다.

예를 들어 3천만 원 / 6개월짜리 프로젝트를 통으로 계약하면, 중간에 분쟁이 났을 때 3천만 원 전체를 기준으로 손해배상 등을 따져야 합니다. 하지만 1차, 2차로 나누면, 1차는 완료된 것으로 끝내고 2차에 대해서만 논의할 수 있습니다.

이걸 거부하고 '100% 잔금 지급'을 고수한다면, 개발자는 프로젝트 후반부로 갈수록 불리해집니다. 추가 과업이 생겨도 전체 대금이 볼모로 잡혀있어 협상이 어려워지는 거죠. 또는 '잔금 비중이 80%'처럼 과도하게 높은 경우도 마찬가지입니다. 대금은 실제 과업 비중에 맞춰 나누는 게 가장 적절합니다. 단순하게는는 100일짜리 프로젝트에서 기획에 20일이 걸린다면 기획 완료 시점을 기준으로 20%를 정산하는 식입니다.

4. 현금이 아니라 지분 등 기타 수익 셰어를 통한 지급 방식

"우리 회사 지분을 주겠다", "서비스 오픈하면 수익금을 나눠주겠다" 혹은 '어음'으로 지급하겠다는 제안도 위험신호입니다.

이는 초기 스타트업에서 "우리는 지금 당장 끝날 사람이 아니라 동업자를 찾는다"는 말과 함께 자주 나옵니다. 클라이언트가 진심일 수는 있지만, 그 미래의 수익은 보장되지 않습니다. 계약서상의 현금 계약이 원칙입니다.

마치며

혹시나 위에서 말씀드린 위험 신호가 있다고 꼭 프로젝트를 드랍해야한다고 오해하는 분들이 없으시길 바랍니다. 이미 여러분들도 잘 아시다시피 프로젝트의 성공은 하나의 단편적인 모습만으로는 예측할 수 없습니다.

다만, 성공적인 프로젝트는 단순히 코딩을 잘하는 것만으로 완성되지 않습니다. '리스크 관리'가 필요하고 이를 더욱 안전하게 유도하고 만드는 것 또한 중요한 프로젝트 역량이라는 것을 말씀드리고 싶습니다.

클라이언트와의 첫 미팅은 그 리스크를 관리할 수 있는 가장 중요하고 첫 번째 기회입니다. 오늘 살펴본 '위험 신호'들을 민감하게 감지하고, '필수 확인 리스트'를 통해 클라이언트와 기대 수준을 꼼꼼하게 '동기화'하는 습관이 필요합니다.

이런 철저한 준비는 여러분을 단순한 '개발 용역'이 아닌 신뢰할 수 있는 '전문 파트너'로 만들어줄 것입니다. 이 과정이 클라이언트와의 신뢰를 구축하고, 나아가 프로젝트를 안정적인 성공으로 이끄는 가장 튼튼한 기반이 될 것이므로 꼭 확인하고 위험을 낮추시길 바랍니다!