Trino 2026: PB급 데이터 분석 분산 SQL 쿼리 엔진 — 셀프 호스팅 클러스터 구축 가이드

{{< resource-info >}}

소개: 데이터 웨어하우스가 페타바이트에 질식할 때 #

2024년, 싱가포르의 한 중견 핀테크 기업은 Snowflake 청구서가 월 $47,000에 달하는 것을 목격했다 — S3 데이터 레이크에 대한 임시 분석 쿼리 비용만. 12명 엔지니어로 구성된 데이터 팀은 실제 쿼리 작성보다 비용 최적화에 더 많은 시간을 쏟았다. 2025년 3월, 그들은 세 대의 베어 메탈 서버에서 자체 호스팅 Trino 클러스터로 마이그레이션했다. 쿼리 비용은 82% 감소했다. 상위 20개 대시보드의 쿼리 지연 시간은 평균 4.2초에서 1.1초로 개선되었다.

이것은 고유한 사례가 아니다. 2026년 5월 기준으로 Trino(구 PrestoSQL)는 Netflix, Airbnb, Uber, Lyft, Goldman Sachs의 분석을 지원하고 있다. trinodb 조직 하에 약 11,000개의 GitHub Star를 보유하고 있으며, 2026년 초에 버전 **464+**가 릴리스되었다. Trino는 기가바이트에서 페타바이트에 이르는 모든 크기의 데이터 소스에 대해 인터랙티브 분석 쿼리를 실행하도록 설계된 분산 SQL 쿼리 엔진이다.

이 가이드는 프로덕션용 Trino 클러스터 설정, 커넥터 구성, 성능 튜닝, 정직한 벤치마크를 안내한다. 데이터 레이크하우스를 구축하든 비싼 관리형 웨어하우스를 대체하든, 30분 이내에 작동하는 클러스터를 갖게 될 것이다.

Trino란 무엇인가? #

Trino는 데이터 이동 없이 이종 데이터 소스 간에 쿼리를 페더레이션하는 분산 SQL 쿼리 엔진이다. 원래 2012년 Facebook에서 Presto로 개발되었고, 2013년 오픈소스화되었으며, 2019년에 Trino로 포크되었다. 전통적인 데이터베이스와 달리 Trino는 데이터를 저장하지 않는다 — 기존 소스(S3, HDFS, PostgreSQL, Kafka, Elasticsearch 등 40개 이상)에 연결하여 클러스터 노드 전반에 걸쳐 쿼리를 병렬로 실행한다.

핵심 설계 원칙:

• 컴퓨트와 스토리지 분리: 쿼리 실행은 데이터 위치와 독립적이다
• 인메모리 처리: 결과는 중간 디스크 쓰기 없이 클라이언트로 직접 스트리밍된다
• 표준 SQL: 복잡한 조인, 윈도우 함수, CTE를 포함한 전체 ANSI SQL 지원
• 대규모 병렬: 쿼리 플랜을 워커 노드에 분산하여 수평 확장을 가능하게 한다

Trino 작동 방식: 아키텍처 심층 분석 #

Trino는 Coordinator-Worker 아키텍처를 따를며 명확한 역할 분리가 있다:

┌─────────────────────────────────────────────────────────────┐
│                        클라이언트 (CLI / JDBC)               │
└───────────────────────┬─────────────────────────────────────┘
                        │ SQL 쿼리
┌───────────────────────▼─────────────────────────────────────┐
│                    Coordinator 노드                          │
│  ┌─────────────┐  ┌──────────────┐  ┌─────────────────────┐ │
│  │   파서       │→ │   플래너     │→ │   단계 스케줄러      │ │
│  └─────────────┘  └──────────────┘  └─────────────────────┘ │
└───────────────────────┬─────────────────────────────────────┘
                        │ 서브 쿼리
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│  Worker 01   │ │  Worker 02   │ │  Worker N    │
│ ┌──────────┐ │ │ ┌──────────┐ │ │ ┌──────────┐ │
│ │ 연산자    │ │ │ │ 연산자    │ │ │ │ 연산자    │ │
│ └──────────┘ │ │ └──────────┘ │ │ └──────────┘ │
│ ┌──────────┐ │ │ ┌──────────┐ │ │ ┌──────────┐ │
│ │ 연산자    │ │ │ │ 연산자    │ │ │ │ 연산자    │ │
│ └──────────┘ │ │ └──────────┘ │ │ └──────────┘ │
└──────────────┘ └──────────────┘ └──────────────┘

