Yeong Ki: 7월 2016

2016년 7월 23일 토요일

[키워드 조사] 2016.07.24

사람들은 내가 만드는것에서 `주제` 에 관심이 있을까?

SVN을 서버에 설치 후 소스 공개 - Jenkins이용

Jenkis - 이용가능한 지속 통합(CI : Continuous Intergration)

http://www.moreagile.net/2013/01/jenkins-cicontinuous-integration-1.html

https://en.wikipedia.org/wiki/Jenkins_(software)

젠킨스가 제공하는 기능은 다음과 같다.

미려한 웹 인터페이스를 통한 간편한 설정
강력하고 편리한 레포팅 기능
지속적인 자동화 빌드
지속적인 자동화 테스트
커버리지 감시
코드 품질 감시
다양한 인증기반과 결합한 인증 및 권한관리 기능
Groovy script를 이용한 고수준의 잡 스케줄링 기능
커맨드라인 인터페이스 제공
자동화된 배포 관리
분산빌드 기능
윈도우 커맨드 스케줄링 실행기능

배포파일 Java Web Archive(.war), 자바가 동작하는 환경이라면 어디든지 동작가능

Humble Object와 XunitPattern

Thread Safe

Groovy를 선택한 이유

멀티스레드에서 레이스 컨디션에 대해 설명

그루비와 멀티스레드를 이용해서 엘리버이터 병목 개선 알고리즘을 즉석으로 짜보기
(테스트 코드도 함께)

Spring에 대한 장단점, 이념
Spring 최신버전의 로드맵, IoC, DI등등

Java 객체지향언어의 특성, 컬렉션, GC알고리즘

Angularjs 왜 Angular인지, 장단점, 단점의 해결방책, $scope의 오염에 대해

WebScoket의 프로토콜 설명, 스팩을 HTML5에 맞게 개발하였는지

Nodejs, socket.io의 활용여부

-----

Q. nodejs의 단점
A. 콜벡지옥. 콜벡이 중첩되면 나중에 콜벡안에 콜벡안에 콜벡안에.... 이런식이였음.
Q. 그 단점을 해결하거나 고민해봤나?
A. 처음엔 콜벡을 최소화하기 위해 콜백이 3단계 이상 넘어가는 경우 사용하지 않았음.
그러다보니 node의 장점을 활용하기 힘들어짐. 고민이후 Promise Pattern을 적용해보니
콜백을 1단계 정도로 유지할 수 있었음.

가장 중요한건 '자신감' 그리고 힘든 환경속에서도 유쾌하게 일을 한다는 마인드

---------

Domain Knowledge

[직업 조사] Solution

Solution

▣ 솔루션 개념

솔루션(Solution)은 비즈니스 또는 고객의 문제점을 해결할 수 있는 제품이나 서비스와 같은 조합을 가리킨다. 사용자가 하드웨어, 소프트웨어, 서비스, 제조사, 운영체제 등과 같은 사항을 일일이 파악하는 어려움 없이 문제를 해결 할 수 있게 해 준다. 소프트웨어 패키지나 응용 프로그램과 연계된 문제들을 처리해 주는 하드웨어나 소프트웨어이다.

<웹진 150호: 공학 트렌드> SI와 솔루션 개발의 차이 - 아키텍처 편

불과 얼마 전까지만 해도 소프트웨어는 기관이나 기업에서 필요에 의해 만들어지는 경우가 대부분이었다. 컨설팅이 고객에게 시스템의 필요성을 전달하고 고객은 필요한 예산을 확보한 후 SI(System Integration) 프로젝트로 이어지는 흐름이었다. 하지만 최근에는 어느 정도 구축이 완료된 상태인 ICT의 투자 필요성이 많이 줄어들었고 오픈 플랫폼, 클라우드와 같은 다양한 ICT 기술이 나타나면서 SI 사업은 예전보다는 많이 줄어들고 있는 추세다.

이와는 반대로, 모바일 디바이스와 같은 개인용 기기가 늘어나면서 불특정 다수가 사용하는 솔루션 소프트웨어가 증가 추세에 있다. 솔루션 소프트웨어는 고객이 미리 정해져 있지 않기 때문에 소프트웨어를 개발하는 프로세스나 방법이 SI와는 다소 상이한 편이다. SI는 고객의 요구사항을 파악하고 분석하는데 많은 시간을 할애하지만 솔루션은 개발과 딜리버리, 그리고 업그레이드 등에 많은 시간을 할애한다. 다수의 사용자가 원하는 소프트웨어를 개발하고 오랫동안 사용될 수 있도록 서비스하고 업그레이드를 해야 하기 때문이다.

