좋은 개발자와 좋은 직장인은 크게 다르지 않다는 생각

최근에 같이 일하기 싫지 않은 개발자라는 글을 봤다.

 

https://brunch.co.kr/@kaily/40

같이 일하고 싶지 않은 개발자 특

 

글이 올라오고 한바탕 떠들썩했는데, 개인적으로는 뭐 그러려니 했다...

구현이 불가능한데 로직 정의도 정확히 못한다면서 디자이너나 기획자의 역량이 부족하다며 탓을 하거나

은근슬쩍 개발이 가장 전문적인 직무인 것처럼 행동하는 안하무인 자아과다 개발자들이 한둘이 아니었다.

그러니 기획자라고 못할 일이 뭐 있겠는가...(동의한다는 뜻은 아님)

 

 

디자이너나 기획자가 왜 개발을 알아야 하는가

작년만 해도 그런 책들이 유행했다.

'오늘도 개발자가 안 된다고 말했다'나 '비전공자를 위한 이해할 수 있는 IT 지식' 같은 것 말이다.

디자이너들이 개발을 아는 게 물론 나쁜 일은 아니다. 당연하지만 그 반대의 경우도 동일하다.

인접 직군에 대한 지식을 가지고 있으면 타 직군의 관점에서 상황을 파악할 수 있으므로 커뮤니케이션에 큰 도움이 된다.

이는 물론 비즈니스에 긍정적인 효과를 가져다 준다.

 

그러나 그런 책이 마치 하나의 교양이고 필독서인 것처럼 유행하는 것은 이상했다.

타 직군에 대한 정보를 그들이 스스로 습득하여 이해하려고 한다는 것은 마치 비위를 맞춰주기 위한 행동처럼 여겨졌기 때문이다.

 

나는 개발자와 디자이너, 그리고 기획자가 추구하는 '좋은 제품'에 대한 인식이 완전한 교집합을 이룬다고는 생각하지 않는다.

또한 그렇게 되기를 기대해서도 안된다고 생각하고 있다.

 

개발자는 좋은 소프트웨어를 고민해야 한다. 종종 예외도 있지만(스타트업 MVP나 기능 프로토타입 등) 대개 유지보수성이나 직관성, 성능을 포함한 여러 요소가 관심사가 된다.

소프트웨어의 품질이 고객과 직관되는 것처럼 보이지는 않지만, 잘 짜여진 코드는 새로운 기능이나 확장이 편리하고, 니즈를 쉽고 빠르게 충족하기 위한 환경으로 자리잡아준다.

 

반면 디자이너나 기획자는 미관적인 디자인과 편리한 UI/UX 등으로 사용자에게 편리함을 느끼게 해준다.

서비스 자체를 매력적인 것으로 자리매김하는데 기여하고, 사용자가 진정으로 필요로 하는 것들을 고민하고, 해결방법을 찾는다.

그들이 제안하는 어떤 기능은 별 것도 아닌 주제에 공수가 과다할 수도, 어떤 것들은 제공할 가치가 없게 보일 수도 있다.

그렇다면 기획자라면, 혹은 디자이너라면 당연하게 그런 것들을 인식하고 있어야 하는가?

반대로 그 사람들이 그런 내용을 모르는 것은 역량의 부족이라고 봐야할까?

 

기획자와 디자이너들은 '개발자들은 매번 잘 모르겠는 이유로 안 된다고 한다' 라며 그들만의 단어를 이해하기 위한 도서를 읽는다. API가 뭔지, 캐싱이 뭔지, 프론트는 뭐고 백엔드는 뭔지 하며 말이다. 그들은 커뮤니케이션 면에서 무능하며 개선할 여지조차 느끼지 않는 거만한 개발자를 위해 학습을 병행하려 한다.

 

 

 

 

 

 

 

우리는 팀이다

때때로 이런 경우도 있다.

효율을 빌미로 개발자들을 기획으로부터 완전히 분리하려는 프로세스를 추구하는 회사들이 몇 번 봐왔다.

