테크 이야기2015.06.24 16:31

알고리즘 수업을 듣고 있었다. 렉처러는 알고리즘 분야에서 많은 저명한 논문을 발표한 옥스포드의 Ralf Hinze 교수였다. 그는 OOP와 FP(Functional Programming)을 아래의 수학식을 통해서 간단히 정의한 뒤 설명을 덧붙였다.


OOP와 FP를 설명하는데 있어 서 어떤 설명도 이 수학식보다 간단 명료할 수 있을까? 간혹, FP를 실제 코드에 적용하다 보면 가끔 OOP와 혼용되어 identity가 조금 흔들릴 때가 있지만 그럴때 다시금 이 철학을 되새겨야 한다.

저작자 표시
신고
Posted by 박경훈
테크 이야기2015.03.03 09:42

새로운 웹 프로젝트를 기획하면서 어떤 기술스택을 가져갈지에 대한 고민이 있었다. 그리고 그 고민으로 각 잡사이트를 뒤지면서 구인 현황들을 조회해봤다. 물론, 비지니스와의 연계성뿐만 아니라 개발자의 향후 경쟁력 둘다 고려해야 했다. 비지니스에 최적화만 고려할 수 없는 것이 개발자들이 충분히 흥미가 있어야 하고 또 그 기술적인 투자가 헛되지 않아야 개발 시너지가 생기기 때문이다.

노드를 기반으로 한 MEAN 스택과 파이썬의 장고와 플래스크 그리고 루비 중에 어떤 스택을 선택해야 될지에 대한 고민이 이어졌다. MEAN(Mongo, Express, Angular.js, Node.js)스택의 경우 API 기반의 서비스나 싱글 애플리케이션과 같은 모바일 환경에는 최적화 되었지만 일단, 웹이 주를 이루는 서비스 부분에서는 큰 장점을 발휘하기가 어렵다. 그리고 그에 비해서 학습에 투자해야 되는 부분이 많다는 부분에서 일단 선택에서 제외되었다.

그래서 루비와 파이썬에서 고민이 있었는데 개인적으로 생산성에서는 루비 온 레일스가 나아 보였지만 파이썬의 점유율과 다양한 분야에서 활용도가 높고 또 크게 단점이 없다는 부분에서 결국 파이썬을 선택하게 되었다. 그리고 파이썬에서도 장고와 플래스크의 선택이 있었지만 결국 파이썬을 차근차근 이해하고 또 기술을 원하는 여역위주로 확장해 나갈 수 있다는 점에서 플래스크를 선택하게 되었다. 

그래서 이런 결정을 내리면서 미국과 영국에서는 얼마만큼의 기술 점유율을 가지고 있는지 궁금했고 각 나라를 대표하는 잡 사이트에서 핵심 키워드를 통해서 검색해 봤다. 잡 사이트가 시장에서의 개발자 수요를 나타내고 있고 그 수요가 대부분 개발자 포션을 반영하기 때문에 크게 다르지 않을것이라고 생각했다.

북미 대륙을 대표하는 미국과 유럽을 대표하는 영국 그리고 한국 이렇게 세 나라를 비교해봤다. 조회한 키워드는 node.js, python, ruby, c#, java, php 이다. 모두 웹 서버 플랫폼을 비교하고 싶었지만 java와 C#의 경우 경우 안드로이드 개발자나 윈도우 기반 프로그램 개발자가 포함될 수도 있기 때문에 다소 조회 결과가 많이 나오게 되는 것을 감안하고 보면 좋다.




각 나라별 개발자 구인통계

필자가 이 데이터를 조회하게 된 것은 과연 파이썬, 루비 그리고 노드가 얼만큼 사용되고 있을지가 궁금해서였다. 먼저 한국의 결과부터 살펴보자. 




[잡코리아에서 각 키워드로 검색한 결과]


한국은 자바와 C#그리고 php가 주를 이루는 것을 볼 수 있다. 스타트업 기업들보다는 S.I와 같은 엔터프라이즈 시장이 한국의 주된 점유율을 가지고 있기 때문에 java나 C#이 대부분인 것을 볼 수 있다. php의 경우 이전의 웹 사이트들과 서비스들을 점유하고 있는데 여러 대표적인 오픈 CMS 툴들과 쇼핑몰 솔루션 들이 php로 되어있는 부분도 이 점유율에 큰 일조를 했다고 볼 수 있다. 

그리고 약 5% 정도를 차지하고 있는 node와 python 글고 ruby는 주로 기술 스타트업에서 사용한다고 볼 수 있지만 아직 한국에서는 스타트업 자체의 점유율이 떨어지고 트렌드를 분석하고 선구할 수 있는 개발자들이 많이 부족하다는 부분에서 약 5%가 안되는 점유율이 나온 것으로 분석된다. 




