Lakehouse에도 스키마가 생겼어요 — dbo 말고 나눠 쓰는 법

원문: Lakehouse schemas 게시일: 2026-02-24 · 저자: Sneha Gunda

레이크하우스를 새로 만들 때 대화상자를 자세히 보면 “Lakehouse schemas”라는 체크박스가 기본으로 켜져 있어요. 대충 넘기고 만들면 나중에 테이블이 수백 개로 늘어난 다음에야 이게 뭘 의미했는지 깨닫게 돼요. SQL Server의 dbo 스키마에 익숙한 사람이라면 반가운 기능이지만, 몇 가지는 미리 알고 시작하는 게 좋아요.

왜 스키마가 필요해졌나요

레이크하우스가 작을 때는 테이블을 한 줄로 쭉 나열해도 문제가 없어요. 하지만 조직이 커지면 상황이 달라져요.

• 업무 영역별로 테이블을 정리할 수 있어요. sales, marketing, hr처럼 이름 붙은 묶음으로 테이블을 나눌 수 있어요.
• 스키마 단위로 접근을 제어할 수 있어요. 팀마다 다른 스키마에 접근 권한을 주고, 그 안의 테이블에 행 수준·열 수준 보안을 적용할 수 있어요.
• 워크스페이스를 넘나드는 조회가 가능해요. workspace.lakehouse.schema.table 형태의 4파트 네임스페이스로, 서로 다른 레이크하우스·워크스페이스의 테이블을 한 Spark SQL 쿼리에서 조인할 수 있어요.
• 외부 데이터를 스키마 단위로 끌어올 수 있어요. 스키마 샷컷¹을 쓰면 다른 레이크하우스나 ADLS Gen2의 폴더를 스키마로 매핑해서, 외부 델타 테이블을 로컬 테이블처럼 보이게 할 수 있어요.
• 일부 고급 기능은 스키마가 있어야만 써요. 구체화된 레이크 뷰(materialized lake views) 같은 기능이 여기 해당돼요.

스키마 이름에는 영문자·숫자·밑줄(_)만 쓸 수 있다는 제약도 기억해둘 만해요.

만들 때 정하는 것 — dbo는 기본으로 딸려 와요

Fabric 포털에서 레이크하우스를 만들 때는 스키마가 기본으로 켜져 있어요. 체크박스를 그대로 두면 스키마를 쓰는 레이크하우스가 되고, 해제하면 스키마 없는 예전 방식의 레이크하우스가 돼요. REST API로 만들 때는 반대로 기본값이 꺼짐이라, enableSchemas: true를 명시적으로 넣어야 스키마가 활성화돼요.

POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/lakehouses

{
  "displayName": "Lakehouse_created_with_schema",
  "creationPayload": {
    "enableSchemas": true
  }
}

스키마를 켠 레이크하우스에는 이름을 바꾸거나 지울 수 없는 dbo 기본 스키마가 자동으로 생겨요. 새 스키마는 Tables 영역에서 마우스 오른쪽 메뉴로 “New schema”를 선택해 이름만 지으면 알파벳 순으로 목록에 추가돼요.

노트북에서 코드로 만들 때도 마찬가지로 명시가 필요해요. notebookutils.lakehouse.create를 쓸 때 enableSchemas 옵션을 함께 넘기면 스키마가 켜진 레이크하우스가 만들어져요. 여러 팀·부서 단위로 레이크하우스를 반복 생성하는 스크립트를 짠다면, 이 옵션을 빠뜨리지 않았는지부터 확인하는 게 좋아요.

기존 레이크하우스는 지금 당장 바꿀 수 없어요

여기가 실무에서 제일 자주 놓치는 부분이에요. 스키마가 나오기 전에 만들어둔 레이크하우스는 스키마를 지원하지 않고, 데이터를 옮기거나 다운타임 없이 스키마 있는 레이크하우스로 바꿔주는 마이그레이션 도구가 아직 없어요. 즉 스키마를 쓸지 말지는 사실상 레이크하우스를 만드는 시점에 정해지는 선택이에요.

