백엔드

웹 서비스를 만드는 일이 한 덩어리였던 시절이 있습니다. 화면 모양을 정하는 코드와 데이터를 꺼내 오는 코드가 같은 파일에 섞여 있었고, 한 사람이 위에서 아래로 훑어 내려가며 둘을 같이 고쳤습니다. 페이지가 스무 개쯤이던 시절에는 그 방식이 오히려 빨랐습니다.

서비스가 커지면서 이 방식이 막혔습니다. 무언가 잘못됐을 때 어디를 봐야 하는지가 정해져 있지 않았기 때문입니다. 페이지덱에서 민서가 회의록을 쓰고 저장 버튼을 눌렀는데, 다음 날 열어 보니 마지막 문단이 사라져 있었습니다. 원인을 묻자 답이 셋으로 갈렸습니다. 버튼이 아예 안 눌린 것인지, 눌렸지만 내용이 서버까지 가지 않은 것인지, 서버까지 갔는데 저장이 안 된 것인지. 셋 다 자기 자리에서는 재현이 되지 않았고, 그래서 사흘 동안 아무도 고치지 못했습니다.

그래서 만든 것을 사용자 기기에서 도는 쪽과 회사 서버에서 도는 쪽으로 갈랐습니다. 앞쪽이 프론트엔드로, 브라우저나 앱 안에서 사용자가 직접 보고 누르는 화면을 맡습니다. 뒤쪽이 백엔드입니다. 선을 한 번 긋고 나면 앞 장면의 질문이 한 문장으로 갈립니다. 버튼이 눌린 순간 회색으로 바뀌었는가는 앞쪽 몫이고, 그 내용이 진짜로 남아 다음 날에도 열리는가는 뒤쪽 몫입니다.

둘을 가른 이유는 일의 성격이 아예 달라서입니다. 화면은 한 사람 앞에 한 번 그려지고 마음에 안 들면 다시 그리면 그만이지만, 서버는 수천 명의 요청을 동시에 받고 한 번 잘못 저장된 값은 누가 되돌리기 전까지 그대로 남습니다. 결제 한 건이 두 번 청구된 사고는 화면을 새로 그려서 해결되지 않습니다. 남은 기록을 찾아내 한 건을 취소하고, 다시는 같은 일이 생기지 않도록 순서를 손봐야 끝납니다.

둘 사이를 잇는 창구는 API입니다. 프로그램끼리 무엇을 어떤 모양으로 주고받을지 미리 맞춰 둔 약속으로, 화면 쪽은 이 약속만 보고 일하면 되고 서버 안에서 무슨 일이 벌어지는지는 알 필요가 없습니다. 약속이 문서로 남아 있으면 두 쪽이 서로를 기다리지 않고 같은 주에 나란히 일할 수 있습니다.

백엔드 아래 묶인 용어는 요청 하나가 서버에 들어와 응답으로 나가기까지의 길을 따라 놓여 있습니다. 무엇으로 이루어져 있는가가 구성이고, 요청이 겹쳐 들어올 때 지켜야 할 성질이 원리이고, 그 성질이 깨졌을 때 나는 고장이 위험이고, 요청과 요청 사이에 무엇을 기억해 둘 것인가가 상태입니다. 네 갈래입니다.

구성은 서버 안을 층으로 가르는 갈래입니다. 여섯 가지가 있고, 앞의 셋은 요청이 들어온 그 자리에서 답을 만드는 쪽이고 뒤의 셋은 답을 내보낸 뒤에도 계속 도는 쪽입니다.