[computerjobs에서 조회]


미국도 java와 C# 비율이 낮은 것은 아니지만 우리나라처럼 압도적이지는 않다. java와 C#의 비율이 약 4:3 정도를 유지하고 있으며 국내와 조금 다른 것은 php의 점유율이 높지 않다는 것이다. 주된 node, python 그리고 루비의 점유율이 약 30%를 차지 하고 있다는 부분에서 한국과 많이 대조적이다. 물론, 엔터프라이즈 시장이 한국만큼 크지 않고 스타트업의 점유율이 많다는 점에서 이런 그래프가 그려질 수 있다.

트랜디한 기술을 주도하는 실리콘 벨리 지역에서의 점유율은 아래와 같았다.



[computerjobs에서 조회]

실리콘 벨리에서는 파이썬, 루비와 같은 기술들의 점유율이 상대적으로 높았다. 비지니스 성향에 따라서 기술선택 부분도 달라지게 되는데 아마 뉴욕같은 경우에는 C#이나 java와 같은 엔터프라이즈 환경의 기술이 더 많을지도 모른다. 그리고 자바의 경우 안드로이드 점유율을 포함하고 있기 때문에 월등히 높게 나온 부분이 있다. 웹 서버 기술만 놓고 보자면 자바도 20-30% 정도가 될 것으로 예상된다.


스타트업이 루비 그리고 파이썬과 같은 환경을 더 선호하는 이유는 그만큼 개발 생산성을 보장하고 또 서비스에 더 적합한 환경을 제공하기 때문이다. (참고글: 스타트업에서는 어떤 기술을 이용해야 할까?)

다음은 영국의 개발자 구인현황이다.



[cwjobs에서 조회]

영국에서 놀란 것은 C#이 월등히 높았다는 것이다. 물론, 금융권이 많고 돈을 내더라도 지원을 받을 수 있고 신뢰기반의 환경을 가져가는 것을 더 선호하는 문화 때문에 닷넷 기술의 인지도가 높다.


언어는 도구일 뿐인가?

요즘 닷넷 락스 같은 미국 팟캐스트를 듣다보면 자신을 소개할때 폴리글랏 프로그래머로 소개하는 것을 자주 듣고는 한다. 더군다나 개발 언어들도 느슨한 타입결합을 기반으로 개발자가 쉽게 사용하는 것을 초점에 맞추고 있다는 부분에서 언어는 개발 도구 정도로 흘러가고 있는 분위기이다. 물론, 프로그래밍 언어라는 것은 그 시대의 변화를 상징적으로 함축하고 있고 반영하고 있다. 하지만 요즘 그 변화가 매우 빠른 만큼 그 언어의 철학을 너무 깊이 심취해서 다른 플랫폼을 베타적으로 받아드리면 시야가 좁아지기 쉽다.

폴리글랏 시대에서 엔지니어에게 강조하고 있는 것은 언어나 플랫폼 경험 보다도 서비스 경험과 업무 경험일 것이다. 예를들면 만약 자신이 큰 규모의 트래픽을 다루는 서비스를 설계하고 참여한 경험이 있는지 아니면 클라우드 환경에서 엘라스틱한 서비스를 경험해봤거나 다양한 개발문화들을 얼마나 체험해봤냐와 같은 경험들 말이다.

지금까지는 어떤 언어와 플랫폼을 알고 그 플랫폼의 경험이 중심이 되었다면 이제는 그런 실력을 넘어 경험적인 측면을 많이 보고 있다. 국내에서도 이제는 조금씩 알고리즘 기반으로 코딩 테스트를 진행하고 있는 것을 볼 수 있다. 즉, 어떤 언어와 플랫폼의 지식에 근거하지 않고 그 사람의 problem solving 능력과 기본기로 개발자를 판단하는 분위기로 서서히 바뀌어 가고 있다는 것이다. 기술은 그 시대의 트렌드에 따라서 잊혀지거나 사라지는 경우가 많기 때문이다. 이것을 인정하고 폴리글랏 트렌드를 받아드릴 수 있다면 개발언어와 플랫폼 그 이상의 것을 볼 수 있을 것이다.


저작자 표시
신고
Posted by 박경훈
TAG 개발자
테크 이야기2015.01.26 10:07

오늘 아침에 훈스닷넷에 올라온 질문글에 대한 답변으로 node.js와 닷넷의 웹 서버 동작 구조에 대한 썰을 풀어보고자 한다.

이전 글 "완전히 새로운 닷넷 개발 환경이 온다"에서 런던에서 게임을 개발할 때 IIS기반의 ASP.NET 웹 페이지를 개발하다가 Node.js 로 옮겨 같 사례를 언급한적이 있었다. 당시 그 팀은 SignalR 기술을 이용해서 플래쉬 게임의 데이터를 닷넷으로 구현된 서버에 전달했다. 서버의 메모리 보다는 CPU 효율이 낮다보니 여러 가지 테스트를 거쳐 node.js가 당시 시나리오에서 더 좋은 효율을 가져와 교체하게 되는 결정을 하게 되었다.

