바쁜 개발자들을 위한 REST 논문 요약

REST란 무엇인가? REST는 Representational State Transfer의 줄임말로, 웹을 위한 네트워크 기반 아키텍처 스타일이다. REST는 Roy T. Fielding이 그의 박사학위 논문 “Architectural Styles and the Design of Network-based Software Architectures” 에서 처음 소개하였다.

그의 논문을 읽고 매우 간략히 요약해보았다. 논문의 모든 부분을 동등하게 요약하지는 않았고, REST가 무엇인가를 이해하는데 초점을 맞추어 차별적으로 요약하였다.

논문 요약

1장: Software Architecture

아키텍처 스타일(architectural style)이란, 그 스타일을 따르는 아키텍처가 지켜야 하는 제약조건들의 집합이다.

2장: Network-based Application Architectures

이 논문에서 다루는 아키텍처 스타일의 적용 범위는 네트워크 기반 애플리케이션(Network-based Application)으로 한정된다.

네트워크 기반 소프트웨어는 operation이 네트워크를 경유해서 일어난다는 사실을 사용자에게 감출 필요가 없다. 분산(distributed) 소프트웨어는 감추어야한다.

애플리케이션이기 때문에, OS나 네트워킹 소프트웨어 같은 것은 고려 대상에서 제외된다.

네트워크 기반 애플리케이션 아키텍처의 관심 사항은 다음과 같다.

  • 성능
  • 규모확장성(Scalability)
  • 단순성
  • 수정용이성(Modifiability)
  • 가시성(Visibility)
  • 이식성(Portability)
  • 신뢰성(Reliability)

3장: Network-based Architectural Styles

이 장에서는 Pipe and Filter, Layered-Client-Cache-Stateless-Server, Code on Demand 를 비롯한 여러가지 네트워크 기반 아키텍처 스타일들을 소개한다.

4장: Designing the Web Architecture: Problems and Insights

이 장에서는 웹 아키텍처의 요구사항, 해결해야할 문제를 설명하고 이를 해결하기 위한 접근 방법을 제시한다.

5장: Representational State Transfer (REST)

4장에서 제시한 접근방법의 결과물로 웹을 위한 아키텍처 스타일 “REST”를 소개한다. REST는 3장에서 소개했던 네트워크 기반 아키텍처 스타일들 몇 가지와 추가로 Uniform Interface 스타일을 함께 결합한 하이브리드 스타일이다.

  • Client-Server – 클라이언트-서버 스타일은 사용자 인터페이스에 대한 관심(concern)을 데이터 저장에 대한 관심으로부터 분리함으로써 클라이언트의 이식성과 서버의 규모확장성을 개선한다.
  • Stateless – 클라이언트와 서버의 통신에는 상태가 없어야한다. 모든 요청은 필요한 모든 정보를 담고 있어야한다. 요청 하나만 봐도 바로 뭔지 알 수 있으므로 가시성이 개선되고, task 실패시 복원이 쉬우므로 신뢰성이 개선되며, 상태를 저장할 필요가 없으므로 규모확장성이 개선된다.
  • Cache – 캐시가 가능해야한다. 즉 모든 서버 응답은 캐시 가능한지 그렇지 아닌지 알 수 있어야한다. 호율, 규모확장성, 사용자 입장에서의 성능이 개선된다.
  • Uniform Interface – 구성요소(클라이언트, 서버 등) 사이의 인터페이스는 균일(uniform)해야한다. 인터페이스를 일반화함으로써, 전체 시스템 아키텍처가 단순해지고, 상호작용의 가시성이 개선되며, 구현과 서비스가 분리되므로 독립적인 진화가 가능해진다. 이 스타일은 다음의 네 제약조건으로 이루어진다: identification of resources, manipulation of resources through representation, self-descriptive messages, hypermedia as the engine of application state
  • Layered System – 계층(hierarchical layers)으로 구성이 가능해야하며, 각 레이어에 속한 구성요소는 인접하지 않은 레이어의 구성요소를 볼 수 없어야한다.
  • Code-On-Demand (Optional) – Code-On-Demand가 가능해야한다. 서버가 네트워크를 통해 클라이언트에 프로그램을 전달하면 그 프로그램이 클라이언트에서 실행될 수 있어야한다. (Java applet이나 Javascript 같은 것을 말함) 다만 이 제약조건은 필수는 아니다.

