SQL 결과를 화면에 보여줄 때 컬럼 이름만으로는 부족할 때가 있습니다. name이 users.name인지, orders.name인지 알아야 링크, 설명, 권한 처리, 데이터 계보를 정확히 붙일 수 있기 때문입니다. 이때 필요한 것이 SQLite column metadata입니다.
다만 여기서 말하는 “컬럼 메타데이터”는 한 가지가 아닙니다. 테이블 정의를 묻는 메타데이터와, SELECT 결과 컬럼의 출처를 묻는 메타데이터를 구분해야 합니다.
테이블 컬럼 정보와 결과 컬럼 출처는 다르다
먼저 테이블 스키마의 컬럼 정보가 있습니다.
SQLite C API의 sqlite3_table_column_metadata()는 특정 테이블의 특정 컬럼에 대해 선언 타입, collation, NOT NULL, PRIMARY KEY, AUTOINCREMENT 여부를 돌려줍니다.1 즉 users.id라는 컬럼 자체의 정의를 확인하는 API입니다.
반면 다음과 같은 쿼리를 생각해 봅니다.
SELECT users.id AS user_id, orders.name, random()
FROM users
JOIN orders ON orders.user_id = users.id;여기서 알고 싶은 것은 결과의 첫 번째 컬럼이 원래 users.id에서 왔는지, 두 번째 컬럼이 orders.name에서 왔는지, 세 번째 컬럼처럼 표현식이라 원본 컬럼이 없는지입니다. 이 문제는 테이블 정의 조회가 아니라 결과셋 컬럼의 출처 추적입니다.
결과 컬럼 출처는 SQLite 기능과 바인딩 노출 여부가 함께 중요하다
SQLite에는 결과 컬럼의 원본 정보를 다루는 C API가 있습니다. 예를 들어 sqlite3_column_table_name()은 결과 컬럼의 원본 테이블 이름을 반환할 수 있습니다. 다만 이 계열의 컬럼 메타데이터 API는 SQLite가 SQLITE_ENABLE_COLUMN_METADATA 옵션으로 컴파일되어 있어야 사용할 수 있습니다.
문제는 여기서 끝나지 않습니다. SQLite가 해당 정보를 제공할 수 있더라도, 개발자가 쓰는 언어 바인딩이 그 기능을 노출해야 실제 애플리케이션에서 편하게 사용할 수 있습니다.
예를 들어 Microsoft.Data.Sqlite의 GetSchemaTable()은 결과 컬럼별로 BaseTableName, BaseColumnName, ColumnName, IsExpression, IsAliased 같은 정보를 제공합니다.2 표현식이면 원본 테이블과 컬럼이 NULL이 될 수 있다는 점도 중요합니다.2
반대로 Python 표준 sqlite3 모듈은 SQLite 컬럼 출처 정보를 직접 노출하지 않습니다. 이 경우에는 서드파티 바인딩을 검토해야 합니다. 예를 들어 APSW는 cursor.description_full을 통해 컬럼 메타데이터에 접근할 수 있습니다.
따라서 핵심 질문은 “SQLite가 이 정보를 알고 있는가?”만이 아닙니다. “현재 사용하는 런타임과 드라이버가 그 정보를 안전하고 일관되게 꺼내 주는가?”까지 확인해야 합니다.
PRAGMA는 스키마 조회에는 유용하지만 출처 추적의 답은 아니다
SQLite에서 컬럼 정보를 확인할 때 PRAGMA table_info 같은 문을 자주 사용합니다. PRAGMA는 SQLite 전용 SQL 확장으로, 라이브러리 동작을 바꾸거나 내부 비테이블 데이터를 조회하는 데 쓰입니다.3
PRAGMA를 사용할 때는 몇 가지 특성을 알아야 합니다.
다른 SQL 데이터베이스 엔진과 호환되지 않습니다.3
알 수 없는 PRAGMA 문은 오류 없이 무시될 수 있습니다.3
일부 PRAGMA는 실행 단계가 아니라 SQL 컴파일 단계에서 효과가 발생할 수 있습니다.3
인자는 괄호 형식이나 등호 형식으로 전달할 수 있으며, 두 문법은 동일한 결과를 냅니다.3
선택적으로 스키마 이름을 붙일 수 있고, 생략하면 기본적으로
main스키마가 가정됩니다.3
즉 PRAGMA는 “이 테이블에 어떤 컬럼이 정의되어 있는가?”를 확인하는 데 적합합니다. 하지만 조인, 별칭, CTE, 함수, 계산식이 섞인 임의의 SELECT 결과 컬럼을 원본 table.column으로 되돌리는 문제에는 결과셋 메타데이터 API가 더 직접적입니다.
우회 방법은 가능하지만 비용을 고려해야 한다
표준 바인딩이 결과 컬럼 출처를 노출하지 않는 환경에서는 몇 가지 선택지가 있습니다.
첫째, 컬럼 메타데이터를 제공하는 드라이버나 바인딩을 사용합니다. Python이라면 표준 sqlite3 대신 APSW 같은 대안을 검토할 수 있습니다.
둘째, SQLite C API에 직접 접근합니다. 이 경우 SQLITE_ENABLE_COLUMN_METADATA로 컴파일된 SQLite를 사용하고 있는지 확인해야 합니다.
셋째, 쿼리를 분석합니다. EXPLAIN 출력 분석은 SQLite 쿼리 결과 컬럼 출처를 추적하는 방법 중 하나로 언급됩니다. 다만 이 방식은 구현과 유지보수 비용이 커질 수 있으므로, 가능한 경우 드라이버가 제공하는 메타데이터 API를 먼저 확인하는 편이 현실적입니다.
적용 기준
SQLite column metadata를 다룰 때는 목적을 먼저 나누는 것이 가장 중요합니다.
테이블 정의를 알고 싶다면 sqlite3_table_column_metadata()나 PRAGMA table_info 같은 스키마 조회 도구를 사용합니다. 반대로 SELECT 결과의 각 컬럼이 어느 원본 테이블과 컬럼에서 왔는지 알아야 한다면, 결과셋 메타데이터를 노출하는 드라이버나 바인딩을 선택해야 합니다.
컬럼 이름만 믿는 방식은 단순한 쿼리에서는 충분해 보일 수 있습니다. 하지만 조인, 별칭, 표현식이 들어가면 금방 모호해집니다. SQLite column metadata는 결과를 더 안전하게 해석하고, UI·권한·데이터 계보 처리를 정확히 연결하기 위한 실용적인 기반입니다.
1Extract Metadata About A Column Of A Table
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.