프론트엔드에서 처리하는가, 백엔드에서 처리하는가

데이터 테이블 설계에서 고민했던 지점

API를 만들면서 데이터 테이블을 설계하다 보면,

UI에는 드러나지 않지만 데이터로는 저장해야 하는 값들이 생긴다.

이번 작업에서도 그런 케이스를 하나 마주했다.

 

사용자 입력이 아닌 데이터는 어디서 만들어야 할까?

현재 재직 중인 곳은 헬스케어 도메인이기 때문에, 회원이 건강 카테고리를 직접 선택하는 플로우가 존재한다.

동시에 회원의 건강 검진 데이터나 건강 상태를 기반으로 시스템에서 추천되는 건강 카테고리가 있었고, 이 추천 결과 역시 데이터베이스에는 누적되어야 하는 요구사항이 있었다.

문제는 이 추천 카테고리가 사용자가 직접 선택한 값은 아니라는 점이었다.

 

고민했던 두 가지 방향

이 지점에서 크게 두 가지 선택지를 놓고 고민했다.

1️⃣ 프론트엔드에서 함께 내려보내는 방식

백엔드에서 건강 데이터 기반 추천 카테고리를 내려주고, 사용자가 건강 카테고리를 선택할 때 추천 카테고리도 함께 request payload에 담아 백엔드로 전달하는 방식이다.

이미 추천 카테고리를 API 응답으로 받고 있기 때문에 구현 자체는 어렵지 않았다.

다만, 사용자가 실제로 선택하지 않은 데이터를 프론트엔드에서 의도적으로 추가해 보내는 행위가 조금 부자연스럽게 느껴졌다.

2️⃣ 백엔드에서 처리하는 방식

두 번째는 프론트엔드에서는 사용자가 선택한 값만 전달하고, 건강 데이터 기반 추천 카테고리는 백엔드 로직에서 생성해 같은 테이블에 누적하는 방식이다.

구조적으로는 더 정석처럼 보였지만, 여기서 또 하나의 고민이 생겼다.

사용자 행동으로 생성된 데이터와 시스템 판단으로 생성된 데이터가 같은 테이블에 쌓여도 괜찮을까?

 

사용자 행동 추적 관점에서의 고민

사용자 행동을 추적하는 관점에서 보면 두 데이터의 성격은 분명히 다르다.

하나는 사용자가 직접 선택한 결과이고, 다른 하나는 건강 데이터를 기반으로 시스템이 생성한 결과다.

이 차이가 데이터 상에서 드러나지 않는다면, 나중에 해당 데이터를 해석하거나 활용할 때 오히려 혼란을 줄 수 있다고 느꼈다.

이를 보완하기 위해 해당 테이블에healthDataBasedYn 과 같은 플래그 컬럼을 추가했다. 이로써 데이터가 사용자 입력에 의해 생성된 것인지, 건강 데이터 기반으로 시스템에서 생성된 것인지 명확히 구분할 수 있게 되었고, 같은 테이블에 쌓이더라도 데이터의 의도가 드러나는 구조가 되었다.

 

결정 이후에 더 분명해진 기준

결과적으로는 2번 방식, 즉 백엔드에서 건강 데이터 기반 로직을 처리하는 구조로 설계했다. 이 결정을 확신하게 된 계기는 단순히 API 설계 관점 때문만은 아니었다.

이 데이터들은 결국 운영 중에 조회되고, 관리되고, 분석되어야 하는 대상이었고,

특히 어드민 화면에서 건강 데이터 기반 추천 카테고리와 사용자가 직접 선택한 카테고리를 함께 노출하면서 각 데이터가 어떤 기준으로 생성되었는지를 구분해 보여줘야 했다.

이 요구사항을 고려해보니 “데이터를 어디서 생성할 것인가”보다 “이 데이터가 이후에 어떻게 해석되고 사용될 것인가”가 더 중요한 기준이라는 생각이 들었다.

느낀 점

이번 경험을 통해 느낀 점은 데이터 테이블 설계는 단순히 저장 구조를 만드는 일이 아니라 운영과 관리, 해석까지 포함한 설계 과정이라는 것이었다.

특히 어드민 기능은 나중에 덧붙이는 부가 기능이 아니라, 초기 테이블 구조를 결정하는 데 매우 중요한 기준이 된다는 점을 체감하게 되었다.

추적해야 하는 데이터 중에는 UI 상으로는 드러나지 않는 값들도 많기 때문에, 프론트엔드 API 관점만을 기준으로 테이블을 설계해서는 한계가 있다는 것도 함께 느끼게 되었다.

 

데이터 테이블 설계에 사용한 도구

데이터 테이블 구조를 정리할 때는 아래 웹사이트를 사용했다.

https://dbdiagram.io/d

장점

• 무료로 사용 가능
• 링크로 공유 가능
• 문법이 단순해 빠르게 구조 정리 가능

단점

• 링크를 가진 사람이 수정하려면 유료
• 색상 지정 등 시각적인 표현은 제한적