잘 아시다시피, IT 아웃소싱 산업은 경쟁이 매우 치열한 필드입니다. 이미 레거시를 쌓아놓은 SI 대기업부터, 탄탄한 포트폴리오와 전통을 자랑하는 중형 SI, 그리고 속도감과 민첩함으로 무장한 소형 SI와 프리랜서들까지 매우 다양한 사람들이 경쟁에 참여하고 있죠. 그 중에는 여기, 첫 클라이언트 프로젝트를 맡게 된 의욕 넘치는 김 주임도 있습니다. 김 주임은 자신이 맡은 첫 외주 프로젝트를 꼭 성공시키고 싶었고, 클라이언트와 대화에서 김 주임은 환한 미소와 함께 이런 식으로 말했습니다.

• “네, 그럼요! 당연히 가능합니다!”

• “와, 좋은 아이디어네요! 그렇게 하겠습니다!”

• “네, 알겠습니다! 저희만 믿어주세요!”

클라이언트는 김 주임이 마음에 쏙 드는 눈치였습니다. 모든 요구를 다 받아주는 싹싹한 사람이 앞에 있으니, 함께 일하기 참 편하겠다고 생각했을지도 모르죠. 김 주임 역시 ‘다행히 순조롭게 미팅을 시작할 수 있겠어!’라고 생각하며 뿌듯해했습니다.

하지만 프로젝트가 본격적으로 시작되자, 이 완벽해 보였던 파트너십은 서서히 비극으로 치닫기 시작했습니다.

• (월요일 오전, 카카오톡) “김 주임님, 주말에 생각해보니 메인 화면 디자인이 좀 올드한 것 같아요. 참고 이미지 보내드리니 이런 느낌으로 싹 바꿔주세요.”

• (화요일 오후, 이메일) “실무자입니다. 어제 대표님께서 보시고는 로고 위치를 다시 오른쪽으로 옮기는 게 좋겠다고 하시네요. 확인 부탁드려요.”

• (수요일 저녁, 전화) “아, 김 주임님. 이왕 하는 김에 로그인 페이지에 지금 보내드리는 저희 회사 소개 영상도 하나 넣어주실 수 있을까요? 간단한 거 같은데…”

김 주임의 하루는 온갖 채널에서 쏟아지는 요청사항을 처리하느라 정신이 없었습니다. 실무자 말을 듣고 수정하면 대표가 나타나 뒤집었고, 간단하다던 요청은 개발팀 전체를 흔들었습니다. 결국 김 주임은 클라이언트와 개발팀 사이에 끼어 매일 야근했고, 프로젝트는 처음의 방향을 잃고 산으로 가기 시작했죠.

“클라이언트가 하자는 대로 다 해줬으니, 개발팀이 힘들어하는 건 이해해. 그런데 왜 클라이언트도 만족하지 못할까?”

혹시 이 이야기, 남 일 같지 않게 들리시나요? 괜찮습니다. 수많은 주니어 기획자들이 착한 기획자라는 덫에 빠져 비슷한 눈물을 흘리곤 하니까요. 오늘, 이 악순환을 끊어내고 클라이언트에게 진짜 신뢰를 얻는 프로의 시스템에 대해 이야기해 보려고 합니다.

1. 프로젝트의 규칙을 만드는 시간, 킥오프 미팅

수많은 프로젝트의 비극은 보통 첫 단추를 잘못 끼워서 시작됩니다. 많은 주니어 기획자들이 프로젝트 킥오프 미팅을 그저 서로 얼굴 트고 인사하는 자리 정도로 생각하더라고요. 하지만 킥오프 미팅의 진짜 목적은, 앞으로 몇 달간 함께 항해할 우리 배의 규칙을 만드는 가장 중요한 시간입니다.

“저희는 이 프로젝트를 성공시키고 싶은 프로들이고, 그러기 위해선 우리 사이에 명확한 약속이 필요합니다.”

저희는 보통 킥오프 미팅에서 이런 식으로 말을 하고, 반드시 규칙 3대 조항을 합의하고 넘어갑니다. 이 조항들을 소개하고자 합니다.

제1조 (의사결정권자 확인): "누가 최종 컨펌을 주시나요?"

가장 먼저 할 일은 우리에게 땅땅땅 최종 결정을 내려줄 사람이 누구인지 명확히 하는 겁니다. 실무자, 팀장, 대표 등 여러 사람이 각자의 의견을 낼 수 있지만, 그 의견들이 충돌할 때 누구의 손을 들어줘야 할지 모른다면 프로젝트는 표류하게 되죠.

“저희에게 의견을 주시는 통로가 여러 개라면 문제가 생길 수도 있습니다. 예를 들어 실무자님과 대표님의 의견이 다를 경우를 대비해, 저희가 어떤 분의 의견을 최종으로 따라야 할지 미리 정해두면 혼란을 막고 더 빠르게 움직일 수 있습니다. 이 프로젝트의 최종 의사결정권자는 누구로 지정하면 될까요?”

이렇게 정중하지만 명확하게 물어보는 것만으로도, 나중에 “왜 A님 말 듣고 이렇게 진행했어요? 대표님 생각은 다른데?”라는 비난을 피할 수 있습니다.

제2조 (소통 규칙 확립): "어떻게 대화할까요?"

두 번째는 소통의 규칙을 정하는 겁니다. 채널, 주기, 데드라인을 명확히 해야 하죠.

• 소통 채널: “모든 요청사항은 누락 방지를 위해 슬랙(혹은 지정된 툴) 채널에 남겨주세요. 카톡이나 구두 요청은 저희가 놓칠 수 있습니다.”