이번 글에서는 Node는 어떻게 동작되고 닷넷의  웹 서버는 요청을 어떻게 처리하는지 살펴보도록 하겠다.

먼저 성능에 대한 이야기를 하기 전에 웹서버의 로드(Load)에 대한 정의가 필요하다. 웹서버의 성능은 하나의 요청을 얼만큼 빠르게 응답하느냐로 정의되지 않는다. 1초에 500개의 요청이 갔을 때 그 서버가 얼마나 빠르게 처리할 수 있느냐에 따라서 성능이 정의되고 걸리는 시간을 우리는 로드로 칭할 수 있다.

DB나 파일에 대한 읽고 쓸 필요없이 처리해야 된다면 당연히 IIS가 더 빠를 것이다. IIS는 커널 모드의 캐싱을 이용하고 있기 때문에 바로 커널 모드에서 정적 페이지를 반환해 버리게 된다. 하지만 우리는 동적인 페이지들에 대해서 고려해보고 비교해볼 필요가 있는 것이다.

노드와 같은 경우 기존에 웹서버들이 걸리게 되는 로드들을 어떻게 하면 더 효율적으로 처리할 수 있을까를 착안해서 개발한 플랫폼이다. 즉, 로드가 없다면 닷넷이든 노드든 서로 성능에 대해서는 크게 민감하지 않을 것이다. 닷넷이 더 빠를수도 있고 노드가 더 빠를수도 있다.


ASP.NET의 동작구조

그렇다면 기존의 ASP.NET이 어떤 이유로 로드가 생기고 노드는 어떻게 다른지 살펴보도록 하자. 먼저 요청을 처리하는 웹 서버의 기술 자체가 전혀 다르다고 할 수 있다. ASP.NET은 하나의 request가 있을때 마다 스레드를 생성하고 그 작업은 스레드 풀을 통해서 관리된다. 그리고 스레드 한계 갯수가 넘어가게 되면 그 요청을 큐에 쌓게 된다. 이런 모델만 두고 봤을때는 멀티쓰레드로 처리되기 때문에 큰 문제가 없다.

하지만 스레드에서 공통 리소스에 대한 Lock을 걸게 되면서 로드는 시작된다. 즉, I/O에 따른 요청들이 발생했을 때인데 주로 DB를 호출한다거나 파일을 디스크에 쓴다거나와 같은 요청들이 I/O접근을 요구하는 요청들이다. 이때 각각의 스레드들은 서로 그 리소스에 접근하겠다고 시도를 하게 된다. 버스 문은 하나인데 10명의 사람들이 서로 들어가려고 애쓰는 있다고 생각해보면 이해가 빠르다. 문제는 이 10명은 어떻게든 버스를 타게 되면되는데 이 혼잡으로 인해서 버스를 탈 필요도 없는 사람들이 지나가는데 불편을 초래하는 케이스다. 이 때문에 스레드 풀은 오히려 서버 리소스만 차지하게 될 뿐이지 로드를 빠르게 없애는데 큰 도움이 되지 못한다.

이런 문제를 MS도 알고 있기 때문에 여러가지 방안들을 소개하기도 했다. I/O Completion Ports 라는 기술이 바로 그것이다. 하지만 아쉽게도 여러 닷넷 기술들이 I/O Completion Ports를 지원하지 않는다는 것이다. 엔티티 프레임워크가 대표적인 예이다. 아무튼 이것을 적용하는 것이 굉장히 어렵고 불편한 작업이기 때문에 더이상 닷넷을 한다고 하기 어렵다.

이런 문제를 빠르게 풀기 위해서였을지 몰라도 C#언어가 빠르게 발전했고 async 모델을 발표했다. 즉, 비동기 I/O를 쉽게 개발자들에게 지원하겠다는 의견이다. 기존에는 이것을 전적으로 개발자들에게 맞기는 것이지 일관된 표준을 지정한 것은 아니다. 물론, 지금도 그렇다. 스레드 대신 쉽게 쓸수 있는 문법을 제공해 주었을 뿐일지 모른다. 성능을 개선하고자 하는 전문가는 직접 비동기 방식을 구현해서 개발을 진행하는 것이 가능하다. 하지만 이것은 사람들의 자유의지와 코드를 적절히 잘 사용하는 사람에게만 좋은 방안일 수 있기 때문에 node가 성능이 더 좋은 것처럼 비추어 질 수 있다. 

