Client-Server

화면, 데이터, 규칙이 한 프로그램 안에 있으면 사용자가 한 명일 때는 문제없습니다. 사용자가 두 명이 되는 순간 꼬이기 시작합니다. 한 사람이 재고를 바꾸는 동안 다른 사람이 같은 데이터를 읽으면 어느 쪽이 최신인지 알 수 없습니다. 각자 복사본을 들고 작업하면 나중에 어느 쪽이 맞는지 맞추는 데 기능 개발보다 많은 시간이 들어갑니다. 권한 문제도 따라옵니다. 검증 로직이 클라이언트에만 있으면 규칙을 우회하거나 데이터를 직접 수정하는 것을 막을 방법이 없습니다. 금융 거래나 의료 기록처럼 '누가 언제 무엇을 바꿨는지' 추적해야 하는 시스템에서는 규칙이 사용자 기기에 분산되어 있는 구조가 근본적으로 불안합니다.

초기 단말기는 중앙 메인프레임의 입출력 장치에 가까웠습니다. PC가 나오고 네트워크가 퍼지면서 단말도 자체적으로 화면을 그릴 수 있게 됐지만, 데이터와 규칙은 여전히 한곳에 있어야 했습니다. 여러 사람이 같은 데이터를 쓰는 한, 기준이 흩어지면 충돌을 피할 수 없으니까요. 이 필요가 클라이언트-서버 구조를 만들었고, 형태만 바뀌면서 계속 반복됩니다. 웹에서는 브라우저와 웹 서버, 모바일에서는 앱과 백엔드 API가 그 모습입니다. 특정 시대의 발명이라기보다 '여러 사용자가 같은 데이터를 쓰는 상황'이면 자연스럽게 나타나는 구조입니다.

식당에 비유하면, 손님은 메뉴를 보고 주문하지만 주방에 들어가지 않습니다. 주방은 주문을 받아 조리하고 결과만 내보냅니다. 손님은 주방 사정을 몰라도 되고, 주방은 손님이 어떤 기기로 주문했는지 신경 쓰지 않습니다. 실제 동작은 이렇습니다. 클라이언트가 HTTP나 gRPC로 요청을 보내면, 서버가 받아서 규칙을 실행하고 필요하면 데이터베이스를 조회한 뒤 응답을 돌려줍니다. 이 분리의 핵심은 상태의 기준점이 서버 한 곳에 모인다는 점입니다. 클라이언트가 열 개든 백 개든 데이터의 진실은 서버에 있고, 접근 제어도 서버에서 한 번만 구현하면 됩니다.

클라이언트-서버와 이벤트 드리븐 아키텍처는 둘 다 분리된 컴포넌트 간 통신이지만, 대화 방식이 다릅니다. 클라이언트-서버에서 클라이언트는 서버에 직접 요청을 보내고 응답을 기다립니다. 이벤트 드리븐에서는 '이런 일이 일어났다'는 사건을 발행하고, 누가 처리하는지 관여하지 않습니다. 로그인이나 실시간 조회처럼 결과를 즉시 받아야 할 때는 요청-응답 구조가 자연스럽습니다. 주문 접수 후 재고 차감, 알림 발송, 정산이 각자 처리되어야 하거나 여러 컴포넌트가 같은 사건에 반응해야 할 때는 이벤트 드리븐이 더 맞습니다. 클라이언트-서버에서 서버는 단일 병목이 됩니다. 요청이 몰리면 서버에 부하가 집중되고, 서버가 다운되면 클라이언트는 동작을 멈춥니다. 서버 내부가 커지는 것은 이 구조의 범위 밖 문제입니다.

웹 프런트엔드가 API를 호출하고, 모바일 앱이 같은 백엔드에 연결하고, 사내 단말 여러 대가 하나의 업무 시스템을 공유하는 구조가 모두 클라이언트-서버입니다. 데이터 무결성과 접근 제어가 핵심인 도메인에서 이 구조가 두드러집니다. 금융 거래나 환자 기록처럼 변경 이력을 중앙에서 추적해야 하는 시스템이 그렇습니다. 여러 클라이언트가 동시에 같은 데이터를 다루는 상황에서 서버가 없으면 충돌을 막을 방법이 없습니다. 클라이언트 수가 늘거나 종류가 다양해질수록 이 구조의 이점이 커집니다. 웹, 모바일, 외부 파트너 API가 동시에 같은 백엔드를 사용하는 구조에서 서버는 인증과 데이터 규칙을 한 번만 구현하면 됩니다.