벡터 검색 설계의 핵심 판단축: 재현율, 지연, 비용의 균형

Q: 청킹 크기와 겹침이 재현율을 결정하는 이유는?

벡터 검색의 재현율은 임베딩 모델의 성능보다 **청킹(chunking) 전략에 더 민감하게 반응한다**. 청크가 너무 크면 토픽 혼재로 관련성 점수가 분산되고, 너무 작으면 문맥 손실로 LLM이 활용할 정보가 부족해진다. 일반적으로 256~512 토큰 범위의 청크 크기가 기준이다. 이는 대부분의 임베딩 모델(OpenAI text-embedding-3-small, Mistral Embed 등)이 학습된 시퀀스 길이와 일치한다. 하지만 도메인마다 다르다: - **기술 문서/코드**: 논리적 단위(함수, 섹션)를 기준으로 청킹. 토큰 길이는 부차적. - **뉴스/블로그**: 고정 토큰 기반 청킹(300~400 토큰)이 무난. - **학술 논문**: 단락 단위, 섹션 헤더 포함으로 문맥 유지. 겹침(overlap)은 보통 청크 크기의 10~20%를 쓴다. 겹침 없이 청킹하면 문장이 청크 경계에서 끊겨 검색 누락이 발생한다. 예를 들어 128 토큰 청크라면 12~25 토큰 겹침을 권장한다. **측정 방법**: 고정된 테스트 세트(검증 문서 100~200개, 각각 관련 구간 표시)에서 청킹 변형별로 재현율@10을 비교한다. 겹침 없음 vs 10% vs 20%의 재현율 차이를 정량화해야 선택이 정당화된다.

Q: 임베딩 모델의 차원과 성능은 선형 관계인가?

아니다. 임베딩 차원과 검색 품질의 관계는 **수렴 곡선**을 따른다. 일반적인 관찰: - **384차원**: 가벼운 모델(all-MiniLM-L6-v2 등). 재현율@10 약 72~76% 범위(NDCG 기준 중간 난이도 테스트셋). - **768차원**: 균형형 모델(all-mpnet-base-v2 등). 재현율@10 약 78~82%. - **1536차원**: 고성능 모델(text-embedding-3-small). 재현율@10 약 84~88%. - **3072차원**: text-embedding-3-large. 재현율 향상폭 +2~4p(대비 1536), 계산 비용 2배 증가. 차원이 늘수록 **저장 공간(8바이트/차원 × 문서 수), 인덱스 빌드 시간, 쿼리 거리 계산** 모두 선형으로 증가한다. 실무에서는 **384~768 범위에서 70~80% 재현율을 안정적으로 얻고, 필요 시에만 1536으로 확장**하는 접근이 일반적이다. 또한 임베딩 모델 자체의 차이가 차원 증가보다 크다. MTEB(Massive Text Embedding Benchmark) 기준, 같은 차원이라도 학습 데이터, 파인튜닝 방식, 모델 아키텍처에 따라 재현율이 5~15p 벌어진다. 따라서 **차원 결정 전에 타겟 도메인 테스트 세트로 후보 모델들을 벤치마크하는 단계가 필수다**.

Q: HNSW와 IVF: 어떤 인덱스를 선택할까?

두 인덱스 방식은 다른 트레이드오프를 구현한다. **HNSW(Hierarchical Navigable Small World)**: - 구조: 계층적 그래프 기반. - 재현율: 매우 높음(95~99%, 적절한 파라미터 조정 시). - 쿼리 지연: 수십 ms(100만 문서 기준, 단일 쓰레드). - 메모리: 벡터 저장 용량의 120~150%(인덱스 오버헤드). - 입력 속도: 느림(초당 1,000~5,000 벡터). 배치 빌드는 가능. - 적합: 저지연이 중요하고 도메인이 고정된 상황. **IVF(Inverted File)**: - 구조: 벡터 양자화(quantization) + 역인덱스. - 재현율: 70~85%(파라미터 의존적. nprobe 값에 따라 변동). - 쿼리 지연: 수 ms(HNSW 대비 2~5배 빠름). - 메모리: 원본 벡터의 5~30%(양자화 수준에 따라). - 입력 속도: 빠름(초당 100,000+ 벡터). - 적합: 대규모 코퍼스, 동적 추가, 엄격한 레이턴시 요구. **실측 비교**(Faiss 기준, 1M SIFT 벡터, 128차원): - HNSW: 재현율 98%, 쿼리 시간 12ms. - IVF-256-PQ8: 재현율 82%, 쿼리 시간 2.5ms. pgvector(PostgreSQL 확장)는 HNSW를 구현하며, 단일 머신 기준 **~10M 벡터까지 합리적 성능**을 유지한다. 이 규모를 넘으면 전용 벡터DB(Weaviate, Qdrant, Milvus 등)의 분산 IVF 구현이 비용-성능 이점을 갖는다.

