지난 [프리랜서 개발자 가이드 ③] 첫 미팅에서 피해야 할 프로젝트 찾는 법에서는 프로젝트의 안정성을 떨어뜨리는 '위험 신호'에 대해 알아봤습니다. 하지만 위험을 감지하고 피하는 것만큼이나 중요한 것이 애초에 위험이 발생하지 않도록'적극적으로 프로젝트를 분석하고 대비하는 것'입니다.

프로젝트 분쟁의 가장 큰 원인은 결국 클라이언트와 파트너 간의 '동기화 실패'입니다. 서로 과업의 난이도나 업무 범위를 다르게 생각하는 것이죠.

이번 편에서는 이 '동기화 수준'을 최대로 끌어올려 프로젝트의 안정성을 극적으로 높이는 미팅의 기술을 다룹니다. 주요한 프로젝트 변수들을 사전에 조율하는 미팅 방안에 대해 상세히 알아보겠습니다.

1. 미팅 전 필수 준비 사항

프로젝트의 안정성을 높이는 첫 단계는 '나는 이런 경험을 가진 전문가이며, 이 프로젝트를 이렇게 판단하고 있다'라는 나의 기준을 명확히 전달하는 것입니다. 이를 위해 다음 세 가지를 준비하는 것이 좋습니다.

① 포트폴리오 (또는 경력 기술서)와 래퍼런스

프로젝트를 진행할 때는, 내가 이 과업을 어느 수준까지 수행할 수 있는 역량을 갖추고 있는지 명확히 전달하는 것이 중요합니다. 이는 클라이언트가 프로젝트의 기대 수준을 설정하는 데 직접적인 영향을 미칩니다.

예를 들어, 내가 쇼핑몰을 100개 만들어 본 전문가임을 어필하고 '쿠폰 기능'을 넣었을 때 발생할 수 있는 견적 차이를 설명한다면, 이에 대한 신뢰도를 얻을 가능성이 높습니다. 반대로 프로젝트의 과업을 클라이언트의 기대치만큼 수행할 만한 근거가 부족하다면 자연스럽게 '다른 사람도 쿠폰 기능을 이렇게 어려워할까?'라고 의문을 가질 수밖에 없습니다.

결국 중요한 것은, 우리가 해당 분야에서 얼마나 전문적인 경험과 이해를 갖추고 있는지를 명확히 어필하는 일입니다. 이를 통해 미팅에 참여한 당사자들이 과업의 난이도와 수준을 객관적이고 일관된 기준으로 평가할 수 있는 신뢰의 기반을 마련할 수 있습니다.

② 예상 견적과 일정표

물론, 견적서나 WBS(Work Breakdown Structure, 작업 분해 일정표)를 미리 완벽히 준비하기는 쉽지 않습니다. 미팅 과정에서 논의되는 내용에 따라 세부 사항이 달라질 수 있기 때문입니다.

그러나 사전 미팅 단계에서부터 상세 견적서와 WBS를 준비해 가는 것은 프로젝트의 해상도(clarity)를 높이는 효과적인 방법입니다. 이는 앞서 <[프리랜서 개발자 가이드③] 프리랜서 개발자, 이런 계약 절대 하지 마세요!>에서 다룬 ‘낮은 견적’이나 ‘짧은 기간’으로 인한 리스크를 방어할 수 있는 가장 최고 수단이기도 합니다.

결국 핵심은 내가 이 과업의 난이도를 어느 정도로 판단하고 있는지, 그리고 그에 따라 어떤 비용과 시간이 필요한지를 명확하게 전달하는 일입니다. 이러한 과정을 통해서만 클라이언트와 현실적인 기대치를 조율하고, 프로젝트에 대한 생각을 동기화할 수 있습니다.

③ 프로젝트의 적합 기술

‘이 프로젝트를 어떤 기술 스택(Tech Stack)과 어떤 아키텍처(Architecture)로 구현할 것인가’에 대한 제안을 준비해야 합니다. 특히 개발 지식이 있거나 내부에 개발팀을 보유한 클라이언트의 경우, 실제 미팅에서 서로 상상하는 기술 방향이 다르게 드러나는 경우가 많습니다.

이 차이는 단순한 기술적 오해를 넘어, 프로젝트의 진행 방식과 이후 유지보수 전략에까지 영향을 미칩니다. 개발 이해도가 높은 클라이언트일수록 프로젝트 완료 후 인하우스(in-house, 내부 인력) 유지보수를 염두에 두는 경향이 강하기 때문입니다.

하지만 모든 기술적 요구를 클라이언트의 요청에 맞춰 수용하기는 어렵습니다. 자신이 다루지 못하는 기술을 새로 익히거나, 해당 기술을 다룰 수 있는 인력을 추가로 확보하는 것은 프로젝트 일정에 직접적인 지연을 초래하기 때문입니다.

