[새싹] 웹을 지탱하는 기술 Chapter02

채상엽·2022년 5월 10일

Sproutt 2nd - Spring Study

목록 보기

14/32

layout: post
title: "웹을 지탱하는 기술 스터디 - Chapter2"
date: 2022-02-28T00:00:00-00:00
author: sangyeop
categories: Sproutt-2nd

새싹 개발 서적 스터디 - 웹을 지탱하는 기술 Chapter02

Chapter 02. 웹의 역사

웹 이전의 인터넷

초기의 인터넷에는 웹이 없었다. 인터넷의 기원은 ARPANET 이라고하는 미국 내 대학과 연구기관 사이를 고속 회선으로 접속하고, 전 미국을 연결하는 네트워크이다.

당시의 네트워크에는 리얼 타임(실시간)으로 상대와 통신하는 TCP/IP 뿐만 아니라, 패킷 릴레이 방식의 UUCP에 의한 전송도 존재했었기 때문에 메일이 도달하기까지 지연이 있었다.

웹 이전의 하이퍼미디어

Memex - 하이퍼미디어의 기원

Memex는 실재하는 시스템이 아닌 구상이었지만, 전기적으로 접속한 책과 파일을 서로 링크하고 링크를 따라서 차례로 표시하는 현재의 웹을 예상할 수 있는 시스템 이었다. 이 Memex 구상때는 하이퍼미디어라는 단어는 등장조차 하지 않았지만 많은 연구자들에게 영향을 끼쳤다.
Xanadu - 하이퍼미디어라는 단어의 탄생

테드 넬슨은 1965년에 하이퍼텍스트와 하이퍼미디어라는 말을 잇달아 고안해냈다. 하이퍼텍스트가 문자 정보 중심의 문서를 상호 링크시키는 개념인데 반해, 하이퍼미디어는 그 사고를 확장해 음성과 동영상 등 다양한 미디어를 상호 링크시킨 개념이다. 이렇게 이상적인 기능을 가진 하이퍼미디어 Xanadu를 구상했지만, Xanadu는 개발의 고기능으로 인한 복잡성때문에 실패하고 말았다.
HyperCard - 최초의 실용적인 하이퍼미디어

HyperCard에는 네트워크를 통해 데이터를 주고받는 기능조차 없었지만, '카드'라고 불리는 문서를 단위로 상호 링크하고, 스크립트언어 HyperTalk에 의한 프로그램을 실행할 수 있는 말하자면, Stand-Alone 방식의 웹 서비스였다.
웹 이전의 하이퍼미디어의 문제점

현재 가장 많이 보급된 하이퍼미디어의 구현은 웹이다. 웹상의 문서는 모두 링크로 연결되어 있다. 그러나 넬슨 등의 하이퍼미디어 추진자들의 시각에서의 웹은 불완전한 하이퍼미디어로 비춰질 것이다. 왜냐하면 웹은 단방향 링크만 지원하고, 링크가 끊어질 가능성이 있으며, 버전 관리와 트랜스클루전 기능이 없기 때문입니다.

트랜스클루전(Transclusion) : 어떤 문서 안에 다른 문서의 단편으로 연결되는 참조를 삽입하여, 마치 하나의 문서처럼 보이게 하는 기술. 이에 따라 문서의 모듈화가 가능해졌다. HTML에서 구현한 예로는 <img>요소에 의한 이미지 삽입 등을 예로 들 수 있겠지만, 어떤 것도 넬슨이 상정했던 기능에는 미치지 못한다.

웹 이전의 분산 시스템

분산시스템도 웹 등장 이전부터 존재하던 기술이다. 여기서는 분산 시스템의 역사를 돌아보며 기술적인 문제를 짚어보겠다.

중앙 집중형 시스템과 분산 시스템
- 최초
  
  과학 기술 계산 등의 단일 목적으로 만들어졌다.
- 1960년대
  
  한 대의 컴퓨터를 여러 목적으로 사용할 수 있게 되었다. 이 당시에는 단말기로 호스트 컴퓨터에 접속해서 호스트 컴퓨터에서 집중해 처리하는 방식이었다.
- 1970년대 이후
  
  컴퓨터의 소형화와 성능이 향상됨에 따라서, 복수의 컴퓨터를 조합해 처리를 분산해 전체적인 성능을 향상 시킬 수 있었다.
RPC - 다른 컴퓨터의 기능을 이용하기

