김동성개발자
2021-02-03 05:02:32 작성 2021-02-03 14:11:58 수정됨
22
8080

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 실상이 어쩔수 없어요. 이런 천상계들은 만날수 없고 다양한 사람들이 모이는데 완전 복불복이죠.-_-;




28
16
  • 댓글 22

  • 바벨매니아
    276
    2021-02-03 07:42:27

    SI업계에 있는 사람으로서 극 공감이 되네요.

  • gredo
    844
    2021-02-03 09:17:29

    좋은 내용이네요.

    "함수명을 보고 주석을 처리하면 딱 그 기능만 제외될 정도로 모듈화를 시켜 놓는 개발자." 저도 그렇게 되고 싶네요 ㅎㅎ

  • 인사동
    2021-02-03 09:37:44

    SI에 국한되는 내용은 아닌거 같네요

    그런 잘하시는 분들이 구글도 가고 트위터도 가고 하는거죠

  • 천사와악마
    2k
    2021-02-03 10:10:54

    균형 맞추는게 참 어렵습니다

    코드품질에 비중을 두면 납품 시기가 촉박해지고

    납기에만 포커싱을 맞추면 코드는 본문처럼 변경요청에 유연하지못해 누더기가 되버리고

    -1
  • 방황하는젊은이
    1k
    2021-02-03 11:12:59

    공감합니다. 지옥행 열차를 탔습니다.

  • youngyoung
    2k
    2021-02-03 12:35:31

    그런데 말입니다

    PM은 항상 팀원들을 전원 우수상태로 보고 스케쥴을 잡더란 말입니다 ㅠㅠ

  • setPayPeriod
    1k
    2021-02-03 12:40:37

    일정은 필수 품질은 양심

  • qskm
    265
    2021-02-03 13:12:15

     SI만 그런게 아니라 개발의 대부분이 그렇습니다

  • 허허
    1k
    2021-02-03 13:30:57

    공감합니다.

    좋은글 감사해요


    근데 전 요즘 지옥행이 시작 될때 탈출하네요 ㅎㅎㅎㅎ

  • crazygun22
    858
    2021-02-03 16:12:47 작성 2021-02-03 16:13:22 수정됨

    SI 가 지옥행이 되지 않으려면 

    SI 도 코딩 테스트 도입 해서 개발자 가려 뽑아야 합니다.


    그렇지 않는 이상,  SI 지옥은 영원할 것입니다.

  • 도롱뇽
    2021-02-03 16:20:35

    날림으로 해서 결과만 나오면 되도록 개발하는 사람을 기준으로


    공수가 선정되기 때문에 절대로 불가능 할듯 합니다 ㅜㅜ 

  • 김똘똘
    257
    2021-02-03 16:30:41
    이상과 현실의 괴리는 큽니다
    SI는 일정과 공수가 돈인데 품질보단 아웃풋위주로 돌아간지 오래입니다
  • 최심바
    363
    2021-02-03 19:24:19

    상당히 좋은 글이네요. 공감합니다.


    SI는 지금까지의 악습(관습?)으로 인해 시간이 넉넉치 않은게 대부분 이죠.

    하지만 시간이 없다고 해서 코드 복붙에만 충실하고 가독성이나 유지보수성 생각 안하고 짰다가는,

    그 리스크는 곧 자기 자신에게 부메랑이 되어 돌아옵니다.


    요구사항이 엄청 많이, 그리고 크게 바뀌잖아요? 그 때 마다 시간이 배로 소요됩니다.

    잘 정리되지 않은 코드는 테스트 케이스가 많아지고 테스트 자체도 어려워지기 때문에 품질이 확 떨어지죠.

    애당초 요구사항이 최초 기획한 버전에서 하나도 바뀌지 않는 프로젝트는 세상에 존재하지 않아요.

    사람은 완벽하지 않고 더 좋은 품질의 프로덕트를 원하기 때문입니다. 아주 당연한 이치에요.

    잘못이 있다면 필연적으로 변경될 요구사항을 고려하지 않고 기간을 산정한 사람들 이지요.

    결국 SI에서 조금이라도 시간을 벌려면 코드 신경써서 잘 짜야 합니다.


    이 말은 즉, 우수한 코드레벨을 위한 기본기를 갖추게 되면 상당히 유리해 진다는 겁니다.

    동일한 시간이 주어진다 하더라도,

    누구는 유지보수에 엄청 불리한 코드를 짜서 구현과 테스트에 급급한 반면,

    누구는 요구사항이 바뀌어도 사이드 이펙트를 최소한으로 해서 효율적으로 개발할 수 있는 코드를 짤 수 있는 것이지요.

    이 둘의 차이는 엄청납니다. 경험해본 사람들은 그 차이를 확실히 알아요.

    IT업계에서의 대우도 완전히 극과 극 입니다. 코딩테스트 결과물이나 면접을 보면, 어떻게 개발해왔는지 다 나옵니다.

  • 지붕뚫고높이차
    1k
    2021-02-03 20:31:58

    와. 아주 많이 공감되는 글이네요.

    잘 보고 갑니다.

  • 기획출신아키텍트
    516
    2021-02-04 02:00:32
    시궁창 청소를 걸레로 하냐 방수차로 하냐 차이.
  • 체리콜라
    47
    2021-02-04 17:13:24

    그렇다면 그렇게 코드 수준이 높은 개발자를 SI 업체에서 어떻게 증명하고 가려 뽑느냐 그 인력은 대체 어디서 구해야되냐 참 어렵죠...애초에 SI 사업구조를 첫단추부터 잘못 끼운것이 아닐런지요.

  • 에르딘트
    3k
    2021-02-04 17:59:53 작성 2021-02-04 18:00:41 수정됨

    와~ 맞는 말씀입니다...

    새로운 곳 들어왔는데 vue 도 모르는 사람이 환경, 공통잡고 백엔드 개발자한테 vue로 프론트 개발시켜서 작업해놓았음 ㅜㅜ 


    전에 있던 개발자들...

    소스에 퀄리티는 1도 없이 다 복붙 하다가 다 도망감... 초급이건 특급이건 상관없이 모두 개판임... 다 복붙이라 이거 왜그러냐 물어보면 모른다함... ㅎ

    처음 시작할 때 들어와서 개발했으면 어렵지 않게 갈 수 있는 걸... 남들이 만들어놓은 똥치우고 있느라 짜증이 나네요 ㅜㅜ

  • 보후리
    716
    2021-02-05 13:59:02

    명확하게 파악해야할 그 기획이 계속 바뀌면 어떻게해야하죠.. ㅠ

  • 마라토집착
    5k
    2021-02-06 10:50:26

    업무를 잘아는 개발자가 기획자를 압도 하고 리딩 하면 됩니다  제가 은행여신 업무만 20년인데 저같은 시람이 기획자랑 미팅하면 제가 더 업무를 잘아니 제가 리딩 하니 

    어떻게 바뀔지 잘 알고 있습니다 

    업무경험많고 플젝 기술셑에 고수인 개발자가 필요합니다

    Si 는 

  • 하두
    12k
    2021-02-06 12:40:27

    단순함은 그냥 얻어지지 않습니다.

  • 꽃중년보넥스
    -1k
    2021-02-07 17:19:50

    공감합니다^^

    수백배의 생산성차이를

    지금 관리자꼰대들이 자기 인생동안

    이해할 수나 있을까요? ㅎㅎ

    -3
  • 가자가즈아
    2k
    2021-02-08 13:00:19

    우리나라 SI는 대부분 복붙의 연장인것 같습니다..

    SI를 가나 SM을 가나 소스 뒤져보면 글자 토시하나 안바꾸고 복붙한것도 많더군요..


  • 로그인을 하시면 댓글을 등록할 수 있습니다.