• 피드백 데드라인: “이번 주 수요일까지 디자인 시안에 대한 피드백을 주시면, 금요일까지 수정본을 전달드릴 수 있습니다. 만약 피드백이 늦어지면 전체 프로젝트 일정도 함께 지연될 수 있다는 점 미리 양해 부탁드립니다.”

조금은 딱딱하게 느껴질 수 있지만, 이런 규칙이 결국 서로의 시간을 아껴주고 프로젝트가 늘어지는 것을 막아주는 가장 확실한 안전장치가 됩니다.

제3조 (정기 미팅 확립): "우리, 매주 수요일 2시에 만나요."

마지막으로 정기적인 만남을 약속하세요. 이슈가 있을 때만 비정기적으로 만나는 것이 아니라, 매주 정해진 시간에 진행 상황과 이슈를 공유하는 거죠. 이렇게 하면 자잘한 문제들을 쌓아뒀다가 나중에 큰 폭탄으로 터뜨리는 일을 막을 수 있습니다.

2. 모호함과의 전쟁에서 승리하는 법: 문서로 대화하세요

자, 이제 프로젝트의 기본 규칙을 세웠습니다. 그다음 단계는 모든 과정을 기록으로 남겨 모호함이 끼어들 틈을 없애는 것입니다. 클라이언트의 머릿속에 있는 두루뭉술한 아이디어를 구체적인 문서로 번역하는 과정이죠.

저는 기획서를 ‘클라이언트를 위한 제품 설명서’이자, ‘우리 팀을 위한 설계도’라고 생각해요. 이 두 가지 역할을 제대로 해내기 위해, 특히 기능 명세서는 집요할 정도로 상세하게 작성해야 합니다.

로그인 기능 하나를 기획한다고 해볼까요?

[Before] 나쁜 기획서의 예:

• 소셜 로그인 기능을 추가한다.

[After] 당신과 팀을 구원할 좋은 기획서의 예:

• 기능명: 소셜 로그인 (카카오, 네이버)

• 기본 정책:

  • 사용자는 카카오, 네이버 계정을 통해 신규 회원가입 및 로그인을 할 수 있다.

  • 최초 소셜 로그인 시, 서비스 이용약관 및 개인정보처리방침 동의 절차를 거친다.

• 예외 처리 1 (계정 중복 케이스):

  • 이미 동일한 이메일로 가입된 회원이 해당 소셜 로그인을 시도할 경우, "이미 가입된 이메일입니다. 기존 계정과 연동하시겠습니까?" 라는 안내 팝업을 노출한다.

• 예외 처리 2 (API 에러 케이스):

  • 소셜 로그인 API 호출 실패 시, "일시적인 오류가 발생했습니다. 잠시 후 다시 시도해주세요." 라는 토스트 메시지를 노출한다.

• UI/UX 정책:

  • 버튼 디자인은 시스템 디자인 가이드의 Primary Button-L 타입을 따른다.

  • 버튼 내 문구는 각각 "카카오로 시작하기", "네이버로 시작하기"로 한다.

어떤가요? 차이가 느껴지시나요? 이렇게 상세한 명세서는 다음과 같은 엄청난 힘을 발휘합니다.

• (클라이언트에게) “내가 돈 주고 만드는 기능이 이렇게 세세한 부분까지 고려되어 동작하는구나”를 명확히 인지시켜, 나중에 “생각했던 거랑 다른데요?”라는 말을 차단합니다.

• (디자이너/개발자에게) “이럴 땐 어떻게 처리해요?”라고 기획자에게 다시 물어보는 시간을 대폭 줄여주고, 잘못 만들어서 다시 뜯어고치는 재작업(Rework) 비용을 막아줍니다.

• (기획자 본인에게) 모든 작업의 명확한 근거가 되어, 클라이언트의 변덕이나 팀 내부의 혼란으로부터 스스로를 보호하는 가장 강력한 무기가 됩니다.

마무리: ‘좋은 파트너’는 ‘착한 사람’이 아닙니다

클라이언트와 성공적으로 일하는 것은 그들의 모든 말에 무조건 "Yes"를 외치는 것이 아닙니다. 오히려 프로젝트 초반에 명확한 규칙을 함께 세우고, 진행 과정에서 문서라는 투명한 언어로 소통하며 프로젝트를 올바른 방향으로 이끄는 것이죠.

이러한 과정이 처음에는 클라이언트를 귀찮게 하는 것처럼 보일 수 있습니다. 하지만 결국에는 프로젝트의 수많은 리스크를 줄이고 성공 확률을 높여주는 프로의 일처리이며, 이것이야말로 클라이언트에게 진짜 신뢰를 주는 가장 확실한 방법입니다.

착한 사람이 아닌, 함께 일하고 싶은 든든한 파트너로 거듭날 당신을 위해 지금 당장 실천해 볼 수 있는 3가지 액션 아이템을 제안합니다.

1. '우리 팀만의 킥오프 미팅 체크리스트' 만들기: 오늘 소개한 3가지 조항을 포함하여, 프로젝트 시작 전 클라이언트와 꼭 합의해야 할 것들을 팀원들과 함께 정리하고 다음 프로젝트부터 바로 사용해보세요.

2. 가장 간단한 기능 명세서부터 상세하게 써보기: 지금 맡은 프로젝트의 아무 조그마한 기능이라도 좋습니다. 노출 조건, 닫기 버튼 정책, 어뷰징 방지 정책 등 예외 케이스까지 꼼꼼하게 작성하는 연습을 해보세요.

3. 회의록은 무조건 24시간 내 공유하기: 클라이언트와 미팅 후, 결정된 사항(Decision)과 다음 할 일(Action Item)을 정리하여 반드시 24시간 내에 공유하고 "제가 이해한 내용이 맞을까요?"라고 확인받는 습관을 들이세요. 이메일 한 통이 나중에 당신을 구할 겁니다.