서버 · 클라이언트
Server / Client
서버란?
- 클라이언트=요청하는 쪽
- 서버=제공하는 쪽
- 둘이 주고받아 서비스
이 구분이 실제로 바꾸는 것은 '누구 탓인가'를 가르는 선입니다. 화면이 깨졌다는 제보가 들어왔을 때, 특정 직원 한 명의 브라우저에서만 깨지면 클라이언트 쪽이고, 전 직원이 같은 시각에 같은 증상을 겪으면 서버 쪽입니다. '나만 그런가, 다들 그런가'라는 한 가지 질문만으로 확인할 범위가 절반으로 줄어듭니다. '사이트가 이상하다'가 아니라 '어느 쪽이 이상한지'를 말하는 순간 외주 개발사의 회신 속도부터 달라집니다.
실무에서 경계를 가르는 기준은 세 가지입니다. 첫째는 오류 번호입니다. 404·403처럼 4로 시작하면 요청한 쪽(클라이언트)의 문제, 500·502처럼 5로 시작하면 처리한 쪽(서버)의 문제라는 약속이 웹 전체에 깔려 있습니다. 둘째는 데이터가 어디에 남느냐입니다. 새로 고치면 사라지는 값은 클라이언트에, 다른 기기로 로그인해도 그대로인 값은 서버에 저장된 것입니다. 셋째는 속도입니다. 마우스 올렸을 때 색이 바뀌는 정도는 클라이언트가 즉시 처리하지만, 서버를 한 번 다녀오면 0.3~2초의 왕복 시간이 그대로 붙습니다.
가장 흔한 오해는 '화면에 안 보이면 없는 것'이라는 착각입니다. 클라이언트로 내려간 코드와 데이터는 F12 한 번이면 누구나 열어볼 수 있습니다. 바이브 코딩으로 만든 사내 도구에 AI API 키를 브라우저 코드에 그대로 박아 두었다가, 외부에서 그 키로 호출이 쏟아져 요금 폭탄을 맞는 사고가 지금도 반복됩니다. 금액 계산·권한 확인·비밀 키는 예외 없이 서버에서 처리하고 클라이언트에는 '보여주기'만 맡긴다 — 이 선만 지켜도 사고 대부분은 막힙니다. 관리자 버튼을 화면에서 숨기는 것은 보안이 아닙니다.
1970~80년대 여러 단말이 중앙 컴퓨터에 연결되던 컴퓨팅 환경에서 정립된 '클라이언트-서버 모델'에서 비롯됐고, 웹(1990년대)의 기본 구조가 됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 120명, 연매출 400억 원대 생활용품 유통사 A사의 자사몰 사례입니다. 3개월 동안 '장바구니가 안 담긴다'는 CS 문의가 월 60건까지 쌓였는데, 운영팀은 매번 외주 개발사에 '사이트가 이상하다'고만 전달했고 답을 받기까지 평균 3일이 걸렸습니다.
- 운영팀 김 대리가 문의 60건을 '한 사람만 겪는 건'과 '여러 명이 같은 시각에 겪는 건'으로 나눠 보니, 41건이 특정 고객 한 명에게서만 나온 클라이언트 쪽 문제였습니다.
- 개발사 PM이 '오류 화면을 캡처해서 접속 시각과 같이 보내 주세요'라고 요청해, CS 응대 템플릿에 오류 번호와 접속 시각을 묻는 항목을 추가했습니다.
- 남은 19건은 로그를 열어 보니 전부 오후 8시대 502 오류였고, 프로모션 알림을 5만 명에게 한 번에 쏘는 순간 서버가 동시 접속을 못 버틴 것이었습니다.
- IT팀장이 알림 발송을 8시 정각 일괄에서 10분 간격 3회로 쪼개자, 다음 달 502 오류는 19건에서 2건으로 떨어졌습니다.
- 6개월 뒤 장바구니 관련 문의는 월 60건에서 17건으로, 개발사 회신까지 걸리던 시간은 평균 3일에서 4시간으로 줄었습니다.