케이블이 꽂혔다고 호환이 끝난 건 아니다: StarRocks와 MySQL 프로토콜의 진짜 경계

노트북에 USB-C 케이블을 꽂았다.

충전 표시가 뜬다. 그런데 외장 모니터는 검은 화면이고, 고속 데이터 전송도 안 된다. 같은 모양의 단자를 썼는데 왜 어떤 기능은 되고 어떤 기능은 안 될까?

데이터베이스에서도 비슷한 일이 생긴다.

StarRocks는 MySQL 프로토콜과 호환된다. MySQL Client나 DBeaver로 연결할 수 있고, 익숙한 SQL도 실행할 수 있다. 여기까지만 보면 이렇게 말하고 싶어진다.

“그럼 MySQL을 지원하는 도구라면 StarRocks도 전부 지원하는 것 아닌가?”

아쉽지만 그렇지 않다.

케이블이 꽂혔다는 사실과 충전·영상·고속 전송을 모두 지원한다는 사실이 다르듯, 프로토콜 호환과 제품 기능 전체의 호환도 다르다.

이 차이를 이해하면 데이터베이스 연결 문제를 훨씬 정확하게 설명할 수 있다.

StarRocks는 어떤 데이터베이스일까

StarRocks는 대규모 데이터를 빠르게 집계하고 분석하는 데 초점을 둔 분산 OLAP 데이터베이스다.

온라인 쇼핑몰을 예로 들어 보자. 주문 한 건을 저장하는 일보다 “오늘 지역별 매출은 얼마인가?”, “최근 한 시간 동안 가장 많이 팔린 상품은 무엇인가?” 같은 질문에 빠르게 답하는 데 강하다.

이를 위해 여러 노드가 일을 나눠 처리한다.

MySQL Client / BI Tool
        │
        │ MySQL protocol :9030
        ▼
FE · Frontend
  SQL 접수 · 인증 · 실행 계획 · 스케줄링
        │
        ├── BE · 실행 + 로컬 저장
        │
        └── CN · 실행 + 캐시
                  │
                  └── Object Storage

클라이언트가 처음 만나는 곳은 보통 FE다. FE는 SQL을 받아 해석하고, 어떤 노드가 어떤 계산을 맡을지 계획한다. 실제 데이터 처리와 집계는 BE나 CN이 나눠 수행한다.

StarRocks FE의 기본 MySQL query port는 9030이다.

mysql -h <fe-host> -P 9030 -u <user> -p

이 명령으로 연결됐다면 무엇을 확인한 걸까?

적어도 클라이언트와 FE가 MySQL 프로토콜로 대화할 수 있다는 사실은 확인했다. 하지만 아직 “모든 기능이 호환된다”는 결론에는 도달하지 않았다.

호환에는 세 층이 있다

“호환된다”는 말을 세 층으로 나누면 오해가 줄어든다.

1층: 프로토콜 호환

클라이언트가 서버와 연결하고, 로그인 요청을 보내고, SQL과 결과를 주고받을 수 있는가?

이 층이 맞으면 MySQL Client나 MySQL 계열 JDBC 도구로 StarRocks에 접속할 가능성이 열린다. USB-C 케이블이 단자에 들어가고 충전 표시가 뜨는 단계와 비슷하다.

2층: SQL과 메타데이터 호환

연결된 뒤에는 더 복잡한 질문이 시작된다.

스키마와 테이블 목록을 제대로 가져오는가?
StarRocks의 Catalog 구조를 이해하는가?
View와 Materialized View를 올바르게 구분하는가?
사용한 SQL 문법을 parser가 정확히 해석하는가?
대량의 객체를 탐색할 때 성능이 괜찮은가?

같은 MySQL 프로토콜을 사용해도 내부 객체 구조와 SQL 의미가 완전히 같지는 않다.

3층: 보안과 운영 기능 호환

마지막 층은 연결보다 훨씬 넓다.

실행한 SQL을 감사 로그로 남기는가?
SELECT, INSERT, DELETE를 구분해 통제하는가?
민감한 컬럼을 마스킹하는가?
승인받은 시간과 네트워크에서만 접속하게 하는가?
데이터베이스의 권한 모델과 접근제어 제품의 권한 모델이 맞물리는가?

여기까지 와야 “업무에서 필요한 기능을 지원한다”고 말할 수 있다.

연결 성공
  ≠ 객체 탐색 성공
  ≠ SQL 분석 성공
  ≠ 감사·권한·마스킹 지원

이 네 줄만 기억해도 “연결은 됐는데 왜 지원이 아니죠?”라는 질문에 훨씬 정확하게 답할 수 있다.

Catalog는 데이터 세계의 지도다

StarRocks를 이해할 때 빠뜨리기 쉬운 개념이 Catalog다.

Catalog는 데이터가 어디에 있는지 구분하는 최상위 지도다. StarRocks 내부 데이터뿐 아니라 Hive, Iceberg, Hudi 같은 외부 데이터도 Catalog를 통해 탐색할 수 있다.

Catalog
  └── Database
        └── Table / View / Materialized View

예를 들어 외부 Hive Catalog에 있는 매출 데이터를 조회한다고 해 보자.

SHOW CATALOGS;
SET CATALOG hive_catalog;
SHOW DATABASES;
USE analytics;

SELECT region, SUM(amount) AS total_amount
FROM sales
GROUP BY region
LIMIT 10;

