고객·클라이언트와의 관계
고객·클라이언트와 오래 가는 비결: 말보다 “예측 가능성”
동료와 협력하고 경계 세우는 얘기(지난 편)까지 했으니, 이제 사무실 문을 살짝 열고 바깥으로 나가보자. 바로 고객·클라이언트 관계. 솔직히 말하면, 여기서의 신뢰는 코드 품질 하나로 끝나지 않는다. 일정, 소통, 책임, 그리고 “말한 대로 되는 경험”까지. 나도 개발자 출신이라 “결과물이 좋으면 다 됐지!”라고 생각하던 때가 있었는데… 어? 현실은 다르더라. 예측 가능성이야말로 최고의 서비스다.
한 줄 요약: 고객은 “감동”보다 “예측”을 좋아한다. 놀라게 하지 말고, 놀라기 전에 알려주자.
신뢰의 4요소: CARE 프레임
아! 거창한 건 아니고, 내가 프로젝트할 때 스스로 마음속에서 돌리는 체크리스트다. 이름도 나름 귀엽게 CARE.
- Clarity: 목적, 범위, 역할, 일정, 기준을 또렷하게
- Accountability: 책임 주체와 승인권자를 명확히
- Respect: 상대의 시간과 맥락을 존중(긴 메일 대신 요약, 회의는 시간 엄수)
- Empathy: 불편의 감정부터 인정하고 대응(“그럴 수밖에 없었죠”가 아니라 “불편하셨죠, 제가 이렇게 보완하겠습니다”)
킥오프에서 합의해야 할 7가지(놓치면 100% 후회)
처음부터 잘 깔면 절반은 이긴다. 나는 킥오프에서 이 7가지를 꼭 합의한다. 문서로!
- 목표와 성공 기준: “무엇을 하면 끝난 걸로 볼까?”
- 역할과 책임: 우리팀/당신팀, 승인권자 1명 지정
- 일정과 마일스톤: 중간 검토일을 달력에 고정
- 소통 채널과 빈도: 주간 리포트 요일·형식 합의
- 변경관리(스코프 크립 방지): 변경요청 절차를 미리 합의
- 리스크/에스컬레이션: 문제 생기면 누구에게, 언제까지 알릴지
- 산출물 형식: 문서/코드/디자인의 “최종본” 기준 정의
내가 쓰는 작은 요령 하나.
- 3-3-3: 메일·메시지는 3줄 요약, 3가지 선택안, 3단계 다음 행동.
예시:
- 요약: “A기능은 일정상 이번 배포에 어렵습니다.”
- 선택안: “1) 마감 연기 2) 기능 축소 3) 별도 과금으로 추가 리소스 투입”
- 다음 행동: “내일까지 선택 주시면, 일정표 업데이트하고 공유드릴게요.”
스코프 크립? 미리 ‘문장’을 준비해두자
솔직히 고객 입장에서는 “이거 조금만 더”가 죄는 아니잖아. 문제는 우리의 체력과 일정. 그래서 나는 문장을 미리 만들어 둔다. 부드럽지만 선명하게.
- “좋은 아이디어예요! 다만 현재 범위에서는 포함되지 않아 두 가지 옵션이 있어요. 1) 이번 범위 안에서 대체 방안을 찾기 2) 변경요청으로 별도 견적 드리기. 어떤 쪽이 좋으세요?”
- “이건 기존 설계에 영향을 줘서 품질·일정 리스크가 큽니다. 안전하게 가려면 변경요청으로 관리하는 게 좋아요.”
- “작업 시간은 12~16시간 정도 예상돼요. 승인 주시면 오늘부터 착수할게요.”
그리고 형태는 이렇게 쓴다:
- 계약서 또는 SOW(작업지시서): 범위·산출물·일정·검수 기준
- 변경요청서(개정 SOW): 변경 내용·추가 비용·일정 영향·승인자 서명
- 커뮤니케이션 규칙: 요청은 티켓으로, 구두 요청은 반드시 기록으로 남기기
팁: “무료”는 습관이 된다. 대신 “한 번은 서비스로, 다음부터는 변경요청으로 진행”을 명확히 선언하자.
힘든 상황도 스킬로 풀 수 있다
- 감정보다 사실: “어제 18시 배포 실패(사실) → 서비스 응답지연 12분(영향) → 오늘 10시에 롤백, 14시에 재배포(계획).”
- 사과와 보상: “불편을 드려 죄송합니다. 이번달 유지보수 10% 크레딧로 보상 드리겠습니다.”
- 헤드룸 확보: 일정은 내부적으로 10~20% 버퍼. 고객에게는 너무 타이트하게 약속하지 않기.
- 레드 플래그 대처: 밤 11시 이후 반복 호출, 승인권자 없음, 요구만 있고 책임 없음 → “운영 창구/시간을 재합의” 하자. 안 되면 용기 내어 손절도 전략이다.
보고는 짧게, 하지만 누락 없이
주간 리포트, 이렇게 보낸다. 5분이면 쓰고, 30분의 오해를 막는다.
[주간 요약 – 2/3]
1) 완료: 결제 모듈 리팩토링, QA 15건 중 14건 해결
2) 진행: 관리자 대시보드(60%), 성능 튜닝(예상 +2일)
3) 리스크: 외부 API 지연으로 실시간 알림 지연(대안: 배치 전환)
4) 의사결정 필요: 대시보드 필터 요구사항 확정(옵션 A/B/C)
5) 다음 주 계획: 스테이징 배포(수), UAT 회의(목 14시)
회의록은 “결정/담당/기한”만 굵게.
- 결정: 결제 취소 플로우는 A안 유지
- 담당: 우리팀(로그 추적), 고객팀(정책 문구)
- 기한: 금요일 18시
실패담 하나: “그냥 이 정도야”의 참사
예전에 “그냥 금방 되겠지”하고 구두로 OK했다가, 그 ‘조금’이 3주 야근이 된 적이 있다. 고객도 미안해했고, 나는 더 미안했다. 배운 점은:
- “좋아요”보다 “정리해서 보내드릴게요”
- 구두 OK는 24시간 내 문서화
- 변경은 다 문서로(비용·일정·영향 포함)
- 승인권자 1인 룰(여럿의 말은 법이 아니다)
- 릴리즈 전 “스모크 테스트 시트” 한 장이라도 만들기
유머 섞자면… 그때 커피가 날 살렸고, 이후엔 템플릿이 날 살렸다.
장기 관계를 만드는 작은 습관
- 첫 응답 SLA: 업무시간 2시간 내 “접수”만이라도
- 미리 알림: 일정 변동은 생기기 전에 알리기(“지연될 것 같다”가 아니라 “지연될 수도 있다” 수준에서)
- 미니 교육: 배포/로그 보는 법 짧은 동영상 5분짜리 공유 → 문의 절반 감소
- 포스트모템: 문제 후 1장짜리 회고(원인-대책-재발방지) 공유
- 오프보딩도 경험: 프로젝트 종료 때, 산출물 목록/계정/백업/운영 가이드 정리
- 레퍼런스·추천: “런칭 2주 후 만족도 확인 → 만족 시 레퍼런스 요청” 타이밍 잡기
고객이 “조직”이라는 사실 기억하기
여기서 다음 화(조직문화 읽기)로 자연스럽게 이어지는데, 고객은 한 명이 아니다. 회사다. 그러니 결정은 문화의 산물이다. 잠깐만 미리 맛보기.
- 단일 의사결정형: 승인권자 1명, 속도 빠름 → 주간 한 번 터치포인트로 충분
- 합의 지향형: 여러 팀 조율 → 회의록 꼼꼼, 시안은 항상 2~3안
- 위험회피형: 레퍼런스·사례·벤치마크가 설득 포인트
- 데이터 중시형: 수치와 로그가 곧 언어. 대시보드를 먼저 만든다
- 관계 중시형: 인사와 맥락 설명이 설계만큼 중요
다음 편에서는 이 “조직문화의 언어”를 읽고, 거기에 맞춰 커뮤니케이션을 튜닝하는 법을 더 깊게(아, 너무 딱딱하진 않게!) 풀어볼게.
마지막으로, 바로 써먹는 문장 모음
- 기대치 설정: “이번 주는 데모에 집중하고, 성능은 다음 주 최적화로 가져갈게요.”
- 일정 지연 알림: “예상치 못한 이슈로 1~2일 지연될 수 있어요. A안(범위 축소)과 B안(일정 연장) 중 어떤 게 나을까요?”
- 비용 안내: “이 변경은 10~12시간 추가가 예상되고, 견적은 120~150 사이로 나옵니다.”
- 갈등 진화: “불편하셨죠. 바로 사과드립니다. 지금 가능한 보상은 두 가지예요. 크레딧 제공 또는 무상 긴급 대응 4시간, 어떤 걸 선호하세요?”
- 마무리: “오늘 합의한 사항을 정리해 메일로 공유하고, 승인 후 바로 진행하겠습니다.”
끝으로, 고객과의 관계는 결국 “사람 대 사람”이더라. 기술은 수단이고, 신뢰는 과정이다. 솔직히 말하면 완벽한 정답은 없어. 대신 상황별로 최선의 합의와 예측 가능한 실행이 있을 뿐. 우리, 그걸 꾸준히 해보자. 다음 편에서는 “그 사람들(고객·조직)”이 어떤 문화에서 어떤 결정을 하는지, 그 흐름을 읽는 팁을 들고 올게!