1. 서버 — 요청을 받아 처리하고 응답을 돌려주는 프로그램입니다. 사람이 안 볼 때도 꺼지지 않고 켜져 있다는 점이 노트북에서 잠깐 돌리는 프로그램과 다릅니다.
2. 비즈니스 로직 — 업무 규칙을 코드로 옮긴 부분입니다. "무료 플랜은 문서를 세 개까지만 만들 수 있다" 나 "결제가 실패하면 7일 동안은 읽기만 되고 8일째에 잠긴다" 같은 회사의 결정이 여기 들어앉습니다. 규칙이 화면에만 있고 여기 없으면 앱과 웹이 서로 다른 답을 냅니다.
3. 미들웨어 — 요청과 응답 사이에서 공통 처리를 맡는 층입니다. 로그인한 사람이 맞는지 확인하고, 누가 언제 무엇을 불렀는지 기록을 남기고, 한 사람이 1분에 백 번 넘게 부르면 잠시 막는 일이 전부 여기서 한 번에 처리됩니다. 기능마다 같은 코드를 스무 번 쓰지 않기 위한 자리입니다.
4. 백그라운드 작업 — 응답과 분리해 뒤에서 처리하는 작업입니다. 문서 300쪽을 PDF 로 내보내는 데 40초가 걸린다면, 그 40초 동안 사용자를 빈 화면 앞에 세워 두는 대신 "만들고 있습니다" 를 곧바로 돌려주고 다 되면 알려 줍니다.
5. 메시지 큐 — 작업을 줄 세워 비동기로 처리하게 하는 장치입니다. 뒤에서 돌릴 일이 한꺼번에 몰릴 때 순서대로 늘어놓고 처리 가능한 만큼씩 꺼내 씁니다. 월요일 아침 9시에 내보내기 요청이 500건 들어와도 서버가 넘어지지 않는 이유가 이것입니다.
6. 크론 잡 — 정해진 시각마다 자동 실행되는 작업입니다. 매일 새벽 3시에 어제 사용량을 집계하고, 매달 1일에 청구서를 만드는 식으로 사람 손 없이 도는 일이 여기 붙습니다.

원리는 요청이 겹쳐 들어와도 결과가 흔들리지 않게 하는 성질입니다. 동시성은 여러 작업을 겹쳐 진행하는 처리 방식으로, 한 요청이 데이터베이스 응답을 기다리는 동안 다른 요청을 처리해 두는 식입니다. 서버 한 대가 수천 명을 감당하는 것은 이 겹침 덕분이지만, 겹치는 순간 두 요청이 같은 값을 동시에 건드릴 수 있게 됩니다. 멱등성은 같은 요청을 여러 번 보내도 결과가 같은 성질입니다. 결제 버튼을 조급하게 세 번 누르거나 통신이 끊겨 앱이 자동으로 재시도했을 때, 청구가 세 번 되지 않고 한 번에서 멈추게 만드는 장치입니다.

위험은 그 겹침이 어긋났을 때 나는 고장입니다. 경쟁 상태는 동시에 실행된 작업의 순서에 따라 결과가 달라지는 문제입니다. 남은 좌석이 하나인 워크숍에 두 사람이 같은 순간에 신청하면, 둘 다 "남은 자리 1" 을 읽고 둘 다 신청을 넣어 좌석이 마이너스 1 이 됩니다. 이 고장이 고약한 이유는 열 번 시도해 한 번 날까 말까 하다는 데 있습니다. 재현이 안 되니 버그로 접수되지 않고, 대신 한 달에 한 번씩 정체 모를 환불 요청으로 돌아옵니다.

상태는 요청과 요청 사이에 서버가 무엇을 기억할지 정하는 갈래입니다. 세션은 서버가 사용자를 기억하기 위해 유지하는 상태로, 로그인을 한 번 하면 다음 요청부터 누구인지 다시 묻지 않게 해 줍니다. 무상태는 그 반대로 요청 사이에 아무것도 들고 있지 않는 설계입니다. 서버가 기억을 들고 있으면 서버를 두 대로 늘리는 순간 문제가 됩니다. 1번 서버에서 로그인한 사람의 다음 요청이 2번 서버로 가면 처음 보는 사람 취급을 받기 때문입니다. 그래서 기억은 서버 밖의 공용 저장소에 두고 서버 자체는 비워 두는 쪽으로 설계합니다.