Q: 하이브리드 검색이 모든 경우에 필요한가?

아니다. 도메인과 쿼리 특성에 크게 의존한다. **하이브리드 검색이 유리한 경우**: - 도메인 고유 용어(기술 용어, 약자, 고유명사)가 많을 때. 벡터 유사도가 정확한 키워드 일치를 놓칠 수 있다. - 쿼리가 짧고 구체적일 때(예: "Python GIL이란?"). 벡터만으로는 약한 신호. - 재현율이 매우 중요하고 거짓 부정(false negative)이 비용이 클 때. **벡터만 충분한 경우**: - 도메인이 자유 텍스트 기반일 때(문학, 에세이, 블로그). - 쿼리가 길고 의미론적으로 복잡할 때(다문장 질문). - 지연 요구가 엄격할 때(하이브리드는 두 인덱스를 모두 실행하므로 지연 증가). **하이브리드 구현의 비용**: - 인덱싱: 벡터 인덱스 + 역인덱스(키워드) 병렬 유지. - 쿼리: 두 검색 결과를 통합(RRF, weighted score 등). 지연 +20~50ms. - 유지보수: 두 인덱스 간 일관성 관리. 대부분의 실제 배포는 **벡터 검색 baseline → 테스트 세트에서 재현율 재평가 → 부족 시 하이브리드 추가** 경로를 따른다.

Q: pgvector가 전용 벡터DB를 대체할 수 있는 규모는?

2026년 기준, 이 경계는 **코퍼스 크기와 동시 쿼리 부하**로 나뉜다. **pgvector(PostgreSQL 기반) 실측 임계**: - 벡터 수: ~5M까지 안정적(768차원 기준). - 응답 지연(HNSW, 단일 쿼리): 10~30ms(적절한 인덱스 파라미터). - 동시 쿼리: 초당 10~30 쿼리(단일 인스턴스, 8코어 기준). - 저장소: 벡터만 약 4.6GB(5M × 768 × 8바이트). **전용 벡터DB(Weaviate, Qdrant, Milvus)**: - 벡터 수: 100M+ (분산 아키텍처). - 응답 지연: 수 ms(최적화된 IVF + 양자화). - 동시 쿼리: 초당 1,000+ (샤딩 활용). - 저장소 효율: PQ 양자화로 ~10% 저감. **선택 기준**: - 코퍼스 10M 또는 쿼리 > 100 QPS: 전용 벡터DB 필수. pgvector의 장점은 **기존 PostgreSQL 인프라와 통합** 가능(같은 DB에서 관계형 필터링 + 벡터 검색). 단점은 **스케일링 아키텍처 부재**(수평 확장이 제한적)와 **IVF 미지원**(HNSW만 가능).

Q: 자주 간과되는 설계 실수는 무엇인가?

**임베딩 생성 비용을 구현 단계에서 발견하는 것** 대부분의 팀은 벡터 검색 **쿼리** 성능에만 집중하고, 코퍼스 임베딩 생성 비용을 과소평가한다. 구체적 예: - 코퍼스: 1M 문서, 청크당 평균 200 토큰 = 200M 토큰 임베딩 필요. - OpenAI API(text-embedding-3-small): $0.02 per 1M 토큰. - 초기 임베딩 비용: **~$4**, 재임베딩(모델 업그레이드 시) 또 $4. - 이건 무시해도 될 수준이지만, 자체 모델을 GPU에서 실행한다면? - A100 GPU에서 50 토큰/초(배치 128, 768차원): 200M 토큰 ≈ **111시간** = GPU 10일 이상. 또한, 모델 업그레이드 후 **전체 코퍼스 재임베딩**을 의무적으로 수행해야 한다는 점도 자주 간과된다. 이전 벡터와 새 벡터를 혼재할 수 없기 때문이다. **권장**: - 초기 설계 단계에서 임베딩 생성의 시간·비용을 명시적으로 계산. - 모델 변경 가능성을 고려해 버전 관리 체계 구축. - 대규모 코퍼스라면 증분 임베딩(신규 문서만) 파이프라인 설계.

