하지만 미팅 준비부터 사후 대응까지, 작은 디테일 하나가 수주 성공률을 좌우합니다. 대부분의 클라이언트는 첫 미팅에서 이미 '이 파트너와는 견적도 안 받아도 될 것 같아요' 또는 '이 파트너는 너무 좋은데요, 견적 맞으면 바로 계약하고 싶어요' 같은 의사결정을 내립니다. 그런 만큼 굉장히 중요한 자리죠.

비유하자면미팅은 소개팅과 같습니다. 서로가 얼마나 잘 맞는 사람인지를 알아보는 자리죠. 그렇다 보니 상대방이 무엇을 좋아하고 무엇이 필요한지에 대한 준비가 없으면 성공적인 미팅은 애초에 불가능한 영역에 가깝습니다.

지난 프리랜서 개발자 가이드에서는 안전한 계약을 위해 미팅 전후 단계에서 필수적으로 체크해야 할 것을 알아봤습니다. 이번 글에서는 플랫폼에서 수천 건의 미팅을 지켜본 경험을 바탕으로, 실제로 계약률이 높은 개발자들이 공통적으로 하는 것들을 정리했습니다.

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

미팅 시작 첫 10분! 첫인상을 좌우하는 회사 소개

첫 미팅! 서로를 소개하는 자리입니다. 앞서 미팅은 소개팅과 같다고 말씀드렸죠. 그런 만큼 첫 10분이 상대의 첫인상을 결정하는 데 아주 중요합니다. 이때 우리가 해야 할 일은 효과적으로 자신을 소개하는 것입니다. 개인 개발자면 자기 자신을, 회사라면 회사를 소개해야겠죠. 이 소개부터 클라이언트에게 신뢰감을 줄 수 있어야 합니다.

어떻게 하면 소개를 잘할 수 있을까요? 정해진 정답은 없지만, 제가 계약률 높은 개발자들을 지켜본 결과, 아래 네 가지를 정말 잘하고 있었습니다.

다른 회사와 비교되는 우리 회사의 특장점 소개
업력과 인력 수 등 회사의 안정성 소개
작업 프로세스 소개
유사 포트폴리오 소개

하나씩 알아보겠습니다.

1) 다른 회사와 비교되는 우리 회사의 특장점 소개

혹시 “저희 웹 많이 만들어봤습니다” “앱 전문입니다” “개발 잘합니다” 이렇게 소개하고 계신가요? 이렇게 소개하는 분들을 정말 많이 봤습니다. 이런 말씀을 안 하시는 분들이 손에 꼽힐 정도로 없습니다.

그런데 이런 말은 클라이언트에게 대단히 의미 있는 소개로 들리지 않습니다. 클라이언트 입장에서는 어떤 회사와 만나더라도 듣는 말이죠. 더 구체적으로 우리 회사가 다른 회사보다 정말 더 신경 써서 작업하는 영역, 특출한 분야를 구체적으로 보여줘야 특장점이 어필이 됩니다.

예를 들어 이렇게 말이죠.

"저희가 디자인한 앱 서비스가 디자인 공모전에서 수상한 경험이 있습니다. 다른 회사와 달리 디자인에 대한 많은 역량을 가지고 있습니다."
"저희는 스타트업을 대상으로 계속 납품해 왔고, 특히 초기에 빠르게 서비스를 만들고 시장을 검증하는 과정에서 어떤 개발 프로세스로 가는 것이 좋은지 잘 알고 있는 회사입니다."

'개발을 잘한다', '디자인을 잘한다' 같은 모호한 표현보다는 우리가 어떤 영역에서 실제로 다른 회사보다 강점이 있는지, 어떤 영역에 주된 포트폴리오와 경험을 가지고 있는지 구체적으로 보여주는 것이 중요합니다.

또 이 특장점은클라이언트의 상황과 맞아떨어지는 것이 좋습니다. 클라이언트가 스타트업이라면 스타트업 경험을 강조하는 것이죠. 반대로 클라이언트가 대기업이라면 스타트업 경험은 잘 먹히지 않을 수 있습니다. 그럴 때는 대기업의 프로세스나 절차, 그 정도 규모의 프로젝트를 얼마나 안정적으로 수행해 왔는지에 대한 소개가 이루어져야 합니다. 스타트업, 대기업 경험을 다 해봤다 하더라도, 두 가지 경험을 장황하게 이야기하는 것보다 클라이언트 상황에 맞는 부분을 핵심적으로 소개하는 것이 더 효과적입니다.