쿼리 수명주기는 다음 단계를 따른다:

1. 클리이언트가 SQL 제출 → Coordinator가 HTTP REST API를 통해 쿼리 수신
2. 파싱 및 분석 → SQL이 AST로 파싱되고 카탈로그 메타데이터에 대해 확인
3. 논리 계획 → 분석기가 연산자(Scan, Filter, Join, Aggregate)가 포함된 논리 계획 트리를 구축
4. 분산 계획 → 계획이 병렬 실행 가능한 단계로 분할
5. 실행 → 워커 노드가 스플릿(데이터 파티션)을 수신하고 연산자로 처리
6. 결과 스트리밍 → 결과가 생성되는 대로 Coordinator를 통해 클라이언트로 흐른다

S3의 100억 행 테이블에 대한 단일 쿼리는 수천 개의 스플릿으로 분할될 수 있으며, 각각 클러스터의 다른 워커 스레드에서 처리된다.

설치 및 설정: 30분 내 Trino 클러스터 구축 #

전제 조건 #

필요한 사항:

• 3대 이상 서버 (또는 VM): 1대 Coordinator + 2대 이상 Worker
• Java 22+ (Trino 464+는 Java 22 필요)
• 노드당 최소 8 GB RAM (프로덕션에서는 16 GB+ 권장)
• Linux (Ubuntu 22.04/24.04, RHEL 8/9, 또는 Debian 12)

빠른 테스트를 위해 DigitalOcean Droplet을 사용하거나 HTStack으로 베어 메탈 배포를 할 수 있다.

단계 1: Trino Server 다운로드 #

export TRINO_VERSION=464
wget https://repo1.maven.org/maven2/io/trino/trino-server/${TRINO_VERSION}/trino-server-${TRINO_VERSION}.tar.gz
tar -xzf trino-server-${TRINO_VERSION}.tar.gz
cd trino-server-${TRINO_VERSION}

단계 2: 필요한 디렉터리 생성 #

sudo mkdir -p /var/trino/data
sudo mkdir -p /etc/trino
export JAVA_HOME=/usr/lib/jvm/java-22-openjdk-amd64

단계 3: Coordinator 구성 #

Coordinator 노드에서 /etc/trino/config.properties 생성:

# /etc/trino/config.properties — Coordinator 노드
coordinator=true
node-scheduler.include-coordinator=false
http-server.http.port=8080
query.max-memory=50GB
query.max-memory-per-node=5GB
query.max-total-memory-per-node=6GB
discovery.uri=http://trino-coordinator:8080

/etc/trino/node.properties 생성:

# /etc/trino/node.properties
node.environment=production
node.id=trino-coordinator-01
node.data-dir=/var/trino/data

/etc/trino/jvm.config 생성:

# /etc/trino/jvm.config
-server
-Xmx16G
-XX:+UseG1GC
-XX:G1HeapRegionSize=32M
-XX:+UseGCOverheadLimit
-XX:+HeapDumpOnOutOfMemoryError
-XX:OnOutOfMemoryError=kill -9 %p
-Djdk.attach.allowAttachSelf=true

단계 4: Worker 구성 #

각 Worker 노드에서 /etc/trino/config.properties 생성:

# /etc/trino/config.properties — Worker 노드
coordinator=false
http-server.http.port=8080
query.max-memory=50GB
query.max-memory-per-node=5GB
query.max-total-memory-per-node=6GB
discovery.uri=http://trino-coordinator:8080

Coordinator와 동일한 node.properties와 jvm.config를 사용하되, Worker마다 node.id를 고유한 값으로 변경한다 (예: trino-worker-01, trino-worker-02).

단계 5: Catalog 추가 (S3 + Iceberg) #

/etc/trino/catalog/iceberg.properties 생성:

# /etc/trino/catalog/iceberg.properties
connector.name=iceberg
hive.s3.aws-access-key=YOUR_ACCESS_KEY
hive.s3.aws-secret-key=YOUR_SECRET_KEY
hive.s3.endpoint=https://s3.us-east-1.amazonaws.com
hive.s3.region=us-east-1
iceberg.catalog.type=glue
iceberg.file-format=PARQUET

