[웹을 지탱하는 기술] chapter 02. 웹의 역사

 

[목차]
chapter 01. 웹이란 무엇인가?
chapter 02. 웹의 역사

 

01 웹 이전의 인터넷

인터넷의 기원은 1969년에 구축된 ARPANET(Advanced Research Project Agency가 구축한 네트워크)까지 거슬러 올라간다. ARPANET은 미국 내 대학과 연구기관 사이를 고속 회선으로 접속하고, 전 미국을 연결하는 네트워크로서 서서히 성장해갔음

웹 이전의 인터넷 환경은 1998년 프로그래밍 언어 C의 저자 브라이언 커니핸이 번역자 이시다 교수 앞으로 보낸 전자메일에서 엿볼 수 있다.

• 메일의 서식은 현재와 동일하지만 내용은 일본어임에도 모든 문자가 영문자와 숫자로 되어 있음
• 당시의 네트워크는 리얼 타임으로 상대와 통신하는 TCP/IP뿐만 아니라, 패킷 릴레이 방식의 UUCP에 의한 전송도 존재했었기 때문에 메일이 도달하기까지 지연이 있었음

 

02 웹 이전의 하이퍼미디어

Memex - 하이퍼미디어의 기원

• 하이퍼미디어의 기원은 1945년 미국의 연구자 버니바 부시가 발표한 ‘Memex’라는 정보 검색 시스템에 대한 논문
• Memex는 실재하는 시스템이 아닌 구상
• 전기적으로 접속한 책과 파일을 서로 링크하고 링크를 따라서 차례로 표시하는 현재의 웹을 예상할 수 있는 시스템
• 하이퍼미디어라는 단어조차 등장하지 않았지만 많은 연구자들에게 영향을 끼침

Xanadu - 하이퍼미디어라는 단어의 탄생

• 1965년 Memex 구상에 영향을 받은 테드 넬슨이라는 연구자가 하이퍼텍스트와 하이퍼미디어라는 말을 고안
• 하이퍼텍스트 - 문자 정보 중심의 문서를 상호 링크시키는 개념
• 하이퍼미디어 - 하이퍼텍스트를 확장하여 음성과 동영상 등 다양한 미디어를 상호 링크시킨 개념
• 넬슨은 현재의 웹을 더욱 진화시킨 기능을 가진 이상적인 하이퍼미디어 Xanadu를 구상하고 개발
• 고기능으로 인한 복잡성으로 실패

HyperCard - 최초의 실용적인 하이퍼미디어

• HyperCard는 웹 이전에 성공을 거둔 하이퍼미디어
• Bill Atkinson이 1987년에 Apple에서 개발
• 네트워크를 통해 데이터를 주고받는 기능은 없었음.
• ‘카드'라고 불리는 문서를 단위로 상호 링크하고, 스크립트 언어 HyperTalk에 의한 프로그램을 실행할 수 있는 Stand-alone 방식의 웹 서비스
• 성공. 많은 게임과 애플리케이션들 개발

웹 이전의 하이퍼미디어의 문제점

• 지금까지 가장 많이 보급된 하이퍼미디어의 구현은 웹. 웹상의 문서(리소스)는 모두 링크에 의해 서로 연결되어 있음.
• 다만, 넬슨 등 예전의 하이퍼미디어 추진자들의 시각으로는, 웹은 불완전한 하이퍼미디어로 비춰짐
  • 웹이 단방향 링크 밖에 지원하고 있지 않고, 링크가 끊어질 가능성이 있으며, 버전 관리와 트랜스클루전 기능이 없는 것 등이 이유
• 하지만 현실에서는 보급율로 보면 웹이 가장 성공한 하이퍼미디어라는 점
  • 웹의 성공을 가져온 원인은 최소한의 링크 기능만을 갖추고 있었다는 점
  • 반대로 웹 이전의 하이퍼미디어의 최대 문제점은 그 복잡성에 있었음.

 

03 웹 이전의 분산 시스템