6장: Experience and Evaluation

REST 아키텍처 스타일은 URI, HTTP 등의 웹 표준에 반영되었다.

문제는 Uniform Interface (그리고 다음 포스팅 예고)

우리가 이 논문에서 가장 주목해야 할 부분은 바로, REST를 구성하는 스타일들 중 하나인 “Uniform Interface”다. 이 스타일에 따르면, REST API는 기본 URI와 미디어 타입의 정의만 알면 이용할 수 있어야한다.

예를 들어 Github API가 REST API라면, https://api.github.com 이라는 기본 URI와 application/json의 정의만 알면 API 문서 없이도 Github API 전체가 이용이 가능해야 한다는 말이 된다. 아마 가능하지 않을 것이다. 따라서 Github API는 REST API가 아니다. 아마 세상의 거의 모든 HTTP API가 REST API가 아닐 것이다.

Code-On-Demand를 제외한 모든 스타일을 다 따라야만 REST API이기 때문에, 자신의 API를 REST API라고 부르고 싶다면 이 Uniform Interface 스타일 역시 따라야한다.

과연 Uniform Interface 스타일을 따르는 것은 가능할까? 아니 그 이전에 따르기는 해야 하는 것일까? 그것에 대해서는 다음 포스팅에서 다룰 것이다.

비바 리퍼블리카로 이직한 이야기

2016년 11월 20일, 나는 8년 10개월간 근무한 네이버를 퇴사하고, 그 바로 다음날인
21일 스마트폰 송금 서비스 토스를 만드는 비바 리퍼블리카에 입사했다.

입사를 결정하게 된 계기

작년 즈음부터 스타트업에서 일해보는 것도 괜찮을 것 같다는 생각을 하게 되었는데,
그 와중에 비바 리퍼블리카에서 보낸 구인 메일을 받고서 이직을 생각하게 되었다.

2주일 정도 생각을 해보다가 한번 면접을 보기로 결정하고 회신 메일을 보냈다. 나는
내가 좋아하는 서비스를 만들기를 원했고, 비바 리퍼블리카에서 만드는 토스는 UX가
굉장히 훌륭해서 매우 만족스럽게 쓰고 있다. 그것이 입사를 결정한 가장 결정적인
이유이다.

채용 과정

이후 진행은 일사천리였다.

10월 2일(일), 입사 제의를 받아들이기로 결정하고 회신
10월 4일(화), 오프라인에서 비바 리퍼블리카가 어떤 회사인지 이야기를 들음
10월 5일(수), 메일로 이력서 전달
10월 7일(금), 기술 면접
10월 10일(월), 최종 면접
10월 11일(화), 최종 합격 및 오퍼 받음
10월 12일(수), 오퍼 수락

면접을 보기로 결정하고 최종적으로 오퍼를 받아들이기까지 고작 10일밖에 걸리지
않았다. 정말 놀라운 속도였다.

퇴사 및 입사

10월 17일(월), 네이버 퇴직 신청
11월 5일(금), 네이버 마지막 출근
11월 20일(일), 네이버 퇴사
11월 21일(월), 비바 리퍼블리카 입사

2주간 휴가를 갖고 비바 리퍼블리카에 입사하였다.

여담

비바 리퍼블리카에 이력서를 보낸 날, 적립 서비스 도도포인트를 만드는 스타트업인
스포카에도 이력서를 보냈다. 스포카는 오픈소스 활동을 적극적으로 하는 점이
매력적이어서 관심을 갖고 있던 회사였다.

하지만 아쉽게도 스포카에서 서류 전형 합격 메일을 받았을 때는 이미 내가 비바
리퍼블리카의 오퍼를 받은 뒤였기 때문에 스포카의 면접을 보는 일은 없었다.
스포카의 채용 프로세스가 느리지는 않았지만 비바 리퍼블리카가 너무나도 빨랐다.

wordpress.com로 이사

원래 cafe24 가상 호스팅에 설치형 워드프레스를 쓰고 있었는데, 때때로 서버가 죽어서 좋지 않았다. 죽어도 알려주지도 않는다는 점은 더욱 나빴다.

그래서 서비스형 워드프레스로 이사왔다. 도메인 연결비용 연 13달러만 내면 되고 서버가 잘 죽지도 않을 것 같고 죽더라도 알아서 살려낼테니.