Q: 청크 크기를 정확히 정하는 방법은?

테스트 세트(관련 구간 표시된 검증 문서 100~200개)에서 청크 크기별(128, 256, 512, 1024 토큰)로 재현율@10을 측정하는 것이 유일한 방법이다. 도메인 특성(문서 평균 길이, 주제 복잡도)에 따라 최적값이 다르므로 추측은 실패한다. 보통 256~512 범위에서 최적점이 나타난다.

벡터 검색 설계에서 가장 먼저 결정할 것은 무엇인가?

RAG(Retrieval-Augmented Generation) 파이프라인의 성패는 "올바른 문맥을 얼마나 정확하고 빠르게 찾느냐"에 달려 있다. 이 결정은 세 축의 트레이드오프에서 시작한다: (1) 재현율(recall) — 필요한 관련 문서를 놓치지 않는 정도, (2) 지연(latency) — 쿼리 응답 시간, (3) 저장 및 계산 비용.

이 세 축이 독립적이지 않다는 점이 핵심이다. 재현율을 높이면 대개 지연이 늘고, 비용 절감을 추구하면 재현율이 떨어진다. 2026년 기준으로 이 균형점을 찾는 설계 기준은 청킹 전략 → 임베딩 모델 선택 → 인덱스 구조 → 검색 방식(단일 모드vs 하이브리드) 순서로 결정된다.

청킹 크기와 겹침이 재현율을 결정하는 이유는?

벡터 검색의 재현율은 임베딩 모델의 성능보다 청킹(chunking) 전략에 더 민감하게 반응한다. 청크가 너무 크면 토픽 혼재로 관련성 점수가 분산되고, 너무 작으면 문맥 손실로 LLM이 활용할 정보가 부족해진다.

일반적으로 256~512 토큰 범위의 청크 크기가 기준이다. 이는 대부분의 임베딩 모델(OpenAI text-embedding-3-small, Mistral Embed 등)이 학습된 시퀀스 길이와 일치한다. 하지만 도메인마다 다르다:

기술 문서/코드: 논리적 단위(함수, 섹션)를 기준으로 청킹. 토큰 길이는 부차적.
뉴스/블로그: 고정 토큰 기반 청킹(300~400 토큰)이 무난.
학술 논문: 단락 단위, 섹션 헤더 포함으로 문맥 유지.

겹침(overlap)은 보통 청크 크기의 1020%를 쓴다. 겹침 없이 청킹하면 문장이 청크 경계에서 끊겨 검색 누락이 발생한다. 예를 들어 128 토큰 청크라면 1225 토큰 겹침을 권장한다.

측정 방법: 고정된 테스트 세트(검증 문서 100~200개, 각각 관련 구간 표시)에서 청킹 변형별로 재현율@10을 비교한다. 겹침 없음 vs 10% vs 20%의 재현율 차이를 정량화해야 선택이 정당화된다.

임베딩 모델의 차원과 성능은 선형 관계인가?

아니다. 임베딩 차원과 검색 품질의 관계는 수렴 곡선을 따른다.

일반적인 관찰:

384차원: 가벼운 모델(all-MiniLM-L6-v2 등). 재현율@10 약 72~76% 범위(NDCG 기준 중간 난이도 테스트셋).
768차원: 균형형 모델(all-mpnet-base-v2 등). 재현율@10 약 78~82%.
1536차원: 고성능 모델(text-embedding-3-small). 재현율@10 약 84~88%.
3072차원: text-embedding-3-large. 재현율 향상폭 +2~4p(대비 1536), 계산 비용 2배 증가.

차원이 늘수록 저장 공간(8바이트/차원 × 문서 수), 인덱스 빌드 시간, 쿼리 거리 계산 모두 선형으로 증가한다. 실무에서는 384768 범위에서 7080% 재현율을 안정적으로 얻고, 필요 시에만 1536으로 확장하는 접근이 일반적이다.

