웹 서버와 WAS 서버? 우린 웹으로 무엇을 만들고 있는가?

자바 지배적인 한국에서는 왠만한, 아니, 거의 표준이라고 할 만한 개발용어들 대부분이 자바에서 따왔다.
물론 자바에 없는 개념은 다른 언어에서도 가져오기도 한다.

웹에서는, 자바 경험자들이 IT 관리하다 보니 웹 서비스 시 웹 서버와 WAS 서버라고 칭한다.
웹 서버는 웹 페이지를 서비스하는 서버 프로그램이고. 이에 해당하는 제품이 Apache나 IIS, nginx, webtob 등이 있다.
WAS 서버는 Web Application Server의 약자로, 서버단 언어를 통해 웹 기반의 서비스를 제공하는 서버를 뜻한다. 이에 해당하는 제품이 Tomcat, Jetty, WebLogic, WebSphere, JEUS 등이 있다.

당연히 WAS 단독으로 운영은 가능하며, 자바로 아예 독립적인 웹 서비스를 제공할 수 있다.
하지만 관행적으로 반드시 Tomcat 같은 WAS 서버를 통해서 제공해야 대한민국 개발자들은 직성이 풀린다.

그렇다면 자바로 아예 독립적인 웹 서비스를 제공하는 것을 뭐라고 하느냐.
간단하다. 닷넷에서는 웹 응용 프로그램(Web Application)이라는 용어가 있다.

그렇다. 웹 앱이다. 내가 웹 애비다. 웹 어플리케이션. 웹 프로그램 등등… 그냥 웹 기반의 프로그램인 것이다.
초보들이 어려워하는 이유 안다. 대체적으로 WEB과 WAS 분리 운영, 그리고 서블릿 기반만 가르치다 보니,
자바 혼자서 운영하리라고 생각할 틈을 주지 않는다. PHP는 더하고, 하지만 파이썬이나 루비 등은 오히려 여기에 익숙하다.

갑자기 생각나네. C++ 으로 웹 어플리케이션 제작 후기 올렸는데 왜 생산성 좋은 자바 안쓰냐고 태클건 어느 코더의 댓글…

하지만, 특히 자바 개발자들, 우리는 지금 웹 어플리케이션을 만든다는 것을 잊어선 안 된다.
스프링은 웹 아닌 환경에서도 제공하지만, MVC를 통해 웹 개발 환경도 제공한다.
전자정부는 웹 어플리케이션이라고 칭하지 않는다. 웹 개발 환경이라 칭한다. 왜인진 나도 모른다.
어찌됐던, 우리가 자바던 닷넷이던 그 어떤 언어던 웹 기반의 프로그램을 작성하고 있다면,
웹 앱 또는 웹 응용 프로그램(Web Application)을 개발한다고 해야 모든 언어의 개발자들이 이해하기 쉽다.

이번 글은 웹개발하는 우리의 정체성을 일깨워 주기 위해 싸지른 글이라고 볼 수 있다.
홍콩행 게이바에서 핑크가 딜도 던지는 그런 정체성 말고.

composite / 2017년 10월 24일 / Piss Development / 0 Comments

웹 개발자 도구의 역사

웹디자인의 역사는 뭐 웹디자인 관련 블로그만 검색해도 질리게 나온다.

하지만 웹 디자인을 발전시키게 해준 초석인 웹 개발자 환경의 역사는 구글링을 해봐도 잘 안나왔다.

이 얼마나 슬픈 일인가 개발자들이여!

그래서 내가 정리해준다.

1. 넷스케이프에도 개발자 도구는 있었다.

이 글 보는사람들 중 넷스케이프에 신경쓴 개발자가 몇 있을지는 나도 모르겠지만, 때는 1998년이다.

솔직히 넷스케이프 시절에 필자는 초딩이였다. 그때는 모뎀 인터넷 시절이었고, 인터넷이 종량제이며, 인터넷을 할려면 전화를 못받는다는 단점 때문에 상당히 제한적이었지만, 그래도 나름 문화컬쳐였다. 

그런 초딩 시절에 넷스케이프 4 에 자바스크립트 디버거가 있었는데, John Bandhauer 가 개발한 자바스크립트 디버거는 그때당시 자바스크립트는 그저 옵션에 불과했지만, 자바스크립트 개발하는데 있어서 생산성을 촉진시킨 하나의 유물인 것은 확실하다.


2. Venkman Javascript Debugger.

Venkman Debugger

이 기술을 넷스케이프가 모질라로 올인하면서 디버깅 기술까지 전수받았는데, 2001년 출시한 모질라 기반 자바스크립트 디버거를 Venkman Javascript Debugger 라 불렀다.

이녀석의 강점은 모질라 기반임에도 불구하고 크로스 플랫폼에서도 디버깅 환경을 제공하고자 하는 노력이었다,

그래서 Ajax 가 뜰 때 당시에 이 역사가 재조명되었지만, 다른 개발자 도구가 워낙에 좋아서 거기서 그치는 비운의 도구였다.

debugger; 키워드를 ECMA 표준으로 등재시킨 툴이였고, 별도의 프로세스로 돌아갔어도 불여우가 역시 개발자를 위한 브라우저구나 하는 무릎 탁 치게 하는 기원이였다고 해도 과언이 아니었다.

자세한 내용은 링크를 참고하라. : https://developer.mozilla.org/ko/docs/Venkman

3. DOM 시각화.

당신의 웹 어플리케이션에 동적으로 컨텐츠를 넣었다가 갑자기 레이아웃이 깨졌다면, 어떻게 모니터링하고 대처했을까?

분명 테이블이 잘 만들어진것 같은데 테이블이 무너져 보인다면, 소스를 다시 보면서 캐치해야 하니..

하지만 기존 웹브라우저는 잡아내는 방법이 너무나 제한적이었다. 소스 보기를 해도 원 소스를 보여주지 동적으로 추가된 곳까지 신경써주지는 않았으니까. 어찌나 불편했을까? 뭐.. 한국은 액티브엑스가 동적 컨텐츠를 제공하는데 아주 잘 활용해서 말이 통할려나 모르겠지만.

이것을 해냈다. 해냈어. 불여우가해냈어!

View Source Chart

DOM Inspector. 우리말로는 DOM 검사기.

