개발자의 소통의 중요성

IT기술을 기반으로 성장하는 스타트업에서 개발 부서는 그 회사의 중심이라고 해도 과언이 아니다. 물론 마케팅이나 고객지원, 기획, 경영지원, 영업 등의 부서들도 회사에 없어서는 안될 중요한 부서이긴 하지만 서비스가 개발되지 않으면 그 기업이 존재할 수 없는 IT 스타트업의 특성상 개발 부서의 역할은 중요하다. 그래서 개발 부서의 소통력은 좁게는 프로젝트의 성공여부와 넓게는 회사의 발전을 결정하는 중요한 능력이다. 이 글에서는 내가 느낀 개발자들의 소통의 중요성과 필요성에 대해 말해보고자 한다.

자기개발

개발자들은 회사업무 외 자기 개발에 관심을 많이 가지고 항상 자기 개발을 위해서 노력한다. 일반화 하고 싶진 않지만 내 기준에서 주변의 개발자 분들 중에서는 이러한 노력에 좀더 나은 의사소통을 위한 노력을 기울이는 개발자를 많이 보지 못한 것 같다. 기술력을 높이기 위한 노력은 개발자에게 없어서는 안될 덕목 중 하나이다. 많은 개발자들은 그 중요성을 알기에 오늘도 성장을 위해 자기 개발에 노력을 쏟고 있고 흔히 보는 개발 블로그나 SNS에서 성장하지 않는 개발자는 죽은 개발자와 같은 맥락의 글들을 심심치 않게 볼 수 있다. 하지만 여기서 말하고 있는 성장에도 기술의 성장을 의미하지 소통력의 성장을 의미하는 것 같진 않다.

개발자는 엄청난 천재(?)라고 해도 혼자서는 일을 할 순 없다. 설령 뛰어난 기술력으로 아주 좋은 제품을 개발했다고 하더라도 그 제품을 사용하는 고객이 존재하지 않다면 그 제품은 없는 것이나 다름없다. 고객이 그 제품을 사용하게 하려면 사람들에게 그 제품을 알려야 하고 그것을 관리할 수 있어야 하며, 사람들의 필요성을 파악하고 예측해서 더 나은 제품으로 발전해야 한다. 이 모든 것은 절대 혼자 할 수 없다. 그래서 개발 자는 마케터나 기획자, 디자이너 등과 같이 비 개발자들에게 자신이 만든 제품을 잘 설명할 수 있어야 하며 어떤 목적성을 가지는 지를 말하는 등 소통이 필요하게 된다. 결국 개발자에게 소통능력은 빠질 수 없는 능력이며 높은 기술력과 원만한 소통능력을 함께 가져야 유능한 개발자가 될 수 있다.

프로젝트

두가지 사례를 들어 개발자의 소통이 어떻게 프로젝트에 영향을 미치는 지 얘기해 보겠다.

요구사항을 가진 이해관계자와 기획자가 프로젝트 발의를 하였다. 요구사항은 터무니 없진 않았지만 기술적으로 해결해야 하는 문제점을 다수 포함하고 있었고 이러한 문제점을 해결하기 위해 개발자와 함께 해결방안에 대한 논의를 진행하였다. 개발자는 여기서 단순히 이해관계자와 기획자에게 요구사항에 기술적 문제점이 있으니 요구사항을 수용할 수 없거나 기능을 대폭 줄일 수 밖에 없다는 얘기만 반복하였다. 이 개발자는 이해관계자와 기획자는 개발자가 아니니 이해하지 못할 내용이니 자세한 설명은 생략하고 그냥 불가능하다는 얘기만 한 것이다.

개발실에서 특정 기능을 개선하는 프로젝트를 진행하였다. 해당 기능을 구현할 때 개발자마다 각각 자기가 구현해야할 기능을 개발하였다. 개발 기간동안 개발자들은 자기가 구현해야할 구현에만 집중하였고, 오픈일이 얼마 남지 않은 시점에 각자 구현한 기능들을 연동하는 작업을 진행하였다. 개발자들은 자신이 구현한 기능들은 기술적으로 문제가 없고 테스팅이 모두 끝난 상태였으므로 연동에 문제가 없을 것이라 자신하였다.

위 두 사례의 프로젝트는 성공하였을까? 예상했겠지만 두 프로젝트는 실패하였다.