2) 업력과 인력 수 등 회사의 안정성 소개

규모가 크지 않은프로젝트를 수행하는 개발자 또는 개발사에게는 상대적으로 그 중요도가 낮아질 수 있는 부분이지만, 규모가 큰 프로젝트나 규모가 큰 클라이언트의 프로젝트를 맡은 분들은 준비하고 어필해야 하는 내용입니다.

특히기획·디자인·개발을 한 번에 맡기는 턴키 프로젝트의 경우, 프로젝트 규모가 크다 보니 대부분의 클라이언트가 의뢰할 회사 자체의 안정성을 봅니다. 대표적으로 많이 보는 것이 업력과 인력 수입니다. 경험상 업력은 최소 기준이 1년, 적정 기준은 3년 이상입니다. 인력 수는 정규직 기준 20~30명 이상이면 큰 회사로 인식됩니다. 만약 업력이 3년 이상이고 인력 수가 15~20명 이상이라면, 이런 것들을 어필하거나 최소한 이 정도급 되는 회사임을 소개하는 장치가 필요합니다.

즉 턴키 프로젝트일수록 우리 회사의 안정성을 보여줄 수 있는 자료들이 회사 소개에 포함되어야 합니다. 어차피 결국 물어보게 되어 있으니, 우리가 먼저 이야기해 주는 것이 그런 경험과 안정성을 어필하는 차원에서 필요합니다.

또 대기업 프로젝트를 많이 해보신 분들은 잘 아시겠지만, 대기업은 신용등급이나 현금 흐름을 보는 경우도 있습니다. 이런 부분까지 깔끔하게 해소시켜줘야 클라이언트의 의구심을 제거하고 갈 수 있습니다.

3) 작업 프로세스 소개

말 그대로 프로젝트가 진행되는 과정에서 우리가 어떻게 작업을 진행하고, 그 과정에서 어떻게 클라이언트와 소통하며, 어떻게 결과물을 보여주는지에 대한 프로세스를 소개해야 합니다. 쉽게 말하면 납품 과정 같은 것이죠.

왜 이것이 들어가야 할까요? 외주를 자주 맡겨보지 않은 대부분의 클라이언트는 외주 진행 과정을 막막하게 여깁니다. 해본 적이 없으니까요. 어떤 단계에서 어떻게 소통해야 하고, 어떤 단계에서 결과물을 받아볼 수 있으며, 어떻게 피드백을 줄 수 있는지 잘 모르는 경우가 많습니다.

조금만 구글링 해 봐도 외주 실패 사례가 나오죠. 거기서 보면 '예상치 못한 결과물 받았어요', '다 된다고 하더니 연락이 안 돼요' 같은 이야기들이 나옵니다. 실제로는 많은 개발자들이 개발 과정에서 클라이언트와 충분히 소통하면서 결과물을 제공하지만, 경험이 없는 클라이언트들은 이런 이야기를 듣고 불안감을 갖습니다.

그래서 미팅에서는 클라이언트가 가지고 있는 불안 요소를 해소해 주어야 합니다. 그중 하나가 커뮤니케이션에 대한 불안감입니다. 이 불안감을 해소할 수 있는 것은 결국 우리가 대화를 잘할 수 있고, 클라이언트가 원하는 방향에 맞춰 계속 리스닝하며 그에 따라 결과물을 주겠다는 것을 보여주는 것입니다. 그래서 납품 과정, 작업 프로세스를 잘 소개하는 것이 굉장히 중요합니다.

4) 유사 포트폴리오 소개

유사 포트폴리오는 실제로 이 회사가 내가 의뢰하려는 서비스를 다뤄본 회사인지를 판단하는 요소입니다. 유사 포트폴리오들을 골라서 소개하는 작업은 무조건 필요합니다.

