SQL Server 하던 사람이 Fabric Warehouse에서 당황하는 T-SQL 차이

원문: T-SQL Surface Area in Fabric Data Warehouse 게시일: 2026-08-26 · 저자: William Assaf

SQL Server를 오래 다뤄온 사람일수록 Fabric Warehouse를 처음 열었을 때 착각하기 쉬워요. “T-SQL 쓴다며, 그럼 다 되겠지”라고요. 절반만 맞는 말이에요. Fabric Warehouse는 SQL Server 엔진을 그대로 클라우드에 올린 게 아니라, 분산 처리에 맞게 다시 만든 엔진이라서 지원하는 T-SQL 명령의 범위(Surface Area)¹가 따로 정해져 있어요. Microsoft가 이 범위를 별도 문서로 관리한다는 사실 자체가, 온프레미스 습관을 그대로 옮기면 안 된다는 신호예요.

문제는 이 범위가 계속 바뀐다는 거예요. 몇 달 전에 안 되던 게 지금은 되고, 반대로 커뮤니티에 떠도는 “이건 안 됩니다” 글이 이미 옛날 정보인 경우도 많아요. 그래서 마이그레이션 전에는 소문이 아니라 최신 Surface Area 문서를 직접 확인하는 게 안전해요.

근본 원인은 단순해요. Fabric Warehouse는 하나의 서버가 디스크를 붙잡고 도는 SQL Server 인스턴스가 아니라, 컴퓨트와 스토리지가 분리된 분산 엔진이에요. 단일 서버에서는 자연스러운 트리거·전역 임시 테이블 같은 동작이, 여러 노드가 나눠서 처리하는 구조에서는 구현 자체가 까다롭거나 아예 다른 방식으로 풀어야 해요. 그래서 “SQL Server에 있던 기능인데 왜 없지”보다는 “분산 환경에서 이 기능이 필요한 이유가 아직 있는지”부터 따져보는 게 낫습니다.

이미 되는데 안 된다고 오해하는 것들

의외로 마이그레이션 체크리스트에 잘못 올라오는 항목이 있어요.

