Sunday, June 12, 2016

[잡담] 실리콘밸리(Silicon Valley)에서의 Software Engineer 포지션 구직 관련 팁 및 정보


미국에서 소프트웨어 엔지니어로 일하기 가장 좋은 지역이 세 곳이 있는데 (씨애틀 지역, 샌프란시스코/실리콘 벨리 지역, 텍사스 오스틴 지역) 그 중에서도 가장 평균 연봉도 높고 구글과 애플 그리고 페이스북 같은 거대 IT 대기업의 본사가 있을 뿐만 아니라 많은 스타트업 회사들이 포진해 있어서 기회가 많은 샌프란시스코/실리콘 밸리가 지역이 가장 엔지니어한테는 일하기 좋은 지역이 아닐까 생각합니다. 이 글은 필자가 실리콘밸리 지역에서 경험한 내용과 주변 사람들의 이야기를 통해 배운 구직 관련 내용입니다.

1. 접근성
본인이 정말 실리콘밸리에 있는 회사에 취직을 하고 싶다면 우선은 실리콘밸리 쪽으로 오는 것이 가장 좋다고 생각합니다. 사실 이 부분은 꼭 실리콘밸리 지역에 국한된 것은 아니지만 많은 분들이 이 접근성의 중요성에 대해 간과하고 있는게 사실입니다. 학교를 실리콘 밸리 쪽에 있는 학교로 오든 아니면 본인이 원하는 회사는 아니지만 실리콘 밸리 쪽에 있는 회사로 취직을 한후 이직을 준비하든 우선 이 곳에 와서 생활을 하고 인맥을 넓히고 실력을 쌓으면서 인터뷰 준비를 성실히 잘 한다면 기회는 꼭 찾아올 것입니다. 특히 인맥이 중요한 이유는 다른 사람들의 인터뷰 경험을 들을 수 있으며 때에 따라서는 그 회사의 오픈 포지션에 대한 리퍼 (추천)를 받을 수도 있어서 인터뷰 성공 확률을 높일 수 있습니다. 참고로 미국 내에 있는 대부분의 회사들은 추천만으로 고용이 되는 경우는 극히 드물지만 추천을 받게 되면 서류 심사 절차는 생략이 되는 경우가 많기 때문에 인터뷰를 함에 있어서 큰 도움이 됩니다. (특히 구글이나 페이스북 또는 애플 같은 큰 회사는 온라인으로 레즈메를 접수해도 너무나 많은 지원자들 때문에 서류 심사를 통과하는 것도 힘이 드는 경우가 많습니다.) 마지막으로 실리콘 밸리 지역에서는 개발자들을 위한 여러 형태의 컨퍼런스나 Hackathon 같은 이벤트가 매년 꾸준히 열리고 있어서 기술 동향이나 인맥 형성에도 큰 도움이 되고 있습니다.

2. 실력
물론 당연한 이야기지만 실리콘 밸리에 있는 좋은 회사에 취직하기 위해서는 경력과 레벨에 따른 실력이 있어야 합니다. 작은 회사일 경우를 제외하고는 다른 사람의 추천 만으로 취직을 하기가 쉽지 않고 실력이 없다면 대부분의 Technical 인터뷰 과정에서 떨어지기 때문입니다. 참고로 이제 막 졸업한 학생일 경우에는 몇 가지 특별한 도메인의 스페셜리스트가 되기 보다는 다양한 분야에 대한 경험이 있는 것이 더 좋을 수 있습니다. 그 이유는 첫째, 학교에서 경험할 수 있는 프로젝트에는 한계가 있고, 둘째, 그 경험들이 실제 인더스트리에서 사용되는 경우도 거의 없으며 (여러가지 환경적인 요인들 때문에) 마지막으로 그렇게 되면 결국 자신이 구할 수 있는 취직 기회의 범위를 축소하는 결과를 낳기 때문입니다. 대략적인 인터뷰 과정과 준비해야할 항목에 관해서는 따로 글을 작성해서 올리도록 하겠습니다.

3. 학력
몇몇 특정 기업의 특정 포지션에 한해서는 학력을 중요시하는 경우가 있지만 이곳에 있는 대부분의 회사들은 특정 학교 졸업을 요구하거나 인터뷰 시 중요하게 보고 있지 않습니다. 단 학사 졸업은 보통 기본으로 요구하고 있으며 (CS나 CE 쪽) 석사를 선호하는 편입니다. 어떤 학교를 나오든 인터뷰를 보는 절차는 같기 때문에 인터뷰 준비만 잘 하면 학력은 크게 문제가 되지 않는 것 같습니다.

