Web2Hub

By 서민구님

RoR이 좋다/나쁘다, 최고다/아니다. 이런건 좀 아닌 것 같습니다. Java라면 Java가 C++보다 빠르다고 하죠. .NET은 MS가 .NET을 처음에 들고나오면서, Java와 .NET으로 만든 두개의 동일한 web apps를 가지고 돌렸을 때 Java는 그냥 다운되버린다는 데모를 보여주기도 했습니다. .NET이 빠름을 보이기위해 자바의 펫스토어 example을 가지고 .NET이 더 빠름을 MS가 보였습니다. 후에 Oracle이 다시 .NET보다 수천배빠름을 보였고, .NET이 다시 그보다 빠름을 보이고, Loc도 자바보다 적음을 보였습니다. 후에 또 iBatis(OR Mapping 프레임웍입니다)는 자신들의 프레임웍을 적용하면서 자바가 닷넷보다고 빠르다고 우겼죠. 이런식의 언어간의 비교는 특정 벤더나 advocate들의 말만 듣고 결론을 내리기가 무척 어렵다고 생각합니다. 잘 아시겠지만 잘해도 flame war만 야기할 뿐이죠.

제가 생각하기에 어떤 애플리케이션이 scalable한가는 Roger Session이 이야기한대로, stateless로 구현이 되는가 아닌가에 매우 큰 비중이 있다고 생각합니다. 또, Roger아저씨가 쓴 책 COM+ and Battle for the Middle Tier라는 책에도 나오듯이, TP monitor와 같은 구현이 얼마나 쉽게될 수 있는가에 복잡한 웹 애플리케이션의 성패가 달려있다고 생각해도 과언이 아니라고 생각이 됩니다. (아쉽지만 TP 모니터 개념같은게 Ruby엔 없을 거라고 생각되는군요.)

어떤 웹 애플리케이션을 위한 개발환경이 궁극의 정점에 이르렀는가 아닌가에 대한 판단기준으로, 현대적인 의미에서는 쓸만한 persistence layer의 유무, MVC아키텍처(.NET이라면 code behind, JAVA라면 model2)의 유무, 쓸만한 IDE의 유무, 개발자 저변의 확대 정도, 멀티 쓰레딩을 위한 지원의 수준, 잘 갖추어진 보안 모델 등에서 볼 수 있다고 생각이 듭니다. 심지어 Javascript의 경우엔 보안모델이라는 개념 자체가 아예 없기 때문에 이것을 언어의 프레임웍에서 잘 다뤄주는 노력이 필요하게 됩니다.

Ruby가 그토록 쉬운 언어인가 아닌가는 심지어 중요하지 않기도 합니다. 어떤 사람들에게는 C++이 어렵지만 Scott Myers에게는 쉽겠죠. Herbert Schildt라면 심지어 모든 언어들의 API에 빠삭할겁니다. 닷넷 이벤절리스트들은 뚝딱 뚝딱하는 것만으로 애플리케이션을 만들거나, 상대방 프레임웍을 손쉽게 다운 시키는 스크립트들로 무장하고 있겠죠. 제임스 고슬링은, .NET은 unsafe 한 동작이 허용되므로 아무짝에도 쓸모없다고 생각하겠죠, 또 그가 생각하기에는 Groovy가 있으니 JAVA도 스크립트 언어입니다. 모든건 정말 상대적인것입니다.

특히나 RoR이 가진 생산성의 배경은, code generation인데요. 타입 검사가 유연한 언어가 code generation으로 무장하고선 다른 프레임웍보다 우수하다고 주장하는건 상당히 아아러니입니다. 사실 c2.com의 사람들은 code generation을 흔히 리팩토링에서 이야기하는 bad smell로 취급합니다. 어떤 언어가 code generation을 제공한다는 것은, 바로 '기능'이 아니라 'lack of a feature'라는 관점으로 볼 수 있습니다. 이런 관점으로 보면, strong type을 지향하는 언어에서 많은 코드가 캐스팅과 타입 맞추기에 들어간다는 것은 분명히 낭비입니다. 그래서 형을 아예 없애버리거나 형검사를 덜 엄격히 하는 Ruby등의 언어가 우수한 것이죠. 하지만, 기존의 개발환경과 루비를 웹 개발이라는 측면에서 갖다 놓고 보면 둘다 code generation에 의존하고 있습니다. JAVA야 아직 JSF가 빌빌거려서 코드 generation을 쉽게하는 단계에 이르르기 직전의 상태에서 계속 시간을 끌고 있지만, 닷넷의 예를 보면 굉장한 code genration에 의해 apps를 얼마나 쉽게 만들 수 있는지 볼 수 있습니다. (언어 자체도 대단하죠. [WebMethod...] 라고만 메소드 앞에 적어주면 아무 메소드나 XML Webservices가 됩니다. 자바는 EJB 3.0부터 이런것이 됩니다. Ruby는 모르겠군요.)