DOM 검사기는 DOM 구조를 트리 구조로 시각화해서 눈으로 보여주는 아주 획기적인 도구였다.

이 도구 덕분에 테이블 등에 엉뚱한 태그가 들어가서 테이블 구조가 깨지는 문제를 손쉽게 해결할 수 있었고,

동적으로 컨텐츠가 들어갔어도 바로 볼 수 있었다.

XML에 비해 HTML은 엄격하지 않아서 물론 잘못 코딩해도 보이긴 하지만, 레이아웃 깨졌거나 뭐 엉뚱한 글자가 페이지여 보여서 컴플레인 들어오면 이젠 두렵지 않은 도구가 되었다.

하지만 한국은 이때도 액티브엑스 전성기라서 우리나라 웹 페이지는 저 구조에 크게 신경쓰지 않았거나,

테이블 기반 구조로 저게 필요한 상황을 만들었음에도 깨지기만 하면 정말 고치기 힘든 웹 사이트 구조를 만들어냈다.

그래도 저게 있어서 한국의 지랄같이 테이블 의존성 구조에서 어느정도 벗어날 수 있었지만, 그 은혜를 모른다.

정말 테이블 태그로 만든 레이아웃은 미관엔 좋았지만.. 개발과 유지보수가 어려운 단점은 피할 수 없었다.

그게 왜냐면, 디자이너들이 나모 웹에디터같은 위지윅 개발도구에 의지하고, 개발자조차도 거기에 의지한 탓이다.

그나마 테이블은 미리보기에도 그대로 볼 수 있었기 때문이었고, CSS 표현력이 제한적이라서 div 기반의 레이아웃에서 잘 보여준다는 보장이 없었으니까.

그래서 이때 웹 개발 비용이 부담된건 사실이다. 아무리 편해도 그게 한계가 있다는 것을 여실히 보여준 트랜드였던 것이다.

쪽팔리게 개발자가 나모웹에디터나 쓰고.. 으이구..

이제 Ajax 이후 하드코딩의 시대가 도래했는데, 이 DOM 검사기 도구는 하늘이 내려준 선물임은 확실하다.

4. Web Developer for Firefox.

불여우가 왜 웹 개발자를 위한 브라우저인지 다시한번 마음에 새기는 혁신(?)이 왔는데, 

하나의 작은 툴바에서부터 시작됐다. Chris Pederick 이 만든 Web Devloper toolbar 였는데, 웹 개발자를 위한 편의성 도구들을 제공하여 웹 개발에 도움을 주게 만든 일등공신이었다.

이 툴바의 강점은 Disable CSS와 Disable Javascript 기능인데, 이는 크로스 플랫폼, 크로스 브라우징 보기, 그리고 CSS가 적용되지 않은 경우와, 자바스크립트가 비활성화된 브라우저의 경우, 그리고 시맨틱과 웹 접근성 개발에 도움을 주는 기능들이 한자리에 모여서 웹 개발자들에게는 없어서는 안될 도구로 성장했다.

2003년 첫 릴리즈 이후 계속 버전업 해가면서 기능과 성능 최적화가 되고, 처음엔 미약했지만 끝은 비대한 웹개발자에겐 모르면 간첩인 도구가 됐다.

근데 한국의 경우 웹접근성이 주목받은 때가 2010년이다. 외국에 비해 7~8년 늦은 접근성이다. 비즈니스와 편의성에만 추구한 나머지 웹취약계층과 접근성은 개나 줘버렸었다. 가뜩이나 IE에만 신경썼는데 오죽했을까? 인종차별 인종차별 소리지르면서 정적 한국이 내가 보기엔 존나 차별하는것 같다.

그렇다고.

5. 개발자 도구의 시작, Firebug.

불여우가 왜 괜히 웹 개발자를 위한 브라우저일까? 애초부터 그렇게 시작한 거다.

한국에 IE와 불여우, 크롬 3대장이 웹 시장을 주름잡기 시작했는데, 불여우가 일반인에게 쓰기 어려운 브라우저인 이유가 바로 이런 개발자 환경에 신경쓴 환경이기도 하다.

어쨌든, 개발자 도구의 표준안을 마련한 도구, Firebug다.

Firebug HTML Tree

하지만 Firebug가 처음부터 표준안을 선도한 것은 아니었다. 버전 0.2 에서는 자바스크립트 콘솔과 CSS 구조, 선택한 DOM의 속성을 제공한 게 전부였다.

0.3 에서는 DOM 기능에 충실하게 출시해서 DOM 이벤트와 속성, 해당 적용된 DOM의 CSS 속성들도 볼 수 있게 됐다.

그리고 혁신을 이루어낸 것은 버전 0.4 부터인데,

0.3을 기점으로 자체 DOM 검사기를 포함하는 것으로 시작해서, 자바스크립트에 표준 바람을 불게 만든 console 객체를 출시했다. 비록 Firebug 밖에 되지 않았지만, 혁신을 이루게 한 건 사실이다. 귀찮게 로그성 데이터를 DOM에 뿌릴 필요 없었고, 정보도 바로바로 볼 수 있었던 덕에 많은 웹 개발자에게 Firebug는 이제 없어선 안될 도구가 되고, console 객체 또한 조금 늦지만 ECMA 표준에 등재된 쾌거를 이루었다.

그리고 이 주목받은 기능을 등에 업고 1.0을 출시했을 때는 상용 도구로 개발될 예정이었으나, 불여우에 왠 뜬금없는 상용 툴? 뚝.

아 미안. 그냥 공짜임. 콜! 오픈소스다. BSD로. 아주 좋소!

어쨌든, 지금의 Firebug 화면과 유사하게 나온다. 콘솔과 DOM 검사기, CSS와 스크립트 디버거, 그리고 DOM 객체 구조와 네트워크 타이밍까지. 웹 개발에 있어서 제공하는 모든 것들을 제공했다.

현재는 쿠키와 프로파일러, 설정 등 다양한 기능들이 커뮤니티를 통해 제공했다.

그리고 웹 사이트 성능 측정 도구인 YSlow. 웹 개발자라면 다 아는 도구다. 야후까지 가세해서 Firebug는 웹 개발자가 모르면 간첩.

그리고 이에 힘입어 Firebug Lite 까지 출시했는데, Firebug를 다른 브라우저에서 돌리고 웹개발에 편의성을 주도록 개발한 녀석이다.