기획 단에서 개발팀이 소외되면 그들은 기능의 필요성을 놓쳐 스스로 가치 없는 일을 하고 있다고 느끼기도 하고, 이해할 수 없는 기능을 만들기도 한다. 프로덕트가 발전하는 과정에서 그들은 마치 생산직과 같은 역할을 요구받는다.

 

통계나 데이터를 제공하거나 도메인에 대한 지식이 부족한 기획자나 디자이너가 만든 프로세스에 오류가 있을 수도 있다.

그게 아니더라도 개발 단계에서 밝혀질 수 있는 기획 오류는 전무하지 않다.

기획이 무결하지 않고, 개발이 생산직으로 전락할 때 분개하는 개발자가 있다.

일정은 밀릴 대로 밀려 이제 만들지 않으면 안 되는(혹은 이미 한창 만드는) 상황에서 페이지나 구조를 바꾸거나 엎어야 한다는 결론이 나오는 경우가 솔찬해서다.

 

개발이 참여하지 않은 회의와 기획이 바탕이 되어서 생긴 오류들은 마치 기획자나 디자이너의 역량이 부족한 것처럼 치부되고, 그들은 결국 개발의 관점을 이해하기 위해 그들의 직무가 아닌 것들을 배워야 하는 입장에 놓인다.

또 이 과정에서 생기는 갈등은 대개 무익하다. 시너지를 떨어뜨리고 협력과 점점 멀어지게 된다.

 

개발자가 그들의 인사이트를 제공하는 것만으로도 생길 수 있는 많은 문제들을 사전에 협의할 수 있다.

일방적인 일정 산출과 업무 하달에 대부분의 개발자가 오너십을 잃고 불만을 가지는데 왜 시스템은 그들을 서비스의 구상으로부터 점점 멀어지게 하려는 걸까?

 

 

 

 

 

불친절한 협업은 개발자의 역량 부족이다

만일 그들이 "왜 안 되는 건데요?" 라고 묻는다면 대부분 설명하기가 까다롭다. 또 별반 도움도 안 된다.

"말씀해주신 UI 레퍼런스는 프론트엔드에서 인증 처리를 전담할 때 가능한 구조인데 저희는 지금 세션 방식으로 처리 중이라 프론트엔드에서 해당 값을 확인하려면 이런 방식으로 구조를 바꿔야 하는데 그러면 로그인 이후에 이슈가 생기거든요..." 라거나,

 

"지금 메뉴 구조 같은 경우에는 셀프 조인으로 구성된 형태라서 기획서에 있는 방식으로 하려면 전반적인 구조에 문제가 생기고 메뉴와 엮인 api들도 전반적으로 변경을 해줘야 하거든요..." 같은 말을 하느니,

 

"말씀해주신 UI는 로그인 이후에 개발 측에 이런 이슈가 생겨서 바로 적용하기 어려운 사항이에요. 이 문제의 핵심은 로그인 이후의 메인 페이지에서 생기는 문제예요. 만약에 메인 페이지에 있는 이 탭을 조금 조정하거나 로그인 할 때 이런 식으로 우회해보는 것은 안 될까요?" 나,

 

"메뉴 구조도의 변경은 이렇게까지는 큰 문제가 없는데, 여기서부터 공수가 많이 발생하는 지점이라 말씀해주신 일정에 맞추기엔 조금 빡빡할 수 있을 것 같아요. 하지만 이런 방식으로 접근한다면 큰 문제가 되지 않아요." 라고 하는 편이 오히려 낫다.

 

'왜 안 됩니다'라고 항변하는 것보다도 '이것 때문에 문제가 생깁니다' 라고 말하는 편이 낫다는 것이다.

디자이너와 기획자에게 필요한 것이 그것이기 때문이다. 그럼에도 불구하고 이 기능이 제공하는 임팩트가 크므로 구현을 부탁할 기준과, 만일 이 경우가 불가능하다면 이를 어떻게 해결할 지를 판단할 근거 말이다.

 