따라서 프로젝트 초반부터 내가 생각하는 적합한 기술 스택, 즉 내가 숙련되어 있고 현실적으로 수행 가능한 기술을 중심으로 제안하고, 클라이언트와 명확히 동기화하는 것이 무엇보다 중요합니다.

2. 미팅에서 반드시 확인할 질문 리스트

① 프로젝트의 진행 목적

무엇을 만드느냐도 중요하지만 ‘왜’ 만드는지를 먼저 물어봐야 합니다. 제 경험상 생각보다 많은 개발자들이 이 질문을 하지 않습니다. 심지어 클라이언트도 먼저 이야기하지 않는 경우도 많습니다.

위시켓에서 다루는 분쟁 사례 중 가장 까다로운 부분 중 하나는 클라이언트의 '외주 목적'에 충족하지는 않으나 '완성된 결과물'은 있는 상태입니다. 클라이언트는 항상 어떠한 목적을 달성하기 위해 '외주'를 선택합니다. 비용적인 효율이든, 개발 지식의 부재든, 어떤 시점에서 얻는 사업적 수익이든 말이죠. 그렇다보니 클라이언트의 목적을 알지 못한 상태에서 시작한 프로젝트는 높은 확률로 분쟁을 겪습니다.

예를 들어, 클라이언트가 매일 수기로 반복 작업하던 일을 효율화하기 위해 프로젝트를 의뢰했습니다. 그리고 개발자는 클라이언트가 필요하다고 느끼는 기능을 만들었죠. 그런데 막상 완성된 결과물을 사용해보니 기존 업무 방식에 비해 시간은 70%밖에 줄지 않은 것입니다. 결국 개발자는 요구사항대로 다 개발해줬지만, 클라이언트는 원하는 결과물을 얻지 못한 상황이 됩니다. 이때부터 프로젝트의 성공 여부를 두고 치열한 논쟁이 시작됩니다.

실제로 위시켓은 아주 작은 변화 하나로 분쟁을 줄여냈습니다. 바로 이번 프로젝트를 통해 클라이언트가 달성하고자 하는 목표(프로젝트 의뢰 목적)을 더 많이 공고에 명시하고 계약서를 작성하는 과정에서도 리마인드 했습니다. 물론 계약서에도 명시했습니다. 상세한 데이터를 공유하긴 어렵지만 이를 통해 '프로젝트 이슈 발생 비율'과 '계약 해지 비율'을 긍정적으로 낮췄습니다.

결국 이 서비스의 목적을 무엇인지, 이 프로젝트를 통해 어떤 결과가 달성되어야 하는지, 그 결과가 달성되기 위해 어떤 결과물이 만들어져야하는지에 대해 서로 동기화 된다면 다른 모든 질문의 실마리를 찾을 수 있습니다.

② 핵심 화면/기능/프로세스의 '결과물 퀄리티'

매우 중요한 항목입니다. 단순히 어떤 기능이 필요한지 듣는 것을 넘어, '어느 수준(Level)'으로 구현되길 원하는지 물어봐야 합니다.

0% 수준의 결과물을 70%로 만드는 것보다 90% 수준의 결과물을 91%로 끌어올리는 것이 더 어려운 개발인 경우도 많습니다. 하지만 많은 클라이언트들은 막연히 91% 이상의 결과물 퀄리티를 기대합니다. '퀄리티'라는 추상적인 단어를 구체적인 질문으로 바꿔야 합니다.

속도: 핵심 기능의 반응 속도(ms)나 로딩 시간 목표치를 확인해야 합니다. (예: '틱톡' 같은 숏폼) "스크롤 시 다음 영상이 로딩되는 속도를 어느 정도로 기대하시나요?"
정확도: (예: AI, OCR) "신용카드 번호 인식 시 100번 중 몇 번 성공해야 하나요?"

특히 AI 챗봇을 GPT 같은 외부 솔루션으로 구현한다면, "이런 개발 방식은 결과물 퀄리티를 100% 통제하기 어려울 수 있습니다."라고 명확히 고지해야 합니다. 이는 '기술적 제약에 대한 근거' 및 '제약에 대한 사전 고지'로 분쟁을 해결할 수 있는 근거가 될 수 있을 뿐 아니라 결과물 수준의 동기화를 통해 분쟁 자체를 사전에 예방할 수 있는 좋은 방법입니다.

③ 납기와 중간 점검 일정

최종 납품 일정을 확인해야 합니다. 하지만 이때 '완료'의 기준이 무엇인지도 명확히 해야 합니다. 개발자는 '개발 완료' 시점, 클라이언트는 '검수 완료' 시점이라고 다르게 생각하는 경우가 많습니다.