그래서 오페라 브라우저에 신경쓰는 웹 개발자에겐 가뭄에 비같은 도구로 잘 활용했었다. 지금은 오페라도 자체 개발자 도구 제공해서 상관은 없지만.

IE에게는 가뭄에 산성비같은 도구였다. Firebug가 느리기 때문인데, 이는 Firebug 문제가 아니라 JScript 엔진이 병신같아서 그런 거다. 엔진 자체가 느려 터졌다고.

하지만 IE 8부터 자체 개발자 도구가 생겼으니 굳이 고민을 할 필요는 없어보인다.

현재는 불여우에 자체 개발자 도구로 제공하고, Firebug 보다 더 빠른 성능을 제공해 주지만, 아직도 많은 불여우 기반 웹 개발자는 Firebug를 쓰고 있다.

여담으로, Firebug 또한 한국에서 최고의 개발자 도구로 주목받았을 땐 한글화해준 고마운 사람이 있었다, 하지만 그는 누군지 모르고, 게다가 현재는 Firebug 한글화가 진행되지 않고 있다.

그래서 현재 Firebug 는 받으면 영어로 나오며, Firebug 공식 홈페이지에 한글화 번역자는 등재되지 않고 있다.

왜죠?

6. 개발자 도구의 반격, Internet Explorer.

한국인이야 알다시피 IE는 웹 환경의 혁신(?)을 불러일으킨 브라우저다. 하지만 너무 자체적으로 표준으로만 만들었다 보니 다른 브라우저에서 안되고, 액티브엑스 때문에 갈라파고스화를 만들어낸 주범이었다.

물론 이것도 마소가 독점하려고 일부러 그렇게 만든건 맞다. 하지만 IE의 보안성 부재와 불여우의 선전, 그리고 구글까지 웹 브라우저를 만들고 나서려고 하니 마소에게 똥줄타지 않을 수가 없다보니…

IE 7을 출시했다. 사용자 측면에서는 탭 브라우징이 끝이다. 시발. 장난하냐?

그리고 IE 7의 실패를 맛본 마소는 이번엔 IE 8 을 출시했다. 물론 욕나오는 브라우저긴 하다. 버그 작렬과 쳐진 성능. 즉, IE 6에 익숙했던 똥컴에게 IE8은 지랄같은 존재였던 것이다.

하지만 마소가 이제 점점 웹표준 수순을 밟고 가려는 의도가 점점 보이고 있는 웹브라우저였고,

마소도 몇몇 기술을 웹 표준에 등록했는데, 대표적인 기술이 localStorage 다.querySelector 도 있긴 한데 제한적이니…

참고로 Ajax를 만들어게 이룩한건 IE의 ActiveX 였지만, 모질라의 XMLHttpRequest가 채택되고, IE에서는 XMLDOM 액티브엑스의 래퍼(Wrapper)로 쓰였다.

그리고 IE 8에서 F12를 누르면 개발자 도구가 나오는데, 혁신을 이루게 만든 하나의 기능이 있었는데 바로 “프로파일러”다.

자바스크립트 프로파일러는, 수집하는 동안 사용자가 브라우징하는 동안에 이벤트와 속성, 함수 호출 내역을 기록하는 기능인데, 사실 이걸 재대로 쓰는 개발자는 많지 않지만, 동적 UI 편의성 모니터링과 개선에 이만한 기능이 없다.

그리고 자바스크립트 디버거 성능이 장난이 아니었다. 비주얼 스튜디오로 나태한 디버거를 만들어낸 마소 답게, 비주얼 스튜디오 좀 만졌다면 IE 자스 디버거는 이보다 편할 수 없을 것이다. 굳이 안만져봤다 해도 상당히 좋은 기능으로 자리매김하였다.

하지만 IE 개발자 도구의 단점이 이런 장점을 덮어버렸는데,

DOM 검사기를 제공한 건 잘한 일이지만 동적이지 못한 단점이 있다. 즉, DOM 변경에 대응을 하지 않았다는 것이다. 수동으로 새로고침을 해야지 그 결과를 볼 수 있다. 상당히 불편한 기능이다.

그리고 자바스크립트 콘솔을 제공하는데, Firebug 가 다른 콘솔은 객체만 치면 객체의 대략적인 속성이나 constructor 가 뭔지 알 수라도 있는데, IE에서는 그저 [object] 로 나온다. 시발 어쩌라고.

그리고 네트워크 탭이 없었다. 물론 Fiddler 가 그 역할을 대신해주긴 했지만, Ajax나 동적 스크립트, 그리고 누락된 리소스 알아내는데 Fiddler 켜야 하니 불편하지 않을 수 없었다.

그리하여 IE 9에는 네트워크 탭이 생겼는데, 이녀석인 프로파일러처럼 개발자가 키면 수집하고 안키면 수집 안하는 식이다.

이는 어찌보면 편하기도 하고 불편하기도 한데, 내가 쓴 바로는 그닥 불편하지 않고, 필요한 경우에만 켰다가 필요없는 경우에 끄는 기능도 괜찮다고 생각한다. 키고 끄는게 가능하지만 조금 불편한 감이 있는 Firebug와, 아예 수집만 주구장촹 하는 웹키트 기반에 비해서 IE는 IE만의 특징이 있다고 보면 된다.

IE 10까지 별다른 진척 없다가 IE 11에서 개발자 도구가 플랫 UI를 안고 탈바꿈 하였는데, IE 11의 DOM 검사기는 이제 수동으로 새로고침 안해도 변경되면 반영하게 됐다. 그 외 나머진 별 다를거 없고.

그리고 UI 응답성 테스트가 생겼는데. 그냥 YSlow 비슷하다 보면 된다. 일종의 프로파일러다. UI가 렌더링된 시간을 기록하여 시각적 결과를 제공해준다. 이건 잘만든 기능이다.

이렇게 IE의 개발자 도구도 강력해지긴 했는데, 아직도 고질적인 문제는 IE는 각 버전마다 렌더링이.. 시발.. 아주그냥.. 시발..

7. Webkit, 개발자 도구로 대동단결.

맥으로 웹개발하는 사람이라면 알겠지만, 사파리나 크롬이나 개발자 도구는 똑같이 생겼다. 그 이유인 즉슨, 둘 다 사용하는 엔진인 웹키트가 개발자 도구를 대동단결했으니까. (웹키트 엔진에 번들로 제공한다고.)

