calmglow (최진호)

이 글을 쓰기에 앞서 우선 나는  REST에 대하여 아주 우호적이며, 국내 어떤 개발자보다 일찍(2003년) REST를 기업에 적용해서 그 장점과 단점을 누구보다 충분히 알고 있다는 것을 언급하고 싶다.

이미 이 글을 여기까지 읽었다면 REST에 대해서 아는 이 일거라 가정하고 좀 더 나의 고민을 풀어가보겠다.

엔터프라이즈 애플리케이션을 비롯하여 대부분의 애플리케이션은 추상화 과정을 통해 그 아키텍처에 계층을 구성하고 이 계층이 많아질 수록 추상화가 높아지며 그 계층이 보통 다음과 같이 세가지 이상의 단계로 구성이 된다.

• Data Access 계층
• Domain 계층
• 서비스 계층
• (Presentation 계층)

이렇게 계층화를 시도하면 서비스 계층에서는 주로 Use case의 비즈니스 관점의 업무로직을 다루게 되어 보다 재사용 가능하고 유연한 구조를 획득하게 된다. 이 서비스에서는 다양한 내부 트랜잭션들을 수행하기 마련이다. 따라서 Data access에서 서비스 계층으로 나아갈 수록 인터페이스는 보다 Coarse grained하게 그 특성이 변하게 된다.

XX은행에서 돈을 '이체한다'라는 서비스는 실제로는 다양한 업무 트랜잭션을 내부에 감추고 있고 이러한 추상화를 통해 개발 생산성 뿐만 아니라 성능적인 문제에 있어서도 훨씬 더 나은 효과를 가져다주기 마련이다.

그런데 Web 2.0시대에 오면서 REST api를 여러 엔터프라이즈 프로젝트나 모바일 관련 프로젝트 등에서 자주 사용되고 있는 것을 접하고는 하는데, 과연 REST의 특성이 이러한 Coarse grained한 업무 서비스 설계에 어울리는 인터페이스인가 하는 진지한 고민을 할 필요가 있다는 게 이 글의 요지이다.

REST는 말 그대로 자원에 대한 접근을 URL과 HTTP method를 통해 허용하는 방식이다. 그러다보니 아무리 서비스스러운 API 설계를 잘한다고 해도 그 근간은 Domain이나 Data 위주일 수밖에 없다. 조금이라도 복잡한 비즈니스 트랜잭션을 수행하려면 자원관점에서는 설계하기 까다로운 상황이 자주 발생하며, 이러한 복합 트랜잭션이나 업무 트랜잭션 처리를 presentation, client 영역에 떠넘기게 되는 상황이 발생하곤 한다.

이게 왜 문제냐면, 이러한 진지한 고민없이 REST를 주요 인터페이스로 프로젝트를 끌고 가다보면 Open직전에 Coarse grained하지 않은 client와 서비스간 잦는 호출 문제로 인하여 성능에 엄청난 악영향을 미치게 되기 때문이다. REST는 아키텍트가 설계하기는 편하지만 여러가지 비즈니스이슈와 성능 및 트랜잭션 이슈등을 무시하게 되는 상황을 만들 여지가 큰 인터페이스인 것이다.

클라이언트 개발자는 REST가 편하다고 엄청나게 많은 비동기 AJAX call을 서버에 때려버리고, 예전같으면 page call 트랜잭션 한번이면 끝날 것을 수없이 많은 fine grained한 call로 성능을 느리게 만들어버린다.

따라서 내가 이야기하고 싶은 결론은, 유행이라고 하여 REST와 AJAX기반의 fine grained한 클라이언트와 서버간 통신을 남발하다가는 프로젝트 말미에 엄청난 고생을 할 여지가 있으니, REST는 꼭 필요한 때에만 사용하는 것이 좋지 않겠는가 하는 것이다.
굳이 꼭 main interface로 써야한다면 REST를 굳이 domain model 관점에서 인터페이스 구성하지 말고 정말 업무로직 관점에서 설계하여 애초에 자원 접근은 막고 업무로직 기반의 Coarse grained한 서비스를 설계하는 자세가 필요할 것이다.

문득 지금 태어나는 아이들은 22세기에도 살아있겠구나라는 생각을 한다.
21세기에는 고작 장수를 꿈꾸지만 그때에는 영원한 생이 꿈이 아닌 때가 되지않겠는가하는 무서운(?) 생각.
지금 태어나는 아이들은 영원한 삶을 사는 첫 세대가 될 수도있다는 생각.
모두가 영원한 삶을 살 수는 현실적으로 어려울테니 영원한 삶을 사는 권리는 소수에게만 주어지고 다수는 죽음을 맞이하거나 dna와 기억의 일부가 컴퓨터 저장 장치에 기록되겠지.
어떤 사람이 영생의 권리를 누릴까?
아마도 돈 많은 사람이거나 엄청난 재능을 가지고 있는 사람일것이다.
그러나 돈과 재능은 줄어들거나 대체가 가능한 속성들이다. 더구나 아무리 부와 재능이 있어도 그것이 타인을 위해 쓰이지않고 자신만을 위해 쓰였다면 사회가 그 사람의 영생을 원할 이유는 없다.
결국 살아오면서 얼마나 이타적인 삶을 살아왔는지가 그 사람의 영생 여부를 결정하지 않을까?
인류가 그리던 천당과 지옥의 사후세계는 그렇게 머지않은 미래에 우리 앞에 실존하게 될 것이다.

