오늘도 개발자가 안 된다고 말했다. - 안 된다는 말의 여러 가지 의미

 

협업은 혼자하기 어려운 문제를 함께 해결하기 위해 공동의 목표를 세우고 달성해가는 과정이다.

 

 

IT기술 서적들 사이에서 이 책 제목을 봤을 때, 평소와 달리 나도 모르게 가장 먼저 손이 갔다. 개발자인데다 "안 된다"고도 꽤나 말해서 뜨끔하기도 했지만 그보다 나도 다른 직업군(기획자 등)과 소통이 잘 안돼서 답답했으니까.

 

프롤로그는 이렇게 시작한다.

IT 업계 종사자에게 업무 중 힘든 일이 무엇인지 물어보면 개발자와 협업하는 것이라는 이야기는 빠지지 않고 나온다. 아마 개발자와 협업을 해본 사람이라면 누구나 공감할 것이다.

회사에 다닐적엔 항상 개발팀에 있었기에 개발자들끼리의 협업 방식만 중요한 줄 알았다. 다른 직업군과의 대화는 주로 팀장님들이 하셨기에 경험할 일도 생각할 일도 없었다.

그 때문인지, 퇴사 후 첫 사이드 프로젝트를 해보며 처음으로 다른 직업군과 협업할 일이 생겼을 때, 난 받은 기획안을 개발만 하면 된다고 여겼고, 기능 구현을 해내는 열정에만 불타올랐었다. 그리고 결국 그 프로젝트는 망했다. 두 번째도.. 마지막까지 같이 했던 팀원들끼리 좋게 헤어지지도 못했다.

 

꽤나 오랜 시간이 지나서야 소통의 중요성을 느꼈다. 정확히 언제부터인지는 모르겠지만, 계기는 명확하다. 창업을 혼자 시도해보면서 사람이 필요하다는 걸 알게됐고, 팀원과 지속적으로 소통을 잘 해나간다는게 정말 어렵다는 것 또한 체감했기 때문이다. 그리고 똑같은 실수를 반복하고싶지 않았다. 소통에 관해서는 노력하지 않았음을 인정하는게 우선이었다.

 

책의 저자가 말하는 "온몸으로 느낀 개발자"의 세 유형을 보면서 내 과거와 현재가 있었다.

퇴사 후 첫 사이드 프로젝트에서는 "무엇이든 가능하다고 말하는 개발자"였고, 기능 구현 자체에 집중하다 보니 서비스 구조, 안정성, 우선순위 등은 고려하지 않은채 개발이 이뤄져 스스로 일정관리가 되지 않았기에 결국 "안 된다는 말을 달고 사는 개발자"였다. 다행히도 지금은  개발뿐만 아니라 비즈니스와 고객에 초점을 맞추다 보니 자연스럽게 "대안을 제안하는 개발자"가 되어가는 중인듯 하다.

 

IT 서비스 인체와 비교

 

개발자로서 재밌는 부분은  "개발자에게 하면 안 되는 말"이었다. 

"눈으로 보기에는 간단해 보이는 일이더라도 서비스는 하나의 인격체처럼 연결되어 있기 때문에 단순하게 생각해서는 안된다." 같은 말을 개발자가 아닌 사람이 해준다는 것에 좀 놀랬다. 또한 "타 서비스에서는 제공하던데요?"같은 무의식 중에 하는 경우가 많은 말이 개발자에게 얼마나 큰 무례일 수 있는지를 알려주신다는 것에 감사했다.

 

 

읽으며 사실 내게 필요했던 부분은 "기획자의 일"에 관한 것이었다. 과거에 기획자와 일해본 적이 있었고, 현재 진행 중인 프로젝트에 PO님과 같이 협업 중인데, 난 PO와 기획자를 구분하지 못하고 동일시하고 있다는 걸 알게됐다. 이 책을 읽어보고 검색을 통해 좀더 알아보지 않았다면, 또 크게 실수를 저질렀을 지도 모른다. 이젠 알게됐고 책에 기획에 관한 좋은 팁들도 담겨있으니, PO님과 함께 기획적인 부분을 논의하며 더 나은 방향으로 소통할 수 있을거 같다.

 

책을 덮을 때쯤, 다른 방면의 소통에 관해서도 많이 생각하게 된다.

똑같은 한국말로 하지만 기획자와 개발자간 서로 다른 직업군의 소통, 영어로 대화하지만 다른 국가와 문화를 가진 상태에서의 소통, 오랜 시간을 함께 보낸 가족끼리도 서로를 이해하지 못하는 대화 등이 계속 떠올랐다. 문득 "사회가 복잡하고 다양해져서 그럴까?" 라는 물음을 가졌을 때, 저자는 "서로 함께 있지만 너무나 다른 사고 방식을 갖고 있다. 어쩌면 이들이 부딪히는 일이 생기는 건 당연할지도 모른다."라는 답변을 해준다. 머릿속으로는 분명 알고 있는 내용인데, 대화를 하는 도중에는 이게 참 쉽지 않은 것 같다. 이래서 습관이 무서운 건가...

 

저자의 말대로, 경험상 개발의 영역에서 불가능한 부분은 내 경험 상에도 사실상 거의 없었다.

즉, 개발자가 안 된다는 말을 할 때면 그 의도는 "우리가 가진 자원(시간, 인력, 비용 등)내에 안 된다"는 의도로 말하고 있지만, 받아들이는 입장에서는 보통 그렇게 알아 듣지 못한다는 것이다. 이 부분에 있어 기획자에게 좀더 친절히 쉽게 설명해줄 수 있는 것도 협업을 잘 하기 위한 개발자의 역량중 하나라고 받아들이게 된다.

반면, 어떤 기획이라도 서비스의 성장을 위해 사용자의 관점에서 이유와 목적이 설명이 된다면 개발자는 아주 적극적으로 움직일 것이다. 왜냐하면 개발자에게 이유는 매우 중요하니까.

 

 

만족한 점 : 40~50명 이상의 개발자와 협업해본 저자의 경험.

아쉬운 점 : 디자인과 개발 지식에 관한 내용들은 많이 줄였다면.