서버와 클라이언트, 이것만큼은 알고 가자
기획자가 서버를 모르면, 결국 아무도 설명을 못한다
“이거 서버에서 처리해야 돼요.”
“클라이언트에서만 보여주면 안 될까요?”
“서버 응답 느려서 UX가 나빠요.”
기획 회의에서 흔히 나오는 얘기들입니다.
‘서버에서 처리한다는 게 무슨 말이지..‘
‘클라이언트는 고객 아닌가요..’
이런 생각하셨다면, 당첨.
구버전 저랑 똑같은 수준이시네요.
기획자에게 이 두 개념이 안 잡혀 있으면,
개발 요청을 할 때마다 구조가 엉키고,
기능 흐름이 혼선에 빠집니다.
서버 vs 클라이언트, 초간단 정의
서버와 클라이언트의 개념을 가장 쉽게 이해하려면 다음과 같이 정리할 수 있습니다.
클라이언트: 사용자가 직접 접하는 화면입니다. 앱, 웹 브라우저, 화면, 버튼 등 눈에 보이는 부분을 담당합니다.
서버: 눈에는 보이지 않지만, 데이터를 처리하고 클라이언트로 보내주는 컴퓨터 또는 시스템입니다.
햄버거 주문으로 이해해 보자
당신이 햄버거집에 들어간다 = 클라이언트
주문을 받는 점원 = UI (사용자 인터페이스)
주방에서 햄버거를 만드는 곳 = 서버
햄버거 완성 후 나오는 결과 = 서버 응답
기획자는 어떤 주문을 어떤 방식으로 받을지(UI),
주방에는 어떤 조리를 요청할지(API),
메뉴가 없을 땐 어떻게 응답할지를 정의하는 사람입니다.
이걸 모르면 기획서가 이 모양이 됩니다:
“이 버튼을 누르면 리스트가 보입니다.”
개발자: “그 리스트 어디서 가져오죠?”
기획자: “그냥 띄워주면 되지 않나요?”
개발자: “아니… 서버에서 데이터를 받아와야 할 텐데요.”
데이터가 서버에 있는지, 클라이언트에 미리 있는지 구분 못하면 “구현은 못 하는데, 수정 요청도 애매한” 기획서가 됩니다. 결국 개발자와 핑퐁만 반복되죠.
기획자가 꼭 알아야 할 서버 지식(딱 이것만)
1. 서버에서 처리해야 할 작업 vs
클라이언트에서 처리할 작업
서버와 클라이언트는 각자 처리해야 할 작업이 다릅니다.
구분하지 못하면 개발 단계에서 큰 문제가 발생합니다.
예를 들어, 로그인 인증은 서버에서 처리해야 합니다. 로그인 데이터는 보안이 중요한 정보이므로 서버에서 검증하고 토큰을 관리합니다.
반면, 화면 전환 애니메이션은 클라이언트에서 처리하는 것이 맞습니다. 사용자가 즉각적으로 반응을 느끼게 하기 위해 클라이언트 측에서 처리해야 합니다.
다른 사례로는:
결제 처리: 서버에서 해야 합니다. 외부 결제 시스템과 연동하며, 기록을 남기기 위해 서버 처리 필요.
단순 버튼 클릭 반응: 클라이언트에서 해야 합니다. 빠른 피드백이 중요하므로 로컬에서 처리하여 즉각 반응.
구분 못하면?
서버에 애니메이션 넣자고 하고,
클라이언트에서 결제 처리하자고 기획함.
2. 서버 응답 시간이 UX에 미치는 영향
서버 응답이 느리면 어떤 일이 벌어질까요?
서버에서 응답이 1~2초만 늦어도, 사용자는 “앱 느려”라고 느낍니다.
서버 응답이 2초 걸리면 사용자는 “버튼이 안 눌렸나?” 하고 두 번 누릅니다.
그럼 중복 요청이 들어가서 서버는 더 힘들어져요.
기획자가 로딩 처리나 시간 제한을 걸어두지 않으면, 이런 사소한 UX가 전부 ‘오류’처럼 보이게 됩니다.
그래서 기획자가
“여기 로딩 인디케이터 넣어주세요”
“응답 안 오면 5초 후에 에러 메시지 띄워주세요”
같은 걸 미리 고려해 줘야 UX가 안 망합니다.
3. 서버 비용은 공짜가 아니다
서버를 더 쓰면 돈 더 듬
트래픽 많아지면 AWS 요금 상승
실시간 처리 많아지면 병목 생김
기획자는 기술적으로 가능하냐 보다, 현실적으로 합리적이냐를 같이 고민할 줄 알아야 돼요.
“실시간 알림 무조건 1초 내로!” 같은 말 함부로 하면,
개발자는 속으로 서버비 걱정하고 있을지도 몰라요.
기획자 실수 예시 모음
“결제 버튼 누르면 완료돼요” 서버 응답을 기다리지 않고 ‘완료됨’ 처리해 버림 (이건 진짜 망함)
“이건 클라이언트에서 처리하는 거니까 빨라요” 사실 서버 3단계 API 호출이 들어가 있었음
“화면에 오류 메시지 안 나오던데요?” 서버는 500에러 뿜고 있었고, 클라이언트는 침묵 중
사실 이런 실수는 보통 QA나 개발 리뷰 과정에서 걸러지지만, 기획자가 구조를 모르면 문제의 근본 원인을 이해하지 못한 채 핑퐁만 길어지는 경우가 생긴다는 점에서 유의가 필요합니다.
마무리하며
기획자는 서버 개발자가 아닙니다.
하지만 클라이언트와 서버가 어떤 역할을 하고,
서로 어떤 데이터를 주고받는지 정도는 이해해야
제대로 된 기획서를 쓸 수 있습니다.
서버는 보이지 않지만, 기획의 흐름을 살리는 심장입니다.
기획자가 서버와 클라이언트를 명확히 이해해야
서비스의 구조를 제대로 잡을 수 있습니다.