제일 좋은 것은 시연입니다. 이미지로 소개하는 것보다 프로토타입을 보여주는 것이 좋고, 프로토타입보다는 실제로 구동되고 있는 사이트를 보여주는 것이 제일 좋습니다. 클라이언트 입장에서 현실감이 들고, 이 사람과 작업했을 때 실제로 어떤 결과물이 나올 수 있을지를 가늠해볼 수 있기 때문입니다.

여기서 유의할 점이 있습니다. 유사하지 않은 포트폴리오를 소개하는 데 시간을 많이 쓰는 것은 좋지 않습니다. 유사하지 않은 것을 소개하느라 시간을 쓰면 클라이언트가 미팅에 지루함을 느끼는 것은 물론, 이 회사가 우리에게 중요한 것들을 잘 파악하지 못한다고 느끼는 경우도 많습니다.

따라서 모든 포트폴리오가 아니라 클라이언트가 자신의 상황과 유사하다고 느낄 수 있는 포트폴리오들만 골라서 소개하는 것이 낫습니다. 회사소개서는 미팅 끝나고 다시 보내줘도 되니까요. 핵심 유사 포트폴리오들만 선정해서 소개하는 작업이 필요합니다.

➡️위시켓에서 포트폴리오 둘러보기

회사 소개 시 유의사항
✅ 적정 시간은 5분
10분 넘어가면 클라이언트들은 길다고 느낍니다. 또 내용이 충분히 전달되는 것도 중요합니다. 간혹 정말 짧게 마무리하시는 경우들도 있는데, 물론 안 하는 것보다는 낫습니다. 하지만 무엇보다 준비한 자료를 통해 클라이언트의 흥미를 이끌어내고, 신뢰성을 높이는 작업을 하는 것이 중요합니다. 그러려면 적정 시간은 5분 정도이며, 2~3분 정도는 준비한 자료를 기반으로 이야기하는 것이 좋습니다.
✅ 미팅 참석자들 중 우리를 모르는 사람도 있다
회사 소개를 하는 자리는 우리를 잘 아는 사람들을 위한 자리가 아닙니다. 우리를 모르는 분들에게 우리가 전문가이고, 프로젝트를 잘 수행할 수 있는 요건을 갖췄다는 것을 보여주는 자리라고 생각하고 회사 소개를 하는 것이 가장 좋습니다.

성공적인 미팅 전략: 클라이언트의 불안감을 해소하라

미팅 첫 10분. 이제 회사 소개를 마쳤습니다. 이제 본격적으로 프로젝트에 대해 이야기하며 성공적인 계약으로 이끌어가야 하겠죠. 이를 위해서는 클라이언트의 ‘불안’을 해소해주는 것이 정말 중요합니다. 클라이언트가 무엇을 걱정하고 있고, 이로 인해 어떤 니즈를 가지고 있는지를 아는 것이 미팅에서 가장 중요한 승패 요인입니다.

많은 분들이 미팅에서 IT 전문가라는 어필을 하기 위해 개발 용어를 많이 섞어 사용하려 합니다. 하지만 단지 IT 지식이 많은 전문가가 아니라 클라이언트가 의뢰한 프로젝트를 끝까지 성공적으로 잘해낼 수 있는 상대라는 믿음을 주는 것이 더 중요합니다. 클라이언트들은 외주를 맡길 때 커뮤니케이션이 잘 안 될까봐, 그리고 개발을 너무 몰라서 사기를 당할까봐 혹은 이해하지 못할까봐 두려워하기 때문입니다. 이는 개발 지식이 있는 클라이언트들도 우려하는 부분이기도 합니다.

실제로 정말 잘하는 개발사들 중에는 미팅 자리에서 클라이언트가 이해하지 못하는 개발 용어들을 최대한 지양하는 사람들이 많습니다. 그렇다고 해서 클라이언트가 그 사람이 전문가가 아니라고 느끼는 것은 아닙니다. 오히려 더 신뢰하고 계약까지 하게 되죠. 클라이언트는 커뮤니케이션에서의 어려움, 개발에 대한 낮은 해상도를 가장 걱정하기 때문에, 이 두 가지를 해소해준다면 큰 신뢰를 얻을 수 있습니다.

