고객이라는 미지의 세계
개발 업무에서 고객은 일반인이 아니다. 클라이언트다. 업무를 수주한 회사를 말한다. 자체 서비스를 진행하는 경우에는 서비스를 운영하는 직원이다. 개발자는 최종 고객, 다시 말해 일반 서비스를 이용하는 사람과는 연결되지 않는다.
이 경계가 중요하다. 개발자와 최종 사용자가 직접 연결되면 서비스의 컨셉이 흔들릴 수 있고, 개인정보가 유출되거나, 운영 지침이나 업무에 혼란을 야기할 수 있다.
프로그래밍을 모르는 사람들
대부분의 고객은 프로그래밍을 잘 모른다. 회사의 마케팅 부서에 있는 사람이 고객이 될 수 있고, 대표가 고객이 될 수도 있다. 영업하는 사람, 가게 주인이 고객이 될 수도 있다.
고객은 무엇을 만들고 싶은지에 대한 아이디어만 가지고 있다. 그 아이디어를 실제로 구현하는 사람이 개발자다. 개발자는 아이디어를 어떻게 만들지를 고민하고, 현재 기술력으로 가능한지를 판단하면 된다.
처음 프로젝트 미팅을 할 때가 그렇다. 고객이 말한다. "이런 기능이 있었으면 좋겠어요. 간단한 거잖아요?" 간단하지 않다. 고객에게는 버튼 하나 추가하는 것처럼 보이지만, 그 버튼 하나를 위해 DB 테이블을 새로 만들고, API를 개발하고, 화면 로직을 짜고, 예외 처리를 해야 한다.
"다른 사이트에는 이런 기능이 있던데 하루면 되죠?" 안 된다. 보이는 화면은 비슷해 보여도 내부 시스템은 완전히 다를 수 있다. 데이터 구조가 다르고, 인증 방식이 다르고, 결제 모듈이 다르다. 그냥 가져다 붙일 수 있는 게 아니다.
하지만 고객을 탓할 수는 없다. 고객은 프로그래밍을 모른다. 당연하다. 개발자가 마케팅을 모르고, 영업을 모르고, 회계를 모르는 것처럼. 각자의 영역이 있다.
추상적 아이디어와 구체적 구현
고객이 말한다. "사용자 친화적인 화면으로 만들어주세요." 무슨 의미인지 알 수 없다. 사용자 친화적이란 게 무엇인지. 버튼이 큰걸 말하는지. 색깔이 밝은 걸 말하는지. 클릭 수가 적은 걸 말하는지.
"트렌디한 느낌으로 해주세요." 트렌디가 뭔지. 요즘 유행하는 그라데이션을 쓰라는 건지. 큰 폰트를 쓰라는 건지. 미니멀한 걸 원하는 건지.
고객의 언어는 추상적이다. 개발자의 언어는 구체적이다. 이 간극을 메우는 게 기획자의 역할이다. 기획자가 고객의 추상적인 아이디어를 구체적인 화면 설계서로 만든다. 버튼 위치, 색상 코드, 폰트 크기, 여백까지 명시한다.
하지만 기획자가 모든 걸 메울 수는 없다. 개발 도중에도 고객은 계속 말한다. "이 부분 느낌이 별로인데." 무엇이 별로인지 구체적으로 말하지 못한다. 그냥 느낌이 별로다.
여러 번 물어봐야 한다. "색상이 별로인가요, 레이아웃이 별로인가요?" "음... 전체적으로요." 다시 물어야 한다. "버튼 크기가 작아서 그런가요, 간격이 좁아서 그런가요?" "아, 간격이 좁아서 그런 것 같아요."
시간이 걸린다. 하지만 이 과정을 건너뛸 수 없다. 고객이 원하는 게 무엇인지 정확히 파악해야 제대로 된 결과물이 나온다.
마치 취조하듯 고객에게 되물어야 한다. 기획자나 개발자 스스로 결정하면 후에 감당이 안될 수 있다. 고객의 서비스이지 기획, 개발자의 서비스가 아니다. 그래서 되도록이면 고객사에서 기획을 진행한다.
다만, 가끔 고객사의 기획자도 추상적일 때가 있다.
영역의 경계
아이디어와 운영은 고객의 영역이다. 개발자가 관여할 영역이 아니다. 개발자는 아이디어를 잘 구현하고, 운영을 잘할 수 있게 시스템을 관리하는 역할만 한다.
가끔 경계를 넘고 싶을 때가 있다. "이 기능보다는 저 기능이 더 필요할 것 같은데요." "이렇게 운영하시면 문제가 생길 것 같은데요." 말하고 싶다. 하지만 참아야 한다.
고객이 요청하지 않았다면 말하지 않는다. 기술적 조언은 할 수 있어도 평가해서는 안 된다. 고객의 아이디어가 시장에서 성공할지는 고객이 판단할 영역이다. 개발자는 그 아이디어를 기술적으로 구현 가능한지만 판단하면 된다.
"이 기능은 기술적으로 불가능합니다"는 말할 수 있다. "이 기능은 별로일 것 같습니다"는 말하면 안 된다. 전자는 기술적 판단이고, 후자는 사업적 판단이다.
물론 경계가 애매할 때도 있다. "이 방식으로 구현하면 서버 부하가 심할 수 있습니다"는 기술적 조언이다. "이 방식으로 하면 사용자가 불편할 것 같습니다"는 경계를 넘는 말이다.
고객을 이해하는 법
25년 동안 수많은 고객을 만났다. 자기 아이디어에 확신이 넘치는 사람, 계속 마음이 바뀌는 사람, 개발 일정을 이해 못 하는 사람, 모든 걸 개발자에게 맡기는 사람.
각양각색이지만 공통점이 있다. 모두 자기 사업을 성공시키고 싶어 한다는 것. 그래서 개발자에게 기대를 건다. 자기 아이디어를 완벽하게 구현해 주기를 바란다.
그 기대를 저버리지 않으려면 고객을 이해해야 한다. 고객이 프로그래밍을 모른다고 답답해하지 말고, 천천히 설명해야 한다. 고객이 계속 마음을 바꾼다고 짜증 내지 말고, 왜 바꾸는지 이해하려 해야 한다.
고객도 처음이다. 시스템을 만드는 게 처음인 사람이 많다. 개발 프로세스를 모르고, 일정이 왜 중요한지 모르고, 기획서를 왜 확정해야 하는지 모른다. 알려줘야 한다.
개발자가 먼저 다가가야 한다. 고객이 개발자의 언어를 배우기를 기다리지 말고, 개발자가 고객의 언어를 이해해야 한다. 기술 용어를 쓰지 말고, 쉬운 말로 설명해야 한다.
가끔 SNS를 보다 보면 판교사투리라는 것을 보게 된다. 한국어도 아닌 영어도 아닌 IT 분야에서 사용하는 용어 사용을 말한다. 전문 분야 언어는 그 분야의 사람들과 대화할 때 사용하는 언어이지 다른 분야 사람에게 강요해서는 안된다.
경상도나 전라도에 가면 그 지방의 사투리만 사용해야 하는 건 아니다. 서울에 왔다고 서울말만 해야 하는 것도 아니다. - 다른 분야 사람에게 전문 분야 용어를 남발하는 것은 자기 자랑이고, 자신은 아직 초보라서 더 자랑하고 싶은 것이라는 생각밖에는 들지 않는다. -
고객은 미지의 세계가 아니다. 그냥 다른 영역에서 일하는 사람일 뿐이다.
서로의 영역을 존중하고, 경계를 지키고, 필요할 때 다리를 놓으면 된다.
