외주 클라이언트와 효율적으로 일하는 법

안전 컨설팅 기업이 홈페이지를 새로 만들고 싶다며 다른 회사의 홈페이지를 참고 사이트를 주셨습니다.

자빈스튜디오가 실제로 맡은 외주 1건의 첫 장면입니다. 이때 "그 사이트처럼"이 어디까지인지 정하지 않으면 범위와 일정이 나중에 흔들립니다. 일이 늦어지는 이유는 대개 개발 속도보다 서로 다르게 이해한 말에 있습니다.

저희가 찾은 클라이언트와 효율적으로 일하는 법은 열심히 맞춰주는 것이 아니라, 첫 미팅에서 기준을 날짜와 항목으로 적어두는 것입니다.

1. 첫 미팅에서는 무엇을 먼저 정하나요?

디자인보다 오픈일, 자료 전달일, 최종 승인자, 필수 페이지와 기능, 예산, 다음 일정을 먼저 정합니다. 45~60분 동안 일곱 가지 주제를 정해진 순서로 묻고, 마지막 5분은 합의사항을 다시 읽는 데 씁니다. 답이 정해지면 그 자리에서 기록하고, 날짜가 나온 항목은 마감일까지 바로 입력합니다.

킥오프 인터뷰 시트의 진행 순서

시간이 부족해도 여덟 가지는 반드시 확인합니다. 최종 오픈일, 고객 자료 전달일, 최종 승인자, 필수 페이지, 필수 기능, 레퍼런스에서 원하는 점, 예산과 결제, 다음 회의 또는 시안 전달일입니다.

미팅이 끝나기 전에는 날짜 다섯 개를 확정합니다. 고객 자료 전달 완료일, 1차 디자인 시안 전달일, 디자인 최종 승인일, 개발본 검수 시작일, 최종 오픈일입니다.

2. 일정은 왜 클라이언트 몫까지

개발보다 고객 자료 전달이 늦어져서 일정이 밀리는 경우가 많습니다.

시트에는 "오늘 자료 전달일을 같이 정하겠습니다"라는 말을 그대로 적어두었습니다. 로고, 회사소개서, 서비스 소개 문구, 현장 사진, 인증서, 수행 실적마다 담당자와 전달 가능일을 그 자리에서 받아야합니다.

일정이 밀릴 때의 기준도 미리 합의합니다. 고객 자료 제공이 늦어지면 납품일도 같이 조정하고, 승인된 뒤에 디자인을 바꾸면 일정을 다시 계산합니다. 고객 내부 결재가 늦어지는 것은 저희 작업 지연과 구분해서 기록합니다.

중요한것은 누구 탓인지 따지려는 것이 아니라, 일정이 왜 움직였는지 나중에 같이 볼 수 있게 하려는 것입니다.

3. 모호한 부분들을 다루는 방법

모호한 말은 그대로 받지 않고, 고를 수 있는 항목으로 쪼갭니다. 참고 사이트는 꼭 가져오고 싶은 부분 3개와 바꾸고 싶은 부분 3개를 함께 묻습니다. 메뉴 구조, 서비스 분류 방식, 회사 신뢰도를 보여주는 방식, 색상, 사진 스타일처럼 나눠서 고르게 하고, 정말 아니다 싶은 싫은 느낌도 묻습니다.

요즘IT에 실린 한 프리랜서 개발자의 글도 같은 이야기를 합니다. 클라이언트가 "사용자 간 연결을 더 편리하게"처럼 모호하게 말하면 위험 신호로 보고, 기능이나 화면을 구체적으로 되물으라고 조언합니다.

계약서에도 같은 원칙을 적습니다. "그 회사 사이트처럼"이라는 말은 참고 사항일 뿐

계약 범위가 아니고, 과업범위서에서 체크한 페이지와 기능만 기본 과업으로 확정합니다.

4. 클라이언트의 범위 밖 요청

합의한 범위 안의 구현 오류는 무상으로 고치고, 범위 밖의 요청은 일정과 비용을 확인한 뒤 추가 과업으로 진행합니다. 이 기준을 킥오프 때 고객에게 먼저 말하고 계약서에도 적어둡니다.

추가 요청을 처리하는 판단 순서

계약 당일에는 돈, 만들 것, 일정, 수정 범위, 도메인·서버 소유권, 콘텐츠 책임, 검수 기준, 오픈 후 운영 순서로 여덟 가지를 확정합니다. 과업범위서에는 기본 과업에 포함되지 않는 항목도 적습니다. 로고 신규 제작, 전문 사진 촬영, 다국어 번역, 쇼핑몰과 결제, 회원가입과 로그인, 외부 시스템 연동이 여기에 들어갑니다. 기본안에는 디자인 수정 2회와 검수 후 30일 무상 하자보수를 적어두고, 기본 SEO는 구축 단계의 기술 설정이며 검색 순위나 AI 답변 노출을 보장하지 않는다는 문구도 넣습니다.

