화성인 개발자의 대화를 이끌어내는 법?

요즘 스타트업이 꽤 많아졌다. 하지만, 개발이 가미되어야 하는 스타트업 입장에서 개발자와의 관계 설정을 좀 쉽게 생각하는 경향이 있다. 어렵게 생각 할 필요도 없지만.. 그렇다고 조선 시대 종부리듯 개발자를 개발을 위한 도구로 생각 해서는 안된다고 생각하기에 몇가지 썰을 풀어보려고 한다. 

[이미지 출처: 구글 I/O]

개발자에 대한 편견

개발자랑 이야기를 해본적이 있는가? 아니지.. 그런 이야기를 하기에 앞서 개발자와 비 개발자를 어떻게 구분해야 하는지를 한번 보자. 필자가 생각하기에 개발자는 언어학자다. 비 개발자는 감성 학자라고 규정하고 싶다. 이 역시도 업무 과정에서만 이런 판단을 내려야하지 업무 외적으로 나가보면 사실상 큰 차이가 없는 일반인이다. 

우리가 흔히 개발자하면 머리속에 각인 된 Geek하거나 꼬질꼬질한 옷과 부시시한 행태로 날새면서 일하는 모습을 먼저 떠올린다. 오타쿠 같은 느낌도 일부 풍기는데, 개발이란 업무 특성상 몰입도가 중요하기에 약간 이런 공통적 이미지를 느낄 수는 있지만, 사실 이런 것 역시 편견에 지나지 않는다고 생각한다. 

경험했던 개발자가 수백명은 아니었지만, 만난 사람마다 지식의 깊이가 꽤 깊었고.. 상당수 책과 영화 청취 같은 일에 많은 비용을 투자하기도 한다. 혼자 사색하는 걸 좋아하는 사람들이 많은 편인데.. 개발이란 직업을 가지고 있기 때문에, 딱딱하고 재미없을 것 같은 편견이 생기는 것이다. 

후배 개발자와 이야기를 한다고 생각해보자. 날마다 서비스 개발 이야기만 할수는 없다. 물론, 업무중에는 자연스럽게 개발에 대한 논의가 진행되지만, 기본적으로는 업무를 벗어나면 개발 이야기만 가지고 모든 대화를 이끌어 갈 수 없다. 

서로 개발자라면 신기능이나 현재 JAVA의 방향이 어떻다느니 하면서, 개발자스러운 대화를 진행 할 수 있을지는 모르지만, 이 역시도 한계가 있다는 생각이다. 

개발자와 대화에서 개발과 관련되거나 기술과 관련 된 이야기를 해야 할 것 같은 압박과 부담감에 사로잡 힐 필요도 없고 그런 편견적인 시선으로 개발자를 대해서는 그들을 이해하지 못한다고 이야기하고 싶다. 

 

개발자에게 대화 거리를 던져주자

이는 개발자에게만 해당되는 것은 아니다. 대화를 스스로 이끌어나기지 못하는 사람들에 대한 이야기에 더 가까운데, 서로에 대해서 잘 알고 있지 않는 이상 상대방에서 어떻게 대화를 건내야 할지 모르는 경우가 많다. 

특히 업무와 연관해서 만난 개발자의 경우 자신의 빈듬이 들어날 수도 있고, 개발자가 자신을 무시 할 수도 있다는 생각 때문에 대화를 진행하는데 매우 조심하는 경향이 있다. 

그런데 생각해 보면 꼭 업무와 관련된 것이 아니더라도 개발자가 가진 폭넓고 깊이 있는 지식들에 접근하기 위한 노력을 조금만 기울인다면, 연예/시사 이이기를 자주하는 비 개발자의 대화 이상의 가치를 끌어내기도 한다. 

예를들어 자신이 쓰는 윈도우 이야기를 먼저 꺼냈다고 생각해 보자. 

