출처 : https://okky.kr/articles/779785

 

OKKY - 악성 프로젝트, 그리고 그 사이의 개발자

코로나로 힘든 요즘 모두들 안녕하신지 모르겠습니다. 저는 좀 안녕하지 못합니다. 요 한 3~4주간 정말 힘들고 바쁘게 일했습니다.인생에 다시 없을 성장의 기회라 생각하고 열심히 임했죠.그러

okky.kr

 

 

본문
코로나로 힘든 요즘 모두들 안녕하신지 모르겠습니다.


저는 좀 안녕하지 못합니다.




요 한 3~4주간 정말 힘들고 바쁘게 일했습니다.

인생에 다시 없을 성장의 기회라 생각하고 열심히 임했죠.

그러나 이상과 현실은 달랐습니다.




제가 과거에 이런 글을 썼었습니다. SI의 프로젝트나 코드에 왜 흉흉한 괴담이 떠도는지요.

그때 회사가 프로젝트에 대해 산정한 시간이나 보수에 관한 철학에 하자가 있으면 프로젝트가 산으로 간다..

뭐 이런 글을 썼던 것으로 기억합니다.




이번에 정말, 마치 '그래서는 안될 케이스'에 교과서 예시로 실릴만한 프로젝트를 경험해 그 썰을 풀어볼까 싶습니다.

SI 프로젝트가 어째서 그토록 암울하고 어두운 풍문이 떠도는 도시전설같은 존재가 되는지.

바람직한 사원의 모습, 열정적인 신입의 모습이 아닌 잿빛 세상에 내던져진 사이버 노동자의 입장에서 글을 써보려고 합니다.




여러분은 지금, 성실하고 열정적으로 살고자 했던 신입사원이 현실에 물들어 영락해가는 모습을 보고 계십니다.

저를 비롯한 모든 개발자들이 앞으로는 이와 같은 힘든 일을 겪지 않기를...




1. '시간' 을 이유로 규범과 규칙이 무시된다.

소프트웨어를 개발하는데 있어 수 많은 규범과 규정, 그리고 어드바이스가 있죠.

하지만, 시쳇말로 '꼬롬한' SI 프로젝트에는 그런 것들이 고려되지 않습니다.

고려하기 싫어서 그러는 것은 아닙니다. '시간'이 없어서 그렇습니다.

그 '시간' 이 없다보니 일단 중구난방 코드를 짜게 됩니다.

우선 돌아가기만 하면 된다. 이런 마인드로 말이죠.

문제는 어떻게든 짠 그 코드가 영원히 올바른 동작을 보장할 수 없다는 겁니다.

언젠가는 뜻하지 않은 곳에서 문제가 생기고, 변화에 대응해야 할 때가 와요.

그런데 그런 이슈가 발생했을 때에는 시간에 여유가 있을거라 장담할 수 있을까요? 

...코드는 점점 괴물이 되어갑니다.




2. 개발을 쉬이 여기는 사람들이 주변에 산재해 있다.


케바케일거라고 생각합니다만, 괴물같은 코드와 지옥같은 일정을 가진 프로젝트는 

대부분 개발을 모르는 사람이 감독으로나, 고객으로나 꼭 있습니다.

개발을 모르는 것 자체는 문제가 되지 않습니다. 모를 수도 있죠.




진짜 문제는, 이 분들이 개발을 '앉아서 키보드질만 하는 것' 으로 여기면서 시작됩니다.

책상머리에 앉아서 키보드만 두들기면 원하는 바가 뚝딱! 나오는 편한 일쯤으로 생각한다는거에요.

개발이라는 일을 모르는 사람이 뒤에서 쳐다만 보고 있으면 그렇게 쉬워보일 수가 없나봐요.




이런 분들이 무언가 요구사항을 이야기 할 때 개발자가 시간이 10만큼 필요하다고 하면,

왜 금쪽같은 시간을 10이나 쓰려고하냐며 반문하고 따집니다. 자기가 봤을 때는 3정도만 있어도 될 것 같거든요.

이 사람들한테 개발은 그냥 타자연습이나 다름없고, 구글링 하는건 웹서핑으로 보여요. 

(네이버에서 검색하고 있으면 난리가 납니다. 근무시간에 웹서핑을 왜하냐고...)

개발자 입장에서 절대 납득할 수 없는 시간이지만, 철저히 을의 입장에 선 개발자는 할 수 있는 말이 그다지 많지 않습니다.

어떻게 어떻게 협상을 해서 한 5~7정도의 시간을 받아옵니다. 그럼 1번같은 상황이 발생하는거에요.




비하하는 것은 아니지만... 유독 나이가 좀 있으신 분들이 이런 경향이 강합니다.

내가 하는 일은 힘들고 고되지만, 남이 하는 일은 만사 편할 것 같다는 편견...




3. 돌이키기엔 너무나 멀리 와버린 것들이 많다.


말 그대로입니다. 지금 하는 작업이 처음부터 끝까지 새롭게 개발하는 것이 아니라면 이 부분이 크게 느껴집니다.

한 반년만 프로젝트가 진행되었어도, 바꾸고 싶은 것들 쉽게 못바꿉니다.

더 세련되고 빠른 로직, 더 깔끔한 표시 방식을 발견했어도 이미 DB 안에 들어가 있는 수많은 데이터를 당장 어찌할 수가 없기 때문입니다.

무언가 바꿔버렸을 때 이전에 올린 게시물이나 데이터들의 안정성을 보장할 수 없다는 문제가 있는 이상

위에서는 해당 부분을 바꾸기 꺼려할테고, 개발자 역시 시간도 없는데 확실하지 않은 일을 리스크를 떠안고 맡을 이유가 없습니다.

아직 우리나라에 구형 자바와 DB, 프레임워크가 많은 이유가 이것일 겁니다.





위의 1, 2, 3번 문제는 따로따로 발생하는것이 아니라 톱니처럼 맞물려 복합적으로 일어나는 사항입니다.

서로가 서로의 이유 및 핑계가 되면서 프로젝트를 점점 경직시키고, 결과적으로 괴물이 탄생하고 마는거죠.




프로젝트가 제 영역을 떠난 지금, 내 손으로 괴물을 만들고 말았다는 죄의식과 불안감에 시달리는 오후입니다...