SI와 솔루션 소프트웨어의 차이를 좀 더 체계적으로 확인하여 소프트웨어 개발에 도움을 주고자 이번 달에는 SI와 솔루션 개발의 차이를 아키텍처, UX, 테스트, 그리고 개발 관점으로 알아보고자 하며, 이번 회에서는 아키텍처 관점으로 차이점을 살펴보기로 한다. 먼저, SI의 아키텍처와 솔루션 아키텍처의 구성과 역할에 어떤 차이가 있는지 알아보고, 두 아키텍처의 설계 프로세스를 비교하여 차이점을 살펴보기로 한다.

아키텍처 구성과 역할의 차이

아키텍처 구성의 차이

사전에서 정의하는 아키텍처란 컴퓨터 시스템의 컴포넌트를 배치하고 통합하는 방식으로 나타나 있고, IEEE에서는 시스템을 구성하는 요소를 식별, 정의하고 그들 간의 관계를 설정해 놓은 기본적인 구조체, 그리고 설계와 전개에 대한 가이드 원칙으로 나타나 있다. 아키텍처는 다양한 의미로 해석되고 활용되지만 한마디로 요약하면 “시스템의 구조체”라는 것이다. 시스템을 만들기 위한 기본적인 요소를 비즈니스, 애플리케이션, 데이터, 기술로 나누어 구성한다. 이러한 4개의 구성을 계획자, 분석자, 설계자, 개발자의 관점으로 살펴본다면 <그림 1>과 같이 나타낼 수 있다.

SI는 고객의 요구사항에 맞춰 시스템을 구성하기 때문에 시스템 개발 초기에 기술적으로 시스템의 큰 그림을 그리는 성향이 강하다. SI는 시스템의 뼈대를 만들고 그에 맞춰 살을 붙여가는 것을 고객에게 보여주면서 완성해야 하기 때문이다. 솔루션은 고객의 요구사항을 전달받기보다 프로젝트 팀에서 사용자가 원하는 것을 자체적으로 파악하는 경우가 많기 때문에 소프트웨어를 개발하는 자체에 더 초점이 맞춰져 있다.

이러한 이유로, <그림 1>을 살펴보면 SI는 세부 기술과 관련된 데이터, 기술 아키텍처에 집중하는 성향이 강하고, 솔루션은 비즈니스, 애플리케이션에 집중하는 성향이 강하다. 이해관계자 관점에서 본다면, 전사적인 모델을 구축하는 계획자, 분석자는 SI 개발에서 더 많은 역할을 하고, 직접적으로 소프트웨어 개발을 하는 설계자, 개발자는 솔루션 개발에서 더 많은 역할을 한다.

아키텍처 역할의 차이

앞에서 살펴본 것처럼 아키텍처의 가장 큰 역할은 고객, 프로젝트 팀원과 같은 이해관계자들 간의 의사소통 수단이다. 특히 SI 프로젝트 초기에는 시스템의 실체가 없기 때문에 시스템의 뼈대를 보여주는 아키텍처의 중요성은 매우 높다. 또한 SI에서 아키텍처는 프로젝트를 성공시키기 위해 필요한 기술적인 접근방법, 프로젝트 위험을 최소화하기 위한 기준과 가이드 등을 제시하여 이해관계자의 의사결정과 프로젝트 관리계획을 수립하는데 가장 중요한 역할을 한다. 아래는 SI에서 아키텍처의 역할을 정리한 내용이다.

*이해관계자 간의 의사소통 수단

*기술적으로 집중해야 할 사항을 결정

*시스템의 초기 설계 결정의 기준과 가이드 제공

*프로젝트에서 일어나는 기술적인 문제점을 최소화

*재사용 가능한 추상화 모델 수립

SI에서 아키텍처는 위에서 보는 것처럼 만들고자 하는 시스템에 대한 의사소통과 의사결정을 위한 추상화 모델의 역할이라고 할 수 있지만, 솔루션에서 아키텍처는 불특정 다수가 사용하는 소프트웨어를 설계하고 개발하는 원칙과 개발 후 배포, 기능 추가, 업그레이드에 유연하게 대처하는 모델을 수립하는 역할이라고 볼 수 있다. 아키텍처의 구성 별 역할을 <표 1>과 같이 정리하였다.