분산 시스템을 실현하기 위해서는 각 서버가 제공하는 기능을 다른 서버와 클라이언트에서 호출할 수 있어야 한다. RPC는 분산 시스템을 실현하기 위한 기술 중 하나이다. RPC를 이용하면 원격서버에서 실행하고 있는 프로그램을 클라이언트 쪽에서 호출할 수 있다.
CORBA,DCOM - 분산 오브젝트로의 진화

RPC(Remote Procedure)는 이름 그대로 함수를 호출 하는 구조다. 하지만 현대적 프로그래밍 언어들은 거의 모두가 객체지향 기능을 갖추고 있기 때문에, 단순 호출이 아닌 객체 자체를 원격으로 호출하는 분산 오브젝트라고 불리는 기술이 고안되었다. CORBA와 DCOM은 오브젝트의 메서드를 정의하고, 구현은 네트워크를 경유해 시리얼라이즈 된 메시지를 교환하는 점이 RPC와 동일하다. 그러나 CORBA와 DCOM은 매우 복잡하고, 호환성이 없어서 서로 접속할 수 없다는 문제가 있었다.
웹 이전의 분산 시스템의 문제점
- 성능열화의 문제
네트워크를 경유한 함수 호출은 프로세스 내 함수 호출에 비해서 더 많은 시간이 걸리고, 여러번 호출해야 하기때문에 성능이 문제가 생긴다.
- 데이터형 변환의 문제
프로그래밍 언어마다 지원하는 데이터형이 다르기 때문에, 복수 언어가 존재하는 환경에서 문제가 생긴다.
- 인터페이스 버전업 시 호환성 문제
기능 추가가 되면서 서버 인터페이스가 바뀐 경우, 구 버전에 대해 하위 호환성을 가질 수 없다.
- 부하 분산의 문제
일반적으로 RPC 기반의 시스템은 서버 상에 클라이언트의 애플리케이션 상태를 가지고 있기 떄문에, 서버끼리 애플리케이션 상태를 공유하지 않으면 안 되고, 다수의 서버에서 부하를 분산하는 것이 어려워진다.

웹의 탄생

하이퍼미디어로서의 웹

장점
- 인터넷을 이용하기 때문에 불특정 다수의 정보를 서로 링크시킬 수 있고
- 시스템을 대규모화하기 쉽다
단점
- 정보의 집중적 관리가 어려워진다
- 링크가 끊어지기 쉽다
웹에 복잡한 확장 링크 구조를 도입하려는 움직임도 있었지만, 사용자에게 있어서 이해하기 쉽고 구현이 간단한 단반향 링크로 현재까지 보급되었다.
분산 시스템으로서의 웹

RPC는 미리 상정된 숫자와 종류의 클라이언트를 상대로하는 서비스에서는 매우 뛰어나다. 그러나 개방된 불특정 다수의 클라이언트에게는 적합하지 않다. 개방적이고 불특정 다수를 상대로하는 시스템이 바로 웹이다. 각 유저들의 OS와 하드웨어가 통일되어 있지 않으며, 다양한 환경에서 서비스에 접근할 수 있다. 이것은 클라이언트-서버간 인터페이스를 HTTP라는 심플한 프로토콜로 고정함으로써 실현되었다.

웹의 표준화

웹의 스펙 책정

웹을 구성하는 기술 HTTP, URI, HTML에 대한 표준화가 요구되었다. 그러나 웹이 급속하게 보급되어 버림으로써 각 기업의 구현이 제각각이라 상호운용성이 결여되는 사태가 발생했다. 당시 상황을 "브라우저 전쟁" 이라고도 한다.
REST 탄생

로이 필딩이라는 인물이 버너스-리 그룹과 함께 HTTP 1.0, HTTP 1.1의 스펙을 제정하는게 관여했다. 로이 필딩은 웹이 성공한 이유, 대규모 시스템이 성립된 것인지에 대해서 하나의 아키텍처 스타일로 정리했다. 이 아키텍처 스타일을 REST라고 이름 붙였다. 이 이름은 리소스 상태의 표현 이라는 의미에서 비롯해서. Representational State Transfer라고 정해졌다.
다양한 하이퍼미디어 포맷의 탄생

초기 웹에서는 HTML이 유일한 하이퍼미디어 포맷이었다. 그러나 웹이 보급됨에 따라서 HTML 만으로는 대응하기 어려운 요구들이 나타났고 새로운 하이퍼미디어 포맷들이 탄생했다.
- microformats
  - HTML에 다양한 의미를 가지게 할 수 있는 기술 포맷이다.
- RSS
  - 웹페이지의 새로운 정보를 서버에서 발송하고, 전용 프로그램으로 체크하기 위한 용도로 등장했다.
