- 개발을 잘 모르는 조직에서 개발하기 힘들다는 푸념 (=그냥 개발팀 최소 인원만 놔두고, 정리하고 SI 돌릴까.)
- 팀장, 본부장의 폭언, 폭행에 시달렸다는 루머 낭설 (=폭행을 했으면 경찰서를 갈 것이고, 폭언을 했으면 넌 지금까지 버티고 이런 글을 쓰지도 못했을 거임.)
을 주변 동료와 자신의 SNS 혹은 구직 리뷰 사이트에 남기고 퇴사.
개발자들 커뮤니티에서 흔히 하는 장난(!) 어디까지가 장난일까?
둘째. 저는 잘못한 게 없는데요. 저는 뭘 잘못했는지 모르겠는데요.
특히, 개발자가 한, 둘 밖에 없거나, 그래서 해결할 사람이 본인밖에 없다는 사실을 악용할 때 이런 사례가 많이 나온다. 특정 데이터가 맞지 않거나, 서비스 동작시에 오류가 발생하면서, 해당 문제를 해소하는 회의에서 개발자들은 앞뒤의 흐름, 데이터의 순서, 서비스의 우선순위 등을 모두 고려했다며 서비스에 대한 장애를 이야기하고, 비개발자는 특정 문제를 해소하기 위해서, 자신의 방법으로 데이터를 뽑고, 하루 종일 확인한 데이터를 기반으로 이야기를 하는데, 개발자는 뭘 모른다는 식으로 비개발자의 행동을 폄훼하는 경우에, 개발자는 짜증섞인 말투로 이런 말이 나오게 된다.
물론, 특정 상황에 따라 데이터나 서비스 동작에 문제가 있다면, 비개발자가 찾아낸 오류가 개발 영역에 대해 멋모르고 한 내용일 수도 있다. (사실 이 부분도, 관련 서비스 환경, 세팅, 값들의 비교, 주변 환경에 대한 변화는 차치하고 모니터 상에서 나온 결과값만 가지고 보면 말도 안 되는 이야기에 해당된다.)
그렇게 '문제'를 인지하고 인식하는 중요함을 제쳐두고, 그 상황을 회피하고, 다른 영향도와 서비스 운영을 핑계 대며 문제를 스스로 만드는 것을 개발자는 인지하지 못한다.
그냥, 내 잘못이 아니라는 식의 막연한 회피와 대응은 비개발자들이 극도로 혐오하는 방법이다.
셋째. 서비스와 조직은 모르면서, 개발자의 우선순위만 챙기는 경우
특히나, 개발 경험은 몇 년 되지도 않으면서 깝죽거리는 개발자나, 커뮤니티 활동 열심히 하면서, 아키텍처에 대한 설계 경험이나, 데이터 모델링에 대한 경험이 별로 없는, 서비스 구현체에 대한 내용들에 대해서 깊은 고민을 하지도 않았으면서, 비개발자 출신의 경영자나 관리자의 말에 부정적인 말만 늘어놓을 때에 비개발자는 절망한다.
고작 몇 년 되지도 않는 서비스 개발 경력과 개념으로, 몇 백/몇 천만 사용자 서비스를 만들어본 비개발자 출신 경영자나 관리자에게 현재의 API 중심의 메세지 구조나, 서비스 간의 연관관계, 데이터 모델과 보안 이슈가 있는 토큰의 발급 체계에 대한 이론, 데이터 모델까지 이야기하는 개발자의 이야기를 듣고 있는 비개발자 출신의 기획자나 관리자, 임원은 매우 고통스러운 시간을 보낸다.
더군다나, 그렇게 이야기하는 사람이 KOSA 기준 특급 기술자라면, 회사를 접고 서비스를 포기하고 싶을 만큼 비개발자는 괴로워할 것이다.
개발자라고 다 같은 개발자일까? 외주가 하는 구축은 쉽다. 운영(유지/보수)이 어렵다. 많은 비개발자들이 잘 모르는 사실. 진짜 개발자는 사내에 있는 개발자 1명이다.
넷째. 본인이 구축했지만, 구축 후 발생되는 버그에 대해서는, 외주로 입장이 돌변하는 상황
버그이던, 신규 기능이던 이슈는 해결되어야 한다는 사실을 뻔히 인식하지만, 대부분의 복합적인 개발 이슈들은 그 서비스를 만든, 혹은 이어받은 개발자가 해결해야 합니다. 물론 팀장이 있고, PM이 있고, 해당 비지니스 흐름을 기획한 기획자들을 거쳐서 실무 담당자까지 문제를 공감하여야 하지만, 결국 시스템 문제의 해결은 개발자 몫입니다.
하지만, 그런 규칙이 있다고 하더라도, 서비스 러닝 중 일어나는 각종 버그와 에러는 비개발자들의 애간장을 태웁니다. 슬랙을 아무리 보내도, 개발 팀장에게 아무리 말을 해도, 이슈 프로세스가 계속 발생함에도 불구하고, 듣는 척만 척하는 경우, 자리로 찾아가 나라 잃은 것처럼 굽신거려야 겨우 대꾸하는 경우입니다.
서비스를 사용하는 유저는 작은 문제가 매우 불편하고 어렵다. 그리고 그 항의를 온전히 받아내는 건, 마케팅, CS 그리고 비개발자 중 일반 관리자다. (출처 : 신현묵님 블로그)
물론, 현재 진행하고 있는 개발도 중요하고, 담배 태울 시간도 필요하겠지만, 서비스의 완성도는 비지니스에 중요한 것이기 때문에, 작은 에러나 버그, 즉 품질에 대단히 민감합니다.
그래서, QA에서 미처 발견하지 못한 품질에 대해서 개발팀에서 최대한 끌어올리도록 언제나 최선을 다합니다.
하지만, 윗 선에서 내려오는 빈번한 기획 변경에도 불구하고, 회의에서는 별다른 대꾸나 질문도 없다가, 막상 서비스가 출시된 이후 발생되는 이슈에 대해서는 방관하고 현업 실무자를 탓하는 것을 비개발자들 스스로 알고 있습니다.
어떤 상황에서도 문제를 해결하려고 하지만, 비개발자들을 절망하게 하는 것은...
큰 문제를 작은 문제처럼 말하고, 이슈에 대해서 비난과 비슷한 핑계를 대고, 왜? 똑같은 버그가 또 생겼음에도 불구하고 아무런 (죄)의식이나 책임감을 감당하려고 하지 않습니다.
개발자가 개발자를 판단할 때까지 필요한 시간은? 팀 스스로 정제할 때까지 기다려 달라는 건, 다른 부서도 마찬가지일까? (출처 : 신현묵님 블로그)
물론, 정말 문제 있는 기획자, 디자이너, 실무자라면 회사나 팀 내부에서 스스로 정제하여 내보냅니다.
그리고, 문제가 있는 개발 상황을, 비개발자는 개발팀에 말하지 않아도 되는 문제는 최대한 방어하려고 애쓰는 것이죠.
매번 오류가 발생하는 순간에도, 업무 중에 정해진 프로세스(개발 우선순위)를 지켜주며, 업무를 진행하는 비개발자들을 도와주어야지, 적인지 아군인지 모를 태도로 협조하지 않는 것은 전쟁 같은 서비스 환경에서 창과 방패를 들고 나서서 싸우는 비개발, 실무자들을 무시하는 처사입니다.
그리고, 마지막으로...
보통 개발자들과 일하는 비개발자들은 위에서 언급된 환경들이 점점 최악으로 달리고 있다고 하더라도, 각자의 임계치까지는 최대한 '성질'을 죽이고, '문제'를 해결하도록 기회를 줍니다.
그들이 아무 말 없이 '일'을 하는 것은...
개발자들의 태도나 모습에 공감해서 참고 있는 것이 아닙니다.
그냥, 그들의 변화를 기대해봐야, 문제 해결에 도움이 안 되기 때문입니다.
'문제'가 발생하면 서비스를 동작시켜야 하고, 회사를 지켜야 하기 때문에 최선을 다할 뿐이죠.
그리고, 임계치를 넘으면... 개발자들을 혼내거나, 개발자 교체를 건의하거나, 회사를 그만두게 됩니다.