화요일, 7월 16

최근 웹 개발환경 이해 - 진보된 웹 환경 공부 #1 REST




개요


 Framework는 개발자들에게 보다 편하고 쉽게 좋은 코드를 만들 수 있게 해주는 역할을 합니다. 그렇다면, 무엇이 좋은 코드이고 무엇이 좋은 코드일까요? 이것은 누구도 쉽게 대답하기 어려운 질문입니다.

 최근 프로그래밍 기법이나 언어는 지속적으로 OOP를 지향하며 발전되어 왔습니다. OOP하면 우리는 지겹도록 들어온 말이 재사용성이나 캡슐화 같은 이야기인데 잘 와닿지는 않을 것입니다. 왜냐면 그건 결과이기 때문이죠. 우리가 OOP언어를 사용하기 때문에 재사용성이 높아지고 하는 것이 아니라, OOP 적으로 설계하고 코드를 짤 수 있어야 그 결과물로 수업시간에 배운 OOP의 장점들을 얻어낼 수 있게 되는 것입니다.

 이번 최근 웹 개발환경의 이해에서는 REST와 함께 Knockout.js 라이브러리를 통해 요즘 OOP 기법에서 특히 중요하게 생각하는 "결합도 낮추기"를 선배님들이 어떻게 고민하였고 해결 방안을 제시했는지에 대해서 공부하고자 합니다.

 { "결합도 낮추기 (Decoupling) " = 코드간 의존성을 없애는 것을 뜻하며, 최근에 애자일 혹은 Lean 방식의 개발방법론이 대세를 이루며, 가장 핵심 기능을 우선 구현하여 단계적으로 향상시켜나가는 방식에 가장 중요한 OOP 요소입니다. " }



REST 란?


 먼저 살펴볼 것은 REST 입니다.
 REST는 Representational State Transfer 의 약자로 우리나라 말로는 "상태 재현적 전송" 으로 표현할 수 있겠습니다. "상태 재현적 전송"이란 REST의 설계 원칙 중에 하나로 (그리고 WWW의 설계 원칙에도 동일한 ) Stateless = 비연결성을 뜻합니다.

 원칙적으로 HTTP는 비연결성을 지향합니다만, 현존하는 거의 모든 웹사이트들은 세션이나 쿠키등을 통해 상태 정보를 저장하고 이를 통해 일종의 연결성을 임의로 만들어서 운용하고 있습니다. REST는 로이필딩이 2000년도 박사 논문으로 발표했고, HTTP의 주요 저자라고 합니다. 그러니 HTTP가 오용되는 현실을 보고 이를 바로잡기 위해서 REST를 발표했다고 생각해도 무리는 아닌 것 같습니다. ( 2000년 발표된 설계 기법이 퍼지는데 걸린 시간을 생각해보면 IT라고 해도 변화가 그렇게 빠른건 아닌 것 같습니다. )

 어쨌든, WWW 는 말 그대로 Web과 같은 네트워크 시스템을 만들고자 한 것이 목표였고 REST는 이와 같은 목표를 이루기 위한 방법론이라고 할 수 있겠습니다.

 REST의 장점을 대표하는 케이스를 하나 찝어보자면,
 웹 서비스들이 폭발적으로 성장하게 된 계기를 마련해준 Open-API 가 바로 REST의 대표적인 케이스입니다. 이쯤에서 REST 서비스를 웹 개발이나 서비스에 전혀 조예가 없는 초심자 분들에게도 쉽게 설명해드리고자 합니다.


예를 들어, 프로그래밍을 짤 때를 생각해보시길 바랍니다.
우리가 만드는 함수는 어떤 짜여진 규격이 있습니다.
다음의 pseudo 코드를 한번 보시죠.

[반환값] function1 ( Arg1, Arg2 ) {
        ... work work work ...
        return result;
}

어떠세요? 위의 코드는 거의 모든 분이 이해하실 수 있을 겁니다.
그럼 이제 질문을 하나 드리겠습니다.

REST는 아래와 같은 질문을 통해 이해해야 합니다.
< 위와 같은 코드를 Remote에서 호출하려면 어떻게 해야 할까요? >
- 1. 어떤 머신도 쉽게 접근할 수 있는 식별 가능한 주소.
- 2. 서로 다른 머신끼리 통신할 수 있는 공통의 인터페이스.
- 3. 함수를 호출하고자 하는 머신을 식별할 수 있는 stateless한 인터페이스.
- 4. 해당 함수에 인자를 줄 수 있는 공통의 인터페이스.

 다시 한번 강조드리는 것은, REST는 WWW, WEB처럼 거미줄로 엮인 네트워크 시스템을 고민하면서 나온 설계 철학이라는 것 입니다. REST의 저자인 로이 필딩은 이와 같은 문제들을 풀 수 있는 환경 = RESTful 을 구축하면 여러가지 장점이 있다고 생각한 것 입니다. ^^

 그리고 각 필요한 요소들이 시간이 지나면서 구축이 되기 시작한 것이죠 ~~


1번의 답 URI
URL은 많이 들어보셨을텐데 URI는 뭔가 하시는 분 혹시 계신가요?
URL은 Uniform Resource Location의 약자로, 말 그대로 Resource의 Location에 대한 Uniform 입니다. 예를들면 http://{host}/image.jpg 와 같은 형식이 URL입니다. 하지만 이것으론 충분하지 않게 됐습니다.

왜냐구요? 위를 보세요, 우리는 이제 함수를 호출할 수 있는 어떤 주소값도 필요하게 되었습니다. 이를 URL처럼 http://{host}/fucntion1 으로 접근하면 어때? 오, 그거 좀 괜찮은데? 그래서 나온게 URI입니다. URI는 Uniform Resource Identifier의 약자로 식별자로서 리소스를 구분하겠다는 뜻입니다. 앞의 예처럼 http://{host}/function1이라고 하면 이것은 함수와 연결되는 리소스의 식별자라고 생각하면 되겠죠.

대신 자신만 사용하는 것이 아니기 때문이 이름은 신중이 지을 필요가 있습니다~


2번의 답 JSON
JSON은 아직 표준이 아닌 것으로 알고 있어서 의견이 다를 수 있습니다만, 어쨌든 JSON도 서로 다른 머신끼리 통신할 수 있는 공통의 인터페이스를 목표하는 것은 맞습니다.

JSON이 뭔지 간단히 집고 넘어가자면, 위에서 예를 든 함수에서 반환값이 ArrayList와 같은 형식이라고 생각해봅시다. 이것을 Remote에서 호출한 컴퓨터에게 어떻게 전달하면 좋을까요? 이런 의문에서 만들어진 코드입니다.

JSON은 JavaScript Object Notation의 약자로, 말 그대로 Javascript에서 Object를 표기하는 방법입니다. 이는 Hashmap과 같이 key-value 짝 형식으로 되어 있는데, 예를 들자면
{
    "이름": "테스트",
    "나이": 25,
    "성별": "여",
    "기혼": true,
    "주소": "서울특별시 양천구 목동",
    "특기": ["농구", "도술"],
    "가족관계": {"#": 2, "아버지": "홍판서", "어머니": "춘섬"},
    "회사": "경기 안양시 만안구 안양7동"
 }
이런 형식입니다. Object들에 대한 Descriptor를 함께 가지고 있다고 생각하면 될 것 같습니다. 그렇기에 Client에서는 JSON을 통해 Return값을 받고 이를 적절히~ 파싱해서 화면에 보여주면 되는 것이죠.

3번의 답 Stateless.
Stateless는 단순히 비연결지향만을 뜻하는 것은 아닙니다.
비연결을 지향하기 위해 서버/클라이언트 간에 혹은 타 머신간에 서로를 인식하기 위한 값을 커뮤니케이션 시에 함께 보냄을 뜻하는 것 입니다. 이것은 마치 TCP와 UDP의 통신 방식의 차이와 유사합니다.


4번의 답 HTTP Protocol
앞선 단계를 따라 Remote의 함수를 URI를 통해 호출하고 결과를 HTTP JSON으로 받는 것까지를 설계적으로 구현했다면, Argument를 주는 것을 어떻게 할 것인가? 이것은 HTTP Protocol을 사용합니다. HTTP 스펙에 따르면 HTTP 프로토콜은 4가지 메소드를 지원하는데 Get, Post, Put, Delete 가 그것입니다.

굳이 이런 Argument를 방식을 사용하는 이유는 HTTP 프로토콜보다 범용적으로 사용되는 것이 없기 때문이기도 하겠고, 애초에 설계 방향이 같기도 하기 때문인 것 같습니다. 어쨌든 Argument로 값을 넣어주고자 한다면, Post로 JSON을 보내면 되고, 단순히 값을 넣고자 한다면 Put을 사용하면 되겠죠.





마치며...


 이번 글에서는 REST에 대해서 간략히 다뤄봤습니다.

 REST라는 설계, 구현 방법을 배우고 습득하는 것도 중요하지만 그만큼 REST라는 것을 만들기 위해 했던 선배들의 고민과 문제의식 그리고 해결방안을 생각하기 까지의 과정을 생각하는 것도 중요하다고 생각합니다.

 다음 글에서는 REST를 실질적으로 구현할 수 있는 Framework를 보면서 REST 서비스를 구현하기 위해 필요한 요소들이 무엇인지에 대해 살펴보도록 하겠는데, 아마 분량이 너무 많을 것이므로 서버 측면과 클라이언트 측면으로 나누어 설명하고 그 후에 서버와 클라이언트를 통합해 기존의 방식과 설계/디자인패턴의 변화에 대해 다루겠습니다.

 3편이 남았네요.











댓글 없음:

댓글 쓰기