disqus로 댓글 단 건 옮겨오지 못하고 백업만 했다. xml로 export를 하기는 했는데, 여기로 import 하는 방법은 모르겠다.

구글 크롬으로 구글에 접속하면 HTTP/2가 아닌 SPDY/3.1을 사용하는 이유

구글 크롬을 이용해서 구글 사이트에 접속하면 HTTP/2가 아닌 QUIC+SPDY/3.1로
동작하게 된다. 왜 HTTP/2가 아닌 SPDY/3.1을 사용하는 것일까?

내 생각엔 명세상 QUIC과 HTTP/2를 동시에 사용할 수 없어서가 아닐까 싶다.

HTTP 명세를 살펴보자. 우선 HTTP/1.1은 TCP를 강제하지 않는다. 신뢰할 수 있는
transport layer 위에서 구현되어 있기만 하면 된다.

HTTP is a stateless request/response protocol that operates by
exchanging messages (Section 3) across a reliable transport- or
session-layer “connection” (Section 6).

https://tools.ietf.org/rfc/rfc7230.txt

다음 문장에서도 그 사실을 확인할 수 있다.

Although HTTP is independent of the transport protocol, the “http”
scheme is specific to TCP-based services because the name delegation
process depends on TCP for establishing authority.

https://tools.ietf.org/rfc/rfc7230.txt

TCP를 강제하지 않는 것은 SPDY/3.1 역시 마찬가지다.

SPDY adds a framing layer for multiplexing multiple, concurrent streams
across a single TCP connection (or any reliable transport stream).

https://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1

반면에 HTTP/2는 명시적으로 TCP를 요구한다.

An HTTP/2 connection is an application-layer protocol running on top
of a TCP connection ([TCP]).

https://tools.ietf.org/rfc/rfc7540.txt

구글에서 구현한 QUIC 프로토콜은 TCP의 영역인 transport layer를 포함한다.
따라서 QUIC을 사용한다는 것은 TCP를 사용하지 않는다는 것이므로 QUIC 위에서
HTTP/2를 동작시키는 것은 HTTP/2 명세의 정의상 불가능하다.

변정훈님의 트윗을 보고 생각나서 적어보았다.

ps. Brian Hong님의 트윗에 따르면 QUIC은 TCP만을 대체하는 것이 아니라 SPDY도 대체하는 것이라고 한다. 확인해보니 QUIC은 TCP+TLS+SPDY 혹은 TCP+TLS+HTTP/2와 동등하다고 한다.

gnome에서 hidpi 1.5배 스케일

요새 hidpi 지원하는 모니터/노트북들이 많은데, 이런 디스플레이의 경우 gnome은 자동으로 2배로 스케일을 해 준다. 하지만 솔직히 2배는 너무 크다. 1.5배 정도가 적당할 것 같은데, 스케일은 오직 정수 단위로만 지원된다.

하지만 다음과 같이 스케일은 1배로 하고, 텍스트만 1.5배로 하는 걸로 어느정도 흉내는 낼 수 있다.

gsettings set org.gnome.desktop.interface scaling-factor 1
gsettings set org.gnome.desktop.interface text-scaling-factor 1.5

그럭저럭 만족하면서 쓸 수 있는 수준은 될 것이다.

웹 프로그래머를 위한 HTTP 완벽 가이드 읽는 법

HTTP 완벽가이드는 이름 그대로 HTTP를 매우 자세히 다루고 있는 책이다. HTTP를 이해해야 하는 사람은
웹 프로그래머만은 아니므로, 이 책은 웹 프로그래머만을 위해 쓰여진 책이 아니다.
따라서 웹 프로그래머가 이 책의 내용을 모두 다 완전히 이해해야 하는 것은 아니며,
중요도가 장 마다 크게 다르다.

웹 프로그래머의 시간은 유한한데 반해 공부해야 할 내용은 어마어마하게 많으므로,
중요한 것만 읽고 안 읽어도 되는 부분은 그냥 넘어가자.

무엇을 읽고 무엇을 안 읽을 것인가

I. HTTP: 웹의 기초

Part I은 모두 읽는 것이 좋다. 기초가 튼튼해야 이후의 내용을 잘 이해할 수 있다.

1장 “HTTP 개관”은 HTTP에 대해 개략적으로 설명해주므로, 이후의 내용들을
이해하는데 도움이 된다.

