SI가 코드레벨이 우수해야 되는 이유가 있습니다.

기간내에 끝내려면 코드레벨이 낮아서는 절대로 프로젝트 기간내에 끝나지 않습니다.

기간내에 프로젝트를 끝내려면 기획파악능력, 구조설계, 코드가독성이 우수해야합니다. 변수명 개똥같이 설정하면 클라이언트가 엿 먹는게 아닙니다. 개발하는 자기 스스로가 자기가 만든 변수명에 엿을 먹습니다. 폴더 구조 일관성이 없으면 자기 스스로 함정에 빠집니다.  걱정을 분산해야되고 자주 반복되는 로직은 추상화 시켜서 코드를 줄여야합니다.

그리고 기획적으로 명확하게 파악하면 그 모든게 코드에 들어나게 됩니다. 기획적으로 파악을 못하면 확장성이 떨어지는 변수명이 생기고  클라이언트 요구가 변경되면 그때는 기존에 만들어놓은 변수명이 발목을 잡습니다. 그렇게 어거지로 만들어진 이름으로 개발하다가 다시 하자보수가 들어오면 기존에 개발시간의 2배를 소비하죠.

실력이 부족하면 기획 파악 능력이 떨어지고 기획을 파악하지 못하면 기획적으로 희생해야 될 것과 살릴 것을 판단하지 못하고. 그렇게 스키마를 짜면 모든 것을 JOIN연산으로 데이터를 가져오게 됩니다. MongoDB를 MySql처럼 쓰는거죠. 

join연산이 나쁘냐? 아뇨 사실 교과서적이죠. 일관성 유지로 보면요. 그러나 꼭 일관성이 유지되지 않아야될 포인트를 결정을 하는건 기획적인 능력이고 이게 실무와 포폴의 차이이죠. 물론 신생기업이니 무차별 JOIN으로 가져와도 데이터가 얼마없으니 얼마나 느려지겠어? 라는 생각도 할 수 있으나 그러면 늘 고통받으면서 SI를 하게되는 겁니다. 프로젝트 하나 가지고 5년간 유지보수하면서  놀고 먹고 사는 분들도 있습니다. 

그리고 커머스같은 경우 로직을 분산하지 않으면 로직 하나가 천줄이 넘어가는 경우가 허다합니다. 보통 잘한다는 개발자는 타입스크립트같은 tool에 능숙한 개발자들이 아닙니다. 

우수한 개발자는 폴더 구조에서 상당한 context를 제공하게 만들어 놓습니다. 폴더만 한겹씩 까봐도 대충 그림이 그려지는거죠. 

천 줄짜리 로직을 신입이 그냥 쭉쭉 읽으면 바로 이해가 되게 만들어 놓는 분들을 저는 본적이 있습니다. 

함수명을 보고 주석을 처리하면 딱 그 기능만 제외될 정도로 모듈화를 시켜 놓는 개발자. 모든 프로젝트를 자기가 예전에 만든 코드를 복붙만해도 동작되도록 만드는 개발자들도 있습니다. 

SI를 하려면 코드레벨이 높아야합니다. 그것도 아주 많이 높아야해요. SI는 코드레벨이 낮으면 지옥행 열차를 타게되고 개발자를 그만 둘 확률이 아주 높습니다.

코드레벨이 높아지면 언어 장벽이 무너집니다. 처음에는 새로운 언어를 배우는 것이 어렵고 러닝커브가 아주 높습니다. 생각보다 이익이 없죠. 당장 새로운 언어로 돈 벌이가 되는게 아니라고 생각하죠. 그런데 코드레벨이 높아지면 언어를 제외한 모든 패턴들은 반복이 되고 패턴에 익숙해집니다. 그러면 언어만 갈아끼우면 언재든지 프로젝트를 진행할 수 있다는 자신감이 생기죠. 그러니 프로젝트의 선택폭도 아주 넓어집니다. 자바스크립트로 만든 서버를 그대로 파이썬으로 이식해도 손 쉽게 프로젝트를 끝냅니다. 하나의 언어를 끝내면 다른 언어가 쉽다는건 여기서 나오는 말입니다. 언어를 그냥 책을 보고 아는 것이 아니라 하나의 언어를 이용해서 극한의 코드레벨을 끌어내면 자연스럽게 다른 언어로도 그 코드레벨이 구현이 된다는 거죠. 언어 다양하게 알면 뭐해요. 코드레벨이 낮은데...-_- 

정말 SI는 극과극입니다.

지옥행이거나 천국행이거나 누구는 프리로 벤츠뽑고 사는가하면 누구는 프로젝트 위약금을 무니 마니 소송을 거니 마니 하는 게 SI 세상이죠. 

팀단위 SI는 리더의 능력에 따라서 프로젝트의 승패가 갈리고 보통 능력있는 분들은 사실 1억-2억 단위 프로젝트 혼자서 만들기 때문에 위시켓에서는 그런분들 보기도 힘들어요. 7억짜리 프로젝트 10년차 개발자 5명 붙어서 실패한 프로젝트 한명이 5달만에 끝내는게 SI세상입니다. 늘 프로젝트 예약이 꽉차있는 분들도 있어요. SI는 코드레벨 필요 없다는 이야기 들으면 엄청 웃을 겁니다.

근데 SI 실상이 어쩔수 없어요. 이런 천상계들은 만날수 없고 다양한 사람들이 모이는데 완전 복불복이죠.-_-;