웹의 역사를 통해 기술들이 성립해온 과정을 살펴보고, 웹이 지닌 역사적 배경을 하이퍼 미디어, 분산 시스템 두 가지 측면에서 접근해본다.
00 웹 이전의 인터넷
초기의 인터넷엔 웹이 없었다. 간단한 인터넷의 역사를 살펴보자면 1969년에 구축된 ARPANET까지 거슬러 올라간다. ARPANET은 미국 내 대학과 연구기관 사이를 고속 회선으로 접속하고, 전 미국을 연결하는 네트워크로서 성장해갔다.
웹 이전의 인터넷 환경에서의 네트워크는 리얼 타임으로 상대와 통신하는 TCP/IP 뿐 아니라 패킷 릴레이 방식의 UCCP(Unix to Unix Copy Protocol)에 의한 전송도 존재했기 때문에 메일이 도달하기까지 지연이 있었다.
인터넷 어플리케이션은 전자메일 이외에도 많이 생겼다. 여러 사람들이 참여할 수 있는 포럼 형식의 넷 뉴스, 파일교환을 위한 FTP(File Transfer Protocol), UNIX 호스트에 원격접속하기 위한 Telnet, 콘텐츠를 간단히 공개하는 Gopher등이 있었다.
01 웹 이전의 하이퍼 미디어
하이퍼 미디어는 50이 넘는 역사를 가진 오래된 기술이다. 웹이 등장하기 전에는 어떤 역사를 가지고 있었는지, 그리고 문제점은 무엇이었는지 살펴보자.
Memex - 하이퍼 미디어의 기원
하이퍼 미디어의 기원은 1945년 미국의 Vannevar Bush가 발표한 Memex라는 정보 검색 시스템에 대한 논문이다. Memex는 실재하는 시스템이 아닌 구상이었지만, 전기적으로 접속한 책과 파일을 서로 링크하고 링크를 따라 차례로 표시하는 현재의 웹을 예상할 수 있는 시스템이었다. 이는 많은 연구자들에게 영향을 끼쳤다.
Xanadu - 하이퍼 미디어라는 단어의 탄생
부시의 Memex 구상에 영향을 받은 Ted Nelson은 1965년에 하이퍼텍스트와 하이퍼미디어를 잇달아 고안했다. 하이퍼 텍스트에 더해 사고를 확장하여 음성과 동영상 등 다양한 미디어를 상호 링크시킨 개념이다.
넬슨은 이상적인 하이퍼미디어 Xanadu를 구상하고 개발하기 시작했지만 고기능으로 인한 복잡성으로 실패하고 말았다.
HyperCard - 최초의 실용적인 하이퍼미디어
웹 이전에 성공을 거둔 하이퍼미디어는 Bill Atkinson이 1987년에 Apple에서 개발한 HyperCard가 있다. 네트워크를 통해 데이터를 주고받는 긴으 조차 없었지만, 카드라고 불리는 문서를 단위로 상호 링크하고, 스크립트 언어 HyperTalk에 의해 프로그램을 실행할 수 있는 Stand-alone 방식의 웹 서비스였다. 이후 많은 게임과 어플리케이션들이 개발되었다.
웹 이전의 하이퍼 미디어의 문제점
지금까지 가장 많이 보급된 하이퍼미디어의 구현은 웹이다. 웹상의 문서는 전부 링크에 의해 연결되어 있다. 때문에 링크는 웹의 필수불가결한 기본 기술이다. 다만, 넬슨 등 예전의 하이퍼미디어 추진자들의 시각으로 볼 때, 웹은 불완전한 하이퍼미디어로 비춰질 것이다. 그 이유는 그 당시 웹이 단방향 링크밖에 지원하지 않고 있고, 링크가 끊어질 가능성이 있으며, 버전 관리와 트랜스클루전 기능이 없는 점 때문이었다.
하지만, 현실에서는 그 보급율로 볼 때 웹이 가장 성공한 하이퍼 미디어라는 점에 의심할 여지가 없다. 웹의 성공을 가져온 원인은 최소한의 링크 기능만을 갖추고 있었다는 점이다. 반대로 웹 이전의 하이퍼 미디어의 문제점은 그 복잡성에 있다고 말할 수 있다.
02 웹 이전의 분산 시스템
분산 시스템도 웹이 등장하기 전부터 있던 기술이다. 그 역사와 문제점은 웹의 설계에 영향을 주고 있는데 분산시스템의 역사를 돌아보며 기술적인 문제점을 짚어보자
중앙 집중형 시스템과 분산 시스템
가장 최초의 컴퓨터는 과학기술계산 등의 전용 목적으로 만들어졌고, 그러던 것이 1960년대에 메인 프레임이 개발되며 한 대의 컴퓨터를 여러 목적으로 이용할 수 있게 되었다. 이 당시 컴퓨터의 이용 형태는 단말기로 호스트 컴퓨터에 접속하여 호스트 컴퓨터에서 집중하여 처리하는 방식이었다.
1970년대 이후, 컴퓨터의 다운사징이 진행되며 컴퓨터의 크기는 소형화되고 성능은 향상됨에 따라서 복수의 컴퓨터를 조합하여 처리를 분산시켜 전체적인 성능을 향상시킬 수 있는 방법들이 등장했다.
RPC - 다른 컴퓨터의 기능 이용하기
분산 시스템을 실현하기 위해선 각 서버가 제공하는 기능을 다른 서버와 클라이언트에서 호출 할 수 있어야 한다. RPC(remote Procedure Call)는 분산 시스템을 실현하기 위한 기술 중 하나이고 RPC를 이용하면 원격 서버에서 실행하고 있는 프로그램을 클라이언트 쪽에서 호출할 수 있다. (예: Sun Microsystems의 SunRPC, 아폴로, IBM과 DEC가 공동개발한 DCE)
RPC 개발이 진행되던 1980년대 후반은 'UNIX WAR'라고 불리는 UNIX 벤더에 의한 표준화 경쟁이 치열하던 시대, 모두 자사의 분산 시스템 기술을 표준을 삼기 위해 열심히였었다.
CORBA, DCOM - 분산 오브젝트로의 진화
RPC는 이름 그대로 리모트 프로시저, 즉 함수를 호출하느 구조이다. 다만 현대적인 프로그래밍 언어들은 모두 객체지향적 기능을 갖추고 있다. 그래서 단순한 함수 호출이 아니라, 오브젝트 자체를 원격으로 배치하는 '분산 오브젝트'라고 불리는 기술이 고안되었다.
그 대표적인 예가 CORBA(Comman Object Request Broker Architecture)이다. Microsoft는 CORBA에 대항하여 DCOM(Distributed Component Object Model)을 개발하였다.
CORBA와 DCOM은 IDL(Interface Definition Language)로 오브젝트의 메서드를 정의하고, 구현은 네트워크를 경유해 시리얼라이즈 된 메세지를 교환하는 점이 RPC와 동일하다.
단, 범용적인 오브젝트 기능을 실현하려고 했기 때문에 매우 복잡한 스펙을 가지게 되었다. 또한 서로의 호환성이 없다는 문제도 있었다.
웹 이전의 분산 시스템의 문제점
RPC는 지금도 NFS(Networ File System) 같은 분산 시스템을 구현하는데 사용되고 있다. 하지만 RPC가 현실적으로 동작하는 것은 통신 상대가 어느정도 정해져 있는 인트라넷 정도의 환경까지로 좀 더 복잡한 이기종 분산환경으로는 확장되지 않는다.
이유는 다음과 같다
- 성능열화의 문제
- 네트워크를 경유한 함수의 호출은 동일 프로세스 내에서 함수를 호출하는데 에비해 몇 배의 시간이 걸린다. 일반적으로 함수의 입도가 작아 목적을 달성하기 위해선 여러번 호출하여야 하고, 네트워크의 오버헤드가 호출하는 회수만큼 걸리게 된다.
- 데이터형 변환의 문제
- 프로그래밍 언어마다 지원하는 데이터형이 다르므로 복수의 언어가 혼재하는 환경에서는 데이터형 변환 시 문제가 발생한다.
- 부하 분산의 문제
- 일반적으로 RPC 기반의 시스템은 서버 상에 클라이언트의 어플리케이션 상태를 가지고 있다. 그렇기 때문에 서버끼리 상태를 공유하지 않으면 안 되고, 다수의 서버에 부하를 분산하는 것이 어려워진다.
위에서 다룬 내용 때문에 웹 이전의 분산 시스템은 하드웨어든 소프트웨어든 한정된 수로 균일한 클라이언트를 전제로 하게 되었다. 이런 방식으로는 전 세계적인 규모로 동작하는 시스템이 될 수 없기 때문에, 대규모 분산 시스템에 필요한 것은 무엇인지, 그에 대한 답은 웹에 의해 명확해지게 된다.
03 웹의 탄생
지금까지 1980년대 까지 하이퍼 미디어에 대한 구상이 생겨나고, 인터넷이 등장하면서 복수의 컴퓨터를 연결한 분산 시스템이 구축되는 과정을 알아보았다. 웹은 이런 시대적 환경에 의해 탄생했다.
1990년 11월 12일 스위스의 CERN(Europe Organizationfor Nuclear Research)이라는 국제 연구소에서 근무하던 팀 버너스리가 하이퍼 미디어를 이용한 인터넷 기반의 '분산정보관리 시스템'이라는 웹 제안서를 썼다. 버너스-리가 최초 버전을 발표한 이래로, 웹은 전 세계로 서서히 보급되기 시작하였고, 당시의 인터넷은 주로 기업과 대학 연구소가 이용하고 있었는데, 그들은 점차 무상으로 공개된 서버와 브라우저를 시험삼아 사용하게 되었고, 콘텐츠를 공개하기 시작했다.
웹의 보급을 단번에 앞당긴 것은 1993년 일리노이 대학의 NCSA(National Center for Supercomputing Application)가 공개한 브라우저 Mosaic이다. 그전까진 문자정보밖에 다루지 못했는데, Mosaic은 본문에 인라인으로 이미지를 혼재시킬 수 있었다.
Mosaic은 Internet Explore와 Firefox 같은 현재의 브라우저의 원류가 되었다.
하이퍼 미디어로서의 웹
웹은 인터넷을 이용한 하이퍼미디어로서 설계되었다. 이는 웹 이전의 하이퍼미디어와 가장 큰 차이점이다. 인터넷을 이용하기 때문에 불특정 다수의 정보를 서로 링크시키고, 시스템을 대규모화하기 쉽다는 중요한 이점을 가지고 있었다. 반면, 정보의 집중적인 관리가 어려워지고 링크가 끊어지기 쉽다는 결점도 가지고 있다.
웹이 구현하고 있는 링크는 심플한 단방향 링크 뿐이라는 점도 특징이다. 원래 링크의 개념은 외부에서 링크를 지정하는 확장 링크의 개념도 존재했는데, 웹에 복잡한 링크 구조를 도입하려는 시도도 있었지만 결국은 심플한 단방향 링크만 사용 되고 있다.
사용자에게 있어서 이해하기 쉽고 구현이 간단한 링크였기 때문에 웹이 지금에 이르기까지 보급되고 있다고 할 수 있다.
분산 시스템으로서의 웹
RPC는 폐쇄 네트워크 환경에서 미리 정해놓은 숫자와 종류의 클라이언트를 상대로 서비스를 제공하는 시스템으로는 뛰어나다. 반대로 개방된 네트워크 환경에서 불특정 다수의 클라이언트에 대해 서비스를 제공하는 시스템으로는 어울리지 않는다.
개방형이고 불특정 다수를 상대로 하는 시스템이 바로 '웹'이다. 각 유저의 컴퓨터 환경은 OS와 하드웨어가 특정되지 않아도 사용할 수 있고, 다양한 브라우저와 디바이스를 통해 하나의 웹 서비스에 접근할 수 있다. 이것이 가능한 이유는 HTTP라는 심플한 프로토콜로 서버 간의 인터페이스를 고정하여 실현되어 있기 때문이다.
04 웹의 표준화
Mosaic에 의해 폭발적으로 보근된 웹에는 다양한 플레이어가 추가되었다. 학술적인 콘텐츠를 넘어 뉴스와 오락미디어, 쇼핑 등 Microsoft와 IBM, Sun Microsystems 등 대기업들의 가세 등이 1990년대 중후반에 걸쳐 동시다발적으로 일어났다.
웹의 스펙 책정
이런 상황 속에서 웹을 구성하는 기술, 특히 HTTP와 URI와 HTML에 대한 표준화가 요구되었다. 각 회사의 서버, 클라이언트 사이에서 이요되어야 하고 상호 운용성이 요구 되었기 때문이다.
웹 이전의 인터넷 표준은 모두 IETF(Internet Engineering Task Force)의 RFC(Request for Comments)로 정해왔다. 실제로 HTTP, URI, 그리고 버전2 까지의 HTML은 RFC로 정의되어 있다.
그러나 웹이 너무 급속하게 보급되어 버려서 IETF에서의 스펙 책정이 따라가질 못하고, 각 기업의 구현은 제각각이라 호환성이 결여되는 상태가 발생했다. 이러한 문제를 해결하기 위해 웹 기술을 구현하고 있는 벤더들이 모여 표준화를 수행하는 단체로서, 1994년에 버너스-리가 중심이 되어 W3C(World Wide Web Consortium)를 설립하게 된다.
W3C에서는 HTML, XML, HTTP, URI, CSS 등의 표준화 작업이 이루어졌고, 특히 HTML과 CSS의 표준화는 중요했다. 당시 상황을 브라우저 전쟁이라고 부르기도 하는데 Netscape Navigator와 Internet Exploere가 독자적인 확장을 반복한 끝에 양쪽 진영의 HTML과 CSS의 렌더링 결과가 크게 차이가 나게 되었기 때문이다. 그렇기에 개발자들은 브라우저 별로 대응해야만 하는 사태에 이르게 되었다. 이런 상황은 오랜 시간이 지나며 해결되어 왔지만 현재에도 문제는 남아있다.
버너스-리는 웹의 콘셉트를 발명하고, 최초의 브라우저와 서버를 구현했다. 하지만 웹이 지금까지 확장성을 가지고 동작하고 있는 것은 각종 서버와 브라우저를 구현한 경험과 HTTP나 URI의 스펙이 책정되는 과정에서 서서히 설계적으로 올바른 서택이 이어져온 결과이다.
REST 탄생
당시 캘리포니아 얼바인 대학교의 학원생이었던 Roy Fielding은 웹이 생겨난 초기 때부터 각종 소프트웨어의 구현에 관여하였다. (Apache httpd & libwww-perl, www-stat 등) 필딩은 구현 경험을 바탕으로 버너스-리 그룹과 함께 HTTP 1.0, 1.1 스펙을 제정하는데 관여했다. HTTP의 스펙을 책정하는 시기에 필딩은 자신의 연구과제로 웹이 왜 이렇게 대성공 했는지, 왜 이 정도의 댁모 시스템이 성립된 것인지에 대해 소프트웨어 아키텍처의 관점에서 분석하고, 하나의 아키텍처 스타일로 정리하였다. 2000년, 그는 이 아키텍처 스타일을 REST(Representation State Transfer)라 이름을 붙이고, 박사학위 논문으로 제출하였다.
REST라는 이름은 컴퓨터 관계에서 자주 있는 억지스런 명명법이지만 아마 HTTP가 Hypertext Transfer Protocol의 약자라는 점에서 힌트를 얻은 것이다. 즉 HTTP는 원래 하이퍼 텍스트를 전송하기 위해 만들어진 프로토콜이지만 실제로는 하이퍼텍스트 이외의 다양한 것들을 전송하고 있었다. 그것이 무엇인가 하면 '리소스 상태'의 표현이라는 것이 필딩의 주장이다.
다양한 하이퍼미디어 포맷의 탄생
초기 웹에서는 HTML이 유일한 하이퍼 미디어 포맷이었다. 하지만 웹이 보급되며 HTML 만으로는 대응할 수 없는 다양한 요구가 생겨났고 새로운 하이퍼 미디어 포맷들이 탄생하였다.
예를 들면 HTML 구조는 그대로 유지한채 다양한 의미를 가지게 할 수 있는 기술로 microformats이 등장했다.
또한 웹페이지의 새로운 정보를 서버에 발송하고, 전용 프로그램으로 체그하기 위한 용도로 RSS(RDF Site Summary, Rich Site Summary, Really Simple Syndication)가 제안 되었다. 하지만 복수 버전이 난립하여 혼란스러웠기 때문에 IETF에서 Atom이 표준화 되었다.
HTML과 Atom은 XML을 베이스로 한 구조화 문서용 마크업 언어이기 때문에 데이터를 기술하기 위한 표기가 너무 중복되었는데, 이를 좀 더 단순한 데이터로 표현하기 위해 포맷이 몇 가지 제안되었고 그 중에서도 디팩토스탠다드가 된것이 JSON이다.
05 웹 API를 둘러싼 논의
초기의 웹은 학술을 위한 시스템이었다. 그러나 웹의 용도가 다양화 되며, 프로그램을 이용해 자동화 처리를 하고자 하는 요구가 생겨나기 시작했다. 1990년대 후반부터 2000년대 전반에 걸쳐 프로그램으로 조작이 가능한 웹 API에 대한 논의가 일어났다.
SOAP과 WS-
1990년대 후반, 웹은 성공을 거두고 버블을 맞는다. 무엇이 되었든 웹 기술을 이요하는 것이 트렌드가 되었다. HTTP 1.1을 책정한 필딩 그룹과 별개로 다양한 배경을 가진 그룹들이 웹을 프로그램에서 이용할 수 있도록 하기 위해 확장을 시도했다.
그 중에서 큰 세력을 가지고 있던 것이 RPC/분산 오브젝트 그룹이다. 그들은 과거에 CORBA와 DCOM과 같은 분산 오브젝트로 자사의 기술을 디팩토 스탠다드로 만들기 위해 표준화 경쟁을 벌인적이 있었다.
이들의 움직임 중에서 가장 기본적인 프로토콜은 SOAP이다. SOAP는 HTTP를 애플리케이션 프로토콜이 아닌 트랜스포트 프로토콜로 다루고, HTTP 상에서 독자적으로 메세지를 전송한다. SOAP은 Microsoft가 W3C에 제안하였고, IBM과 그 밖의 벤더를 끌어들여 표준화가 시작되었다.
SOAP은 메세지 전송 방법만을 규정한 스펙이기 때문에 실제로 시스템 구축시에는 SOAP상의 서비스 별로 프로토콜을 정의하지않으면 안되었다. 이것들을 각 벤더마다 제각기 정의하게 된다면 전과 같은 전철을 밟는 셈이었기 때문에 WS-Security, WS-Transaction, WS-ReliableMessaging등 'WS-' 라고 불리는 주변 스펙들이 W3C와 OASIS에 제안 되었다. 하지만 여러 비슷한 스펙이 여러 개가 난립했기 때문에 결국 이전과 마찬가지의 표준화 경쟁을 일으켰다.
SOAP vs REST
이런 혼돈의 도가니 속에서 W3C에서는 프로그램에서도 이용 가능한 웹의 아키텍처에 대해 활발히 논의되고 있었다. 이 논쟁에는 필딩도 적극 관여하여 REST의 이론을 바탕으로 대기업들이 추진하는 SOAP 기반의 기술을 부정하고, 웹이 웹 다울 수 있는 아키텍처로서 REST를 권장했다.
하지만 대기업의 힘은 한 사람의 연구자보다 훨씬 강했고, 필딩이 아무리 잘못된 점을 주장하여도 SOAP 스펙의 책정 작업이 W3C에서 계속 진행되었다. 그러다 분산 오브젝트 기술에 관여 하던 Mark Baker와 SGML의 계보를 이어받은 XML/구조화 엔지니어인 Paul Prescod가 필딩의 의견을 지지하였고, 기술적 배경이 다른 두사람이 웹을 통해 REST를 만났고, 다양한 미디어를 통해 함께 REST를 선전했다.
REST의 오해와 보급
SOAP와 REST에 대한 논쟁은 2000년대 전후부터 시작되어 2003년 정도가 정점이었다. 그 당시에는 현재와 같은 프로그램으로 조작이 가능한 각종 웹 API는 존재하지 않았었다.
REST의 보급이 탄력을 받기 시작한 것은 2002년에 등장한 Amazon 웹 서비스이다. Amazon은 자신들이 취급하는 서적과 상품들의 정보를 웹을 통해 취급할 수 있도록 하였다. 그때 Amazon은 SOAP를 이용한 형식과 특정 URI와 HTTP로 GET하는 형식의 2가지 방식을 준비했다. (기술적으로 정확한 것은 아니지만 후자를 편의상 REST로 칭함)
Amazon의 웹 API는 그 정보의 유용성과 편리한 사용방법에 힘입어 순식간에 보급되었다. 그리고 SOAP와 REST의 이용 비율이 20 : 80 이라 보고 되자 SOAP 와 REST의 논쟁에 불이 붙었다.
REST를 반대하는 사람들은 "Amazon 처럼 보안이 필요 없는 간단한 웹 API에서는 URI를 GET 하기만 하는 단순한 방식이 이용될 수 있지만 기간 시스템과 같은 트랜잭션과 신뢰성이 필요한 곳에는 REST 기능이 불충분하다"라는 주장을 냈다.
결과적으로 REST측이 승리하게 되었고, 2004년 부터 시작된 웹2.0의 흐름속에서 Google과 Amazon 같은 기업들은 REST 형식의 웹 API를 제공하기 시작했다. 웹 2.0에서 중요했던 것은 Mashup인데 이는 여러 가지 웹 API가 제공하는 정보를 조합하여 하나의 application을 실현하는 방법이다. 이를 위해 가벼움이 요구되었기 때문에 웹 API가 제공하는 리소스를 HTTP와 URI로 간단히 조작할 수 있는 REST 스타일 쪽이 받아들여졌던 것이다.
SOAP와 WS-의 패인
그렇다면 SOAP과 WS-는 왜 패하게 되었는가 ?
- 첫 째는 기술적인 이유이다. SOAP과 WS-는 RPC/분산 오브젝트가 가지고 있던 기술적인 문제점을 그대로 가지고 있었고 스펙들 마자 복잡해졌다. 예를 들면 벤더 간 인터페이스 호환성의 결여와 복잡한 프로토콜 스택, 네트워크를 통한 인터페이스 호출에 발생하는 오버헤드 등이 있다.
- 둘 째는 정치적인 이유이다. SOAP과 WS-의 표준화 작업은 W3C와 OASIS에서 수행했는데, 여기서의 표준화 작업은 각 벤더가 드래프트를 가지고 오면 그 차이를 조정하는 식으로 이루어졌다. 하지만 많은 벤더들이 SOAP 자체도 표준으로 확정되기 전에 구현을 추진했기 때문에 동일한 SOAP와 WS-라고 하여도 해석에 차이가 생겼고 호환성이 결여될 수 밖에 없었다.
모든것은 웹으로
REST가 보급되며 웹은 인터넷을 통째로 집어 삼키기 시작했다. 그때까지 백엔드에서 동작하고 있는 프로토콜은 변화하지 않았지만, 적어도 유저 인터페이스는 웹으로 통일되기 시작했고 엔드 유저는 웹만을 인시갛게 되었다.
이런 배경에는 Ajax와 Comet 등의 기술적 돌파구가 있었다. 이 기술들에 의해서 그전까지 있을 수 없었던 UI와 편의성이 웹의 장점과 맞물려 계속 실현되었다.
이와 같이 현재 우리들이 이용하고 있는 소프트웨어의 많은 부분이 웹을 전제로 하고 있다. 모든 소프트웨와와 데이터들이 계속해서 웹으로 구현되며 웹의 중요성은 날로 커지고 있다.