결국 미팅은 클라이언트의 불안감을 해소해 신뢰할 수 있는 상대라는 이미지를 쌓아가는 과정인데요. 이를 위해 클라이언트에게 관심을 표현하는 것이 중요합니다.

성공적인 커뮤니케이션은 말을 잘하는 게 아니라 ‘관심을 표현하는 능력’이다

흔히들 말을 유려하게 잘하는 것을 커뮤니케이션을 잘하는 것이라고 생각합니다. 물론 말을 잘하고 의견을 잘 개진하는 것도 좋은 커뮤니케이션 능력입니다. 하지만 성공적인 커뮤니케이션에서 제일 중요한 첫 번째는 상대에게 관심을 표현하는 것입니다.

관심을 표현하는 것은 클라이언트가 프로젝트에 대해서 생각하지 못했던 요건들을 짚어주는 데서부터 출발합니다. 예를 들어 클라이언트가 쇼핑 입점몰을 만들고 싶다고 했을 때, 대부분의 파트너들이 클라이언트가 이야기하지 않았지만 자신은 알고 있는 것들에 대해 ‘당연히 이런 것은 생각 안 하겠지’, 또는 ‘당연히 이런 것들은 포함하겠지’ 하고 생각합니다. 하지만 이전 챕터에서도 이야기했듯 당연한 건 없습니다.

클라이언트가 말하지 않은 것이 있고 우리가 확인해야 할 게 있다면, "이러한 부분들은 필요하지 않을까요?", "이러한 부분들은 빼는 게 좋지 않을까요?" 하고 물어야 합니다. 그것이 관심의 표시입니다. 내가 이 프로젝트에 많은 관심을 쏟고 있으며, 프로젝트의 결과물이 잘 나오기를 바라고 있다는 것을 보여주는 것이죠. 이것이 가장 중요합니다.

그래서 "이러한 것도 필요하지 않으세요?", "이런 것들도 넣어보시면 어때요?" 같은 기능적인 부분, 정책적인 부분을 계속 많이 질문하는 것이 중요합니다. 이렇게 질문하는 파트너일수록 클라이언트는 ‘내가 모르는 영역까지 이야기해 줄 수 있는 파트너’, ‘이 프로젝트에 많은 관심을 가진 파트너’라고 생각합니다.

관심을 표하는 방법①: BM 모델이나 유지보수 방안을 묻고 제안하기

‘나는 관심이 있어’라고 생각해도 그것을 표현하지 않으면 상대는 모릅니다. 게다가 관심이란 눈에 보이지 않기 때문에 내가 관심이 있다고 표현하는 방법이 무엇인지 머릿속에 잘 그려지지 않을 수 있습니다. 그래서 클라이언트에게 관심을 보이는 구체적이고 대표적인 방법 두 가지를 소개하려 합니다.

개발자들이 여러 프로젝트를 하다 보면, 비슷한 서비스들이 어떻게 돈을 버는지, 유지 보수는 어떻게 해야 하는지에 관한 경험이 쌓일 것입니다. 그런데 이런 부분은 클라이언트도 똑같이 고민하는 부분입니다. 미팅에서 말을 하지 않을 뿐이죠. 클라이언트가 말을 하지 않더라도 이런 부분에 대해 먼저 물어본다면 클라이언트는 개발자가 프로젝트에 관심과 경험이 많다고 느낄 것입니다.

물론 비즈니스 모델이나 유지 보수 방안은 클라이언트가 생각하고 결정해야 할 부분이 맞습니다. 하지만 클라이언트가 고민하는 부분을 먼저 알아차리고 그에 대한 방안을 제안한다면 더욱 신뢰감을 줄 수 있습니다. 만약 이전에 비슷한 서비스를 만들어본 경험이 있다면 “이 서비스는 이런 방식으로 비즈니스 모델을 가지고 가면 좋습니다” 또는 "제가 해보니까 예전에 이런 유사한 서비스는 이런 비즈니스 모델을 가지고 있는 것 같더라고요"라고 가이드를 제공하는 것은 클라이언트에게 좋은 관심 표현이 됩니다.

