생계형 개발자 SI에서 살아남기 by 연서은

[ 밑줄/연결 ]

 

 

40층 건물이 올라갔는데 옆으로 10cm만 옮겨주세요 라는 게 요구사항 변경입니다.

고객 입장에서는 고작 10cm이지만 옮기기 위해서는 기반 공사부터 다시 해야 합니다.

 

 

개발 이터레이션은 얼마나 빠른 주기로 코드를 개선할 것인가에 대한 논제입니다.

SI개발자는 이런 말을 신경 쓰지 않아도 됩니다. 코드를 개선하지 않으니까요.

만들고 나면 프로젝트는  끝입니다. 개선이라는 말은 SM에서나 존재하는 단어입니다.

 

 

애자일은 고객 만족을 목표로 하고 끊임없이 개선되는 SW를 가정하는데 이게 성공하려면 무제한 시간이 필요하다는 특징이 있습니다. 서비스 기업은 가능합니다. 이미 베타 버전으로 어떤 식으로든 돈을 벌고 있고 더 많은 돈을 벌기 위해 시스템을 개선해 나가야 하니까요. 즉 애자일은 프로그램의 라이프싸이클과 개발기간의 라이프싸이클이 동일할 때만 가능합니다.

 

SI에서 애자일이 성공할 수 없는 이유는 비용으로 환산되는 시간이 고정되어 있기 때문입니다.

SI에서 성공한 프로젝트라는 의미는 고객 만족이 아닙니다. 고객 만족도 중요하겠지만 정해진 시간 내에 기능 목록이 몇 % 이상 완성되었는지가 성공의 기준입니다. 서비스 기업과 SI는 서로 지향점 자체가 다릅니다. 따라서 방법도 다릅니다.

 

 

고도화 프로젝트의 경우 "뭘 하느냐?" 가 아니라 기존의 코드가 어떤 식으로 되어 있는지에 따라서 난이도가 결정됩니다.

어떤 프로젝트든 마찬가지지만 고도화는 특히 사람 + 기존 코드 콤보라고 생각하시면 됩니다.

 

SI에서 자료구조는 별로 쓸모있지 않아요.

SI에서 Primary type이나 기본적인 클래스 사용법을 제외한다면 자료구조는 딱 2개만 사용합니다.

바로 Map과 List입니다.

 

SI에서는 알고리즘을 짜는 것이 아닙니다. 작동되는 프로그램을 만드는 겁니다.

 

사실 SI에서 코딩이란 여러 모듈을 조립해서 새로운 기능을 완성하는 것에 가깝습니다.

다만 이 과정이 사람들이 생각하는 것만큼 간단하지는 않습니다. 

어떤 것이 어떤 기능을 하는지 알아야 하고, 그것들이 다 적절한 위치에 놓여야 하고, 어느 부분을 변경해야 하는지도 알아야 하거든요.

 

현업에서는 '퀴리가 전부다'라는 말을 많이 합니다.

데이터베이스 중심 프로그래밍이란 모든 비즈니스 로직이 데이터베이스에 녹아 있는 것을 말합니다.

 

 

시간이 없는데 수정할 사항이 많다면 야근을 넘어 철야를 할 수도 있으므로 개발자들은 "뭐든지 담을 수 있는 객첵"를 활용합니다. 대표적인 것이 Map과 List입니다.

 

SI에서 비즈니스는 퀴리에 있어야 합니다.

 

SI에서 일하는 사람들은 상대적으로 최신 트렌드에 둔감한 분들이 많습니다.

SI 자체가 안정적이고 검증된 기술만을 도입하기 때문입니다.

 

 

실무에서 개발해 보면, 사실 개발은 뭔가 굉장한 알고리즘을 짜는 일 보다는 각 컴포넌트 간의 조립이라는 것을 아실 겁니다. 예를 들어보면 컨트롤러에서 데이터를 받아서 서비스로 넘기고, 가공 없이 DAO로 전달하고, 퀴리를 실행한 다음 결과를 다시 뷰까지 전달하는 일련의 과정이죠.

 

각 기능을 개별적으로 만들고 퍼즐 조각은 어디든 낄 수 있는 레고처럼 만든 다음, 일단 끼워놓습니다.

그 다음 삐걱거리거나 이상한 부분이 있으면 그 부분만 수정하고 개발을 계속 진행하는 것이 요령입니다.

SI는 속도입니다.

 

