개발자가 고객사와 직접 미팅했을 때 당황한 순간들

개발자 현직자 솔직 경험담

개발자가 고객사와
직접 미팅했을 때 당황한 순간들

"그거 그냥 버튼 하나 추가하는 거 아니에요?"라는 질문에 얼어붙었던 첫 미팅.

3년 차쯤, 팀 규모가 작아서 PM 없이 개발자가 직접 고객사 미팅에 들어가야 했던 적이 있다. 그날 고객사 담당자가 던진 질문 하나에 완전히 얼어붙었다. "그거 그냥 버튼 하나 추가하는 거 아니에요? 왜 2주나 걸려요?" 기술적으로는 백 번이고 설명할 수 있었는데, 그 순간 머릿속이 하얘졌다. 그날의 당황스러움부터 이후 조금씩 나아진 과정까지 정리해봤다.

개발자가 고객사와 직접 미팅했을 때 당황한 순간들

4회고객사 미팅 직접 참여 횟수

3번답변 못 하고 당황한 순간

6개월미팅 대응력이 나아지기까지

1. 당황했던 순간들 — 실제로 겪은 세 가지

돌아보면 당황했던 순간들에는 공통점이 있었다. 기술적으로는 맞는 말인데, 고객 입장에서 이해할 수 있게 풀어내지 못했다는 것이다.

1

"버튼 하나인데 왜 2주씩이나"

API 연동, 권한 처리, 예외 케이스까지 포함된 작업이었지만, 화면에 보이는 건 버튼 하나였다. "화면에 보이는 것"과 "실제 작업량"의 괴리를 설명하지 못했다.

2

"경쟁사는 이거 다 되던데요"

경쟁 서비스와 비교하며 압박하는 질문에, 기술적 난이도 차이를 설명하려다 오히려 변명처럼 들려서 분위기가 더 안 좋아졌다.

3

"그럼 언제까지 되는 거예요?" (즉답 요구)

정확한 일정을 계산 못 한 상태에서 압박에 못 이겨 즉흥적으로 날짜를 던졌다가, 나중에 못 지켜서 신뢰를 잃은 적이 있었다.

⚠ 그때 느낀 것 기술적으로 옳은 설명과 고객이 납득할 수 있는 설명은 완전히 다른 것이었다. "왜 오래 걸리는지"를 기술 용어로 나열하는 건 오히려 신뢰를 떨어뜨렸다.

2. 첫 번째 실수 — 기술 용어로 방어하려 했다

"버튼 하나인데 왜 2주"라는 질문을 받았을 때, 나는 당황해서 이렇게 답했다.

고객사 담당자 그거 그냥 버튼 하나 추가하는 거 아니에요? 왜 2주나 걸려요?

나 아, 그게... API 스펙 변경이 필요하고, 권한 체크 로직도 새로 추가해야 하고, 기존 데이터 마이그레이션도 고려해야 해서요...

고객사 담당자 (표정이 굳어지며) 음... 잘 이해가 안 되는데, 그래서 결론이 뭔가요?

이 대화가 끝나고 나서야 내가 "왜 어려운지"를 나열했을 뿐, "그래서 무엇을, 언제까지 해드릴 수 있는지"를 말하지 않았다는 걸 깨달았다. 고객이 듣고 싶었던 건 기술적 이유가 아니라 명확한 결론이었다.

그때의 답변 방식

기술 용어 나열

API, 마이그레이션 등 이유부터 설명

이후 바꾼 방식

결론 먼저, 근거는 요약해서

"2주 안에 가능합니다, 이유는 세 가지입니다" 순서로 전환

3. 변화의 계기 — PM 역할을 잠깐 겸했던 시기

같은 프로젝트에서 PM이 잠깐 공백이 생겨, 어쩔 수 없이 몇 달간 고객 커뮤니케이션까지 직접 맡게 됐다. 처음엔 부담스러웠지만, 오히려 이 시기에 커뮤니케이션 방식을 크게 바꿀 수 있었다.