단순, 블락킹 논블락킹 모델을 떠나서 노드는 싱글 리스너를 사용하는 반면 닷넷은 멀티플 리스너를 이용한다. 이 차이 때문에 싱글스레드 동작 방식과 멀티 스레드 동작방식의 차이가 생성되므로 CPU 효율이 차이가 나기 마련이다.




Node.js는 어떻게 다른가?

Node.js의 경우 닷넷과 같이 개발자가 이해하고 있고 또 원한다면 I/O에 있어서 비동기로 처리하게 설계하지 않았다. 전부다 I/O 비동기 처리 정책을 만든 것이다. 이 결정 때문에 노드 개발자들은 하나의 노드 인스턴스 별로 하나의 싱글 스레드만 생성하였고 스레드 스위칭을 최소화하게 된다. 그리고 하나의 스레드가 큐에 쌓여진 작업을 순차적으로 처리하는 방식을 사용하게 된 것이다. 

이런 처리 방식때문에 노드는 기존에 스레드가 스위칭되면서 발생하는 CPU의 효율을 최소화하는 것이 가능했다. 왜냐하면 노드는 전부다 비동기 I/O라는 정책이 있었기 때문이다. (물론, 추가적인 add-on 을 통해서 이 모듈도 원하는 방식대로 처리할 수 있다.) 

그렇다면 어떻게 하나의 스레드가 멀티플 요청을 처리하는 것이 가능할까? 먼저 노드는 하나의 리스너 스레드만 존재한다. 그렇다고 스레드 풀을 안쓰는 것은 아니다. 많은 사람들이 노드는 싱글스레드로 동작한다는 이야기 때문에 스레드가 1개로 오해하기도 한다. 단, 하나의 메인스레드가 요청을 받고 각각의 non-blocking 모델을 반환한 이벤트를 처리한다는 부분에서는 분명 싱글스레드가 맞는 것이다. 

즉, 동작원리를 정리하자면 I/O작업과 같이 오랜 시간을 필요로 하는 작업은 기본적으로 스레드 풀로 보내서 작업을 진행하고 작업끝난 녀석들의 이벤트를 다시 싱글 스레드가 받아서 그 이벤트를 실행하는 구조이다. 아래 그림이 노드의 동작을 잘나타 내주고 있다.







닷넷과 노드.js의 차이 정리


- 두 가지 모델에 대한 차이들을 다시 정리하자면 node는 1개 스레드의 리스너를 가지고 있고 닷넷은 N개의 스레드를 이용한다. 만약 스레드에 조금더 효율을 가져가려면 node쪽이 효율이 좋다고 이야기 할 수 있다. 닷넷이든 노드든 서버 리소스에 제한을 받는 것은 마찬가지 이다. 


- 노드의 경우 I/O기반의 작업은 기본적으로 non-blocking 스레드 방식으로 동작한다. 닷넷은 개발자가 async 패턴을 도입해서 구현해야 한다. 여기서 닷넷 개발자의 역량에 따라서 더 좋은 모델이 될수도 있고 안좋은 모델이 될 수도 있다.

- 노드의 경우 이벤트 기반의 작업 패턴을 이용하고 닷넷 또한 이런 작업을 람다식과 async로 구현할 수 있다. 

- 노드와 닷넷 I/O 기반의 작업에서 높은 퍼포먼스를 낼 수 있는 구조이지만 기본적으로 IIS 파이프라인 때문에 노드 만큼의 성능을 내기가 어렵다. IIS는 세션 상태 정보와 인증 등 다양한 모듈 들의 통합 때문에 서버 자체가 노드만큼 가볍지 못하다. 이러한 것들이 많은 사람들이 아파치와 IIS를 떠나 DJango나 Rails와 같은 웹서버를 이용하는 이유이기도 하다.


여기까지가 노드와 현재 닷넷 버전의 차이점으로 정리하였다. 지금 새로운 버전 ASP.NET5의 리눅스 버전에서는 이런 모델을 어떻게 반영하고 개선할지에 대한 기대가 개인적으로 크다. 적어도 IIS 파이프라인보다 심플한 구조의 웹 서버가 탄생하지 않을까 기대해 본다.

저작자 표시
신고
Posted by 박경훈
테크 이야기2015.01.09 10:01

닷넷 플랫폼에서는 작년 9월부터 vNext에 대한 소식들로 많이 달구어져 왔다. 이번 글에서는 ASP.NET5(vNext)의 출시 배경과 무엇이 달라졌는지 또 향후의 기대에 대해서 짧고 굵게 요약해 보겠다. 

왜 새롭게 바꾸었나? 

여러가지 이유가 있지만 먼저 자바와 닷넷은 이제 서비스 개발에 있어서 비주류의 분위기로 흘러 가고 있는 것에 있다. 물론, 국내만 이야기 하는 것은 아니다. 무엇보다도 실리콘 벨리의 스타트업들만 보더라도 자바나 닷넷의 안정성 이면의 무거운 웹 서버 환경을 선호하지 않고 있는 것이 추세이다. 즉, 서비스 개발에 있어서는 거의 Ruby on Rails와 Node.js 그리고 DJango정도가 주측으로 자리를 잡아가고 있는 것이 부인할 수 없는 현실이다.