SI 프로젝트에서 스프링으로 업무를 하는 경우 가장 많이 쓰이는 자료 구조는 데이터를 키:쌍으로 표현하는  Map입니다. Map<String, Object> 형태를 대부분 사용합니다.

 

SI에서는 절대로 추상화화면 안 됩니다.

추상화하는 건 결국 여러 기능을 한군데 합친 겁니다.

그런데 SI 현장에서는 추상화할 일보다 추상화된 기능을 분리해야 하는 일이 휠씬 더 많습니다.

 

프로젝트의 3 요소는 속도, 비용, 분량이라고 한다면  SI는 이 세가지를 다 이루어 냅니다.

 

SI개발자는 오래갈 프로그램을 만들지 않습니다.

프로젝트가 끝나면 나면 다시는 그 코드를 보지 않기 때문입니다.

 

프레임워크를 사용하는 이유는 프레임워크의 기능을 사용하기 위해서도 있지만 비슷한 코딩 스타일로 만들기 위한 이유도 있다는 점도 잊지 마세요

 

젠킨스는 빌드 툴입니다. 그럴듯한 용어로는  CI(Continuation Integration,지속적 통합)툴이라고 부릅니다.

보통 VCS(Version Control System, 버전관리 시스템,  svn 혹은 git 등)에서 소스 코드를 가져와서  maven build를 한 후 target server(스테이지 개발 운영....등)에 배포하고 서버를 재가동하는 것까지 자동화할 수 있습니다.

 

스프링 프레임워크는 웹 뿐만 아니라 콘솔 프로그램, 배치 프로그램 등을 만드는데도 쓰이는 범용 프레임워크입니다.

 

MyBatis는 XML로 RDBMS SQL를 관리해주는 라이브러리입니다.

 

스키마가 변경되면 프로그램 소스코드도 변경되어야 하지만, 안에 있는 데이터들도 새로운 스키마에 맞게 분산되거나 합쳐져야 하는 경우가 많습니다. 이런 작업을 데이터 마이그레이션이라고 합니다....

참고로 똑같은 스키마에 데이터를 옮기는 것은 마이그레이션이라고 하지 않고 덤프라고 부릅니다.

 

 

스타트업은 당장 일을 할 수 있는 사람이 필요합니다. 아무것도 모르는 사람을 키워서 쓰기에는 스타트업의 빠른 속도를 못  따라갑니다.

 

만약 회사가 자체 서비스를 제공하는 기업이라면, 기본기도 탄탄하고, 당장 일을 할 수 있어야 하며, 코딩 테스트 정도는 토오가를 할 수 있는 사람을 찾습니다.

 

퀴리 실력을 키워요

SI 개발 실력은 퀴리에서 거의 결정이 납니다. 데이터베이스 중심 개발을 하기 때문이지요.

그래서 퀴리를 잘 만드는 사람이 SI에서는 인정받습니다.

 

내가 조금 더 직급이 높다고, 나이가 많다고 갑질하고 명령 내리는 거 좋아하는 사람들 어디를 가도 꼭 있습니다.

그럴 때는 냉정하게 끊어주세요. 전쟁터에서 서로에게 몸을 맞기는 사이 아니잖아요. 서로의 이익을 위해 노동력을 투입하러 온 거니까요. 평생지기 죽마고우를 만드는 것도 좋습니다만, 그것도 사람봐 가면서 해야 합니다.

 

 

SI의 3대장은 사람들이 꺼리기로 유명한 곳들입니다.

구글에 조금만 확인해 보시면 나옵니다.

 

 

결국 SI도 사람이 사는 곳입니다. 때로는 치사하고 때로는 어처구니 없고 때로는 힘들지만, 결국은 우리의 생존을 위해서 가끔 즐거음을 느끼며 사는 곳입니다. 그저 일터로써의 SI 현장에 대해 바라만 주시고, 너무 나쁜 편견들이 있었다면 조그이나마 편견을 떨쳤으면 좋겠습니다.

 

 

 

[ 자평 ] 참 현실적으로 썼다...과장없고 포장없이...이렇게 써도 되나? 

 

내가 SI를 경험한 시대는 1999 ~ 2001년 이다.

요즈음  (2020년 시대) SI가 어떤 모습인지 솔직한 내용을 좀 읽고 싶었다.

저자는 2020년 현재 10년 정도 개발자로 일하고 있으신 분이라 한다. 적합하다.