2장 “URL과 리소스”와 3장 “HTTP 메시지”는 반드시 읽어야 한다. 이 장들을 읽지
않으면 이후 내용들도 이해하기 어렵다. 특히 3장은 이름대로 HTTP 그 자체를
설명하는 장이다.

4장 “커넥션 관리”도 읽는 것이 좋다. HTTP 기저에서 TCP가 어떻게 동작하는지
설명한다. 읽고 나면 HTTP가 왜 느린지 이해할 수 있게 될 것이다.

II. HTTP 아키텍처

Part II는 유용한 내용이 많다. 특히 5장이 가장 중요하고 그 다음은 7장이 유용하다.

5장 “웹 서버”는 웹 서버가 어떻게 동작하는지 설명한다. 웹 프로그래머라면 반드시
이해해야 할 것이다.

6장 “프락시”도 읽는 것이 좋다. 프락시에 대한 이야기는 이후에도 계속 나오게
된다. 또한 네트워크 엔지니어들과 대화하려면 프락시 정도는 이해하는 것이 좋다.

7장 “캐시”도 읽어 두자. 제목은 캐시지만 캐시 뿐 아니라 조건부 요청(304로
응답하는 그거)도 다룬다. 웹 프로그래머라면 반드시 써먹게 될 것이다. 15장에서도
같은 내용을 다루기는 하지만 7장이 더 자세하다.

8장 “통합점: 게이트웨이, 터널, 릴레이”는 꼭 읽어야 하는 건 아니다. 나중에
궁금해지면 읽어도 별 상관은 없다.

9장 “웹 로봇”은 로봇이나 검색엔진에 관심이 있다면 읽어보자. 웹 서비스를
운영하게 된다면 웹 로봇이 무슨 원리와 규칙으로 동작하는지 궁금해질 것이다. 혹은 그냥 웹에 대한 교양이라는 느낌으로 읽어도 좋다.

10장 “HTTP/2.0″는 HTTP/2가 궁금하다면 읽어보자. HTTP/2의 목적은 성능 개선이니, HTTP/1이 느린 것이 불만인 사람도 읽어보자. HTTP/2가 완성되기 전에 쓴
것이긴 하지만 최신 명세와 크게 다른 점은 없을 것이다.

III. 식별, 인가, 보안

Part III는 13장 빼고는 대체로 유용하다.

11장 “클라이언트 식별과 쿠키”를 읽으면 쿠키에 대해 올바르게 이해할 수 있게 된다.

12장 “기본 인증”도 읽으면 좋다. 기본 인증(Basic Authentication)은 여전히 종종
쓰이기 때문이다. 그리고 매우 쉬워서 읽기도 좋다.

13장 “다이제스트 인증”은 읽을 필요가 없다. 다이제스트 인증 쓰는 것은 거의 본
일이 없다. 이걸 공부해도 써 먹을 일은 아마 없을 것이다. 심지어 내용도 복잡해서
읽어도 이해가 잘 안된다. 여럿이 같이 스터디 중이라면 이 장은 그냥 제끼자.

14장 “보안 HTTP”은 HTTPS를 다루고 있다. 읽는 것이 좋다. 몰라도 HTTPS를 쓸 수는
있겠지만, 왜 HTTPS가 안전한지 이해하고 싶다면 읽는 것이 좋다.

IV. 엔터티, 인코딩, 국제화

파트 I가 HTTP에 대한 기본적인 이해를 위해 필요했다면, 파트 IV는 HTTP를 제대로
쓰기 위해서 필요하다. 여기서 다루는 내용들은 대체로 웹 서버나 웹 프레임워크가
알아서 처리해주지 않아서 웹 프로그래머가 이해해야 하는 것들이 많다. 가급적 모두
읽도록 하자.

그 중에서도 16장 “국제화”에서 다루는 내용은 비단 웹 프로그래밍이나 HTTP에만
적용되는 내용이 아니라 다국어를 다루는 모든 프로그래머가 알아야 할 내용이므로 활용 범위가 매우 넓다.

V. 콘텐츠 발행 및 배포

이 파트의 내용은 선택적으로 필요에 따라 읽으면 된다. 스터디를 하고 있다면 이
파트 전체를 생략해도 괜찮다.

18장 “웹 호스팅”은 웹 서비스 운영을 시작하게 되면 그때 읽어도 무방하다.

19장 “배포 시스템”은 FrontPage와 WebDAV을 다루는데, 지금 FrontPage나 WebDAV을 쓸 일이 없다면 읽지
않아도 무방하다.