<표 1> 솔루션 아키텍처의 역할

위와 같이 솔루션에서 아키텍처는 누가, 언제, 어떻게 사용하더라도 유연하게 대처하는 모델을 수립하는 것이 가장 중요하다. 또한 대개 완성 후 개발이 종료되는 SI와는 다르게 솔루션은 배포, 기능 추가, 업그레이드에 대한 전략이 반드시 필요하고, 관리 측면에서는 소프트웨어의 버전을 관리하는 버저닝(Versioning) 전략도 고려해야 한다.

버저닝 개념 이해

http://www.esri.com/news/arcuser/0110/versioning101.html

SI 아키텍처와 솔루션 아키텍처 비교

앞에서 살펴본 것처럼, SI는 고객이 요구하는 소프트웨어이고 솔루션은 구체적인 목표가 없는 상태에서 필요에 의해 만들어지는 소프트웨어이기 때문에 SI 아키텍처와 솔루션 아키텍처는 무슨 소프트웨어를 만들 것인지 목적이 다르다. 따라서 구성되는 아키텍처의 특징도 <표 2>와 같이 다르게 나타난다.

<표 2> SI 아키텍처와 솔루션 아키텍처의 특징

<표 2>를 살펴보면, SI 아키텍처는 기술적인 요소가 반드시 포함되고 그에 따라 개발이 진행된다. 하지만, 솔루션 아키텍처는 설계와 개발이 진행되면서 아키텍처가 서서히 정의되기 때문에 기술적인 요소가 아예 포함되지 않을 수도 있다.

또한 두가지 아키텍처의 근본적인 목표는 비즈니스 요구사항을 만족하는 소프트웨어를 만들기 위한 요소들과 그 관계를 정의한 것이다. 따라서 비즈니스를 분석하여 정의하는 프로세스가 두가지 아키텍처에서 모두 존재하게 되는데, 여기서 SI 아키텍처와 솔루션 아키텍처의 가장 큰 차이점이 나타난다. SI 아키텍처는 비즈니스 요구사항을 기술로 해석한 후 필요한 요소들을 정의하여 소프트웨어를 개발하는 것이고, 솔루션 아키텍처는 비즈니스 요구사항을 그 자체로 해석한 후 소프트웨어를 개발한다. 아키텍처는 개발이 진행되면서 최종 완성된다. SI 아키텍처에 요구사항이 제대로 반영되었는지 고객들이 검증하기 어려웠던 것은 기술로 정의된 요인이 크다. <그림 2>는 SI 아키텍처를 정의하는 것을 나타내고 있다.

<그림 2> SI 아키텍처 설계 프로세스

<그림 2>를 살펴보면, 비즈니스 아키텍처 수립 후에 애플리케이션, 기술, 데이터 아키텍처가 정의되는 것을 볼 수 있다. 하지만 내부의 아키텍처 정의 내용들이 모두 기술적으로 정의되고 있다. 기술 요소로 구성된 SI 아키텍처는 설계자나 개발자들이 해석하고 활용하기는 좋으나 추상적인 비즈니스를 기술적인 아키텍처로 옮기기에는 다소 무리가 있다. 이러한 이유로, SI에서는 비즈니스와 기술을 연결해주는 부분을 해결하고자 엔터프라이즈 아키텍처(EA, Enterprise Architecture)를 적용하였지만 크게 호응을 얻지는 못했다.

<그림 3>은 솔루션 아키텍처 설계 프로세스를 나타내고 있다. 비즈니스 전략과 목적을 통해 비즈니스 모델을 만들고 엔터프라이즈 아키텍처를 거쳐 비즈니스 프로세스와 비즈니스 시스템, 그리고 솔루션 아키텍처를 만들고 있다.

<그림 3> 솔루션 아키텍처 설계 프로세스

자료: Alan McSweeney의 Structured Approach to Solution Architecture

솔루션 아키텍처의 근본적인 목적은 <그림 4>에서 보는 것처럼 비즈니스 모델에서 요구되는 요구사항을 효율적이고 명확하게 파악하여 비즈니스 시스템을 정의하고, 이를 소프트웨어로 만들어 딜리버리 하도록 하는 것이다. 비즈니스 모델을 비즈니스 시스템으로 정의하기 위해 엔터프라이즈 아키텍처를 활용한다. 일반적으로 TOGAF를 많이 사용하며, TOGAF는 하단을 참조한다. 여기까지는 SI와 유사하다고 볼 수 있다.