4. 언어 능력 (영어)
미국 내에 있는 회사에서 일을 하려면 영어 구사 능력은 필수이지만 그래도 다른 직종에 비해 (회계사나 세일즈맨 같은) 엔지니어들한테 요구되는 언어 능력은 조금 덜 한 편이며 특히나 실리콘 밸리 지역은 워낙에 외국인 엔지니어들이 많기 때문에 (특히 인도인과 중국인) 미국 내의 다른 지역에 비해 언어 능력 부족에 조금 관대한 편입니다. 기본적인 회화 능력과 자기 생각에 대한 정확한 서술을 할 수 있고 상대방의 이야기를 이해하고 토론 가능한 정도면 일을 하는데 있어서 큰 무리가 없습니다. (물론 이전에 미국에서 생활한 경험이 없거나 영어권 국가에서 연수 및 유학을 하지 않은 경우에는 이 정도까지 오는데도 쉽지는 않겠지만요) 그렇지만 위의 내용은 말단 엔지니어일 때의 경우이고 좀더 높은 포지션의 인터뷰 때는 (매니저나 테크니컬 리드 같은) 기술적인 실력도 중요하지만 언어 능력이 더 많이 중요하게 작용하기 때문에 이 부분에 있어서는 좀더 많은 개선이 있어야 합니다.

5. 대기업 vs 스타트업 회사
일반적으로 스타트업 회사는 경험이 많이 있거나 여러가지를 다양하게 할 줄 아는 엔지니어를 선호하며 (지금 당장 쓸수 있는 엔지니어) 대기업은 경험이 부족해도 잠재력이 있거나 기초가 튼튼한 엔지니어들을 고용하는 경우가 많이 있습니다. 입사 후에 하는 일들도 대기업은 특정 분야에 대해서만 일을 하게 되지만 스타트업 같은 경우에는 여러 가지 다양한 일을 동시에 진행하는 경우들이 대부분입니다. 참고로 이야기하자면 스타트업의 업무 환경이 대기업보다 더 좋은 곳이 많으며 평균 이상의 스타트업 같은 경우 (투자금 상황이 괜찮은 경우) 직원 대우 (연봉 + RSU)도 대기업과 거의 비슷한데다가 향후 주식상장을 하거나 대기업에 합병되었을 때 스톡옵션이 대박나는 경우들이 있기 때문에 오히려 대기업보다 더 들어가기 힘든 곳들이 꽤 있습니다. (Uber나 Airbnb 같은)

6. 회사별 몇 가지 정보
 - Google: 구글은 웬만한 지원자들한테 인터뷰 기회를 주는 편이며(학벌이나 경력 상관없이) 인터뷰한 사람들의 DB를 구축해서 관리하고 있은 것으로 알고 있습니다. 인터뷰 난이도는 높은 편이지만 절차가 상당히 체계적이고 공정하게 진행되는 것으로 알려져 있습니다. 구글 인터뷰 과정의 특징은 Hiring Manager의 권한이 제한되어 있어서 소수의 인맥을 통한 편법적인 채용이 힘들고 모든 인터뷰 절차가 끝난 후 인터뷰를 진행한 사람들이 모여 인터뷰 결과를 공유하는데 이 때 다수로 부터 높은 점수를 받아야 합격이 되는 것으로 알고 있습니다. 만약 인터뷰에 패스를 못 하면 1년 안에 다시 지원을 못하며 (지원을 하더라도 새로운 인터뷰 진행이 안됩니다) 온사이트 같은 경우에는 최대 3번까지 가능합니다. (만약 온사이트까지 가서 떨어진게 3번이 되면 삼진 아웃제 같이 차후에 지원을 하더라도 인터뷰 진행 자체가 아예 안되는 것으로 알고 있습니다.)
 - Apple: 애플은 같은 부서에서 나온 포지션만 아니면 여러 부서의 여러 포지션에 대한 동시 인터뷰 진행이 가능합니다. 인터뷰 과정 중 특이한 점은 알고리즘 쪽 관련 질문 외에도 그 부서에서 사용하는 기술 관련 질문들의 비중도 꽤 높은 편이며 구글보다는 Hiring Manager의 권한이 큰 편입니다.
 - Amazon: 애플과 비슷하게 여러 오픈 포지션에 대해 동시에 지원이 가능하며 아마존 만의 특징은 우선 Scalability 관련 질문을 많이 하는 편이며 인터뷰 시작 때 Behavioral Question을 꼭 하나 이상 하는 경향이 있습니다.
 - 스타트업 회사들: 위에 언급한 것처럼 일반적으로 경험이 많이 엔지니어를 뽑으려 하는 경향이 있으며 인터뷰 과정이 나쁘지 않더라도 자신보다 나은 경쟁자가 있을 시에는 제한된 버젯 때문에 채용이 안 되는 경우도 더러 있습니다. (돈에 여유가 있는 대기업 같은 경우에는 인터뷰 과정이 괜찮은 후보자가 여럿 있을 경우 없는 포지션을 만들어서라도 둘다 고용하는 경우가 있는데 스타트업 회사 같은 경우에는 아마래도 돈에 제한이 있다보니 꼭 정해진 인원만 뽑으려는 경향이 있습니다. 물론 인터뷰를 정말 잘 했을 경우에는 다른 이야기지만요.) 또한 인터뷰 난이도도 일반 대기업들보다 더 높은 경우들도 많습니다.