유지 보수도 마찬가지입니다. 클라이언트가 언급하지 않더라도 개발자가 먼저 이 부분에 대해 이야기한다면, 역시 좋은 관심 표현이 됩니다. 위시켓에 프로젝트를 등록하는 클라이언트들 대분이 '추후 유지보수까지도 같이 진행할 수 있는 파트너를 원합니다'라는 항목을 선택합니다. 이는 대부분의 클라이언트가 처음에 의뢰했던 사람과 프로젝트를 잘 마치고, 그 사람이 계속 내 것을 잘 유지해 줬으면 좋겠다는 의사를 갖고 있기 때문입니다. 그래서 추후 유지보수가 진행되려면 기술 스택을 어떤 식으로 하면 좋을지, 어떤 식으로 시스템 설계를 구성하면 좋을지 제안하면 신뢰를 얻을 수 있습니다.

여기서 정말 한 발 더 들어가는 파트너들은 이렇게 말합니다.

"이런 식으로 유지보수 구성을 해 놓으시면 나중에 저희가 아니더라도, 다른 누군가가 개발을 하더라도 유지보수가 원활하실 겁니다."

클라이언트는 비즈니스 모델이나 유지 보수에 관한 고민을 미팅 자리에서 개발자와 나눠야 한다고 생각하지 못할 수 있습니다. 그런데 먼저 나서서 물어보고 제안을 더한다면 더욱 신뢰감을 높여 계약으로 이어질 수 있습니다.

관심을 표하는 방법②: 포트폴리오를 소개하며 스토리를 언급하기

클라이언트에게 관심을 표현하고 신뢰를 얻는 확실한 방법 중 하나는 나의 과거 경험을 근거로 제안하는 것입니다.

단순한 아이디어 제시는 누구나 할 수 있습니다. 하지만 "이전 프로젝트에서 지금과 똑같은 상황을 겪었는데, A 방식으로 해결하니 결과가 좋았습니다. 이 방식을 도입해 보시는 건 어떨까요?"라는 말은 무게가 다릅니다. 클라이언트는 이 말을 듣는 순간 상대가 '내 상황을 정확히 이해하고 있다'고 느끼며, 개발자의 제안을 단순한 '아이디어'가 아닌 '검증된 해결책'으로 받아들입니다. 기능이든 정책이든, 그 제안에 훨씬 큰 매력을 느낄 수밖에 없습니다.

이것이 곧 신뢰로 이어집니다. 항상 '내 경험에 비추어 볼 때'라는 구체적인 근거를 가지고, '이런 점을 고려해 보면 어떨까요?'라고 제안하는 것이 중요합니다.

관심을 표하는 방법③: 클라이언트의 개발 지식 수준에 맞춘 커뮤니케이션

여기에 한 가지 중요한 역량이 더 필요합니다. 바로 클라이언트의 개발 지식 수준에 맞춘 커뮤니케이션 능력입니다.

많은 클라이언트가 "지원자들의 이력서에 알 수 없는 개발 용어가 너무 많아 누구와 미팅해야 할지 모르겠다"고 토로합니다. 개발을 모르는 클라이언트에게 "저희는 이런 방법론을 적용할 것입니다" 또는 "이 작업은 분산 처리가 필요합니다"라고 말하는 것은, 그들에게는 '외계어'로 나의 능력을 설명하는 것과 같습니다.

미팅에서 클라이언트의 지식 수준을 빠르게 파악하고, 그 수준에 맞는 언어로 제안을 구성해야 합니다.

클라이언트가 개발 지식이 있다면, 기술적인 방법론을 제안하는 것이 효과적입니다.
클라이언트가 개발 지식이 없다면, 개발 용어를 완전히 배제하고 '기능적인 아이디어'나 '정책적인 아이디어'를 중심으로 역제안해야 합니다.

그래야 클라이언트는 비로소 "이 사람이 나에게 꼭 맞는, 이해할 수 있는 제안을 하고 있다"고 판단하고 당신을 신뢰하게 될 것입니다.

한끗을 더하는 고급 미팅 기술: 역제안

한발 더 들어가봅시다. 미팅에서 중요한 것은 이 프로젝트를 성공시킬 수 있는 나의 역량을 어필하는 것입니다. 단순히 업무 범위가 어디까지인지를 확인하는 자리가 아닙니다. 그렇다면 어떻게 내 역량을 효과적으로 어필할 수 있을까요? 아주 핵심적인 스킬이 있습니다. 바로 ‘역제안’입니다.