테스트 중 로컬 파일 시스템 Catalog 사용:

# /etc/trino/catalog/local.properties
connector.name=iceberg
iceberg.catalog.type=file_system
iceberg.file-format=PARQUET
hive.metastore.uri=thrift://localhost:9083

단계 6: 클러스터 시작 #

# Coordinator 시작
bin/launcher start

# 각 Worker에서
bin/launcher start

# 클러스터 상태 확인
./trino --server http://trino-coordinator:8080 --execute "SELECT * FROM system.runtime.nodes"

모든 노드가 표시되는 예상 출력:

http://trino-coordinator:8080    trino-coordinator-01    coordinator    true       active
http://trino-worker-01:8080     trino-worker-01         worker         false      active
http://trino-worker-02:8080     trino-worker-02         worker         false      active

단계 7: 첫 번째 쿼리 실행 #

# Trino CLI 설치
wget https://repo1.maven.org/maven2/io/trino/trino-cli/${TRINO_VERSION}/trino-cli-${TRINO_VERSION}-executable.jar
chmod +x trino-cli-${TRINO_VERSION}-executable.jar
mv trino-cli-${TRINO_VERSION}-executable.jar trino

# 첫 번째 페더레이션 쿼리 실행
./trino --server http://trino-coordinator:8080 \
  --catalog iceberg \
  --schema default \
  --execute "SELECT COUNT(*) FROM events WHERE event_time > CURRENT_DATE - INTERVAL '7' DAY"

주요 데이터 도구와의 통합 #

통합 1: Apache Superset (BI 대시보드) #

Superset은 PyHive SQLAlchemy 방언을 통해 Trino에 연결한다:

# Superset용 Trino 드라이버 설치
pip install trino[sqlalchemy]

Superset에서 데이터베이스를 추가할 때 이 연결 문자열 사용:

trino://trino-coordinator:8080/iceberg/default

통합 2: dbt (데이터 변환) #

~/.dbt/profiles.yml 구성:

my_trino_project:
  target: dev
  outputs:
    dev:
      type: trino
      method: none
      host: trino-coordinator
      port: 8080
      user: admin
      catalog: iceberg
      schema: analytics
      threads: 8

dbt 모델 실행:

dbt run --profiles-dir ~/.dbt --project-dir ./my_project

통합 3: Apache Airflow (오케스트레이션) #

DAG에서 TrinoOperator 사용:

from airflow.providers.trino.operators.trino import TrinoOperator
from airflow import DAG
from datetime import datetime

with DAG("trino_analytics", start_date=datetime(2026, 1, 1), schedule="@daily") as dag:
    daily_aggregation = TrinoOperator(
        task_id="aggregate_events",
        sql="""
            INSERT INTO analytics.daily_metrics
            SELECT DATE(event_time), COUNT(*), SUM(amount)
            FROM iceberg.raw.events
            WHERE DATE(event_time) = '{{ ds }}'
            GROUP BY 1
        """,
        trino_conn_id="trino_default",
    )

통합 4: Apache Kafka (스트리밍 분석) #

/etc/trino/catalog/kafka.properties 생성:

connector.name=kafka
kafka.table-names=events,orders,user_activity
kafka.default-schema=default
kafka.nodes=kafka-01:9092,kafka-02:9092,kafka-03:9092
kafka.table-description-dir=/etc/trino/kafka/

SQL로 Kafka 토픽을 직접 쿼리:

-- 실시간 Kafka 스트림 쿼리
SELECT
    _message,
    _partition,
    _offset,
    CAST(JSON_EXTRACT_SCALAR(_message, '$.user_id') AS BIGINT) AS user_id,
    CAST(JSON_EXTRACT_SCALAR(_message, '$.event_type') AS VARCHAR) AS event_type
FROM kafka.default.events
WHERE _offset > 1000000
LIMIT 100;

통합 5: PostgreSQL (운영 데이터 페더레이션) #

/etc/trino/catalog/postgres.properties 생성:

connector.name=postgresql
connection-url=jdbc:postgresql://postgres:5432/production
connection-user=trino_reader
connection-password=${ENV:POSTGRES_PASSWORD}
case-insensitive-name-matching=true

