Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.
RetroTech 팟캐스트 44BITS 팟캐스트

IBM dW Live! 세미나 "웹 개발 다반사" #1

5일(토)에 IBM에서 하는 developerWorks Live! 세미나 "웹 개발 다반사"에 참석을 하고 왔습니다.

IBM dW Live! 로고

최근에 dW에서 세미나를 많이 하는 느낌이었는데 실제로 참석한 것은 처음이었던 것 같습니다. 이번 웹개발 다반사는 Pecha Kucha형식의 발표세션과 개발자의 수다로 진행이 되었습니다. 페차쿠차는 프리젠테이션 젠에서 처음 알게 되었는데 20장의 PPT를 장당 40초로 6분간 발표하는 형식입니다. 장당 40초이고 자동으로 40초가 지나면 다음 페이지로 넘어가게 되기 때문에 발표자는 6분내에 자신이 말하고 싶은 것은 모두 담아야 합니다. 처음 알았을때 꽤 흥미롭겠다 싶었는데 이번 dW에서는 15장당 30초로 진행을 하였습니다.



Pecha Kucha
페차쿠차형식이라서 많은 내용을 정리하기는 어려웠고 그냥 들으면서 인상적인 내용들만 적었습니다. 누락된 내용도 꽤 많습니다. ㅎ




Realtime Web 간보기 - 김석준
김석준님은 요즘 많은 기대를 받고 있는 Comet에 대한 얘기를 하셨습니다.  Comet은 아시다시피 클라이언트가 요청해서 결과를 받는 것이 아니라 서버가 Push를 해주는 것을 말합니다. Comet의 구현방법은 아주 많이 있지만 이것들을 총칭해서 Comet이라고 부릅니다. Jetty 서버등이 있고 브라우져랑 WAF가 통신을 하고 Comet용으로 Orbited라는 Comet서버가 브라우저랑 통신을 하게 됩니다.
WebHook은 코멧과는 다른 방식으로 서버가 특정 callback을 두고 callback을 실행시키는 방식입니다.
XMLPP는 메신저용 프로토콜로 Push를 하며 Google talk등에서 쓰이고 있습니다. HTTP와는 다른 프로토콜이므로 HTTP랑 연결하기 위해서는 Bosh라는 코멧기술이 필요합니다.
Juggernaut는 플래시의 XML 소켓을 이용해서 리얼타입통신을 사용합니다.
원래도 자바애플릿을 이용한 서버 푸시가 존재했습니다.
HTML5에는 Web Socket이 포함되어 곧 소켓통신이 다시 돌아올 것입니다.

최근 Comet에 관심을 가지고 있기 때문에 내용에 관심이 갔습니다. 워낙 방대한 주제라서 시간내에 담기는 부족하기는 했지만 개념만 알고 구체적인 내용을 잘 몰라서 궁금한게 많았는데 관련 기술들을 찾아볼 수 있는 정보들을 좀 얻을 수 있었네요. 워낙 방대한 내용이라 시간내에 다 설명하기 쉽지 않아보이셨습니다.



추상 계층의 딜레마 - 황대산
사람들이 항상 좋다고 생각하는 것들이 있습니다. 코드재사용이 그런데 추상계층 또한 그러합니다.
추상계층의 첫번째 문제는 추상계층은 자연어와는 달리 인위적으로 만들어진 것이고 모든 상황을 고려해서 만든것이 아닌 그때그때 필요해서 우발적으로 만든 것입니다. 그리고 사용자와 만든 사람이 다릅니다.
두번째 문제는 추상계층에서 설게자는 신입니다. 많은 개발자들이 신을 꿈꾸지만 괴팍한 신이 너무 많습니다.
세번째 문제는 추상계층이 SW산업의 수익모델입니다. 올바른 추상계층 설계와 매출극대화가 일치되지 않으며 어설픈 추상계층을 통해서 기술지원과 교육등을로 수익이 되고 있습니다.
추상계층 밑으로 내려갈 수 있는가를 생각해 보아야 합니다. 모두 추상계층 위에서만 개발을 하고 있어서 어려운 문제는 해결하기가 너무 어려워 지는데 추상계층 밑으로 가는 것이 생각보다 어렵지 않고 밑으로 내려가면 월씬 단순하게 문제를 해결할 수 있습니다.