분산 시스템도 웹이 등장하기 이전부터 있던 기술이다. 분산 시스템의 역사를 돌아보면서 기술적인 문제점을 짚어본다.

중앙 집중형 시스템과 분산 시스템

• 최초의 컴퓨터는 과학기술계산 등의 전용 목적으로 만들어짐
• 1960년대에 메인 프레임이 개발되면서 한 대의 컴퓨터를 여러 목적으로 이용
  • 이 당시 컴퓨터의 이용 형태는 단말기로 호스트 컴퓨터에 접속하여 호스트 컴퓨터에서 집중해서 처리하는 방식
• 1970년대 이후, 컴퓨터의 다운사이징이 진행되면서 컴퓨터들이 소형화되고, 성능은 향상됨. → 복수의 컴퓨터를 조합하여 처리를 분산시킴으로써 전체적인 성능을 향상시키는 방법들이 등장

RPC - 다른 컴퓨터의 기능을 이용하기

분산 시스템을 실현하기 위해서는 각 서버가 제공하는 기능을 다른 서버와 클라이언트에서 호출할 수 있어야 한다. RPC(Remote Procedure Call)는 분산 시스템을 실현하기 위한 기술 중 하나다. RPC를 이용하면 원격 서버에서 실행하고 있는 프로그램을 클라이언트 쪽에서 호출할 수 있다.

RPC 시스템이 개발되는 1980년대 후반은 ‘UNIX 전쟁'이라고 불리는 UNIX 벤더에 의한 표준화 경쟁(자사의 분산 시스템 기술을 표준으로 하기 위한 경쟁)이 치열한 시대였음.

CORBA, DCOM - 분산 오브젝트로의 진화

RPC는 이름 그대로 함수를 호출하는 구조지만, 현대적인 프로그래밍 언어들은 거의 모두가 객체지향 기능을 갖추고 있음

→ 단순한 함수 호출이 아니라 오브젝트 자체를 원격으로 배치하는 ‘분산 오브젝트(Distributed Object)’라고 불리는 기술이 고안되었음.

대표적인 예

• CORBA(Common Object Broker Architecture)
• Microsoft의 DCOM(DistriburedComponent Object Model)

IDL(Interface Definition Language)로 오브젝트의 메서드를 정의하고, 구현은 네트워크를 경유해 시리얼라이즈 된 메시지를 교환하는 점이 RPC와 동일함.

단, 범용적인 오브젝트 기능을 실현하고자 하였기 때문에 매우 복잡한 스펙을 가지게 되었음.

또한, CORBA와 DCOM은 호환성이 없어서 서로의 시스템에 접속 할 수 없다는 문제점도 존재

웹 이전의 분산 시스템의 문제점

• 성능열화의 문제
  • 네트워크를 경유한 함수의 호출은 동일 프로세스 내에서 함수를 호출하는 데 비해 몇 배나 시간이 걸림
  • 일반적으로 함수의 입도가 작아 목적을 달성하기 위해선 여러 번 호출하지 않으면 안됨
  • 네트워크의 오버헤드가 호출하는 횟수만큼 걸림
• 데이터형 변환의 문제
  • 프로그래밍 언어마다 지원하는 데이터형이 다르기 때문에 복수의 언어가 혼재하는 환경에서 데이터형 변환시 문제 발생
• 인터페이스 버전업 시 호환성 문제
  • 기능을 추가하면서 서버의 인터페이스가 변경된 경우, 구 클라이언트에 대해 하위 호환성을 가질 수 없음
• 부하 분산의 문제
  • RPC 기반의 시스템은 서버 상에 클라이언트의 애플리케이션 상태를 가진다. 그렇기 때문에 서버끼리 애플리케이션 상태를 공유하지 않으면 안되며, 다수의 서버에서 부하를 분산하는 것이 어려워진다.