Wednesday, September 30, 2015

Cache vs Cookies: 웹브라우저 캐시와 쿠키의 차이 점

Cache와 Cookies는 특정 웹사이트의 접속 속도 개선을 위해 클라이언트의 컴퓨터에 임시로 저장되어 있는 데이터란 개념은 같지만 아래와 같은 다른 점들이 있습니다.

Cookies란?
Cookies란 넷스케이프의 Netscape Navigator란 자사의 웹브라이저를 통해 소개된 기술로 특정 웹페이지에 대한 유저의 행동 패턴을 주로 저장하는 작은 사이즈의 텍스트 파일입니다. 주로 저장되는 정보로는 특정 웹사이트나 웹페이지에 얼마나 자주 또는 몇 번 방문했는지 그리고 특정 배너를 클릭을 했는지 했으면 얼마나 자주 했는지 검색 시 어떤 키워드를 사용했는지 등의 정보들입니다. 또한 웹서버 쪽에서 유저를 식별하기 위한 Session Tracking의 방법으로 사용되기도 합니다. Cookies 정보는 오직 그 Cookies를 작성한 웹서버만이 Access 가능하며 대부분의 Cookies는 Expiration Date (사용기한)이 정해져 있어서 기한이 만료되면 자동으로 삭제됩니다.

Cache란?

Cache란 웹페이지 Resource 파일들 (오디오, 비디오, 이미지 등)의 임시 저장소로 다음에 같은 웹페이지 (또는 웹사이트) 접속 시 페이지 로딩 속도를 개선해주는 역할을 합니다.

차이점
1. 유저의 컴퓨터에 임시로 저장되어 있는 점은 같지만 사용 목적은 위에 이야기한 것 처럼 다릅니다.
2. Cache는 오직 웹페이지 로딩 속도 개선을 위해서만 사용되지만 Cookies는 유저 관련된 여러가지 다른 목적으로 사용 가능합니다.
3. Cache는 오디오, 비디오, 이미지 등의 Resource 파일등을 주로 저장하는 반면에 Cookies는 User preference (유저가 웹사이트 접속 시 하는 행동 패턴 또는 관련 정보) 위주의 정보를 저장합니다.
4. 보통 Cache는 유저가 삭제할 때까지 유저의 컴퓨터에 저장되지만 Cookies는 서버 쪽에서 설정한 기간이 지나면 자동으로 삭제됩니다.
5. Cookies는 웹서버의 Access가  가능한 반면에 Cache는 Access가 불가능합니다. (사실 Access를 해야할 이유도 없지만요)

References
1. http://www.differencebetween.com/difference-between-cache-and-vs-cookies/
2. http://www.techcuriosity.com/resources/difference_between/difference_between_cache_and_cookies.php
3. http://www.guidingtech.com/8925/what-are-browser-cache-cookies-does-clearing-them-help/
4. https://answers.yahoo.com/question/index?qid=20081201160300AAa1kh8
5. http://www.ehow.com/info_8304895_difference-between-cookie-cache.html