첫 번째 사례는 개발자의 배려가 문제다. 개발자는 이해관계자와 기획자에게 왜 구현에 문제점이 존재하는 지, 어떤 기술적 어려움이 요구사항을 수용하기 어려운지에 대해 설명해야할 의무를 가지고 있다. 위 사례처럼 제대로 된 설명 없이 단순히 할 수 없다라고만 한다면 이해관계자와 기획자는 그 개발자가 단순히 하기 싫어서 이거나 어려워서 요구사항을 수용하지 못하고 있는건 아닌지 등 온갖 오해를 가지고 프로젝트를 진행하게 될 것이고, 프로젝트가 진행되는 동안 개발자와 낮은 신뢰를 가지고 함께 업무를 하게 될 가능성이 높다. 이런 프로젝트는 설령 그 프로젝트가 마무리 되었다고 하더라도 제대로 된 기능이 구현되어 있을 수가 없다. 개발자는 개발자 나름대로의 불만을 이해관계자와 기획자는 그들 나름대로의 불만을 가지고 프로젝트를 마무리 하게 될 것이다.

두 번째 사례는 개발자의 무책임함이 문제다. 본인의 구현이 아무리 기술적으로 완벽하다 해도 다른 개발자가 구현한 기능과 잘 어우러져야 제품은 완성된 것이다. 구현 중에 자주 다른 개발자와 소통을 하고 맞추어 간다면 연동 과정에서 발생하는 불필요한 의견 충돌이라던지 오류가 발생할 가능성은 많이 줄일 수 있다. 하지만 자신만을 위한 기능구현만 하고 소통의 노력이 없다면 그 개발자는 무책임한 개발자라고 말할 수 있을 것이다.

말투

Tech has a Toxic Tone Problem — Let’s Fix It! 글에서 개발자들이 왜 말투를 고쳐야 하는지 말하고 있다. 사실 이 글을 쓰게된 계기도 이 글을 읽고 난 후 느낀바가 있어서 이기도 하다. 개발자는 자신이 개발자이기 때문에 친절하지 않는 말투를 사용해도 된다. 라는 면죄부를 자신에게 부여하는 경향이 있어 보인다. TV나 SNS에서 보면 높은 기술력을 가진 사람이 자신의 주장을 관철시키기 위함인지는 모르겠지만 직설적이고 강한 어조로 사람들에게 자신의 의견을 전달하는 것을 많이 보았다. 어쩌면 다른 개발자들도 그렇게 말하면 자신이 그 유명한 사람이 된 것 같은 착각을 가지는 지도 모르겠다. 나도 그런 경향을 가지고 있지 않는지 항상 경계하고 고치려고 노력하고 있다. 하지만 나는 아무리 똑똑하고 유능한 사람이라고 해도 타인에게 상처를 줄 수 있는 말을 할 수 있는 권리는 없다고 생각한다. 설령 자기가 말한 의도가 그렇지 않다고 해도 상대방이 그렇게 느낀다면 그건 말한 사람이 상대방에게 실수를 범한 것이다. 왜냐하면 소통은 혼자만 하는 활동은 아니기 때문이다. 같은 말이라도 상대방의 기분을 살피면서 대화하는 연습을 해야 한다.

IT스타트업에서 조직의 구성원이 많아지면 많은 구성원을 어떻게 관리하고 어떻게 개발할 건지에 대한 개발프로세스 논의를 많이 할 것이다. 나는 회사의 개발 프로세스도 중요하지만 회사 구성원들의 소통문제를 해결하는 것이 가장 중요한 문제라고 생각한다. 구성원이 적을 때의 소통비용과 많을 때의 소통비용은 많은 차이를 가지기 때문이다. 소통의 문제를 해결하지 않고 단순히 개발프로세스나 인원관리에 대한 논의만 진행된다면 항상 문제는 원점으로 돌아갈 것이다.

개발부서와 개발자 개개인은 원만한 소통을 위한 노력을 기울이지 않는다면 개발부서는 그 회사의 비전을 공유하고 서비스의 발전에 노력하기 보다 정해진 요구사항만 처리하는 것만 추구하는 외주업체와 다를바가 없을 것이다.

Tech has a Toxic Tone Problem — Let’s Fix It!에서 긍정적인 환경에서의 업무성과는 부정적인 환경보다 10%~30% 높은 성과를 보여주었다는 얘기가 있다. 원활하지 않는 소통환경에서 개발자들은 팀내 뿐만 아니라 프로젝트 내에서 긍정적인 환경을 조성하기 어려우며 결국 좋은 성과를 기대하기 어렵다.

소통능력의 필요성은 개발자 뿐만 아니라 비 개발자도 모두 포함되지 않느냐라고 말할 수도 있다. 맞다. 비 개발자도 포함한다. 하지만 개발자는 그 필요도가 큰 것에 비해 필요성을 덜 느끼고 있지 않는가 라는 생각에 개발자의 소통능력은 특히 더 중요하고 필요하다고 생각한다. 개발자는 기술력의 발전에 항상 노력하듯이 자신의 소통능력에 문제가 있지 않는 지 항상 경계하고 향상시키기 위한 노력을 해야 하겠다.

https://compassionatecoding.com/blog/2016/8/25/tech-has-a-toxic-tone-problemlets-fix-it/