Insights·2026-06-11

백엔드란 무엇인가: 1993년 방명록에서 시작된 문제 해결의 계보

백엔드는 서버가 요청을 받아 데이터를 처리하고 결과를 돌려주는 영역으로, 1993년 방명록 문제를 풀다가 태어났습니다. 미리 만들어 둔 HTML 파일로는 방금 방문자가 남긴 글을 다음 사람에게 보여 줄 수 없어서, 서버가 요청이 올 때마다 그 자리에서 화면을 새로 조립하기 시작한 것이 출발점입니다. 이후 30년의 발전사도 같은 패턴의 반복이며, 이 계보를 알면 비개발자도 AI에게 백엔드를 구체적으로 지시할 수 있게 됩니다.

백엔드는 어떻게 태어났는가

백엔드라는 단어 앞에서 비개발자는 흔히 멈칫합니다. 그런데 출발점을 보면 1993년 방명록입니다. 그때의 서버는 보관소였습니다. 사용자가 주소를 입력하면 미리 저장해 둔 HTML 파일을 꺼내 던져 주면 끝이었죠. 그런데 방명록이 등장하면서 벽에 부딪힙니다. 방금 방문자가 남긴 글을 다음 사람에게 보여 주려면 누가 언제 무슨 글을 남길지 미리 알고 파일을 만들어 둬야 하는데, 그건 불가능합니다.

그래서 발상을 뒤집습니다. 파일을 미리 만들지 말고, 요청이 들어올 때 그 자리에서 화면을 새로 조립하자. 서버는 파일을 보관하는 역할에서 요청마다 결과를 제조하는 역할로 바뀌었고, 백엔드는 바로 여기서 태어났습니다.

이후 30년도 같은 패턴이었다

이후의 역사도 같은 패턴의 반복입니다. 글을 보관할 곳이 필요해 데이터베이스가 나왔습니다. 처음에는 텍스트 파일에 한 줄씩 쌓았지만, 수천 건이 되자 글 하나를 찾는 데 파일 전체를 읽어야 했기 때문입니다. 기능이 늘며 코드가 한 파일에 뒤엉키자 데이터와 화면과 교통정리를 분리하는 MVC로 정리했고, 2007년 아이폰이 등장하자 앱은 HTML이 아니라 데이터를 원했습니다. HTML을 만들어 내던 서버는 JSON으로 데이터를 공급하는 API 서버로 다시 역할을 바꿉니다.

나머지 조각들도 전부 특정 문제의 답입니다. HTTP는 기억력이 없어 로그인을 해도 다음 요청에서 서버가 그 사람을 알아보지 못합니다. 그래서 번호표를 발급하는 세션과 그 번호표를 브라우저에 보관하는 쿠키가 생겼습니다. 사용자가 늘어 서버가 느려지자 자주 찾는 데이터를 메모리에 올려 두는 캐시가, 계좌이체가 중간에 끊기면 안 되니 전부 성공 아니면 전부 취소라는 트랜잭션이 생겼습니다. 외울 목록이 아니라, 각 기술이 어떤 문제를 풀려고 태어났는지 흐름으로 이해하면 되는 이유입니다.

언어보다 지시의 구체성이 결과를 가른다

언어 선택부터 막막해할 필요도 없습니다. PHP든 파이썬이든 자바든, 로그인의 본질은 '아이디가 존재하고 비밀번호가 맞으면 통과', 조건문 두 개입니다. 파이썬은 if 뒤에 콜론이 붙고 자바는 중괄호가 생기는 정도의 문법 차이만 있을 뿐, HTTP 요청을 받아 처리하고 응답을 돌려준다는 구조는 완전히 같습니다. 하나를 익히면 나머지는 방언 수준입니다.

그래서 결과물을 가르는 건 어떤 언어를 고르느냐가 아니라 얼마나 구체적으로 지시하느냐입니다. 계보로 흐름이 잡히면 '로그인 만들어 줘'가 '인증은 JWT로 하고 비밀번호는 해싱해서 저장해 줘'로 바뀝니다. 지시가 구체적인 만큼 결과물이 달라지고, 흐름을 알면 AI가 짜 준 코드에서 빠진 부분까지 눈에 들어옵니다.

비개발자는 무엇부터 배워야 하는가

비개발자가 AI에게 백엔드를 맡길 때 정말 필요한 건 문법 암기가 아니라 이 계보입니다. 모든 기술은 앞 기술이 남긴 문제를 풀려고 태어났고, 그 문제를 알면 기술을 외우는 대신 이해하게 됩니다. SH Consulting의 바이브 코딩 교육이 백엔드를 역사 순서로 풀어내는 이유가 여기에 있습니다. 계보가 손에 잡히는 순간, 같은 AI를 써도 시킬 수 있는 일의 수준이 함께 올라갑니다.