백엔드 개발자

웹 서비스를 만드는 일이 한 사람 몫이던 시절이 있었습니다. 화면도 짜고 서버도 올리고 데이터도 직접 넣었습니다. 서비스가 작을 때는 이 방식이 빨랐습니다. 버튼 하나와 그 버튼이 부를 주소를 한 사람이 만드니 회의할 일이 없었습니다.

이 방식은 사용자가 늘면 버티지 못합니다. 열 명이 쓰던 서비스에 만 명이 들어오면 문제의 성격이 갈립니다. 화면 쪽에는 브라우저마다 다르게 보이는 문제와 첫 화면이 3초씩 걸리는 문제가 쌓이고, 서버 쪽에는 같은 순간에 들어온 요청 둘이 같은 값을 건드려 숫자가 어긋나는 문제와 새벽에 서버가 멈추는 문제가 쌓입니다. 고치는 방법도 확인하는 방법도 다릅니다.

한 사람이 둘을 함께 지면 급한 쪽이 사람을 데려갑니다. 페이지덱에서도 태오가 화면과 서버를 함께 맡던 시기에는 장애 알림이 뜨는 날마다 그 주에 나가기로 한 화면 작업이 다음 주로 밀렸습니다. 그래서 만드는 자리를 둘로 갈랐습니다. 프론트엔드 개발자가 사용자가 보고 누르는 쪽을, 백엔드 개발자가 그 뒤에서 데이터를 꺼내고 규칙을 따지는 쪽을 맡습니다.

하루의 절반쯤은 새 기능을 만들고 나머지 절반은 이미 돌아가는 것을 고치고 지키는 데 씁니다. 순서대로는 대개 이렇습니다.

1. 지난밤 확인 — 밤사이 쌓인 오류 기록과 응답 속도를 먼저 봅니다. 새벽 3시에 오류가 200건 났는데 아무도 문의하지 않았다면, 사용자가 눈치채지 못한 채 데이터가 어긋나고 있다는 뜻이라 더 급합니다.
2. 설계 — 새 기능의 요구사항을 데이터 모양으로 옮깁니다. "문서에 댓글을 달 수 있게 하자" 는 문장을 받으면, 댓글을 어느 표에 어떤 항목으로 저장할지, 문서가 지워지면 댓글은 어떻게 할지를 먼저 정합니다.
3. 창구 합의 — 화면 쪽이 무엇을 어떤 모양으로 받을지를 API로 정해 둡니다. 프로그램끼리 주고받기로 미리 맞춰 둔 약속입니다. 문서로 먼저 나오면 두 쪽이 서로를 기다리지 않고 동시에 일합니다.
4. 구현 — 정한 대로 코드를 씁니다. 대부분의 시간은 데이터베이스에서 필요한 것만 빠르게 꺼내 오는 일과, 잘못된 요청이 들어왔을 때 무엇을 돌려줄지 정하는 일에 들어갑니다.
5. 리뷰와 배포 — 코드 리뷰로 동료의 확인을 받고, CI/CD가 자동으로 검사한 뒤 서버에 올립니다.
6. 대응 — 그사이에 들어오는 장애와 문의를 처리합니다. 이 항목만 계획에 넣지 못해서, 주기마다 실제로 쓸 수 있는 시간이 예상보다 짧아집니다.

여섯 가지를 관통하는 기준은 하나입니다. 지금 맞게 도는지가 아니라 사용자가 열 배로 늘어도 맞게 도는지입니다. 목록을 한 번에 다 꺼내 오는 코드는 데이터가 100건일 때 잘 돌고 100만 건이 되는 날 서비스를 세웁니다.

매일 말을 섞는 상대는 대여섯 자리로 정해져 있습니다.

프론트엔드 개발자와는 창구를 두고 매일 맞춥니다. 응답에 항목 하나를 더할지, 목록을 몇 개씩 끊어 줄지가 화면의 모양을 바꾸기 때문에, 한쪽이 혼자 정하면 다른 쪽 작업이 통째로 다시 갑니다.