<그림 4> 솔루션 아키텍처 설계의 근본적인 목적

자료: Alan McSweeney의 Structured Approach to Solution Architecture

Enterprise Architecture: TOGAF 개념 이해

https://www.opengroup.org/togaf/

<그림 5>는 비즈니스 요구사항과 아키텍처 기준을 기반으로 솔루션 아키텍처를 정의하고, 이를 솔루션으로 딜리버리하는 것을 나타내고 있다. 이처럼 비즈니스 요구사항 자체를 아키텍처에 반영하고, 이를 바탕으로 원하는 소프트웨어를 딜리버리 하는 것이 솔루션 아키텍처의 장점이라고 볼 수 있다. 다만, 이러한 비즈니스를 반영하기 위해 설계자와 개발자도 비즈니스에 대한 많은 경험과 지식이 요구된다.

<그림 5> 솔루션 딜리버리를 위한 아키텍처 설계

자료: Alan McSweeney의 Structured Approach to Solution Architecture

아키텍처는 만들고자 하는 소프트웨어를 미리 살펴보면서 필요한 요소들을 큰 그림으로 나타내는 것이다. 그리고 소프트웨어를 분석, 설계, 개발하면서 원래의 의도대로 만들고 있는지 비교해보는 기준을 나타내기도 한다. 지금까지 살펴본 바와 같이 SI와 솔루션 아키텍처는 만들어지는 목적과 시점이 다소 다르다. SI의 아키텍처는 고객이 요구하는 환경에 맞게 구성해야 하고, 솔루션 아키텍처는 소프트웨어가 구동하는데 가장 이상적인 환경을 가정하여 구성한다.

이번 회에서는 SI와 솔루션 아키텍처를 구성하는 방법과 역할, 그리고 두 아키텍처에 대한 차이점을 비교해보면서 장단점을 살펴보았다. 모바일 디바이스의 증가 추세로 볼 때, 불특정 다수가 사용하는 솔루션 형태의 소프트웨어가 점점 증가할 것으로 보인다. 지금까지 안정화된 많은 SI 아키텍처의 특징과 구성을 잘 파악하여 지속적으로 늘어나는 솔루션 아키텍처를 효율적으로 구성할 수 있도록 해야 할 것이다. 솔루션 아키텍처는 기하급수적으로 늘어나는 솔루션들의 개발 방향을 알려줄 것이다.

[직업 조사] SM (System Management - 시스템 운영 or 유지보수)

SM (System Management - 시스템 운영 or 유지보수)

▣ SI프로젝트의 결과로 구축된 시스템을 운영하고 발생하는 문제에 대처하는 업무

▣ 실시간으로 발생하는 트러블에 대응 -> 전화응대 - 친절한 말투와 세련된 말솜씨는 중요한 스킬이다.

[직업 정보] SI(System Intergration - 시스템 구축)

SI(System Integration - 시스템 구축)

◈ 전산시스템을 필요로 하는 곳으로부터 하청을 받아, 시스템의 기획, 개발, 유지보수, 운영 등을 대신 해주는 업종

◈ 개인보다는 기업이나 관공서가 주된 고객

◈ 고객의 요청에 따라 제안서를 작성->PM과 개발자를 투입하여 프로젝트를 수행 -> 소요된 인건비와 솔루션의 단가 등을 수임료로 벌어들이는 형태의 산업

◈ 특성 : 도급 시스템과 파견업무

SI에 대한 좋지 않은 말들이 많지만 그래도 꾸준히 프로그래머들이 몰리는 이유

1. 진입장벽이 없다.

누구든지 국비 지원학원을 다녀서 공부를 하고나면 시장에 진입할 할 수 있다. 실제 공무원시험 준비를하다가 개발자가 된 케이스도 꽤 있다.

2. 시장이 상당히 크다.

가령 한국IDC는 2018년 국내 SI시장 규모가 약 3조 3750억원에 이를 것으로 내다봤다. 때문에 타 분야에 비해서 이직이 용이한 편이고, 실력만 있다면 그만한 대우를 받을수도 있다. 실업률도 상당히 낮은편. 당연한 얘기지만, 막장 인력파견소 직원과, 영업력 있는 프리랜서와의 수입차이는 하늘과 땅차이

