Client-Server

사용자 화면, 데이터 저장, 비즈니스 규칙을 모두 한곳에서 직접 처리하려고 하면 변경이 겹칠수록 관리가 빠르게 어려워집니다. 여러 사용자가 동시에 접근하는 순간 데이터 충돌과 권한 통제 문제도 생깁니다. 각 단말이 데이터를 제각각 들고 있으면 상태를 맞추는 비용이 커지고, 어디가 진짜 기준인지도 흐려집니다. Client-Server는 이 혼란을 줄이기 위해 입력하는 쪽과 처리하는 쪽의 책임을 갈라 놓습니다.

초기의 컴퓨팅은 단말이 거의 표시 장치 역할만 하고, 실제 계산과 데이터는 중앙 시스템이 맡는 경우가 많았습니다. 사용자가 늘고 네트워크가 일반화되면서 화면은 점점 풍부해졌지만, 데이터 기준점과 정책을 중앙에서 관리해야 한다는 요구는 계속 남았습니다. 그래서 입력과 처리 책임을 나누는 구조는 웹, 모바일, 기업 시스템 전반에서 오래 살아남았습니다. Client-Server는 화려한 패턴이라기보다, 분산된 사용자와 중앙 규칙을 연결하는 가장 기본적인 출발점에 가깝습니다.

클라이언트는 주로 사용자 입력을 받고 결과를 보여 주며, 서버는 요청을 받아 규칙을 실행하고 저장소와 통신합니다. 핵심은 화면과 데이터 기준점을 분리하는 데 있습니다. 서버가 공통 규칙과 상태를 중앙에서 잡아 주기 때문에, 여러 클라이언트가 있어도 같은 기준으로 동작시킬 수 있습니다.

Client-Server와 Event-Driven Architecture는 모두 컴포넌트가 떨어져 통신한다는 공통점이 있습니다. 하지만 Client-Server는 요청을 보낸 쪽이 즉시 응답을 기대하는 직접 대화 모델이고, Event-Driven Architecture는 어떤 일이 발생했다는 사실을 흘려보내고 나중에 다른 쪽이 반응하는 느슨한 모델입니다. 즉 지금 바로 답이 필요한 상호작용을 정리할 때는 Client-Server가 더 자연스럽고, 누가 듣는지 모른 채 변화를 퍼뜨려야 할 때는 다른 사고가 필요합니다.

웹 프런트엔드가 백엔드 API를 호출하고, 모바일 앱이 같은 서버에 접속하며, 여러 사내 단말이 하나의 업무 시스템을 함께 쓰는 장면에서 Client-Server는 여전히 기본 틀입니다. 특히 데이터 기준점이 한곳에 있어야 하고 접근 제어를 중앙에서 해야 할 때 구조가 선명해집니다. 다만 서버 안의 책임이 커지기 시작하면 그 내부를 더 잘 나누는 구조가 곧 필요해집니다.

다음에 볼 개념

함께 보면 좋은 개념