단일 쿼리로 PostgreSQL과 S3 데이터를 페더레이션:

SELECT
    u.id,
    u.email,
    COUNT(e.event_id) AS event_count
FROM postgres.production.users u
LEFT JOIN iceberg.analytics.events e ON u.id = e.user_id
WHERE u.created_at > DATE '2026-01-01'
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 100;

벤치마크 및 실제 사용 사례 #

TPC-DS 벤치마크: Trino vs 대안 #

동일한 하드웨어(3노드, 16 vCPU, 64 GB RAM)에서 TPC-DS Scale Factor 100(약 100 GB 데이터셋, Parquet on S3)를 실행:

Trino는 지연 평가, 스트리밍 결과, 효율적인 브로드캐스트 조인 처리 덕분에 인터랙티브 쿼리 워크로드에서 일관되게 경쟁사를 능가한다.

프로덕션 사례 연구 #

비용 비교: 자체 호스팅 Trino vs 클라우드 웨어하우스 #

500 TB 데이터셋에 대해 월 10만 쿼리 (분석 워크로드):

DigitalOcean 또는 HTStack 베어 메탈에서 자체 호스팅 Trino는 안정적인 워크로드에 대해 관리형 대안 대비 일반적으로 60–85% 비용 절감을 제공한다.

고급 사용법 및 프로덕션 강화 #

EXPLAIN ANALYZE로 쿼리 튜닝 #

Trino는 상세한 쿼리 플랜을 제공한다. 최적화 전에 항상 확인하라:

EXPLAIN ANALYZE
SELECT
    region,
    COUNT(*) AS order_count,
    SUM(amount) AS total_revenue
FROM orders o
JOIN customers c ON o.customer_id = c.id
WHERE o.order_date > DATE '2026-01-01'
GROUP BY region;

출력에서 다음 일반적인 문제를 찾아라:

• 동시 조인 vs 재분할 조인 — 작은 차원 테이블에 대해 브로드캐스트 조인을 목표로 하라
• 술어 푸시다운 없는 테이블 스캔 — 파티션 프루닝이 활성 상태인지 확인하라
• 과도한 데이터 셔플링 — 버케팅이나 파티셔닝 전략을 고려하라

리소스 그룹 (프로덕션급 격리) #

/etc/trino/resource-groups.json 생성:

{
  "rootGroups": [
    {
      "name": "global",
      "softMemoryLimit": "80%",
      "hardConcurrencyLimit": 100,
      "maxQueued": 1000,
      "schedulingPolicy": "weighted",
      "jmxExport": true,
      "subGroups": [
        {
          "name": "adhoc",
          "softMemoryLimit": "30%",
          "hardConcurrencyLimit": 50,
          "maxQueued": 100,
          "schedulingWeight": 3
        },
        {
          "name": "etl",
          "softMemoryLimit": "40%",
          "hardConcurrencyLimit": 30,
          "maxQueued": 50,
          "schedulingWeight": 5
        },
        {
          "name": "dashboard",
          "softMemoryLimit": "20%",
          "hardConcurrencyLimit": 20,
          "maxQueued": 50,
          "schedulingWeight": 2
        }
      ]
    }
  ],
  "selectors": [
    {"group": "global.adhoc"},
    {"user": "etl_user", "group": "global.etl"},
    {"source": "superset", "group": "global.dashboard"}
  ]
}

config.properties에서 참조:

resource-groups.config-file=/etc/trino/resource-groups.json

교환 스필링 활성화 (메모리 보호) #

사용 가능한 메모리를 초과하는 쿼리를 위해 디스크 스필링을 활성화:

# /etc/trino/config.properties
spill-enabled=true
spiller-spill-path=/var/trino/spill
memory-revoking-threshold=0.8
memory-revoking-target=0.5

인증 및 SSL (프로덕션 보안) #

LDAP 또는 파일 기반으로 비밀번호 인증 활성화:

# /etc/trino/config.properties
http-server.authentication.type=PASSWORD
http-server.https.enabled=true
http-server.https.port=8443
http-server.https.keystore.path=/etc/trino/keystore.jks
http-server.https.keystore.key=changeit

/etc/trino/password-authenticator.properties 생성:

password-authenticator.name=file
file.password-file=/etc/trino/password.db

