SI에 가면 무슨 일이 일어날까?

 

세상 절대 다수의 회사는 중소기업이고 대부분의 직장인은 중소기업에 다니고

한국 대부분의 IT 회사는 SI라는 것은 그냥 객관적인 사실이다.

 

취업을 할 땐 다들 자체 서비스를 꿈 꾸지만, SI에 가게 될 확률이 높다.

그럼 SI에 가면 어떤 일이 벌어질까?

오늘은 신입 개발자가 SI에 들어가면 겪을 수 있는 일에 대해 간략히 얘기해보려 한다.

 

SI 프로젝트의 환장스러운 점 중 하나는 바로 요구사항변경무제한제공참말사건이다.

 

문서나 산출물은 워터폴인데 요구사항 변경만 아주 지입맛대로 애자일 섞어찌개다.

소프트웨어 공학에서 워터폴이라든가 애자일이라든가 하는 말을 들어본 적이 있을 것이다.

다 일리 있는 말이고 근거 있는 방법론이겠지.

 

하지만 현실 세계에서 아름답게 워터폴이 가능할까?

요구사항과 기획이 처음부터 완벽할 수 없기 때문에 개발을 하다가 설계나 디자인이 바뀌는 일이 안 생길 수가 없다.

개발하다 의문이 생길 수도 있는 거고 논리적인 허점을 뒤에 발견할 수도 있는 것... 사람이 하는 일이니 당연하다...

 

어쨌든 갑을관계 속 워터폴은 마감 기한이라는 게 분명히 존재한다. 그리고 마감 기한은 늘어날 일은 없다.

(기한이 늘어나면 그건 그것대로 비상사태...일지도)

 

개발 완료 기한을 얼마 안 남기고 촉박하게 개발을 거의 완료하고 있는 그 시점.

 

당연히 WBS 같은 건 지키려고 만드는 문서가 아니고, 견적도 그야, 당연히 거짓말이다.

흔히들 뻥튀기라고 하는데... 뻥튀기 시켜서 파견을 보내지 않더라도,

견적서 상으로 인원수를 더 높게 잡는 비일비재하다. (아니, 안 그런 곳이 없지 않을까)

실무자는 죄다 주니어, 신입이며 견적서 상으로는 몇 개월의 분량이지만 실제로는 한 달 미만의 개발 기간을 가지고 오직 돌아가는 것을 목표로 개발한다. 어떻게든-주말과 밤을 희생하여-마감을 맞춘다. 그럼 이제 우리는 행복해질 수 있는 것일까?

 

그렇지 않다. 예를 들어...

갑자기 디자인이 바뀐다.

 

디자인이요???

여기서 좀 더 정상적인 SI라면 사내에 디자이너가 있다거나 UIUX팀이 있다거나 해서 최소한 디자인이 개발자한테 디자인이 바뀌었다고 알려주기라도 할테지만 작은 SI는 개발자 외의 직무는 모두 사치라는 듯 아무것도 두지 않기에,

UIUX고 디자인이고 다른 회사에서 주는데,

대충 협업툴에 잠수함 패치를 한다.

 

피그마 등의 협업툴은 실시간으로 내용이 변경되어, 문서를 이메일로 주고받고 수동으로 버전업을 하는 더럽게 비효율적인 방식보다는 낫지만

단점은 이전 버전 내용이 안 남아 증거를 남길 수도 없다는 것이다. (두둥...)

 

그럼 고객사에서 검수를 할때는 디자인 가이드를 보고 한다.

 

갑자기 개뜬금없이 느닷없이 한 n시간 전 쯤 버튼이 추가되고 색깔이 바뀌고 무슨 헤더 세로 길이가 변경되고 메뉴 순서가 변경되어도 

다 반영을 해주어야 한다. 안 하면 내 탓.

 

이 세상엔 이런 책도 있지만, 안 된다고 말할 수 있는 개발자는 그래도 행복한 개발자이다. 나에게는 판타지 소설같다.

내가 책을 낸다면...

 <오늘도 PM이 된다고 말했다>

 

왜 다 된다고 하는 것이지?

 

자, 그러면 UIUX나 디자이너도 없는 회사에 퍼블리셔가 있을까? 당연히 없다.

헉..그럼 당연히 프론트엔드가 퍼블리싱까지 하는건가? 라고 생각할 수도 있는게 그것도 아니다.

퍼블리싱은 외주다.

그럼 할 일이 줄어드니 좋은거 아닌가? 라고 생각한다면 오산이다.

css-in-js라든가 tailwind-css같은 신기술이란 게 있겠어요.

얄짤없이 전역 CSS다!!!! (하다못해 scss였다면..)

 

여러 의문과 혼란과 함께 한 일정 속에서 운영/유지보수/개발을 멀티태스킹으로 하고

당연히 물리적으로 코드리뷰-해 줄 사람도 없다-도 불가능하니 크로스체크도 불가능하고

후에 장애가 생겨도 그것은 나의 업보가 되며

고통과 절망이 끝이 없다.

SI에서는 아직까지 JSP + 제이쿼리가 인기가 많지만, VUE 를 쓰기도 한다.

리액트보단 뷰가 인기다.

난 리액트도 뷰도 다 좋은 라이브러리/프레임워크라고 생각한다. (리액트를 더 좋아하지만 뷰는 어떻게보면 합리적이다.)

하지만 SI에서 VUE 를 사랑하는 까닭은 

이전 레거시에서의 퍼블리셔-퍼블리싱처럼....

다만 html와 css 를 복붙하기 위해서일지도 모른다.

 

퍼블리싱에 붙어있는 제이쿼리를 보면 "왜"라는 생각을 자주 하게 된다.

처음엔 제이쿼리를 모두 걷어내야 한다고 생각했다.

재사용 하기 좋게 컴포넌트도 모두 분리하고.

 

하지만 그러면 결국 나만 힘들다.

그러한 프로젝트들은 그냥 컴포넌트의 재사용이고 나발이고 

제이쿼리를 설치해서 그대로 써야 정신건강에 이로울 것이다.

그러면 기술적 성장이나 성취는 없겠지만,

 

개발자이기 이전에 직장인이며

포괄임금제의 직장인인데

그냥 대충 하고 이직을 위한 공부를 하자.