SHOW CATALOGS는 사용할 수 있는 지도를 펼치는 명령이다. SET CATALOG는 그중 한 지역을 고르는 일이다. 그 뒤에야 Database와 Table을 찾아갈 수 있다.

그래서 어떤 도구가 StarRocks에 연결만 성공했다고 해서 객체 탐색까지 자연스럽게 되는 것은 아니다. 도구가 MySQL식 지도만 알고 있고 StarRocks의 Catalog를 모른다면, 케이블은 연결됐지만 파일 탐색기가 드라이브를 제대로 보여 주지 못하는 상황이 생긴다.

TCP 연결 성공은 데이터베이스 로그인 성공이 아니다

운영에서 특히 조심해야 할 장면이 있다.

TCP Proxy를 거쳐 데이터베이스에 접속한다고 해 보자. Proxy는 사용자의 IP와 접근 시간을 확인한 뒤 목적지까지 길을 열어 줄 수 있다.

사용자
  → TCP Proxy: 이 시간과 IP에서 접속 가능한가?
  → StarRocks: 이 DB 계정이 유효한가?
  → StarRocks: 이 Table을 SELECT할 권한이 있는가?

여기에는 서로 다른 확인이 세 번 있다.

Proxy 관점에서 연결이 성공해도, StarRocks의 ID/PW가 틀리면 데이터베이스 로그인은 실패할 수 있다. 로그인까지 성공해도 특정 Table의 SELECT 권한이 없으면 조회는 거부될 수 있다.

고속도로 톨게이트를 통과했다는 기록이 목적지 건물의 출입 승인까지 증명하지 않는 것과 같다.

따라서 로그도 분리해서 읽어야 한다.

Proxy Connect Success
  ≠ StarRocks 인증 성공
  ≠ SQL 실행 성공
  ≠ SQL 감사 로그 생성

연결 로그 한 줄을 보고 전체 기능이 성공했다고 판단하면, 장애 원인을 엉뚱한 층에서 찾게 된다.

접근 경로 통제와 데이터 권한은 다른 책임이다

접근제어 제품은 보통 “누가, 어디에서, 언제 이 데이터베이스 연결을 사용할 수 있는가?”를 통제한다.

StarRocks는 “로그인한 DB 사용자가 어떤 Catalog, Database, Table에서 어떤 작업을 할 수 있는가?”를 판단한다.

예를 들어 분석가 Alice가 매출 테이블을 조회한다고 해 보자.

접근제어 정책: Alice의 Connection 사용 허용
StarRocks 로그인: 성공
StarRocks 권한: analytics.sales SELECT 없음
최종 결과: 조회 실패

반대도 가능하다. Alice가 StarRocks에서 SELECT 권한을 갖고 있어도 허용된 네트워크 밖에서 접속하면 접근 경로가 열리지 않을 수 있다.

보안은 둘 중 하나를 고르는 문제가 아니다.

접근 경로 통제는 불필요한 연결을 줄인다.
데이터베이스 권한은 연결 뒤 할 수 있는 행동을 제한한다.
감사와 마스킹은 행동을 기록하고 민감정보 노출을 줄인다.

서로 다른 책임을 겹쳐 놓아야 최소 권한이 완성된다.

“지원되나요?” 대신 물어야 할 질문

새 데이터베이스와 도구를 연결할 때 “지원되나요?”라는 한 문장만 묻지 말자. 다음처럼 쪼개면 PoC 범위가 선명해진다.

어떤 버전과 build를 사용하는가?
실제 접속 endpoint와 port는 무엇인가?
어떤 Client와 JDBC driver를 사용하는가?
직접 접속과 Proxy 경유 접속이 모두 되는가?
어떤 Catalog를 사용하며 세션에서 어떻게 선택하는가?
테이블 목록과 View 같은 metadata가 정확히 보이는가?
Web Editor, Query Audit, Privilege, Masking 중 무엇이 필수인가?
접속 성공뿐 아니라 실패와 취소도 올바르게 기록되는가?

이 체크리스트의 장점은 “된다/안 된다” 싸움을 멈추게 한다는 것이다.

연결은 되지만 객체 탐색은 느릴 수 있다. 기본 조회는 되지만 특정 SQL 문법은 분석하지 못할 수 있다. 접속 경로는 통제하지만 SQL 감사는 남기지 못할 수 있다.

각 기능을 따로 검증하면 놀라움이 줄어든다.

호환은 명사가 아니라 문장이다

“StarRocks는 MySQL과 호환된다.”

이 문장은 틀리지 않았다. 다만 아직 짧다.

더 좋은 문장은 이렇다.

StarRocks는 MySQL 프로토콜을 사용해 클라이언트 연결과 기본 SQL 실행이 가능하다. 다만 Catalog 탐색, SQL 문법, 감사, 세부 권한, 마스킹 같은 기능은 도구와 버전 조합별로 따로 검증해야 한다.

호환성은 체크박스 하나가 아니다.

어느 층에서 호환되는지, 어떤 기능까지 시험했는지, 실패했을 때 어느 시스템이 판단했는지를 함께 적어야 비로소 쓸모 있는 정보가 된다.

다음에 케이블이 꽂히는 순간을 만나면 너무 빨리 박수치지 말자.

충전만 되는지, 화면도 나오는지, 파일도 빠르게 오가는지 확인해야 한다. 데이터베이스도 똑같다.

접속은 시작점이지, 지원의 종착점이 아니다.