변경 비용으로 나누는 클라이언트와 서버의 책임

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

클라이언트가 두 값으로 퍼센트를 계산할 수 있다면 직접 해야 할까? 계산은 쉽다. 설계 질문은 그 퍼센트에 어떤 의미가 있고 웹과 iOS, Android 클라이언트가 배포된 뒤 바꾸는 비용이 얼마인가이다.

세 질문을 연결해서 본다. 화면에 보여주기만 위한 로직인가? 계산된 값에 비즈니스 의미가 있는가? 앞으로 바뀔 가능성은 얼마나 되는가?

표시 방식은 표시하는 곳 가까이에 둔다

진행 막대를 그리거나 화면을 배치하기 위한 계산이라면 클라이언트가 자연스러운 주인인 경우가 많다. 서로 다른 클라이언트가 같은 데이터를 다르게 표현할 수도 있다. 모든 포맷 결정을 서버로 옮기면 백엔드가 통제할 필요 없는 세부사항까지 책임지게 된다.

비즈니스 의미를 가진 값은 다르다. 퍼센트 자체가 정책에 쓰이거나 어디서나 같은 뜻으로 해석돼야 한다면 백엔드에서 계산하는 편이 분명할 수 있다. 모든 클라이언트가 같은 로직을 복제하는 대신 서버가 하나의 의미를 제공한다.

경계는 조건부다. 지금은 고정돼 보이는 퍼센트 공식에도 나중에 보정값이나 변수가 추가될 수 있다. 그러면 여러 클라이언트에 복사된 로직을 함께 바꿔야 한다. 반올림 방식이나 출시 시점의 작은 차이로 화면 결과가 달라질 수도 있다.

배포된 앱은 변경 비용이 비대칭이다

웹 코드는 대체로 중앙에서 바꿀 수 있다. 설치형 앱은 사용자 기기에 남고 모두가 즉시 업데이트하지 않는다. 그래서 클라이언트 로직을 고치는 비용이 커진다.

구버전 앱이 응답 필드 두 개로 계산하고 있다고 해보자. 나중에 서버 계산값을 새로 도입해도 기존 앱을 위해 옛 필드를 유지하면서 신버전 앱용 결과를 추가해야 할 수 있다. API 버전을 나눈다고 비용이 사라지지는 않는다. 지원 정책이 요구하는 동안 구버전을 계속 운영해야 한다.

팀에는 하위호환 정책이 필요하다. 앱 몇 개 버전을 지원하는가? 강제 업데이트는 언제 허용되는가? 필드를 추가해도 구버전이 깨지지 않는가? 이 답에 따라 앱에 로직을 얼마나 적극적으로 둘 수 있는지가 달라진다.

긴 지원 기간과 여러 클라이언트의 동일한 결과가 필요하면 의미 있는 계산값을 백엔드에서 내려주는 쪽에 기운다. 출시를 강하게 통제할 수 있거나 화면 표현만의 문제라면 클라이언트가 더 유연할 수 있다.

문구와 오류도 같은 비용을 드러낸다

에러 메시지는 변경 비용을 쉽게 보여준다. 서버가 에러 코드만 보내고 앱마다 문구를 하드코딩하면 문장을 고칠 때 앱을 다시 배포해야 한다. 서버가 표시 문구를 함께 보내거나 앱이 메시지 맵을 주기적으로 받는 방법도 있다. 각각 복잡성과 통제 범위가 다르다.

도메인 오류에도 경계가 있다. 내부 오류 메시지를 그대로 공개해도 되는 경우가 있고, API가 클라이언트용 코드와 메시지로 변환해야 하는 경우도 있다. 서비스 계약에 필요한 사례가 생겼을 때 매핑한다. 구체적인 요구 없이 변환 계층부터 만들지는 않는다.

의미와 생명주기로 결정한다

책임을 정하기 전에 묻는다.

• 특정 인터페이스만의 표현 선택인가?
• 값에 비즈니스 의미가 있는가?
• 모든 클라이언트가 정확히 같은 결과를 내야 하는가?
• 규칙이나 문구가 얼마나 자주 바뀔 수 있는가?
• 구버전 클라이언트를 얼마나 오래 살려야 하는가?

백엔드가 모든 것을 계산해야 한다는 규칙은 없다. 입력값이 있다는 이유만으로 의미 있고 자주 변하는 로직을 모든 클라이언트에 복제할 필요도 없다. 의미가 가장 또렷하고 실제 출시 생명주기에서 변경 비용이 감당되는 곳에 책임을 둔다.