이렇게 웹 이전의 분산 시스템은 하드웨어든 소프트웨어든 한정된 수로 균일한 클라이언트를 전제로 했음. 이런 방식으로는 전 세계적인 규모로 동작하는 시스템이 될 수 없었음.

 

04 웹의 탄생

앞서 살펴본 것처럼 웹은 하이퍼미디어에 대한 구상, 복수의 컴퓨터를 연결한 분산 시스템이 구축되어가는 시대적 환경에 의해 탄생했다.

1990년 11월 12일 팀 버너스-리가 하이퍼미디어를 이용한 인터넷 기반의 ‘분산정보관리 시스템’이라는 웹 제안서를 썼다. 버너스-리는 다음 날부터 구현하기 시작해, 그해 크리스마스 휴가에 첫 버전의 서버와 브라우저를 완성시켰음.

버너스-리가 최초 버전을 발표한 이래로, 웹은 전 세계로 서서히 보급되기 시작함. 당시의 인터넷은 주로 기업과 대학 연구소가 이용하고 있었는데, 그들은 점차 무상으로 공개된 서버와 브라우저를 시험 삼아 사용하게 되었고 콘텐츠를 공개하기 시작함.

하이퍼미디어로서의 웹

웹은 인터넷을 이용한 하이퍼미디어로서 설계되었음. 웹 이전의 하이퍼미디어와 가장 큰 차이점이라고 할 수 있음.

인터넷을 이용하기 때문에 불특정 다수의 정보를 서로 링크시킬 수 있고, 시스템을 대규모화하기 쉽다는 이점을 가짐.

반면, 정보의 집중적인 관리가 어려워지고 링크가 끊어지기 쉽다는 결점이 있음

웹이 구현하고 있는 링크는 심플한 단방향 링크뿐. 사용자에게 있어서 이해하기 쉽고 구현이 간단하기 때문에 웹의 보급력에 날개를 달아줌

분산 시스템으로서의 웹

RPC는 폐쇄된 네트웨크 환경에서 미리 상정한 숫자와 종류의 클라이언트를 상대로 서비스를 제공하는 시스템으로는 뛰어남. 개방된 네트워크 환경에서 불특정 다수의 클라이언트에 대해 서비스를 제공하는 시스템으로는 어울리지 않음. → 개방형이고 불특정 다수를 상대로 하는 시스템이 웹.

각 유저의 컴퓨터 환경은 특정한 OS와 하드웨어로 통일되어 있지 않으며, 다양한 브라우저와 디바이스를 통해 하나의 웹 서비스에 접근할 수 있다. 클라이언트와 서버 간의 인터페이스를 HTTP라는 심플한 프로토콜로 고정함으로써 실현되어 있음.

 

05 웹의 표준화

웹은 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, CSS등의 표준화 작업이 이뤄짐. 특히 HTML과 CSS는 Netscape Navigator와 Internet Explorer의 독자적인 확장으로, 개발자들은 브라우저 별로 대응해야하는 사태가 발생했기 때문에 표준화는 중요했음.

버너스-리가 웹의 기초를 모두 쌓아올렸다고 보기는 어렵다. 하지만, 웹이 여기까지 확장성을 가지고 동작하고 있는 것은 실제로는 각종 서버와 브라우저를 구현한 경험과 HTTP나 URI의 스펙이 책정되는 과정에서 서서히 설계적으로 올바른 선택이 이어져온 결과.

REST 탄생

웹의 아키텍처를 결정한 중요한 다른 인물로는 **로이 필딩(Roy Fielding)**이 있다.

로이 필딩은 웹의 창세기부터 각종 소프트웨어 구현에 관여해왔다. (Apache httpd & libwww-perl, www-stat 등)

로이 필딩은 이 구현 경험을 바탕으로 버너스-리 그룹과 함께 HTTP 1.0과 HTTP 1.1의 스펙을 제정하는데 관여했다. HTTP 스펙을 책정하는 시기에 대학원생이었기 때문에 연구과제로 웹이 왜 이렇게 성공했는지, 왜 이 정도의 대규모 시스템이 성립된 것인지에 대해 소프트웨어 아키텍처 관점에서 분석하고, 하나의 아키텍처 스타일로 정리했다. 2000년 그는 이 아키텍처 스타일을 ‘REST(Representational State Transfer)’라 이름붙이고, 박사학위 논문으로 제출함.