웹키트의 개발자 도구는 조금 늦은 감이 있다. 웹키트 자체 DOM 검사기가 2006년에 소개됐으니까.

하지만 초기에 기능이 워낙 강력해서 Firebug 보다 나았던 시절도 있었다는 것.

왜냐면 이녀석은 시각적 효과가 화려하게 제공되고, 자바스크립트 콘솔이 강력했다. 자동완성을 먼저 지원했기 때문이다.

사실 IE 8과 비슷한 시기에 웹키트 기반 개발자 도구가 대중에 공개됐는데, Firebug 에 비해 이녀석은 아예 그냥 모든 사이트라면 F12 만 누르면 죄다 수집하고 분석하고 기록한다.

어찌보면 편하기도 하지만, 프레임으로 지속적으로 불러오는 웹 사이트 구조라면 계속 수집해서 목록이 늘어날수록 성능이 떨어지는 단점이 있다. 이는 어쩔 수 없다.

그래서 조금은 불편한 감이 있기도 하다. 왜냐면 Firebug 와는 달리 특정 기능만 키고 끌 수가 없으니까.

그래도 나름 웹키트 다운 면모가 있다.

그리고 사파리와 크롬은 결국 개발자 도구도 다른 길로 걷게 되는데, 사파리는 웹키트의 주를 이루니 웹키트 흘러가는대로 가지만, 크롬은 웹키트 변형 엔진인 블링크를 만들어 쓰기 시작해서 지금도 비슷하게 생겼지만 점점 달라지고 있다는거.

8. 마치며.

사실 각 플랫폼별로 나열했기 때문에 누가 먼저 하고 그다음 누가 했는지 햇갈릴 것이다. 그건 필자도 인정한다.

한가지 분명한 사실은, 넷스케이프에서 가장 먼저 개발자 도구를 만들기 시작했고, 그 전신을 이어받은 모질라가 먼저 개발자 도구를 만들고 선도한 것은 틀림없는 사실이다.

불여우가 웹 개발자를 위한 브라우저라고 누차 강조한 이유가 그 역사를 달고 태어났기 때문이라고 나는 자신있게 말한다.

어쨌든, 이렇게 개발자 도구가 서로 경쟁하고 선도하고 발전하면서, 웹 개발이 이렇게 발전할 수 있었던게 아닐까 싶다.

웹 디자인도, 웹 개발에 초석이 되지 않았다면, 가뜩이나 웹 디자인에 가장 많은 의존을 하는 CSS 개발도 어려웠을 것이다.

생산성도 향상되고 디자인도 여러가지로 화려해졌지만, 그렇다고 단가가 낮아진 건 아니다.

클라이언트가 요구하는 건 점점 더 다양해지고, 이를 수용할 수 있는 웹 디자이너와 개발자는 그만한 가치가 있기 때문이다.

이렇듯 웹 개발자 도구는, 절대 무시해선 안될 도구다. 특히 웹 개발자는 더. 액티브엑스? 몰라. 그딴거.

개발자 도구. 고맙게 쓰자.

composite / 2014년 2월 10일 / 미분류 / 0 Comments

요즘 웹디자인 대세는 점점 되돌아가는 방향으로 가는 것인가?

아마 앞으로 나간 디자인은 글로시 디자인(Glossy Design)인 것 같다. 확실히 미래지향적으로 느껴지는 디자인이었으니.

PNG의 보급과 CSS 의 입지가 커짐으로써 같이 주목받고 유행했던 디자인이었다. 2012년까지는.

그리고 2013년 플랫 디자인으로 유행을 했는데..

이제는 디자인 패턴이 되돌아보자는 차원인지.. 모르겠다.

물론 이게 나쁜것만은 아니다. 디자이너는 원래 유행을 좇는 종특을 가지고 있다고 하면 디자이너가 나 죽여 팰 것이고.

유행을 만들던 따르던 그건 당신 마음이지만 일단 유행은 그렇다고.

그리고 2013년 후반기부터 플랫 디자인에 힘입어 새로운 패턴이 등장했으니 바로 카드 디자인이다.

님들 페북이나 튓터 많이 하잖아. 글 하나하나마다 영역이 분리돼있지? 그게 카드 디자인이라고. 납득 ㅇㅇ?

어쨌든, 왜 카드 디자인이 2014년 디자인을 유행할 아이템인 것인가?

간단하다. 나 따라해봐.

  1. 니 명함을 본다.
  2. 니 명함을 스마트폰에다 갖다대본다
  3. 올ㅋ

그렇다. 카드 디자인은 모바일 장치에도 대응할 수 있고, 글 하나하나 영역이 뚜렷하기 때문에 어렵지 않게 볼 수 있다는 장점이 있다.

플랫 디자인은 영역이 “공백의 미” 라면, 카드 디자인은 “영역의 미” 인 것이다.

이 카드 디자인의 첫 상용화의 신호탄은 페이스북인가? 아니다. 의외로 새로운 서비스가 신호탄을 때렸다. 핀터레스트다. 사진 기반 소셜. 여자들이 모르면 간첩인 서비스다. (몰랐다구여? 죄송해여.)

페이스북도 사실 카드 디자인을 반영한 것 맞지만, 글로시도, 플랫도 아닌, 뭔가 리트로하고 심플하며 조금이나마 입체감 있는 디자인 패턴이 주류였다. 물론 지금은 IOS 7 신호탄 때릴때 플랫한 카드 디자인을 채용했다. 좀 됐지만.

구글도 이미 이를 따라갔고, 구글쁠라쓰 가면 카드 디자인이 담긴 메시지가 당신을 반길 것이다.

하지만 역시 디자이너의 글이 내 글보다 더 와닿을 것이다. 아래 글을 참고하라.

http://insideintercom.io/why-cards-are-the-future-of-the-web/ (원문)

http://radiofun.tumblr.com/post/60843934125/why-cards-are-the-future-of-the-web (한글번역)

비디자이너가 카드 디자인이 왜 유행인지 한번 내가 납득시켜주겠다.

쿠폰 봐봐. 존나 눈에 확들어오지? 그거야.

카드 디자인의 핵심을 다시한번 짚어보고 끝내겠다.

  • 정보 전달의 집중성.
  • 다양한 활용 능력.
  • 작지만 많은 것을 담을 수 있는 수용력.