또한 임베딩 모델 자체의 차이가 차원 증가보다 크다. MTEB(Massive Text Embedding Benchmark) 기준, 같은 차원이라도 학습 데이터, 파인튜닝 방식, 모델 아키텍처에 따라 재현율이 5~15p 벌어진다. 따라서 차원 결정 전에 타겟 도메인 테스트 세트로 후보 모델들을 벤치마크하는 단계가 필수다.

HNSW와 IVF: 어떤 인덱스를 선택할까?

두 인덱스 방식은 다른 트레이드오프를 구현한다.

HNSW(Hierarchical Navigable Small World):

구조: 계층적 그래프 기반.
재현율: 매우 높음(95~99%, 적절한 파라미터 조정 시).
쿼리 지연: 수십 ms(100만 문서 기준, 단일 쓰레드).
메모리: 벡터 저장 용량의 120~150%(인덱스 오버헤드).
입력 속도: 느림(초당 1,000~5,000 벡터). 배치 빌드는 가능.
적합: 저지연이 중요하고 도메인이 고정된 상황.

IVF(Inverted File):

구조: 벡터 양자화(quantization) + 역인덱스.
재현율: 70~85%(파라미터 의존적. nprobe 값에 따라 변동).
쿼리 지연: 수 ms(HNSW 대비 2~5배 빠름).
메모리: 원본 벡터의 5~30%(양자화 수준에 따라).
입력 속도: 빠름(초당 100,000+ 벡터).
적합: 대규모 코퍼스, 동적 추가, 엄격한 레이턴시 요구.

실측 비교(Faiss 기준, 1M SIFT 벡터, 128차원):

HNSW: 재현율 98%, 쿼리 시간 12ms.
IVF-256-PQ8: 재현율 82%, 쿼리 시간 2.5ms.

pgvector(PostgreSQL 확장)는 HNSW를 구현하며, 단일 머신 기준 ~10M 벡터까지 합리적 성능을 유지한다. 이 규모를 넘으면 전용 벡터DB(Weaviate, Qdrant, Milvus 등)의 분산 IVF 구현이 비용-성능 이점을 갖는다.

재현율 10%를 높이려면 어떤 비용이 드는가?

"현재 재현율@10이 75%인데 85%로 올리고 싶다"는 요구가 자주 나온다. 그 경로와 비용을 정리하면:

경로 1: 청킹 최적화

비용: 낮음(재계산만 필요).
효과: +3~8p(일반적).
실행: 테스트 세트로 청크 크기, 겹침, 경계 전략 재평가.

경로 2: 임베딩 모델 업그레이드(384→768차원)

비용: 중간(저장소 2배, 임베딩 생성 시간 1.5배 증가).
효과: +4~6p.
시점: 청킹 최적화 후 여전히 부족할 때.

경로 3: 고성능 임베딩 모델로 교체(1536차원)

비용: 높음(저장소 4배, 쿼리 거리 계산 4배).
효과: +3~8p(모델마다 다름).
실행: MTEB에서 타겟 도메인 유사 테스트에 높은 점수의 모델 선정.

경로 4: 하이브리드 검색(벡터 + 키워드)

비용: 중간(키워드 인덱스 추가).
효과: +5~15p(도메인 의존적).
조건: 키워드 검색이 보완할 만한 구조적 특성이 있을 때.

경로 5: 재현율@10에서 재현율@20으로 완화

비용: 낮음(쿼리마다 2배 검색).
효과: 논리적으로 +20p(상위 20개 중 상위 10개 포함).
트레이드오프: 지연 2배, LLM 입력 문맥 길이 증가.

실무에서는 경로 1 → 4 → 2 순으로 시도하고, 비용 대비 효과를 ROI로 판단한다.

하이브리드 검색이 모든 경우에 필요한가?

아니다. 도메인과 쿼리 특성에 크게 의존한다.

하이브리드 검색이 유리한 경우:

도메인 고유 용어(기술 용어, 약자, 고유명사)가 많을 때. 벡터 유사도가 정확한 키워드 일치를 놓칠 수 있다.
쿼리가 짧고 구체적일 때(예: "Python GIL이란?"). 벡터만으로는 약한 신호.
재현율이 매우 중요하고 거짓 부정(false negative)이 비용이 클 때.

벡터만 충분한 경우:

도메인이 자유 텍스트 기반일 때(문학, 에세이, 블로그).
쿼리가 길고 의미론적으로 복잡할 때(다문장 질문).
지연 요구가 엄격할 때(하이브리드는 두 인덱스를 모두 실행하므로 지연 증가).

하이브리드 구현의 비용:

인덱싱: 벡터 인덱스 + 역인덱스(키워드) 병렬 유지.
쿼리: 두 검색 결과를 통합(RRF, weighted score 등). 지연 +20~50ms.
유지보수: 두 인덱스 간 일관성 관리.

대부분의 실제 배포는 벡터 검색 baseline → 테스트 세트에서 재현율 재평가 → 부족 시 하이브리드 추가 경로를 따른다.

pgvector가 전용 벡터DB를 대체할 수 있는 규모는?

2026년 기준, 이 경계는 코퍼스 크기와 동시 쿼리 부하로 나뉜다.

pgvector(PostgreSQL 기반) 실측 임계:

벡터 수: ~5M까지 안정적(768차원 기준).
응답 지연(HNSW, 단일 쿼리): 10~30ms(적절한 인덱스 파라미터).
동시 쿼리: 초당 10~30 쿼리(단일 인스턴스, 8코어 기준).
저장소: 벡터만 약 4.6GB(5M × 768 × 8바이트).

전용 벡터DB(Weaviate, Qdrant, Milvus):

벡터 수: 100M+ (분산 아키텍처).
응답 지연: 수 ms(최적화된 IVF + 양자화).
동시 쿼리: 초당 1,000+ (샤딩 활용).
저장소 효율: PQ 양자화로 ~10% 저감.

선택 기준:

코퍼스 < 1M, 동시 쿼리 < 5 QPS: pgvector 충분.
1M < 코퍼스 < 10M, 동시 쿼리 < 50 QPS: pgvector 또는 경량 전용DB.
코퍼스 > 10M 또는 쿼리 > 100 QPS: 전용 벡터DB 필수.

pgvector의 장점은 기존 PostgreSQL 인프라와 통합 가능(같은 DB에서 관계형 필터링 + 벡터 검색). 단점은 스케일링 아키텍처 부재(수평 확장이 제한적)와 IVF 미지원(HNSW만 가능).

자주 간과되는 설계 실수는 무엇인가?

임베딩 생성 비용을 구현 단계에서 발견하는 것

대부분의 팀은 벡터 검색 쿼리 성능에만 집중하고, 코퍼스 임베딩 생성 비용을 과소평가한다.

구체적 예:

코퍼스: 1M 문서, 청크당 평균 200 토큰 = 200M 토큰 임베딩 필요.
OpenAI API(text-embedding-3-small): $0.02 per 1M 토큰.
초기 임베딩 비용: ~$4, 재임베딩(모델 업그레이드 시) 또 $4.
이건 무시해도 될 수준이지만, 자체 모델을 GPU에서 실행한다면?
A100 GPU에서 50 토큰/초(배치 128, 768차원): 200M 토큰 ≈ 111시간 = GPU 10일 이상.

또한, 모델 업그레이드 후 전체 코퍼스 재임베딩을 의무적으로 수행해야 한다는 점도 자주 간과된다. 이전 벡터와 새 벡터를 혼재할 수 없기 때문이다.

권장:

초기 설계 단계에서 임베딩 생성의 시간·비용을 명시적으로 계산.
모델 변경 가능성을 고려해 버전 관리 체계 구축.
대규모 코퍼스라면 증분 임베딩(신규 문서만) 파이프라인 설계.

핵심 정리

벡터 검색 설계는 재현율, 지연, 비용 세 축의 트레이드오프에서 시작한다. 청킹 → 임베딩 모델 → 인덱스 구조 → 검색 방식 순으로 결정 우선순위가 있다.
청킹 크기(256512 토큰)와 겹침(1020%)이 재현율을 크게 좌우한다. 임베딩 모델 성능 개선 전에 청킹을 최적화하면 비용 대비 효과가 크다.
임베딩 차원과 재현율은 수렴 곡선을 따른다. 384~768 범위에서 충분한 성능을 얻을 수 있으며, 3000차원 이상 확장은 비용 증가 대비 효과가 미미하다.
HNSW(높은 재현율, 높은 지연)와 IVF(낮은 지연, 양자화로 저장소 절감)는 상황에 따라 선택한다. pgvector는 ~10M 벡터까지, 그 이상은 분산 벡터DB를 고려한다.
하이브리드 검색(벡터 + 키워드)은 도메인 고유 용어가 많거나 재현율 요구가 매우 높을 때만 추가한다. 일반적으로는 벡터 검색으로 시작해 필요 시 확장한다.
임베딩 생성의 시간·비용을 설계 단계에서 명시적으로 계산하고, 모델 변경 시 전체 코퍼스 재임베딩 필요성을 미리 고려해야 한다.