Friday, May 1, 2015

Redis(레디스) 3.0 설치 (CentOS 6.5 64-bit)


Redis 설치
  1. Redis 설치 전에 필요한 패키지
    • $ yum install tcl*
  2. 가장 최신 버전의 Redis 다운로드 및 컴파일
    • $ wget http://download.redis.io/redis-stable.tar.gz
    • $ tar xvzf redis-stable.tar.gz
    • $ cd redis-stable
    • $ make
    • $ make install
  3.  Redis 서버 시작
    1. 기본 설정을 이용한 서버 시작: 간단한 테스트나 개발 환경에서만 사용을 추천하며 프로덕션 레벨에서의 사용은 추천하지 않습니다.
      • $ redis-server
    2. 설정파일과 함께 서버 시작: 설정 파일은 보통 Redis를 설치한 폴더에 포함이 되어 있습니다. 예를 들어 '/opt' 폴더에 설치했을 때는 '/opt/redis-stable/redis-conf'와 같은 형태로 포함해야 합니다.
      • $ redis-server ../redis-stable/redis-conf
  4. Redis 패키지와 함께 제공되는 클라이언트 프로그램을 이용한 간단한 테스트
    • $ src/redis-cli
    • 127.0.0.1:6379>ping
    • PONG
    • 127.0.0.1:6379> set foo bar
    • OK
    • 127.0.0.1:6379> get foo
    • "bar"
  5. Sources:
    1. http://redis.io/download
    2. http://briansnelson.com/How_to_install_Redis_on_a_Centos_6.4_Server
    3. http://blog.andolasoft.com/2013/07/how-to-install-and-configure-redis-server-on-centosfedora-server.html

Friday, March 27, 2015

AngularJS: $digest vs $apply vs $timeout vs $evalAsync 차이점 및 설명


 AngularJS (이하 Angular)Two-way binding이라는 편리한 기능을 제공하지만 이 기능을 사용할 때 몇 가지 어려운 점이 있습니다. 그 중에 하나가 Angular Context 외에서 들어오는 데이터를 모델에 업데이트를 할 때 (여기서 모델이란 $scope로 정의된 variable들을 이야기합니다. : $scope.data) 개발자가 인위적으로 업데이트를 해야하며 이 때 사용하는 것이 $digest, $apply, $timeout 또는 $evalAsync 입니다. 참고로 Angular Context (또는 Angular  Scope )Angular를 사용하지 않고 제작하는 모듈을 가리키며 가장 간단한 예로 서버를 들 수 있습니다. 서버에서 어떤 이벤트가 발생해서 Angular로 제작된 클라이언트 모듈 쪽으로 데이터가 들어오고 그 들어온 데이터를 UI에 반영하기 위해서 $scope.data에 업데이트를 해야 하는데 위에 언급한 함수들을 사용하지 않으면 클라이언트 모듈 쪽에는 데이터가 업데이트 되었지만 UI쪽인 HTML 쪽에는 (보통 {{data}} 형식으로 포함된) 업데이트가 되지 않아서 UI에 반영이 되지 않은채로 남아있습니다.

Two-way binding의 동작 원리
Two-way binding의 동작원리는 개발자가 $scope를 이용해서 variable을 생성하면 생성된 variable watcher가 생성되고 $apply()$digest()가 실행되었을 때 현재까지 생성된 모든 watcher들이 실행되어서 변화된 값을 업데이트합니다. 여기서 watcher란 할당된 variableold valuenew value를 비교하여 두 값이 다를 경우 old valuenew value로 업데이트해주는 모듈로 $scope.$watch 함수를 이용하여 이 작업을 합니다. UI쪽에서 발생하는 데이터값의 변화에 Two-way binding이 아무런 추가 작업 없이 정상 동작하는 이유는 AngularUI에서 발생하는 이벤트에 대해 $apply()를 자동으로 실행하기 때문입니다. 예를 들어 ng-click 같은 이벤트가 생성이 된다면 $apply()도 자동으로 실행이 됩니다.

$digest()
$digest()는 위의 동작원리에서 설명한 대로 현재까지 생성된 모든 $scope variable 들의 watcher를 실행하여 값이 변화된 variable의 값을 최신값으로 업데이트해주는 일을 합니다.
사용 예: $scope.digest();

