---
title: "임시 테이블도 복제하면 되지 않을까요? ClickHouse에서 중간 결과를 나누는 방법"
date: 2026-10-25
status: review-draft
source_published_at: 2026-09-15
source_url: https://clickhouse.com/blog/replica-aware-routing-public-beta
---

# 임시 테이블도 복제하면 되지 않을까요?

서버 A에 임시 테이블을 만들었는데, 다음 요청이 B로 가면서 찾지 못했다고 해볼까요? “그러면 임시 테이블도 복제해 두면 되겠네요?”라는 생각이 자연스럽게 들겠지요.

그런데 ClickHouse에서는 **임시 테이블 자체를 복제형으로 만드는 방식은 지원하지 않습니다.** 공식 문서에서도 임시 테이블에 복제 엔진을 사용할 수 없으며, `ON CLUSTER`로 모든 서버에 만드는 것도 지원하지 않는다고 설명합니다. [임시 테이블 공식 문서](https://clickhouse.com/docs/reference/statements/create/table/temporary-table)

그렇다고 중간 결과를 여러 서버에서 함께 쓸 수 없다는 뜻은 아닙니다. 데이터를 어디에, 얼마나 오래 둘지부터 다시 고르면 됩니다.

## 잠깐 혼자 쓰는 메모와 함께 보는 작업장을 나눠볼까요?

임시 테이블은 한 세션에서 사용할 메모에 가깝습니다. 같은 작업의 다음 요청이라면, 같은 세션을 유지하고 같은 서버로 보내는 접근이 어울립니다. ClickHouse 팀도 이런 상황을 위해 관련 요청을 같은 레플리카로 보내는 방식을 소개했습니다. 다만 재시작·확장 때 경로는 바뀔 수 있다고 합니다. [Amy Chen·Jan Mensch의 사례 — 2026.09.15](https://clickhouse.com/blog/replica-aware-routing-public-beta)

반대로 서버 A에서 만든 중간 결과를 B나 다른 작업자도 읽어야 한다면 어떨까요? 이때는 임시 메모보다 **일반 테이블로 만든 공동 작업장**에 가깝게 생각해 보세요.

이를 흔히 작업용 테이블, 또는 스테이징 테이블이라고 부릅니다. 이름에 “임시”가 붙더라도 `CREATE TEMPORARY TABLE`로 만드는 객체와는 다릅니다. 작업이 끝나면 우리가 정리할 일반 테이블인 셈이지요.

## 직접 운영한다면 일반 복제 테이블을 작업용으로 쓸 수 있습니다

아래는 설명을 위한 예시입니다. Keeper와 매크로 설정을 마친 **1샤드·2레플리카** 클러스터 `demo_cluster`를 가정합니다. `{shard}`는 두 서버에서 같고 `{replica}`는 서로 달라야 합니다. 실제 환경에서 실행 검증한 운영 스크립트는 아닙니다.

```sql
CREATE TABLE default.work_items ON CLUSTER demo_cluster
(
    job_id UUID,
    item_id UInt64,
    value String,
    expires_at DateTime DEFAULT now() + INTERVAL 2 HOUR
)
ENGINE = ReplicatedMergeTree(
    '/clickhouse/tables/{shard}/default/work_items',
    '{replica}'
)
ORDER BY (job_id, item_id)
TTL expires_at DELETE;
```

여기서 역할을 나눠 보면 이해하기 쉽습니다.

- `ON CLUSTER`는 해당 서버들에 테이블 정의를 만듭니다. 이 구문 자체가 데이터를 복제하는 것은 아닙니다.
- `ReplicatedMergeTree`가 같은 샤드의 레플리카 사이에서 데이터를 복제합니다. 기본 복제는 비동기이므로, A의 쓰기 성공 직후 B에도 보인다고 가정하면 안 됩니다.
- `job_id`는 여러 작업의 행을 구분하기 위한 열입니다. 다른 작업의 데이터를 섞어 읽지 않도록 조회 조건에 넣습니다.

새로 생긴 데이터는 레플리카가 백그라운드에서 따라갑니다. 쓰자마자 다른 레플리카에서 읽어야 하는 작업이라면, 복제 확인과 조회 일관성도 별도로 설계해야겠지요. 서버 수를 늘렸다고 서로 다른 샤드의 모든 데이터가 각 서버에 생기는 것도 아닙니다. [복제 엔진 공식 설명](https://clickhouse.com/docs/reference/engines/table-engines/mergetree-family/replication)

## ClickHouse Cloud라면 공유 저장소의 일반 테이블을 생각하면 됩니다

Cloud에서는 같은 서비스의 일반 `MergeTree` 테이블이 내부적으로 `SharedMergeTree`로 처리됩니다. 앞의 직접 운영 예시를 그대로 가져와 레플리카별 복제를 수동 설정할 필요는 없습니다.

```sql
-- ClickHouse Cloud의 일반 테이블 예시
CREATE TABLE default.work_items
(
    job_id UUID,
    item_id UInt64,
    value String,
    expires_at DateTime DEFAULT now() + INTERVAL 2 HOUR
)
ENGINE = MergeTree
ORDER BY (job_id, item_id)
TTL expires_at DELETE;
```

여러 계산 서버가 공유 저장소의 데이터를 이용하는 구조입니다. 다만 새 데이터에 대한 정보는 비동기로 반영될 수 있어, 다른 서버에서 곧바로 조회하는 상황에는 확인이 필요합니다. 이것을 “모든 서버에 즉시 같은 상태가 보인다”는 뜻으로 받아들이지는 마세요. [SharedMergeTree 공식 문서](https://clickhouse.com/docs/products/cloud/features/infrastructure/shared-merge-tree)

## 작업이 끝난 데이터는 누가 치워줄까요?

일반 테이블은 세션을 닫아도 사라지지 않습니다. 대신 보관 기한을 정하고 정리하는 방식을 설계해야 합니다. 위 예시의 `TTL`이 그 역할을 돕습니다.

여기서 “2시간이 되면 정확히 그 순간 삭제된다”고 생각하면 안 됩니다. TTL 정리는 백그라운드 병합 과정에서 진행됩니다. 기한 지난 데이터를 조회에서 바로 빼고 싶다면, 예시처럼 유효 시간도 조건으로 확인할 수 있습니다. [TTL 동작 설명](https://clickhouse.com/docs/concepts/features/operations/delete/ttl)

```sql
SELECT item_id, value
FROM default.work_items
WHERE job_id = toUUID('11111111-1111-4111-8111-111111111111')
  AND expires_at > now();
```

`job_id` 조건은 작업을 구분하는 장치이지 권한 검사를 대신하는 장치는 아닙니다. 여러 사용자가 쓰는 서비스라면 접근 범위도 따로 정해야 합니다.

## 두 방법 중 무엇이 필요할까요?

한 세션 안에서 작은 데이터를 잠깐 계산한다면 임시 테이블이 간단합니다. 여러 서버나 다음 작업이 결과를 이어받아야 한다면 일반 작업용 테이블과 보관 정책을 검토하는 편이 맞겠지요.

또한 Memory 임시 테이블을 사용하는 분산 쿼리는 그 쿼리를 처리할 원격 서버에 데이터를 전달할 수 있습니다. 하지만 이것은 다른 세션에서 계속 조회할 복제 테이블을 만든다는 뜻은 아닙니다. [임시 테이블의 분산 쿼리 범위](https://clickhouse.com/docs/reference/statements/create/table/temporary-table)

오늘의 질문은 “임시 테이블에 복제를 켤까?”에서 한 걸음 옮겨보면 좋겠습니다. **이 데이터는 한 세션의 메모인가요, 여러 작업자가 이어받아야 할 결과인가요?** 그 답에 따라 둘 자리가 달라집니다.

---

## 출처

- 주제 원문: [Replica-aware routing public beta](https://clickhouse.com/blog/replica-aware-routing-public-beta)
- 작성자·매체: Amy Chen, Jan Mensch · ClickHouse Blog
- 원문 게시일: 2026년 9월 15일 / 확인일: 2026년 10월 25일
- 기술 검증 보조 자료: 위 본문에 연결한 ClickHouse 공식 임시 테이블·복제·SharedMergeTree·TTL 문서. 문서의 최초 게시일은 확인하지 않았으며, 최신 기능 확인용 참조로 사용했습니다.
- 자체 구성: 공동 작업장 비유, 작업용 테이블 설계와 SQL 예시. 원문 팀의 실제 스키마를 옮긴 것은 아닙니다.