대학에서 공부를 하는 것은 대부분 이론이다. 실무를 가르치는 곳이 있을까 모르겠으나, 적어도 내가 있는 환경은 그렇지 않았다. 그나마 코딩을 한다고 해봐야 알고리즘이 고작이고 나머지는 스스로 해야 경험해야 할 텐데, 막상 개발에 들어가게 되면 배운 적 없는 것들만 가득하니 당황할 수 밖에 없었다. 그래서 나는 많은 삽질을 해야 했다. 그렇게 개발을 다 마치고 나서야, "아, 이걸 먼저 배웠으면 나머지 것들을 배우는 데에 도움이 됐을 텐데." 하고 아쉬워 한 것들이 너무도 많았다.
그래서 글을 작성한다. 선배 개발자 분들이 보기엔 너무 쉬운 내용이겠으나, 나보다 경험이 적은 개발자, 또는 나처럼 복수전공, 부전공으로 개발을 시작해 아직 배경 지식이 없는 사람들에게 도움이 되기를 바란다.
서버란 뭘까?
사실 서버라는 것은 어떤 요청이 왔을 때 응답해주는 기기를 말한다. 그러다보니 우리는 그 기기를 서버라고 하기도 하고, 그 기기에서 동작하는 소프트웨어를 서버라고 하기도 한다. 또 이 서버를 말할 때도 내 노트북에서 돌아가는 서버를 개발 서버라고 한다거나, 24시간 배포된 서버를 배포 서버라고 하는 등 하드웨어에 따라 구분하여 말하기도 한다. 그래서 배우는 사람들에게 서버는 매우 복잡한 무언가로 인식하게 만드는 것 같다.
그러니 일단 서버를 24시간 편의점 정도로 생각해보면 어떨까?
앞서 말한 것처럼 우리 노트북도 서버의 역할을 충분히 수행할 수는 있다. 그렇지만 24시간이고 몇 달, 몇 년이고 동일한 프로그램을 돌리고 있을 수는 없잖은가. 그러다보니 aws나 ncp에서 서버를 대여하기도 한다. 흔치 않을 거라고 생각되지만, 나처럼 라즈베리파이라고 해서 소형 전자기기 위에 서버를 올려놓는 경우도 있을 것이다. 우리가 노트북에 올려놓았을 서버는 특정 시간이 되면 문을 닫는 슈퍼에 불과하지만, 이런 데에 서버를 올려놓으면 24시간 편의점으로 둔갑할 수 있다. 요약하자면 서버란 24시간 돌아갈 뿐인 컴퓨터라고 할 수 있겠다.
HTTP, 트랜잭션은 뭐고?
당장은 서버에 대해 이 정도만 알아두고 넘어가도 좋겠다. 나를 혼란스럽게 한, 서버 사이드 렌더링, 클라이언트 사이드 렌더링처럼 서버와 클라이언트를 구분하는 내용은 일단 무시하자. 서버가 24시간 돌아가는 편의점이라고 치면, 이제 우리는 물건을 사는 법을 알아야 한다. 이런 규칙, 방법 따위를 보통 프로토콜 이라는 이름으로 부르곤 하는데, 이번에 알아야 할 것이 바로 이 HTTP 프로토콜이다.
const server = http.createServer(app);
server.listen(port, () => {
server.on('error', onError);
server.on('listening', onListening);
});코드를 가지고 설명하면 이렇다. 개발자가 보통 만드는 영역이, 위에서 app 이라고 친다면, 그 app을 사용하는 것이 HTTP 라고 할 수 있겠다. 마치 편의점이 만들어졌으면 그걸 사용하는 규칙이 있듯이. 이번에는 편의점 말고 다른 것으로 예를 들어보자. 우리가 카카오톡을 한다고 가정해보자. 보통은 그렇지 않지만(...) 우리가 카카오톡 메시지를 보내면 상대방이 반드시 응답해야 한다는 규칙이 있다고 해보자. 이름을 짓자면 이를 심심이 프로토콜 이라고 할 수 있겠다.
나 : 뭐하고 있어? 친구 : 답장. 나 : ( ... )
이 때, 먼저 말을 한 것을 요청(Request)이라고 하고, 그에 대한 대답을 응답(Response) 이라고 한다. 또 이 둘을 합쳐서 트랜잭션(Transaction) 위에도 요청과 응답을 모두 충족하고 있다. 서버는 이런 HTTP 프로토콜을 따라야 한다. 그렇다면 서버를 개발한다는 것은, 위의 대화를 조금 더 성의있게 만드는 일인 셈이다. 대화를 저런 식으로 한다면 인간관계가 잘 굴러갈 리가 없을 테니.
HTTP 메서드란?
import express from 'express';
import controller from '../controllers/issues.js';
const router = express.Router();
router
.route('/') // 여기서의 경로는 '/issues' 이다.
.get(controller.get)
.post(ccontroller.post)
.put(controller.put)
.delete(controller.delete);
export default router;위 코드는 router를 통해서 해당 경로에 get, post, put, delete 라는 메서드들에 맞게, 내가 임의로 만든 함수들을 가리키게 하고 있다. get 요청이 들어오면 controller의 get 함수를 사용하여 처리하고, post 요청이 들어오면 controller의 post 요청을 사용해 처리하게 하는 식이다. put이나 delete도 마찬가지다. 사이트를 만들게 되면 가장 기본적으로 필요한 메서드(method)가 저 4가지인데, CRUD ( create, read, update, delete ) 라고 부르기도 한다.
get은 read에 해당하고, post가 create, put이 update고 delete는 delete다.
HTTP에는 이 4가지를 제외하고도 많은 메서드들이 있고, 이것들을 통해서 사용자의 요청에 응답할 수 있는데, 사실 get 요청의 함수에 controller의 post나 delete처럼 다른 것을 넣을 수도 있다. 그렇지만 그건 꽤 부자연스러운 일일 것이다.
사용자 : 내가 issues에 get 요청을 보내면 issues를 주겠지? 사용자 : 내가 issues에 post 요청을 보내면 새 issues를 만들어주겠지? 사용자 : 내가 issues에 put 요청을 보내면 issues를 수정해주겠지? 사용자 : 내가 issues에 delete 요청을 보내면 issues를 삭제해주겠지?
개발을 하기에 앞서 이 단어 ( method )를 사용하는 건 이미 암묵적인 약속이나 다름없다.
물론 저 암묵적인 약속을 무시할 수는 있다. 모든 것을 post로 하되, 함수들만 바꿔주는 것이 그 예시가 될 것이다. post로 get 함수를 부르고, post로 put이나 delete에 해당하는 함수들을 호출하면, 사실 동일한 동작을 기대할 수는 있다. 그렇지만 함부로 약속을 깨버리면 사용자에게 혼란을 줄 수 있다.
사용자 : 데이터 조회를 추가해줘. 사용자 : 데이터 삭제를 추가해줘. 사용자 : 데이터 수정을 추가해줘.
못알아 먹을 것은 아니지만, 이런 식으로 대화하는 것과 다를 바 없다.
RESTful API
API (Application Programming Interface), 어플리케이션 프로그래밍 인터페이스는, 쉽게 말하면 기능을 사용하기 위한 인터페이스라고 할 수 있겠다. 비유하자면 자판기의 버튼일까.
API는 Server에서만 쓰이는 말은 아니다, 모바일에서 화면을 터치해서 사용하는 버튼들도, 예전 스마트폰에 있던 홈 버튼도, 사용자가 직관적으로 사용할 수 있는 모든 인터페이스를 일컫는 말이기도 하다. 서버 역시 HTTP 프로토콜을 따르는 한, 내부의 모든 처리는 요청과 응답으로 이루어진다.
서버 개발자들이 설계하는 것 역시 API를 설계한다고 할 수 있겠다. 서버 개발자들은 이런 약속을 지키고자 노력(?)을 하는데, 이 때 약속을 충실히 이행한 설계를 우리는, RESTful API 라고 한다.
다시 묻자, 이런 설계를 지키면 어떤 점이 좋을까?
일단 위 예시에 이어서 말하면, 서로 알아듣기 편하다는 게 장점일 것이다. 사용자가 모든 것을 post 요청으로만 설명하거나, 또는 서버가 그렇게 하게끔 강제하는 것보다는, 미리 약속된 것들을 토대로 대화하는 것이 훨씬 더 대화가 용이할 것이 분명하다. 그러면 또 다른 장점은 뭐가 있을까?
클라이언트와 서버의 대화
클라이언트 : 데이터 좀 줘 서버 : 어디다 쓸 건데? 클라이언트 : 아, 그냥 알아서 잘 쓸 거니까 좀 줘!
자녀와 부모의 대화
자녀 : 용돈 좀 줘 부모 : 어디다 쓸 건데? 자녀 : 아, 그냥 알아서 잘 쓸 거니까 좀 줘!
나는 RESTful한 API라는 것을 이러한 의미로 생각한다. 첫째로, 설계 내용물을 몰라도, 클라이언트가 어떠한 것을 돌려받을 거라는 믿음이 성사될 수 있다는 점이다. 마치 자판기 버튼을 누르면 음료수가 나올 거라는 믿음과 같다.
당연한 것처럼 보이겠지만, 인터페이스가 분리되지 않았을 무렵, 또는 이러한 약속들이 없고 각 서버나 클라이언트마다 자체적인 패턴을 적용했을 무렵의 웹은 난장판이었다고 한다. RESTful API는, HTTP 표준을 따르는 사람이면 어떤 서버나 웹 사이트, 클라이언트 등 환경에 대한 걱정 없이 설계를 할 수 있게 만들어 준다. 개발자들의 수고를 덜어준 셈이다.
아래의 비유를 보자, 만약 삼촌에 RESTful한 사람이라면, 부모님과 동일한 응답을 기대해볼 수 있겠다.
자녀 : (부모님 대신에 삼촌에게 용돈 달라고 하면 주지 않을까...?)
둘째로, 앞서 이미 말한 것과 같이 서버 개발자의 수고가 줄어든다. 즉 설계가 단순해진다. 요청에 따라 주기만 하면 된다. 정말로 위험한 거라면 그냥 안 주면 되는 거 아닌가?
자녀 : 통장 좀 줘 부모 : 그걸 왜 달라는 건데! (이런 과도한 부탁은 들어주지 않는다. 들어주는 부모가 있다면...)
클라이언트를 믿지 못하는 서버는, 클라이언트가 무언가를 달라고 할 때마다, 그것이 잘못 쓰일 경우를 대비한 온갖 예외와 오류를 대비할 수 있어야 한다. 그러나 RESTful한 API는 그런 고민이 없다. 정말로 위험한 것은 애초에 줄 생각이 없을 뿐더러, 주고 난 후의 일은 클라이언트의 책임으로 물으면 된다. 말하자면 정말로, 알아서 잘 쓸 것이라고 믿는 것이다. 아래처럼 대화해야 한다면 부모 ( 서버 ) 입장에서도 힘들지 않겠는가.
자녀 : 용돈 좀 줘! 부모 : 언제, 어디서, 무엇을, 어떻게, 누구와, 왜 쓸 건데?
이는 결과적으로, 서버와 클라이언트를 분리할 수 있게 해준다.
부모 : ( 나는 달라는 대로 줬으니깐, 나머지는 애가 알아서 하겠지. )
2021.03.03
서버와 클라이언트를 분리한다는 게, 서버 측의 책임을 없앤다는 것은 아니다.
오히려 사용자에게 메서드가 어떤 용도로 사용되는지를 암시해주고, 일반적으로 안전한 메서드라 생각되는 것으로 인해 문제가 발생한 경우, 책임 소지는 서버 측이 가지는 게 맞다.
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
