서버

프로그램이 한 사람의 컴퓨터 안에서만 돌던 시절에는 여러 사람이 같은 데이터를 함께 다룰 방법이 파일을 주고받는 것뿐이었습니다. 회의록을 정리해 메일로 보내면 받은 사람이 고쳐서 다시 보내고, 그 사이에 원본을 고친 사람이 또 있습니다. 며칠 지나면 같은 문서의 버전이 다섯 개가 되고, 어느 것이 최신인지 아무도 확신하지 못합니다.

규칙도 함께 흩어졌습니다. 무료 사용자는 문서를 세 개까지만 만들 수 있다는 회사의 결정이 각자의 프로그램 안에 복사되어 있으면, 그 결정을 바꿀 때 모든 사람의 컴퓨터를 찾아가야 합니다.

그래서 데이터와 규칙을 한 곳에 두고 모두가 그곳에 물어보게 만드는 프로그램이 자리를 잡았습니다. 이 프로그램이 지켜야 하는 조건 하나가 나머지를 다 정합니다. 언제 요청이 오든 받을 수 있어야 하므로 꺼지지 않고 켜져 있어야 한다는 것입니다. 노트북에서 필요할 때 실행하고 닫는 프로그램과 갈리는 지점이 여기입니다.

실제로 푸는 것은 넷입니다.

1. 진실을 한 벌로 만듭니다. 문서의 최신 내용과 누가 어디까지 볼 수 있는지가 한 곳에만 있고, 웹과 앱과 외부 연동이 모두 그곳에 물어봅니다. 무료 플랜 제한을 세 개에서 다섯 개로 바꾸는 일이 한 번의 배포로 끝나는 이유가 이것입니다.
2. 항상 받습니다. 새벽 3시에 들어온 요청도 처리되고, 사용자가 화면을 닫은 뒤에 끝나야 하는 일도 계속 돕니다. 이 조건 때문에 운영이라는 일이 따로 생깁니다.
3. 판정을 밖에 맡기지 않습니다. 이 사람이 이 문서를 볼 수 있는지는 서버가 정합니다. 화면 쪽 코드에 맡기면 그 코드를 우회하는 사람에게는 판정이 없는 것과 같습니다.
4. 무거운 일을 대신합니다. 문서 300쪽을 PDF 로 만들거나 계정 500개의 사용량을 집계하는 일은 사용자 기기에서 하기 어렵습니다.

요청 하나가 지나가는 길은 대체로 정해져 있습니다.

1. 요청을 받습니다.
2. 공통 처리를 거칩니다. 로그인한 사람이 맞는지 확인하고 기록을 남기고 호출이 너무 잦으면 잠시 막는 일을 한자리에서 하는 층을 미들웨어라고 합니다.
3. 규칙을 적용합니다. 회사의 결정을 코드로 옮긴 부분이 비즈니스 로직입니다.
4. 저장된 값을 읽거나 씁니다. 값이 실제로 남는 곳은 데이터베이스입니다.
5. 응답을 돌려줍니다.

응답을 보낸 뒤에도 끝나지 않는 일이 있습니다. 40초 걸리는 내보내기를 응답과 떼어 뒤에서 처리하는 것이 백그라운드 작업이고, 그런 일이 한꺼번에 몰릴 때 줄을 세우는 장치가 메시지 큐입니다.

한 가지 설계 규칙이 처음부터 붙습니다. 요청과 요청 사이에 서버가 무엇을 기억하고 있으면 서버를 두 대로 늘리는 순간 깨집니다. 1번에서 로그인한 사람의 다음 요청이 2번으로 가면 처음 보는 사람이 되기 때문입니다. 그래서 기억은 서버 밖 공용 저장소에 두고 서버 자체는 비워 둡니다.

같은 문제를 다르게 푸는 방법이 넷 있습니다.

