StudioEgo's Thoughts, seasonⅡ

이 내용은 일본 IT잡지 WEB+DB Vol.89의 특별기고 “YAPC::Asia Tokyo 2015″의 요약, 축약 번역이며, 발표때 공개된 발표 동영상과 슬라이드를 한국어 사용자들을 위해 공유합니다.

잡지 내용은 요약, 축약 번역이기 오역. 직역체가 난무합니다. 잡지 내용의 일본어를 완전히 아는 것이 아니므로 동영상과 슬라이드를 참조하여 이 글을 구성하였습니다. 전체 글에 대한 번역은 아닙니다.

そして今回は@VienosNotesさんによるYAPC::Asia 2015のレポートも掲載。Larry Wallの基調講演（トールキン話だ！）など3つをピックアップしてご紹介しています。Perl 6もリリース間近ですね……みなさんもう試されましたか……？ #wdpress

— WEB+DB PRESS編集部 (@wdpress)

2015년 10월 26일

번역(飜譯,Translation)

그리고 이번엔 @VienosNotes씨의 YAPC::Asia 2015의 보고서도 게재. Larry Wall의 기조강연(톨킨이야기다!)등 3가지를 선택해 소개하고 있습니다. Perl 6도 출시 임박이네요 ...... 여러분 이제 시도했습니까 .....? #wdpress

青木大佑(AOKI Daisuke, 아오키 다이스케) 

Twitter: @VienosNotes 

2015년 8월 20일부터 22일에 걸쳐, 도쿄 빅사이트에서 "YAPC::Asia Tokyo 2015"가 개최되었습니다. 올해는 10회째로 열린 YAPC::Asia이지만, 이번 행사는 마지막으로 발표되는 것도 있고 훌륭한 토크가 몇몇 있었습니다, 그 중 몇가지를 소개합니다.
-----

メリークリスマス！ / Larry Wall(메리크리스마스/래리 월)

Perl6와 반지의 제왕(Perl6と指輪物語)
기조연설은 Perl을 만든 아버지로 알려진 Larry Wall씨가 “메리크리스마스!”을 이야기 하였습니다. Larry Wall씨는 J.R.R. Tolkien씨의 “호빗"과 "반지의 제왕” 2개의 소설의 관계를 Perl5와 Perl6의 관계 간의 동통점이 많다는 것을 이야기 했습니다.
“호빗”을 출간한 후로, 톨킨(Tolkien)이 15년의 세월동안 "반지의 제왕”을 완성한 것과 같이, Perl6도 올해에 발표까지 15년째입니다.  지금까지, "반지의 제왕"과 “호빗”의 줄거리를 바탕으로 좋은 작품이 되었습니다만, Perl6도 다양한 컨셉(개념)을 Perl5에서 가져와, 좋은 언어를 목표로 하였습니다
그러나 "표현력이 뛰어나다, 쉬운 것은 쉽게, 어려운 것일수 있다”는 점을 Perl5에서 받아 연결한 이념을 이야기 하였습니다 그래서 Larry Wall씨는 “제대로 실패”라는 것의 중요성을 강조하였습니다. Perl6를 좋은 것으로 모으기 위하여 여러가지 신기능을 검토하였습니다. 좋은 아이디어로 판명하는데 시행착오 중의 흥미를 깊이 끄는 심층 조달를 여러가지 범 지금까지 “약속은 할 수 없지만”이라고 전제를 한 뒤, 올해의 크리스마스는 Perl6을 릴리즈할 예정입니다. 이것이 오늘의 발표입니다. 기대되네요!

ps. 역자주: 영화 및 책  The Hobbit(한국어명: 호빗)을 일본에서는  ホビットの冒険(호빗의 모험)으로 번역되었고, The Lord of the Rings (한국어명: 반지의 제왕)을 일본에서는 指輪物語(반지이야기)로 번역이 되었습니다. 번역자는 한국어 사용하는 독자를 위해   ホビットの冒険(호빗의 모험)를 “호빗”이라고 번역 및 指輪物語(반지이야기)를 "반지의 제왕”이라고 번역했습니다.


세계규모서비스를 디플로이하는 방법

