논문 제목의 번역 추가, 달러 사인 처리

content/translations/misappropriated-rest-dissertation/index.md

@@ -20,11 +20,11 @@ RESTful API는 어디에서나 쓰이고 있다. 그런데 얼마나 많은 사
 
 이런 오해 중 가장 큰 것은 필딩의 논문이 API 구축에 대한 문제를 직접적으로 다룬다는 것이다. 나는 REST가 처음부터 HTTP 위에 구축되는 웹 API의 아키텍처 모델로서 의도되었을 거라고 생각하고 있었다. 내 생각에는 많은 사람들이 그럴 것이다. 나는 원래 다음과 같이 상황이 전개되었을 거라고 생각했다. 사람들이 HTTP 위에 엉망진창으로 API를 구축하던 혼란스럽고 실험적인 시기가 있었고 필딩이 나타나 REST라는 합리적인 해결책을 제시한 거라고 말이다. 하지만 이런 타임라인은 말이 되지 않는다. 우리가 오늘날 알고 있는 형태의 웹 서비스 API는 필딩이 논문을 발표한 후 몇 년이 지나서야 등장했기 때문이다.
 
-필딩의 논문은 "Architectural Styles and the Design of Network-based Software Architectures"라는 제목인데, HTTP 기반으로 API를 구축하는 방법에 대한 것이라기보다는 HTTP 그 자체에 대한 것이다. 필딩은 HTTP 1.0 명세에 기여했고, 1999년에 발표된 HTTP/1.1 명세의 공동 저자였다. 필딩은 HTTP 프로토콜의 설계에서 얻을 수 있는 아키텍처에 대한 교훈에 관심을 갖고 있었다. 그리고 그의 논문은 HTTP/1.1의 표준화 과정을 주도했던 아키텍처 설계 원칙을 정리한 개념으로 REST를 제시했다. 필딩은 어떤 제안을 HTTP/1.1에 포함할지에 대한 결정을 내릴 때 이 원칙을 사용했다. 예를 들어 필딩은 새로운 `MGET`, `MHEAD` 메서드를 도입하여 요청을 일괄 처리할 수 있게 하자는 제안을 거부했다. REST에 규정된 제약 조건 중 REST 시스템 내의 메시지가 프록시 및 캐싱하기 쉬워야 한다는 조건[^1]을 위반한다고 판단했기 때문이다. 그 대신 HTTP/1.1은 지속적으로 유지되는 연결을 기반으로 여러 HTTP 요청을 보낼 수 있도록 설계되었다. (또한 필딩은 쿠키가 stateless해야 할 시스템에 상태를 추가하기 때문에 RESTful하지 않다고 생각했다. 하지만 이미 쿠키는 널리 사용되고 있었다[^2].) 필딩에게 REST는 HTTP 기반의 시스템을 구축하기 위한 가이드가 아니라 HTTP를 확장하는 방법에 대한 가이드였다.
+필딩의 논문은 "네트워크 기반 소프트웨어 아키텍처의 아키텍처 스타일과 설계(Architectural Styles and the Design of Network-based Software Architectures)"라는 제목인데, HTTP 기반으로 API를 구축하는 방법에 대한 것이라기보다는 HTTP 그 자체에 대한 것이다. 필딩은 HTTP 1.0 명세에 기여했고, 1999년에 발표된 HTTP/1.1 명세의 공동 저자였다. 필딩은 HTTP 프로토콜의 설계에서 얻을 수 있는 아키텍처에 대한 교훈에 관심을 갖고 있었다. 그리고 그의 논문은 HTTP/1.1의 표준화 과정을 주도했던 아키텍처 설계 원칙을 정리한 개념으로 REST를 제시했다. 필딩은 어떤 제안을 HTTP/1.1에 포함할지에 대한 결정을 내릴 때 이 원칙을 사용했다. 예를 들어 필딩은 새로운 `MGET`, `MHEAD` 메서드를 도입하여 요청을 일괄 처리할 수 있게 하자는 제안을 거부했다. REST에 규정된 제약 조건 중 REST 시스템 내의 메시지가 프록시 및 캐싱하기 쉬워야 한다는 조건[^1]을 위반한다고 판단했기 때문이다. 그 대신 HTTP/1.1은 지속적으로 유지되는 연결을 기반으로 여러 HTTP 요청을 보낼 수 있도록 설계되었다. (또한 필딩은 쿠키가 stateless해야 할 시스템에 상태를 추가하기 때문에 RESTful하지 않다고 생각했다. 하지만 이미 쿠키는 널리 사용되고 있었다[^2].) 필딩에게 REST는 HTTP 기반의 시스템을 구축하기 위한 가이드가 아니라 HTTP를 확장하는 방법에 대한 가이드였다.
 
 필딩이 REST를 다른 시스템 구축에 적용할 수 없다고 생각했다는 이야기는 아니다. 다만 그는 REST를 적용할 다른 시스템 역시 "분산 하이퍼미디어 시스템(distributed hypermedia systems)"이라고 생각했다. 바로 이게 사람들이 REST에 대해 가지고 있는 또 다른 오해다. REST가 어떤 네트워크 애플리케이션에도 적용할 수 있는 범용 아키텍처라는 것이다. 하지만 필딩이 논문에서 REST를 소개하는 부분을 요약하자면 근본적으로 이렇게 말하는 것과 같다. "이봐, 우리가 방금 HTTP를 설계했어. 만약 너도 *분산 하이퍼미디어 시스템*을 설계하고 있다면, 우리가 만든 이 REST라는 멋진 아키텍처를 사용하면 훨씬 더 쉬울 거야." 웹이 이미 존재하는 상황에서 누군가가 이런 시스템을 구축하려는 시도를 할 거라고 필딩이 생각한 이유는 분명하지 않다. 어쩌면 2000년 당시에는 하나 이상의 분산 하이퍼미디어 시스템이 세상에 존재할 여지가 있는 것처럼 보였을지도 모른다. 어쨌든 필딩은 REST가 인터넷 상의 하이퍼미디어를 연결할 때 발생하는 확장성과 일관성의 문제를 해결하기 위한 개념이며, 분산 애플리케이션 전반을 위한 아키텍처 모델은 아니라는 점을 분명히 한다.
 