당장 전환할 수 없다고 손 놓고 있을 필요는 없어요. 스키마 없는 레이크하우스에서도 코드에서는 미리 workspace.lakehouse.dbo.table 같은 4파트 이름을 써두는 방법이 있어요. dbo 스키마가 아직 실제로 존재하지 않아도 Spark가 이 문법을 받아주기 때문에, 나중에 스키마가 활성화됐을 때 쿼리를 크게 고치지 않아도 돼요.

Spark·SQL에서 참조하는 법이 달라져요

코드에서 테이블을 저장할 때 스키마 이름을 붙이지 않으면 자동으로 dbo 스키마로 들어가요.

# schema.table
df.write.mode("overwrite").saveAsTable("marketing.productdevelopment")

스키마와 스키마 없는 레이크하우스를 동시에 다루는 코드도 짤 수 있어요. 스키마 없는 쪽은 스키마 부분을 생략하고 lakehouse.table이나 workspace.lakehouse.table로만 참조하면 돼요.

-- 스키마 있는 레이크하우스: workspace.lakehouse.schema.table
-- 스키마 없는 레이크하우스: workspace.lakehouse.table
SELECT *
    FROM my_workspace.sales_lakehouse.retail.orders AS schema_table
    INNER JOIN my_workspace.legacy_lakehouse.customers AS nonschema_table
    ON schema_table.customer_id = nonschema_table.id;

노트북의 객체 탐색기도 테이블을 스키마별로 묶어서 보여주고, 테이블을 코드 셀로 드래그하면 스키마까지 포함한 참조 코드가 자동으로 생성돼요. 다만 노트북에서 스키마 문법을 쓰려면 그 노트북의 기본 레이크하우스가 스키마 지원 레이크하우스여야 하거나, 아예 기본 레이크하우스를 지정하지 않은 상태여야 해요.

Power BI에서는 스키마가 이름 충돌을 대신 풀어줘요

스키마를 나누는 실익은 Power BI 리포트 작성 단계에서도 체감돼요. 스키마가 없던 시절에는 테이블 이름이 곧 유일한 식별자라서, orders라는 이름을 이미 어딘가 다른 테이블이 쓰고 있으면 새로 이름을 지어내야 했어요. 스키마가 있는 레이크하우스에서 시맨틱 모델을 만들 때는 sales.orders와 legacy.orders처럼 같은 이름이 서로 다른 스키마에 있어도 되고, 모델 보기에서 겹치는 이름에는 자동으로 번호가 붙어 구분돼요. 이름 규칙을 팀끼리 맞추려고 애쓰는 대신, 스키마 경계로 자연스럽게 네임스페이스를 나눠 쓸 수 있는 셈이에요.

아직 남아있는 제약

• 워크스페이스 단위 공유가 아직 안 돼요. 스키마가 있는 레이크하우스는 워크스페이스 수준 공유로 바로 공유할 수 없어요. 대신 사용자가 워크스페이스 역할을 가진 다른 레이크하우스에 샷컷을 만들어서 우회해야 해요.
• ADLS 외부 테이블 메타데이터를 직접 지원하지 않아요. OneLake 샷컷을 통해 외부 델타 테이블을 참조하는 방식으로 대신해야 해요.

정리

레이크하우스 스키마는 SQL Server의 dbo 관습을 레이크하우스로 가져온 기능이에요. 업무 영역별 정리, 스키마 단위 보안, 워크스페이스 간 조회처럼 얻는 게 분명하지만, 스키마 여부는 레이크하우스를 만드는 순간 사실상 고정되고 지금은 되돌리거나 나중에 바꾸는 도구가 없어요. 새로 레이크하우스를 만든다면 스키마를 켜둘지부터, 코드에서 4파트 네임스페이스를 미리 습관 들일지까지 먼저 정하고 시작하는 게 좋아요.

---

어휘 주석

1. 스키마 샷컷(schema shortcut): 다른 레이크하우스나 ADLS Gen2 폴더에 있는 델타 테이블들을 통째로 하나의 스키마로 매핑해서, 데이터를 복사하지 않고도 로컬 테이블처럼 보이게 하는 기능이에요. 원본이 바뀌면 자동으로 반영돼요.