웹 개발의 전체 흐름

웹을 공부하다 보면 지식이 끝없이 쪼개진다. 렌더링, 상태관리, 인증, 데이터베이스, 배포… 하나씩 익히다 보면 정작 "이게 전체 그림의 어느 조각인지"를 잊어버리기 쉽다.

이 글은 개별 기술을 설명하지 않는다. 대신 웹을 만들고 운영하는 일이 결국 어떤 문제들을 푸는 일인지를, 데이터가 흐르는 순서대로 짚는다. 각 문제를 깊이 파는 건 해당 폴더의 몫이고, 여기서는 "무슨 문제를, 왜 풀어야 하는지"까지만 잡는다. 공부하다 길을 잃으면 여기로 돌아와, 지금 내가 어느 문제 앞에 서 있는지 확인하면 된다.

웹은 결국 무슨 일을 하는가

웹은 한 줄로 말하면, 멀리 떨어진 수많은 사람에게 데이터를 화면으로 보여주고, 그들이 화면에서 한 행동을 받아 데이터를 안전하게 바꾸는 일이다.

블로그에 댓글 하나 다는 장면을 떠올려 보자. 누군가 글을 열면 서버 어딘가에 저장돼 있던 댓글 목록이 그의 화면에 그려진다. 그가 입력창에 글을 쓰고 버튼을 누르면, 그 내용이 경계를 넘어 서버로 가서 검증을 거쳐 저장되고, 다음 사람에게도 보인다. 이 사소해 보이는 왕복 안에 웹 개발의 거의 모든 문제가 들어 있다. 이 글은 그 왕복을 따라가며 만나는 문제들을 하나씩 펼친다.

같은 문제를 더 잘 풀려는 시도였다 — 짧은 역사

이 문제들이 처음부터 다 보였던 건 아니다. 웹의 역사는 같은 근본 문제(보여주고, 받아서 바꾸기)를 조금씩 더 잘 풀려는 시도의 연속이었다.

처음엔 서버가 완성된 HTML을 통째로 만들어 보냈다. 링크를 누를 때마다 페이지 전체가 새로 고쳐졌다. 단순하고 견고했지만, 작은 변화 하나에도 화면 전체를 다시 받아야 했다. 2000년대 중반 AJAX가 등장하면서 페이지 전체가 아니라 필요한 데이터만 따로 받아 화면 일부만 바꾸는 길이 열렸다. 화면은 훨씬 매끄러워졌지만, 이제 화면을 조립하는 책임이 클라이언트로 넘어오면서 복잡도도 함께 넘어왔다.

그 복잡도를 감당하려고 React 같은 도구가 나왔고, 화면 전체를 자바스크립트로 그리는 방식(SPA)이 대세가 됐다. 대신 첫 화면이 느리게 뜨고, 검색엔진이 빈 페이지를 보고, 자바스크립트 덩치가 비대해지는 새 문제가 따라왔다. 그래서 다시 서버에서 그리되 클라이언트의 상호작용은 살리는 절충(SSR)이 나왔고, 최근의 서버 컴포넌트와 스트리밍은 "어디까지 서버가 그리고 어디부터 클라이언트가 맡을지"를 더 잘게 나누는 데까지 왔다.

중요한 건 연도나 도구 이름이 아니다. 각 단계가 하나같이 "이전 방식의 한계"를 풀려고 등장했다는 점이다. "왜 React가 필요했나"는 결국 "그 이전엔 무엇이 불편했나"를 묻는 일이고, 이 질문을 품고 봐야 도구가 비로소 납득된다. (렌더링 방식들의 구체적 비교는 [[frontend/INDEX|frontend]]와 [[contract/INDEX|contract]]에서 더 판다.)

데이터를 따라가며 만나는 문제들

이제 댓글 하나가 화면에 그려졌다가 다시 서버로 돌아가 저장되기까지, 그 길 위의 정거장들을 차례로 지난다.

화면에 무엇을, 어떻게 그릴까

가장 먼저 댓글 목록을 화면에 그려야 한다. 순진하게 보면 HTML에 글자만 박으면 끝일 것 같지만, 실제 화면은 가만히 있지 않는다. 새 댓글이 달리고 좋아요 숫자가 바뀔 때마다 화면은 그 변화를 다시 그려야 하고, 그것도 화면 전체가 아니라 바뀐 부분만 효율적으로 다시 그려야 한다. 무엇을 어떤 단위로 나눠 재사용할지, 어떻게 보기 좋게 배치할지, 데이터가 바뀔 때 어떻게 최소한으로 다시 그릴지가 모두 여기 모인다. 브라우저가 화면을 그리는 원리부터 리렌더링 비용까지 → [[frontend/INDEX|frontend]].

사용자가 건드리는 순간을 어떻게 감당할까