-우리는 필딩의 논문을 REST를 처음 소개한 논문으로 기억한다. 하지만 사실 그 논문은 모든 상황에 적용되도록 만든(one-size-fits-all) 소프트웨어 아키텍처가 얼마나 형편없으며 어떻게 하면 필요에 맞는 소프트웨어 아키텍처를 더 잘 선택할 수 있는지에 대한 논문이다. REST 자체를 다루는 내용은 논문의 챕터 하나에 불과하다. 논문의 대부분은 네트워크 애플리케이션에서 사용할 수 있는 다양한 아키텍처 스타일[^3]을 분류하는 데에 쓰인다. 이중에는 유닉스 파이프에서 영감을 받은 Pipe-and-Filter(PF)도 있고 Client-Server(CS) 스타일의 여러 변형도 있다. 예를 들어 Layered-Client-Server (LCS), Client-Cache-Stateless-Server (C$SS), 그리고 Layered-Client-Cache-Stateless-Server (LC$SS) 같은 것들 말이다. 이런 구조들은 점점 난해하고 다루기 힘들어진다. 하지만 필딩이 강조하고자 했던 핵심은 기존의 스타일들이 부과하는 제약들을 조합해서 새로운 스타일을 만들 수 있다는 것이다. REST 역시 이런 방식으로 도출되었으며 사실 REST 대신 Uniform-Layered-Code-on-Demand-Client-Cache-Stateless-Server (ULCODC$SS)라고 불릴 수도 있었다. 물론 명백한 이유로 그렇게 되지는 않았다.(역자: 당연하지만 REST에 비해 너무 길고 어색한 이름이니까) 필딩은 각각의 제약이 특정 애플리케이션에 적합할 수도 있고 그렇지 않을 수도 있으며, HTTP에는 이러한 제약 조건의 조합(REST)이 가장 적합하다고 판단했다는 점을 강조하기 위해 이러한 아키텍처 분류 체계를 제시했다.
+우리는 필딩의 논문을 REST를 처음 소개한 논문으로 기억한다. 하지만 사실 그 논문은 모든 상황에 적용되도록 만든(one-size-fits-all) 소프트웨어 아키텍처가 얼마나 형편없으며 어떻게 하면 필요에 맞는 소프트웨어 아키텍처를 더 잘 선택할 수 있는지에 대한 논문이다. REST 자체를 다루는 내용은 논문의 챕터 하나에 불과하다. 논문의 대부분은 네트워크 애플리케이션에서 사용할 수 있는 다양한 아키텍처 스타일[^3]을 분류하는 데에 쓰인다. 이중에는 유닉스 파이프에서 영감을 받은 Pipe-and-Filter(PF)도 있고 Client-Server(CS) 스타일의 여러 변형도 있다. 예를 들어 Layered-Client-Server (LCS), Client-Cache-Stateless-Server (C\$SS), 그리고 Layered-Client-Cache-Stateless-Server (LC\$SS) 같은 것들 말이다. 이런 구조들은 점점 난해하고 다루기 힘들어진다. 하지만 필딩이 강조하고자 했던 핵심은 기존의 스타일들이 부과하는 제약들을 조합해서 새로운 스타일을 만들 수 있다는 것이다. REST 역시 이런 방식으로 도출되었으며 사실 REST 대신 Uniform-Layered-Code-on-Demand-Client-Cache-Stateless-Server (ULCODC\$SS)라고 불릴 수도 있었다. 물론 명백한 이유로 그렇게 되지는 않았다.(역자: 당연하지만 REST에 비해 너무 길고 어색한 이름이니까) 필딩은 각각의 제약이 특정 애플리케이션에 적합할 수도 있고 그렇지 않을 수도 있으며, HTTP에는 이러한 제약 조건의 조합(REST)이 가장 적합하다고 판단했다는 점을 강조하기 위해 이러한 아키텍처 분류 체계를 제시했다.
 
 REST가 이렇게 어디서나 쓰이고 있는 건 참으로 깊은 아이러니다. REST는 오늘날 모든 종류의 네트워크 애플리케이션에서 맹목적으로 사용되고 있지만, 필딩은 원래 개별 애플리케이션의 특정한 요구사항에 맞는 소프트웨어 아키텍처를 도출해 내는 방법의 예시로 REST를 제시했다.