ㅇㅋ?

이해 못하겠으면 내가 링크한데 가보랑께?

그럼 끝. 개발자가 존나 나불대봐야 디자이너와 개발자는 논란의 시발점이지. 물론 나처럼 안싸우는 사이도 있긴 하지만.

이렇게 기존에 실생활에 쓰던 디자인이 웹 디자인의 중심이 되고 있다.

그래서 나는 되돌아가는 방향으로 가고 있나 의심을 해봤다.

근데.. 되돌아간다기보다는 되짚어본다가 맞는 것 같다.

카드라고 해서 옛디자인으로 돌아가는 건 아니다. 디자인은 계속 진보되고 있는 사실은 확실하다. 베충이도 이해시켜줄까? 이게 팩트라고.

기존의 것에서 활용하는 것으로 시작된 웹 디자인. 플랫디자인부터 시작해서 카드 디자인,

이제 다음 디자인은 어디서 발견할 것인가? 이목을 집중시킬 만 하다.

진짜 끝.

composite / 2014년 1월 10일 / 미분류 / 0 Comments

독립형 OWIN 기반 웹 서버 – NOWIN

보통 닷넷에서 독립형 웹 서비스를 구현할 때 HttpListener 를 쓸 것이다. node.js 처럼 쉽게 구축이 가능하기 때문이다.

물론 그럴 일은 없겠지. 아무래도 안정화된 IIS로 다들 쓸텐데.

그러고 보니 MS도 OWIN 웹 서버인 Katana 를 만들어서 아직까지는 실험적으로 배포하고 있긴 하다. (모노 지원은 개나 줘버리고)

OWIN 표준은 1.0 으로 안정화가 되어 있지만, 이는 기본적인 웹 서비스를 위한 스펙이며, 아직 부가적인 요소 (웹소켓 등)은 표준을 만들고 있는 중이다.

그러는 와중에 드디어 내가 바랬던 프로젝트가 있었으니.. 바로, NOWIN 으로 OWIN 표준 기반 웹 서버다.

https://github.com/Bobris/Nowin

이녀석은 닷넷 4.5로 만든 웹 서버인데, 가장 큰 특징은 HttpListener 를 안썼다는 것이다.

무슨 소리냐고? 지랄같이 제한적인 기본적인 웹 서버 클래스를 안썼다는 것이다.

이말인 즉슨, 직접 웹서버를 닷넷으로 구현했다는 것이다.

이렇게 되면 모노 지원은 이미 따놓은 당상이며, 웹소켓도 아무렇지도 않게 지원된다.

윈도우 7이나 2008 R2 라도, 닷넷 4.5 깔면은 순수 닷넷으로 웹소켓과 웹서버를 한번에 휘어잡을 수 있게 된다.

아파치의 NIO같은 Non-Blocking I/O 를 직접 구현함으로써 극대화한 웹 서버가 이 프로젝트의 특징이다.

아시다시피 네이티브 웹소켓은 윈도우 2012 에 들은 IIS8에 채용되었다.

지금 윈도우 2012 로 닷넷 돌리는 곳이 얼마나 있을까. 가뜩이나 윈도우 라이센스 하면 치가 떨리는데.

프로젝트가 제시한 특징을 알아보자.

  • Http 1.0 와 1.1 클라이언트를 SocketAsyncEventArgs 클래스를 이용하여 가장 빠르게 인터넷을 구현
  • KeepAlive, 비테스트 파이프라인, 요청/응답에 자동 chunked en/decoding 기능 구현
  • 모든 개체에 비동기를 실현하였으며, 자동으로 병렬 코어로 작동하도록 구현
  • SSL 은 .Net SSL 스트림으로 동일한 보안 시스템 구현
  • WebSockets 을 독립적으로 작동할 수 있다! 따라서 SignalR 을 HttpListener 내장된 Win8 보다 더 빠르게 작동시킬 수 있다.
  • 현재 연결 수, 최대 할당 연결, 할당이 필요한 지 추적하는 기능을 제공한다.
  • 연결당 20kb RAM 정도가 소요되며 대부분 재사용된다. 하지만 절대 할당이 해제되지 않는다.
  • 기본적으로 최대 요청/응답 크기는 8KB 이다.
  • Nuget 으로 쉽게 사용이 가능하며, 종속성이 없다.

보아라. 종속성이 없다고 한다. 닷넷의 코어 기능만을 사용하여 웹 서버를 구현한 것이다. 이제 닷넷판 Netty 가 나온 것인가?

그렇다면 사용법을 알아보자.

Microsoft.Owin.Hosting nuget 사용시 샘플

static class Program
{
    static void Main(string[] args)
    {
        var options = new StartOptions
        {
            ServerFactory = "Nowin",
            Port = 8080
        };

        using (WebApp.Start<Startup>(options))
        {
            Console.WriteLine("Running a http server on port 8080");
            Console.ReadKey();
        }
    }
}

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.Use(context =>
        {
            if (context.Request.Path == "/")
            {
                context.Response.ContentType = "text/plain";
                return context.Response.WriteAsync("Hello World!");
            }

            context.Response.StatusCode = 404;
            return Task.Delay(0);
        });
    }
}

빌더를 사용한 Https 샘플

var builder = ServerBuilder.New().SetPort(8888).SetOwinApp(SomeOwinApp);
builder.SetCertificate(new X509Certificate2("certificate.pfx", "password"));
using (builder.Start())
{
    Console.WriteLine("Listening on port 8888. Enter to exit.");
    Console.ReadLine();
}

마치 node.js 의 http API 와 흡사하다. 거기에다가 대리자를 통한 비동기 처리를 구현하였다.

이정도면 원하는 웹 서버를 쓰기 좋지 아니한가? 모노라도?

안타깝게도 아직까지는 안정성과 보안성을 검증하지 못하였다. 계속 테스트 중이며, 아직 실제로 쓰기에 보장이 전혀 없다.

Fork 는 12 지만 실제 참여자는 2명이다. 아는사람인지 알 턱은 없지만.

하지만 그래도 같이 테스트하고 참여해 볼 만 하다. 순수 닷넷으로 이정도를 구현했으면, 자바 부럽지 않은 웹 어플리케이션이 탄생해도 무방하지 아니한가? 이 NOWIN 을 통하여 Nancy 와 SignalR 조합이면 웹 어플리케이션에 두려움은 없을 것이란 생각이 자꾸 든다. 오호.

