SQL Struct: 데이터베이스가 책장처럼 생각하는 법을 배울 때

데이터베이스를 거대한 도서관이라고 생각해보자. 지금까지 수십 년 동안, 우리는 전통적인 도서관 목록 시스템처럼 데이터를 정리해왔다. 모든 책의 정보를 각각 다른 카드에 적어서 별도의 서랍에 보관하는 방식 말이다. 제목 카드는 여기, 저자 카드는 저기, 출판연도는 또 다른 곳에. 이게 바로 데이터베이스에서 말하는 **정규화(normalization)**다.

그런데 만약 도서관이 책의 모든 정보를 하나의 똑똑한 봉투에 담을 수 있다면 어떨까? 제목, 저자, 출판 정보, 심지어 리뷰까지 모두 깔끔하게 한 곳에 모아둘 수 있다면? 이게 바로 현대 SQL 데이터베이스에서 struct가 해주는 일이다.

Struct가 뭔지 정확히 알아보자

Struct는 데이터계의 스위스 아미 나이프 같은 존재다. 관련된 정보들을 억지로 여러 테이블에 나눠 담지 않고(도서관 카드 시스템처럼), 연관된 필드들을 하나로 묶어서 논리적인 덩어리로 만들어준다.

-- 기존 방식: 테이블 여러 개
-- books: book_id, title
-- authors: book_id, author_name  
-- publishers: book_id, publisher_name, year

-- Struct 방식: 관련 데이터를 한 테이블에 뭉쳐놓기
CREATE TABLE books (
  book_id INT64,
  info STRUCT<
    title STRING,
    author STRING,
    publisher STRING,
    year INT64
  >
)

파일링 캐비닛(기존 테이블들)과 잘 정리된 서류가방(struct)의 차이라고 보면 된다. 둘 다 서류를 보관할 수 있지만, 서류가방은 관련 있는 것들끼리 구역을 나눠서 함께 넣어둔다.

Array of Structs의 마법

여기서부터 진짜 재밌어진다. 우리 책 봉투가 여러 권을 담을 수 있다면? 이게 바로 array of structs다. 완전한 책 정보 여러 개를 담을 수 있는 확장형 폴더 같은 거다.

-- 고객의 독서 기록
CREATE TABLE customers (
  customer_id INT64,
  name STRING,
  reading_history ARRAY<STRUCT<
    book_title STRING,
    genre STRING,
    rating INT64,
    date_read DATE
  >>
)

민지라는 고객의 독서 기록이 이런 식으로 저장된다고 생각해보자:

민지의 독서 기록:
📚 [
  {title: "해리포터", genre: "판타지", rating: 5, date_read: "2025-01-15"},
  {title: "미움받을 용기", genre: "자기계발", rating: 4, date_read: "2025-02-20"},
  {title: "듄", genre: "소설", rating: 5, date_read: "2025-03-10"}
]

민지의 모든 독서 기록이 한 곳에 딱 들어있다. 고객 정보와 함께 다니는 개인 독서 다이어리 같은 느낌이다.

데이터베이스계의 영원한 떡밥

이쯤 되면 데이터 엔지니어링에서 가장 뜨거운 논쟁거리가 나온다: 데이터를 도서관 목록처럼 깔끔하게 나눠 놓을 거냐(정규화), 아니면 개인 파일함처럼 뭉쳐 놓을 거냐(struct 쓴 비정규화)?

도서관 목록 스타일 (정규화)

• 좋은 점: 중복 없이 깔끔, 하나만 고치면 끝
• 아쉬운 점: 전체 정보 보려면 여기저기 뒤져야 함
• 언제 쓰나: 개별 정보를 자주 수정할 때

개인 파일함 스타일 (Structs)

• 좋은 점: 관련 정보가 다 한 곳에, 빠르게 조회 가능
• 아쉬운 점: 하나 고치려면 통째로 다시 써야 함
• 언제 쓰나: 주로 읽기만 하고 수정은 별로 안 할 때

Struct가 자주 업데이트하는 걸 싫어하는 이유

음식점 상황을 생각해보자. 서빙하는 입장에서:

기존 테이블 방식 (정규화): 주문 항목마다 따로 전표를 쓴다. 손님이 하나 바꾸고 싶다고 하면 그 전표만 버리고 새로 쓰면 된다.

Struct 방식: 전체 주문을 하나의 큰 전표에 다 적는다. 손님이 하나만 바꾸고 싶어도 전체 전표를 지우고 처음부터 다시 써야 한다.

-- 정규화된 테이블: 간단한 업데이트
UPDATE order_items SET quantity = 3 WHERE order_id = 123 AND item = '피자';