MS도 S.I 환경의 엔터프라이즈 시장만 더이상 고수할 수 밖에는 없는 것이다. 과거에는 엔터프라이즈 마켓이 기술을 주도하는 것이 가능했다. 오픈소스가 열리기 이전에 기술을 드라이브하는 것이 IBM, MS, 오라클 등의 대형 벤더들이었기 때문이다. 하지만 이제는 IT 서비스 회사들이 오픈소스와 함께 기술 트렌드를 주도한다. 페이스북이나 트위터 이런 대규모의 서비스 경험이 있는 회사들이 자사의 아키텍처들을 소개하고 더불어 오픈소스를 확산한다. 그것이 곧 기술트랜드로 자리 잡히는 상황이다 보니 더이상 엔터프라이즈 환경에서는 힘을 쓰기가 어렵다.

MS 웹 개발자들이 다른 플랫폼으로 떠나는 것을 보고만 있을 수 없었던 것이다. 그래서 지금 웹 시장을 선점해가고 있는 node와 ruby의 트렌드를 따라서 그들은 다시금 asp.net의 방향을 새로하기로 결정했다. 그리고 닷넷은 vNext 소식이 들린지 두어달 만에 닷넷 오픈소스 정책을 세상에 공표했다.

마지막으로 MS는 클라우드 사업에 열두하고 있다. Azure가 나쁘지 않은 성과를 얻을 수 있었던 것이 기존의 닷넷 개발자들이 있었기 때문이라고 조심히 예측해 본다. 런던에서 닷넷 개발회사들만 보더라도 Azure를 사용했지 AWS를 사용하는 팀은 본적이 없다. 물론, 아직까지도 AWS와의 격차가 많이 크지만 만약 웹 개발 시장을 선점한다면 분명 그 마켓이 어떻게 될지 두고봐야할 것이다.

ASP.NET 5 어떻게 바뀌나?

먼저 크로스 플랫폼 개발 환경을 지원한다. 즉, 우분투나 맥에서 얼마든지 개발이 가능하다. 셀프 호스팅을 지원한다는 환경까지 놓고 봤을 때 node와 유사하다고 볼 수 있다. 실제로 싱글 스레드 기반으로 동작될지는 아직 내부 아키텍처를 까보지 않아서 이야기 하기 어렵다. 하지만 분명 node 이상의 속도를 보장하지 못하면 어필자체가 어렵기 때문에 더 나은 속도와 모델을 보장할 것이 분명하다. 그리고 node가 제공하는 non blocking 이벤트 기반의 프로그래밍 기법은 이미 C#5의 async/await 모델을 통해서 제공하고 있기 때문에 언어적으로도 큰 문제는 없다.

두번째로 현재 닷넷이 가지고 있었던 조금 산만해 보일 수 있는 버전들을 정리하기 시작한다. 예를 들어 WCF와 MVC 그리고 웹폼등 다양한 버전들이 산재해있다. 만약 내가 API 서비스를 만들고 싶다면 WCF의 웹API를 이용해서 만들수도 있고 MVC나 웹폼을 통해서도 만드는 것이 가능했다. 단지 차이가 있다면 개발 방법의 차이가 있는 것이지 IIS를 통해서 request와 response에 대한 액션은 거의 비슷하다. 


이런 개발환경을 새롭게 발표한 환경에서 동작할 수 있게 다시금 정리하게 되는데 ASP.NET MVC로 통합되어 제공 된다. 버전은 6이다. 

여러 변화들은 컴파일러 로슬린(Roslyn)을 통해서 주도한다. 가장 큰 변화는 기존에 컴파일 시에 dll 파일을 만들지 않고 메모리에 가지고 있다는 것이다. 닷넷 윈도우에서 사용되는 CLR 버전이 있고 크로스 플랫폼에서 사용하는 CLR이 따로 존재한다. 그리고 Owin이라는 표준 닷넷 인터페이스를 기반으로 하고 있기 때문에 낸시나 카타나 등과 같은 기존의 오픈소스 프레임워크들과도 시너지가 가능하다.

같이 소개되고 있는 Entity Framework 7 이라는 ORM에 대한 기대도 크다. 기존에 RDB위주로 지원을 넘어 Redis의 지원이 가장 눈여겨 볼 만한 부분이다. 물론, 엔티티프레임워크도 오픈 소스이기 때문에 향후 다양한 제품들 지원에 박차가 될 것으로 생각된다.


ASP.NET 5의 효과는?