IDENTITY 열: Fabric Warehouse에서 지원돼요. 자동 증가 키를 못 쓴다고 지레 겁먹을 필요 없어요.
MERGE 문: 지원되고, 이제는 정식 기능(GA)이에요. Upsert 로직을 굳이 INSERT/UPDATE 두 문장으로 쪼갤 필요 없어요.
임시 테이블(#temp): 세션 범위로 지원돼요. 다만 SQL Server처럼 전역 임시 테이블(##temp)까지 기대하면 안 돼요.
CTE(공용 테이블 식): 표준·순차·중첩 CTE를 모두 지원해요. 중첩 CTE만 아직 프리뷰 단계예요.
TRUNCATE TABLE: 지원돼요. 대량 삭제를 굳이 DELETE로 돌릴 필요 없어요.
쿼리·조인 힌트: 전체가 아니라 일부만 지원돼요. 힌트에 크게 의존하던 튜닝 로직이 있다면 지원 목록부터 확인해야 해요.

이 네 가지는 실무 회의에서 “그거 Fabric에서 안 되지 않아요?“라는 말이 자주 나오는 항목이라 먼저 짚을 가치가 있어요.

정말 안 되는 것들 — 쓰면 문제가 생겨요

문서는 이 목록을 그냥 “미지원”이 아니라 “시도하지 말라”고 못 박아요. 겉보기엔 성공한 것처럼 보여도 나중에 웨어하우스에 문제를 일으킬 수 있다는 뜻이에요.

트리거(Triggers): 전혀 지원하지 않아요. 데이터 변경에 반응하는 로직은 트리거 대신 파이프라인이나 애플리케이션 레이어로 옮겨야 해요.
구체화된 뷰(Materialized Views): 지원하지 않아요.
동의어(Synonyms): 지원하지 않아요. 스키마 이름까지 포함해 참조를 명시적으로 관리해야 해요.
재귀 쿼리(Recursive queries): 지원하지 않아요. 계층 구조를 다룰 때 재귀 CTE에 의존하던 코드는 다시 설계해야 해요.
BULK LOAD: 지원하지 않아요. 다만 bcp는 프리뷰 기능으로 쓸 수 있고, 실무에서는 파이프라인·COPY 계열 방식을 더 권장해요.
CREATE USER: 지원하지 않아요. 사용자·권한 관리는 Fabric 워크스페이스 역할 체계로 옮겨야 해요.
시스템 테이블·사용자 테이블을 직접 대상으로 하는 쿼리: 지원하지 않아요.
SET TRANSACTION ISOLATION LEVEL, SET ROWCOUNT: 지원하지 않아요.
sp_showspaceused: 지원하지 않아요. 저장 공간 확인은 다른 방법을 써야 해요.
벡터(vector) 데이터 타입과 검색 함수: 지원하지 않아요. AI 함수(프리뷰)는 별도로 있지만 벡터 타입 자체는 아직이에요.
FOR JSON: 지원은 하지만 쿼리의 맨 마지막 연산자로만 써야 해요. 서브쿼리 안에서는 못 써요.
스키마·테이블 이름에 /나 \: 쓸 수 없어요.

ALTER TABLE은 할 수 있는 것만 정해져 있어요

SQL Server에서는 ALTER TABLE로 웬만한 걸 다 고쳤다면, Fabric Warehouse에서는 지원 범위가 명확히 좁혀져 있어요.

ADD로 nullable 열을 추가하는 것과 DROP COLUMN은 지원돼요.
기본 키·고유 키·외래 키 제약을 추가할 수 있지만, 반드시 NOT ENFORCED² 옵션과 함께여야 해요. 즉 제약이 실제로 강제되지 않고 옵티마이저 힌트에 가까운 역할을 해요. 이 조건이 아닌 다른 ALTER TABLE 시도는 막혀 있어요.
열 이름 변경은 ALTER TABLE ... ALTER COLUMN 대신 sp_rename 저장 프로시저를 써야 해요. ALTER COLUMN으로 데이터 타입 자체를 바꾸는 기능은 아직 프리뷰예요.
지원되는 ALTER TABLE 문은 명시적 트랜잭션 안에서 실행할 수 있어요.

웨어하우스와 SQL analytics endpoint는 권한이 달라요

같은 T-SQL이라도 대상이 웨어하우스인지, 레이크하우스의 SQL analytics endpoint³인지에 따라 할 수 있는 일이 갈려요. 테이블을 만들고(CREATE TABLE) 고치고 지우는 것, 그리고 INSERT/UPDATE/DELETE는 웨어하우스에서만 가능해요. SQL analytics endpoint에서는 이미 있는 델타 테이블 위에 뷰·함수·프로시저를 얹어서 읽는 용도로만 T-SQL을 쓸 수 있어요. 마이그레이션 설계 단계에서 “쓰기가 필요한 데이터는 웨어하우스로, 조회 전용은 레이크하우스로”라는 구분을 먼저 해두면 나중에 권한 문제로 헤매지 않아요.

정리

Fabric Warehouse의 T-SQL은 SQL Server의 부분집합이 아니라, 분산 엔진에 맞춰 다시 그은 별도의 경계선이에요. IDENTITY·MERGE·CTE처럼 이미 되는 걸 안 된다고 오해하지 말고, 대신 트리거·구체화된 뷰·재귀 쿼리·BULK LOAD·CREATE USER처럼 확실히 안 되는 것들은 마이그레이션 설계 초기에 대체 방안을 정해두세요. 이 경계선은 계속 넓어지고 있으니, 확신이 안 서면 Learn의 Surface Area 문서를 그때그때 다시 확인하는 습관이 제일 안전해요.

어휘 주석

Surface Area(서피스 에어리어): 특정 제품이나 엔진이 지원하는 명령·문법의 전체 범위를 가리키는 표현이에요. Fabric Warehouse 문서에서는 “SQL Server의 T-SQL 중 여기서 실제로 쓸 수 있는 부분”을 뜻해요.
NOT ENFORCED 제약: 데이터베이스가 실제로 값을 검사해서 위반을 막아주는 제약이 아니라, 옵티마이저에게 “이 관계가 성립한다고 가정해도 된다”는 힌트만 주는 제약이에요. 데이터 정합성은 적재 과정에서 직접 보장해야 해요.
SQL analytics endpoint: Fabric 레이크하우스에 쌓인 델타 테이블을 T-SQL로 읽을 수 있게 자동으로 열어주는 조회 전용 엔드포인트예요. 웨어하우스처럼 직접 쓰기 작업은 할 수 없어요.