자주 묻는 질문

청크 크기를 정확히 정하는 방법은?

테스트 세트(관련 구간 표시된 검증 문서 100200개)에서 청크 크기별(128, 256, 512, 1024 토큰)로 재현율@10을 측정하는 것이 유일한 방법이다. 도메인 특성(문서 평균 길이, 주제 복잡도)에 따라 최적값이 다르므로 추측은 실패한다. 보통 256512 범위에서 최적점이 나타난다.

벡터 검색과 키워드 검색을 섞을 때 가중치 비율은?

하이브리드 검색에서 키워드 스코어와 벡터 스코어를 합산할 때, 고정 가중치(예: 0.6×벡터 + 0.4×키워드)보다는 테스트 세트에서 측정한 각 방식의 개별 재현율을 기반으로 가중치를 결정한다. 예를 들어 벡터가 80% 재현율, 키워드가 60%라면, 초기 가중치는 0.8:(1-0.8) = 0.8:0.2 비율로 시작하고 조정한다. 절대적 비율은 없고, 테스트 세트 NDCG를 최대화하는 값이 답이다.

1M 문서 규모에서 임베딩 차원을 줄여야 할까?

저장소와 쿼리 성능 관점에서는 줄이는 것이 합리적이다. 하지만 먼저 384→768차원으로 단계적으로 늘려가며 재현율 향상폭을 측정하는 게 낫다. 대부분의 경우 768 이상에서 수렴하므로, 불필요한 차원까지 유지할 필요는 없다. 저장소가 심각할 때만(예: 5M 이상) 384로 제한을 고려한다.

pgvector의 인덱스 파라미터 m과 ef_construction은 어떻게 설정할까?

이는 HNSW의 그래프 연결도(m)와 빌드 시간(ef_construction)을 제어한다. 공식 권장은 m=16, ef_construction=200이다. 메모리와 성능 균형을 보려면 m=16, ef=200으로 시작해 쿼리 지연(ef 증가시킬 때)과 재현율을 측정한 후 조정한다. 메모리가 부족하면 m을 8로 낮추되, 재현율 손실을 감수해야 한다.

모델을 업그레이드할 때 이전 벡터는 어떻게 처리할까?

기존 벡터는 폐기하고 전체 코퍼스를 재임베딩해야 한다. 상이한 모델의 벡터 공간은 호환되지 않으므로 혼재할 수 없다. 따라서 마이그레이션 계획(임베딩 생성 시간, 인덱스 재빌드, 다운타임)을 미리 수립하고, 가능하면 비업무 시간에 실행한다. 대규모 코퍼스라면 벡터DB의 배치 임베딩 기능을 활용해 병렬화한다.

재현율 vs 지연 중 어느 것을 우선할까?

RAG 시스템의 최종 성능은 검색 재현율과 LLM 품질 모두에 의존한다. 검색이 틀리면 LLM이 보정할 수 없으므로, 보통 재현율을 75% 이상 확보한 후 지연 최적화를 진행한다. 단, 대화형 시스템(챗봇)이라면 지연 < 500ms 제약이 있을 수 있으므로, 그 경우 재현율@20으로 완화하거나 IVF로 지연을 단축한다.

벡터 검색이 실패하는 주요 신호는?

(1) 테스트 세트에서 재현율@10이 60% 이하, (2) 쿼리 응답이 500ms 이상, (3) 새로운 도메인 문서 추가 후 재현율 급락. 이 중 (1)은 청킹·모델·인덱스 구조 재검토가 필요하고, (2)는 인덱스 파라미터(IVF nprobe, HNSW ef) 조정 또는 양자화 추가, (3)은 임베딩 모델이 새 도메인에 맞지 않을 신호다. 각각 원인 분석 순서가 다르다.