윈도우를 쓰는데 너무 느리고, 하드웨어 업그레이드를 주기적으료 교체해야 할 것 같은 부담이 있다고 하면.. 기본적으로 개발자는 대안에 대해서 고민을 하게되고 우분투, 애플 Mac 등을 대안으로 제시해 주기도 한다. 사실 여기까지만 왔다면 개발자와 대화를 이끌어내는게 어렵지 않다는 걸 깨닫게 될 것이다. 

그걸 써봤느냐? 뭐가 좋냐등 비개발적 이야기지만 충분히 공감대를 형성해 갈 수 있다. 

 

개발자를 이해하는 특성 

프로그래밍을 하는 것이 좋아서 개발자를 하는 유형의 사람들은 필자가 느끼기엔 문제점을 풀어내는데 익숙한 생각 구조를 가진 사람들이 많다는 생각이다. 생각이 상당히 구조화 되어 있다고 볼 수 있는데, 이 때문에 대화를 하는 과정에서도 상당히 분석적인 경우가 있다. 

예를들어 애플 MAC AIR가 이뻐서 사고 싶어.. 근데 돈이 문제야라고 말한다면, "글쎄요? 잘 모르겠는데요?" 같은 대답이 돌아올때도 있고, "예뻐서 사고 싶은 거예요? 아니면 필요해서 사려는 거예요?" 같은 대답을 오는 경우도 있다. 물론, 이 예는 일반적이진 않다. 

다만, 이 예를 통해 설명하고 싶은것은 사고하는게 개발업무 때문인지.. 아니면 개발을 공부하고 이에 대한 지식을 확장시켜가면서 변화해서 그런지 다른 측면을 보는 경우가 있다는 것이다. 

디자인이나 이런 부분에서의 가치보다 과연 돈값을 왜? 하는지를 더 볼 수 있다는 이야기다. 

그들은 코딩을 통해서 서비스를 만들어 간다. 시스템 전반에 걸친 아키텍처 설계와 그 시스템을 바탕으로 데이터가 서로 교환되면서 상호 작용되는 서비스를 만들어가는 일을 하기 때문에 겉모습 보다는 기능 하나 하나의 구현에 따른 버그를 줄이는게 이들에겐 더 큰 목표점이 된다. 

즉, 이런 업무를 많이 하다보니 감성적인 부분보다는 다소 실용성에 더 초점을 맞추는 경향이 생겼는지.. 다른 시각차를 보이는 경우가 종종 있어 보였다. 

그런때 마다 왜? 라는 질문을 던지기 보다는 그럼 XXX는 그 제품을 보면 어떤 느낌이 들어와 같은 그들의 생각을 이해 할 수 있을만한 문장을 던지는게 좋다는 것이다. 이는 업무에서도 통용되는 이야기로, 개발자를 이해하면 조금은 업무의 편함을 느끼게 되는데, 이런 차이를 인정 할 수 있기 때문이다. 

 

업무에서 만나는 개발자의 특징

기획이나 디자인의 경우 미완성인 상태로 논의하면서 완성도를 높여가는 경우가 많다. 그런데 개발자에겐 이런 환경이 그리 익숙하지 않고 싫어라 하는 경향이 있다. 시스템 설계에 대한 온갖 변수가 도사리는데, 완성도까지 떨어진다면 그들은 매우 불안해 하기 때문이다. 

그래서 경력 있는 개발자와 초보 개발자가 일을 하면 훈계를 많이 듣게된다. 철자부터 아주 사소 할 수 있는 많은 것들에 대한 디테일한 지적이 진행되며, 수정을 거치는 개발자가 있다. 이것은 개발의 특성상 작은 업무라도 고민해야 하는 텀을 줄여야 하는 개발자 특유의 특성 때문이다. 

또, 디자인적인 것이나 성능적 퍼포먼스 보다는 시스템이 운영자가 없는 상황에서도 가능하면 안정적으로 돌아 갈 수 있는 구조를 만드는데 더 초점을 맞추는 성향을 보여준다. 

필자의 경험인데, 특정한 경우에 에러가 나는 경우가 있다. 

