프론트엔드도 데이터 설계를 해야 하는 이유 (feat. 백엔드)

프론트엔드를 하면서 데이터 설계가 백엔드의 영역이라고 생각한다면,
너는 당장 생각을 바로고칠 필요가 없다.
풀스택 을 한 내가 할 말이냐고 생각할 수 있겠지만, 프론트엔드 또한 데이터 설계가 필요하다.

결국엔 화면에 표시해야 할 건 데이터고, 그 데이터를 화면에 표현하는 게 바로 네 역할이기 때문에,
프론트엔드 개발자는 화면에 표시해야 할 데이터에 대한 기준을 마련해야 할 필요가 있다.

백엔드 데이터와 화면에 필요한 데이터의 적절한 밸런스

물론 나는 풀스택 개발하고 백엔드 데이터와 화면에 표시해야 할 데이터가 뭔지를 내 몸으로 익히 알고 있기 때문에 백엔드 데이터와 화면에 필요한 데이터 모두 아무렇지도 않게 설계하고 표현할 수 있다.
그래서 오늘은 주니어 프론트 하는 너희들에게 데이터를 표현할 밸런스 사례를 소개한다.

별거 없다.

백엔드 데이터 유형을 해치지 않으면서, 화면에 표현하기에 매우 적절한 데이터

이렇게 정리하면 된다. 케이스 바이 케이스로 몇가지 예를 들어 주겠다.

날짜(Date/Time)

화면에 표시하면서 보통 DB 저장 데이터와 화면 표시 데이터 간의 차이점 중에 가장 이질감이 느껴지는 부분이 바로 이 날짜일 것이다.

화면에 표시해야 할 날짜의 예를 들자면

• 2023년 11월 16일 12시 34분 56초
• 2023-11-16 12:34:56
• 23/11/16 오후 12:34
• 16 Nov 2023 12:34 PM (유럽식이고 보통 미국식은 Nov 부분이 앞으로 간다.)

뭐 여러가지 있겠지만, DB에 저장되는 유형은 크게 둘로 나눌 수 있다.

• DATE '2023-11-16T12:34:56' 또는 시차(Timezone, 예: +09:00Z) 첨가
• VARCHAR '20231116123456'

특이한 사항으로 Unix Timestamp 형태인 NUMERIC 형태로도 들어갈 수 있지만 그럴 일 드물고 내 경험상 단 한번도 없었으니 이건 논외로 치고,

그러면 백엔드 개발자와 표시할 데이터를 협상하게 된다. 만약 그렇지 않고 한쪽에서 강요한다면...
그건 내가 경험상 감히 말하는데 한쪽에 쏠린 프로젝트 치고 정상적인 프로젝트는 없었다.

협상 방식 예를 들어 볼까?

• 날짜는 목록에 단순히 표시하는 용도이니, 쿼리 상에서 화면에 표시되는 날짜로 표현하기
  만약 날짜 데이터 변경 시나리오가 없을 경우, 데이터 교환 시 보통 백엔드에서 챙겨준다.
  SQL 상에서나 백엔드 어느 언어에서나 날짜 변환은 그리 힘든일이 아니다.
  따라서 읽기 전용 데이터 시나리오일때는 가장 흔히 사용하는 시나리오고, 백엔드도 인지하고 처리해준다.
• 날짜는 변경이 가능하므로, 변환하기 좋은 용도(예: ISO-8601)로 표현해서 넘겨주기
  데이너 변경하는 시나리오가 있을 때에 대한 데이터 교환 시 이 방법이 널리 사용하는 협상 방식이다. 백엔드와 프론트엔드 모두에게 좋은 방식으로 String 으로 변환하여 넘겨준다. 그리고 백엔드나 프론트엔드나 이걸 Date 기반의 객체로 변환하여 관리하게 된다. 날짜를 수정하거나, 더하거나 빼거나... 가공이 좋고, 프론트엔드는 변경 결과를 다시 DB에서 보내준 형식에 맞춰 전달한다.

여기서 느낀 점이 생겼다면, 너는 이제 프론트엔드 개발할 준비가 본격적으로 됐다고 칭찬하도록 하겠다.
그렇다. 정리하면, 날짜는 어디든 정보 교환하는 데 있어서, 공통적인 형식을 정하는 것이 가장 기본적으로 협상할 때 항상 최상의 시나리오를 만들 수 있다 하겠다.