$apply()
간단하게 설명하면 $apply() $rootScope.$digest()랑 같습니다. 하는 일은 $digest()와 같지만 다른 점은 커버하는 scope가 다르다는 점입니다. 다시 말해서 $digest()는 해당 scopevariable의 값들만 업데이트하지만 $apply()는 무조건 rootScoperootScope 밑에 있는 모든 child scope들의 variable들 값을 모두 업데이트하기 때문에 자주 사용하면 제품 전체의 성능/효율성을 저하 시킬 수 있습니다. 기본적으로 Angular$apply()의 사용을 추천하고 있지만 제 개인적인 의견으로는 만약 어떤 scopevariable이 업데이트 되어야 하는지 안다면 $digest()의 사용을 추천합니다.
사용 예: $scope.$apply(); 또는 $scope.$apply(function() { ….. } );

$timeout()
$timeout()은 일반적인 자바스크립의 APIsetTimeout()Angular 버전으로 $timeout()함수 안에서 바뀐 variable 값을 업데이트하기 위해 $apply()를 기본적으로 포함하고 있습니다. $timeout()은 보통 setTimeout()과 마찬가지로 얼마동안의 Delay 이후에 해당 코드를 실행하기 위해 사용되어지고 있는데 이 용도 이외에 ‘$digest already in progress’ 에러 발생에 대한 임시 해결책으로도 사용되어지고 있습니다. (DirectiveController 안에서 여러 번의 $apply()를 포함한 개발을 해본 개발자라면 최소한 한 번 이상은 저 에러 메세지를 본 경험이 있을겁니다.) ‘$digest already in progress’에러의 발생원인은 Angular는 기본적으로 한 번에 두 개의 $digest() 동시 실행을 금지하고 있어서 이미 $digest()가 실행 중일 때 또 다른 $digest()가 실행이 된다면 이 에러 메세지가 출력되고 나중에 실행된 $digest()는 실행이 되지 않습니다. 그럼 어떻게 $timeout()의 사용이 이 문제의 해결책이 될 수 있는건가요? 그 이유는 $timeout()$apply() 실행 타이밍 때문인데 $timeout()은 이미 기존에 실행되고 있는 $digest()가 있다면 그 실행이 끝날 때까지 기다렸다가 $timeout() 내부에 포함된 $scope.$apply()을 실행하는 특징이 있고 이 때문에 위의 에러에 대한 임시 해결책으로 사용되어 지고 있습니다.
사용 예: $timeout(function() {…….}, 0);

$evalAsync()
$evalAsync()‘$digest already in progress’에러에 대한 Angular팀의 근본적인 해결책으로 이해하시면 편합니다. (위에도 언급했듯이 $timeout()의 기본용도는 이 문제의 해결이 아닌 얼마간의 Delay이후에 실행이기 때문에 근본적인 해결책이 될 수는 없습니다. 또한 약간의 화면 깜빡이는 문제를 발생시킬 수도 있습니다.) $evalAsync()도 기본적으로 $apply() 함수를 포함하고 있으며 현재 진행중인 $digest()가 있을 경우에 이 $digest()의 실행이 끝나기 전에 $evalAsync()에 포함된 variable의 바뀐 데이터도 같이 업데이트할 수 있는 기능을 제공합니다. $evalAsync()AngularJS 1.2 버전부터 제공되어지고 있습니다.
사용 예: $scope.$evalAsync(function() {…….});

추가사항:
AngularJS 1.3 버전부터 $applyAsync() 함수가 추가 되었다고 합니다.  기본적인 기능은 $evalAsync()와 비슷하지만 효율성 면에서 아주 미세한 차이가 있다고 하는 것 같은데 필자는 사용 경험이 없어서 자세한 사항은 잘 모르겠습니다.

References

Wednesday, February 11, 2015

[NEWS] Node.js Foundation 출범


어제 있었던 Node Summit 2015 (2월 10일)의 마지막 세션이었던 'The future of Node.js'에서 Joyent의 CEO인 Scott Hammond가 Node.js Foundation의 출범을 선언했습니다. 그동안 Node.js 프로젝트는 Joyent가 메인으로 지원했었는데 그래서 폐쇄성과 새 릴리즈의 계속된 지연 등 여러가지 문제가 많이 있었습니다. (그래서 결국 초창기 핵심 개발자들의 주도하에 Node.js의 포크버전인 io.js가 작년에 나오게 되었습니다.)

