brunch

매거진 SW 개발에 관한 생각들

라이킷 15 댓글 4

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Extreme Code Aug 26. 2021

개발자의 인성이 중요할까?

개발자의 인성은 팀의 생산성에 영향을 얼마나 미칠까

예전에 지인과 개발자의 인성이 얼마나 중요한 요소일지에 관해서 이야기를 나눈 적이 있었다. 나는 예전에는 개발자의 인성은 크게 중요치 않고 실력이 가장 중요하다고 생각했던 적도 있었고, 실제로 그러한 생각을 가지고 있는 사람들이 꽤 있다. 하지만, 프로젝트를 이끌어나가고 팀을 운영하는 경험이 쌓이고 다양한 의견을 접하다 보니 개발자의 인성은 꽤 중요한 요소라고 생각하게 되었다.

그리고, 이에 관하여 좋은 예시가 생겨서 글을 써본다.

인성 엉망인 개발자의 예시

최근에 병X같은 놈이 이 글에 이상한 댓글을 달았다는 걸 알게 되었다. 사실 내 시간은 매우 소중하고, 병X들에게 낭비할 시간은 없기 때문에 웬만하면 이런 데 답글을 달지는 않는다. 하지만 워낙에 뻘소리를 해대서 답글도 달게 되었다.

일단, 이미 해당 글에서 밝혔듯이 이러한 구분은 서로 독립적이 아니며, 회사/분야 등에 따라서 얼마든지 바뀔수 있다. 그럼에도 불구하고 개소리를 해대니 어쩔 수 없이 내가 이렇게 글을 쓰게 되었다.

프론트엔드는 UX가 핵심이긴 하지만 비즈니스 로직을 아예 안다루는 것이 아니다. 특히나 요즘같은 복잡도 높은 앱이 만들어지는 시대에는 말이다. 예를 들어, GraphQL 을 사용하는 React 개발자는 뭐라고 부를 것인가? 일반적으로 프론트엔드 개발자라고 한다. gql 을 사용하여 쿼리를 사용함에도 말이다.

카카오톡 PC버전은 데스크톱 앱임에도 불구하고 electron같은 프레임워크를 활용한 FE팀에서 만든다. 왜냐면 주로 뷰를 구성하고 나머지는 서버와의 통신으로 진행하기 때문이다. 요즘에는 웹/앱/데스크탑을 모두 한가지 프레임워크를 사용하는 추세이다. React Native나 Flutter가 왜 나왔는지를 생각해보라. 요즘은 웹/앱/데스크탑 앱 모두 클라이언트 형태로 활용이 되는 추세이다. 그리고 여기서 다루는 비즈니스 로직의 복잡도에 대해서는 프론트/백이 우열을 가릴 수 없다.

JS기반이 아닌 Qt와 같은 네이티브 크로스 플랫폼 개발 프레임워크도 마찬가지이다. 핵심은 뷰를 보여주는 것이다. 요즘같은 때에 인터넷 연결 없이 그냥 동작하는 앱이 몇개나 될까? 요즘은 대부분 클라우드 네이티브로 개발된다. 웹/앱/모바일은 프론트엔드에 가까운 작업을 하게 되는 것이다. 물론 앱이나 데스크톱의 경우에도 별도의 채용 시 별도의 JD를 만들어서 채용한다. 하지만 대부분 클라이언트 형태의 앱이기 때문에 그런 의미로 프론트엔드에 가깝다고 쓴 것이다.

그렇다면 반대로 백엔드에 관해 생각해보자. 음성 인식 앱이 있다. 여기에 들어가는 핵심 모델을 만든 개발자에게 당신은 백엔드 개발자입니까? 라고 물어보면 뭐라고 할까? 100이면 99는 "아니요, 머신러닝 엔지니어입니다." 아니면 "음성인식 기술 연구원입니다." 라고 할 것이다.

또 다른 애매한 케이스를 보자. Photopea는 웹에서 돌아가는 포토샵 클론이다. static JS 로 서빙되기 때문에 백엔드는 전혀 들어가지 않는다. 그러면 프론트엔드 개발자인가? 어느 정도 그렇다. 하지만 핵심은 뷰 쪽이 아닌 포토샵의 이미지 프로세싱 알고리즘이고, 이를 JS로 구현하는 것들이 핵심이다. 그렇다면 그냥 프론트엔드 개발로만 볼 수도 없다. 프론트엔드 개발이 들어가지만 핵심은 이미지 연산 알고리즘이기 때문이다.

즉, 내가 말하고자 하는 것은 프론트엔드는 보여지는 것 / 백엔드는 뒷단에서 돌아가는 것 이라는 분류는 단지 사전적인 정의일 뿐이라는 것이다. 실제 회사들이 JD를 살펴보면 프론트엔드는 주로 JS기반으로 React, Angular등을 활용하여 웹을 구성하는 개발자들을 의미하고 백엔드는 서버기반으로 RESTful API 와 DB 제어, 서버 운영/관리 위주로 하는 개발자를 의미한다. 단지 뒷단에서 돌아가는 비즈니스 로직을 다룬다고 백엔드라고 말하지 않는다.