- Atom
  - RSS의 복수 버전이 난립해 혼란스러웠던 문제를 개선하기 위해 등장했다.
- JSON
  - HTML과 Atom은 XML 기반으로 한 구조화 문서용 마크업 언어이기 때문에 표기의 중복이 너무 많았다. 이를 개선하기 위해 단순한 포맷을 가지고 등장한 사실상 표준이 된 것이 JSON이다.

웹 API를 둘러싼 논의

초기에는 주로 문서를 읽기 위한 시스템이었으나, 점점 자동화 처리와 프로그램으로 조작이 가능한 웹 API에 대한 논의가 일어났다.

SOAP과 WS-*
- SOAP
  - RPC 분산 오브젝트 그룹의 움직임 중에서 가장 기본적인 프로토콜
  - HTTP 애플리케이션을 프로토콜이 아닌 트랜스포트 프로토콜로 다루고, 독자적으로 메시지를 전송한다.
  - 메시지 전송 방법만을 규정한 스펙이기 때문에, SOAP 상에 별도 프로토콜을 정의하지 않으면 안된다.
- WS-*
  - SOAP에서 각 벤더마다 별도 프로토콜을 정의하면 이전 분산 시스템과 같은 길을 밟는 것이기 때문에 등장했다.
  - 하지만 여러 비슷한 스펙이 난립해서 표준화 경쟁을 불러일으켰다.
SOAP 대 REST

로이 필딩은 본인의 REST 이론을 바탕으로 대기업들이 추진하는 SOAP 정책에 맞서 부정했다. 처음에는 대기업의 정치적 세력의 차이 때문에 힘을 쓰지 못했지만, 필딩을 지지하는 마크 베이커와 폴 프레스코드 라는 사람과 함께 다양한 미디어를 통해 함께 REST를 선전했다.
REST의 오해와 보급

Amazon은 서적과 상품들의 정보를 웹을 통해 프로그램으로 취급할 수 있도록, SOAP를 이용한 형식과 특정 URI와 HTTP로 GET하는 형식의 2가지를 준비했다. 이 때 후자를 REST 형식이라고 불렀다. 이를 계기로 웹 API의 보급이 빠르게 이루어지고, 논쟁이 일었다. 결과적으로는 REST측이 승리했다. 2004년부터 시작된 웹 2.0의 흐름속에서 Google과 Amazon 같은 기업들은 REST 형식의 웹 API를 제공했다. 이 웹 2.0에서는 가벼움이 요구 되었는데 HTTP와 URI로 간단히 조작할 수 있는 REST 쪽이 받아들여졌기 때문이다.
SOAP와 WS-*의 패인

크게 두 가지로 볼 수 있다.
- 기술적인 요인
  - RPC/분산 오브젝트가 가지고 있던 기술적인 문제점을 그대로 가지고 있다
  - 예를 들어 벤더 간 인터페이스 호환성의 결여, 복잡한 프로토콜 스택, 네트워크를 통한 인터페이스 호출에 의한 오버헤드 등
- 정치적인 이유
  - SOAP와 WS-*의 표준화 작업은 W3C와 OASIS에서 수행했다. 여기서 표준화 작업은 각 벤더가 드래프트를 가지고 오면 그 차이를 조정하는 식으로 이루어졌다.
  - 하지만 많은 벤더들이 SOAP 자체도 표준으로 확정되기 전에 구현을 추진해서, 해석에 차이가 생기고 호환성이 결여되었다.

모든 것은 웹으로

점점 REST가 보급되면서 웹은 인터넷을 통째로 집어 삼키기 시작했다. 이런 배경에는 Ajax, Comet등의 기술적 돌파구가 있었다. 이 기술들에 의해서 사용자 인터페이스와 편의성이 웹의 장점으로 맞물려 실현되었다.

예를 들어서 이전의 맵 소프트는 맵 데이터를 로컬 하드디스크에 설치해서 이용했었는데, 이 방식으로는 한대의 PC에 인스톨 한 데이터밖에는 다룰 수 없었다. 그에 비해, 현재의 맵 서비스는 전 세계의 위성사진과 지도를 언제나 최신 상태로 이용할 수 있는데 이는 서버 측에서 맵 데이터를 모아서 보관하고, 필요에 따라 웹을 통해 다운로드 하는 방식이기 때문에 가능한 것이다.

이 처럼 모든 소프트웨어와 데이터들이 계속해서 웹으로 구현되면서 웹의 중요성이 날로 커지고 있다.