Tag: SI

소프트웨어 트렌드의 변화 – SI to 알고리즘

SI의 시대에서 ~~~의 시대로 넘어오면서
(삑데이터, IOT, AI, 기타 솔루션, 모바일, 자체서비스 …)
알고리즘의 중요도가 더 높아진 것 같다.

기존 한국의 소프트웨어 산업은 영어의 원뜻과는 별 상관없는 것 같지만, SI라고 불리는 한 축을 중심으로 성장 해 왔다. 그리고 이 SI산업은 전통적인 여러 산업의 효율성을 증대시켜주고 2000년대 한국산업의 발전에 지대한 역할을 했다.
(개발자는 죽어났지만.. 거의 80년대 봉재노동자급… 중동 건설인부 = 일본캐나다 진출)
이 시기에는 시스템 성능을 높이기 위해서는 쿼리튜닝, 파일용량 낮추기, 네트워크와 컴퓨팅 파워 업그레이드가 더 중요했다. (자바-오라클의 시대)
개발 방법론도 효율적인 코딩보다 빠른 코딩이 대세였고… 그 흐름을 타고 순위권에 진입한 언어가 자바, 파이썬, 루비

SI의 업무분야는 대강 아래의 범주에 다 포함된다.
– 은행/카드/보험/증권 (차세대) 개발, 쇼핑몰, ERP연동, VOC
근데 이 산업군들은 이제 개발이 다 끝났다. 개선은 계속 이뤄지겠지만… 적어도 서비스를 구축하기에 급급하던 시절은 지났다.

근데.. 인터넷 왕폭발이 일어나고 10년쯤 지난 지금은? 좀 다르다.

이제 생각할 수 있는 것은 거의 다 만들어졌다.
이제는 ‘새로움’ 보다는 ‘나아짐’을 만드는 시대다.
서비스를 개선한다는 것은 비용을 낮추거나 사용편의성을 높이는 것일텐데…
같은 컴퓨팅 파워로 더 많은 일을 하려면 아키텍처/알고리즘의 개선.. 밖에 답이 없지 않을까?
– 서버1대 월 10만원에서 10%효율을 높이는 것은 쓸데없는 짓이지만… 1000대라면
기존에 운영되던 서비스들도 인터넷 인구가 늘면서 사용자가 많아지고 따라서 데이터양이 늘고.. 이로인해 기존에 겪어보지 못한 문제를 맞닥뜨리게 된다.

이런 배경에서 알고리즘의 중요성이 다시 대두되는 것 같다.

 

노가다 코딩의 시대의 종말

요즘은 뭘 해도 데이터가 많다. SI업무분야에 포함되는 업종들도 마찬가지…
예전엔 0.01ms의 차이가 별 것 아니었지만, 데이터양이 많아지다보니 이런 부분에서 더 큰 차이를 보인다.
라이브러리들도 많은 기능보다는 작고 빠른게 대세로 자리잡고 있다.
– PlayFramework, Flask와 같은 경량프레임워크의 약진
(그리고 라이브러리 뭐 있었는데 기억이 안난다)

 

이직 – 알고리즘

어느회사 이력서를 넣었다가 온라인 코딩테스트를 하길래…
ㅋ 뭐 얼마나 대단하길래? 라는 생각으로 1시간만에 하고 자야지~
하고 시작했다가.. 좌절을 맛봤다. 잠도 못자고…
그러고 나니 알고리즘에 대해 다시 생각을 해 보게 된다
… 되게 어려웠는데
이 회사 개발자가 몇명인데~ 여기 있는 다른개발자들은 이런문제 다 풀어내는건가?

취업 이후에는 계속 아키텍팅이나 구조분석/설계에만 집중을 했었는데…
시대가 변한 것 같으니 알고리즘도 공부를 해야하지 않을까 싶다.

책도 좋지만..
온라인 테스트 사이트가 다른사람하고 경쟁심도 생기고… 훈장도 받을 수 있고 하니 더 좋아보인다
다양한 언어를 지원 해 줘서 이미 풀었던 문제나 쉬운 문제를 새로 공부하는 언어로 다시 풀어보는 것도 도움이 될 것 같다.

 

사이트 목록은 여기서 퍼옴 http://ledgku.tistory.com/40

오일러 프로젝트

알고스팟

더블릿

코딜리티

https://codility.com/programmers

코드도장

탑코더

코드포스

해커랭크

 

협력업체의 엿먹활동

SI 하다보면 매우 비협조적인 사람을 만나게 된다.

그리고 이 사람이 내 밑이나 을의 위치가 아닌.. 대든 또는 갑의 위치라면 매우 힘들 수 있다는 것을 확실히 느끼고 있다.

 

쿼리, 코드 뭐가됐던 개발을 할 때 가장 중요한 것은 무엇일까?

이번에 확실히 느낀건데

 

일관성이 가장 중요하다.

 

네이밍이 이상할 수도 있고 오타가 심할수도 있지만.. 아 이걸 왜 이렇게 했어!!! 라고 하다가도 나도모르게 나도 똑같이 쓰고 있는 모습을 발견하게 된다.

 

이번에는… 진짜 강적이다

 

TOT, CP, PWD, HP, GBN, FL, NM, AMT, CUST

이런 줄임단어를 진짜 심각할 정도로 사용했다.
혹시 모를까봐 풀 단어를 써주면

TOTAL, COUPON, PASSWORD, HANDPHONE, GUBUN, FLAG, NAME, AMOUNT, CUSTOMER

 

글자수 제한이 있는것도 아니고 이거 줄인다고 별로 많이 줄어드는 상황도 아닌데 굳이 저걸 저렇게 줄여댄다.

그런데.. 그래도 저건 금방 익숙해졌다.

 

또 문제…

Data타입을 뽑을 때 개발자마다 자신의 특성이 있지 않나? 습관이라고 할까? 개인적으로 yyyy-MM-dd hh:mm:ss 형태를 선호한다.

사람에 따라서 yyyyMMdd 라던가 외국 물 먹은 사람은 dd/MM/yyyy형태도 쓰긴하는데 중요한 것은… 이사람들은 자신의 습관에 따라 한가지 형태를 지속적으로 사용한다는 것!!

이번에는 달랐다. 이걸 돌아가면서 쓴다….

심지어 디비에서 프로시저로 뽑아줄 때 start_date, end_date가 아닌 period라는 필드로 yyyyMMdd-yyyyMMdd 형태로 뽑아줬다.
그래… 그럴 수 있어 여기까지는

 

그럼 그 다음은

PROCEDURE_1(
INPUT_ID,
INPUT_NAME,
CURSOR
RESULT_CODE);



PROCEDURE_2(
INPUT_ID,
INPUT_NAME,
RESULT_CODE
CURSOR);

1번과 2번을 섞어서 사용한다.

미친놈 아닌가 이정도면

그러지말자

 

 

그래서 조상님들이 SI하지말라고 하셨나보다