프로덕트 매니저와는 값을 두고 이야기합니다. 지현이 기능을 설명하면 태오는 그것이 데이터 구조를 건드리는지 알려 줍니다. 겉보기에 비슷한 요구 둘 중 하나는 하루, 하나는 3주가 되는 일이 흔해서 우선순위가 여기서 갈립니다.

데브옵스 엔지니어·SRE와는 경계를 나눠 집니다. 코드가 돌아갈 서버와 배포 과정은 그쪽이, 그 위에서 도는 코드는 이쪽이 맡습니다. 느려졌을 때 원인이 코드인지 서버인지는 둘이 같이 봐야 알아서, 장애 때는 늘 한자리에 모입니다. 구성원이 적은 회사에는 이 자리가 따로 없어 백엔드 개발자가 그 일까지 나눠 집니다.

데이터 엔지니어와는 기록을 두고 맞춥니다. 나중에 세고 싶은 것이 있으면 그 순간에 남겨 둔 기록이 있어야 해서, 기능을 만들 때 무엇을 남길지 미리 정합니다. QA 엔지니어와는 깨지는 경우를 두고 맞춥니다. 정상 경로보다 이상한 입력이 들어왔을 때가 주로 쟁점입니다.

"그건 화면만 바꾸면 되는 게 아니라 백엔드도 같이 가야 해요. 저장하는 구조를 바꿔야 합니다."

작아 보이는 요구가 실제로는 큰 작업이라는 신호입니다.

"응답 형태만 먼저 주세요. 그동안 화면은 가짜 데이터로 붙여 놓을게요."

두 쪽이 순서대로 일하지 않고 동시에 가기 위한 합의입니다.

"이번 주는 백엔드 개발자 두 명 중 한 명이 장애 당번이라 담을 수 있는 게 줄어요."

사람 수가 그대로여도 계획에 넣을 수 있는 양은 줄어든다는 말입니다.

페이지덱에서 문서 공유 링크에 만료 기한을 붙이자는 요구가 올라온 적이 있습니다. 민서가 그린 화면은 날짜를 고르는 칸 하나였고, 지현은 이번 주에 되는 일로 봤습니다. 태오가 본 것은 다른 층이었습니다. 이미 나가 있는 링크 40만 개에는 기한 항목이 없어 전부 채워 넣어야 했고, 만료된 링크로 들어온 요청을 거절하는 판단은 화면이 아니라 서버에 있어야 했습니다. 주소를 직접 입력하면 화면의 검사는 아무 소용이 없기 때문입니다.

결과는 화면 하루, 서버 이레였습니다. 이 차이가 보이지 않는 자리에서 일정이 자주 어긋납니다.

사용자를 만나지 않으니 사용자 경험과는 먼 자리라는 오해가 가장 흔합니다. 눈에 보이는 것을 만들지 않으니 그렇게 보입니다. 하지만 사용자가 겪는 불편의 상당수는 서버 쪽에서 정해집니다. 목록이 뜨는 데 걸리는 4초, 결제 버튼을 두 번 눌렀을 때 두 번 청구되는 사고가 전부 여기서 갈립니다. 이 자리를 화면과 무관하게 두면 디자인은 깔끔한데 쓰기 답답한 제품이 나옵니다.

언어와 도구를 아는 것이 곧 실력이라는 오해도 흔합니다. 채용 공고에 언어 이름이 먼저 적혀 있으니 그렇게 보입니다. 실제로 갈리는 지점은 무엇을 어디에 저장할지 정하는 판단입니다. 처음에 잘못 잡은 데이터 구조는 나중에 코드를 아무리 잘 써도 덮이지 않고, 고치려면 이미 쌓인 데이터를 전부 옮겨야 해서 값이 몇 배로 뜁니다. 도구는 반년이면 익히고 이 판단은 몇 번의 실패로 익힙니다.