물론 ASP.NET 기반은 이걸로 동작이 어려울 것이다. ASP.NET MVC 등이 100% OWIN에도 동작하지 않는 이상은.

왜냐면 이들은 HttpListener 기반으로 돌아간다. 호환성은 망했어요.

닷넷에 이 프로젝트는 심히 기대대뇐 프로젝트다. 계속 눈여겨보고 테스트해야겠다.

근데 나 지금 회사에서 자바개발중이라서 아마 안될거야..

집에서 해야겠네.. 흑.

composite / 2014년 1월 8일 / 미분류 / 0 Comments

composite / 2013년 12월 17일 / 미분류 / 0 Comments

AppHarbor 로 .NET Application 테스트/서비스하기

아오 썅 AppHarbor 쓰는 한국인들 없나? 닷넷이 이렇게 죽었어? 엉? 구글 검색으로도 안나와 어떻게 된게.

그래서 내가 열받아서 쓴다. 참고로 AppHarbor 는 웹 어플리케이션 및 백그라운드 어플리케이션 (걍 콘솔)을 지원한다.

여기서는 웹 어플리케이션을 만들고, 올리고, 보여주는 식으로 강좌를 올리겠다.

AppHarborHeroku 의 .NET 버전이라고 보면 된다고 한다. (어느 외쿡님이)

AppHarbor 는 PaaS 서비스로, 어플리케이션을 올려서 서비스 한다고 보면 되며, 야는 .NET 만 지원한다.

.NET 버전은 csproj 파일에 있는 버전으로 알아채기 때문에 버전이 어떤 거든 상관은 없는데 최신 기술인 4.5 도 지원된다고 한다.

일단 .NET 클라우드 플랫폼에서 웹 서비스만 할거라면.. 무료다. 표를 통해 확인해봅세.

구분 

Azure 웹 무료

 AppHarbor 무료

 앱 개수

사이트 10개

제한 없음

 사이트 개수

 1

1

 저장소 용량

1GB (사이트 공유 총용량)

딱히 없는듯

 트래픽 제한

 일 165MB

월 100GB (작은 Worker) 

 사용자 지정 도메인

지원 안함

추가 요금 (제한없이 10$/월)

 SSL

지원 안함

기본 SSL 지원, 개별 별도 요금

 DB

MSSQL 전용 20MB 제공

 확장을 통해 무료 MSSQL 공유 20MB

MySQL 및 MongoDB도 있음.

 협업

불가능 (웹 게시 방식)

Git 를 통해 가능

 비고

 90일 무료 체험 가입해야함

그냥 가입하고 쓰면 됨

구분 

Azure 웹 서비스 표준

AppHarbor CATAMARAN

월 가격 (최소 인프라)

75$

49$

사이트 개수

100

1

 인스턴스 개수

 10

2

 사용자 지정 도메인

 지원

지원

 SSL

 별도 추가 요금

지원

 DB

 마찬가지이며 추가시 별도과금

마찬가지이며 추가시 별도과금

 협업

 불가 (웹 게시 방식)

Git 를 통해 가능

 저장소

10GB (사이트 공유 총용량)

 제한 없음

요금제 분석

 작은 여러 사이트 운영시 유리한 요금

큰 단일 사이트 운영시 유리한 요금

딱히 놓고 보면 AppHarbor 가 가격 면에서 비싸보인다. (솔직히 비싼것 같다.) 하지만 무료 환경이 좋다. 그래서 소개하는 것이다.

유료 요금제 분석 내가 가격과 스펙을 봤을 때 아무래도 이렇게 쓸 때 좋겠다는 주관적 입장일 뿐이며, 자세한 사항은 직접 가서 비교하기 바란다.

AppHarbor 는 Worker Scale 에 자세한 스펙을 표시하지 않았다. 그래서 한번 찾아봤더니 다음과 같이 나온다.

One worker is currently limited to roughly 50% of an AWS Elastic
Compute Unit (ECU) which is equivalent to 500-600 MHz. The worker
is allowed to consume up to 512MB of RAM (soft limit) and there’s a
1GB hard RAM limit. You might also want to check out the limits
section of our program policy which
specifies other limits of interest.

Limits

AppHarbor has soft and hard limits for the use of its services. Hard
limits are automatically enforced and soft limits are consumable
resources that you agree not to exceed.

  • Network Bandwidth per Worker Unit: 100GB/month – Soft
  • Shared DB processing: Max 200msec per second CPU time – Soft
  • Request timeout: 30 seconds – Soft; 120 seconds – Hard
  • RAM usage per Worker Unit: 512 MB – Hard (if you only have a single
    worker unit per worker the limit is: 512MB – Soft; 1024MB – Hard).
    Workers are restarted/recycled when exceeding this value).
  • CPU resources per Worker Unit: ~600MHz – Hard
  • Requests Queue limit per Worker Unit: 500 Requests – Hard

Worker 하나당 500MHz, 반기가헤르츠의 처리 속도와 512기가의 RAM을 제공받는다고 보면 된다. (물론 기본 Worker 당 스케일 늘리면 당연히 늘어나겠지만)

그리고 트래픽 100기가, 공유 DB의 경우 처리 속도가 200밀리초 미만, 최대 요청 시간 30포, 500개의 요청 대기를 지원한다.

그리고 RAM 의 경우 허용 크기를 넘어버리면 Worker 가 다시 시작된다. 사이트를 다시 시작한다는 뜻이다. 그렇게 되면 세션같은 메모리에 적재된 데이터는 날라간다. 무분별하게 메모리 내에 객체를 담는 것은 지양해야 할 것이다.

하지만 이정도 사양이면 사이트 테스트및 개인 연습 사이트 운영 등에 지장이 없다. 대국민 서비스는 젭알.

자. 이제 AppHarbor 로 어플리케이션을 어떻게 배포하는지 알려주도록 하겠다.

필자는 Nancy 로 만든 ASP.NET 웹 프로젝트를 만들었다. ASP.NET MVC 써도 되고 걍 ASP.NET 써도 되고

여의치 않는 사용자는 WebMatrix 로 만든 웹 사이트도 가능하다.