시간과 예산, 범위를 모두 고정할 수는 없다는 생각은 저희만의 것이 아닙니다. 37signals(Basecamp)의 『Getting Real』은 출시일과 예산은 고정하고 범위를 줄여 맞추라고 말합니다.

5. 효율적인 의사결정이 서로에게 좋다

하지 않기로 한 결정도 날짜와 이유를 함께 남깁니다. 실제 예시로 저희가 맡은 프로젝트 2차 수정 요청에는 회사 정보와 자격, 장비 같은 상세 내용을 대표님이 직접 수정하게 해달라는 항목이 있었습니다. 저희는 관리자 편집 화면을 설계했지만 데이터 구조를 새로 만들어야 해서 개발량이 컸습니다.

2026년 10월 9일에 이 기능은 하지 않기로 결정했고, 회사 정보 같은 정적 콘텐츠는 개발팀이 직접 수정해 반영하기로 했습니다. 설계안은 나중을 위해 참고용으로 보관했습니다.

같은 요청이 다시 나왔을 때 처음부터 논의하지 않아도 되고, 고객도 왜 그렇게 정했는지 다시 볼 수 있습니다. 회사 이름 표기가 명함과 사이트에서 다르다는 지적도 사이트 표기를 유지하기로 하여 효율적인 의사결정으로 클라이언트와 개발진 모두에게 좋은 효과를 줍니다.

6. 고객(왕)에게 보고를

요청마다 상태와 담당, 규모를 표로 관리하고, 오픈 전에는 체크리스트 22개를 모두 확인한 뒤 고객의 "오픈 승인"을 받아야 배포합니다. 2차 수정 요청 9건은 4건 완료, 1건 진행 중, 2건 고객 자료 대기, 2건 취소로 정리됐습니다. 이런 현황은 고객이 언제든 볼 수 있어야 합니다. 요즘IT 글에는 보고가 없으면 클라이언트가 "어둠 속에 남겨진 느낌"을 받는다는 사례가 나옵니다.

2차 수정 요청의 처리 결과

몇 가지는 판단이 필요했습니다.

"공개가 두 개"라는 요청은 문장만으로는 어느 화면인지 알 수 없었습니다. 그래서 코드에서 후보를 찾고 통화에서 화면을 짚어달라고 요청했습니다. 코드로 중복은 확인해서 고쳤지만, 고객이 가리킨 곳이 정말 거기였는지는 확인 전이라고 기록해 두었습니다.

오픈 전에는 문의폼 실제 테스트, 문의 이메일 수신 테스트, 개인정보처리방침 반영, 대표 전화·이메일·주소 확인, 기존 홈페이지 백업을 봅니다. 가장 조심하는 것은 도메인 DNS입니다. DNS를 잘못 바꾸면 회사 이메일이 끊길 수 있어서, 바꾸기 전에 기존 메일 서비스와 MX·TXT·SPF·DKIM 레코드를 먼저 기록합니다.

7. 자빈스튜디오만의 분업 체계화

한 업무에는 최종 책임자를 한 명만 둡니다. 저희 4명은 제품과 고객은 CEO, 아키텍처와 개발은 CTO, 클라우드와 배포는 인프라 담당, 요구사항과 QA는 QA·기획 담당이 맡습니다. 요청이 들어왔을 때 누구에게 물어야 하는지가 분명해야 고객도 같은 질문에 다른 답을 듣지 않습니다. 회의를 끝내기 전에는 결정사항, 담당자, 마감일을 확정합니다.

해외에서는 thoughtbot이 디자이너와 개발자로 이뤄진 작은 팀이 클라이언트와 긴밀하게 협업한다고 소개하고, 방법론을 담은 플레이북을 공개해 둡니다. 규모가 작을수록 방식을 문서로 남겨두는 것이 일을 덜 흔들리게 한다는 점은 저희와 같습니다.

8. 자주 묻는 질문

Q. 첫 미팅에서 예산을 바로 물어보나요?

예산을 바로 묻기 어려우면 "어떤 기능까지 포함할지"를 먼저 정하고 범위를 설명합니다. 오픈 시 반드시 필요한 것, 가능하면 포함할 것, 2차 개발로 미룰 수 있는 것으로 나눠서 받습니다.

Q. 오픈 뒤 문구나 이미지 수정은 무상인가요?

구현 오류는 무상으로 고치지만, 문구와 이미지 교체는 범위에 따라 협의합니다. 킥오프 때 오픈 뒤 단순 수정을 누가 담당하는지 먼저 물어보고, 유지보수 방식을 월 계약과 건별 중에서 정합니다.

Q. 도메인과 서버는 누구 명의로 만드나요?

가능하면 고객사 명의로 운영하는 것을 원칙으로 합니다. 도메인, 서버, 분석 도구 계정을 누구 명의로 만들지는 계약 당일에 확정하는 항목입니다.

참고 자료

요즘IT, 외주 개발에서 클라이언트와 협업할 때의 커뮤니케이션 조언

37signals(Basecamp), Getting Real: Launch on time and on budget

thoughtbot, Small teams of designers and developers collaborating closely with clients