이 장에서는 웹이 지닌 역사적 배경을 하이퍼미디어 시스템과 분산 시스템의 두 가지 측면에서 설명하겠습니다.
👨🏻💻 웹 이전의 인터넷
인터넷의 기원은 1969년에 구축된 ARPANET까지 거슬러 올라갑니다. ARPANET은 미국 내 대학과 연구기관 사이를 고속 회선으로 접속하고, 전 미국을 연결하는 네트워크로서 서서히 성장해갔습니다.
👨🏻💻 웹 이전의 하이퍼미디어
하이퍼미디어는 웹이 등장하기 이전부터 있던 기술입니다.
Memex - 하이퍼미디어의 기원
- 하이퍼미디어의 기원은 1945년 미국의 연구자 버니바 부시가 발표한 ‘Memex’라는 정보 검색 시스템에 대한 논문이라고 합니다.
- Memex는 실재하는 시스템이 아닌 구상이었지만, 전기적으로 접속한 책과 파일을 서로 링크하고 링크를 따라서 차례로 표시하는 현재의 웹을 예상할 수 있는 시스템이었습니다.
- 이 Memex 구상에는 하이퍼미디어라는 단어조차 등장하지 않았지만 많은 연구자들에게 영향을 끼쳤습니다.
Xanadu - 하이퍼미디어라는 단어의 탄생
- 하이퍼텍스트가 문자 정보 중심의 문서를 상호 링크시키는 개념임에 반해, 하이퍼미디어는 그 사고를 확장하여 음성과 동영상 등 다양한 미디어를 상호 링크시킨 개념입니다.
- 넬슨은 1965년에 이 단어들을 고안함과 동시에 현재의 웹을 더욱 진화시킨 기능을 가진 이상적인 하이퍼미디어 Xanadu를 구상하고 개발하기 시작했지만 고기능으로 인한 복잡성으로 실패하고 말았습니다.
HyperCard - 최초의 실용적인 하이퍼미디어
- Bill Atkinson이 1987년 Apple에서 개발한 HyperCard에는 네트워크를 통해 데이터를 주고받는 기능조차 없었지만, ‘카드'라고 불리는 문서를 단위로 상호 링크하고, 스크립트 언어 HyperTalk에 의한 프로그램을 실행할 수 있는 Stand-alone 방식의 웹 서비스였습니다.
웹 이전의 하이퍼미디어의 문제점
- 지금까지 가장 많이 보급된 하이퍼미디어의 구현은 웹입니다. 웹상의 문서는 모두가 링크에 의해 서로 연결되어 있습니다. 링크가 웹에 필수불가결한 기본 기술이라는 사실.
- 다만, 넬슨 등 예전의 하이퍼미디어 추진자들의 시각으로 볼 때, 웹은 불완전한 하이퍼미디어로 비춰질 것입니다. 그 이유는 웹이 단방향 링크 밖에 지원하고 있지 않고, 링크가 끊어질 가능성이 있으며, 버전 관리와 트랜스클루전 기능이 없는 것 등입니다.
- 웹의 성공을 가져온 원인은 최소한의 링크 기능만을 갖추고 있었다는 점입니다. 반대로 웹 이전의 하이퍼미디어의 최대 문제점은 그 복잡성에 있었다고 할 수 있습니다.
👨🏻💻 웹 이전의 분산 시스템
분산 시스템도 웹이 등장하기 이전부터 있던 기술입니다.
중앙 집중형 시스템과 분산 시스템
- 1960년대에 메인 프레임이 개발되면서 한 대의 컴퓨터를 여러 목적으로 이용될 수 있게 되었습니다. 이 당시 컴퓨터의 이용 형태는 단말기로 호스트 컴퓨터에 접속하여 호스트 컴퓨터에서 집중해서 처리할 수 있는 중앙 집중형 시스템이였습니다.
- 1970년대 이후, 컴퓨터의 다운 사이징이 진행되면서 컴퓨터들이 소형화되고 성능은 향상됨에 따라 복수의 컴퓨터를 조합하여 처리를 분산시킴으로써 전체의 성능을 향상시킬 수 있는 분산 시스템이 가능해졌습니다.
RPC - 다른 컴퓨터의 기능을 이용하기
분산 시스템을 실현하기 위해서는 각 서버가 제공하는 기능을 다른 서버와 클라이언트에서 호출할 수 있어야 합니다.
- RPC를 이용하면 원격 서버에서 실행하고 있는 프로그램을 클라이언트 쪽에서 호출할 수 있습니다.
- 유명한 RPC 시스템으로는 Sun Microsystems의 sunRPC와 아폴로, IBM과 DES가 공동 개발한 DCE가 있습니다.
- RPC 시스템이 개발되던 1980년대 후반은 ‘UNIX 전쟁'이라고 불리는 UNIX 벤더에 의한 표준화 경쟁이 치열하던 시대로, 모두 자사의 분산 시스템 기술을 표준으로 하기 위해 열심이었습니다.
CORBA, DCOM - 분산 오브젝트의 진화
RPC는 리모트 프로시저(Remote Procedure), 즉 함수를 호출하는 구조입니다. 다만, 현대적인 프로그래밍 언어들은 거의 모두가 객체지향 기능을 갖추고 있기 때문에
단순한 함수 호출이 아니라, 오브젝트 자체를 원격으로 배치하는 ‘분산 오브젝트(Distributed Object)’라고 불리는 기술이 고안되었습니다.
- CORBA(Common Object Request Broker Architecture)
- Microsoft는 CORBA에 대항해서 DCOM(Distributed Component Object Model)을 개발했습니다.
CORBA와 DCOM은 IDL(Interface Definition Language)로 오브젝트의 메서드를 정의하고, 구현은 네트워크를 경유해 시리얼라이즈 된 메시지를 교환하는 점이 RPC와 동일합니다. 단, 범용적인 오브젝트 기능을 실현하려고 했기 때문에 매우 복잡한 스펙을 가지게 되었습니다. 또한, CORBA와 DCOM은 호환성이 없어서 서로의 시스템이 접속할 수 없다는 문제점도 있었습니다.
웹 이전의 분산 시스템의 문제점
RPC는 지금도 NFS(Network File System) 같은 분산 시스템을 구현하는데 사용되고 있지만
RPC가 현실적으로 동작하는 것은 통신상대가 어느 정도 정해져 있는 인트라넷 환경까지로 좀 더 복잡한 이기종 분산 환경으로 확장되지 않습니다.
다음과 같은 문제점이 각각의 RPC 시스템에 있었기 때문입니다.
- 성능열화의 문제
- 네트워크를 경유한 함수의 호출은 동일 프로세스 내에서 함수를 호출하는 데 비해 몇 배나 시간이 걸린다. 또한, 일반적으로 함수의 입도가 작아 목적을 달성하기 위해선 여러 번 호출하지 않으면 안 되고, 네트워크의 오버헤드가 호출하는 회수만큼 걸린다.
- 데이터형 변환의 문제
- 프로그래밍 언어마다 지원하는 데이터형이 다르기 때문에 복수의 언어가 혼재하는 환경에서는 데이터형 변환 시 문제가 발생한다.
- 부하 분산의 문제
- 일반적으로 RPC 기반의 시스템은 서버 상에 클라이언트의 애플리케이션 상태를 가지고 있다. 그렇기 때문에 서버끼리 애플리케이션 상태를 공유하지 않으면 안 되며, 다수의 서버에서 부하를 분산하는 것이 어려워진다.
웹 이전의 분산 시스템은 균일한 클라이너트를 전제로 했습니다. → 이는 전 세계적인 규모로 동작하는 시스템이 될 수 없음을 의미
👨🏻💻 웹의 탄생
1980년대까지 하이퍼미디어에 대한 구상이 생겨나고 인터넷이 등장하면서 복수의 컴퓨터를 연결한 분산 시스템이 구축되었습니다. 웹은 이런 시대적 환경에 의해 탄생했습니다.
1990년 11월 12일 버너스-리가 하이퍼미디어를 이용한 인터넷 기반의 ‘분산정보관리 시스템'이라는 웹 제안서를 썼고, 그 해 크리스마스 휴가에 첫 버전의 서버와 브라우저를 완성시켰습니다. 버너스-리가 최초 버전을 발표한 이래로, 웹은 전 세계로 서서히 보급되기 시작했습니다.
웹의 보급을 단번에 앞당긴 것이 1993년 일리노이 대학의 NCSA(National Center for Supercomputing Application)가 공개한 브라우저 Mosaic입니다. 그전까지의 브라우저가 브라우저 자체로는 문자정보밖에 다루지 못했던 것에 비해, Mosaic은 Internet Explore나 Firefox 같은 현재의 브라우저의 원류가 되었습니다.
하이퍼미디어로서의 웹
- 웹은 인터넷을 이용한 하이퍼미디어로서 설계되었습니다. 웹 이전의 하이퍼미디어와 가장 큰 차이점은 인터넷을 이용하기 때문에 불특정 다수의 정보를 서로 링크시킬 수 있고, 시스템을 대규모화하기 쉽다는 중요한 이점을 가지고 있습니다. 반면, 정보의 집중적인 관리가 어려워지고 링크가 끊어지기 쉽다는 결점도 가지고 있습니다.
- 웹이 구현하고 있는 링크는 심플한 단방향 링크뿐이라는 점도 특징입니다. 웹에서는 브라우저에 표시하거나 링크를 클릭하면 새로운 웹페이지로 이동합니다. 하지만, 원래 링크의 개념은 외부에서 링크를 지정하는 확장 링크의 개념도 존재했습니다. 웹에 복잡한 링크 구조를 도입하려는 움직임도 있었지만, 결국은 심플한 단방향 링크만 사용되고 있습니다. 사용자에게 있어서 이해하기 쉽고 구현이 간단한 링크였기 때문에 웹이 여기까지 보급되었다고 할 수 있습니다.
분산 시스템으로서의 웹
RPC는 폐쇄된 네트워크 환경에서 미리 상정한 숫자와 종류의 클라이언트를 상대로 서비스를 제공하는 시스템으로는 뛰어납니다. 거꾸로 말하면, 개방된 네트워크 환경에서 불특정 다수의 클라이언트에 대해 서비스를 제공하는 시스템으로는 어울리지 않습니다.
- 개방형이고 불특정 다수를 상대로 하는 시스템이 바로 ‘웹’
- 웹에서는 전 세계의 유저들이 전 세계의 웹 서비스를 이용할 수 있습니다. 각 유저의 컴퓨터 환경은 특정한 OS와 하드웨어로 통일되어 있지 않으며, 다양한 브라우저와 디바이스를 통해 하나의 웹 서비스에 접근할 수 있습니다. 이것이 클라이언트와 서버 간의 인터페이스를 HTTP라는 심플한 프로토콜로 고정함으로써 실현되어 있습니다.
👨🏻💻 웹의 표준화
Mosaic에 의해 폭발적으로 보급된 웹에는 다양한 플레이어가 추가되었고, 학술적인 콘텐츠뿐만 아니라, 뉴스와 오락 미디어의 참여, 쇼핑 사이트의 등장, Microsoft와 IBM, Sun Microsystems 등 대기업들의 가세 등이 1990년대 중후반에 걸쳐 동시다발적으로 일어났습니다.
웹의 스펙 책정
웹을 구성하는 기술, 특히 HTTP와 URI와 HTML에 대한 표준화가 요구되었습니다. 이들은 각 회사의 서버, 클라이언트 사이에서 이용되어야 하고 상호 운용성이 요구되었기 때문입니다.
웹 이전의 인터넷 표준은 모두 IETF의 RFC였지만 웹이 너무나 급속하게 보급되어 버렸기 때문에 IETF에서의 스펙 책정이 따라가질 못하고, 각 기업의 구현은 제각각이라 상호운용성이 결여되는 상태가 발생되어 버렸습니다.
이러한 문제를 해결하기 위해 웹 기술을 구현하고 있는 벤더들이 모여 표준화를 수행하는 단체로서, 1994년에 버너스-리가 중심이 되어 W3C(World Wide Web Consortium)를 설립합니다.
- W3C에서는 HTML, XML, HTTP, URI, CSS(Cascading Style Sheet)등의 표준화 작업이 이루어졌습니다.
Netscape Navigator와 Internet Explorer가 독자적인 확장을 반복한 끝에 HTML과 CSS의 렌더링 결과가 크게 차이가 나게 되었고, 개발자들은 브라우저 별로 대응해야만 하는 사태에 이르게 되었다. 이러한 상황은 오랜 시간이 지나면서 서서히 해결되어 왔지만, 현재에도 문제는 남아 있습니다.
REST 탄생
로이 필딩은 웹이 왜 이렇게 성공했는지, 왜 이정도의 대규모 시스템이 성립된 것인지에 대해 소프트웨어 아키텍처의 관점에서 분석하고, 하나의 아키텍처 스타일로서 REST(Representational State Transfer)을 제시합니다.
다양한 하이퍼미디어 포맷의 탄생
초기 웹에서는 HTML이 유일한 하이퍼미디어 포맷이었지만, 점차 HTML만으로는 대응할 수 없는 다양한 요구가 생겨나기 시작해, 새로운 하이퍼미디어 포맷들이 탄생했다.
- HTML의 구조는 그대로 유지한 채, HTML에 다양한 의미를 가지게 할 수 있는 기술로서 microformats가 등장
- 웹페이지의 새로운 정보를 서버에서 발송하고, 전용 프로그램으로 그것을 체크하기 위한 용도로 RSS(RDF Site Summary, Rich Site Summary, Really Simple Syndication)가 제안됨.
- RSS는 봇수의 버전이 난립해 혼란스러웠던 탓에 최종적으로는 IETF에서 Atom이 표준화되었다.
- HTML과 Atom은 XML을 베이스로 한 구조화 문서용 마크업 언어이기 때문에 데이터를 기술하기 위한 표기가 너무 중복되었다. 그래서 좀 더 단순한 데이터 포맷인 JSON이 등장
👨🏻💻 웹 API를 둘러싼 논의
초기의 웹은 주로 사람이 문서를 읽기 위한 시스템이었지만, 프로그램을 이용해 자동화 처리를 하고자 하는 요구가 등장으로 웹 API에 대한 논의가 일어났다.
SOAP과 WS-
HTTP 1.1을 책정하는 필딩의 그룹과는 별개로, 다양한 배경을 가진 그룹들이 웹을 프로그램에서 이용할 수 있도록 하기 위해 확장을 시도했습니다.
- RPC/분산 오브젝트 그룹의 움직임 중에서 가장 기본적인 프로토콜은 SOAP입니다. SOAP은 HTTP를 애플리케이션 프로토콜이 아닌 트랜스포트 프로토콜로 다루고, HTTP 상에서 독자적으로 메시지를 전송합니다.
- SOAP 역시 메시지 전송 방법만을 규정한 스펙이기 때문에 실제로 시스템을 구축할 때는 SOAP 상에 서비스 별로 프로토콜을 정의하지 않으면 안 됩니다. 결국 이전과 마찬가지의 표준화 경쟁을 불러일으켰습니다.
SOAP 대 REST
필딩은 REST의 이론을 바탕으로 대기업들이 추진하는 SOAP 기반의 기술을 부정하고, 웹이 웹다울 수 있는 아키텍처로서 REST를 권장했습니다. 이후 필딩의 의견을 지지하는 사람들이 서서히 등장했고, 그 중 베이커와 폴 프레스코드는 다양한 미디어를 통해 REST를 선전했습니다.
REST의 오해와 보급
REST의 보급이 탄력을 받기 시작한 것은 2002년에 등장한 Amazon 웹 서비스입니다. Amazon은 SOAP를 이용한 형식과 특정 URI와 HTTP로 GET하는 형식의 2가지를 준비했다. 후자는 기술적으로 정확하지는 않지만 편의상 ‘REST 형식'이라고 불렀다.
Amazon의 웹 API는 유용성과 편리성으로 인해 순식간에 보급되었고, SOAP 대 REST 논쟁에 불을 붙였다. 결과적으로는 REST 측이 승리
웹 2.0의 흐름 속에서 구글과 아마존 같은 기업들은 REST 형식의 웹 API를 제공하기 시작하였다. 웹 2.0에서 중요했던 것은 매쉬업(Mashup)입니다. 매쉬업이란, 여러 가지 웹 API가 제공하는 정보를 조합하여 하나의 애플리케이션을 실현하는 방법을 말한다. 매쉬업에서는 가벼움이 요구되었기 때문에, 웹 API가 제공하는 리소스를 HTTP와 URI로 간단히 조작할 수 있는 REST 스타일 쪽이 받아들여졌던 것이다.
SOAP와 WS-가 실패한 이유
- 첫째는 기술적인 이유
- SOAP와 WS-는 RPC/분산 오브젝트가 가지고 있던 기술적인 문제점을 그대로 가지고 있는데다 스펙들마저 복잡해져 버렸습니다.
- 예를 들어 벤더 간 인터페이스 호환성의 결여, 복잡한 프로토콜 스택, 네트워크를 통한 인터페이스 호출에 의한 오버헤드 등입니다.
- 둘째는 정치적인 이유
- SOAP와 WS-의 표준화 작업은 W3C와 OASIS에서 수행했습니다. 여기서의 표준화 작업은 각 벤더가 드래프트를 가지고 오면, 그 차이를 조정하는 식으로 이루어졌습니다. 하지만 많은 벤더들이 SOAP 자체도 표준으로 확정되기도 전에 구현을 추진했기 때문에 동일한 SOAP와 WS-라도 해석에 차이가 생겼고, 호환성이 결여되었습니다.
- SOAP와 WS-의 표준화 작업은 W3C와 OASIS에서 수행했습니다. 여기서의 표준화 작업은 각 벤더가 드래프트를 가지고 오면, 그 차이를 조정하는 식으로 이루어졌습니다. 하지만 많은 벤더들이 SOAP 자체도 표준으로 확정되기도 전에 구현을 추진했기 때문에 동일한 SOAP와 WS-라도 해석에 차이가 생겼고, 호환성이 결여되었습니다.
👨🏻💻 모든 것이 웹으로
현재 우리들이 이용하고 있는 소프트웨어의 많은 부분이 웹을 전제로 하고 있다. 모든 소프트웨어와 데이터들이 계속해서 웹으로 구현되면서 웹의 중요성은 날로 커지고 있다.
