'웹을 지탱하는 기술' 1회차 스터디 정리
December 21, 2019
집필 목적
-
스펙의 설명
- 웹 다움은 HTTP, URI, 각종 하이퍼미디어 포맷들의 스펙이 가진 아키텍처적인 뒷받침에 기초하기 때문에 스펙을 알아야 좋은 웹서비스를 설계할 수 있다.
-
웹 서비스의 구체적인 설계 방법
- 설계를 위해선 시스템 전체에 대한 깊은 지식이 필요하므로 관련 스킬을 하루아침에 익히기란 불가능하다. 그렇기 때문에 웹 서비스를 구체적인 설계 프로세스와 사고방법으로 설명하여 좋은 설계란 무엇인가에 대해 생각할 수 있도록 한다.
1부 웹 개론
웹이란 무엇인가
웹은 웹사이트, UI, API등의 분야에서 다양하게 사용된다.
웹을 지탱하는 기술들의 공통점 : 심플함
- URI : 종이 광고에 삽입할 수 있을 정도의 짧은 문자열
- HTML : XML을 바탕으로 한 문서포맷
- HTTP : HTTP메소드는 고작 8개 뿐
웹을 특징짓는 두가지 기술적 측면
- 하이퍼미디어 시스템 : 텍스트, 이미지, 영상 등 다양한 미디어를 하이퍼링크로 연결해 구성함 / 사용자가 자유롭게 정보를 선택할 수 있음(비선형적)
- 분산 시스템 : 복수의 컴퓨터를 조합해 처리를 분산시킨 형식 / 심플한 프로토콜 덕분에 분산 시스템의 실현이 가능
웹의 역사
초기의 인터넷에는 웹이 없었다.
- 1969년 미국 내 대학과 연구기관을 연결하기위해 ARPANET 회선이 구축되었다.
하이퍼미디어의 역사
- 1945년 ‘Memex’라는 정보 검색 시스템 구상
- 1965년 최초의 하이퍼미디어 ‘Xanadu’ 개발 but 개발의 복잡성 때문에 실패
- 1987년 ‘HyperCard’라는 실용적인 하이퍼미디어 탄생
분산 시스템
- RPC, CORBA, DCOM가 개발되었지만 한정된 수의 클라이언트를 전제로 했기 때문에 세계적인 규모의 시스템이 될 수 없었다.
웹의 탄생
- 1990년 팀 버너스리가 하이퍼미디어를 이용한 인터넷 기반의 ‘분산정보관리 시스템’이라는 웹 제안서를 작성하였다. 최초 버전이 발표된 후 전 세계로 보급되기 시작했다.
- 최초로 이미지를 혼재시킨 Mosaic 브라우저. IE, Firefox의 원류
웹의 성공 요인
- 심플한 단방향 링크, 최소한의 링크 때문이다.
- 개방형, 불특정 다수의 정보를 서로 링크시킬 수 있어 시스템을 대규모화하기 쉽다.
- 링크는 사용자에게 있어서 이해하기 쉽고 구현이 간단하다.
- HTTP 라는 인터페이스로 모든 프로토콜이 고정되어 있어 다양한 접근이 가능하다.
흥미로운 점
- 웹의 급속한 보급에 인터넷 표준 책정은 그 속도를 따라가지 못했고 기업간의 상호 윤용성이 결여되었다. 이를 해결하기 위해 1994년 버너스리를 중심으로 W3C가 설립되었고 HTML, XML, HTTP, URI, CSS등의 표준화 작업이 이루어졌다.
- 당시 Netscape Navigator와 Internet Explorer의 ‘브라우저 전쟁’으로 인해 브라우저별로 HTML과 CSS의 렌더링 결과가 크게 차이났다. 지금도 서서히 해결 중이지만 현재에도 남아있는 문제이다.
- 로이필딩이라는 대학원생이 HTTP의 스펙을 책정하는 시기에 웹의 성공 요인, 대규모 시스템의 성립 이유를 소프트웨어 아키텍처의 관점에서 분석하고 하나의 아키텍처 스타일로 정리했다. 그 후 2000년 ‘REST(Representational State Transfer)‘라는 이름으로 박사학위 논문을 발간했다.
- SOAP라는 프로토콜과 REST의 대결에서 복잡한 SOAP의 스펙에 비해 URI로 간단히 조작할 수 있는 REST가 승리했다.
REST-웹 아키텍처 스타일
아키텍쳐 스타일(패턴) : 복수 아키텍처의 공통된 성질, 양식, 규정 혹은 독특한 방식을 가리키는 말. 즉 아키텍처를 설계할 때 설계 지침, 규정, 방식등을 적용하고 결정해주는 나침반과 같은 역할
| 추상화 레벨 | 웹에서의 예 |
|---|---|
| 아키텍쳐 스타일 | REST |
| 아키텍쳐 | 브라우저, 서버, 프록시, HTTP, URI, HTML |
| 구현 | Apache, Firefox, Internet Explorer |
REST 웹 전체의 아키텍쳐 스타일이기도 하며, 개발 웹서비스와 웹 API의 아키텍쳐 스타일이다. 개별 웹 서비스가 전체의 조화를 무너뜨리면 전체가 통일된 아키텍쳐 스타일을 지킬 수 없기 때문에 REST규약을 지키는 것이 중요하다.
리소스 : 웹상의 정보 / 리소스는 URI로 의미있는 이름을 가진다 / URI를 이용하여 리소스 정보에 접근할 수 있다.
REST는 다음과 같은 복수의 아키텍처 스타일을 조합했다.
| 아키텍처 스타일 | 내용 | 장점 |
|---|---|---|
| 클라이언트/서버 | UI와 처리를 분리 | 클라이언트를 멀티 플랫폼으로 구성할 수 있음(PC, mobile) |
| 스테이트리스 서버 | 서버가 어플리케이션의 상태를 관리하지 않음 | 서버측의 구현을 간략화 할 수 있음 |
| 캐시 | 한번 가져온 리소스를 클라이언트쪽에서 돌려씀 | 클라이언트와 서버의 통신량을 줄여 효율적인 처리가 가능 |
| 유니폼 인터페이스 | 인터페이스의 고정 | 전체적인 아키텍처가 간결해짐 |
| 계층화 시스템 | 시스템을 계층별로 분리 | |
| 코드 온 디맨드 | 프로그램을 클라이언트에 다운로드하여 실행 | 클라이언트의 확장 가능 |
2부 URI
URI의 스펙
URI(Uniform Resource Identifier) : 리소스를 통일적으로 식별하는 ID
http://yohei:pass@blog.example.com:8000/search?q=test&debug=true#n10| 종류 | URI 요소 | 정보 |
|---|---|---|
| URI Scheme | http | URI가 이용하는 프로토콜 |
| 사용자 정보 | yohei:pass | 리소스 접근시 이용할 사용자이름과 패스워드 |
| 호스트명 | blog.example.com | 도메인명이나 IP어드레스 |
| 포트번호 | 8000 | 프로토콜이 사용할 TCP의 포트번호 |
| 패스 | /search | 호스트 안에서 오로지 하나의 리소스를 가리킴 |
| 쿼리 파라미터 | q=test&debug=true | 검색 키워드를 전달할 때, 동적 URI를 생성할 때 사용 |
| URI 프래그먼트 | #n10 | 리소스 내부의 세세한 부분을 특정 |
URI 종류
| URI 종류 | 내용 | 예시 |
|---|---|---|
| 절대 URI | 루트에서부터 전체 경로를 기술 | http://example.com/foo/bar |
| 상대 URI | URI스키마와 호스트명을 생략하고 경로만 표현 | /foo/bar |
| Basw URI | 상대 URI의 기점이 되는 URI | - |
URI에서 사용할 수 있는 문자
- 알파벳 : A-Za-z
- 숫자 : 0-9
- 기호 : -.~:@!$&`()
ASCII 이외의 문자(한글)를 URI에 넣을 때는 %인코딩 방식 사용
EX) 가 -> %EA%B0%80
주의할 점
- URI는 알파벳 대문자와 소문자를 구별하여 사용
- 가능한 절대 URI를 사용하는 편이 클라이언트에게 도움이 됨
- 문자 인코딩의 혼란을 피하고자 %인코딩의 문자 인코딩으로 될 수 있는 한 UTF-8을 이용
URI의 설계
좋은 URI(Cool URI)는 변하지 않는 URI이다.
변하지 않는 URI를 만들기 위해서는 다음과 같은 조건들이 있다.
- 프로그래밍 언어에 의존적인 확장자와 경로를 포함하지 않는다.
- 구현에 의존적인 경로명을 이용하지 않는다.(cgi-bin, servlet 등)
- 프로그래밍 언어의 메서드명과 세션ID를 포함하지 않는다.
- URI는 리소스를 표현하는 명사로 한다.
심플한 URI는 사용성이 향상된다. 기억하기 쉽고 일반인들도 사용하기 쉽다는 점이 Cool URI의 장점이다.
운용중인 시스템의 URI를 안이하게 변경해선 안되지만 변경해야 할 때는 가능한 Redirect하도록 하자.
메트릭스 URI
- 확장자로 표현을 지정하는 방법
- 확장자는 URI의 설계에 있어 좋지 않은 것으로 말했지만 구현에 의존하지 않는 확장자는 좋은 측면이 있다.
- 언어를 지정하는 확장자
http://example.com/content/press.koorpress.en