OpenLogic이라는 오픈소스 관련 컨설팅 및 서비스 회사가 구글 트렌드 검색과 자체 방법론등을 이용하여 2011년 최고의 오픈소스 스타를 분야별로 정리하였다.
먼저 2010년 대비 2011년 크게 성장하고 트렌드를 이끌어간 오픈소스 5개는 다음과 같다.
1. HBase, a distributed, column-oriented database system built on top of Hadoop.
2. Node.js, a platform for writing highly scalable Internet applications in Javascript.
3. nginx, a high concurrency, low memory usage web server and reverse proxy.
4. Hadoop, a framework for distributed processing of large data sets across clusters of computers.
5. Rails, a highly scalable web application framework.

그리고 분야별로 다음과 같이 정리하였다.

	App server/ Webserver	프레임워크	DB, big data
트렌드 성장	Node.js, nginx	Rails	HBase, Hadoop, MongoDB
트렌드 유지	Tomcat, Apache HTTP server	Spring, Grails, Struts	MySQL, PostgreSQL
트렌드 감소	JBoss, GlassFish		CouchDB

트렌드에 대한 조사이기 때문에 실제 시장에서의 선호도와는 약간의 차이가 분명히 존재할 것이고, 트렌드는 아주 쉽게 변동이 가능한 만큼의 위의 2012년 성장했던 스타 오픈소스가 올해도 승승장구하리라고 장담할 순 없을터.
개인적으로 2011년에 성장했던 오픈소스 중 마음에 드는 것은 거의 없다. 거의 대부분 1,2년 잠깐 반짝하다 명맥만 유지할 것들처럼 보인다. 그나마 Hadoop이나 nginx정도가 좀 더 장수하는 기술이려나?

지금도 많은 기업들은 변화와 혁신과 발전을 위해 IT에 많은 부분을 투자하고 있고 쉴 새 없이 새로운 프로젝트를 수행하고 있다.
1. 대부분의 프로젝트는 서비스를 Open하고
2. 거의 대부분의 프로젝트는 기간을 넘겨서 서비스를 Open하고(혹은 Open하고 개선)
3. 소수의 프로젝트는 잘 사용되지만
4. 1년이 지나지 않아 많은 서비스 및 결과물은 폐기되거나 쓰레기가 되어버린다.
5. 다시 새로운 프로젝트가 구상되고 1번으로 반복된다.

정말 많은 프로젝트는 '사실상' 실패하고
실패는 엄폐되거나 그 원인이 외부 요인으로(때로는 북한 ^^;) 돌려진다.

왜 실패할까? 아니, 실패는 왜 끊임없이 비슷한 패턴으로 반복될까?
개별 실패의 원인은 천차만별이겠지만 비슷한 패턴의 반복되는 실패의 원인은,
결국 개별 실패의 원인을 객관적으로 까발리고 실패를 자산화하지 않기 때문이다.

하지만 프로젝트 참여자들은 위에서부터 아래사람까지 모두 실패를 인정하고 싶어하지 않는다.
그럼에도 불구하고 프로젝트의 성공 실패 여부를 판단할 수 있는 가장 적절한 사람들은 역시나 프로젝트 참여자들.
따라서 프로젝트가 끝나고 1년 혹은 6개월 정도의 시간(인사평가 기간이 지날만한 시간 이후)이 지난 후 서비스 사용자들에게 Feedback을 받아서 프로젝트 참여자들이 스스로 평가하여 조금 더 자유롭고 여유로운 마음으로 부족했던 부분을 회고하여 자산화할 수 있는 제도가 있으면 좋지 않을까 생각해본다.

클리앙은 전자 및  IT기술을 중심으로 그 외에 다양한 이슈에 대해 이야기하는 우리나라 최대 커뮤니티 중 하나이다.
비교적 매너있는 커뮤니티인데다가 다양한 주제들이 상당히 빨리 업데이트되기 때문에 자주 가는 편인데,
문제는 한번 빠지면 어마어마한 글의 양 때문에 읽다보면 시간을 빼앗기기 쉽고 자칫 중독의 길에 들어서면
클리앙을 원망하면서도 자신도 모르게 클리앙에 접속하는 나를 발견하게 된다.

그래서 google app engine에 python으로 간단하게 클리앙 모두의 공원 RSS를 만들었는데, 모든 글을 피드하는게 아니라
첫페이지에서 두번째 페이지로 넘어가기 전에 코멘트가 9개 이상 달린 글을 피드하는 RSS.
나는 개인적으로 매우 유용하게 쓰고있는 중인데, 예전보다 훨씬 클리앙을 헤매는 시간이 줄었다.
전자담배처럼 클리앙 중독을 어느 정도 막아줄 수 있는 피드서비스라고나 할까?

google appengine이 트래픽 용량 제한이 있어서 공개를 주저하다가 한번 올려본다.