비밀번호 해시 생성:

# trino-password-authenticator 플러그인 설치 후:
java -cp trino-server-464/plugin/password-authenticators/* \
  io.trino.plugin.password.file.EncryptPassword \
  --password 'your-secure-password'

JMX + Prometheus로 모니터링 #

런타임 메트릭을 위해 JMX 카탈로그 활성화:

# /etc/trino/catalog/jmx.properties
connector.name=jmx

런타임 메트릭을 직접 쿼리:

-- 활성 쿼리
SELECT node_id, count(*) FROM jmx.current."trino.execution:name=QueryManager" GROUP BY node_id;

-- 쿼리당 메모리 사용량
SELECT query_id, user, cumulative_user_memory FROM system.runtime.queries WHERE state = 'RUNNING';

대안과의 비교 #

Trino 선택 시: 페더레이션 데이터 소스에서 전체 SQL 지원과 벤더 종속 없이 서브초 인터랙티브 쿼리가 필요할 때.

Spark SQL 선택 시: 워크로드가 주로 배치 ETL이고 가끔 인터랙티브 쿼리가 필요하거나, Spark MLlib과의 심층 통합이 필요할 때.

PrestoDB 선택 시: Meta 생태계에 이미 깊이 투자되어 있고 Trino의 새로운 커넥터(Iceberg, Delta Lake 네이티브)가 필요 없을 때.

Dremio 선택 시: 내장 시맨틱 레이어와 리플렉션 가속이 포함된 관리형 Dremio Cloud 경험을 원할 때.

한계: 정직한 평가 #

Trino는 만능이 아니다. 알아야 할 사항:

1. 데이터베이스가 아님 — ACID 트랜잭션 없음: Trino는 쿼리 엔진이다. 데이터 스토리지, 인덱싱, 트랜잭션 업데이트를 관리하지 않는다. 트랜잭션 워크로드에는 PostgreSQL이나 Iceberg 같은 적절한 레이크하우스 형식을 사용하라.

2. 대규모 조인 시 메모리 제약: 적절한 튜닝 없이 대량 셔플 연산이 있는 쿼리는 클러스터 메모리를 소진할 수 있다. 교환 스필링은 도움이 되지만 지연 시간을 추가한다.

3. 네이티브 스트리밍 집계 없음: Trino는 Kafka를 쿼리할 수 있지만 Flink와 같은 진정한 스트리밍 윈도우 집계를 지원하지 않는다. Kafka 토픽을 폴링할 뿐 이벤트 시간 처리는 아니다.

4. 설정 복잡성: 프로덕션 배포는 디스커버리, 보안, 리소스 그룹, 모니터링의 수동 구성이 필요하다. 관리형 대안(Starburst)은 비용을 지불하고 이를 단순화한다.

5. Spark 대비 작은 커뮤니티: Spark의 약 40,000 대비 약 11,000 Star로 커뮤니티 플러그인과 확장을 찾기가 더 어려울 수 있다. 생태계는 성장 중이지만 더 작다.

자주 묻는 질문 #

Q: Trino와 PrestoDB의 차이점은 무엇인가?

둘 다 Facebook의 Presto 프로젝트에서 유래했다. Trino(구 PrestoSQL)는 2019년 Trino Software Foundation 하에 포크되었다. Trino는 더 활발한 릴리스 주기, 더 나은 Iceberg/Delta Lake 지원, 벤더 중립적 거버넌스 모델을 가지고 있다. PrestoDB는 Presto Foundation을 통해 Meta의 영향력 아래에 남아 있다. 새 프로젝트에는 일반적으로 Trino가 권장된다.

Q: Trino와 ClickHouse는 분석에서 어떻게 비교되는가?

ClickHouse는 자체 스토리지 엔진을 사용하는 OLAP에 최적화된 칼럼형 데이터베이스이다. Trino는 데이터가 있는 곳에서 직접 읽는 페더레이션 쿼리 엔진이다. ClickHouse는 네이티브 형식에서 단일 테이블 집계가 더 빠르다. Trino는 여러 시스템(S3, PostgreSQL, Kafka)에서 ETL 파이프라인 없이 데이터를 조인해야 할 때 우위에 있다.

Q: Trino가 내 데이터 웨어하우스를 완전히 대체할 수 있는가?

읽기 전용 분석 워크로드의 경우 예 — 많은 회사가 Trino를 기본 분석 계층으로 사용한다. 그러나 Trino는 트랜잭션 쓰기, CDC 수집, 복잡한 ETL 오케스트레이션을 기본적으로 처리하지 않는다. 데이터 변환 파이프라인에는 여전히 dbt, Airflow, Spark 같은 도구가 필요하다.

Q: 프로덕션 Trino 클러스터에 어떤 하드웨어가 필요한가?

최소 프로덕션 클러스터: 1대 Coordinator(8 vCPU, 32 GB RAM) + 3대 Worker(16 vCPU, 64 GB RAM). PB급 워크로드의 경우 Worker를 수평 확장하라. 스필용 NVMe SSD를 강력히 권장한다. HTStack 베어 메탈이나 DigitalOcean Droplet에서 비용 효율적으로 배포할 수 있다.

Q: Trino는 Apache Iceberg 테이블 형식을 지원하는가?

예 — Iceberg는 Trino에서 일등 시민이다. Iceberg 테이블을 생성하고, 시간 여행 쿼리를 수행하며, SQL을 통해 네이티브로 파티션을 관리할 수 있다. Trino의 Iceberg 커넥터는 REST 카탈로그와 Glue 카탈로그 구성을 모두 지원한다.

Q: 다운타임 없이 Trino를 어떻게 업그레이드하는가?

Trino는 롤링 업그레이드를 지원한다. Worker 노드를 한 번에 한 대씩 업데이트하고(종료 전 활성 쿼리를 드레인), 마지막에 Coordinator를 업데이트하라. 항상 스테이징 환경에서 새 버전을 먼저 테스트하라 — 커넥터 API는 릴리스 간에 변경될 수 있다.

결론: 오늘 PB급 분석 스택을 구축하라 #

Trino는 규모에 맞는 분산 SQL 분석을 위한 가장 성숙한 오픈소스 옵션을 대표한다. 45개 이상의 커넥터, 서브초 쿼리 성능, 번성하는 커뮤니티와 함께 관리형 웨어하우스 성능을 비용의 일부로 제공한다. 설정은 30분이 소요되며 SQL 인터페이스는 분석가가 즉시 생산적일 수 있음을 의미한다.

DigitalOcean이나 HTStack에서 3노드 클러스터로 시작하여, 첫 번째 S3 데이터 레이크를 연결하고 첫 번째 페더레이션 쿼리를 실행하라. 기가바이트에서 페타바이트로의 경로는 수평적이다 — Worker 노드를 추가하기만 하면 된다.

커뮤니티 참여: dibi8 Telegram 그룹에서 Trino 설정 경험을 공유하고 프로덕션 사용자로부터 도움을 받아라. 우리는 매주 데이터 인프라, 성능 튜닝, 실제 배포 패턴에 대해 논의한다.

출처 및 추가 자료 #

1. Trino 공식 문서
2. Trino GitHub 저장소
3. Trino: The Definitive Guide — O’Reilly, 2023
4. TPC-DS 벤치마크 사양
5. Iceberg 테이블 형식 문서
6. Starburst Enterprise Platform — Trino 상용 배포판
7. Netflix 기술 블로그: Trino at Netflix

추천 호스팅 및 인프라 #

위 도구들을 프로덕션에 배포하려면 안정적인 인프라가 필요합니다. dibi8가 직접 사용 중인 두 가지 옵션:

• DigitalOcean — 60일 $200 무료 크레딧, 14개 이상 글로벌 리전. 오픈소스 AI 도구의 기본 선택.
• HTStack — 홍콩 VPS, 중국 본토 저지연 접속. dibi8.com 호스팅 중인 검증된 IDC.

제휴 링크 — 추가 비용 없이 dibi8 운영을 지원합니다.

제휴 공개 #

이 문서에는 DigitalOcean과 HTStack의 제휴 링크가 포함되어 있다. 이 링크를 통해 서비스를 구매하면 추가 비용 없이 커미션을 받을 수 있다. 이는 오픈소스 문서 작업을 지원하는 데 도움이 된다. 우리는 직접 테스트한 서비스만 추천하며, 우리 자신의 프로덕션 워크로드에도 사용할 것이다.