기존에 윈도우 환경을 좋아하고 닷넷을 해온 사람들에게 또 다시 공부를 해야 한다는 이야기로 들려 그렇게 달가운 뉴스가 아닐 수 있다. 하지만 닷넷을 좋아하지만 리눅스 계열의 웹 환경을 쫓아야 했던 사람들에게는 더할나위 없이 좋은 소식이 분명하다. C#은 굉장히 완성도가 높은 언어이고 누구나 쉽게 배울 수 있는 언어이기 때문이다.

아직 preview 버전이고 알파 단계가 되는지 모르겠다. 하지만 이런 변화의 소식은 다른 플랫폼들을 고민하고 있는 닷넷 개발자들에게 무척 좋은 소식이다. 이전에 런던에서 일할 때에도 asp.net signalR과 Redis를 이용해서 게임을 만들었지만 결국 서버 성능상의 이슈로 node.js로 바꾼 적이 있었다. 적어도 이렇게 탈 닷넷화하는 현상은 생기지 않을 것이다. 

지금은 시장을 선점하기 어렵겠지만 2년을 조금 더 지켜보자고 이야기 하고 싶다. 물론, 국내 말고 세계적으로 봤을 때는 절대 의심의 여지가 없다. 닷넷이 다시금 어느정도 포션을 가져올 것은 분명하다. 하지만 국내는 몇년이 걸릴지는 아직 예측이 어렵다.


세계를 상대로 의심의 여지가 없는 이유는 간단하다. 세계적으로 굉장히 많은 닷넷 개발자들이 얼마나 많은가? 국내에서 3%도 안될 플랫폼 점유율이지만 세계적으로 봤을 때 못해도 30%는 될 것이다. 이렇게 많은 닷넷 개발자들은 바로 오픈소스의 자원들이다. 사용자의 요구사항에 대한 피드백을 받아서 특정 벤더가 그것을 분석해서 반영하는데 까지의 시간이 너무나 길다. 하지만 오픈 소스의 경우 다양한 회사들이 직접 수정하고 만들고자 할 것이고 그 나아진 모델을 제시하며 발전에 박차를 가할 것이다.

박경훈.

저작자 표시
신고
Posted by 박경훈
테크 이야기2014.12.16 13:37

개발&디자인 리소스 TOP 22


my sql 관리 툴 TOP 10

Angular.JS를 시작하기 전에 알아야 할 5가지


개발자들에게 필요한 크롬 익스텐션 15가지


BDD 테스트 자동화의 소개 with Serenity and JUnit


API가 적작물이 되어서는 안된다.


2014년도를 빛낸 JQuery 플러그인 25개




저작자 표시
신고
Posted by 박경훈
테크 이야기2014.12.10 09:22

웹 프레임워크의 경량화가 유행처럼 번지면서 또 오픈스택이 실리콘 벨리의 스타트업 심장과 같은 역할을 하기 시작하면서 닷넷 개발 스택도 많이 변하기 시작했다. 무거운 닷넷 프레임워크와 IIS 같은 윈도우에만 의존하기 보다는 이제 경량화할 수 이는 프레임워크를 찾기 시작한 것이다. 

그래서 영국에서 요즘 많이 유행하고 있는 닷넷 스택을 보자면 Nancy 프레임워크를 기반으로 Azure, EF, Angular 정도가 기본이 되는 것 같다. 솔직히 국내에서는 닷넷 개발자의 입지가 좁다보니 node.js나 자바로 옮겨가는 것을 많이 보지만 실제로 닷넷의 성능이나 기능이 후져서가 아니다.

그렇다면 ruby나 파이썬을 구동하는 웹 프레임워크 처럼 가볍게 갈 수 없을까에 대한 해답이 바로 nancy프레임워크가 될 것이다. 물론, vNext의 행보를 보더라도 크로스 플랫폼을 더불어 self-hosting까지 지원하면서 아마 모든 웹 스크립트 언어들 부럽지 않게 성장할 수 있을것으로 사료된다.




저작자 표시
신고
Posted by 박경훈
테크 이야기2014.12.10 08:30

출처: http://9gag.com/gag/anXEbe0?ref=t.mw




저작자 표시
신고
Posted by 박경훈
테크 이야기2014.12.09 08:46

기술을 두고 보면 참 예측하기 어렵다. 모노토닉하게 한 방향으로 발전하지 않기 때문이다.
어떤 한 모델이 한참 유행이 되다가도 다시 본질을 찾아가는 사례가 많다.

그런 관점에서 아래 그림은 참 의미가 있다.



한때는 굉장히 화려하고 rich한 웹 페이지가 유행 하다가도 지금은 오히려 심플하고 사용자 반응에 더 집중한 웹 페이지를 선호한다. 이와 비슷한 관점으로 병렬 프로그램과 멀티 쓰레드 프로그래밍이 다수의 CPU를 기반으로 하는 하드웨어를 기반으로 선풍적인 유행으로 다가 왔지만 결국 지금은 싱글 스레드에 더 집중하고 있다.