여기가 랭귀지의 우수성을 따지는 장이 아니라 Web 2.0관점에서 기술을 바라보고자 하는 곳이라면 과연 차세대 언어가 Ruby인가 아닌가는 별로 중요한게 아닙니다. 본질적인 이슈는 팀 오랄리가 이야기했듯이 애플리케이션이 얼마나 빨리 갱신될 수 있는가 하는 것입니다. RAD의 부활이란 얘기죠. 그런 관점에서 스크립트 언어가 우수한 것이고, 그런 관점에서 Ruby가 좋은 것입니다. 여기서 Scalable한가 아닌가는 Ruby에다가 목메도 살 수 있을까 아닐까를 따지겠다는 얘긴데, 그건 아무도 장담 못하는 미래입니다. 흔히들 하는 얘기로 오픈소스의 단점은 RI가 적고, 문서가 적고, 실패했을때 배상해줄 수 있는 사람이 없다고 합니다. Ruby역시 마찬가지 이야기가 적용되는 것이고, 이건 언어가 좋은가 나쁜가와 성공은 별개의 이야기란 의미입니다. 특히나 현재의 마켓쉐어는 1% 안팎에 불과한 듯 싶던데, 이 상태에서 그 언어에 목을 메겠단 결심은 쉽게 하기 힘들군요.

극단적으로 생각하면 RoR엔 AJAX를 쉽게 적용가능하다는 것 말고는 별다른게 없습니다. 그리고 다른 프레임웍들이 그보다 AJAX 적용에 있어서 쓸만한가 아닌가에 대해서는 저는 솔직히 잘 모르겠습니다. 하지만 조금만 시간이 지나면 빠른 프로토타이핑되는 정도야 금방 만들어 질 것이라 생각되는군요.

