[책 요약] IT 개발자의 거의 모든 것(1편), 개발자를 꿈꾸는/개발자로 일하는/개발자와 일하는 모든이를 위한 실용지침서

1. 개발자로 살아남기

 

회사에서 무엇보다 중요한 것이 PM의 역할이지만, 본인이 원해서 PM을 수행하는 개발자는 별로 없다. 그런 경우 프로젝트 수행 관리로 인한 스트레스 때문에 정작 자신이 좋아하던 기술은 연마하지 못한 채, 그저 시대에 뒤떨어진 관리자로 은퇴할 가능성이 높다.

 

개발을 수행할 때 자신이 그 일을 할 수 있는지 없는지는 고려 대상이 아니라는 사실도 알게 됐다. 또 자신이 개발에 책임을 질 수 없는 상황에는 충분히 문제제기를 해서 문제가 발생했을 때 책임져줄 누군가를 찾아 증거를 남겨놓는 것이 중요하다는 사실도 깨달았다.

 

하나의 거대한 장비에 들어가는 1,000개 이상의 소프트웨어 전체를 설계하고 개발자들에게 분배하며, 다른 소프트웨어 파트 책임급들과 연동을 맞추려면 그런 코딩을 할 시간이 없다고 했다. 결국 사람과 자원을 관리하는 업무로 자연스럽게 밀려났다는 얘기였다.

 

금융권이나 정부 프로젝트의 경우 소규모는 대략 4~6개월, 중간 규모는 6~10개월, 대형은 1년에서 1년 6개월 정도로 줄어들었는데, 경험에 기반한 주관이 많이 들어간 일정이긴 하지만 필자가 보기에 아주 무리한 일정은 아니다. 적당한 일정의 프로젝트라 하더라도 성패가 극명히 엇갈리는 이유는 무엇보다 수치화되지 못하는 개발자들의 역량 때문이다.

 

대부분의 관리자는 그 아래 세대의 개발자들에게 아무런 설명 없이 암묵적인 역할을 강요하는데, 그 이유는 앞서 신입사원의 사례에서 살펴본 바 있다. 이들은 짧은 개발 역사를 거쳐오는 동안 부족한 실력이나 모자란 자원을 시간이라는 자원으로 모두 대체해 왔는데, 그 사실을 자신이 젊은 시절에 가졌던 기술력으로 착각하기도 한다.

 

소프트웨어 개발자가 프로젝트를 성공적으로 수행하기 위해 가져야 할 능력

개발기술력

커뮤니케이션 능력 - 개발 일정을 고려하지 않고 적용된 수많은 요구 사항에 대해서는 개발자가 현업에게 논리적 반론을 제기해야만 한다

리더십 - 과업을 여유 있게 소화할 수 있어야 프로젝트에서 리더십을 발휘할 수 있다.

개방성

잉여성
- 최고의 품질을 위해서는 단순히 만드는 것 이상의 고급 노동력과 재화가 투입되는 게 당연한 법이다. 품질이 높아질수록 그 값어치는 올라가기 마련이다.
- 프로젝트에서 여유롭게 개발을 마무리한 개발자는 남는 시간에 휴식을 취하며 시간을 보낼 수 있다. 우리의 뇌는 컴퓨터처럼 작동하지 않기 때문에 자신이 작성한 프로그램이 완료되자마자 곧바로 고도화하고 버그를 찾아내 수정할 수 없다. 또 지쳐 있는 뇌는 지금 당장 문제가 발생하지 않으면, 깊숙한 곳에 숨어 있는 버그를 발견하고도 수정하지 말아야 하는 이유를 스스로 만들어낸다. 휴식시간 동안 충분히 여유를 취한 후에야 뇌는 비로소 이 버그가 근본적인 문제점을 가지고 있다고 느끼고, 모듈을 수정할 수 있는 잉여력을 발생시킨다. 이는 아주 탄탄한 개발물의 토대가 된다.

 

2. 프로젝트의 이해

 

WBS는 1950년대, 미 국방성에서 최초로 사용된 용어로, 원래는 작업물 기준의 일정 분류표인데 여기서는 자원 배분에 대한 내용으로 채워보도록 하겠다.

 

프로젝트는 백엔드 시스템의 양은 크게 고려하지 않고 난이도로 구분된 대략 500~600개 정도의 뷰(HTML)를 개발하는 양으로 산정된다. 사실 이런 식의 규모 산정은 업무의 난이도 측면에서 볼 때 매우 불합리한 분석 방법이라고 할 수 있다. 뷰가 몇 개 없고 백엔드 시스템의 복잡도가 높은 프로젝트의 경우 상대적으로 일거리가 적어 보일 수 있기 때문에 이런 분석단계에서 단순 뷰로 인력을 계산하게 되면 프로젝트의 위험도가 매우 높아질 수 있기 때문이다.

600개의 뷰를 기준으로 4개월의 개발 기간을 정했다면 개발자들의 뷰 개발 속도를 기준으로 프로젝트의 노동밀도를 산정해볼 수 있다. 매우 단순한 계산으로도 알 수 있는 사실이다.

 