20장 “리다이렉션과 부하 균형”은 앞부분만 좀 읽고 넘어가도 된다. 이 장에서
다루고 있는 캐시 배열 라우팅 프로토콜 같은 거 나는 써본 일이 없다. 혹시
네트워크 엔지니어 역할까지 겸하고 있다면 알 필요가 있을지도 모르겠는데, 나는
그런 경험을 해 본 일이 없어서 잘 모르겠다.

21장 “로깅과 사용추적”도 역시 필요에 따라 읽으면 된다. 로그 포맷에 대한 내용은
사용하고 있는 웹 서버의 매뉴얼을 읽어도 충분할 것이고, 사용 추적은 필요하지
않을 수도 있다.

VI. 부록

부록은 대체로 HTTP 명세나 IANA 웹사이트 등에서 찾아볼 수 있는 것들이다. 책이
두꺼워서 들고다니기 무겁다면 잘라내도 좋다. 그냥 인터넷에서 찾아봐도 된다.

세줄 요약

매우 바쁘다면 1-3장만 읽자. 그 정도만 읽어도 큰 도움이 된다.

조금 바쁘다면 1-5, 7, 11, 12, 14, 15, 16, 17장을 읽자.

13, 19장은 관심있는 사람만 읽자.

프로 Git 읽는 법

Git은 서브버전보다 사용하기 어렵다. 아마 대중적인 버전관리도구 중 가장 어려울 것이다. 서브버전은 따로 공부하지 않고 썼던 개발자라도, Git을 쓰려면 공부를 해야한다.

Git을 공부하는 최고의 방법은 책 ‘프로 Git‘을 읽는 것이다. 프로 Git을 처음 읽는 순간 그것을 확신했으며, 이후 사용자로서 Git을 익히고, 부분적으로 Git을 구현해보기도 하고, 사내에 Git 교육과정을 만들어 진행해본 이후에도 그 생각은 변하지 않았다.

그러나 아무리 훌륭한 책이라고 할지라도, 오직 버전관리도구만을 위해 200페이지가 넘는 책을 처음부터 끝까지 모두 읽어야 한다는 것은 당장 개발을 시작하고 싶어하는 개발자들에게는 너무나도 지루하고 고통스러운 일이다.

다행히도 이 책을 반드시 모두가 완독해야만 하는 것은 아니다. 필요에 따라서 골라 읽어도 무방하다. 예를 들어 당장 내일부터 Git을 써서 개발을 시작해야 하는 상황이라면, 이 책의 1.3.5절과 2장을 읽고 연습해서 Git의 사용법을 익히면 된다.

어떤 챕터를 언제 읽는 것이 좋을지 적어보면 다음과 같다.

  1. 시작하기 – 가급적이면 읽자. 정 읽기 싫으면 “1.3.5 세 가지 상태”만이라도 읽자. 그것만은 절대로 읽어야 한다. 읽지 않으면 Git을 쓸 수 없다.
  2. Git의 기초 – 이것을 읽으면 Git을 쓸 수 있게 된다. 반드시 읽자
  3. Git 브랜치 – 이것을 읽으면 Git을 잘 쓸 수 있게 된다. 왠만하면 읽자.
  4. Git 서버 – Git 서버를 직접 운영한다면 읽어야 한다. 그렇지 않다면 읽지 않아도 무방하다. 물론 읽으면 서버를 이해할 수 있게 되어서 좋기는 하다.
  5. 분산 환경에서의 Git – 여러명이 협업한다면 읽는 것이 좋다.
  6. Git 도구 – 뭐 더 좋은 기능 없어? 라는 생각이 들 때 읽어도 무방하다.
  7. Git 맞춤 – 위와 마찬가지로, 이런 설정은 없나? 라는 생각이 들 때 발췌해서 읽어도 무방하다.
  8. Git과 다른 VCS – Subversion과의 차이가 궁금하다면 읽자.
  9. Git의 내부구조 – Git을 능숙하고 편안하게 다루려면 반드시 그 내부를 이해해야 한다. 팀에 한 명 정도는 이 챕터의 내용을 이해할 수 있는 수준에 달해있는 것이 좋다.

이런 훌륭한 책을 지은 스캇 샤콘과, 한국어로 번역한 박창우, 이성환, 최용재님께 깊은 감사를 드리고 싶다.