클라이언트와 개발자, 서로 다른 언어를 말하다

"그거 있잖아요, 버튼 누르면 뭔가 딱 나오는 거요."

클라이언트와 미팅을 하다 보면 이런 말을 종종 듣는다. 4년째 외주 개발을 하고 있지만, 이런 순간은 여전히 당황스럽다. 당연히 알아들어야 할 것 같은 말인데, 정확히 뭘 원하는지 알 수가 없다.

외주 개발에서 가장 어려운 건 코딩이 아니다. 커뮤니케이션이다.

개발자와 클라이언트는 기본적으로 다른 언어를 쓴다. 개발자는 "API", "데이터베이스", "서버", "프론트엔드" 같은 용어로 생각하고 말한다. 하지만 클라이언트에게 이런 단어는 외계어에 가깝다.

반대로 클라이언트는 "사용자 경험", "브랜드 이미지", "시장 반응" 같은 비즈니스 관점에서 이야기한다. 개발자에게는 이게 추상적으로 느껴질 수 있다.

4년 전 처음 시작했을 때, 이 간극을 인식하지 못했다. 서로 다른 것을 상상하면서 "네, 알겠습니다"라고 대답하고, 결과물이 나왔을 때 "이게 뭐예요?"라는 반응을 받은 적이 한두 번이 아니다.

이 문제를 해결하는 가장 좋은 방법은 요구사항을 문서로 정리하는 것이다. 말로 하면 서로 다르게 이해하기 쉽다. 하지만 글로 쓰면 오해의 여지가 줄어든다.

예를 들어 클라이언트가 "회원가입 기능이 필요해요"라고 했다면, 나는 이렇게 정리한다.

이렇게 구체적으로 쓰면 클라이언트도 피드백을 줄 수 있다. "전화번호는 필수로 해주세요", "이메일 인증은 없어도 돼요" 같은. 모호함이 사라지고 기대치가 맞춰진다.

글로 정리해도 여전히 오해가 생길 수 있다. 특히 화면 UI에 관한 부분은 말로 설명하기가 어렵다. 이때 와이어프레임이 큰 도움이 된다.

와이어프레임은 화면의 대략적인 레이아웃을 그린 것이다. 예쁘게 만들 필요 없이, 어디에 무엇이 배치되는지만 보여주면 된다. 나는 피그마(Figma)로 간단하게 그려서 공유한다.

아무리 열심히 글로 설명해도 "네네, 알겠어요"라고 하던 클라이언트가, 와이어프레임을 보면 "어, 이게 아니라..."라고 하는 경우가 정말 많다. 시각적으로 보여주는 것이 그만큼 강력하다.

4년간 배운 가장 중요한 교훈 중 하나. 최대한 자주, 일찍 결과물을 공유하라.

완성된 후에 한 번에 보여주면 안 된다. 중간중간 진행 상황을 공유해야 한다. "아직 디자인은 안 입혔는데, 기능은 이렇게 동작해요"라면서 작동하는 프로토타입을 보여준다.

이 방식의 장점은 방향이 틀어졌을 때 일찍 발견할 수 있다는 것이다. 전체를 다 만들고 나서 "이게 아닌데요"라는 말을 들으면 처음부터 다시 해야 할 수도 있다. 하지만 중간에 발견하면 수정 범위가 작아진다.

클라이언트의 모든 요청을 들어줄 수는 없다. 기술적으로 불가능한 것도 있고, 가능하더라도 시간과 비용이 너무 많이 드는 것도 있다.

초반에는 "안 된다"고 말하기가 어려웠다. 프로젝트를 놓칠까 봐 걱정됐다. 하지만 무리한 요청을 수락하면 결국 양쪽 다 불행해진다는 걸 여러 번 경험했다.

지금은 안 되는 건 안 된다고 말한다. 대신 왜 안 되는지, 대안은 무엇인지를 함께 설명한다. 의외로 클라이언트들은 근거 있는 거절을 잘 받아들인다.

결국 커뮤니케이션의 목표는 신뢰를 쌓는 것이다. 클라이언트가 "이 사람한테 맡기면 잘 해줄 거야"라고 믿을 수 있어야 프로젝트가 순탄하게 진행된다.

신뢰는 거창한 게 아니다. 약속한 일정을 지키고, 문제가 생기면 미리 알려주고, 질문에 성실하게 답하는 것. 이런 작은 것들이 쌓여서 신뢰가 된다.

4년간 단테 컴퍼니를 운영하면서 느낀 건, 개발 실력만큼이나 소통 능력이 중요하다는 것이다. 아니, 어쩌면 더 중요할지도 모른다.

같은 고민을 하는 분들에게 도움이 됐으면 좋겠다. 궁금한 점이 있으시면 dante.company를 통해 편하게 연락주세요.

다른 글