일반적인 파트너: "이 기능도 포함하실 건가요? 포함하면 견적이 오릅니다." (단순 과업 확인)
전문가 파트너: "클라이언트의 목적을 달성하려면, 이 기능은 이런 방식으로 바꾸는 것이 낫습니다." (능동적 역제안)

대부분의 파트너는 "어떤 기능을 만들어야 하나요?"를 확인하고 "저 이 기능 경험 많아요"라고 말하는 데 그칩니다.

하지만 진짜 전문가는 다릅니다. 이들은 단순히 '해야 할 과업'이 아니라 '클라이언트가 만들려는 결과물의 목적'을 파악합니다. 업무 범위를 아는 것은 기본입니다. 전문가는 클라이언트가 원하는 성공적인 결과물을 만들기 위해, "오히려 이렇게 만드시는 게 낫습니다" 또는 "이런 식으로 바꾸는 것을 고려해 보시죠"라며 적극적으로 역제안할 수 있어야 합니다.

많은 분들이 “과업은 클라이언트가 선정하는 것”이라는 생각에 클라이언트가 제안한 범위 안에서 수동적으로 과업을 협상하려고 합니다. 하지만 실제로 프로젝트를 성공적으로 이끄는 최고 수준의 개발자들은 과업을 스스로 '정의'하는 사람들입니다. 이들은 "성공을 위해 이런 것들까지 필요할 것 같습니다"라고 먼저 이야기합니다.

역제안을 너무 거창하게 생각할 필요는 없습니다. 미팅 자리에서 "더 좋은 결과물을 위해서는 이런 방식을 더하는 게 좋을 것 같다"는 아이디어를 던지는 것만으로도 충분합니다. 역제안을 할 수 있다는 것은 프로젝트를 잘 이해하고 있다는 것, 프로젝트에 큰 관심을 갖고 있다는 것을 보여줄 수 있는 아주 효과적인 방법입니다. 거기에 더해 프로젝트가 더 성공적인 방향으로 나아갈 수 있는 방법을 제안하는 것이기 때문에 잘 한 역제안은 클라이언트에게 큰 신뢰를 얻을 수 있습니다.

역제안 시나리오
클라이언트: 운동 기록을 관리할 수 있는 피트니스 앱을 개발하고 싶습니다. 운동 시간, 종류, 칼로리 소모량 정도를 기록하는 간단한 앱이면 됩니다.
파트너:"네 말씀하신 부분 충분히 가능합니다. 추가적으로 단순 기록보다는 운동 기록을 인스타그램과 같은 SNS에 쉽게 업로드할 수 있도록 하거나, 게시판 형태의 커뮤니티를 앱 내에 넣어보는 것은 어떨까요? 아무래도 요즘 운동 인증이나 러닝크루와 같이 혼자 운동하는 것보다는 이를 다른 사람들에게 공유하거나 소모임 형태로 진행하는 경우도 많아서요. 간단한 형태라면 공수도 크지 않을 것 같아서 사용자 유입 측면에서 도움이 될 수 있을 것 같습니다. 이런 기능들은 마케팅적으로도 활용해볼 수 있을 것 같습니다.

이런 건 절대로 하지 마세요!

지금까지는 해야 하는 행동을 알아봤는데요. 반대로 미팅에서 신뢰감을 잃을 수 있는 행동도 있습니다. 생각보다 많은 분들이 하고 계시는 일이라, 글을 마치기 전에 꼭 짚고 넘어가려 합니다.

방어적인 행동을 하지 마세요

미팅은 단순한 논의의 자리가 아니라, 사실상 계약 진행 여부가 결정되는 '판단의 순간'입니다. 클라이언트는 미팅 중에 "이 사람과 일해야겠다", "더 논의해 봐야지", "이 사람은 안 되겠다"를 결정합니다.

'안 되겠다'는 판단이 서는 가장 흔한 경우는, 파트너가 클라이언트의 모든 제안에 부정적이거나 방어적인 태도를 보일 때입니다.