이름만 알고 있던 황대산님을 처음 뵈었습니다. 나중에 개발자들의 수다에서 얘기가 나오지만 실제 추상계층 밑으로 내려가서 작업을 많이 하고 계시더군요. 개인적으로 추상계층을 좋아하기는 하고 충분하다고 생각하고 있는데 그런 선입관에 같혀있는건 아닌지 한번 생각해 볼 만한 문제인듯 합니다. 정해진 시간내에서 설명하시려다 보니 말이 너무 빠르시더군요. ^^



괜찮은 오픈 API 제공하기 + VLAAH API 소개 - 홍민희
말로만 RESTful API라고 하는 것이 너무 많습니다. 왜 api.YourURL.com같은 도메인을 만드는 것인가요? HTTP 규약에는 내용협상에 대한 정의가 있습니다. accept입니다. 같은 도데인에 accept를 이용해서 처리할 수 있습니다.
예쁜 URL이 좋은 URL은 아닙니다. url/page/2같은 것은 같은 내용을 보장해 주지 못하기 때문에 url?page=2처럼 작성해 주는 것이 낫습니다. API 버전도 내용협상으로 하는 것은 어떠할까요? Deprecated된 버전은 언제까지 보장되는지를 표시해 주는것이 좋고 협상(accept)결렬되었을 때는 그냥 에러를 내는 것이 좋습니다.
인증은 HTTP에 이미 인증에 대한 헤더가 있기 때문에 다른 방법을 고민할 필요가 없습니다. Sandbox를 제공하는 것도 중요합니다. VLAAH에서는 샌드박스외에 모든 것을 제공하고 있습니다.

야간개발팀에 홍민희님의 발표였습니다. REST에 대해서 많이 알고 계셔서 도움될 만한 내용이 많았습니다. 나중에 알고 보니 나이도 22살이시던데 역시 실력은 숙련의 시간에 대한 것이지 나이가 아니군요. 말씀도 잘하시고 나중에 RESTful할때 생각해 보아야 할 문제인듯 합니다.



(Startup기업 CEO의 관점에서 본) 기술의 경제학 - 정지웅
스타트업회사는 비용에 민감하며 변화에 대한 비용에 더욱 민감합니다. 기술을 필요한 만큼만 사용하고 완성도보다 속도가 중요하며 빨리 변화해야 합니다. 이것이 스타트업만의 이야기인가?
경영자들은 왜 Agile을 싫어하는가? 경영자들은 변화의 비용을 싫어합니다. 애자일은 만능이 아닙니다. 애자딜은 변화의 비용을 복리로 나누어 받는 것입니다. 워터풀은 단계별로 되어 있어서 경영자가 변화비용을 예측하기 쉽지만 애자일은 그렇지 않기 때문에 경영자의 입장에서는 답답합니다.
최근 실리콘밸리에서는 Lean Startup이 뜨고 있습니다. 애자일을 하면서 나온 데이터, 피드백, 인사이트를 경영자에게 다시 알려주어 경영자입장에서의 불확실성을 줄여주는 것입니다. 애자일의 가치는 이터레이션을 통해서 불확실성을 줄여나가는 것입니다. 개발자들이 이러한 변화비용을 너무 무시합니다.
이제는 Hacker의 시대는 지나가고 Creator의 시대가 왔습니다. 이젠 기술이 아닌 가치를 두는 Creator의 시대입니다. 기술은 가능성에 불과하며 그 대표적인 것이 Twitter입니다. 기술에만 집중하지 말고 사용자와 컨텍을 해보시고 사용자의 가치를 보는 것이 중요합니다. 개발자 이상의 크리에이터가 되세요.