네 갈래는 나란히 놓인 목록이 아니라 서로를 끌어당깁니다. 사용자가 늘면 동시에 들어오는 요청이 늘고, 그러면 경쟁 상태가 드러나고, 그것을 막으려면 멱등성을 갖춘 설계와 줄 세우는 장치가 필요해지고, 서버를 늘려 감당하려면 상태를 밖으로 빼야 합니다. 그리고 그 모든 판단의 재료는 데이터베이스에 남은 기록입니다.

"이건 백엔드 문제 같아요. 화면에는 저장됐다고 떴는데 서버에는 안 남았어요."

증상이 화면에서 보인다고 원인이 화면 쪽인 것은 아니라는 말이고, 담당과 확인 순서를 넘기는 신호입니다.

"그 계산은 백엔드로 옮깁시다. 화면마다 따로 계산하면 앱이랑 웹이 다른 값을 보여 줘요."

같은 규칙을 여러 화면이 각자 구현하면 언젠가 어긋나니 한 곳에서만 계산하자는 제안입니다.

"이번 스프린트는 백엔드 작업이라 보여 드릴 화면이 없습니다. 창구 먼저 열고 다음 주에 붙입니다."

눈에 보이는 결과물이 없는 주기라는 사전 공지이고, 진척을 화면으로만 재지 말아 달라는 요청이기도 합니다.

페이지덱에서 이 영역은 태오가 맡습니다. 새 기능이 잡히면 태오가 가장 먼저 하는 일은 코드를 쓰는 것이 아니라 주고받을 값의 모양을 정해 문서로 올리는 것입니다. 문서 공유 기능이라면 누구에게 무엇을 보낼 때 어떤 값이 오가고 권한이 없으면 무엇이 돌아오는지를 적습니다. 그 문서가 올라온 날부터 민서는 화면을 만들고 태오는 서버를 만듭니다.

기능이 나간 뒤에도 태오의 일은 남습니다. 지현이 "저장이 가끔 안 된다는 문의가 이번 주에 네 건 들어왔다" 고 전해 오면 태오는 어느 요청이 실패했는지 기록에서 찾습니다. 넷 중 셋은 같은 시각에 몰려 있었고, 한 사람이 문서를 여는 동안 다른 사람이 같은 문서를 지운 경우였습니다. 화면만 보고는 절대 알 수 없고, 서버에 남은 기록을 시간순으로 늘어놓아야 보입니다.

규원이 이 영역에 대해 묻는 것은 보통 둘입니다. 사용자가 지금의 열 배로 늘면 서버 비용이 얼마가 되는지, 그리고 지금 구조로 그 열 배를 받을 수 있는지입니다.

백엔드는 화면이 없으니 사용자 경험과 상관없다고 여기는 오해가 가장 흔합니다. 사용자가 보는 것이 전부 화면이니 그렇게 보일 만합니다. 하지만 사용자가 느끼는 느림의 상당 부분은 서버가 답을 만드는 시간입니다. 문서 목록을 여는 데 0.3초가 걸리던 것이 2초로 늘면 화면 코드는 한 줄도 바뀌지 않았는데 사람들은 앱이 굼떠졌다고 말합니다. 이 오해를 그대로 두면 팀은 화면 애니메이션을 다듬는 데 2주를 쓰고 체감은 그대로인 결과를 받습니다.

백엔드를 데이터를 넣고 꺼내는 단순 작업으로 보는 오해도 자주 나옵니다. 기능 하나를 놓고 보면 실제로 그렇게 보입니다. 값을 받아 저장하고, 요청이 오면 꺼내서 돌려주는 일이니까요. 어려움은 그 일이 한 번이 아니라 동시에 수천 번 일어나고, 중간에 네트워크가 끊기고, 같은 요청이 두 번 들어오는 데서 생깁니다. 한 사람이 쓸 때는 멀쩡하던 코드가 동시에 백 명이 쓰는 순간 중복 청구와 사라진 문서를 만들어 냅니다. 이 오해를 붙들고 있으면 일정 산정이 계속 어긋납니다. 사흘이면 된다고 본 기능이 삼 주가 되는데, 늘어난 시간은 기능을 만드는 데 쓰인 것이 아니라 겹쳐 들어올 때를 막는 데 쓰입니다.