백엔드는 왜 태어났는가
1993년의 서버는 보관소였습니다. 사용자가 주소를 입력하면 미리 저장해 둔 HTML 파일을 꺼내 던져 주면 끝이었습니다. 그런데 방명록이 등장하면서 벽에 부딪힙니다. 방문자 A가 남긴 글을 방문자 B에게 보여 주려면 누가 언제 무슨 글을 남길지 미리 알아야 하는데, 그건 불가능합니다.
그래서 발상이 바뀌었습니다. 파일을 미리 만들지 말고 요청이 들어올 때 그 자리에서 만들자. 1993년 CGI가 그 첫 도구였고, 서버는 파일을 보관하는 역할에서 제조하는 역할로 바뀌었습니다. 이것이 서버 사이드 렌더링이고, 백엔드의 출생 신고입니다.
DB, MVC, API는 어떤 문제를 풀었는가
방명록 글을 보관할 곳이 필요했습니다. 처음에는 텍스트 파일에 한 줄씩 쌓았지만 수천 건이 되자 글 하나를 찾는 데 파일 전체를 읽어야 했습니다. 1995년 MySQL 같은 관계형 데이터베이스가 등장한 이유입니다.
기능이 늘면서 코드가 한 파일에 뒤섞이자 데이터(M), 화면(V), 교통정리(C)로 역할을 나누는 MVC 패턴이 나왔습니다. 그리고 2007년 아이폰이 등장합니다. 앱은 HTML이 아니라 데이터가 필요했고, HTML 제조자였던 서버는 JSON으로 데이터를 공급하는 API 서버로 다시 바뀝니다. 백엔드와 프론트엔드라는 직군이 명확히 갈라진 시점도 바로 여기입니다.
세션, 캐시, 트랜잭션은 왜 생겼는가
HTTP는 기억력이 없습니다. 로그인을 해도 다음 요청에서 서버는 그 사람을 알아보지 못합니다. 그래서 번호표를 발급하는 세션과 번호표를 브라우저에 보관하는 쿠키가 생겼고, 서버가 여러 대로 늘어나자 서명으로 위조를 검증하는 JWT가 나왔습니다. 비밀번호는 해싱을 거쳐 DB가 털려도 원본을 알 수 없는 형태로 저장합니다.
사용자가 늘어 서버가 느려지자 자주 찾는 데이터를 메모리에 올려 두는 캐시(레디스)가 생겼고, 계좌이체가 중간에 끊기면 안 되니 전부 성공 아니면 전부 취소라는 트랜잭션이 생겼습니다. 그래도 한계가 오면 서버를 키우는 대신 늘리는 수평 확장으로, 코드 덩어리가 너무 커지면 기능별로 쪼개는 마이크로서비스로 갑니다. 전부 문제 해결의 결과물입니다.
백엔드 언어는 무엇을 골라야 하는가
결론부터 말하면 뭘 골라도 됩니다. 로그인의 본질은 '아이디가 존재하고 비밀번호가 맞으면 통과', 조건문 두 개입니다. 파이썬은 if 뒤에 콜론이 붙고 자바는 중괄호가 생기는 정도의 문법 차이만 있을 뿐 구조는 완전히 같습니다. PHP, 파이썬, 자바, Go가 달라 보여도 결국 하는 일은 HTTP 요청을 받아 처리하고 응답을 돌려주는 것 하나입니다. 하나를 익히면 나머지는 방언 수준입니다.
비개발자가 이 계보를 알면 무엇이 달라지는가
AI에게 내리는 지시가 달라집니다. '로그인 만들어 줘'가 '인증은 JWT로 하고 비밀번호는 해싱해서 저장해 줘'로 바뀝니다. 흐름을 알면 AI가 만든 결과물에서 빠진 부분이 보이고, 지시가 구체적인 만큼 결과물의 품질이 올라갑니다. SH Consulting의 바이브 코딩 교육에서 백엔드를 역사 순서로 풀어내는 이유가 여기에 있습니다. 모든 기술은 어떤 문제를 풀려고 태어났고, 그 문제를 알면 기술을 외우는 게 아니라 이해하게 됩니다.