날짜 형식을 예로 들면, (밀리초 이하 단위는 별도 협상)

• YYYY-MM-DD HH:mm:ss 및 구분자 기반
• YYYYMMDDHHmmss 등의 붙여쓰기

대부분 위 두가지 기반의 방식으로 데이터 교환을 협상할 것이다. 이렇게 교환 방식 하나 정해놓고 통일하면, 백엔드도 프론트엔드도 날짜를 가공하고, 읽고 쓰기에 매우 편리하여 좋은 결과가 나올 것이다.

열거자(Enumeration)

열거자는 다양한 유형이 있다. Y/N 이라든가, 0/1 이라든가, A/B/C 나 00/01/02 등등...
보통은 설계자들이 정해놓는다. 따라서 보통은 프론트엔드가 관여할 자리가 없어 보이는 영역이기도 하다.

하지만, 프론트엔드는 이 열거자 값을 사용자가 이해하기 쉬운 값으로 변환해야 하기 때문에 이 또한 협상에서 빠질 수 없는 부분이다.

예를 들면, 같은 Y/N 코드라도, 예/아니오 일 수도 있고, 가능/불가 일 수도 있고 다양한 화면 표시 방식이 존재할 것이다.
그렇다면, 이것을 어떻게 해결하면 좋을까? 보통이라면...

그래서 보통 업체들은 소위 '공통코드' 라고 하여 어플리케이션에 공통적으로 코드와 명칭을 정해놓아 저장하는 공간을 마련한다.

이렇게 백엔드가 거의 독점으로 관리하는 것 같은 영역에서 프론트엔드가 협상해야 할 게 뭐가 있을까?
바로 이들을 받아 처리하기 위해 사전 협상하는 방식이다.

보통 아래와 같은 시나리오가 있고, 경우에 따라 섞어 사용하기도 한다.

• 코드와 명칭을 미리 받고 프론트엔드에서 전역 단위로 캐시해서 코드에 따른 명칭을 바로 가져오는 방식
• 어플리케이션에서 사용하는 코드와 명칭 사전을 페이지 및 화면마다 제공
• 백엔드에서 통상적인 데이터와 함께 코드와 명칭을 제공하고 프론트엔드에서 명칭을 화면에 표시하고 코드는 내부에 보관

각기 장단점이 있다.

• 전역 캐시 방식은 데이터 수신 빈도가 낮아 트래픽 등의 절약 효과가 있으나, 프론트엔드 상에서 손실했을 경우 이를 대응하는 시나리오를 별도 대응해야 하고 이에 대한 난이도가 높아지고 그만큼 최신 코드 사전 데이터를 얻을 기회가 적다.
• 페이지 단위 캐시 방식은 전역 캐시 방식에 비해 페이지 진입 시마다 최신의 코드 사전을 취득하여 좀 더 최신의 기반 명칭을 사용자에게 제공할 수 있으나 호출 빈도가 늘어나 트래픽 절감 효과가 떨어진다.
• 주 업무 데이터를 받으면서 코드를 받는 형식은 상시 최신의 사전을 받을 수 있으므로 사전 수정 빈도가 높은 업무에 적합하나, 호출 빈도가 가장 높고 주 업무와 함께 전달하기 때문에 용량이 조금 더 커지며, 매번 가공하는 시나리오를 프론트엔드가 대응해야 한다.

과연 어느 방식이 적절할까? 서비스 및 업무 어플리케이션에 따라 정답은 없다. 이건 프론트엔드 개발자와 백엔드 개발자와 사전 협상하여 풀어야 할 숙제인 것이다.

퍼블리시와 프론트엔드의 차이점

만약,

퍼블이랑 프론트랑 뭐가 다름?

이딴 무식한 질문을 던지는 새끼가 있다면, 데이터 처리에 대한 방식을 어필하기만 해도 대부분 해결한다.
퍼블리시는, 디자이너가 잡아준 페이지의 전체적인 구조와 레이아웃, 이동과 버튼 시나리오에 따른 가이드를 제공하지만, 데이터 처리에 대한 시나리오는 제공하지 않는다. 애초에 퍼블리셔는 그런 영역이 아니기 때문이다.

