by
Aug 06. 2019
개발자들이 마음을 아프게 하는 상황들...
그리고, 팀과 회사에 무책임한 행동과 태도를 너무 쉽게 한다.
우선 이 포스팅은 브런치 작가 #신현묵 님의 '개발자들의 마음을 아프게 하는 상황들...'
(https://brunch.co.kr/@supims/578utm_source=pf_brunch&utm_campaign=weekly#comment) 이라는 글을 오마쥬하였음을 밝힙니다.
신현묵 님이라는 분을 잘 알지 못하지만, 오늘 우연히 브런치 카톡 계정으로 해당 글이 푸시되어 보게 되었습니다. 그리고 조금 더 찾아보게 되었죠.
적도 많고 아군도 많은 분이시더군요. 적이 왜 많은지 알 것 같은 느낌적인 느낌이었고, 반대로 아군은 어떤 분들 인지도 어렵지 않게 알아챌 수 있었습니다.
이 글을 확인하기 이전에 '신현묵'님의 글을 먼저 봐주셨으면 좋겠네요. (창을 두 개 띄우고 함께 읽어보시는 게 가장 좋을 듯합니다.)
저는 전체 10여 년의 경력 중, 비개발자로 10여 년을 살았지만 지금까지 같이 일해본, 저를 거쳐간 (외주 합쳐서) 개발자만 백여 명은 되는 듯 하니, 개인으로서 의견을 내기에는 부족함이 없으리라 생각합니다. 특히 최근에 정말 좋지... 개발팀을 경험해본지라.
신현묵 님이 개발자로서 어떤 서비스를 경험했는지 궁금하네요. 깊게 찾아보지는 않아서. 모쪼록 개발자로서, 후배 개발자들을 이끄는 좋은 글만큼, 세상을 혁신할 좋은 서비스를 많이 보여주시길 바랍니다.
*다수의 선하고 맡은 바 업무에 최선을 다하는 엔지니어를 존중합니다. 다만, 개발자들만큼 비개발자들 역시 서비스와 제품을 위해 노력을 한다는 부분을 다수의 '비엔지니어' 입장에서 서술한 글입니다.
슬프게도 개발자들이 조직 내에 있는 비개발자들은 그런 말이나, 그런 상황이 빈번하게 노출된다.
그것은 그들이 '소프트웨어 개발'에 대해서만 생각하거나, 비개발자들과 같이 일을 하는 방법, 일을 처리하는 방법에 대해서는 정말 관심이 없는 경우에 이런 상황들은 빈번하게 일어난다.
그리고, 전체 업무에 피해를 줄 수 있는 무책임함과 행동들이 반복된다.
슬프게도, 개발자와 함께 일하는 비개발자들은 이런 행태(?)에 대해서 너무도 익숙하고, 그러려니 하면서 반응하고, 참다가... 한마디를 하거나, 징계와 해고 사이에서 갈등하는 행위를 반복하는 슬픈 상황들이 연출된다.
그렇다면, 개발자들이 비개발자를 얼마나 무시하는지에 대한 몇 가지 사례를 들어 보겠다.
첫째. "불가능합니다" "어렵습니다" "못합니다" 혹은 "오늘 안에 가능합니다."
조직의 상하 관계와 같은 문제가 아니라, 그 다음의 문장에서 비개발자들에게 비수를 던진다.
케이스. 비수 1
"**님 이거 수정하는데 얼마나 걸려요?"
(침묵) "못합니다"
콘텐츠 준비하고, 경영진과 중간다리 하는 것도 힘든데, '못한다''안된다' 이 한마디 던지고 자기들(개발자)들끼리 눈치만 보는데 여념이 없다.
비개발자들이 이런 대화에서 왜 기분이 나쁘고, 절망감을 느낄까?
그것은... 비개발자들은 개발을 모르고, 도와주고 싶어도 도울 수가 없고, 개발 외에 팀과 프로젝트를 지킬 무언가를 계속하여야 한다. 그런데 개발자는 비개발자가 잘 모른다는 이유로, 설명은 커녕 침묵으로 상황을 넘기려고만 한다.
그리고 결국 비개발자(실무자)들 기운 다 빠지게 한 후, "휴~그래 해줄게" 하는 태도로 진행. (왜 무조건 안된다고만 할까? 결국 할 거면서, 해야 되는 거 뻔히 알면서)
케이스. 비수 2
"**님 이 버그 잡는데 얼마나 걸려요?"
(초긍정) "네, 몇 시간이면 해요"
개발자가 된다는 말만 믿고, 이것저것 다 준비해놓았는데 말이 없길래 몇 시간 후 슬랙으로
"됐어요?" 물으면, 자리에 없음. (담배 태우러 감)
또 얼마 후 "얼마나 더 걸려요?" 물으면 (침묵...),
계속 기다리다가 못 참고 자리에 가보면 (퇴근...)
카톡 또는 슬랙으로 왜 말도 없이 갔냐고, 다 기다리고 있지 않냐고, 물어보면
"아~생각보다 시간이 오래 걸리네요. 약속이 있어서... 이따 집에 가서 할게요."
그 말만 믿고, 유관부서 팀원들은 한참을 기다리다가, 보다 못한 팀장이 한 명씩 퇴근시키고 결국 밤 12시 즈음 다시 연락하여 물어보면,
"어떻게 됐어요? 오픈할 수 있어요?"
(답 없음) (전화 안 받음)
그 다음 날, "**님 어떻게 전화도 안 받고..." 하면 "하다가 잠들었어요" 하면 그뿐.
"얼마나 더 걸려요?"
"오전까지 할게요."
결국 그날 퇴근시간이 넘어서야 다 됨.
이렇게 두 가지의 극단적 케이스를 몇 번 경험 하고, 몇 개월 지나면 보통 아래와 같은 상황으로 귀결됨.
- 개발자가 일하기 힘든 환경 (=개발자와 일하기 힘들다...)
- 개발자를 무시하는 발언, 폭언, 심야 연락, 잦은 야근 (=비개발자와 비지니스를 무시하는 발언, 무시, 잠수)
- 개발을 잘 모르는 조직에서 개발하기 힘들다는 푸념 (=그냥 개발팀 최소 인원만 놔두고, 정리하고 SI 돌릴까.)
- 팀장, 본부장의 폭언, 폭행에 시달렸다는 루머 낭설 (=폭행을 했으면 경찰서를 갈 것이고, 폭언을 했으면 넌 지금까지 버티고 이런 글을 쓰지도 못했을 거임.)
을 주변 동료와 자신의 SNS 혹은 구직 리뷰 사이트에 남기고 퇴사.
개발자들 커뮤니티에서 흔히 하는 장난(!) 어디까지가 장난일까?둘째. 저는 잘못한 게 없는데요. 저는 뭘 잘못했는지 모르겠는데요.
특히, 개발자가 한, 둘 밖에 없거나, 그래서 해결할 사람이 본인밖에 없다는 사실을 악용할 때 이런 사례가 많이 나온다. 특정 데이터가 맞지 않거나, 서비스 동작시에 오류가 발생하면서, 해당 문제를 해소하는 회의에서 개발자들은 앞뒤의 흐름, 데이터의 순서, 서비스의 우선순위 등을 모두 고려했다며 서비스에 대한 장애를 이야기하고, 비개발자는 특정 문제를 해소하기 위해서, 자신의 방법으로 데이터를 뽑고, 하루 종일 확인한 데이터를 기반으로 이야기를 하는데, 개발자는 뭘 모른다는 식으로 비개발자의 행동을 폄훼하는 경우에, 개발자는 짜증섞인 말투로 이런 말이 나오게 된다.
물론, 특정 상황에 따라 데이터나 서비스 동작에 문제가 있다면, 비개발자가 찾아낸 오류가 개발 영역에 대해 멋모르고 한 내용일 수도 있다. (사실 이 부분도, 관련 서비스 환경, 세팅, 값들의 비교, 주변 환경에 대한 변화는 차치하고 모니터 상에서 나온 결과값만 가지고 보면 말도 안 되는 이야기에 해당된다.)
그렇게 '문제'를 인지하고 인식하는 중요함을 제쳐두고, 그 상황을 회피하고, 다른 영향도와 서비스 운영을 핑계 대며 문제를 스스로 만드는 것을 개발자는 인지하지 못한다.
그냥, 내 잘못이 아니라는 식의 막연한 회피와 대응은 비개발자들이 극도로 혐오하는 방법이다.
셋째. 서비스와 조직은 모르면서, 개발자의 우선순위만 챙기는 경우
특히나, 개발 경험은 몇 년 되지도 않으면서 깝죽거리는 개발자나, 커뮤니티 활동 열심히 하면서, 아키텍처에 대한 설계 경험이나, 데이터 모델링에 대한 경험이 별로 없는, 서비스 구현체에 대한 내용들에 대해서 깊은 고민을 하지도 않았으면서, 비개발자 출신의 경영자나 관리자의 말에 부정적인 말만 늘어놓을 때에 비개발자는 절망한다.
고작 몇 년 되지도 않는 서비스 개발 경력과 개념으로, 몇 백/몇 천만 사용자 서비스를 만들어본 비개발자 출신 경영자나 관리자에게 현재의 API 중심의 메세지 구조나, 서비스 간의 연관관계, 데이터 모델과 보안 이슈가 있는 토큰의 발급 체계에 대한 이론, 데이터 모델까지 이야기하는 개발자의 이야기를 듣고 있는 비개발자 출신의 기획자나 관리자, 임원은 매우 고통스러운 시간을 보낸다.
더군다나, 그렇게 이야기하는 사람이 KOSA 기준 특급 기술자라면, 회사를 접고 서비스를 포기하고 싶을 만큼 비개발자는 괴로워할 것이다.
개발자라고 다 같은 개발자일까? 외주가 하는 구축은 쉽다. 운영(유지/보수)이 어렵다. 많은 비개발자들이 잘 모르는 사실. 진짜 개발자는 사내에 있는 개발자 1명이다.넷째. 본인이 구축했지만, 구축 후 발생되는 버그에 대해서는, 외주로 입장이 돌변하는 상황
버그이던, 신규 기능이던 이슈는 해결되어야 한다는 사실을 뻔히 인식하지만, 대부분의 복합적인 개발 이슈들은 그 서비스를 만든, 혹은 이어받은 개발자가 해결해야 합니다. 물론 팀장이 있고, PM이 있고, 해당 비지니스 흐름을 기획한 기획자들을 거쳐서 실무 담당자까지 문제를 공감하여야 하지만, 결국 시스템 문제의 해결은 개발자 몫입니다.
하지만, 그런 규칙이 있다고 하더라도, 서비스 러닝 중 일어나는 각종 버그와 에러는 비개발자들의 애간장을 태웁니다. 슬랙을 아무리 보내도, 개발 팀장에게 아무리 말을 해도, 이슈 프로세스가 계속 발생함에도 불구하고, 듣는 척만 척하는 경우, 자리로 찾아가 나라 잃은 것처럼 굽신거려야 겨우 대꾸하는 경우입니다.
서비스를 사용하는 유저는 작은 문제가 매우 불편하고 어렵다. 그리고 그 항의를 온전히 받아내는 건, 마케팅, CS 그리고 비개발자 중 일반 관리자다. (출처 : 신현묵님 블로그) 물론, 현재 진행하고 있는 개발도 중요하고, 담배 태울 시간도 필요하겠지만, 서비스의 완성도는 비지니스에 중요한 것이기 때문에, 작은 에러나 버그, 즉 품질에 대단히 민감합니다.
그래서, QA에서 미처 발견하지 못한 품질에 대해서 개발팀에서 최대한 끌어올리도록 언제나 최선을 다합니다.
하지만, 윗 선에서 내려오는 빈번한 기획 변경에도 불구하고, 회의에서는 별다른 대꾸나 질문도 없다가, 막상 서비스가 출시된 이후 발생되는 이슈에 대해서는 방관하고 현업 실무자를 탓하는 것을 비개발자들 스스로 알고 있습니다.
어떤 상황에서도 문제를 해결하려고 하지만, 비개발자들을 절망하게 하는 것은...
큰 문제를 작은 문제처럼 말하고, 이슈에 대해서 비난과 비슷한 핑계를 대고, 왜? 똑같은 버그가 또 생겼음에도 불구하고 아무런 (죄)의식이나 책임감을 감당하려고 하지 않습니다.
개발자가 개발자를 판단할 때까지 필요한 시간은? 팀 스스로 정제할 때까지 기다려 달라는 건, 다른 부서도 마찬가지일까? (출처 : 신현묵님 블로그)물론, 정말 문제 있는 기획자, 디자이너, 실무자라면 회사나 팀 내부에서 스스로 정제하여 내보냅니다.
그리고, 문제가 있는 개발 상황을, 비개발자는 개발팀에 말하지 않아도 되는 문제는 최대한 방어하려고 애쓰는 것이죠.
매번 오류가 발생하는 순간에도, 업무 중에 정해진 프로세스(개발 우선순위)를 지켜주며, 업무를 진행하는 비개발자들을 도와주어야지, 적인지 아군인지 모를 태도로 협조하지 않는 것은 전쟁 같은 서비스 환경에서 창과 방패를 들고 나서서 싸우는 비개발, 실무자들을 무시하는 처사입니다.
그리고, 마지막으로...
보통 개발자들과 일하는 비개발자들은 위에서 언급된 환경들이 점점 최악으로 달리고 있다고 하더라도, 각자의 임계치까지는 최대한 '성질'을 죽이고, '문제'를 해결하도록 기회를 줍니다.
그들이 아무 말 없이 '일'을 하는 것은...
개발자들의 태도나 모습에 공감해서 참고 있는 것이 아닙니다.
그냥, 그들의 변화를 기대해봐야, 문제 해결에 도움이 안 되기 때문입니다.
'문제'가 발생하면 서비스를 동작시켜야 하고, 회사를 지켜야 하기 때문에 최선을 다할 뿐이죠.
그리고, 임계치를 넘으면... 개발자들을 혼내거나, 개발자 교체를 건의하거나, 회사를 그만두게 됩니다.
좋은 비개발자들이 그렇게 해서 팀을 이탈한다는 것을 꼭 기억하시기 바랍니다.
(끝)