사용자가 입력창에 타이핑하고 버튼을 누른다. 그 사이 화면은 '작성 중', '전송 중', '실패' 같은 상태를 오간다. 이 순간순간의 상태를 어디에 어떻게 담아둘지가 까다로운 문제다. 게다가 전송은 시간이 걸리는데 그동안 화면이 굳으면 안 된다 — 자바스크립트는 한 번에 한 가지 일만 하는 싱글스레드라서, 이 비동기를 매끄럽게 다루는 일이 생각보다 어렵다(그 밑바탕인 이벤트루프는 [[language/INDEX|language]]). 입력을 받고, 검증하고, 화면 상태를 흐트러뜨리지 않는 일 → [[frontend/INDEX|frontend]].

어떻게 경계를 넘어 서버와 이야기할까

작성한 댓글이 내 브라우저 안에만 있어서는 아무 의미가 없다. 경계를 넘어 서버로 가야 한다. 그런데 브라우저와 서버는 서로 다른 세계라 둘 사이엔 약속이 필요하다. 무슨 형식으로 주고받을지, 이 요청을 보낸 사람이 정말 로그인한 그 사람이 맞는지, 누군가 새 댓글을 달면 다른 사람 화면에도 곧바로 떠야 하는 실시간 같은 요구까지 — 한쪽만으로는 성립하지 않는, 양쪽의 계약이 전부 여기 있다(그 아래에는 HTTP·TCP 같은 통신 원리가 깔려 있다, [[cs/INDEX|cs]]) → [[contract/INDEX|contract]].

서버는 그 요청을 어떻게 처리할까

요청이 서버에 도착했다. 서버는 이 사람이 이 글에 댓글을 달 권한이 있는지 확인하고, 내용이 비어 있거나 지나치게 길지 않은지 검증하고, 악의적인 입력을 걸러낸 뒤에야 저장으로 넘긴다. 들어온 요청을 어떤 흐름으로 처리할지, 권한을 어떻게 가를지, 잘못된 입력과 에러를 어떻게 다룰지가 여기 문제다 → [[backend/INDEX|backend]].

데이터를 어떻게 저장하고, 어떻게 일관되게 지킬까

댓글은 어딘가에 영구히 남아야 다음에 또 보인다. 어떤 구조로 저장할지, 댓글이 수백만 개가 돼도 빠르게 불러올지, 두 사람이 같은 데이터를 동시에 건드려도 꼬이지 않게 할지가 여기 달려 있다. 화면은 사라져도 데이터는 남아야 한다 → [[data/INDEX|data]].

이 모든 게 어디서, 어떻게 돌아갈까

지금까지의 코드는 누군가의 노트북이 아니라 실제 서버 위에서, 그것도 사람이 몰려도 죽지 않고 돌아야 한다. 어떻게 배포하고, 트래픽에 맞춰 늘리고, 문제가 터졌을 때 어디가 터졌는지 들여다볼지 → [[infra/INDEX|infra]].

흐름의 한 점이 아니라, 모든 점에 얹히는 문제들

지금까지의 문제들이 데이터가 흐르는 길 위의 정거장이라면, 다음 질문들은 그 길 전체에 똑같이 따라붙는다. 댓글 입력에 악성 스크립트를 심으면 막을 수 있나(안전한가), 목록이 수천 개여도 화면이 빠른가(빠른가), 저장 도중 서버 한 대가 죽어도 댓글이 유실되지 않나(안 죽나), 그리고 이 모든 게 의도대로 동작한다고 어떻게 확신하나(검증됐나). 어느 한 폴더의 문제가 아니라 프론트든 백엔드든 데이터든 똑같이 들이대는 잣대다 → [[cross/INDEX|cross]].

흐름을 만들고 유지하는 일

여기까지가 "웹이 동작하는" 흐름이라면, 그 흐름을 만들고 고치는 작업 자체도 지식이다. 여러 사람이(혹은 과거의 나와 지금의 내가) 같은 코드를 안전하게 고쳐 나가는 버전관리, 고친 것이 멀쩡한지 자동으로 확인하는 테스트, 그리고 무언가 잘못됐을 때 원인을 되짚는 디버깅 같은 것들이다. 이것들은 웹 그 자체의 흐름은 아니지만, 그 흐름을 떠받치는 작업대다. 버전관리는 [[library-framework/INDEX|library-framework]]의 git에서, 테스트는 품질의 한 축으로 [[cross/INDEX|cross]]에서 다룬다.

닫으며

이 글은 지도일 뿐이다. 각 정거장에서 "그래서 이걸 어떻게 푸나"가 궁금해지는 순간, 망설이지 말고 해당 폴더로 들어가면 된다. 그리고 세부에 파묻혀 길을 잃을 때면 다시 여기로 돌아와, 지금 자신이 어느 문제를 풀고 있었는지 확인하자. 큰 그림을 쥐고 있는 한, 어떤 지식도 떠다니지 않는다.