아무튼 Joyent는 이런 여러가지 문제를 해결하고자 formal open governance 형태인 Node.js Foundation을 출범하기로 결정하였고 이 Foundation 멤버로는 Joyent를 포함해 IBM, Microsoft, PayPay, Fidelity, SAP 그리고 The Linux Foundation로 구성되었습니다. 또한 이 세션에서 앞으로 Node.js는 OpenStack과 비슷하게 두 가지 버전으로 출시할 예정이며 하나는 지금까지의 Node.js처럼 무료로 사용할 수 있는 오픈소스 버전으로 출시되며 이 버전을 Node.js Foundation가 지원할 예정이고 다른 버전은 몇 가지 기업용 기능이 추가된 유료 버전으로 Joyent가 이 버전을 지원/관리할 예정입니다. (즉 Rackspace가 OpenStack을 지원하는 방식처럼 오픈 소스도 지원하고 유료 버전을 따로 제작해서 지원하겠다는 의미입니다. 실질적으로 세션에서 이 내용을 이야기하면서 Rackspace가 오픈스택을 지원하는 모델을 따르겠다고 이야기하였습니다.)

출처: https://www.joyent.com/about/press/joyent-moves-to-establish-nodejs-foundation

Friday, January 9, 2015

앵귤러JS (AngularJS) 란?


앵귤러JS란
앵귤러JS (짧게 앵귤러라고도 합니다)는 MIT License로 무료로 배포되고 구글이 지원하고 있는 오픈 소스 웹 어플리케이션 프레임워크입니다. 앵귤러JS는 자바스크립트로 제작되었으며 기본적으로 MVC (Model-View-Controller) 모델 지원과 같은 다른 웹 어플리케이션 프레임워크에서도 지원하는 기능을 제공할 뿐만 아니라 Two-way data binding이나 directive 같은 새로운 개념의 기술도 지원하여 웹 개발자들이 해야할 많은 일들의 단축 및 좀더 파워풀하고 테스트가 용이한 웹 어플리케이션 제작에 도움이 되는 기능을 제공하고 있습니다. 아직 나온지 5년 정도 밖에 안된 프레임워크지만 구글의 전폭적인 지원 속에 다른 경쟁 프레임워크들이 비해 가장 빨리 커뮤니티가 성장하고 있는 프레임워크가 아닐까 생각합니다.

왜 사용하나요?
  • 체계적인 코드작성 지원: 개인적인 경험으로 JavaScript는 다른 프로그래밍 언어에 비해서 체계적으로 프로그래밍하기 어려운 언어인 것 같습니다. 그래서 프로젝트 사이즈가 커지면 금방 이해하기 힘들어지고 Debug가 어려워지는 Spaghetti Code가 되기 쉽습니다. 그렇지만 앵귤러같은 프레임워크를 사용하게 되면 이런 부분을 일정 부분 해소해줍니다. 
  • 앵귤러는 다른 프레임워크에 비교했을 때 아래와 같은 장점들을 가지고 있습니다. 
    • 구글의 지원 속에 개발자 커뮤니티가 가장 빠르게 성장하고 있고 앞으로도 성장 가능성이 큽니다. 
    • Two Way Data-Binding: 앵귤러가 제공하는 여러가지 기능 중 가장 유용한 기능이 이 Two Way Data-Binding 일 것입니다. 이 기능에 대해서 간단하게 이야기하면 Model과 View에서 사용되고 있는 데이터를 연결해줘서 어느 한쪽에서 이 데이터 값이 변화하면 다른 쪽에도 바로 업데이트가 되도록 해주는 기능입니다. 보통 이 기능 구현을 위한 코드가 전체 프로젝트의 80% 정도를 차지한다고 하는데 앵귤러는 기본적으로 이 기능을 제공하기 때문에 많은 코드의 반복을 피할 수 있습니다.
    • Dependency Injection 기능을 기본적으로 지원하기 때문에 컴포넌트들 간의 서비스 사용 및 Dependency 관리가 용이하며 각각의 컴포넌트들이 Decoupling (코드상에서 밀접하게 연관되어 있지 않음)되어 있기 때문에 테스트 하기가 쉽습니다. Dependency Injection에 대한 좀더 자세한 사항은 저의 다른 블로그 글인 'Dependency Injection이란'을 참고하시기 바랍니다. 
    • Directives: 앵귤러는 Directives를 제공함으로써 개발자가 자신의 용도에 맞게 HTML tag를 제작하여 사용할 수 있게 하였으며 DOM attributes도 수정 가능하게 하였습니다.