더 극단으로 가자면, AJAX가 rich interface를 만들기 위한 차세대 기술의 전쟁에서 승리했는가 아닌가도 아직은 불투명한 단계입니다. 자바 애플릿의 폭발을 기억하시나요? 지금 자바 애플릿이 몇군데나 쓰이고 있을까요. 순간만 봐서는 안됩니다. 저번 세미나때도 잠시 말씀드렸다시피, AJAX가 성공할 수 있었던건 그것이 독점 소프트웨어가 아니고, 어디서나 사용될 수 있다는 점 때문입니다. 하지만, 이건 플래쉬도 마찬가지입니다. 매크로미디어 역시 FLEX란 환경이 있고, MS는 XAML이 모든 플랫폼에서 돌아갈 수 있도록 오픈할 계획이 있다는 소문이 있습니다. (실제로 C#같은 언어는 ECMA 표준입니다. 독점이 아닙니다.)

저는 솔직히 AJAX가 아직 쓸만한 수준에 이르르지 못했다고 생각하고, 그 이유를 자바스크립트 실행의 느린 속도와 XML이 너무 verbose하다는데서 찾고 있습니다. 예전부터 XML을 바이너리 형태로 만들어서 크기를 작게하고 이를 통해 빠르게 전송할 수 있는 기술을 만들고 있다고 하던데 이것의, AFAIK, 초기 버젼이 만들어지고 있는 정도입니다. 아직 AJAX가 종착역이다 아니다에 대해서는 결론 내리기도 쉽지 않다고 생각이 듭니다.

흔히하는 얘기로, '언어는 도구다'라는 말이 있죠. C++을 조금만 하는 사람은 자바언어의 기초를 1주일이면 다 뗄 수 있습니다. 자바가 어려워보이는 이유는 그 뒤에있는 풍부한 라이브러나, SMP환경에서 멀티쓰레딩을 잘하는 방법이나, 객체를 deserialize하다가 보안 위협에 노출되지 않도록 코딩하는 방법이나, 확장성있는 클래스를 만들기가 어려운 데 있는거죠. 만약 자바를 할줄알면 C#의 기초는 3일정도면 되고, Python은 언어를 조금할 줄 알면 2일이면 기본은 뗍니다. PHP야 남들이 만든 코드만 놓고 보고 따라하면 되더군요. Ruby도 RoR까지 제대로하면 3일안에는 할줄 알게 될거라고 생각합니다. 하지만 정말 문제는 어떻게 만들어야 하나의 웹 apps를 만들때 RAD가 될까하는 것인데, 이것은 보다 본질적으로 생각해보면 개발철학에 관계된 일이고, 요즘 불어닥치는 XP나 Agile의 관점에서 크게 벗어나는 이야기가 아닙니다.

여기 jeus 만들다 오신 분도 계시고, 다들 경험도 풍부하신데 오버한 것 같아서 죄송스럽습니다. 다만, 저로서는 어떤 프레임웍이 최고다아니다를 이야기하기 보다는 AJAX자체를 어떻게 적용할 것인지(사실 제대로 못하면 이건 iframe으로 프레임 분리한것보다 더 못할지도 모릅니다), 아니면 데스크탑 apps와의 간극을 어떻게 줄여줄 수 있을지, 오라클의 엘리슨이 이야기한대로 Network is a computer인지를 실현시켜줄 녀석이 맞는지, Network as a platform을 만드는데 있어서 자바스크립트로 XML을 주고받는다이면 과연 그것만으로 우리는 행복하게 먼 미래까지 잘 살 수 있을지가 생각해볼 방향인 것 같다는 생각이 들어서 글을 적었습니다. 아직 웹은 데스크탑과 정말 다릅니다. 같아지게 만들어줄 기술도 나오지 않았고요...

p.s. 글을 입력할 때 그냥 textarea에 적을 수는 없나요? 편집기 보다는 그냥 html을 입력하는게 편해서요..

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선

License:
This article is provided under the Creative Commons Attribution-Alike 2.0 license (http://creativecommons.org/licenses/by-sa/2.0/) according to the license agreement of the original article. The author of the original article is Ryan Tomayko, and his post can be found at http://naeblis.cx/rtomayko/2004/12/12/rest-to-my-wife. Translation into Korean is provided by Minkoo Seo(minkoo.seo@gmail.com).

라이선스:
이 글은 원문의 라이선스에 따라 Creative Commons Attribute-Alike 2.0 라이선스 (http://creativecommons.org/licenses/by-sa/2.0/deed.kr)에 따라 배포됩니다. 원 저자는 Ryan Tomayko이며, 원문은 http://naeblis.cx/rtomayko/2004/12/12/rest-to-my-wife 에서 보실 수 있습니다. 한국어 번역은 서민구(minkoo.seo at gmail.com)가 하였습니다.

내가 아내에게 REST를 어떻게 설명했는가.

부인: Roy Fielding이 누구야?

Ryan: 남잔데, 똑똑한 사람이야.

부인: 응. 근데 그 사람이 뭘 했어?

Ryan: 최초의 웹 서버를 작성했고, 왜 웹이 현재와 같은 모습으로 동작하는지를 설명하는 많은 연구를 했지. 아, 그의 이름은 서버로부터 브라우저로 데이터를 전송하는 프로토콜 스펙에 올라있기도 해.

부인: 어떻게 동작하는데?

Ryan: 웹말야?

부인: 응

Ryan: 흠.. 어, 사실 굉장히 재밌지. 그리고 가장 재밌는 점은 웹이 과소평가되어있다는거야. 아까 말한 프로토콜은 HTTP라는 이름으로 불려. 그리고 HTTP는 사람들이 종종 간과하기도 하는 멋진 일들을 처리하지.

부인: http는 브라우저에서 주소를 입력할때 넣는 맨 앞의 단어를 말하는거야?

Ryan: 응. 그 처음부분이 브라우저에게 어떤 프로토콜을 써야하는지 말하는 곳이지. 바로 그게 컴퓨팅 역사에서 가장 중요한 혁신적인 일이었어.

부인: 왜?

Ryan: 왜냐면 어느곳에서나 세계의 모든 것들을 기술할 수 있었으니까. 그게 웹의 바탕을 이루지. 이건 지식과 정보를 얻는데 사용되는 GPS 좌표같은거야.

부인: 웹의 좌표?

Ryan: 음.. 그래. 사실 모든 것에 대한 좌표지. 아까 그 Roy Fielding이란 남자 말야. 그 사람의 연구에선 그 무언가를 가리키는 포인트들에 많은 언급을 했어. 웹은 REST라고 불리는 아키텍쳐 스타일에 근간을 두고 있는데, REST는 포인트가 가리키는 자원에 대한 정의를 내려주지.

부인: 웹 페이지가 자원이야?

Ryan: 일종의. 웹 페이지는 자원에 대한 표현이야. 자원은 그냥 개념이고. URL들은 브라우저에서 입력하는 주소이고..

부인: 나 URL이 뭔지 알아.

Ryan: 응 그거. URL을 사용해서 어딘가 개념이 있다고 말해주는 거지. 그럼 브라우저는 그 개념의 특정한 표현을 얻어올 수 있지. 좀더 정확하게 말하자면, 브라우저는 개념의 표현인 웹 페이지를 가져오는거야.

부인: 또 어떤 표현 양식들이 있는데?

Ryan: 사실, 그 표현 방식이라는게 그렇게 많이 쓰이지는 않아. 대부분의 경우에, 자원은 단일의 표현만을 가지지. 그렇지만 우리는 전체에 대한 표현이 미래에는 많이 쓰이기를 바래. 왜냐면 새로운 표현양식들이 자꾸 나타나고 있으니까.

부인: 예를들자면 어떤?

Ryan: 음. 말하자면, 사람들이 웹 서비스(web services)라고 부르는 개념이 있지. 이건 많은 사람들에게 종종 서로 다른 의미로 이해되기는 하지만, 어쨌든 기본적인 생각은 기계가 사람처럼 웹을 사용한다는 것이지.

부인: 이거 로봇같은거야?

Ryan: 아냐. 사실 완전히 그런건 아니고. 컴퓨터가 책상에 앉아서 웹 서핑을 한다는 말은 아니야. 그렇지만 컴퓨터가 같은 프로토콜을 사용해 서로 데이터를 주고 받는다는 거지. 사람들은 이런 일을 아주 오랫동안 해왔지만, 오늘날의 어떤 방식도 전세계의 모든 컴퓨터와 통신하는데는 적당하지 않지.

부인: 어째서?

Ryan: 왜냐면 그렇게 설계되지를 않아서 그래. Roy Fielding과 그의 친구들이 웹을 만들때는, 세계의 모든 컴퓨터와 통신한다는게 아주 중요하게 다뤄진 문제였어. 하지만 우리가 일을 할때 컴퓨터가 서로간에 통신하도록 하는 방식에는 이러한 고려가 되어있지 않아. 우리가 일할때는 몇개의 컴퓨터가 서로간에 대화하도록 하는 정도만 되면 되니까.

부인: 그런데 이제는 세상의 모든 컴퓨터와 이야기 할 수 있어야 한단 거야?

Ryan: 응. 그리고 사실은 더 많은 것이 필요하지. 우리는 세계의 모든 컴퓨터와 사방에 퍼져있는 자료들에 대해서 이야기할 수 있어야돼. 그래서 우리는 어떤 컴퓨터에게 그 컴퓨터 외에 있는 자원에 대해 이야기할 수 있는 방법이 필요한거야.

부인: 뭐라구?

Ryan: 예를 들어서 당신이 여동생과 이야기를 하고 있는데, 걔가 청소기 같은걸 빌리고 싶어한다고 하자. 그런데 당신한텐 그게 없어. 어머니한테는 있지. 그러면 당신은 여동생에게 어머니에게 빌리라고 말을 해야하지. 이게 바로 실제세계에서 일어나는 일고, 컴퓨터가 이야기를 시작함에따라 발생할 일들이지.

부인: 그럼 기계들은 어디에 물건이 있는지 어떻게 말해주지?

Ryan: 물론 URL이지. 만약 컴퓨터가 필요한 URL로만 이야기한다면, 기계에서 필요한 '명사'를 만들었다고 할 수 있지. 당신과 나와 그리고 전세계가 명사에 대해서 동의한다는건 매우 중요한일이야. 그렇지?

부인: 응.

Ryan: 기계한텐 그런 명사가 없어. 그래서 골치가 아프지. 모든 프로그래밍 언어, 데이터베이스, 그리고 다른 모든 시스템들은 서로 명사를 다르게 정의해버렸어. 그래서 URL이 중요한거지. URL은 모든 시스템들이 다른 기계가 가진 명사에 대해 이야기할 수 있게 해줘.

부인: 그치만 나는 웹을 그렇게 생각해본 적이 없는걸?

Ryan: 아무도 안그러지. Fielding 과 몇몇 사람들 빼고는. 그래서 기계란게 갑갑한 거야.

부인: 명사나 대명사나 형용사는 어떻게 해?

Ryan: 당신이 그런말을 하다니 재밌는걸? 사실 그게 REST의 또다른 큰 측면이거든. 음, 어쨌든 '동사'는 그래.

부인: 농담이었는데.

Ryan: 재밌는 농담이긴 한데, 사실 농담이 아닌 일이야. 동사는 중요해. 프로그래밍과 컴퓨터 과학 이론에는 폴리모피즘이라는 강력한 개념이 있지. 폴리모피즘은 명사에 적용되는 동사가 동일할 수 있게 해주는 괴짜같은 방법이야.

부인: 무슨말인지 모르겠어.

Ryan: 음.. 커피 테이블을 보자. 뭐가 명사지? 컵, 차반, 신문, 리모콘. 자, 그럼 이걸 갖구 뭘 할 수 있을까?

부인: 몰라.. (I don't get it..)

Ryan: 그걸 가져올 수 있어(You can get them. 역주: get을 사용한 말장난입니다) 그치? 집을수도 있어. 때려 눞힐 수도 있어. 태울 수도 있지. 이런 다양한 동사를 저기있는 모든 객체들에게 적용할 수 있지.

부인: 좋아... 그래서?

Ryan: 그게 중요한거야. 당신한테 "컵을 갖다줘(get the cup)", "신문을 갖다줘(get the newspaper)", "리모콘을 갖다줘(get the remote)"라고 말하는 대신에, 만약 명사마다 서로 다른 동사를 사용해야한다면 어떨까? 그러면 "갖다줘(get)" 을 온갖 물건에 사용하는 대신에, 모든 동사/명사 조합에 대해서 새로운 단어를 생각해야만 할거야.

부인: 그건 정말 이상할거 같아.

Ryan: 그래, 그렇지. 우리의 뇌는 똑똑해서 서로다른 명사에 같은 동사를 적용할 수 있지. 몇몇 동사는 사용처가 한정되어있어서 일부 명사에만 쓸 수 있지. 예를들어서, 나는 컵을 운전할 수 없고, 자동차를 마실 수 없어. 그렇지만 몇몇 동사는 어디에나 사용될 수 있는데 이런 동사에는 GET, PUT, DELETE가 있지.

부인: 하지만 컵을 지울 수는(DELETE) 없잖아.

Ryan: 응, 그야 그렇지. 하지만 던져버릴 수는 있잖아. 농담인거지 당신?

부인: 그래.

Ryan: 어쨌든간에, Fielding과 그의 친구들이 만든 HTTP라는 프로토콜은 동사를 명사에 적용하는 것에 대한 이야기야. 예를들자면, 웹 페이지에 방문하면, 브라우저는 당신이 입력한 URL에 대해서 HTTP GET을 수행하고 웹 페이지를 보여주지.

웹 페이지에는 보통 이미지가 있어. 그렇지? 각 이미지는 서로 분리된 자원이야. 웹 페이지는 다만 이미지에 대한 URL을 지정할 뿐이고, 그러면 브라우저가 모든 필요한 자원을 획득할 때까지 HTTP GET을 수행하고, 그 후에 웹 페이지가 화면에 나타나지. 그러나 여기서 중요한건 모든 명사를 똑같이 취급할 수 있다는 점이야. 명사가 이미지, 텍스트, 비디오, mp3, 슬라이드쇼든 뭐든지 간에 같게 취급할 수 있지. URL만 있으면 모두 가져올 수(GET) 있는 거야.

부인: GET이란거 무척 중요한 동사같네.

Ryan: 맞아. 특히 브라우저를 쓸 때 그렇지. 왜냐하면 브라우저라는건 그냥 가져오기만 하는 녀석이니까. 자원들을 가지고 무언가 대단한 일을 하지는 않아. 이게 문제야. 왜냐하면 그로인해 많은 사람들이 HTTP란 단지 가져오는 것이다라고 생각하게 만들어버렸으니까. 그렇지만 HTTP는 사실 동사를 명사에 적용하는데 대한 일반화된 프로토콜이야.

부인: 멋진데. 그렇지만 이런것들이 무슨 의미가 있는지 잘 모르겠어. 또 무슨 명사와 동사가 필요한건데?

Ryan: 음, 명사는 있지. 그런데 포멧이 적절하지가 않아. 당신이 나에게 크리스마스 선물을 사주기위해 amazon.com 에 접속했다고 해보자. 각각의 상품이 명사라고 생각해 봐. 만약 기계가 이 상품들이 기계가 이해할 수 있는 형태로 존재한다면, 멋진 일들을 할 수 있어.

부인: 기계는 왜 웹 페이지를 이해할 수가 없어?

Ryan: 왜냐하면 웹 페이지는 사람을 위한 거거든. 기계는 레이아웃이나 스타일에 신경을 쓰지 않지. 기계는 다만 데이터만 있으면 되는거야. 이상적으로 보자면, 모든 URL은 사람과 기계가 모두 읽을 수 있는 표현을 가져야 하지. 기계가 GET을 하면, 기계가 읽을 수 있는 자원을 줘야지. 사람이 브라우저로 GET을 하면, 사람이 읽을 수 있는 것을 줘야하고.

부인: 그럼 사람들이 모든 페이지에 대해서 기계들도 읽을 수 있는 포멧을 만들어야한단 거야?

Ryan: 그런게 의미가 있다면.

지금까지 우리는 많은 추상적인 것들로 대화를 진행해 왔어. 실제 예를 들어보는게 어떨까. 당신이 선생님이라고 해보자... 그러면 학교에는 커다란 컴퓨터가 있을거고, 아니면 적어도 학생 관리를 위한 컴퓨터가 세네 대는 있겠지. 거기에는 어떤 학생들이 등록했는지, 점수는 몇점이나 받았는지, 비상 연락처는 어떻게 되는지, 학생을 가르칠 때 어떤 책을 사용해야할지 같은 정보가 있을거야. 만약 그 시스템이 웹 기반이라면, 그러면 여기에 등장하는 모든 명사에 URL이 있을거야. 이런 명사는 학생, 선생님, 수업, 책, 방 같은거겠지. 자 이제, 브라우저에서 URL을 입력하면 웹 페이지가 나오지. 만약 기계가 읽을 수 있는 표현이 각 URL마다 작성되어 있다면, 새로운 도구를 붙이는게 쉬울거야. 왜냐하면 모든 정보가 표준화된 방법으로 사용될 수 있으니까. 그리고 기계간의 대화도 쉬워지겠지. 즉, 시험 점수를 취합하는데 쓸 수 있도록 국가 전체의 학교 시스템들이 상호간에 통신할 수 있는 시스템을 만들 수 있겠 되는거지.

각 시스템은 간단한 HTTP GET을 사용해서 정보를 얻어오는 거야. 만약 어떤 시스템이 다른 시스템에 무언가를 저장하고자하면 HTTP POST를 쓸 수 있어. 시스템이 다른 시스템의 정보를 갱신하려면 HTTP PUT을 쓰지. 이제 남은 일은 데이터가 어떤 모양이어야 하는가라는 거야.

부인: 그래서, 이게 당신과 모든 컴퓨터 하는 사람들이 하는 일이란 말야? 데이터가 어떻게 나타나야하는가에 대한 것?

Ryan: 불행히도 그렇지는 않아. 대신, 별로 유용하지도 않고 편하지도 않은 또 다른 방식으로 일을 처리하기위한 복잡한 스펙의 계층을 쓰는데 시간을 보내고 있지. 명사는 전세계적으로 통용되는 형태가 아니고, 동사역시 폴리모피즘이 안돼. 수십년간 실세계에서 검증된 기술을 던져버리고는 과거에 실패한 시스템들의 방법을 다시 갖다 쓰고 있지. HTTP를 쓰기는 하는데, 그건 단지 보안 관리자와 대면할 일이 적고, 통신하는데 편하단 이유때문에 쓰는거고. 간단함 대신에 번쩍거리는 도구와 마법사에 의존하고 있어.

부인: 왜?

Ryan: 몰라...

부인: 당신이 뭐라고 좀 하지 그래?

Ryan: 그럴 생각이야.

-------------------------------------------8<------------------------------------------------

예전에 번역해보려고 생각하고 하다가 중단했었는데, 오늘 이야기가 나왔어서
완성 시켰습니다....

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 한재선