// 미팅 전 준비하는 방식이 바뀜 const prepareForMeeting = (request) => { return { conclusion: "가능 여부와 예상 소요 기간을 한 문장으로", reason: "기술적 이유는 최대 2가지로 압축", alternative: "어렵다면 대안이나 축소안을 미리 준비", }; }; // Before: 질문 받고 즉석에서 설명 시도 // After: 미팅 전 예상 질문 3개를 뽑아 답변을 미리 준비

가장 크게 바뀐 습관은 미팅 전에 예상 질문을 미리 뽑아보는 것이었다. "왜 오래 걸리나요", "다른 곳은 되던데요" 같은 질문은 사실 매번 비슷하게 반복됐다. 미리 답변을 준비해두니 실제 미팅에서 당황하는 일이 크게 줄었다.

1번째 미팅

기술 용어로 설명하다 고객 표정이 굳어짐. 처음 겪는 당황스러움.

2번째 미팅

경쟁사 비교 질문에 방어적으로 대응하다 분위기 악화. 이후 원인 분석 시작.

3번째 미팅

결론 먼저 말하는 방식으로 시도. 반응이 눈에 띄게 좋아짐을 체감.

4번째 미팅

예상 질문 미리 준비 후 참석. 즉흥적으로 날짜를 약속하는 실수 없이 안정적으로 진행.

4. 지금은 오히려 미팅이 두렵지 않다

여러 번의 시행착오를 겪고 나서, 이제는 고객 미팅에 들어가는 것 자체가 예전만큼 두렵지 않다. 가장 크게 바뀐 건 "내가 설득당하는 자리가 아니라, 정보를 전달하는 자리"라는 관점의 변화였다.

💡 이후로 지키게 된 습관 미팅 전에 "이 질문이 나오면 이렇게 답하겠다"는 시나리오를 3개 정도 준비해두는 것만으로도 당황하는 빈도가 크게 줄었다. 즉흥적으로 날짜나 가능 여부를 답하지 않고, 확답이 필요한 질문은 "확인 후 답변드리겠다"고 미루는 것도 중요한 습관이 됐다.

1번째 미팅 — 자신감2 / 10

 

3번째 미팅 — 자신감6 / 10

 

현재 (6개월 후) — 자신감8 / 10

 

6개월 후 결론

고객사 미팅에서 당황하는 이유는 기술 실력 부족이 아니라, 기술적 사실을 상대방이 이해할 수 있는 언어로 바꾸는 연습이 부족했기 때문이었다. 결론부터 말하고, 예상 질문을 미리 준비하는 것만으로도 같은 상황에서 훨씬 침착하게 대응할 수 있었다.

"고객은 내 기술 지식을 시험하는 게 아니라, 명확한 답을 원했을 뿐이었다."

회사와 프로젝트 구조에 따라 개발자가 고객 미팅에 참여하는 빈도와 방식은 크게 다를 수 있다. PM이나 기획자가 커뮤니케이션을 전담하는 조직도 많으므로, 이 경험은 특정 상황(소규모 팀, PM 부재)에서의 개인적인 사례로 참고해주시면 좋겠다.

결론

개발자가 고객사와 직접 미팅하며 당황했던 순간들은 대부분 기술 실력의 문제가 아니라, 전달 방식의 문제였다. 결론을 먼저 말하고, 예상 질문을 미리 준비하는 습관만으로도 같은 상황에서 훨씬 침착하게 대응할 수 있었다. 비슷한 자리를 앞두고 있는 개발자가 있다면, 기술적으로 완벽한 답변보다 상대방이 듣고 싶어 하는 결론이 무엇인지부터 먼저 생각해보길 권하고 싶다.

여러분도 비슷한 순간이 있으셨나요?

고객사나 비개발 직군과의 미팅에서 당황했던 경험이나, 그걸 극복한 노하우가 있다면 댓글로 공유해주세요. 비슷한 상황을 앞두고 있는 다른 개발자분들께 큰 도움이 될 것 같습니다.