REST라는 이름은 HTTP가 Hypertext Transfer Protocol의 약자라는 점에서 힌트를 얻음. HTTP는 원래 하이퍼텍스트를 전송하기 위한 프로토콜이지만, 실제로는 하이퍼텍스트 이외의 다양한 것들을 전송하고 있음. 그것이 ‘리소스 상태(Resourse State)’의 ‘표현(Representation)’이라는 것이 필딩의 주장이다.

다양한 하이퍼미디어 포맷의 탄생

초기 웹에서는 HTML이 유일한 하이퍼미디어 포맷이었음. 하지만, 웹이 보급됨에 따라 다양한 요구에 따른 새로운 하이퍼미디어 포맷들이 탄생함.

• microformats - HTML 구조는 유지한 채, 다양한 의미를 가지게 할 수 있는 기술
• RSS(Really Simple Syndication, Rich Site Summary) - 웹페이지의 새로운 정보를 서버에 발송하고, 전용 프로그램으로 그것을 체크하기 위한 기술. 복수의 버전이 가져오는 혼란으로 인해 최종적으로는 IETF에서 Atom이 표준화되었음.
• HTML과 Atom은 XML을 베이스로 한 구조화 문서용 마크업 언어이기 때문에 데이터를 기술하기 위한 표기가 너무 중복되었음. 단순한 데이터 포맷이 몇 가지 제안되었고, 그중 사실상 표준이 된 것이 JSON임.

 

06 웹 API를 둘러싼 논의

문서를 읽기 위한 시스템이었던 초기의 웹이 용도가 다양화되면서, 프로그램을 이용해 자동화 처리를 하고자 하는 요구가 생겨나기 시작함. 1990년대 후반부터 2000년대 전반에 걸쳐서 프로그램으로 조작이 가능한 웹 API에 대한 논의가 일어났음

SOAP과 WS-

1999년대 후반 웹 기술을 사용하는 것이 트렌드가 됨. HTTP 1.1을 책정하는 필딩의 그룹과는 별개로, 다양한 배경을 가진 그룹들이 웹을 프로그램에서 이용할 수 있도록 하기 위해 확장을 시도함.

그 중 큰 세력이 RPC/분산 오브젝트 그룹. 과거에 CORBA와 DCOM 같은 분산 오브젝트로 자사의 기술을 디팩토 스탠더드(사실상 표준)로 만들기 위해 표준화 경쟁을 벌인 적이 있는 그룹이다. 거의 성공하지 못했지만, 같은 방법론으로 웹상의 분산 오브젝트를 구현하려 했음.

RPC/분산 오브젝트 그룹의 움직임 중 가장 기본적인 프로토콜은 SOAP. HTTP를 애플리케이션 프로토콜이 아닌 트랜스포트 프로토콜로 다루고, HTTP 상에서 독자적으로 메시지를 전송한다. SOAP는 Microsoft가 W3C에 제안하고, IBM과 그 밖의 벤더를 끌어들여 표준화가 시작됨.

SOAP는 메시지 전송 방법만을 규정한 스펙. 실제로 시스템을 구축할 때는 SOAP 상에 서비스 별로 프로토콜을 정의해야만 함.

→ 이를 벤더마다 제각기 정의하게 되면 이전 분산 시스템의 전철(벤더 간 호환성이 없어서 서로의 시스템에 접속할 수 없는 현상)을 밟는 셈이기 때문에 ‘WS-*’라고 불리는 주변 스펙들이 W3C와 OASIS(Organization for Advancement of Structured Information Standard)에 제안됨.

