단기 프로젝트

울 회사는 조직개편을 너무 자주 한다.

단기 프로젝트가 많이 때문이다.

대게의 프로젝트가 3개월이고 조금 길면 6개월.

1년 짜리 프로젝트도 몇개 보긴 했는 데..

아무튼 그건 매우 이례적인 일이다.

인터넷 서비스 업계가 시장이 민감해서 그렇게 단기간 프로젝트만 한다지만 너무하다는 생각도 든다.

말로는 앞서가는 업체가 되겠다고 하지만 실상을 보면 대부분 베끼기 밖에 안한다.

경쟁 회사에서 만드니까 우리도 같이 만들어보는 거다.

뭐 항상 남이 안한 것만 할 수도 없긴 하지만, 이런식으로 단기 프로젝트로만 구성하다 보니 문제가 많다.

 

단기 프로젝트라고 해서 조금 만만하게 보는 점도 있다.

사람들도 고급인력이 될 수가 없다. 항상 단기간에 끝내는 일만 하니까.

거기다가 프로젝트 준비를 위한 기간이 프로젝트 중에 많은 부분을 차지하게 된다.

장기 프로젝트라면 setting에 공을 들을 수 있는 데.

단기로 몰아치면 팀 setting할 시간도 적고 그러면서도 이미 시간을 또 많이 까먹는 다.

빨리 끝내야 한다는 압박 때문에 시간 경쟁에만 신경을 쓰고 다른 곳은 별로 신경 쓰지 않는 것 같다.

제품의 품질이라던지, 나중에 성공했을 때 장기 운용시에 문제라던지,

버그 트래킹이나 문서화 같은 것들 말이다.

작은 프로젝트니까 대충 만들어서 얼른 팔아먹고 망하면 버리고 성공하면 그 때 생각해 보겠다는 거다.

하지만 문제는 성공한 후에 그 동안 미뤄뒀던 문제들을 쉽게 해결하기 어렵다는 데 있다.

잘 돌고 있는 시스템에 칼을 데기는 쉽지 않으니까. 문제가 크게 부각 될 때까지 한 줄도 건드리지 못하게 된다.

모든 부분이 모두 뒤죽박죽이라 프로젝트 후 팀이 분리되어 버리면 아무도 손을 델 수가 없다.

사소한 문제라도 혼자서 해결할 수 없고 프로젝트에 참가한 모든 사람이 모여야 한다.

관리가 잘 되었다면 한, 두명이서 해결 할 수 있을 문제를 40~60명의 인원이 48시간동안 컴퓨터 앞에서 대기해야

하기도 한다.

처음부터 시스템을 잘 디자인하고 모듈화 했으면 관리도 쉬울 텐데.

간단한 프로젝트라고 항상 생각하기 때문에 모든게 섞여 있다.

이 업계가 대부분 그런 것 같다. cyworld가 느린 것도 지금 그런 문제로 보이고

울 회사도 마찬가지 인 듯하다.

refactoring시 risk를 감당할 정도로 큰 문제가 부각되어 시스템이 아주 망해가야 그 때서야 사람들의

설득이 가능하고 뒤집어 엎을 수가 있게 된다.

하지만 그 때 고객들은 이미 site를 떠난다.

한 시간만 site가 다운되도 정말 몇 억씩 손해를 본다.

관리가 어렵다고 하지만 몇 억이 드는 일은 아니다.

회사에서 인센티브 몇 백만원씩 직원들에게 더 주면서 살살 꼬셔서 소프트웨어 엔지니어링에 조금 더

신경쓰게만 해도 잘 될 것 같아보이기도 한다.

(시스템 한 시간 다운되서 손해보느니 인센티브 좀 더 주는 게 낫지 않은 가?)

뭐 돈 만 먹고 모두 배째 버릴 수도 있는 데..

(에.. 팀장님들 중에서도 이런 것들 때문에 고민하는 듯..)

 

그렇다고 크게 데여보면 느끼고 다음부터 반성하느냐 하면 그렇지도 않은 것 같다.

성공과 실패에서도 배우지 못하는 사람들은 어떻게 해야 할 지 모르겠다.

 

시장과 기술. 물론 engineer는 기술을 더 생각해야 하지만 울 회사는 기술을 너무 생각하지 않는 것

같아 보이기도 한다. 시장이 너무 빨리 변해서 기술로 관리가 안된다고 포기해 버리는 것 같다.

분명히 둘 다 잡을 수 있을 것 같아보이는 데...

(아직 신입이라 이런 생각 쉽게 하는 걸까?)

-------------------------

그리고 작은 프로젝트만 많이 하니까 자꾸 반복된다는 느낌이 든다.

팀웍 다지고, coding convention 다시 맞추고, 서버 setting하고 source repository 구성하고,

wiki page나 spec문서 만들고, 정리 문서 만들고.

장기 프로젝트라면 이런 것 한 번 잘 해두면 두고두고 쓸 수 있는 데.

너무 짧으니까 익숙해질만 하면 팀 구성이 다시 된다.

그래서 너무 자주 바뀌니까 아예 귀찮아서 관리 안하는 것 같다.

coding convention도 대충 쓰고, 서버도 남는 거 모아다가 쓰고 부족하면 그 때 서야 ls, ps 명령 100번 쯤

치면서 빈 서버 찾고, spec문서도 안 만들고 구두나 메신져로 이야기하고 끝낸다.

 

@ 또 문제를 너무 과장되게 말한 건 아닌지 모르겠군..

    뭐 그리고 회사 기밀을 드러낸 것도 아니라고 본다;;(업계의 관행이라 다들 아는 사실일 뿐)