世界展開する大規模ウェブサービスのデプロイを支える技術 (글로벌 출시하는 대규모 웹서비스의 디플로이를 지원하는 기술)

Miiverse는 멀티 디바이스에 대응하는 커뮤니케이션 서비스입니다. 구조는 일반적인 웹 서비스와 대체로 같습니만, 일본, 미국, 유럽의 3개의 지역에 걸친 세계규모의 디플로이는 특유의 곤란함을 가지고 있습니다. 처음에는 Git을 사용한 pull형의 배치를 하고 있습습니다만, 부하의 높이와 Github Enterprise를 사용한 개발 모델과의 상성이 불편한 문제등이 있었습니다, 우선 서브프로젝트를 위한 새로운 디플로이툴을 작성하기로 결정했습니다.
이 새로운 디플로이툴은 내부는 Consul과 Stretcher같은 툴을 이용하여 효율적인 디플로이를 실현하고 있습니다. 버젼업할때, 성과물을 Amazon S3등의 스토리지들에 설치하고, Consul의 이벤트기능을 사용하여 각호스트에 요구를 통지하였습니다. 통지를 받은 호스트는 디플로이 순서로 성과물을 받아서, 메니페스토 파일(Manifesto file)을 바탕으로 아티팩트(Artifact)를 검색하고 배포를 실행하는 흐름입니다. 이 새로운 도구의 벤치마킹에서 기존의 수법을 비교하여 약 40배의 퍼포먼스를 발휘하는 대성공을 하였습니다.


HTTP/2시대의 웹(HTTP/2時代のWeb)

HTTP/2시대의 웹(HTTP/2時代のWeb) / jxck

HTTP/2는 브라우저등의 통신에 이용하는 HTTP/1.1의 차기버전이고, 올해 2월달에 RFC7540으로 책정한 새로운 사양입니다. 웹의 진보에 따라 리퀘스트 숫자도 1회당 전송량도 증가를 하였습니다. HTTP/2는 이러한 문제를 해결하기 위해 다양한 방법이 도입되었습니다. jxck씨에 따르면 HTTP/2는 책정phase부터 사용phase로 이행했다고 합니다. HTTP/2는 이미 많은 브라우저에 대응되어 있으며, 웹서버에도 대응하는 것이 많아지고 있습니다. 에코시스템(생태계)의 성숙을 위해서도, 구조를 이해하고 있는 상태로 전환이 중요하다고 언급

아래는 "HTTP/2시대의 웹(HTTP/2時代のWeb)"의 발표슬라이드 입니다.

Java의 HTTP/2 지원과 Servlet 4.0에 대하여 소개한 슬라이드

HTTP/2 Comes to Java What Servlet 4.0 Means to You

ps. HTTP(HyperText Transfer Protocol)을 "하이퍼본문전송규약"으로 번역하기도 합니다.

더 빠른 웹을 위해: HTTP/2

웹의 진화를 그래프로 잘 설명한 사이트를 소개하겠습니다.

