데이터 표현과 타입 설계: 고민과 개념 정리

시간과 같은 데이터를 다룰 때, 데이터를 어떻게 표현하고 처리할지에 대한 고민은 소프트웨어 설계에서 중요한 문제입니다. 예를 들어, 시간을 표시하는 라벨에 "60분"을 출력하려고 할 때, 다음 두 가지 방식으로 데이터를 설계할 수 있습니다.

1. 데이터 타입: string, 값: "60분" (클라이언트에서 그대로 출력)
2. 데이터 타입: number, 값: 60 (클라이언트에서 "분"을 붙여서 출력)

개발 중 2번 방식을 선호하는 경우가 많은데, 이를 고민할 때의 개념적인 배경을 정리해보았습니다.

데이터 표현과 처리의 책임 분배: 관련 개념

1. 표현(Presentation)과 데이터(Data)의 분리

이 개념은 데이터를 순수한 상태로 유지하고, 그 데이터를 화면에 어떻게 표현할지에 대한 책임을 클라이언트(프론트엔드) 또는 별도의 레이어에 두는 접근 방식을 말합니다.

• 장점: 데이터의 재사용성과 유연성이 증가.
• 예시: 숫자 데이터 60은 데이터 자체로서 의미가 명확하며, "분"이라는 단위는 출력 로직에서 처리합니다.

2. SRP(Single Responsibility Principle, 단일 책임 원칙)

단일 책임 원칙은 데이터의 본질적 의미와 그것의 표현을 구분하는 철학과 맞닿아 있습니다. 데이터와 UI 표현 로직을 분리하면 각 부분의 유지보수가 더 쉬워지고 책임도 명확해집니다.

3. 데이터 직렬화와 역직렬화

데이터를 저장하거나 전달할 때 사용하는 방식과 그것을 사용자에게 보여줄 때의 형식은 다를 수 있습니다.

• 직렬화(Serialization): 데이터베이스나 API에서 숫자 60과 같은 원본 데이터를 전달.
• 역직렬화(Deserialization): 클라이언트가 "60분"과 같은 UI 표현을 생성.

4. i18n(국제화)와 지역화(Localization)

시간, 날짜, 금액 등과 같은 데이터를 문자열로 고정하면 다른 언어권이나 지역 설정에서 변경이 어렵습니다. 숫자로 데이터를 저장하고 표현은 별도의 로직에서 처리하면 다양한 언어와 단위를 쉽게 지원할 수 있습니다.

5. 타입의 의미와 표현을 분리하는 이유

2번 방식을 선호하는 이유는 데이터의 유의미성과 유연성을 높이기 위해서입니다.

• 유의미성: 숫자는 명확하며 불필요한 데이터 중복을 방지합니다.
• 유연성: 추가 연산(예: 더하기, 평균 구하기 등)이나 다양한 포맷으로 변환하는 데 유리합니다.
• 문자열로 "60분"을 저장하면 연산이나 변환이 어렵고, 데이터의 의미가 UI와 강하게 결합됩니다.

결론: 데이터 표현과 추상화의 설계

이러한 고민은 "데이터 표현과 추상화의 설계" 또는 "데이터와 표현의 분리" 문제로 정의할 수 있습니다. 데이터를 본질적으로 의미 있는 형태로 설계하고, 표현은 클라이언트 또는 별도의 로직에 맡기는 방식이 더 유연하고 확장성 있는 설계를 가능하게 합니다.