야근에 대한 단상 몇 가지..
요즘 느끼는 상황으로는 야근 문제가 수익구조만의 문제가 아니라고 뼈저리게 느끼는 지라.. 함 써봅니다.
1. 일이 꼬였으니 고객에게 "우리 열심히하고 있어요"라는 쑈 하기
아 ㅅㅂ.. 지금 프로젝트 상황이 꼬였습니다.
업무량 예측이 잘못되었든, 설계가 잘못되었든, PM/PL이 무능했든, 개발자가 무능했었든간에 결국 의도했던 진도대로 못 나갑니다.
진도가 안나가는 것에 대해 갑은 열받아있고...
PM은 실제 일이되든 말든간에 "최대한 열심히 한다"라고 쑈를 합니다.
-------> 야근, 밤샘, 주말출근 쇼하기
2. 검증되지도 않은 최신기술 애호
경쟁사보다 기술적으로 우월하다는 이미지를 보여서 프로젝트를 수주해내야 합니다. 영업맨들은 신기술 사용 드립을 쳐서 프로젝트를 따냅니다...(이런 문제는 영업사람들 뿐만 아니라 개발자들도 걍 자기가 배워보고 싶은 욕심에 신기술을 사용하려는 모습으로부터도 나타납니다.)
실제 프로젝트 시작되고 나면 그 신기술이나 프레임워크, 서드파티 제품의 사용이나 특성, 장단점에 대해 알고서 기능구조를 설계하거나 개발계획을 세우는 개발자가 별로 없습니다.
결국 초급 인력들이 와서 배워가며 합니다.... 고객사의 프로젝트는 학습을 위한 실습용 프로젝트로 변질되고 시행오차가 일어나면서 작업 진도는 안 나갑니다.
역시 1번의 상황으로 GOTO....
3. 개념도, 자존심도 없는 (특히 초급)개발자들의 개발새발 코드
꼭 그렇다고 말하긴 좀 어폐도 있습니다만.. 김대중 정부시절 대량 생산된 6개월 프로그래머들..
(물론 저도 그 중의 일부이긴 합니다만)프로그래밍에 대한 애착이나 자존심이 없다고 해야 할라나요..
충분한 시간을 줘도 후딱 끝내고서 일 다했다고 채팅하고 놉니다. 실제 소스코드를 열어보면... 이 인간이 아무생각 없어서 그런건지... 귀챠니즘인지 시스템 전체 흐름이나 관련 소스파일들에 대해 살펴보지도 않고 걍 땜빵코딩 해놨습니다.
** "걍 내가 만드는 기능만 동작하면 됐지"라는 강짜근성으로 아무데나 "else if"절을 추가시켜버립니다.(그리고 자기는 코드 재활용을 극도로 자알 활용한 유능한 인간이라고 흐뭇해합니다.)
다른 개발자들은 저 멀리 안드로메다에 전혀 예상치 못한 else if가 있으리라고는 꿈에도 생각 못하고 계속 작업을 합니다.
** 같이 공통으로 사용해야 하는 환경변수나 라이브러리도 안쓰고 그냥 문자열로 입력시키거나 자기 개(犬)성을 한껏 발휘한 독창적 코딩을 해놓습니다.
시스템 변경 사항이 생겼을때 다른 모두들은 공용라이브러리나 환경변수값을 바꾸면 될 것이라고 생각하지만.. 현실은 시스템 곳곳에 플라스틱 지뢰들이 널려있습니다. 지뢰는 터질때까지 모르기 때문에 지뢰죠..
** 전체적인 업무흐름을 파악하고나서 그 흐름에 맞춰서 biz 로직을 만드는 게 아니라 걍 자기 맘대로 바이패스 루틴을 만들어버립니다. 지 딴에는 일일히 프로그램 짜는 거 없이 기존 루틴만 타는걸로 업무를 끝낸 우수한 생산성의 개발자라고 자부심 쩔지만.. 그런 바이패스가 있을 줄 다른 개발자들은 전혀 모른채 계속 시스템을 구축해나갑니다.
** 등등등..
----> 먹튀 개발자들이 빠지고나면 나머지 사람들이나 후임자들이 고스란히 지뢰들에 당할 수 밖에..
시스템 장애로 열받은 고객은 펄펄 뛰고 상황수습하느라 호출받은 사람들은 버그를 찾아내느라 피똥을 쌉니다.
버그를 찾아내고 나서도 절망... 전체 로직흐름과 전혀 다른 개념으로 구현된 로직... 아예 새로만들어야 하나?
일단 급한대로 땜빵... 상황수습하고 난 사람들은 문서화나 근본적 수습은 커녕 고객에게 욕 얻어먹느라 상처받은 몸과 마음을 풀고싶은 생각뿐입니다. 역시 1번 상황으로 GOTO
이런 인간들 하는 소리가 "아 소스코드 열어보면 몰라?"
개 젖가튼 쉐리들... 도데체 간단한 정보 하나를 찾아내기 위해서 자기가 만든 소스파일 몇개를 성지순례시키는게 당연한걸로 압니다. 이런 인간들은 자기가 만들어놓은 소스를 성지순례해야 하는 다른 사람들의 업무시간을 강탈하고 있다는 개념이 없습니다. 개쉐리..
4. 걍 돈 벌리는 곳으로 고고하는 개발자들
암 생각 없음. 기능 구현에 대한 의식같은 거 없고 그냥 만들고 나면 돈 많이 주는데로만 따라감..
극단적인 예로는... F**x UI 개발자들이 서버측 프로그래밍이나 DB프로그래밍에 대한 지식이 전혀 없는.....
아름답고 멋지고 강력한 기능을 갖춘 UI를 빠른 시간내에 개발할 수 있다고 하지만 정작 투입시켜놓고 나니 "난 DB같은 거 몰라.. 그런거 하는 사람 아냐. SQL만들어줘.. 배째"
-----> 최근에 본 가장 리얼한 코메디 상황이었습니다.
결국 기능 화면 하나를 개발하기 위해서 예전엔 1사람만 투입하면 되었던게.. 지금은 2명 투입해야 합니다!!! 이런 쉬트.. 똥.. 강아지.. 조ㅈ... 기타등등 같은 상황이~!! 1명 투입하면 되던 것이 2명 투입되고 있습니당당당... 1명 UI개발, 1명 서버측 개발.. UI화면 하나 개발하느라 둘이서 머리 맞대고 회의해야 합니다. 그리고.. 그리고 이따음 둘이서 다투기도 합니다. 젭라..
역시 1번 상황으로 GOTO
이런 거 외 기타등등... 기능 구현하면서 예외사항 같은거는 생각안하고 우다다다 프로그램 짜 놓거나...
개발자들 혹사당하는 문제가 물론 갑을병정식의 수익구조에도 있지만
그건 문제를 발생시키는 원인의 한 부분일 뿐이라고 요즘 뼈저리게 느끼고 있어서요.
근본적으로는 "잘 설계되고 잘 최적화된 프로그램"을 양산해내는 개발자를 객관적으로 판단해낼 방법이 사실상 전무하다는게 모든 문제의 시발입니다.
특히 3번같은 먹튀 개발자들이 지뢰 심어놓고 나가면, 나머지 사람들이 아무리 유능하다고 해도.. 프로그램 구현을 위해 사용되었어야 할 man-month가... 원래 의도했던 인력을 사용치못하고 버그원인 찾아내기 위한 단순노동이나 난감한 코드 뒷처리하느라 업무시간을 소진하게 되죠. 결국 그 사람들조차도 자신에게 할당되었던 업무 시간이 고갈되어 버리니까 남은 시간에 빨리빨리 기능 구현이나 해 놓아야하는 상황을 강요받게 됩니다.
이쯤되면 외부에서 고객사(즉 갑)가 보기엔... 개발자들 걍 그넘이 그넘이고 도데체 얼마를 주는게 적절한 개발비인지도 기준이 안나오니... 차라리 좀 더 싸게 부르는 걸 선택하는게 (쬐끔이라도)합리적인 선택이 되는 아스트랄한 상황까지도 경험해봤습니다.