또한, 정부 사업의 '중간 발표'처럼 프로젝트 중간의 핵심 D-day가 있는지도 모두 확인해야 합니다.

④ 예산 범위와 지급 일정

클라이언트가 가용 가능한 '예산 범위'를 물어보는 것이 좋습니다. 예산을 알아야 그 범위 안에서 가능한 과업을 역으로 제안할 수 있습니다.

또한, 대금 지급이 업무 종료 후 즉시 이뤄지는지, 혹은 클라이언트의 내부 프로세스로 인해 정해진 지급 방식이나 일정이 있는지도 확인해야 합니다.

⑤ 요구사항 관련 준비된 자료가 있는지?

요구사항이 불분명한 것은 언제나 가장 큰 리스크입니다. 클라이언트가 준비한 기획서, 래퍼런스 등의 자료가 있는지 꼭 체크해야 합니다. 만약 자료가 없다면 만들어 달라고 요청해도 괜찮습니다. 만약 서면으로 만들어진 자료가 존재하지 않는다면, 1부에서 말한 '불분명한 요구사항' 위험 신호일 수 있습니다.

⑥ 주요 커뮤니케이션 방식 및 의사결정 속도

내가 선호하는 방식(예: 슬랙, 카톡)을 먼저 제안하고, 클라이언트가 선호하는 방식을 확인합니다. 소통 스타일이 맞지 않으면 프로젝트 진행 속도에 영향을 줍니다.

가장 중요한 것은 '의사결정 속도'입니다. "기획안 1차본을 드리면, 검토와 승인(컨펌)까지 며칠 정도 소요될까요?" 이 '클라이언트의 의사결정 시간'을 반드시 전체 프로젝트 일정에 포함해야 합니다.

⑦ 개발적 요구 사항

클라이언트 측에 개발자가 있거나 기술적 요구가 명확할 때 반드시 확인해야 합니다.

환경: 특정 개발 언어, 서버 환경을 요구하는지 확인해야 합니다.
보안 (폐쇄망): 금융권처럼 '폐쇄망' 작업 환경인지 확인해야 합니다. 이에 따라 작업 장소(예: 파트너 사무실)나 납품 방식(예: 클라이언트사 방문 납품)이 달라질 수 있습니다.
가이드: '소스 코드 스타일 가이드'나 '품질 가이드'가 있는지 확인해야 합니다. 이게 없으면 다 만들어 놓고 "코드가 엉망이라 돈을 못 주겠다"는 말을 들을 수 있습니다.
산출물: 개발자가 가장 부담스러워하는 '문서 작업' 범위를 확인해야 합니다. ERD(데이터베이스 관계도), API 명세서, 테이블 정의서, 관리자 매뉴얼 등 어떤 문서를 어디까지 원하는지 사전에 알아야 견적에 반영할 수 있습니다.

3. [Tip] 산업별 특수 체크리스트

AI 프로젝트

데이터 보유량: 클라이언트가 학습시킬 데이터를 얼마나 보유하고 있는지 반드시 확인해야 합니다. 많은 파트너가 이걸 놓칩니다.
데이터 수집/가공: 데이터 수집이나 정제(라벨링 등) 작업도 파트너의 과업 범위에 포함되는지 확인해야 합니다.
정확도: AI 모델의 '정확도' 목표 수준을 확인해야 합니다. (예: 100회 중 95회 성공)

정부 지원 사업

중간 발표: 자금 집행 마감일 외에, '중간 발표' 일정이 언제인지 확인해야 합니다. 이것이 사실상 더 중요한 D-day일 수 있습니다.
문서 작업: 개발 외에, 지원 사업 관련 보고서나 문서 작업이 과업에 포함되는지 확인해야 합니다. 나중에 갑자기 요청하면 당황스러울 수 있습니다.

마치며

두 편의 가이드를 통해 성공적인 프리랜서 프로젝트를 위해 '피해야 할 위험 신호'와 '반드시 챙겨야 할 확인 사항'을 모두 짚어보았습니다.

성공적인 프리랜서 프로젝트는 단순히 코딩을 잘하는 것만으로 완성되지 않습니다. 그것은 '기대 수준을 맞추는 것'이자 '리스크를 관리'하는 영역입니다.

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

이런 철저한 준비 과정은 여러분을 단순한 '개발 용역'이 아닌, 클라이언트가 신뢰할 수 있는 '전문 파트너'로 만들어줄 것입니다. 그리고 이 신뢰가 곧 프로젝트를 안정적인 성공으로 이끄는 가장 튼튼한 기반이 될 것입니다.