node.js 사례도 마찬가지이다. 아파치 웹서버처럼 다중 스레드를 지원하는 모델 보다 단일 스레드를 기반으로 하되 이벤트를 중심적으로 진행하는 플로우가 훨씬 성능이 좋다.


이런 의미에서 소개하고자 하는 아티클이 바로 "Make Your Program Slower With Threads" 이다. 우리가 바라고 있는 이상과 하드웨어가 가지고 있는 한계에 대한 현실을 잘 보여주고 있는 글이다.


저작자 표시
신고
Posted by 박경훈
테크 이야기2014.12.07 16:42

객체지향 프로그래밍에서 거의 교과서라고 할 수 있는 SOLID 디자인 원칙이 데이터베이스에도 적용할 수 있는 사례의 아티클을 발견했다. 물론, 2013년에 작성된 글이지만 내용이 신선해서 링크를 첨부한다.

Building SOLID Databases: Introduction

Building SOLID Databases: Single Responsibility and Normalization

Building SOLID Databases: Open/Closed Principle

Building SOLID Databases: Liskov Substitution Weirdness

Building SOLID Databases: Interface Segregation, or Keep Stored Procedures Simple

Building SOLID Databases: Dependency Inversion and Robust DB Interfaces




저작자 표시
신고
Posted by 박경훈
테크 이야기2014.12.07 16:41

개발자로 일하다 보면 그럴때가 있다.

다른 일들은 다 완료했는데 하나의 문제가 풀릴듯 말듯 하며 나의 발목을 잡는다.
다음날 해도 될 일이지만 왠지 처음부터 해야만 하는 것 같은 그런 기분 때문에 집에 가지도 못하고 앉아있다.
하지만 대부분 그런 문제는 앉아 있는다고 풀리지 않았다.

지금은 오히려 이런 문제에 봉착했을때 오래 앉아 있지 않는다. 
오히려 커피를 마시며 집에 가는 길에 왜 그게 풀리지 않았는지를 생각해 본다.
아니면 다음날 아침 샤워를 하면서 그 문제를 가볍게 꺼내 본다. 

그렇게 한발짝 뒤에서 그 문제를 다시 볼때 가끔은 그 답이 너무나 가까운 곳에 있기도 했고, 
해결 전략을 어느정도 정리하는 것도 가능했다. 

하지만 모니터 앞에 앉아 너를 해결해야만 속 시원하게 집에 갈 수 있을 것 같은 그 아집 때문에 
그 문제를 큰 그림에서 생각하지 못하는 경우가 많다.

코드를 짜다가 막히는 문제가 있을때는 바로 그 자리를 아쉬움 없이 일어난다.
그리고 다시한번 계획을 세워보자.




저작자 표시
신고
Posted by 박경훈
테크 이야기2014.12.04 16:51

이베이에서 몽고디비를 활용하고 있는 사례를 분석해보고자 한다. NOSQL에 대한 이해가 없었다면 아마 이번 글을 통해서 쉽게 개념을 잡아 갈 수 있을 거라고 생각한다. 

그들은 이전에 DB에 테이블에만 의존하던 검색을 메모리 캐쉬(디비)를 이용해서 속도를 향상시킬 수 있었는데 이 사례가 옥션바이트 블로그에 자세히 소개되어있다. 그들은 클라우드 관리와 메타데이터 저장공간 그리고 사용자들이 검색어를 입력했을 때 그와 관련된 연관 검색어들을 보여주고 있다. 이런 작업들을 몽고DB같은 nosql을 활용해서 속도를 올릴 수 있었다. 

그럼 보다 자세히 이 사례를 살펴보도록 하자. 먼저 연관검색어는 아래와 같은 기능이다.


사용자가 타이핑 할 때마다 연관 검색어를 찾아서 보여주는 것이다. 이 때 서버로의 호출이 일어나게 되는데 이 속도를 끌어올리기 위해서 기존에 정렬된 테이블을 이용하기 보다는 메모리 DB를 이용한 것이다. 

우선적으로 이베이에서 내부적으로 샤딩이 필요했는지는 모른다. 만약 검색해야 하는 데이터의 양이 한 서버의 메모리 안에 들어가기 어렵다면 우리는 서버를 분리시켜야 한다. 이 내용을 쉽게 이해하기 위해서 큐브리드에서 설명하고 있는 그림을 살펴보자.


[출처: cubrid.org]


이런 간단한 사례처럼 대규모 데이터 용량의 접근 속도를 올리고 싶다면 메모리 디비를 도입해보는 것을 추천한다. 물론, 데이터가 실시간으로 민첩하게 변경 되지 않은 경우에 해당한다. 여러 nosql 툴들이 데이터 백업과 fault 대비 그리고 다양한 메모리 구조들을 지원하고 있다.

