IT/모바일
제공 : 한빛 네트워크
저자 : Simon St. Laurent
역자 : 김준환
원문 : Web application development is different (and better)
프론트엔드와 백엔드에서 웹은 일반적인 통념에 도전하고 있다.
웹은 가장 흔히 볼 수 있는 분산된 애플리케이션 시스템이 되었기 때문에 프로그래밍 환경으로 생각할 필요가 없다. 나는 거의 매일 프로그래머들(심지어 뛰어난 프로그래머들도)이 얼마나 많이 하위의 낯선 부분들을 처리해야 하는지, HTML을 완전히 분리하고 캔버스로 대체한 것에 대한 역사적인 사건을 얼마나 수정하고 싶어하는지, 그리고 얼마나 관심사의 분리가 불편한지에 대해 투덜대는 언급이나 불평을 보았다. 모든 것은 자바스크립트여야 한다.
(내가 작성한 것과 완벽한 대조를 이루는 시리즈를 트윗한 Tom Dale(father or devops)에게 사과한다. 그는 자바스크립트의 렌더링 스택의 새로운 구축에 대한 비전을 가지고 있었다. 하지만 그 트윗들은 색다르지 않은 의견들이다.)
웹은 다르다, 그리고 나는 왜 프로그래머들이 웹을 선택하는 과정에 대해서 관용적이지 못했는지 볼 수 있었다. 하지만 이때의 프로그래머들은 틀렸다. 웹이 완벽하다는 것은 아니다. - 틀림없는 작은 문제들을 가지고 있다. 무언가 더 나은 것이 성공을 의미하는 것은 아니다. 많은 심각한 문제들은 광범위한 사용자들에 의해 발견되고, 끝없는 단계의 나쁠수록 좋다는 대화들이 있다. 그리고 물론 웹은 모든 프로그래밍이 요구하는 것을 해결하지 못한다. 많은 문제들과 단순히 맞지 않을 뿐이다. 그래도 괜찮다.
그러면 왜 웹이 더 좋은가?
웹은 사람과 기술적인 책임 분배 모두에 허용된 몇 가지 중요한 선택을 통하여, 프로젝트 확장성 문제를 다루는 것을 가능하게 해준다. 이러한 선택은 타협이지만, 타협이 이룬 균형은 모든 수준의 개발자들이 웹에 기여할 수 있게 한다.
웹은 훌륭한 타이밍을 가지고 있었다. 초기 몇 해 동안은 웹이 무엇인지에 대하여 정리되고 개발되었다. 다음 엄청난 성장이 이뤄진 몇 해 동안은 개발자들이 할 수 있는 크고 작은 실수와 그 실수들을 수정하기 위해 총력을 기울이고, 수정된 것들이 자리 잡는 조용한 기간이었다. 심지어 이 조용한 기간에도, 웹은 거대한 크기로 유지되고 있었으며, 웹 프로젝트는 지속적으로 그 크기와 영역이 성장하고 있었다.
웹만이 분산된 애플리케이션을 만드는 좋은 방법인 것은 아니다. 단지 많은 사람들이 만들고자 원하는 때에 나타났다. 프론트 엔드와 백엔드 사이, 그리고 둘 사이의 결합이 유일한 기능 집합과 제약으로 성립되어 훌륭한(그리고 계속 유지할 수 있는!) 애플리케이션들을 쉽게 구축할 수 있게 만들었다.
프론트 엔드
초기에 HTML이 있었다. 더 정확히 말하면, 접착제처럼 GOTO 역할을 하는 하이퍼텍스트 링크였다. 콘텐츠, 구조, 서식, 동작 그리고 링크들이 모두 텍스트 문서들 안에 갇힌 Ted Nelson이 만들어낸 최악의 기술적 악몽이었다.
웹(웹 사이트들)이 거대해지자, 검색과 교체는 한계에 부딪쳤다. 기반 계층인 HTML은 여전히 콘텐츠, 구조, 그리고 하이퍼링크 동작을 혼합하여 포함하고 있지만 관심사의 분리는 웹 콘텐츠를 유지보수하고 배포하는 것을 더 쉽게 만들어 준다. 결국 오늘날 우리가 가진 웹 애플리케이션이 생겨났다.
하이퍼텍스트 마크업 언어 (HTML)는 대다수 사람들이 이해하기 쉽다. 모두는 아니지만 프로그래머나 디자이너들 보다 더 많은 사람들이 할 수 있다. 마크업이 어떻게 동작하는지, 적은 주요 태그들에 대한 기본 지식만 있으면 기본 페이지들부터 복잡한 애플리케이션까지 다른 사람들이 많은 상황에서 사용할 수 있는 콘텐츠를 만들 수 있다. 나는 여전히 "HTML 코드"를 볼 때마다 아차 하지만 적절하게 사용한다. - HTML은 프로그래밍 언어 자체가 아니지만, 분명히 콘텐츠와 구조를 표현한다.
HTML에서 애플리케이션의 밑그림을 그리는 것은 흔히 문서나 포토샵으로 하는 것보다 더 쉽다. 텍스트는 저장하고 다루기 쉽다(표현하는데 머리가 아프기는 하지만). 구글은 이에 의존하는 하나의 주요 검색엔진의 사례다. 마크업 구조는 또한 트리로 정의된다. 문서 객체 모델(DOM), 또는 DOM 경험의 개선을 추구하는 수많은 래퍼들은 개발자들이 트리 형태에 접근할 수 있도록 해준다.
계단형 스타일 시트(CSS)는 HTML을 작성할 때 정확히 어떻게 보여야 하는지를 생각하는데 겪는 어려움을 피하게 해준다. 웹 브라우저 내부 레이아웃에 대한 지속적인 관심과 더 많은 로직을 추가하기 위한 노력으로 복잡한 세계가 되어가는데도 불구하고, CSS는 가장 적절한 수준에 이르렀다. CSS의 서술적인 접근은 사람이 만드는 것과 브라우저에 효율적으로 적용하는 것을 쉽게 만들었다. "계단식"은 때때로 세부적인 부분에서 설명하기 힘들지만, 대개 복잡한 솔루션이 요구하는 충분한 수준으로만 사용되는 상황으로 보인다. 가장 나를 놀라게 했던 것은, CSS는 절차적 환경에서는 불가능한 방법으로 하드웨어 가속 애니메이션과 변형을 통합하도록 해준다.
CSS는 아름답게 만드는 것을 돕는 것을 넘어서, 웹 아키텍처에서 중요한 역할을 한다. CSS는 애플리케이션 컴포넌트들을 포함한 HTML 문서들의 라이브러리를 관리하고, 중복과 오류를 감소시키는 것을 훨씬 쉽게 만든다. 분명한 사실은 여러 문서에 적용되는 표현 정보는 많은 장점을 가진다는 것이다.
CSS는 두 가지 문화적인 문제점들을 갖는데, 하나는 디자인 측면 그리고 다른 하나는 프로그래밍 측면이다. HTML 문서들이 (가장) 자연스럽게 반응하지만, 어떠한 크기든 브라우저 컨테이너가 요구하는 텍스트가 차지하는 공간을 조절하기 위한 부가적인 제어 CSS는, 아름답지만 불안정한 레이아웃을 디자이너에게 권장한다. 레이아웃과 미디어 쿼리를 위한 새 기능은 가능한 다시 한 번 반응형 웹 디자인을 만든다. 프로그래밍 측면에서, 매우 그럴 듯한 태도의 풍자로 밝히는 것처럼 CSS는 프로그래밍이 아니다.
자바스크립트는 동작을 제공한다. 자바스크립트는 오랫동안 완전히 객체지향적도 아니고, 함수형 프로그래밍 언어도 아니라는 많은 비판을 받았지만, 가벼운 언어에서 반드시 배워야만 하는 언어가 되었다. 자바스크립트에 대한 비난과 비판은 멈추지 않았고, 자바스크립트 프로그래머들은 매우 다양해졌지만, 자바스크립트의 강점은 분산된 애플리케이션 개발과 매우 잘 어울린다.
과거 수년 사이에, 브라우저 벤더들은 개발자들에게 더 많은 컨텐츠와 장비들 사이의 상호작용 기회를 제공하기 위한 애플리케이션 프로그래밍 인터페이스(API)를 만들었다. 한 때, 자바스크립트를 넘어선 (지금은 금지된) 상태 표시줄 트릭, 문서 객체 모델 (DOM)은 첫 번째 단계였다. DOM은 좀처럼 "가장 좋은 API 디자인" 목록을 만들지 않았지만, 시간이 지남에 따라 개선되었고, 개발자들은 더 유용하게 DOM을 감쌌다. 더 최근의 API들은 로컬 저장공간이나 장비에 접근할 수 있는 기능을, 브라우저 밖으로 벗어나와 접근 권한 없이 사용자 컴퓨터의 모든 것에 접근할 수 있도록 제공한다.
Ajax는 2005년 Jesse James Garrett이 명명하고 몇 차례 언급했던, 웹 기술들과 1999년 인터넷 익스플로러에서 나타난 XMLHttpRequest 객체의 결합으로 API 위에 구축된 개발패턴이다. 더 많은 브라우저들로 아이디어가 확산되는데 시간이 걸렸지만, 불현듯 거대한 프로그래머 그룹이 프론트엔드 애플리케이션들을 구축했다(객체 이름에도 불구하고, 자주 자바스크립트에서 데이터 포맷을 XML대신에 JSON을 사용했다).
웹은 물론 이러한 도구들로 더 많은 일을 하고 있다.
웹 컴포넌트를 통해 더 강화된 자바스크립트는, 개발자들이 브라우저의 동작을 확장하게 할 수 있다. CSS는 개발자들이 어떻게 컨텐츠를 표현해야 하는지 브라우저에 명령할 수 있게 한다. 이러한 옵션 및 추가 API 사이에, Alex Russell이 불평한 "3등급의 어휘" 이상으로 HTML을 확장하는 것이 가능하다. 웹 프론트 엔드의 다른 부분들이 스스로의 표준들을 만들었기 때문에 이제 "모든 HTML은 반드시 표준이어야 한다"는 주장은 버릴 수 있다.
이것은 무엇을 의미하는가? 그 의미는:
적어도 자바스크립트를 사용하는 폴리필은 아직 작은 결함을 가진다: 동작을 하기 위해 자바스크립트가 요구된다. 실패들은 대부분 우리가 보았듯이 극적이지 않다. 예를 들어, Sigh, JavaScript의 미묘한 실패는 실제로 더 어려운 문제를 만들 수 있다.
Sigh, JavaScript에서의 대부분의 실패에도, 자바스크립트는 웹 애플리케이션 개발의 구석진 자리에서 HTML/CSS/자바스크립트 스택으로 되돌아왔다. 그런 접근법은 웹 애플리케이션을 주로 자바스크립트라고 생각하게 만들었다. HTML은 단순히 자바스크립트를 로딩하고 모든 것을 DOM을 통해 설정하는 외부구조이다(더 극단적인 케이스에서는, 캔버스). 이 모델에서는 생성된 마크업이 보일 때 디버거를 통해 프로그래머가 모두 제어 하는 것을 기대할 수 있다. CSS는 여전히 분리되어 있겠지만, 더 쉽게 반복되는 문서들보다는 애플리케이션에 대해 항상 테스트되어야 한다.
단일 페이지 애플리케이션은, 다른 데스크톱이나 모바일 애플리케이션 모델들, 심지어 Flash까지 프로그래머의 기대에 매우 잘 어울리는 방법들 중 가장 두드러진다. 웹은 이 모델을 수용할 수 있고(프론트와 백 엔드 상에서 모두), 브라우저의 성능은 다른 방식의 네이티브 애플리케이션들과 경쟁할 수 있는 정도까지 향상되었다. 하지만, 상당수는 웹 사고방식의 확장성을 버렸다.
프로그래머는 애플리케이션의 왕과 왕비일지도 모르지만, 모든 것을 감싸기에 충분하지 못하다. 단일 페이지 애플리케이션은 또한, 기반 마크업과 컨텐츠를 채우기 위해 자바 스크립트를 사용하는 것을 강조하여 오명을 뒤집어 쓴다: 그들은 사실상 구글에서 보이지 않는다. 일부의 경우 괜찮다: 그들은 구글이나 다른 스크랩퍼들이 그들의 고객들의 데이터를 들여다 보는 것을 원치 않는다. 구글이 내부를 살펴 볼 때 서버 팜에서 마크업을 생성할 수도 있고, 클라이언트와 서버 사이에 코드를 이동하는 연륜이 여러 상황에서 성공할지도 모른다. 더 혼합된 아키텍처의 Isomorphic JavaScript는 그 토대를 찾은 것처럼 보인다.
접합
거의 초기인 1994년에 URL이 있었다. URL은 획일적인 자원 지시자(uniform resource locator, URL의 정식명칭)나 웹 주소로 웹 개발의 프론트와 백 엔드를 연결할 뿐만 아니라, 하이퍼링크로 연결하는 것을 쉽게 만들어주었다. 텍스트 기반인 URL을 컴퓨터가 읽을 수 있는 그래픽으로 교체하기 위한 다양한 시도(CueCat에서 QR 코드까지)에도 불구하고, URL은 여전히 일반적이고, 교체를 시도했던 후임자를 위한 기반이 된다.
프론트 엔트에서 URL은 항해(URL을 통한 이동)의 중심이었다. 하이퍼링크된 대상들, 북마크(즐겨찾기) 가능한 컨텐츠, 그리고 뒤로 가기, 앞으로 가기 버튼의 단순한 모델의 시작지점을 제공했다(홈페이지를 생각해보라). Ajax가 나오자, 페이지들은 불현듯 새로운 컨텐츠를 기반 URL의 변경 없이 로딩하기 시작했다, 뒤로 가기 버튼은 예측할 수 없게 되었다. 해법인 히스토리 API는 브라우저 히스토리를 자바스크립트 코드가 직접 관리하게 하는데 기여했다. 도움이 되었지만, "주: URL은 실제가 아니므로, 페이지를 새로 고침하면 유효하지 않은 URL로 갈 것입니다."와 같이 거부하는 자세에 대한 시연도 만들어냈다
URL의 오른쪽 끝에서 #으로 시작하는 선택적 부분인 단편화 식별자는, 문서의 명확한 지점에 도달하도록 더 나아가게 한다. 불행하게도, HTML 어휘나 다중 페이지 어느 쪽이든 브라우징 모델의 기본적인 기대를 남겨두고 가면 단편화 식별자는 곧 복잡해진다. 단일 페이지 애플리케이션에서 단편화 식별자를 다시 만드는 것은 몇 년 전 프로젝트에서 그다지 좋아하지 않는 부분이었다. 물론 모두가 나처럼 단편화 식별자에 대해 흥분한 것은 아니었다(심지어 방향 능력을 확장하는 문법을 제안 했다. - 여기서 더 볼 수 있다.)
백엔드에서 URL은 적어도 지난 몇 년 동안 도메인 이름의 오른쪽 부분은 실제동작이 바뀌었다. 서버상의 파일들의 구조 정보로 사용되었고, 아직도 가끔은 사용되지만, 많은 웹 프레임워크들은 라우팅 방법을 통해서 제어를 집중시킨다. PHP는 레일즈 역사에 있어 가장 중요한 컴포넌트를 만드는 동안, 거대한 파일들의 집합에서 응용프로그램 논리를 배포하는 좋은 기수였다. 다른 모델들이지만, 백엔드 개발자들은 URL은 같은 애플리케이션의 다른 방향들을 가리키는 화살표로서 동작할 수 있어야 한다는 주장에 대체로 동의했다.
잠시 중지하고, 당신이 기대하는 다른 애플리케이션 상황에 대해서 생각해보자. 애플리케이션을 데스크톱이나 모바일에서 열 때, 내가 지난번 어디서 열었는지 또는 새 화면에서 여는지 나의 선택은 매우 많다. 특히 내가 원하는 방식이 여러 가지라면, 내가 원하는 방식으로 애플리케이션을 열게 하는 것이 쉽지 않다. 웹에서 이것은 대게 사소하다 - URL은 애플리케이션에서 특정 지점에 연결하게 하고, 일부-영리한 개발모델들이 필요에 따라 로그인하게 한 다음 당신이 방식으로 동작한다. 더 확장할 수 있는 여지가 있겠지만 URL은 다른 애플리케이션들이 겨우 고려하기 시작한 기능을 웹 애플리케이션을 위해 만들 수 있다.
URL은 어느 정도 성공에 대한 처벌을 받았다. Tim Berners-Lee가 시맨틱 웹의 비전 쪽으로 관심을 옮기기 시작하면서 URL에 대한 흥미가 줄어들었다. URL에 대한 대부분의 명확한 이야기 대신, W3C는 현재 많은 시간을 URI(Uniform resource identifier)의 신학에 맞춰 일했다. 유머 감각에 어둡고, 기술 대화를 좋아하고, 많은 시간이 있다면, 당신은 여기에 1년을 낭비할 수 있다. 끝난 것 같지만 끝나지 않은 URI시공간 연속체의 분할이나 그 이전의 대화 대신 그냥 httpRange-14를 찾아라.
백엔드
초기에 HTTP가 있었다. 클라이언트가 URL로부터 컨텐츠를 얻어오는(GET) 기능을 제공했지만, 시간이 흐르면서 많은 수의 메소드-행동-로 확장되었다. GET과 POST가 우세했지만, PUT과 DELETE 또한 개발자들이 웹 애플리케이션에서 정보를 관리하는데 중요한 부분이 되었다.
HTTP가 가진 원래의 매력적인 요소는 HTTP가 가진 단순함이었다. 실제로 많은 것을 하지 않았고, 어디에나 있으며, 무해한 것처럼 여겨지는 점이 결합하여 대체로 방화벽 벤더들이 방화벽을 통과하게 할 용의를 갖도록 만들었다. 때문에 웹 컨텐츠에 대한 소비에 대한 관심은 대역폭 보다 더 빠르게 성장했다 HTTP를 유지 보수하는 사람들은 캐싱과 프록시에 높은 우선 순위를 유지했다. 몇 번의 반복 후에 여전히 상대적으로 단순하지만, 성능에 높은 관심 보이는 프로토콜로 이끌어냈다. (대부분의 사례에서, 단순함의 많은 이점은 보안에 대한 요구와 함께 사라졌지만, 구조적인 것은 남아있다.)
상태를 보존하지 않는 것은 개발자들이 어떻게 여러 요청에 걸쳐서 통신을 유지할지 고려하도록 강요하는 HTTP의 다른 기능이었다. 대부분은 사용자와 개발자에게 눈에 띄지 않는 도전을 하게 만들었던 쿠키-나는 지금 그것에 대한 책을 썼던 것을 후회하고 있다-를 사용했지만, 끝없는 사용자 추적 전략을 가능하게 했고 지속성을 제공했다.
2000년 즈음에, 전송과 방화벽을 쉽게 통과하기 위해 HTTP POST 요청을 사용하는 "웹 서비스"가 나왔다. 단일 페이지 애플리케이션의 경우, 웹 아키텍처와 유사하지 않거나 더 많은 기능상의 이점을 가진 아키텍처를 추구하여 웹 기반 구조(infrastructure)를 사용했다. 대신 CORBA와 당시의 엔터프라이즈 아키텍처에서 많은 영감을 얻었다.
그 당시 나는 대부분의 웹 서비스가 프로그래밍 작업 쪽으로 방향을 돌려 작업하는 것이 적합하지 않았고, XML을 망가뜨리는 것을 우려했다. 다행스럽게도 HTTP는 적어도 스스로를 보살피고 있었고, 한 박사학위논문 챕터의 독특한 형태의 반격이 끌어당기게 만들었다.
HTTP의 강점으로 알려진 REST는 특히 자원에 대한 균일한(그리고 최소화된) 인터페이스를 제공한다. HTTP의 제약은 사실은 HTTP의 장점이었다. 종교적인 것처럼 들리지만 주장의 본질은 무엇이 진정으로 RESTful인지 아닌지에 대한 끝없는 논쟁을 이끌어냈다. 초기의 생성-읽기-갱신-삭제(CRUD)의 논의처럼 HTTP와 유사한 애플리케이션들과 프레임워크들(특히 레일즈)이 맹목적으로 사용하는 동작을 이끌어냈다.
나에게 있어 REST의 성장 중 가장 주목할 만한 부분은 웹 서비스 지지자들이 대중세계와 국제적인 엔터프라이즈 세계 모두에 도달한다고 주장하는 것이다. 웹 서비스는 엔터프라이즈 개발자들의 기대에 기반을 두고 있다. 실질적으로, REST는 엔터프라이즈 개발자들이 아키텍처와 거대한 공용 웹 세계 사례에서 많은 것을 신속하게 할 수 있다는 것이 입증되었다.
최근에 REST가 아닌, 하이퍼미디어 인터페이스가 프로그램을 구성하는 방법의 전통적인 요구를 추진하고 있다. 일부 프로그래머가 문서와 하이퍼텍스트 웹 프로그래밍에 근거하여 가지고 있는 단지 운이 없는 기이한 일이라는 불만에도 불구하고, 나는 도와줄 수 없지만 분산된 개발에서 문서 기반으로 접근하는 방식은 버그가 아닌 기능으로 본다.
HTTP는 몇 가지 주요한 한계가 있다 - 클라이언트와 서버 그리고 중개인이 쏟아지는 컨텐츠의 상대적으로 큰 덩어리를 전송하기를 기대하는 프로토콜이다. 이는 사용자간 접속(peer-to-peer)과 아니라, 효율적으로 적은 컨텐츠를 처리하거나 항상 열려있는 연결을 훌륭하게 다루는 것이다. 이러한 경우, 다른 교육과 다른 기술, 특히 사용자간 접속을 위한 WebRTC와 작고 항상 작동하는 웹 소켓이 필요한 것을 깨닫게 해준다.
그러나, Web 웹의 동료들처럼 HTTP는 그 한계에도 불구하고, 그 한계 때문에 다양한 상황에서 크게 성공했다. HTTP는 심지어 자손이 있다. 제한된 애플리케이션 프로토콜(Constrained Application Protocol)로, 이는 더 경량의 상황에서 Restful HTTP 동작을 지원한다.
웹이 (일반적으로) 더 좋다
나쁠수록 좋다, Richard Gabriel은 "유닉스와 C는 궁극적인 컴퓨터 바이러스들이다."라고 주장했다. 그들은 있었다. 오늘날, 웹은 훨씬 더 바이러스성이 입증되었다.
구조적인 문서 교환은 우리가 프로그램을 작성하고 공유하는 방법을 바꿀 것이라고 누구나 예측할 수 있는 분야가 아니었지만 매우 잘 맞는 분야로 판명되었다. 그것은 모든 문제를 해결하지 못하지만 - 브라우저에서 포토샵이나 영상 처리 소프트웨어를 다시 작성하려고 하지 말라 - 80/20 법칙보다 더, 앞으로 훨씬 발전 할 것으로 보인다.
왜 잘된 것일까? 분산된 애플리케이션 개발은 항상 어렵고, 웹은 거의 시작부터 분산되어 있다. 내 생각에 일부는 초기 웹의 독특한 스트레스와 함께 할 수 있다: 제한된 자원으로 프로젝트를 확장해야 하고, 제한된 대역폭으로 컨텐츠 전달을 확장해야 한다. 그 모범사례는 우리가 대체로 잊어버린 어려운 상황에서 성장했다. 하지만, 다른 중요한 부분은 제공된 접합과 목표의 기본 집합인 URL이다.
나는 지난해 확장 가능한 웹 선언(Extensible Web Manifesto)를 보고 매우 좋아했다. 나에게는 존재하는 웹 기반구조 위에 새로운 가능성을 만들기 위한 비전을 추구하는 것처럼 보였다. "작은 변화" 맞는 말 같지만, 그게 작은가? 최근에 나는 강한 충격을 받았다. 다른 사람들은 프로그래머의 이미지에서 허물고 이미지를 새로 만들 수 있는 기회로 받아들였다. 장애물을 제거하거나 불안정한 것을 최소화하는 것이 겹쳐지는 것 이야말로 웹을 확장할 수 있고 접근할 수 있게 만든다
웹을 확장하고 더 많이 도움을 주어라 - 하지만 이미 제공하는 많은 강점들에 대해 가치 있게 여겨라.
이 흥미로운 무모한 일이나, 그 근원을 더 깊게 살펴보고 싶다면, 무료로 관련된 글을 모아둔 The Web Platform: Building a Solid Stack of HTML, CSS, and JavaScript를 살펴보거나, O"Reilly 에 Fluent Conference와서 나에게 질문하면 된다.
저자 : Simon St. Laurent
역자 : 김준환
원문 : Web application development is different (and better)
프론트엔드와 백엔드에서 웹은 일반적인 통념에 도전하고 있다.
웹은 가장 흔히 볼 수 있는 분산된 애플리케이션 시스템이 되었기 때문에 프로그래밍 환경으로 생각할 필요가 없다. 나는 거의 매일 프로그래머들(심지어 뛰어난 프로그래머들도)이 얼마나 많이 하위의 낯선 부분들을 처리해야 하는지, HTML을 완전히 분리하고 캔버스로 대체한 것에 대한 역사적인 사건을 얼마나 수정하고 싶어하는지, 그리고 얼마나 관심사의 분리가 불편한지에 대해 투덜대는 언급이나 불평을 보았다. 모든 것은 자바스크립트여야 한다.
(내가 작성한 것과 완벽한 대조를 이루는 시리즈를 트윗한 Tom Dale(father or devops)에게 사과한다. 그는 자바스크립트의 렌더링 스택의 새로운 구축에 대한 비전을 가지고 있었다. 하지만 그 트윗들은 색다르지 않은 의견들이다.)
웹은 다르다, 그리고 나는 왜 프로그래머들이 웹을 선택하는 과정에 대해서 관용적이지 못했는지 볼 수 있었다. 하지만 이때의 프로그래머들은 틀렸다. 웹이 완벽하다는 것은 아니다. - 틀림없는 작은 문제들을 가지고 있다. 무언가 더 나은 것이 성공을 의미하는 것은 아니다. 많은 심각한 문제들은 광범위한 사용자들에 의해 발견되고, 끝없는 단계의 나쁠수록 좋다는 대화들이 있다. 그리고 물론 웹은 모든 프로그래밍이 요구하는 것을 해결하지 못한다. 많은 문제들과 단순히 맞지 않을 뿐이다. 그래도 괜찮다.
그러면 왜 웹이 더 좋은가?
웹은 사람과 기술적인 책임 분배 모두에 허용된 몇 가지 중요한 선택을 통하여, 프로젝트 확장성 문제를 다루는 것을 가능하게 해준다. 이러한 선택은 타협이지만, 타협이 이룬 균형은 모든 수준의 개발자들이 웹에 기여할 수 있게 한다.
웹은 훌륭한 타이밍을 가지고 있었다. 초기 몇 해 동안은 웹이 무엇인지에 대하여 정리되고 개발되었다. 다음 엄청난 성장이 이뤄진 몇 해 동안은 개발자들이 할 수 있는 크고 작은 실수와 그 실수들을 수정하기 위해 총력을 기울이고, 수정된 것들이 자리 잡는 조용한 기간이었다. 심지어 이 조용한 기간에도, 웹은 거대한 크기로 유지되고 있었으며, 웹 프로젝트는 지속적으로 그 크기와 영역이 성장하고 있었다.
웹만이 분산된 애플리케이션을 만드는 좋은 방법인 것은 아니다. 단지 많은 사람들이 만들고자 원하는 때에 나타났다. 프론트 엔드와 백엔드 사이, 그리고 둘 사이의 결합이 유일한 기능 집합과 제약으로 성립되어 훌륭한(그리고 계속 유지할 수 있는!) 애플리케이션들을 쉽게 구축할 수 있게 만들었다.
프론트 엔드
초기에 HTML이 있었다. 더 정확히 말하면, 접착제처럼 GOTO 역할을 하는 하이퍼텍스트 링크였다. 콘텐츠, 구조, 서식, 동작 그리고 링크들이 모두 텍스트 문서들 안에 갇힌 Ted Nelson이 만들어낸 최악의 기술적 악몽이었다.
웹(웹 사이트들)이 거대해지자, 검색과 교체는 한계에 부딪쳤다. 기반 계층인 HTML은 여전히 콘텐츠, 구조, 그리고 하이퍼링크 동작을 혼합하여 포함하고 있지만 관심사의 분리는 웹 콘텐츠를 유지보수하고 배포하는 것을 더 쉽게 만들어 준다. 결국 오늘날 우리가 가진 웹 애플리케이션이 생겨났다.
하이퍼텍스트 마크업 언어 (HTML)는 대다수 사람들이 이해하기 쉽다. 모두는 아니지만 프로그래머나 디자이너들 보다 더 많은 사람들이 할 수 있다. 마크업이 어떻게 동작하는지, 적은 주요 태그들에 대한 기본 지식만 있으면 기본 페이지들부터 복잡한 애플리케이션까지 다른 사람들이 많은 상황에서 사용할 수 있는 콘텐츠를 만들 수 있다. 나는 여전히 "HTML 코드"를 볼 때마다 아차 하지만 적절하게 사용한다. - HTML은 프로그래밍 언어 자체가 아니지만, 분명히 콘텐츠와 구조를 표현한다.
HTML에서 애플리케이션의 밑그림을 그리는 것은 흔히 문서나 포토샵으로 하는 것보다 더 쉽다. 텍스트는 저장하고 다루기 쉽다(표현하는데 머리가 아프기는 하지만). 구글은 이에 의존하는 하나의 주요 검색엔진의 사례다. 마크업 구조는 또한 트리로 정의된다. 문서 객체 모델(DOM), 또는 DOM 경험의 개선을 추구하는 수많은 래퍼들은 개발자들이 트리 형태에 접근할 수 있도록 해준다.
계단형 스타일 시트(CSS)는 HTML을 작성할 때 정확히 어떻게 보여야 하는지를 생각하는데 겪는 어려움을 피하게 해준다. 웹 브라우저 내부 레이아웃에 대한 지속적인 관심과 더 많은 로직을 추가하기 위한 노력으로 복잡한 세계가 되어가는데도 불구하고, CSS는 가장 적절한 수준에 이르렀다. CSS의 서술적인 접근은 사람이 만드는 것과 브라우저에 효율적으로 적용하는 것을 쉽게 만들었다. "계단식"은 때때로 세부적인 부분에서 설명하기 힘들지만, 대개 복잡한 솔루션이 요구하는 충분한 수준으로만 사용되는 상황으로 보인다. 가장 나를 놀라게 했던 것은, CSS는 절차적 환경에서는 불가능한 방법으로 하드웨어 가속 애니메이션과 변형을 통합하도록 해준다.
CSS는 아름답게 만드는 것을 돕는 것을 넘어서, 웹 아키텍처에서 중요한 역할을 한다. CSS는 애플리케이션 컴포넌트들을 포함한 HTML 문서들의 라이브러리를 관리하고, 중복과 오류를 감소시키는 것을 훨씬 쉽게 만든다. 분명한 사실은 여러 문서에 적용되는 표현 정보는 많은 장점을 가진다는 것이다.
- 프로그래밍 관점에서, HTML과 CSS사이의 "관심사의 분리"는 "반복하지 말라"(DRY)는 프로그래밍 관점에 딱 들어맞는다. 스타일 시트는 내부적으로 반복될지도 모르지만, 모든 문서에 반복적으로 정보를 표현하는 것에 비하면 쉬운 일이다.
- 네트워크 성능 관점에서, 스타일 시트 재사용을 통한 캐싱 작업을 더 효율적으로 만들어 준다.
- 디자인 관점에서, 디자이너가 사람들이 컨텐츠를 만들기 위한 훨씬 간단한 가이드라인으로 디자인해 나가는 것을 더 쉽게 만든다.
CSS는 두 가지 문화적인 문제점들을 갖는데, 하나는 디자인 측면 그리고 다른 하나는 프로그래밍 측면이다. HTML 문서들이 (가장) 자연스럽게 반응하지만, 어떠한 크기든 브라우저 컨테이너가 요구하는 텍스트가 차지하는 공간을 조절하기 위한 부가적인 제어 CSS는, 아름답지만 불안정한 레이아웃을 디자이너에게 권장한다. 레이아웃과 미디어 쿼리를 위한 새 기능은 가능한 다시 한 번 반응형 웹 디자인을 만든다. 프로그래밍 측면에서, 매우 그럴 듯한 태도의 풍자로 밝히는 것처럼 CSS는 프로그래밍이 아니다.
자바스크립트는 동작을 제공한다. 자바스크립트는 오랫동안 완전히 객체지향적도 아니고, 함수형 프로그래밍 언어도 아니라는 많은 비판을 받았지만, 가벼운 언어에서 반드시 배워야만 하는 언어가 되었다. 자바스크립트에 대한 비난과 비판은 멈추지 않았고, 자바스크립트 프로그래머들은 매우 다양해졌지만, 자바스크립트의 강점은 분산된 애플리케이션 개발과 매우 잘 어울린다.
과거 수년 사이에, 브라우저 벤더들은 개발자들에게 더 많은 컨텐츠와 장비들 사이의 상호작용 기회를 제공하기 위한 애플리케이션 프로그래밍 인터페이스(API)를 만들었다. 한 때, 자바스크립트를 넘어선 (지금은 금지된) 상태 표시줄 트릭, 문서 객체 모델 (DOM)은 첫 번째 단계였다. DOM은 좀처럼 "가장 좋은 API 디자인" 목록을 만들지 않았지만, 시간이 지남에 따라 개선되었고, 개발자들은 더 유용하게 DOM을 감쌌다. 더 최근의 API들은 로컬 저장공간이나 장비에 접근할 수 있는 기능을, 브라우저 밖으로 벗어나와 접근 권한 없이 사용자 컴퓨터의 모든 것에 접근할 수 있도록 제공한다.
Ajax는 2005년 Jesse James Garrett이 명명하고 몇 차례 언급했던, 웹 기술들과 1999년 인터넷 익스플로러에서 나타난 XMLHttpRequest 객체의 결합으로 API 위에 구축된 개발패턴이다. 더 많은 브라우저들로 아이디어가 확산되는데 시간이 걸렸지만, 불현듯 거대한 프로그래머 그룹이 프론트엔드 애플리케이션들을 구축했다(객체 이름에도 불구하고, 자주 자바스크립트에서 데이터 포맷을 XML대신에 JSON을 사용했다).
웹은 물론 이러한 도구들로 더 많은 일을 하고 있다.
웹 컴포넌트를 통해 더 강화된 자바스크립트는, 개발자들이 브라우저의 동작을 확장하게 할 수 있다. CSS는 개발자들이 어떻게 컨텐츠를 표현해야 하는지 브라우저에 명령할 수 있게 한다. 이러한 옵션 및 추가 API 사이에, Alex Russell이 불평한 "3등급의 어휘" 이상으로 HTML을 확장하는 것이 가능하다. 웹 프론트 엔드의 다른 부분들이 스스로의 표준들을 만들었기 때문에 이제 "모든 HTML은 반드시 표준이어야 한다"는 주장은 버릴 수 있다.
이것은 무엇을 의미하는가? 그 의미는:
- 개발자들은 그들의 인터페이스들을 조정하기 위해 API들을 감쌀 수 있다.
- 개발자들은 브라우저들 사이에 누락된 API나 다른 기능 차이를 메울 수 있다.
- 개발자들은 웹 컴포넌트를 사용하여 HTML 어휘를 확장할 수 있다. 달력 또는 탭 바 또는 툴 팁을 원하는가? 하나의 벽돌을 추가하거나 하나의 고분자를 생성하면 된다. 또는 당신의 손으로 말아라. HTML이 가진 어휘는 경계 벽보다는 기초 벽이 된다.
적어도 자바스크립트를 사용하는 폴리필은 아직 작은 결함을 가진다: 동작을 하기 위해 자바스크립트가 요구된다. 실패들은 대부분 우리가 보았듯이 극적이지 않다. 예를 들어, Sigh, JavaScript의 미묘한 실패는 실제로 더 어려운 문제를 만들 수 있다.
Sigh, JavaScript에서의 대부분의 실패에도, 자바스크립트는 웹 애플리케이션 개발의 구석진 자리에서 HTML/CSS/자바스크립트 스택으로 되돌아왔다. 그런 접근법은 웹 애플리케이션을 주로 자바스크립트라고 생각하게 만들었다. HTML은 단순히 자바스크립트를 로딩하고 모든 것을 DOM을 통해 설정하는 외부구조이다(더 극단적인 케이스에서는, 캔버스). 이 모델에서는 생성된 마크업이 보일 때 디버거를 통해 프로그래머가 모두 제어 하는 것을 기대할 수 있다. CSS는 여전히 분리되어 있겠지만, 더 쉽게 반복되는 문서들보다는 애플리케이션에 대해 항상 테스트되어야 한다.
단일 페이지 애플리케이션은, 다른 데스크톱이나 모바일 애플리케이션 모델들, 심지어 Flash까지 프로그래머의 기대에 매우 잘 어울리는 방법들 중 가장 두드러진다. 웹은 이 모델을 수용할 수 있고(프론트와 백 엔드 상에서 모두), 브라우저의 성능은 다른 방식의 네이티브 애플리케이션들과 경쟁할 수 있는 정도까지 향상되었다. 하지만, 상당수는 웹 사고방식의 확장성을 버렸다.
프로그래머는 애플리케이션의 왕과 왕비일지도 모르지만, 모든 것을 감싸기에 충분하지 못하다. 단일 페이지 애플리케이션은 또한, 기반 마크업과 컨텐츠를 채우기 위해 자바 스크립트를 사용하는 것을 강조하여 오명을 뒤집어 쓴다: 그들은 사실상 구글에서 보이지 않는다. 일부의 경우 괜찮다: 그들은 구글이나 다른 스크랩퍼들이 그들의 고객들의 데이터를 들여다 보는 것을 원치 않는다. 구글이 내부를 살펴 볼 때 서버 팜에서 마크업을 생성할 수도 있고, 클라이언트와 서버 사이에 코드를 이동하는 연륜이 여러 상황에서 성공할지도 모른다. 더 혼합된 아키텍처의 Isomorphic JavaScript는 그 토대를 찾은 것처럼 보인다.
접합
거의 초기인 1994년에 URL이 있었다. URL은 획일적인 자원 지시자(uniform resource locator, URL의 정식명칭)나 웹 주소로 웹 개발의 프론트와 백 엔드를 연결할 뿐만 아니라, 하이퍼링크로 연결하는 것을 쉽게 만들어주었다. 텍스트 기반인 URL을 컴퓨터가 읽을 수 있는 그래픽으로 교체하기 위한 다양한 시도(CueCat에서 QR 코드까지)에도 불구하고, URL은 여전히 일반적이고, 교체를 시도했던 후임자를 위한 기반이 된다.
프론트 엔트에서 URL은 항해(URL을 통한 이동)의 중심이었다. 하이퍼링크된 대상들, 북마크(즐겨찾기) 가능한 컨텐츠, 그리고 뒤로 가기, 앞으로 가기 버튼의 단순한 모델의 시작지점을 제공했다(홈페이지를 생각해보라). Ajax가 나오자, 페이지들은 불현듯 새로운 컨텐츠를 기반 URL의 변경 없이 로딩하기 시작했다, 뒤로 가기 버튼은 예측할 수 없게 되었다. 해법인 히스토리 API는 브라우저 히스토리를 자바스크립트 코드가 직접 관리하게 하는데 기여했다. 도움이 되었지만, "주: URL은 실제가 아니므로, 페이지를 새로 고침하면 유효하지 않은 URL로 갈 것입니다."와 같이 거부하는 자세에 대한 시연도 만들어냈다
URL의 오른쪽 끝에서 #으로 시작하는 선택적 부분인 단편화 식별자는, 문서의 명확한 지점에 도달하도록 더 나아가게 한다. 불행하게도, HTML 어휘나 다중 페이지 어느 쪽이든 브라우징 모델의 기본적인 기대를 남겨두고 가면 단편화 식별자는 곧 복잡해진다. 단일 페이지 애플리케이션에서 단편화 식별자를 다시 만드는 것은 몇 년 전 프로젝트에서 그다지 좋아하지 않는 부분이었다. 물론 모두가 나처럼 단편화 식별자에 대해 흥분한 것은 아니었다(심지어 방향 능력을 확장하는 문법을 제안 했다. - 여기서 더 볼 수 있다.)
백엔드에서 URL은 적어도 지난 몇 년 동안 도메인 이름의 오른쪽 부분은 실제동작이 바뀌었다. 서버상의 파일들의 구조 정보로 사용되었고, 아직도 가끔은 사용되지만, 많은 웹 프레임워크들은 라우팅 방법을 통해서 제어를 집중시킨다. PHP는 레일즈 역사에 있어 가장 중요한 컴포넌트를 만드는 동안, 거대한 파일들의 집합에서 응용프로그램 논리를 배포하는 좋은 기수였다. 다른 모델들이지만, 백엔드 개발자들은 URL은 같은 애플리케이션의 다른 방향들을 가리키는 화살표로서 동작할 수 있어야 한다는 주장에 대체로 동의했다.
잠시 중지하고, 당신이 기대하는 다른 애플리케이션 상황에 대해서 생각해보자. 애플리케이션을 데스크톱이나 모바일에서 열 때, 내가 지난번 어디서 열었는지 또는 새 화면에서 여는지 나의 선택은 매우 많다. 특히 내가 원하는 방식이 여러 가지라면, 내가 원하는 방식으로 애플리케이션을 열게 하는 것이 쉽지 않다. 웹에서 이것은 대게 사소하다 - URL은 애플리케이션에서 특정 지점에 연결하게 하고, 일부-영리한 개발모델들이 필요에 따라 로그인하게 한 다음 당신이 방식으로 동작한다. 더 확장할 수 있는 여지가 있겠지만 URL은 다른 애플리케이션들이 겨우 고려하기 시작한 기능을 웹 애플리케이션을 위해 만들 수 있다.
URL은 어느 정도 성공에 대한 처벌을 받았다. Tim Berners-Lee가 시맨틱 웹의 비전 쪽으로 관심을 옮기기 시작하면서 URL에 대한 흥미가 줄어들었다. URL에 대한 대부분의 명확한 이야기 대신, W3C는 현재 많은 시간을 URI(Uniform resource identifier)의 신학에 맞춰 일했다. 유머 감각에 어둡고, 기술 대화를 좋아하고, 많은 시간이 있다면, 당신은 여기에 1년을 낭비할 수 있다. 끝난 것 같지만 끝나지 않은 URI시공간 연속체의 분할이나 그 이전의 대화 대신 그냥 httpRange-14를 찾아라.
백엔드
초기에 HTTP가 있었다. 클라이언트가 URL로부터 컨텐츠를 얻어오는(GET) 기능을 제공했지만, 시간이 흐르면서 많은 수의 메소드-행동-로 확장되었다. GET과 POST가 우세했지만, PUT과 DELETE 또한 개발자들이 웹 애플리케이션에서 정보를 관리하는데 중요한 부분이 되었다.
HTTP가 가진 원래의 매력적인 요소는 HTTP가 가진 단순함이었다. 실제로 많은 것을 하지 않았고, 어디에나 있으며, 무해한 것처럼 여겨지는 점이 결합하여 대체로 방화벽 벤더들이 방화벽을 통과하게 할 용의를 갖도록 만들었다. 때문에 웹 컨텐츠에 대한 소비에 대한 관심은 대역폭 보다 더 빠르게 성장했다 HTTP를 유지 보수하는 사람들은 캐싱과 프록시에 높은 우선 순위를 유지했다. 몇 번의 반복 후에 여전히 상대적으로 단순하지만, 성능에 높은 관심 보이는 프로토콜로 이끌어냈다. (대부분의 사례에서, 단순함의 많은 이점은 보안에 대한 요구와 함께 사라졌지만, 구조적인 것은 남아있다.)
상태를 보존하지 않는 것은 개발자들이 어떻게 여러 요청에 걸쳐서 통신을 유지할지 고려하도록 강요하는 HTTP의 다른 기능이었다. 대부분은 사용자와 개발자에게 눈에 띄지 않는 도전을 하게 만들었던 쿠키-나는 지금 그것에 대한 책을 썼던 것을 후회하고 있다-를 사용했지만, 끝없는 사용자 추적 전략을 가능하게 했고 지속성을 제공했다.
2000년 즈음에, 전송과 방화벽을 쉽게 통과하기 위해 HTTP POST 요청을 사용하는 "웹 서비스"가 나왔다. 단일 페이지 애플리케이션의 경우, 웹 아키텍처와 유사하지 않거나 더 많은 기능상의 이점을 가진 아키텍처를 추구하여 웹 기반 구조(infrastructure)를 사용했다. 대신 CORBA와 당시의 엔터프라이즈 아키텍처에서 많은 영감을 얻었다.
그 당시 나는 대부분의 웹 서비스가 프로그래밍 작업 쪽으로 방향을 돌려 작업하는 것이 적합하지 않았고, XML을 망가뜨리는 것을 우려했다. 다행스럽게도 HTTP는 적어도 스스로를 보살피고 있었고, 한 박사학위논문 챕터의 독특한 형태의 반격이 끌어당기게 만들었다.
HTTP의 강점으로 알려진 REST는 특히 자원에 대한 균일한(그리고 최소화된) 인터페이스를 제공한다. HTTP의 제약은 사실은 HTTP의 장점이었다. 종교적인 것처럼 들리지만 주장의 본질은 무엇이 진정으로 RESTful인지 아닌지에 대한 끝없는 논쟁을 이끌어냈다. 초기의 생성-읽기-갱신-삭제(CRUD)의 논의처럼 HTTP와 유사한 애플리케이션들과 프레임워크들(특히 레일즈)이 맹목적으로 사용하는 동작을 이끌어냈다.
나에게 있어 REST의 성장 중 가장 주목할 만한 부분은 웹 서비스 지지자들이 대중세계와 국제적인 엔터프라이즈 세계 모두에 도달한다고 주장하는 것이다. 웹 서비스는 엔터프라이즈 개발자들의 기대에 기반을 두고 있다. 실질적으로, REST는 엔터프라이즈 개발자들이 아키텍처와 거대한 공용 웹 세계 사례에서 많은 것을 신속하게 할 수 있다는 것이 입증되었다.
최근에 REST가 아닌, 하이퍼미디어 인터페이스가 프로그램을 구성하는 방법의 전통적인 요구를 추진하고 있다. 일부 프로그래머가 문서와 하이퍼텍스트 웹 프로그래밍에 근거하여 가지고 있는 단지 운이 없는 기이한 일이라는 불만에도 불구하고, 나는 도와줄 수 없지만 분산된 개발에서 문서 기반으로 접근하는 방식은 버그가 아닌 기능으로 본다.
HTTP는 몇 가지 주요한 한계가 있다 - 클라이언트와 서버 그리고 중개인이 쏟아지는 컨텐츠의 상대적으로 큰 덩어리를 전송하기를 기대하는 프로토콜이다. 이는 사용자간 접속(peer-to-peer)과 아니라, 효율적으로 적은 컨텐츠를 처리하거나 항상 열려있는 연결을 훌륭하게 다루는 것이다. 이러한 경우, 다른 교육과 다른 기술, 특히 사용자간 접속을 위한 WebRTC와 작고 항상 작동하는 웹 소켓이 필요한 것을 깨닫게 해준다.
그러나, Web 웹의 동료들처럼 HTTP는 그 한계에도 불구하고, 그 한계 때문에 다양한 상황에서 크게 성공했다. HTTP는 심지어 자손이 있다. 제한된 애플리케이션 프로토콜(Constrained Application Protocol)로, 이는 더 경량의 상황에서 Restful HTTP 동작을 지원한다.
웹이 (일반적으로) 더 좋다
나쁠수록 좋다, Richard Gabriel은 "유닉스와 C는 궁극적인 컴퓨터 바이러스들이다."라고 주장했다. 그들은 있었다. 오늘날, 웹은 훨씬 더 바이러스성이 입증되었다.
구조적인 문서 교환은 우리가 프로그램을 작성하고 공유하는 방법을 바꿀 것이라고 누구나 예측할 수 있는 분야가 아니었지만 매우 잘 맞는 분야로 판명되었다. 그것은 모든 문제를 해결하지 못하지만 - 브라우저에서 포토샵이나 영상 처리 소프트웨어를 다시 작성하려고 하지 말라 - 80/20 법칙보다 더, 앞으로 훨씬 발전 할 것으로 보인다.
왜 잘된 것일까? 분산된 애플리케이션 개발은 항상 어렵고, 웹은 거의 시작부터 분산되어 있다. 내 생각에 일부는 초기 웹의 독특한 스트레스와 함께 할 수 있다: 제한된 자원으로 프로젝트를 확장해야 하고, 제한된 대역폭으로 컨텐츠 전달을 확장해야 한다. 그 모범사례는 우리가 대체로 잊어버린 어려운 상황에서 성장했다. 하지만, 다른 중요한 부분은 제공된 접합과 목표의 기본 집합인 URL이다.
나는 지난해 확장 가능한 웹 선언(Extensible Web Manifesto)를 보고 매우 좋아했다. 나에게는 존재하는 웹 기반구조 위에 새로운 가능성을 만들기 위한 비전을 추구하는 것처럼 보였다. "작은 변화" 맞는 말 같지만, 그게 작은가? 최근에 나는 강한 충격을 받았다. 다른 사람들은 프로그래머의 이미지에서 허물고 이미지를 새로 만들 수 있는 기회로 받아들였다. 장애물을 제거하거나 불안정한 것을 최소화하는 것이 겹쳐지는 것 이야말로 웹을 확장할 수 있고 접근할 수 있게 만든다
웹을 확장하고 더 많이 도움을 주어라 - 하지만 이미 제공하는 많은 강점들에 대해 가치 있게 여겨라.
이 흥미로운 무모한 일이나, 그 근원을 더 깊게 살펴보고 싶다면, 무료로 관련된 글을 모아둔 The Web Platform: Building a Solid Stack of HTML, CSS, and JavaScript를 살펴보거나, O"Reilly 에 Fluent Conference와서 나에게 질문하면 된다.
TAG :
이전 글 : 라즈베리 파이로 만든 DIY 게임 보이 포켓
다음 글 : 데브옵스(DevOps)가 무엇인지에 대한 재조명
최신 콘텐츠