오픈 일정이 얼마 남지 않았을 즈음에는 실 운영 요원들이 인수인계를 위해 프로젝트 룸에 투입되며 시간이 되는 개발자부터 구체적인 인수인계를 해주게 된다. 인수인계는 통상 한 달 이상 받아야 하지만 국내에서는 1~2주 만에 졸속으로 처리하는 경우가 흔하다.

 

프로젝트 리스크

기획리스크
그들이 보기에 아무리 받아들이기 힘든 화면 요소가 있다 하더라도 그 설계문서는 현업의 최종 도장이 찍힌 결과물이기에 이의를 제기하기는 어렵다.

기술리스크
기술적인 이슈들의 경우 프로젝트 팀원 가운데 해당 이슈를 해결할 수 있는 인원이 없으면 PM은 외부에 도움을 요청할 수밖에 없는데 그렇게 되면 일정 지연은 피할 수 없다. 외부에서 새로 지원된 인력은 프로젝트의 전반적인 과정을 모르기 때문에 재교육의 시간이 많이 필요하고, 그 인력도 해당 문제를 해결하지 못한다면 최악의 경우 프로젝트 자체가 중단될 수도 있다.

자원리스크
IT 지식이 부족한 영업팀이 프로젝트에 대한 분석을 선행하지 않은 채 실적을 위해 저가로 프로젝트를 무작정 수주하기 때문이다.

기타리스크
개발자능력 속임, 현업비협조, 망분리, 팀원불화, 퇴사 등

 

3. 프로그래밍 작업의 가치

 

사실 이 등급제는 2012년 11월 24일부터 폐지되었다. 따라서 효력도 없다. 하지만 정부 기관이나 일부 대형 사이트에서는 여전히 이 기준을 이용하여 급여 적용을 하고 있다. 물론 이 기준을 점차 사용하지 않는 추세이기는 하다.

 

프로젝트에 뛰어난 개발자가 없는 경우 야근과 철야로 점철된 프로젝트를 수행하게 된다. 그렇게 되면 무리한 프로젝트로 인해 피곤과 사투를 벌이게 되고 나아가 질병과도 싸우게 되는데, 이러한 상황은 자신의 기술을 제대로 연마할 수 없게 만들어 개발자를 악순환의 늪에 빠지게 한다.

 

4.IT업계의 사회병리학

 

보통 유지보수 작업은 하나의 완결된 프로젝트를 맡아서 새로운 추가 기능을 개발하거나 민감한 권한 이슈, 복잡한 데이터베이스 처리 등을 초반부터 도맡아 하기 때문에 중급 혹은 고급 개발자가 수행하거나 2명 이상의 인원이 투입되어 서로를 서포트하는 것이 원칙이다.

 

간단하게 생각해 보면 K의 죽음을 막을 수 있었던 방법은 대단히 많다. 본사의 적절한 기술지원, 서포트 개발자 한 명 추가 투입, 현업의 인간적인 대우와 합리적인 업무 일정 처리 등등. 하다못해 보수를 좀 더 많이 주는 방법이나 윗사람들의 다독임 약간으로도 젊은 개발자를 살릴 수 있었을 것이다.

 

악습

SW 노임단가제의 폐지

최저입찰제의 폐지

재하청금지
- 문제점으로 지적하는 것은 하청 받은 프로젝트를 그대로 재하청을 주고 수수료만 챙기는 관행을 말한다.

 

유지보수 인원들은 신규 기술의 접근성도 떨어지고 보수도 더 낮게 책정되기 때문에 근무 만족도가 매우 낮아 잦은 이직이 일어난다. 그렇게 시간이 지나다 보면 유지보수 팀원들은 경력이 적거나 기술력이 낮은 개발자로 교체되는 경우가 많아지고, 자연히 유지보수팀의 입김이 줄어들면서 유지보수의 중요도를 경시하는 문화가 자리 잡게 된다.

평상시 별 문제가 없다 해도 낮은 신기술 접근성, 뛰어난 개발자와의 협업 기회 결여 등 상대적인 박탈감을 느끼기 쉬운 보직이기도 하다. 따라서 적절한 성과정책으로 유지보수 인원의 이직을 막아야 할 것이다.

 

디지털전환, 빅데이터, 챗GPT 등에 따라 IT의 중요성이 거의 모든 회사의 성패를 가르고 있다.
그러나 IT개발자의 어려움은 현재진행형인 듯하다.
현업의 개발요건보다 실제개발에서 고려할 사항은 훨씬 많을 수밖에 없다.
결국은 책임져줄 누군가를 찾아 증거를 남겨놓는 일이 중요하다는 얘기...!

2023.07.04 - [독서 공부] - [책 요약] IT 개발자의 거의 모든 것(2편)

[책 요약] IT 개발자의 거의 모든 것(2편), 개발자를 꿈꾸는/개발자로 일하는/개발자와 일하는 모