출처:
위키피디아: http://en.wikipedia.org/wiki/AngularJS
사이트포인트: http://www.sitepoint.com/10-reasons-use-angularjs/

Saturday, November 29, 2014

스프링 프레임워크 (Spring Framework)란?


스프링 프레임워크란?
스프링 프레임워크는 Pivotal Software에서 아파치 라이센스(무료 라이센스) 형태로 제공하는 오픈 소스 프로젝트로 자바 어플리케이션 (Standalone 과 웹 어플리케이션 모두 포함)개발에 필요한 여러 가지 서비스를 제공하는 프레임워크입니다. 현재 미국에서 자바로 어플리케이션을 개발하는 많은 회사들이 스프링 프레임워크를 사용 중이며 대한민국 공공기관의 웹 서비스 개발 시 사용을 권장하고 있는 전자정부 표준프레임워크의 기반 기술로도 쓰이고 있습니다.

왜 사용하나요?
1. 오픈소스 프로젝트: 다른 블로그에서도 여러 번 강조했지만 많은 회사들이 오픈 소스를 자사의 개발에 포함하는 이유는 라이센스 비용이 따로 들지 않기 때문입니다.
2. 다양한 기능 지원: 프로그램을 개발할 때 프레임워크를 사용하는 가장 큰 이유 중에 하나는 불필요한 반복을 없애고 업무의 양을 최소화하기 때문이 아닐까 싶습니다. 스프링 프레임워크는 엔터프라이즈용 프로그램을 개발하는데 관련해서 대부분의 기능을 제공하고 있으며 이 프레임워크를 사용하면 개발자들은 자사의 제품에 특화된 비지니스 로직만 추가하면 되기 때문에 많은 시간 및 개발비의 절약을 할 수 있습니다. 또한 많은 부분을 간단한 XML 설정이나 어노테이션으로 대신 할 수 있기 때문에 실제 코딩하는 소스코드의 양을 획기적으로 줄일 수 있습니다. 
3. 다양한 방식 지원: 스프링 프레임워크는 한 가지 컴포넌트에 대한 지원도 다양한 방식으로 하고 있습니다. 예를 들어서 DB 연결 같은 경우에도 Hibernate과 같은 모듈과 연동해서 여러 종류의 JDBC를 약간의 설정만 하면 사용할 수 있게 지원하고 있습니다. 이 점은 하나의 소스코드로 다양한 DB를 사용할 수 있게 해주기 때문에 큰 장점이 됩니다.
4. Dependency Injection: 스프링은 기본적으로 Dependency Injection을 지원하기 때문에 모듈들이 타이트하게 연결되어 있지 않으며 그래서 테스트가 용이한 프로그램을 만들 수 있습니다. (특히 유닛 테스트)

5. ETC: 그 외에도 스프링은 메세징, MVC, 테스팅, AOP 등 다양한 서비스를 기본적으로 제공합니다.

사용시 어려운 점 또는 단점
1. 스프링은 지원하는 기술의 양이 방대하고 같은 기술도 여러 가지 다른 방식으로 지원하기 때문에 처음 접하는 엔지니어들에게는 사용하기 힘든 프레임워크입니다.
2. 스프링은 비교적 무거운 프레임워크이기 때문에 이 프레임워크의 추가 만으로 어플리케이션을 상당히 무겁게 만들 수 있습니다. 

참고로 구글이나 애플 같은 큰 소프트웨어팀을 보유하고 있는 회사 같은 경우에는 자사에서 자체 개발한 프레임워크를 사용하고 있으며 보통 스프링 프레임워크와 비슷하거나 더 많은 기능을 제공하고 있다고 합니다. 그렇지만 사용 방식이나 개념에는 큰 차이는 없다고 합니다. 

출처
1. 위키피디아: http://en.wikipedia.org/wiki/Spring_Framework
2. 스프링 프레임워크 메인 페이지: http://projects.spring.io/spring-framework/