비주얼 스튜디오에서 웹개발 하는 사람이라면 알겠지만, 폴더 단위 프로젝트가 웹 사이트며, WebMatrix 는 웹 사이트 프로젝트만 지원하기 때문에 sln 파일이 따로 없다. 없어도 된다. 그래서 AppHarbor 에 올릴 때 솔루션 파일 (sln)이 없으면 웹 사이트 프로젝트로 취급되어 빌드되고 실행된다.

프로젝트 개수에 상관없이 sln 파일이 있고, 그 하위에 프로젝트 있는 구조로 올리면 된다.

어떤 프로젝트는 sln 이 별도 폴더에 있고 실제 프로젝트는 다른 경로에 있는데 그렇게 하면 잘못 판단하여 빌드 안되므로 유의.

즉, 이렇게 하라는 거다. 올바른 앱 폴더 구조는 다음과 같다.

AppHarbor_Test (앱 최상위 폴더)

└ Project1 (클래스 라이브러리 폴더)

└ ASPNETMVC (웹 프로젝트 폴더)

└ MyApp.sln (솔루션 파일)

또는

AppHarbor_Test (앱 최상위 폴더)

└ App_Data (폴더)

└ Index.aspx (페이지 파일)

└ Global.asax (웹 설정)

└ MyClass.cs (임의 클래스)

└ Web.config (웹 설정)

└ MyApp.csproj (프로젝트 파일)

└ MyApp.sln (솔루션 파일)

아래와 같은 앱 폴더 구조는 올바르지 않다. (웹사이트로 인식되어 올바르게 사이트 뜨지 않는다)

AppHarbor_Test (앱 최상위 폴더)

└ Sln (솔루션 폴더)

    └ MyApp.sln (솔루션 파일)

└ Project1 (클래스 라이브러리 폴더)

└ ASPNETMVC (웹 프로젝트 폴더)

<

p>

이렇게 해서 프로젝트를 만들거나, 기존 웹 되는 프로젝트를 먼저 준비한다.

그리고 아래 프로그램이 있어야 한다.

  • Git for Windows (Github for Windows 는 Github 연동일 때만 해당) (필수)
  • TortoiseGit 또는 Git Extensions (마우스 클릭으로 하고 싶으면 설치, 콘솔로 하겠다면 비설치)
  • Git Source Control Provider for VS2012 (있으면 편하고 없어도 무방)

Git 쓰는 방법은 귀찮아서 패스. 구글 검색하면 흔하디 흔하게 나온다.

AppHarbor 가입하는 방법은 간단하다. 메인 페이지에서 GET STARTED NOT 버튼을 클릭하여 이메일, 아이디, 비번 세가지만 쓰면 된다. 그럼 인증메일이 오는데 인증메일 링크를 클릭하고 로긴하면 가입절차가 끝난다.

그러면 Create New Application 나오는데, 원하는 이름을 입력하고, 서버 위치 선택 후 만들면 된다.

서버 위치가 미국, 유럽, 미국베타가 있는데 걍 미국 선택 후 만든다.

그런 다음, 왼쪽 메뉴 하단에 REPOSITORY URL 버튼이 보일 것이다. 클릭하면 URL이 복사된다.

Git 원격 URL을 복사된 URL로 쓰면 된다.

특이한 점은 비밀키 생성된 파일을 요구하지 않고, 비밀번호만 요구할 것이다. 원체 윈도우다 보니 HTTPS 프로토콜만 제공하나보다. 물론 비밀키파일 생성하고 원격에 등록하면 매번 비번 입력하는 귀차니즘 없이 쓸 수는 있는데.. 안타깝소.

그리고 메뉴에 Hostnames 가보면 생성된 URL이 뜨는데 이게 당신이 만든 웹 사이트를 접근할 URL 이다.

안타깝게도 사용자 지정 도메인은 유료이기 때문에 운영할 맘이 없다면 그냥 기본 제공 도메인을 쓰도록 한다.

다음으로, DB를 쓰도록 하자. AppHarbor 사이트 위에 대메뉴에서 Add-ons 가면 되는데, MySQL, PostgreSQL, MSSQL 등의 SQL DB가 지원되고, MongoDB, Redis, CouchDB 등의 No-SQL 디스크 기반 또는 메모리 DB를 사용할 수 있다.

무료 플랜도 찾아보면 나오며, 테스트로 쓸수 있고, 경우에 따라 원격 접속도 가능하여 확인도 가능하다.

MSSQL 쓰려면 맨 아래로 스크롤 이동하면 나오는데, Yocto 가 무료다. 공유된 SQL 환경에서 20MB 무료로 제공한다.

주저없이 테스트 해주자. 당신의 컴터에 매니지먼트 스튜디오 등의 DB 클라이언트 있으면 거기서도 접속 가능하므로 참고.

composite / 2013년 10월 7일 / 미분류 / 2 Comments

윈도우 애져 후기 – Java in Windows Azure

왜 신개념 후기라면 바로 대우형님께서 제안하던 비주얼스튜디오로 배포하는게 아닌.. 바로!

http://allthingsd.com/files/2013/01/java_skull_crossbones-380x246.jpg

이겁니다. 아시다시피 자바죠. 위에 해골바가지가 왜 있냐구요? 아시는분은 아시겠지만 큰 보안이슈가 있었습니다.

오라클에서 미국의 강경대응 나오자 무섭게 발빠르게 보안 업데이트를 제공해줬습니다. 그러나…

한국에서는 보안 업데이트조차 두려워합니다. 비용도 들고 그동안 서비스 중단해야 하고…

그래서 한국 자바진영엔 결국 별다른 조치를 취하지 않았죠.

그러니..

http://cfile1.uf.tistory.com/image/12109D494FF40580148167

그러니까 개발자들은 자바를 멀리하고 닷넷을 가까이 하는 게 낫습니다.

…라고 하면 한국에서 쫒겨납니다.ㅋ

어쨌든 마소가 자바를 위한 애져 배포 환경을 제공했습니다. 그것도 오픈소스로.

공식적으로 이클립스 배포 환경이 제공되죠. http://www.windowsazure.com/en-us/develop/java/

이번 후기는 만약 가상머신이었다면 자바 쉽게 돌려보려고 했는데 인프라 서비스로 제공되는 바람에..

하지만 자바 하겠다고 했으니 해야죠.