1. 함수만 올려 두는 방식입니다. 서버를 계속 켜 두는 대신 요청이 올 때만 코드가 실행되는 서버리스가 여기입니다. 쓴 만큼만 돈을 내고 켜 두는 일 자체가 없어지는 대신, 한동안 호출이 없다가 들어온 첫 요청은 준비 시간을 기다립니다.
2. 관리형 백엔드를 빌려 쓰는 방식입니다. 로그인과 저장소와 기본 조회를 남이 만들어 둔 서비스로 대신합니다. 처음 만들 때 가장 빠르지만, 규칙이 복잡해지면 그 서비스가 허용하는 범위 안에서만 표현해야 해서 어느 시점에 직접 만드는 쪽으로 돌아옵니다.
3. 규칙을 화면 쪽에 두고 저장소만 쓰는 방식입니다. 만드는 속도는 가장 빠릅니다. 대신 규칙이 사용자 기기 안에 있어서 우회가 가능하고, 웹과 앱에 같은 규칙을 두 번 구현하게 됩니다.
4. 각 기기가 데이터를 들고 있다가 서로 맞추는 방식입니다. 비행기 안에서도 편집이 되는 것이 장점이고, 두 사람이 같은 문단을 동시에 고쳤을 때 무엇을 남길지 정하는 문제가 따라옵니다.

고르는 기준은 셋입니다. 규칙이 얼마나 복잡한지, 요청이 꾸준히 들어오는지 특정 시각에 몰리는지, 운영할 사람이 있는지입니다. 요청이 하루에 몇 건뿐이면 계속 켜 두는 쪽이 낭비이고, 반대로 꾸준히 많으면 켜 두는 쪽이 싸집니다.

"이 규칙은 화면이 아니라 서버에 두는 게 맞습니다. 앱이랑 답이 달라져요."

판정 위치를 옮기자는 지적입니다.

"서버가 세션을 들고 있어서 두 대로 못 늘립니다."

상태를 밖으로 빼야 증설이 된다는 말입니다.

"새벽에 서버가 한 번 죽었는데 아무도 몰랐습니다. 알림 먼저 붙이죠."

켜져 있어야 하는 조건이 곧 운영 부담이라는 보고입니다.

페이지덱이 서버를 두 대로 늘리려던 주에 이 문제를 만났습니다. 접속이 몰리는 월요일 오전에 응답이 느려져서 태오가 서버를 늘렸는데, 늘린 뒤부터 로그인이 무작위로 풀렸습니다. 로그인 정보를 서버가 자기 안에 들고 있었기 때문입니다.

공용 저장소로 옮기는 작업에 사흘이 들었습니다. 그 뒤로는 서버 대수를 늘리는 일이 설정 한 줄이 됐고, 월요일 오전에만 자동으로 늘렸다 줄이는 방식으로 바꿨습니다. 처음부터 비워 두고 만들면 사흘이 들지 않는 일이었습니다.

서버를 기계로 읽는 경우가 가장 많습니다. 서버실에 놓인 상자가 떠오르니 자연스러운 오해입니다. 하지만 이 말이 가리키는 것은 프로그램입니다. 한 대의 컴퓨터에서 서버 프로그램 세 개가 동시에 돌 수 있고, 반대로 같은 서버 프로그램이 컴퓨터 열 대에 복사되어 돌 수도 있습니다. 기계로 읽으면 대수를 늘리는 것만 증설로 보이고, 같은 기계에서 프로그램을 여러 벌 띄우는 방법이 눈에 들어오지 않습니다.

서버를 늘리면 느린 것이 해결된다고 보는 것도 흔합니다. 실제로 그럴 때가 있으니 첫 시도로 자주 나옵니다. 하지만 서버가 상태를 들고 있으면 늘리는 순간 로그인이 풀리고, 느린 원인이 데이터베이스 쪽이면 서버를 열 대로 늘려도 같은 저장소 앞에 줄이 열 줄로 늘어날 뿐입니다. 늘리기 전에 어디가 막혀 있는지를 재는 일이 앞에 옵니다.