웹서버에서는 이런 기초적인 대응을 위한 404나 기타 에러페이지를 띄워 문제가 있음을 알려주는데, 그런 경우의 수를 넘어서는 것들에 대해서도 개발자는 언질을 해준다. 정말 희박한 경우라서 기획자는 보통 그냥 넘기고 그때가서 대응하자는 식으로 이야기하는 경우가 많은데, 지금 생각해 보면.. 이런 개발자는 참 좋은 개발자라는 생각이 든다. 

그만큼 서비스의 로직과 다양한 경우의 수를 스스로 고민했다는 것 아니겠는가? 일에 퍼포먼스만 생각한다면 굳이 희박한 경우까지 고민 할 필요가 없지만, 좋은 개발자는 이런 경우까지 고민하는 것이다. 

때문에, 계획된 것을 좋아하고 일정대로 움직이는 것을 매우 선호한다. 이런 특성 때문에 개발자와 업무로 이야기하기를 꺼리는 경우가 있지만, 상대방에 대한 이해를 보여주면 생각보다 다양한 대화를 하며 자신이 알지 못하는 시스템에 대한 이야기를 전해 들을 수 있다.

때문에 개발자의 업무 특성을 이해하고 그들과 교류하는 것은 IT 업종에 있는 사람이라는 기획/디자이너를 막론하고 자주 긴밀하게 진행해야 한다는 생각이다. 

 

개발자 이해하는 스스로의 노력도 필요

개발자와 대화하면 답답하다거나 대화가 어렵다고 느끼는 경향이 있는데, 꼭 개발과 관련 된 이야기가 아니더라도 질문을 던져주면 좋은 대화가 시작된다. 그것이 그들이 하는 업무의 연속 선상에 있는 것이라면 더욱 친절하고 깊이있게 이야기 해주는 사람들이다. 

어려워서 질문자가 못알아듣고 그렇다 보니 다음부터는 질문조차 안한는 경우가 생기지만, 이것은 개발자들의 잘못이 아니다. 

사람은 누구나 자신이 관심 있어 하는 것을 이야기하는 것에 더 재미를 느끼듯 개발자도 마찬가지란 생각을 해야 한다. 만약 그들과 대화하고 싶은데 이런 이유 때문에 대화가 단절된다면.. 그들을 이해하기 위한 공부를 해야 한다. 

개발 전반을 알 필요도 없다. 서버나 아키텍처나, 자바 같은 그들이 주로 던지고 대화 속에 포함되어 있는 용어들이 무었인지 공부하고 이게 어떤 역할을 하는지의 수고만 들여도 대화의 질이 크게 달라질 것이다. 

후배 개발자와 이야기하다 디자인 패턴 이야기를 한적이 있었는데, 난 이 대화에서 웹 디자인 관점의 디자인 패턴을 이해했는데.. 나중에 알고 보니 개발상에서 디자인 패턴을 적용해 좀 더 효율적인 서비스 개발을 진행 할 수 있다는 내용이었다. 

이와 관련해 여러 개발 방법론이 있다는걸 그때 알았는데.. 이는 꼭 개발이 아니더라도 앞으로 만들어야 할 서비스에 어떤 도움이 되는지 알 수 있고, 기획적으로 활용 할 수 있다는 점에서 도움이 되는 정보였다.

그런 것들을 대화하며 경험하고 또 무엇인지 찾는다면, 자신의 지식을 넓히는대도 도움이 될 뿐만아니라 개발자가 가진 능력도 간접 경험 할 수 있어 업무를 진행하는데도 큰 도움이 된다.

중요한 것은 분화되는 현대의 IT 시스템상 이런 대화가 단절되고 끼리끼리 노는 경향이 있지만, 개인적으로 IT 업종에 종사하는 사람은 서로 다른 직군의 특징을 이해하고 활용하기 위해서라도 서로 대화하는 법을 익히고 상대를 이해하는 노력을 수반해야 한다는 생각이다.

아마 그러면 개발을 하는 것이 더 재미있고 즐겁지 않겠는가?