-- Struct: 복잡한 업데이트 - 배열 전체를 다시 써야함
UPDATE orders 
SET items = ARRAY(
  SELECT CASE 
    WHEN item.name = '피자' 
    THEN STRUCT(item.name, 3 as quantity, item.price)
    ELSE item
  END
  FROM UNNEST(items) as item
)
WHERE order_id = 123;

그래서 struct는 분석용(주로 읽기)에는 짱이지만, 실시간으로 막 업데이트하는 시스템에는 골치 아픈 존재가 될 수 있다.

데이터 엔지니어의 Struct 생존법

1. 스키마 변화: 성장통은 피할 수 없다

Struct는 사춘기 애들 같다. 자라면서 변하는 건 당연한데, 항상 예쁘게 변하지는 않는다. 새 필드 추가는 보통 괜찮지만, 기존 걸 없애거나 이름 바꾸는 건 뒤쪽 시스템들을 다 터트릴 수 있다.

2. 저장 용량: 크기가 다 하는 거 아니다

Struct를 여행 짐 싸기라고 생각해보자. 잘 정리된 struct는 테트리스 고수가 싼 캐리어 같다. 모든 게 딱딱 맞아떨어진다. 하지만 빈 공간 투성이인 struct는 스티로폼만 잔뜩 들어있는 택배상자 같다. 공간 낭비의 끝판왕이다.

3. 성능 패턴: 고속도로 vs 골목길 탐험

• 잘 되는 것: 관련 데이터 통째로 가져오기 (고속도로 쌩쌩)
• 안 되는 것: 특정 중첩값 찾기 (골목길 헤매기)

4. 플랫폼 호환성: 각자 다른 언어 쓰는 느낌

데이터베이스마다 struct 지원이 제각각이다. BigQuery는 struct 마니아고, Spark도 잘 안다. 하지만 구형 시스템들은 통역사가 필요하거나 아예 못 알아듣는다.

5. 메모리 사용: 마트료시카 인형 효과

Struct 배열을 메모리에서 풀어헤치면 러시아 인형 까는 것 같다. 처음엔 하나였는데 갑자기 개별 조각들이 우르르 쏟아져 나와서 메모리를 다 차지한다.

흔한 Struct 함정들 (그리고 피하는 법)

“인셉션” 병

Struct를 너무 깊게 중첩하지 말자. 상자 안의 상자 안의 서랍 안의 창고에서 뭔가를 찾는 거나 마찬가지다. 나중에 아무도 뭐가 어디 있는지 기억 못한다.

“만능 주머니” 증후군

struct에 뭐든 넣을 수 있다고 해서 다 넣으면 안 된다. 동전부터 영수증까지 다 들어있는 지갑 같은 꼴이 된다. 기술적으론 가능하지만 현실적으론 지옥이다.

“업데이트 지옥”

자주 바뀌는 데이터에 struct 쓰는 건 코팅된 메뉴판 같다. 가격 하나 바뀔 때마다 통째로 새로 만들어야 한다.

언제 Struct 쓸지 말지 정하기

이럴 때는 Struct 고고:

• 원래부터 중첩된 형태의 데이터일 때 (주소, 상품 정보, 프로필 같은 것들)
• 주로 읽기만 하고 개별 수정은 거의 안 할 때
• 중첩된 필드들 사이의 관계를 분석해야 할 때
• 분석이나 리포팅 시스템 만들 때

이럴 때는 Struct 피하기:

• 개별 데이터를 자주 수정할 때
• 특정 중첩값을 계속 검색하거나 인덱싱해야 할 때
• 동시접속 많은 실시간 시스템 만들 때
• 팀이 복잡한 걸 감당하기 어려울 때

정리하자면

Struct는 데이터를 위한 똑똑한 비서 같은 존재다. 관련 정보들을 예쁘게 정리해주고 특정 작업들을 훨씬 쉽게 만들어준다. 하지만 모든 비서가 그렇듯이, 적재적소에 써야 한다. 기존의 좋은 데이터베이스 설계 원칙들을 대체하는 게 아니라, 도구상자에 하나 더 추가된 거다.

핵심은 언제 파일링 캐비닛(기존 테이블)을 쓸지, 언제 정리된 서류가방(struct)을 쓸지 아는 것이다. 둘 다 데이터 엔지니어 세계에서 각자 역할이 있고, 최고의 솔루션은 보통 둘을 전략적으로 섞어 쓰는 거다.

기억하자: struct는 “테이블과 행"으로 생각하던 걸 “문서와 객체"로 생각하게 바꾸는 변화다. 이런 패러다임 전환을 받아들이되, 수십 년간 관계형 데이터베이스에서 배운 것들은 버리지 말자. 데이터 엔지니어링의 미래는 하나를 선택하는 게 아니라, 각 도구를 언제 제대로 쓸지 아는 데 있다.