먼저 개발 환경을 구축해 보겠습니다. 이클립스를 실행 후 Install New Software 가겠습니다.

1.png 

저장소 하나를 추가합니다. 이름은 아무렇게나 하고, 주소는

http://dl.msopentech.com/eclipse 되겠습니다.

2.png 

그러면 애져가 떡하니 뜹니다. 깔아주십시다. 깔아주는 과정이야 이클립스 확장 추가하는거와 별 다를 거 없습니다.

그리고 이클립스 재시작하면 툴바에 애져 로고가 뜰테고.. 어쨌든 프로젝트 하나 추가하도록 하겠습니다.

근데 안타깝게도 바로 나와 있지 않으니 Other 해줘야겠져죠.

3.png

이제 애져를 찾아볼까요?

4.png

오 요깄군요. 애져 배포 프로젝트. 추가해주겠습니다.

5.png

프로젝트 이름을 아무렇게나 정해주시고.

6.png

JDK 어딨냐 정해주도록 하겠습니다. 저같은경우는 무설치(포터블) 환경을 선호하는 탓에 수동으로 정해줬습니다.

7.png

웹 프로젝트를 한번 해볼까 해서 이번엔 톰캣 경로를 지정했습니다. 배포하면 JDK와 톰캣까지 같이 배포되겠습니다.

그래야 웹 어플리케이션이 돌아가죠. 애져 클라우드에는 암것도 없습니다. 닷넷만 딸랑 있죠.

8.png

그리고 배포한 웹 앱 파일을 지정해 주겠습니다. 헬로우 월드~

9.png

마지막 단계입니다. 세션 유지 정책과 캐시 정책, 원격 디버깅을 제공해줍니다. 자바 개발자에게 디버깅은 필수겠죠.

이렇게 해서 프로젝트를 다만들고 나면 구조는 요로코롬 생겼습니다.

10.png

왠지 조금 복잡해 보이긴 하지만 기분탓이겠죠.

여기서 여러분이 자주 만질 곳이 바로 startup.cmd 와 run.cmd 그리고 package.xml 입니다.

샘플에 startup.cmd 예제가 있습니다. 톰캣 예제가 하나 있습니다.

저는 이걸 복붙신공을 날렸습니다.

11.png

대충 준비가 됐으니 이제 배포 단계로 넘어가겠습니다. 프로젝트에 마우스 오른쪽 클릭하면…

12.png

Deploy to Windows Azure Cloud 가 있습니다. 클릭!

13.png

이제 여러분의 애져 환경을 세팅해야 하는데.. 모르면 그냥 저 따라하세요.

윈도우 애져에는 배포환경 세팅 파일을 제공해줍니다. 이거 하나면 여러분 애져 환경은 세팅 끝나죠. 빨간박스를 누르면…

14.png

조그만 창이 뜨는데. 먼저 빨간 박스 버튼을 누르면 창 하나 또 뜨면서 애져 로긴창이 뜹니다.

로그인 해주면 알아서 바로 다운로드 해줍니다. 다운 받아 주시고,

아래 Path 에 다운받은 세팅 파일을 불러와 주시고 OK 만 눌러주면 됩니다.

15.png

그러면 애져 계정 세팅은 끝!

 16.png

이건 원격 데스크탑에 접속하기 위한 환경설정입니다. 자바 앱이 잘돌아가는거 확인은 해야죠. 가뜩이나 콘솔 기반인데.

애져는 친절하게도 이렇게 원격 데스크탑으로 들어가서 자바앱이 잘 돌아가나 확인을 할 수 있는 환경을 제공합니다.

여러분이 설정할 것은 원격 데스크탑 아디와 비번입니다. 나머지는 냅두는 것이 정신건강에 이롭습니다.

인증서 다룰 줄 아시면 인정서 바꾸셔도 됩니다.

그리고 원하시면 맨 아래 “배포후 원격 데스크톱 시작” 체크해서 배포 끝나고 바로 원격 데스크탑에 들어갈 수도 있습니다.

이제 최후의 버튼인 Publish 가 있습니다. 눌러주면 애져로 배포 시작합니다.

17.png

솰라솰라솰라…

18.png 

Staging 은 그냥 개발 환경이라 생각하시면 됩니다. 그밖에 Production 이 있는데 그건 실제 운영 환경이죠.

애져는 이렇게 두가지 환경으로 테스트와 서비스를 넘나들 수 있기 해줍니다.

이제 배포중인 걸 확인해 봐야죠? 애져 관리자 페이지에 들어가 보겠습니다.

19.png

여러분이 선택한 앱클라우드에 인스턴스 하나 저렇게 떡하니 뜨면 끝!

어때요. 자바도 참 쉽죠?

마소가 어떤 언어던 정말 배려를 많이 해준 듯 합니다.

이렇게 쉽게 배포가 가능하다면 자바 웹 프레임워크의 유망주인 Play! Framework 도 쉽게 배포할 수 있다는걸 알게 됐습니다.

비록 가상운영체제처럼 자유도가 조금 떨어지지만, 애져의 IaaS 를 활용하여 어떤 앱이던 그냥 배포만 해도 바로 테스트하고 서비스할 수 있는 환경을 만들 수 있다는거에 놀라움을 금치 못했습니다.

근데 한글 메뉴얼이 없는게 아쉽기도 합니다. 뭐.. 자바진영에는 애져를 거들떠도 안볼거라는 슬픈 현실이 있지만..

JSP 커뮤니티에서도 이슈 다뤄본 것도 없다능. 근데 클라우드는 운영체제 막론하고 돈이 드는건 사실이잖아요.

한국에서 클라우드와 언어의 다양성 존중과 다양한 접근이 개발자에게 필요한 시점이긴 하죠.

물론 개발자 천국이라는 제니퍼소프트같은 회사가 아니라면 어려울 것 같긴 하겠지만.

저같이 팍팍한 프리랜서 뛰면서 자유를 갈망하는 개발자도 이런 새로운 시도를 하는데..

여기서 MSSQL 만지는 자바개발자분들 있다면 한번 도전해보세요. 다음 애져 체험이 언제일지는 모르겠디만

아마 또 이 서비스로 체험 이벤트 뜰지도 모를 일이지만.

이것으로 후기를 가장한 팁을 마치겠습니다.

감사합니다.

composite / 2013년 3월 7일 / 미분류 / 0 Comments