3. 해외취업에 굉장히 유리하며 유망직종이다.

웬만한 선진국에서 항상 프로그래밍 계통 직업은 항상 받고 있으며 이민으로 받아들이는 인원도 다른 업종에 비해 훨씬 많다. 오죽하면 마크 주커버그가 자기업계에 이민법을 개정시키려고 로비도 하고 웹사이트도 만들정도.

물론 어중간한 실력으로는 안된다. 같은 실력이면 자국민을 뽑지 외국인을 고용하지는 않기 때문.

◈ 개발자의 위상은 업계나 사용하는 언어가 아니라 몸담고 있는 회사나 연봉에 의해 결정

개발자 대우와 연봉

▣ SI 대기업의 경우

2015년 기준 대기업(삼성SDS / SK / LG) 초봉이 4천 초반 정도이다.

전형적인 하후 상박 구조라서 대리급 연봉하고 신입 연봉하고 큰 차이가 없다고 한다. 복지도 좋다.

현대오토에버의 경우 국내 IT & 개발 기업 대졸 초임 4800만원으로 1위를 기록

계열사에 비해 을의 입장이고(예로 삼성 SDS의 경우 삼성 전자가 갑이된다) 인센티브도 약하기 때문에 대우에 비해서 외부의 인식이 좋지는 않다

▣공공기관의 경우

해당 업체 연봉 테이블을 그대로 따라간다. 이 때문에 금융공기업 전산직 사원은 연봉이 엄청나게 높다.

공공기관 특성상 범죄를 저지르더라도 집행유예 나올 정도 아니면 정년이 보장된다.

입사자의 20% 정도만 차장 이상으로 승진할 수 있기 때문에 승진을 미리 포기하면 야근을 할 필요도 없다.

다만, 프로그래머로서 뭔가 의미있는 일을 하기는 힘들다. 대개 컴퓨터 수리, OS 재설치 같은 잡무를 같이 한다.

▣ 프리랜서

프리랜서의 경우 연봉이 아니라 월단가로 계산한다.

초/중/고급 기준으로 보통 350/450/550 이 기준이 되지만 수년째 이 단가가 변하지 않고 있다.

개인별로 편차가 매우 크다. 수요와 공급의 법칙을 매우 잘 따르며, 경기가 좋으면 개발자가 부족해서 단가가 올랐다가 경기가 나쁘면 쉽게 떨어진다.

▣ 중소기업

중소기업의 경우 4년제 대졸자 초임이 다른 직장과 크게 다르지 않다.

다만 신입 때 적게 받다가 3~4년차 정도에 크게 연봉이 오른다.

좋은 회사는 퇴사자가 거의 없기 때문에 구인 자체를 잘 하지 않고 간혹 나더라도 지인 추천으로 많이 뽑지만, 나쁜 회사는 일한국 같은 사이트에 365일 구인 공고가 난다.

때문에 인맥 없이 일한국 같은데 보고 구직을 하게 되면 대부분 막장일 확률이 높다.

막장을 피해서 이직하면 또 다른 막장이...

개인간의 연봉차이가 심한 실력도 차이가 심하다 직종이라, 중견급 회사의 실력있는 개발자의 경우 대기업 이상의 대우를 받는 경우도 적지않다. 물론 같은 직급의 동료는 연봉을 알 수 없다.

▣ 전산실

중견기업 등의 전산실 직원은 해당 업체와 운명을 같이한다. 이유는 개발 업무를 주력으로 하는게 아니라서 이직이 쉽지 않기 때문. 하지만 보통 정년이 보장회사가 망하지 않는다면..되고 업무 강도는 약한 편이다. 연봉 역시 사내 연봉 테이블을 따라가는 경우가 많다.

▣ 인력파견회사

가장 나쁜 케이스는 일명 보도방으로 불리는 악성 인력파견업체에 취업하는것이다. 신입의 경우 단순히 파견만 되는게 아니라 경력 뻥튀기에(불법이다) 사수 없이 홀로 방치되어 전전긍긍 하다가 욕먹고 프로젝트에서 퇴출당하는 경우도 많다. 국비지원이 생긴 후로는 아무 신입이나 막 뽑은 뒤 국가 지원금만 빼먹고 버리는 경우도 있으니 취업자들은 주의해야 한다.