하지만 프론트엔드는 화면에서 할 수 있는 모든 표현을 할 수 있어야 한다.
물론 꼭 3D로까지 표현해가면서 극단적으로 화려한 시각적 효과까지 배워서 해야 한다는 것은 아니다.
어플리케이션에서 요구하는 시각적 화면과 데이터 표현에 필요한 일련의 처리를 해야 하는게 바로 프론트엔드 역할인 것이다.

만약 당신이 퍼블리셔였고 프론트엔드를 희망하고자 한다면 특히 이 데이터 교환 방식에 대한 이해와 협상은 프론트엔드 역량의 중요한 요소이다.

화려한 시각적 효과?
놀라운 사용자 경험?
감동적인 서비스 품질?

모두 다 뒷받침하는 것은 결국 데이터다. 잘라빠진 정적 텍스트도 데이터라 생각해야 한다는 것이다.
예를 들어, 가상 3D 모델하우스가 있는 웹 앱을 만든다고 가정해 보자.

• 모델하우스에서 표현할 공간 영역
• 해당 영역에서 표현해야 할 도면
• 도면에서 3D 표현에 필요한 여러 요소들(텍스쳐, 맵핑 등등)
• 사용자가 공간 진입에 필요한 시발점 좌표

그리고 더 있을 것이다. 하지만 내가 말하지 못한 요소들까지 모두 데이터에서 출발하고, 프론트엔드 개발자는 이 데이터를 기반으로 화면에 시각적으로 표현해야 한다.

이게 바로 퍼블리셔와 프론트엔드의 차이인 것이다.

리액트를 쓰고 뷰를 쓰고 이게 중요한게 아니다. 요즘 프론트엔드에 리액트가 트랜드라느니 지금 시기에 이런 한가한 소리 하고 자빠진 프론트엔드 개발자들 꽤 많이 눈에 띄는데,
리액트를 쓰든 뷰를 쓰든 이건 목적이 아니라 수단이다.
물론 리액트가 업계에서 프론트엔드에 많이 쓰는 건 맞다.
하지만, 다시한번 말하겠다. 수단이다.

백엔드도 마찬가지로, 물론 한국에서 자바 빠지면 거의 모든 IT 마비될 정도로 너무 많은 점유율이긴 하지만, 자바 언어를 사용하여 스프링 프레임워크를 통해 구축했다. 이것도 하나의 수단일 뿐이다.

그럼 같이 데이터 다루는 백엔드랑 무슨 차이?

어플리케이션에는 제공하고 소비할 여러 층(layer)이 있고, 각 층의 최종 결과물을 최종 사용자(end-user)에게 제공함에 목적이 있다.

백엔드(back-end)는, 뒤(back) 에서 DB 등의 여러 데이터 리소스를 가져와 스프링이나 장고 등의 어플리케이션 수단 등을 통해 최종 사용자(end-user) 에게 제공하는 목적이 있고,
프론트엔드(front-end)는, 백엔드 및 다른 곳에 있는 리소스를 가져와 리액트같은 웹이나 모바일 앱 환경 등의 수단을 통해 앞으로(front) 화면을 표현하여 최종 최종 사용자(end-user) 에게 제공하는 목적이 있다.

이걸 둘 다 쳐 하고 자빠진 나같은 것들이 풀스택(Full-stack)이라 하지.

어쨌든 이렇게 최종 사용자에게 서비스를 제공하기 위한 목적을,
예를 들어 백엔드는 MySQL로 데이터를 보관했다가 자바 언어의 Spring 프레임워크를 통해 이를 화면이나 다른 어플리케이션, 아니면 바로 화면으로 전달하기 위한 데이터 규격을 전달하는 수단을 사용하고,
프론트엔드는 백엔드 및 여러 수단으로 가져온 데이터 규격을 받아 React를 통해 화면으로 가공하여 최종 사용자 제공하는 수단을 사용하는 것이다.

이제 이해 됐으면, 나랑 같이 풀스택하지 않을련?

으악 저리 치워요!

끗.