저작자 표시
신고
Posted by 박경훈
테크 이야기2014.11.19 15:31


  • 1. 테스트 자동화와 TDD 박경훈
  • 2. 진행순서  자동화 된 테스트가 없다면?  자동화 된 테스트의 정의  TDD의 소개
  • 3. 자동화 된 테스트가 없다면?
  • 4. Fact1. 소프트웨어의 소스는 복잡하게 연결 되어 있다.
  • 5. 작은 한 부분이 수정된다면?
  • 6. 모든 기능을 다시 테스트 해야 한다.
  • 7. Fact2. 소스코드는 시간이 흐르면 녹이 슨다.
  • 8. 끊임없이 OOD(Object Oriented Design)와 패턴 구문들을 적용해가며 리펙토링 해야 한다.
  • 9. 하지만 리펙토링이 어려운 이유
  • 10. 모든 기능을 다시 테스트 해야 한다.
  • 11. 자동화 된 테스트가 없다면?  자체 버그 검출 능력 저하 - 모든 기능을 테스트 하기 어려움  소스 코드의 품질 저하 - 어디서 버그가 생길지 모르기 때문에 잘못 된 코드도 고치지 않으려 하는 현상  자체 테스트 비용의 증가 - 작은 수정에도 모든 기능을 다시 테스트 해 야 되는 문제
  • 12. 자동화 된 테스트란?
  • 13. 자동화 된 테스트란?  모든 테스트 케이스를 코드 스크립트로 변환 한 집합체
  • 14. 통합 테스팅의 예
  • 15. 3rd party testing tools  http://www.youtube.com/watch?v=qsh4zWa 6bE8  http://www.youtube.com/watch?v=4TGkGQo nmy4#t=64
  • 16. 누가 테스트 스크립트를 만드는가? Software Engineers QA Engineers Software Architect
  • 17. 개발 프로세스 요구사항 Software & QA Engineer 테스트 케이스 수립 - 공백입력 하면 오류 메시지 띄우기 - 사용자가 여러 개의 비디오를 옮길 수 있게 개발 통합 테스트 코드 작성 QA Engineer Software Engineer
  • 18. TDD
  • 19. TDD란 무엇인가?  Test-Driven Development - 요구사항의 테스트 요건을 먼저 고려  Test-First Development - 개발 전 테스트 코드를 먼저 작성하여 개발  1999년 XP라는 애자일 기반의 개발 방법론과 함께 소개 됨
  • 20. TDD란 무엇인가? 기존 개발방식 TDD의 개발방식
  • 21. TDD의 장점  높은 소스코드 품질 - MS와 IBM사의 조사 결과 TDD 약 15~35% 정도의 개발시간 증가 결 함율(버그)은 약 40~90% 정도 줄어듬 - http://research.microsoft.com/en-us/ groups/ese/nagappan_tdd.pdf  재설계 시간의 절감  손쉬운 테스트 근거 산출 및 문서화 (test coverage, performance)  디버깅 시간의 절감
  • 22. TDD의 단점  all about 개발 생산성!
  • 23. 1부터 10까지의 수를 출력하는 프로그램 만들기! - 단, 3의 배수에서는 숫자대신 “HOONS”를 출력 - 5의 배수에서는 “JAEDAM”을 출력
  • 24. 통합테스트와 유닛테스트 Dependency Injection = AOP
  • 25. 편의점 카운터에서 물건을 스캔한 뒤에 고객에게 최종 가격을 알려주는 프로그램이 필요합니다. 물건들의 가격은 데이터 베이스에 있으며, 한가지 특별한 것은 현재 모든 물건을 2개 사면 하나 더 주 는 이벤트를 하고 있기 때문에 이 로직을 반영해주 세요.
  • 26. 비지니스 레이어 => 할인점검 유닛테스트 데이터 레이어 => 가격정보 유닛테스트 통합테스트
  • 27. 패턴 문화 Test Automation /TDD AOP Repository Pattern MVC, MVP, MVVM Dependency Injection SOLID, DRY, KISS ORM - Entity Agile – XP/Scrum CI Pair programing Git – code review BDD/DDD Daily Standup User Story & Estimation
  • 28. 결과 중심적 개발 프로세스 Project Manager Software Engineer Tester 요구사항 결과물 개발
  • 29. 품질 중심적 개발 프로세스 ① 요구사항 Project Manager ② 분석/설계 전달 Architect / Lead developer 개발 Software Engineers 결과물 ③ 코드리뷰 요청 (pull request) Architect / Lead developer Tester 테스트 요청 결과물 피드백 코드 리뷰
  • 30. Q&A


저작자 표시
신고
Posted by 박경훈