The Evolution of the Web(http://evolutionofweb.appspot.com/) 이라는 사이트입니다.

위의 사이트에서는 1990년, 팀 버너스리가 웹(HyperText Transfer Protocol)을 창시한 것을 시작하여 웹브라우저들의 생성부터 소멸, 그리고 생성후 발달 과정, 그리고 웹 기술(Web Technology)들을 일목요연하게 설명합니다.

웹에 관심 많은 사람이면 꼭 들어가서 Web의 역사를 꼭 봐야합니다. 이런 웹의 역사 및 진화를 볼때마다 재미있게 보여요. 그러나 기술은 너무 많이 발전되어서 저도 따라가기가 힘드네요.

아래는 웹의 발전을 소개하는 영어 글귀입니다.

The web today is a growing universe of interlinked web pages and web apps, teeming with videos, photos, and interactive content. What the average user doesn't see is the interplay of web technologies and browsers that makes all this possible.

Over time web technologies have evolved to give web developers the ability to create new generations of useful and immersive web experiences. Today's web is a result of the ongoing efforts of an open web community that helps define these web technologies, like HTML5, CSS3 and WebGL and ensure that they're supported in all web browsers.

저는 Nokia 6210s라는 스마트폰을 사용하는 대학원생이면서 모바일 다음을 애용하는 사용자입니다.

이번에 Daum 모바일TF Daum모바일, 웹어워드코리아2009 모바일웹 이노베이션 대상 수상~!을 받았다고 이벤트를 준비하였다는걸 알게 되었습니다.

# 관련기사 바로보기 - 모바일화면

# 다음 모바일웹 서비스 소개 보기 - PC화면

# 다음 모바일웹 체험 하기 - 모바일화면

# 웹어워드 코리아 2009 수상내역 자세히보기 - PC화면

그리하여 모바일 Daum(m.daum.net)에서는 "Daum 모바일웹 고객감사 쿠폰 이벤트"를 진행하게 되었지요.

Symbian S60v3을 사용하는 Nokia 6210s사용자인 저로서 이벤트를 참여하려고 하니 난감한 일이 발생되었습니다.

분명히 모바일 기기인 Nokia 6210s에서 접속했을뿐인데, Nokia 6210s에 내장된 웹 브라우저와 Opera Mobile 10 Beta2 웹 브라우저 둘다 "모바일 기기에서 만 접근가능한 페이지입니다"라는 메시지가 나옵니다.

아래는 Nokia 6210s에 내장된 웹 브라우저에서 접속하였을때의 결과입니다.

아래는 Opera Mobile 10 Beta2에서 모바일 Daum(m.daum.net) 를 접속하였을때의 결과입니다.

모바일쪽 개발하는데 여러 기기들중 몇가지만 테스트할수밖에 없는 환경이라는 걸 알고 있기때문에 고생 많다고 말씀드리고 싶습니다. 똑같은 환경으로 꾸며진 iPhone/iPod Touch뿐만 아니라 기기다양성이 심한 Windows Mobile에서까지 개발하느라 Symbian OS쓰는 Nokia 6210s에서도 불편함이 없이 모바일 Daum(m.daum.net)을 이용하기가 쉽습니다.

다만, 국내에 Nokia 6210s와 Nokia 5800 XPressMusic을 사용하는 유저들이 많아져서 Symbian유저에 대해서도 신경을 조금만 써줬으면 좋겠다는 의견을 냅니다.

참고로 Nokia 6210s에 내장된 웹 브라우저 HTTP Header는 기본적으로 아래와 같습니다. (출처 : http://www.forum.nokia.com/devices/6210_Navigator/ )

그리고 Nokia 5800 XPressMusic에 내장된 웹 브라우저 HTTP Header는 아래와 같습니다. (출처 : http://www.forum.nokia.com/devices/5800_XpressMusic/ )

Nokia 폰에 내장된 웹브라우저는 webkit엔진을 쓰기 때문에 다음 모바일팀에서도 문제없이 HTTP헤더부분 인식하는 부분을 인식하는 코드부분만 수정하면 모바일 기기로 인식할수 있을 겁니다.

다음 모바일을 만드시는 분들에게 이제 Nokia 휴대폰을 사용자들이 늘어났기 때문에 Nokia 사용자에게도 다음 모바일을 쓴다는 걸 인식하여주셨으면 좋겠습니다^^

이번에 컴퓨터공학과 3학년 2학기에 새로 생긴 전공과목인 네트워크 프로그래밍이란 과목을 수강하다가 Process를 이용한 웹서버 구현하는 과제를 하였습니다. 생각보단 어렵지는 안더군요. 예전에 Thread를 이용한 간단한 웹서버 구현한 것이있어서 Process로 바꾸는 데에는 금방 했습니다. (참고로 열혈강의 TCP/IP 소켓 프로그래밍이란 책을 참고했습니다.)




그래서 과제를 하다가 World Wide Web을 오랬동안 쓴 저 조차도, HTTP Protocol에 대해선 전혀 모르고 써왔구나를 느꼈습니다.
(저는 하이텔부터 쓴 사람이라서^^, 국민학교 3학년때 아부지 회사였던 테헤란로 K**란 회사에 가서 인터넷이라는 것을 알게 되었다지요. 그때 인터넷 접속할때에는 DOS에서 win를 쳐서 Windows 3.1를 실행시키고, Winsock이란 프로그램을 띄우고 나서 전화선 모뎀으로 접속해야했던 과거 ^^ - 오덕의 기운이 초등학교때부터 시작 ㅡㅡ;)

현재 우리나라에서는 HTTP Protocol가 어떻게 정의되었는지에 대한 책들을 찾기 힘들더군요, 그래서 학교 도서관에서 HTTP The Definitive Guide란 책을 빌려서 보고 있습니다 :D

책 내용이 2002년 9월달에 나왔지만, 변하는 내용은 아니니까. 책을 보면서 당연하게 느낀 것들도 어떻게 정의되었는지를 알게 되었을때 재미가 있네요. 공부가 재미있다는 것이 이런건가? -_-;;

Process를 이용한 웹서버 과제를 하고 나서 HTTP를 사용해서 서버 정보를 가져와 파일로 저장하는 프로그램도 짜봤습니다만, 자주 쓰는 웹서비스도 이해를 안하고 썼다는 것에 충격.


1. HTTP Protocol이란?
HTTP는 Hyper-Text Transfer Protocol의 약자로 WWW(World Wide Web)에서 사용되는 Protocol이다. HTTP/1.0은 RFC1945, HTTP/1.1은 RFC2068, RFC2616에 명시되어 있습니다.
일반적으로 포트번호는 80을 사용합니다.
실제로 쓰는 웹서버들은 포트번호를 명시해주어야 합니다. 예를 들어 네이버 주소는 원칙적으로 쓰면 http://www.naver.com:80/ 이렇게 포트번호 80를 명시해주면서 접속을 해야한다만 http://www.naver.com/ 이런식으로 표현하는 것도 포트번호가 80을 쓴다는 것을 암묵적으로 알기때문입니다.

자세한 내용은 RFC 문서를 읽으시는 것이 좋을 듯 합니다. 블로그에 포스팅하긴 엄청나게 방대한 양이라서요^^
HTTP/1.0 RFC1945 : rfc1945.txt.pdf
HTTP/1.1 RFC2068 : rfc2068.txt.pdf
HTTP/1.1 RFC2616 : rfc2616.txt.pdf

2. 웹서버를 이해하기
웹서버란? HTTP Protocol을 기반으로 해서 웹 페이지가 들어있는 파일을 클라이언트에게 전송해주는 프로그램이라고 보면 됩니다.
지금, 이 글을 보는 여러분들은 인터넷 브라우저인 FireFox나 Internet Explorer를 사용하고 계실 것입니다. 이 인터넷 브라우저는 클라이언트 소켓프로그램에 해당됩니다. 임의의 사이트에 접속을 하려고 할때, 브라우저도 내부적으로 TCP/IP소켓을 생성하기 때문입니다. 다만 인터넷 브라우저가 지니는 특징은, 서버가 전송해주는 HTML문으로 이루어진 문서를 그대로 보여주지 않고 HTML문법에 맞게 변환해 준다는 것이죠.

3. 간단한 HTTP 실행과정
HTTP는 클라이언트와 서버가 일정하고 예측 가능한 방식으로 정보를 교환하고 상호작용을 할수 있도록 허용하는 Method와 header의 집합을 정의하고 있습니다.
웹에서 볼수 있는 각 XHTML파일은 웹과 관련된 URL(Universal Resource Locator)을 가지고 있습니다. URL은 사용자가 접속하고자 하는 리소스(대부분 웹 페이지)에 브라이저가 접속할 수 있도록 하는 정보를 포함하고 있습니다.
예를 들면, http://www.dal.kr/data/index.html

http://는 웹 브라우저가 HTTP를 이용해 리소스를 요청해야한다는 것을 나타냅니다. 중간부분의 www.dal.kr은 서버 호스트 이름입니다. 호스트 이름은 리소스가 위치에 있는 컴퓨터의 이름인데, 이 컴퓨터가 보통 리소스를 간직하고 유지하기 때문에 호스트(Host)라고 합니다.
요청된 리소스 이름 /data/index.html (HTML문서)는 URL의 나머지 부분입니다. URL에서 이 부분은 리소스 이름(index.html)과 경로 (/data)를 확실해 구분해줍니다. 이 경로(path)는 웹 서버 파일 시스템에 있는 실제 Directory를 나타냅니다. 그렇지만 보안상의 이유로 경로는 대부분 가상 디렉토리(Virtual Directory)를 나타냅니다. 이 경우에, 서버는 해당 경로를 서버의 실제 위치로 해석하기 때문에 자원의 정확한 위치를 숨길수 있습니다. (Apache에서 VirtualHost인가 설정하면 해당 경로를 해석해서 표현합니다^^)

주어진 URL에 대해서 브라우저가 웹 페이지를 표현하기 위한 HTTP 트랜젝현을 어떻게 수행될까요?
아래 올려진 그림에서 잘 보여줍니다.
http://www.dal.kr/data/index.html를 접속한다고 생각합니다.
브라우저는 서버로 HTTP요청을 보냅니다. 그 요청은 이렇게 나타냅니다.

GET/data/index.html HTTP/1.1
host : www.dal.kr

GET이라는 단어는 리소스를 검색하고자 하는 클라이언트를 나타내는 HTTP Method입니다. 나머지 요청에서는 리소스의 이름 및 경로 그리고 프로토콜 이름과 버전 번호(HTTP/1.1)를 제공합니다.
(실험한 사이트들이 HTTP/1.0 을 써서 난감 ㅡㅡ;)

클라이언트가 서버에게 메시지를 주면 서버는 클라이언트에 요청 결과를 보내줍니다.
서버는 우선 한 줄로된 HTTP 버전과 그 뒤에 트랜잭션의 상태를 나타내는 숫자 코드와 구(phase)로 응답합니다.
HTTP/1.1 200 OK는 성공, HTTP/1.1 501 Method Not Implemented 는 요청을 처리하는데 필요한 기능이 구현되지 않았음, HTTP/1.1 404 Not found 는 특정한 위치에서 서버 자원을 찾을 수 없다는 응답을 알려줍니다.

아래는 제가 HTTP정보를 얻는 프로그램을 작성해서 돌려본 결과입니다. 제가 가는 사이트 마다 HTTP/1.1 지원하는 사이트가 없군요 ㅡㅡ; 다만 제가 일하고 싶은 오픈마루스튜디오는 HTTP/1.1를 지원하고 있었습니다 ㅠㅠ
서버는 클라이언트에게 보내는 데이터에 관한 정보를 제공하는 하나 또는 그 이상의 HTTP헤더를 보냅니다. 위에 제가 HTTP정보를 얻는 프로그램을 작성해서 돌려본 결과를 보면 그 예를 볼수 있습니다.
Content-Type: text/html; charset=iso-8859-1
Content-Type: text/html; charset=utf-8 Content-Type헤더의 정보는 MIME(Multipurpose Internet Mail Extension) 타입의 컨텐츠를 확인합니다. 서버에서 보내진 각 데이터 타입은 MIME타입을 가지며 이 MINE타입을 통해 브라우저는 받은 데이터를 어떻게 처리할 것인지를 결정합니다.

헤더 다음의 빈줄은 서버가 HTTP 헤더 전공을 끝냈다는 것을 클라이언트에게 알려주는 것입니다. 그리고 나서 서버는 요청된 리소스의 내용들을 보냅니다. 리소스 전송이 완료되면 연결이 종료됩니다. 클라이언트 측 브라우저는 받은 문서를 해석하고 결과를 화면에 출력또는 전달해줍니다.
아래 그림은 웹 서버랑 브라우저랑 어떻게 연결하는지 보여주는 그림입니다 :D
책내용은 HOW TO C++ PROGRAMMING Forth Edition - Deitel 형제가 쓴 책 내용의 일부분 참조했습니다.

아 생각보다 방대한 양들이군요. HTTP/1.1로 구현한 웹서버는 기능을 많이 뺀 것이라 간단하게 프로그래밍 했다만, 제대로 구현하려면 몇줄을 작성해야할까 걱정이 되군요 ㅡㅡㅋ
이왕에 MFC로 윈도우즈에도 써볼까? -_-;;(그러다 밤샐래!)

자세한 내용은 위에 있는 RFC문서를 참조하시기 바랍니다. 영어 해석이 어렵다면 네이버 지식즐을 참조하시길 :D