"이거는 견적이 너무 높아져서 안 될 것 같은데요."
"이 정도까지는 사실상 저희가 R&D를 하는 거나 다름없어서요."
(심지어) "예산만 맞춰주시면 다 하죠."

물론, 과업 범위가 감당할 수 없을 만큼 커질까 봐 두려운 마음은 충분히 이해합니다. 하지만 이런 방어적인 태도는 클라이언트에게 '협상의 여지가 없는 사람'이라는 인상만 줍니다.

거절은 미팅이 끝난 후에 해도 늦지 않습니다. 미팅 중에는 모든 가능성을 열어두고 논의에 집중하시기를 권합니다. 정중한 거절은 추후 견적서를 보내는 단계에서 우회적으로 전달해도 충분합니다. 이 클라이언트와 단 한 번으로 끝낼 관계가 아니라면, 굳이 그 자리에서 방어적인 자세를 취해 '방어적인 결과'를 얻을 필요는 없습니다.

'무조건 다 된다'고 하지 마세요

방어적인 태도의 정반대편에도 흔히 하는 실수가 있습니다. 바로 '전부 다 가능하다'고 말하는 것입니다. 이는 주로 경험이 적은 초보 개발자나, IT 영업에만 오래 익숙해진 분들이 저지르는 실수입니다.

'다 된다'는 대답이 왜 안 좋을까요?

첫째, 클라이언트의 '질문'이 사라집니다. "A 기능도 가능한가요?"라는 질문에 "네, 다 됩니다"라고 답하면, 클라이언트는 더 이상 궁금한 것을 물어보지 않게 됩니다. 좋은 미팅이란 서로 질문을 주고받으며 프로젝트에 대한 상호 이해와 관심을 높여가는 자리인데, 그 흐름이 그 순간 끊겨버립니다.

둘째, 오히려 '신뢰'를 잃습니다. 파트너는 '경험 많고 의욕 넘친다'는 의도로 말한 것이지만, 요즘 클라이언트들은 그렇게 받아들이지 않습니다. 오히려 '디테일이 부족하구나' 혹은 '내 요구사항을 다 듣지도 않고 어떻게 다 된다고 하지?'라며 의구심을 갖게 됩니다.

따라서 '다 된다'고 답하는 대신, 다음과 같이 꼼꼼하게 역으로 이런 이야기를하며 경험을 어필하는 것이 훨씬 효과적입니다.

"그 부분은 현재 어느 수준까지 고려하고 계신가요?"
"저희가 충분히 경험은 있지만, 혹시 생각하시는 방향이 이런 쪽이 맞을까요?"
"이전에 유사한 프로젝트에서는 이런 방식으로 문제를 해결한 경험이 있습니다."

마무리: 미팅, 그 이상의 가치를 증명하는 과정

프리랜서 개발자로서 성공적인 프로젝트 수주를 결정하는 것은 미팅 테이블 위의 단 몇 시간에 달려 있습니다. 우리는 미팅을 통해 단순히 우리의 기술 능력을 '설명'하는 것을 넘어, 클라이언트의 비즈니스를 깊이 이해하고 성공으로 이끌 수 있는 '가치 있는 파트너'임을 증명해야 합니다.

성공률이 높은 개발자들이 보여주는 공통점은 결국, '작은 디테일'에서 차이가 난다는 점입니다.

클라이언트의 불안 요소를 먼저 파악하고 해소하려는 세심함.
IT 용어를 배제하고 상대방의 눈높이에 맞춰 대화하는 커뮤니케이션 능력.
단순히 주어진 과업을 수행하는 것을 넘어, 더 나은 결과를 위한 역제안을 제시하는 주도성.

미팅은 소개팅과 같습니다. 좋은 '느낌'으로 끝나는 만남이 아니라, 확신과 신뢰로 이어져야만 계약이라는 결실을 맺을 수 있습니다. 오늘 공유된 전략들을 통해 미팅을 단순한 논의의 자리가 아닌, 클라이언트가 "이 사람과 함께라면 우리 프로젝트가 성공하겠구나"라는 강력한 믿음을 얻는 '결정적인 순간'으로 만드시기를 바랍니다.