동기
개인적으로 지금 일하는 레포에선 프론트의 책임이 과중한 것 같아서 백엔드에 좀 책임을 이관하고 싶다.
그래도 내가 모르는 고려사항이 많을 테니 gpt에 대충 물어봤다.
좋은 질문이야.
요약하면,
백엔드 책임을 키울지 vs 프론트 책임을 키울지 결정할 때 고려해야 하는 것들은 다음과 같아:
1. 데이터 무결성 요구 수준
-
데이터 일관성, 보안이 중요한 경우 → 백엔드 책임 강화
- 백엔드가 진실의 원천(Single Source of Truth)이 되어야 해.
- 예시: 결제 로직, 계정 권한 처리
-
일시적인 데이터 조작, UI 중심 가공이 중요한 경우 → 프론트 책임 강화
- 사용자 경험을 위해 즉시 반응하고, 결과를 로컬에서 다룰 수 있어야 함.
- 예시: 테이블 정렬/필터링, 클라이언트 캐시 최적화
2. 성능 요구사항
- 서버 부하를 줄이고 싶으면 → 프론트 책임 강화
- 데이터를 한 번 크게 내려주고, 프론트가 필요한 만큼 가공/표시
- 클라이언트 부하를 줄이고 싶으면 → 백엔드 책임 강화
- 모바일 기기나 저사양 환경에서는 프론트 부담을 줄여야 함.
📌 실제 기준:
대량 데이터 가공, 복잡 연산 → 서버에서 미리 가공하는 편이 거의 항상 효율적임.
3. API 재사용성/유연성
-
여러 소비자가 같은 API를 쓸 필요가 있으면 → 백엔드 책임 강화
- 여러 종류의 프론트(앱/웹 등)가 다양한 형태로 데이터를 사용할 때,
백엔드가 포맷을 일관성 있게 정리해야 관리가 쉬워.
- 여러 종류의 프론트(앱/웹 등)가 다양한 형태로 데이터를 사용할 때,
-
특정 프론트엔드에 맞춘 특화된 동작만 필요하면 → 프론트 책임 강화
- 백엔드를 복잡하게 만들지 않고, 프론트가 알아서 조작하는 게 낫지.
4. 팀 역량 및 개발 생산성
- 프론트엔드 개발자가 많고 강하면 → 프론트에 맡겨도 안정적
- 백엔드에 인력이 집중돼 있으면 → 백엔드가 더 많은 책임을 가져야 함
(물론 여기선 "프론트가 강하니까 아무거나 맡긴다" 이런 게 아니라, 유지보수 가능성을 고려해야 한다는 얘기야.)
5. 변경 가능성
-
요구사항이 자주 바뀔 것 같으면 → 프론트 책임 강화
- 서버 변경 없이 화면만 고쳐서 대응하는 게 더 빠르니까.
-
계약(API 스펙)이 단단해야 하는 상황이면 → 백엔드 책임 강화
- 데이터 구조가 자주 변하면 서버를 수정하고, 버전 관리도 해야 돼.
6. 보안
- 민감 데이터나 권한 검증이 필요하면 무조건 백엔드
- 사용자 인증/인가 같은 건 절대 프론트에 맡기면 안 돼.
- 프론트는 표시만, 검증과 권한 관리는 서버가 담당.
요약표
| 고려사항 | 백엔드 책임 강화 | 프론트 책임 강화 |
|---|---|---|
| 데이터 무결성 | 필요 | 덜 중요 |
| 성능 최적화 | 서버가공 | 클라이언트가공 |
| API 재사용성 | 높음 | 낮음 |
| 팀 역량 | 백엔드 강함 | 프론트 강함 |
| 요구사항 변경 | 적음 | 잦음 |
| 보안 | 민감함 | 덜 민감함 |
한줄 요약
"데이터를 믿어야 하는 책임이 어디 있어야 하느냐" 이게 제일 큰 기준이고, 부수적으로 성능/팀역량/변경성 등을 따진다.
필요하면, 각각 상황별 구체적인 예시도 같이 들어줄게.
특정 상황(예: "관리자 페이지에서 테이블 필터링", "회원가입 로직") 같은 거 정해서 물어볼래? 🚀
(그럼 더 현실적인 비교도 해줄 수 있어.)
후기
다른 건 좀 당연한 말이고 집중할 필요가 있어 보이는 것은
- api 재사용성
- 변경 가능성
정도 인 것 같다.
특히 변경 가능성이 높을 때엔 확실히 백엔드에 검증 코드를 넣어두는 것보다 프론트에서 상황에 맞춰 다르게 구현해 놓는 것이 더 빠르고 편할 것 같긴 하다.
지금 작업하는 곳이 변화가 많은 만큼 자연스럽게 프론트 쪽으로 책임이 치우쳐지지 않았나 싶다...