그렇기 때문에 업계에서는 기술 스택 기반으로 분류하는게 더 일반적이다. 그리고 요즘같은 복잡도 높은 시대에는 딱 정해진 룰은 없으며 많은 구루라고 불리는 개발자들도 서로 다른 의견을 가질 때가 많다. 기술 변화가 매우 빠르기 때문이다. 댓글 쓴 병X의 주장은 1) 최신 기술 트렌드에 뒤쳐져 있거나 2) 경험이 부족하거나 3) 난독증이거나 이 세가지중에 하나에 속하거나 다 해당된다고 생각된다.

개발자의 인성이 생산성에 미치는 영향

이 글의 핵심은 이런 개발분야 분류가 아니라 개발자의 인성에 관한 내용이다. 내가 해당 글에 대한 디테일한 설명이 없었기 때문에 오해를 불러 일으킬 수는 있다는 점은 인정한다. (사실 경험 있는 개발자라면 그런 오해를 하기 힘들겠지만) 그런데 정상적인 개발자라면 "제 생각은 이러한데, 잘못 알고 계신거 같습니다." 라던가 "A는 B로 알고 있는데 잘못된 정보인거 같네요." 라고 말할 것이다.

그리고 난 절대 내 생각이 항상 옳다고 생각하지는 않기 때문에 반론은 언제나 환영이다. 그리고 역량 있는 개발자들과의 기술적 토론/논쟁은 즐겁기 때문에 내가 소개란에 기술 토론을 할 수 있는 오픈채팅방 링크도 적어놓았다. 그럼에도 불구하고 난독증에 무매너까지 합해진 댓글을 적는 걸 보면 인성이 뻔히 보인다.

이러한 인성 엉망인 개발자를 채용하는 것이 위험한 이유가 있다. Amy Edmondson의 책 두려움 없는 조직을 보면 "심리적 안정감" 이라는 개념이 나온다. 이것은 사실 구글의 팀 퍼포먼스 분석 결과 중요 요소로 도출되어서 꽤나 많은 주목을 받게 된 개념인데, 나도 다양한 경험을 해 보다 보니 이 심리적 안정감이라는 것이 굉장히 중요한 요소라고 느꼈다. 이게 팀 문화에 자리가 잡혀야 적극적으로 아이디어도 내고, 기술 스택의 발전도 건전하게 이뤄지며, 기술 부채 제거도 잘 될수 있고, 코드리뷰 등도 잘 이뤄질 수 있다. 특히나 인성은 커뮤니케이션과도 관련이 깊다. 개발자의 중요한 덕목 중 하나로 커뮤니케이션도 있는데, 인성 엉망인 개발자와 커뮤니케이션이 제대로 될 리가 없다.

특히나, 요즘같은 속도가 중요한 시대에는 가설 - 구현 - 검증의 단계를 빠르게 iterate 해야 하는데, 이 때 인성 엉망인 빌런 한마리가 맨날 뻘소리를 해 대면 팀의 생산성이 많이 낮아지게 된다. 특히나 이런 빌런들은 자기가 아는게 다인냥 구는 경우가 많다. 그리고 우습게도 공부를 등한시하기 때문에 자신이 부족한걸 어렴풋이 알고 있음에도 불구하고, 그냥 무작정 우기는 경우가 많다. 이러한 빌런들은 뻘소리는 충분한 사실과 근거 기반으로 눌러주면 되기는 하지만 그러기 힘든 상황도 있을 것이다. 그렇게 되면 팀의 생산성이 악화되게 되고 역량과 인성 모두 높은 핵심 개발자부터 다른 곳으로 떠나게 된다. 미꾸라지 한마리가 물을 흐린다는 말이 딱 맞는 것이다.

그래서 채용이 중요한 것이다. 문제는, 이런 인성 엉망인 개발자의 경우 인터넷 상에서는 키보드 워리어처럼 활동하다가 현실 세계에서는 순한 양처럼 조용한 경우가 많다는 것이다. 이런 경우 사실 면접 등으로 쉽게 알기는 힘들다. 주로 reference check 를 통해야만 알 수 있는 경우가 많다. 어쨌든 결론은, 개발자의 인성은 생산성에 큰 영향을 끼치기 때문에 채용 단계에서부터 주의해야 할 필요가 있다는 것이다.

기술의 변화 속도는 매우 빠르고, 그렇기 때문에 항상 오픈 마인드를 갖고 배우려는 자세를 가질 필요가 있다. 위에 예시로 든 병X의 경우에도 부디 자신의 모자람을 깨닫고 미래에는 역량과 매너를 갖춘 인성 좋은 개발자가 되기를 희망해본다.

keyword