하지만 여러 비슷한 스펙이 여러 개가 난립하여, 이전과 마찬가지로 표준화 경쟁을 불러일으켰음. 각 기업들이 자사의 표준을 통과시키기 위해 경쟁하느라, WS-* 사양서의 페이지 수가 급증하여 구현이 어려워짐

SOAP 대 REST

프로그램에서도 이용 가능한 웹의 아키텍처에 대한 논쟁에 로이 필딩도 적극적으로 관여했음. 그는 직접 만든 REST의 이론을 바탕으로 대기업들이 추진하는 SOAP 기반의 기술을 부정하고, 웹이 웹다울 수 있는 아키텍처로서 REST를 권장함.

필딩이 SOAP의 잘못된 점을 지적해도 대기업의 정치적 파워에 의해 SOAP 스펙의 책정 작업은 W3C에서 계속 진행되었음. 하지만, 필딩의 의견을 지지하는 사람들(마크 메이커, 폴 프레스코드 등)에 의해 REST가 선전되었음.

REST의 오해와 보급

SOAP와 REST에 관한 논쟁은 2000년대 전후부터 시작되어 2003년 정도에 정점에 달함. REST의 보급이 탄력을 받기 시작한 것은 2002년에 등장한 Amazon 웹 서비스였음. Amazon은 SOAP를 이용한 형식과 특정 URI와 HTTP로 GET하는 형식(기술적으로 정확하지는 않지만 편의상 ‘REST 형식'이라 부름)의 2가지를 준비했음.

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를 제공하는 정보를 조합하여 하나의 애플리케이션을 실현하는 방법을 말함. 매쉬업에서는 가벼움이 요구되었기 때문에, 웹 API가 제공하는 리소스를 HTTP와 URI로 간단히 조작할 수 있는 REST 스타일 쪽이 받아들여졌음.

웹 2.0: 개방, 참여, 공유의 정신을 바탕으로 사용자가 직접 정보를 생산하여 쌍방향으로 소통하는 웹  기술을 말한다. 웹1.0이 인터넷을 통해 일방적으로 정보를 보여주었다면, 웹 2.0은 사용자가 직접 콘텐츠를 생산하여 쌍방향으로 소통할 수 있다.

SOAP와 WS-*의 패인

첫째는 기술적인 이유다.

• SOAP와 WS-*는 RPC/분산 오브젝트가 가지고 있던 기술적인 문제점(호환성 이슈)을 그대로 가지고 있음 + 스펙들마저 복잡해져 버림
• 벤더 간 인터페이스 호환성의 결여, 복잡한 프로토콜 스택, 네트워크를 통한 인터페이스 호출에 의한 오버헤드 등

둘째는 정치적인 이유다.

• SOAP와 WS-*의 표준화 작업은 W3C와 OASIS에서 수행함.
• 표준화 작업은 각 벤더가 드래프트를 가지고 오면, 그 차이를 조정하는 식으로 이루어짐.
• 많은 벤더들이 SOAP 자체도 표준으로 확정되기도 전에 구현을 추진했기 때문에 동일한 SOAP, WS-*라도 해석에 차이가 생겼고 호환성이 결여됨

 

07 모든 것은 웹으로

REST가 보급되면서 웹은 인터넷을 통째로 집어 삼키기 시작했다. 별도의 프로토콜을 사용하던 메일과 넷 뉴스의 경우 백엔드에서 동작하고 있는 프로토콜은 변화하지 않았지만, 유저 인터페이스는 웹으로 통일되기 시작했고 엔드 유저는 웹만을 인식하게 되었음.

이런 배경에는 Ajax(Asynchronous JavaScript and XML)와 Comet 등의 기술적 돌파구가 있음. 그전까지 있을 수 없었던 사용자 인터페이스와 편의성이 웹의 장점과 맞물려 계속 실현되었음.

이와 같이 현재 우리들이 이용하고 있는 소프트웨어의 많은 부분이 웹을 전제로 하고 있기 때문에 웹의 중요성은 날로 커지고 있다.