최근 플라이팬을 창업하신 정지웅님의 스타트업에 대한 얘기였습니다. 개발을 정말 좋아하시고 신기술에도 민감하신 정지웅님의 시각이라서 좀더 맘에 와닿았던것 같습니다. 저도 기술에 민감한 사람이고 좋아하긴 하지만 실제 회사업무나 수익창출과는 연결되지 않기 때문에 고민도 많았는데 좀 생각해 볼만한 문제입니다. 개인적으로는 기술을 하는 사람과 가치를 연구하는 사람이 분리되는 것도 괜찮지 않은가도 생각하지만 양쪽모두 기술과 가치에 대해서 균형을 잘 맞출필요는 있는것 같습니다.
세미나도 몇번 들은적 있고 온라인에서도 커뮤니케이션 한적 몇번 있어서 인사를 할까 하다가 계속 다른 분들과 얘기중이시기도 하고 아실까하는 불안함으로 인사하지 않았는데 정지웅님이 먼저 나를 알아보시고!! 인사를 해주시더군요. 왠지 기분 좋더군요. 플라이팬 화이팅입니다!! ㅎㅎ 담에 뵈면 꼬박꼬박 인사드리겠습니다. ^^



봄싹 싸이트 개발 협업 방법 및 사용 기술 - 백기선
처음에 모였을때는 5달동안 매주 공부만 하였지만 써먹지 못하는 스터디는 그만하자는 생각이 들었고 만들면서 아이디어를 계속 추가하고 있습니다. 이번 봄싹을 개발하면서는 Spring, Hibernate, jQuey, Spring Security, Spring Web Flow등을 사용하였으며 구글 그룹스와 SCM, CI툴을 통해서 협업을 하며 온라인으로만은 한계가 있기 때문에 매주 혹은 격주로 오프라인에서 모이고 있습니다.
좋은 점은 팀워크가 향상되고 다양한 기술을 습득하고 실험적인 시도를 해볼수 있다는 것이지만 안좋은 점은
낮에도 코딩하고 밤에도 코딩하고 주중에도 코딩하고 주말에도 코딩한다는 것인데 왠지 좀 인간답지 않지 않나요?

아무래도 봄싹에 나가고 있어서 제가 딱히 정리할 내용은 없었네요. 마지막 말은 좀 인상적... 흠.. 싫은건 아니지만 고민은 좀 해보아야할 문제.. ㅎ



흑백무성영화한편! (HTTP) - 이동욱
1990년에 HTTP가 나왔습니다. 기술이 계속 파생되었기 때문에 최하위단계레서 보면 봐야할 기술이 너무 많습니다. 하지만 기술을 위에서 부터 바라보게 되면 파생되어도 공통분모를 계속 가지고 있기 때문에 익히기가 쉽습니다. 웹에서는 HTTP가 그 역할이라고 생각합니다. HTTP를 이해하는데 가장 좋은 것은 HTTP 1.1 W3C 스펙을 읽어보는 것입니다.
파인말이 이런 말을 했습니다. 아주 초심자가 이해할정도로 설명할 수 없으면 이해한 것이 아니다.

HTTP처럼 너무 당연하게 받아들여져서 깊게는 모르는 내용에 대한 지적이있는데 공감되는 내용이었습니다.  특히 기술을 위에서 부터 쫓아가면 더 접근이 쉽다는 말은 인상적이었습니다. 전 아래부터 보느라고 너무 힘들었었죠. ㅎ 황대산님이 말씀하신 추상계층에 대한 얘기하고도 좀 비슷한것 같기도 합니다. 시간에서 스펙도 한번 읽어봐야겠네요.




글이 길어져서 나워서 정리합니다.
IBM dW Live! 세미나 "웹 개발 다반사" #1로 이어집니다.
2009/12/06 22:38 2009/12/06 22:38