brunch

브런치북 스타트업 종사자를 위한 다섯번째글 23화

라이킷 156 댓글 27

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 신현묵 Jul 19. 2019

개발자들의 마음을 아프게하는 상황들...

그리고, 가슴에 비수를 던지는 말을 너무 쉽게 한다.

슬프게도 비개발자들 조직 내에 있는 개발자들에게 그런 말이나, 그런 상황이 너무 쉽게 노출된다.

그것은 그들이 ‘소프트웨어 개발'에 대한 환상만 가지고 있거나, 개발자들과 같이 일을 하는 방법, 일을 처리하는 방법에 대해서는 정말 관심이 없는 경우이 이런 상황들은 빈번하게 일어난다.

그리고, 업무 중에 비수가 되는 단어나 문장, 행동들이 반복된다.

슬프게도,개발자들은 비개발자들의 이런 행태(?)에 대해서 너무도 익숙하고, 그러려니 하면서 반응하고, 참다가... 조용하게 회사를 떠나거나, 다른 일자리를 알아보는 행위를 반복되는 슬픈 상황들이 연출된다.

그렇다면, 비개발자들이 개발자들을 얼마나 무시하는지에 대한 몇 가지 사례를 들어 보겠다.

첫째. 이 앱 하고 똑같은 것 개발해줘.

지적재산권과 같은 문제가 아니라, 그다음의 문장에서 개발자들에게 비수를 던진다.

'남이 만든 것이니, 금방 만들 수 있겠지?'

똑같이 베끼는 것도 자존심이 상하는데, 남이 만든 것을 동일하게 만들면, 더 빠르고, 더 쉽게 만들 것이라고 착각하면서, 개발자들을 무시하는 단어들을 남발한다.

개발자들이 이런 대화에서 왜 기분이 나쁘고, 무시당한다고 느낄까?

그것은... 개발자들은 무언가를 창조하고 싶어 하고, 무언가를 개선하고 싶어 하고, 무언가 자신의 생각을 투영하여 소프트웨어를 만들고 싶어 한다.

그런데, 이런 개발자들의 마음이나 열정을 모두 무시한 상황에서, 복제하라는 이야기를 하면서, 기존의 앱을 만들던 사람들, 그리고. 동일한 기능을 동일하게 구현하는 것에 대해서 개발자들의 능력을 폄훼하는 이런 말들을 들으면, 개발자들은 화가 나기 보다, 체념을 하게 된다.

둘째. 내가 하면 5분이면 하겠다.

특히, SQL을 좀 다루거나, 지적 전문직 종사자들에게서 이런 이야기가 많이 나온다. 특정 데이터가 맞지 않거나, 서비스 동작시에 오류가 발생하면서, 해당 문제를 해소하는 회의에서 개발자들은 앞뒤의 흐름, 데이터의 순서, 서비스의 우선순위 등을 모두 고려하여 최선을 다해서 서비스에 대한 장애에 대한 이야기를 하고 있는데, 비개발자가 특정 문제를 해소하기 위해서, 자신의 방법으로 데이터를 뽑고, 눈으로 확인하는데 5분이면 된다는 식으로 개발자의 행동을 폄훼하는 경우에 이런 말이 나오게 된다.

물론, 특정 상황에 맞춰서 데이터에 SQL문을 던져서, 나온 데이터를 확인하는 것이 전부라면 그 시간대가 맞을지도 모른다. ( 사실, 이 부분도 관련 서비스 환경, 세팅, 값들의 비교, 주변 환경에 대한 변화까지 모두 고려한다면 말도 안 되는 이야기에 해당된다. )

그렇게 '문제'있다고 인지한다는 것이 중요한 것이 아니라, 그 상황을 만든 서비스를 훑어봐야 하고, 다른 영향도와 서비스의 상황들을 고려하여 문제를 찾아야 한다는 것을 비개발자는 인지 못한다.