기획자나 디자이너의 관점은 우리와 다르고, 그들이 추구하는 내용 또한 다르다.

또한 그들이 개발자와 동일한 관점으로 움직이는 것은 안 좋은 상황이다.

그들은 엔지니어들이 아니라 고객을 위해 움직이는 사람들이기 때문이다.

단순히 "그건 기존 설계에 없는 데이터라서 못 들어가요." 라고 단정하는 것은 고객을 위한 소프트웨어를 만드는 개발자의 태도가 아니다. 자기 눈에 예쁘면 그만인 코드를 근신하며 방망이 깎듯 다듬겠다고 선언하는 것과 다름없다.

 

문제를 해결하는 것이 고객과 더 나은 서비스를 위한 행동이고, 그건 개발자가 해야하는 일이다.

자꾸만 기획자에게 뭔가 물어보게 된다면 왜 본인이 그러는지 고민해야 하고, 불가능한 기획사항을 살리기 위해서 어떻게 접근해야 할 지 고민하고, 그들이 모르는 사항을 설명하기 위해 생각하는 것도 개발자의 직무이다.

 

개발자가 있는 것은 코드를 쓰기 위해서보다도 더 나은 서비스를 만들기 위해서라는 사실을 잊어선 안 된다.

 

 

 

더 나은 서비스를 위해 일해야 한다

나는 서론에 첨부한 글이 건설적인 관점에서 작성되었다고 보지 않는다. 그들의 직무와는 전혀 연관이 없다.

 

최악인 인간은 어디서든 있다. 스트레스를 주고, 효율을 떨어뜨리고, 거만하게 행동하기도, 일을 방해하기도 한다.

어떤 사람들은 큼직큼직한 문제들을 터뜨려서 수습도 전에 식은땀부터 나게 만들기도 한다.

그러나 그들이 폭탄을 터뜨리든 남 머리를 쥐어뜯든 "멍청이! 또 시작이네!" 하며 방관자의 입장이 되는 건 훌륭하지 못한 태도다.

다시 말하자면, 방해가 되고 문제가 될 수 있는 여지를 개인의 탓으로 밀어넣은 뒤 내버려두는 것은 옳지 못한 처사다.

 

그들이 만일 악의를 가지고 있는 게 아니라면(이 경우에는 적법한 절차에 따라 어떻게 처리할 지를 생각하는 게 나으리라) 어떻게 이런 일을 방지하거나 해결할 지 생각해야 한다.

 

이미 문서에 명시되어 있음에도 자꾸만 물어보는 직원이 있다면 기획서에 어떤 내용들이 명시되었는지 설명하고 해당 내용들을 찾는데 어려움이 있었는지를 알아내야 한다. 그들에게 사용되는 리소스가 적지 않다고 밝히며 어떤 점이 어려움을 겪게 만들었다면 다음과 같이 해결해보겠다고 이야기할 수 있어야 한다.

 

홀로 개발하는 직원이 있다면 리뷰 주기를 짧게 잡거나 사전에 명확하게 이런 점은 문제가 된다고 지적해야 하며,

동의하지 못하므로 개발을 진행할 수 없다는 직원에게는 판단 근거를 열거하고 논리적인 사유가 없다면 변경이 어렵다고 말할 수 있어야 한다.

 

모든 동료가 괄목할 정도로 뛰어난 사람일 수는 없다.

그들이 일으키는 문제를 대놓고 방치하고 험담하며 즐길 거리로만 소비할 수도 있다.

그러나 이것은 책임감이 부족한 것과는 별개로 더 편하게 일할 수 있는 기회를 놓치고 있다고 봐도 무방하다.

변한다면 기꺼이 더 협력적이고, 똑똑하고, 친절한 동료가 될 테고, 아니라고 해도 결국 원점일 것이다.

그들이 더 나은 동료가 될 수 있는 기회를 한번쯤 제공해도 나쁘지 않다.