그냥, 그 문제는 그 상황에 있을 것이라는 막연한 접근방법은 개발자들이 극도로 혐오하는 방법이다.

셋째. 개발에 대해서 잘 모르면서, 개발자의 우선순위에 관여하는 경우

특히나, 과거에 개발을 좀 해본 기획자이거나, 경영자들이 이런 접근을 심하게 시도하면서, 아키텍처에 대한 관여나, 데이터 모델링에 대해서 이야기를 하고, 서비스 구현체에 대한 내용들에 대해서 자신의 방법이 옮다고 개발자들에게 일장 연설을 늘어놓을 때에 개발자는 절망한다.

10년 전에 홈페이지 개발하는 정도의 수준의 개발 개념으로 현재의 API중심의 메시지 구조나, 서비스 간의 연관관계, 데이터 모델과 보안 이슈가 있는 토큰의 발급체계에 대한 개념도 없으면서, 데이터 모델까지 이야기하는 비개발자의 이야기를 듣고 있는 개발자들은 매우 고통스러운 시간을 보낸다.

더군다나, 그렇게 이야기하는 사람이 직급이 높은 사람이라면, 그 회사를 도망가고 싶을 정도로 개발자는 괴로워할 것이다.

넷째. 개발팀을 콜센터로 착각하는 상황

버그이던, 신규 기능이던 이슈는 해결되어야 하지만, 대부분의 문제들은 복합적이기 때문에 개발자들 내부에서 교통정리가 필요합니다. 그래서, 팀장이 있고, PM이 있고, 해당 비즈니스 흐름을 기획한 기획자들을 거쳐서 실무담당자까지 조절되어야 합니다.

하지만, 그런 규칙이 있다고 하더라고, 현업 담당자가 급하다고... 업무 담당자에게 직접 슬랙 메시지를 날리는 것은 작은 규모의 서비스이거나, 중간 단계가 없던 때의 프로세스인데, 이슈 프로세스가 있음에도 불구하고, 해당 담당자에게 메시지 날리고, 자리로 찾아와서 '문제'에 대해서 따지는 경우입니다.

물론, 장애나 버그는 굉장히 민감한 문제이고, 서비스의 완성도는 비즈니스에 중요한 것이기 때문에, 개발자들인 그 품질에 대단히 민감합니다.

그래서, 소프트웨어 품질을 최대한 끌어올리도록 언제나 최선을 다합니다.

하지만, 빈번한 기획 변경, 품질 떨어지는 기획서, 현업의 업무 이해도의 낮음 등이 뒤섞인 상태에서, 서비스의 이슈가 발생했을 때에 모든 짐과 고난을 개발자들은 짊어지게 되는 것을 개발자들 스스로 알고 있습니다.

어떤 상황에서도 문제를 해결하려고 하지만, 개발자들을 절망하게 하는 것은...

작은 문제도 크게 호도하고, 이슈에 대해서 비난과 비슷한 단어들을 사용하고, 왜? 똑같은 버그가 또 생겼는지에 대해서 항의를 합니다.

물론. 정말 문제 있는 개발자라면, 개발팀 내부에서 스스로 정제하여 내보냅니다.

그리고, 문제가 있는 서비스와 기존 시스템들을 최대한 방어하려고 애쓰는 것이죠.

업무 중에 정해진 프로세스가 아닌, 콜센터의 응답기처럼 개발자들이 DevOps환경에서 이슈를 순차적으로 처리할 수 있도록 도와주어야지, 콜센터처럼 마구잡이로 직접 이슈를 제기하는 것은 개발자를 무시하는 처사입니다.

그리고, 마지막으로...

보통 개발자들은 위에서 언급된 환경들이 점점 최악으로 달리고 있다고 하더라도, 각자의 임계치까지는 최대한으로 '성질'을 죽이고, '문제'를 잡으려고 애를 씁니다.

그들이 아무 말 없이 '일'을 하는 것은...