개인정보처리방침© 2026 DEV BAK - 기술블로그. All rights reserved.
DEV BAK - 기술블로그
AI

오픈웨이트 vs 클로즈드 AI 2026: 벤치마크 격차가 좁혀진 지금, 선택의 기준이 바뀌었다

솔직히 말하면, 1년 전까지만 해도 저는 클로즈드 모델이 한동안은 압도적 우위를 유지할 거라 생각했습니다. GPT-4급 성능을 내려면 OpenAI API 키를 꽂는 게 당연한 수순이었고, 오픈웨이트 진영은 "쓸 만은 하지만 아직..." 수준에 머물렀으니까요. 그런데 그 확신이 흔들리기 시작한 건 팀의 월 API 비용이 특정 임계점을 넘어섰을 때였습니다. 클로즈드 API에 묶여 있는 동안, 비슷한 성능을 1/10 가격에 쓰는 팀이 생겨나고 있다는 걸 실감한 순간이었죠.

그 직감이 맞았습니다. MMLU 기준으로 클로즈드 최상위 모델과 오픈웨이트 최상위 모델 사이에는 2023년 말 기준 17.5%p의 격차가 있었는데(Digital Applied, 2026), 2026년 상반기에는 지식 벤치마크에서 사실상 소멸했고 코딩 분야에서는 오히려 역전된 케이스도 나왔습니다. DeepSeek V4 Pro가 BenchLM.ai 오픈소스 리더보드 1위(87점)를 차지하고, GLM-5.1이 SWE-Bench Pro에서 GPT-5.4와 Claude Opus 4.6을 앞서는 일이 현실이 됐습니다.

이 글을 읽고 나면, "우리 팀 워크로드에는 오픈웨이트와 클로즈드 중 무엇이 맞는가"를 30분 안에 판단할 수 있는 기준이 생깁니다. 단순한 성능 비교가 아니라, 실제 프로덕션 결정을 내릴 때 고려해야 할 비용·데이터 주권·운영 부담을 구체적인 코드와 숫자로 풀어봅니다.


목차

  • 핵심 개념
    • 오픈웨이트 ≠ 오픈소스: 실무에서 중요한 이유
    • 2026년 주요 모델 현황과 VRAM 요구사항
    • 추론 엔진 핵심 개념
  • 실전 적용
    • 예시 1: 규제 산업 내부 배포 — VPC 안에서 LLM 직접 운영하기
    • 예시 2: 고볼륨 자동화 — 비용이 결정적인 배치 워크로드
    • 예시 3: 로컬 개발 환경 — Ollama로 빠르게 실험하기
  • 장단점 분석
    • 오픈웨이트의 강점
    • 클로즈드의 강점
    • 단점 및 주의사항
  • 실무에서 가장 흔한 실수
  • 마치며
  • 참고 자료

핵심 개념

오픈웨이트 ≠ 오픈소스: 실무에서 중요한 이유

저도 처음엔 이 둘을 혼용했는데, 프로덕션에서 라이선스 문제가 불거지고 나서야 차이를 제대로 챙기게 됐습니다.

구분 가중치 공개 학습 데이터 공개 학습 코드 공개
완전한 오픈소스 ✅ ✅ ✅
오픈웨이트 ✅ ❌ (대부분) ❌ (대부분)
클로즈드 ❌ ❌ ❌

오픈웨이트(Open-weight): 학습된 가중치 파일을 외부에 공개하지만, 학습 데이터나 전체 소스코드는 포함하지 않는 모델. Meta Llama, DeepSeek, Qwen, GLM 계열이 대표적입니다. 직접 다운로드해 파인튜닝하거나 로컬 추론이 가능하다는 게 핵심입니다.

"오픈이니까 상업적으로 써도 되겠지"라는 가정이 생각보다 자주 발목을 잡습니다. Llama 계열은 Meta LLAMA 상업 라이선스, DeepSeek은 별도 약관, Qwen은 Apache 2.0 등 모델마다 조건이 다릅니다. 실제로 저는 배포 직전에 라이선스 검토가 빠진 걸 컴플라이언스팀에서 잡아낸 적이 있습니다. 서비스에 붙이기 전에 라이선스 원문을 읽어보시면 좋습니다.

2026년 주요 모델 현황과 VRAM 요구사항

오픈웨이트 진영에서 주목할 모델들은 대부분 중국 공급자에서 나왔습니다. OpenRouter 트래픽에서 중국 오픈웨이트 공급자 비중이 1년 전 2% 미만에서 45% 이상으로 올라섰다는 통계(BenchLM.ai, 2026)는 꽤 충격적입니다.

모델 제공사 주목할 점 권장 VRAM
DeepSeek V4 Pro DeepSeek BenchLM.ai 오픈소스 1위 (87점), SWE-Bench Pro 선두 A100 4장 이상 (FP16)
GLM-5.1 Zhipu AI GPT-5.4·Claude Opus 4.6 대비 코딩 벤치마크 우위 A100 4장 이상
Qwen 3.5 397B Alibaba 추론 분야 강세 A100 8장 이상
Kimi K2.6 Moonshot BenchLM.ai 2위 (84점) A100 4장 이상
Qwen 2.5 72B (양자화) Alibaba Mac M-series에서도 동작 48GB (4-bit 양자화)
Claude Opus 4.6 Anthropic GPQA Diamond·고급 수학에서 리드 API only
GPT-5.4 Pro OpenAI 고복잡도 추론, 멀티모달 성숙도 API only

GPQA Diamond: 박사급 과학 추론 능력을 측정하는 벤치마크입니다. SWE-Bench Pro: 실제 GitHub 이슈를 자율적으로 해결하는 능력을 평가합니다. 두 벤치마크 모두 단순 지식보다 복잡한 추론과 실전 능력을 측정한다는 점에서 다른 벤치마크보다 프로덕션 성능에 가깝다고 볼 수 있습니다.

A100 4장 이상이 필요한 대형 모델을 GPU 없이 써야 한다면, Together.ai나 DeepInfra 같은 관리형 API를 통해 인프라 없이 동일 모델을 호출할 수 있습니다. 아래 예시 2에서 구체적으로 다룹니다.

추론 엔진 핵심 개념

PagedAttention: vLLM이 사용하는 메모리 관리 기법으로, GPU VRAM의 단편화를 50% 줄이고 동시 요청 처리량을 2~4배 높입니다. 여러 사용자가 동시에 API를 호출하는 팀 서빙 환경에서 특히 효과적입니다.

LoRA (Low-Rank Adaptation): 전체 모델 가중치를 재학습하지 않고 소규모 어댑터 레이어만 학습해 파인튜닝하는 기법입니다. 7B 이하 모델이라면 소비자용 GPU(RTX 3090, M2 Max 등) 한 장으로 몇 시간 내에 가능하지만, 70B 이상 대형 모델은 A100 2~4장 이상이 필요합니다. "파인튜닝은 어렵다"는 인식과 달리, 소규모 도메인 데이터셋으로 시작한다면 생각보다 접근하기 쉬운 편입니다.


실전 적용

예시 1: 규제 산업 내부 배포 — VPC 안에서 LLM 직접 운영하기

헬스케어나 금융 도메인에서 일하고 계신 분들이라면 공감하실 겁니다. 원시 환자 데이터나 금융 거래 기록을 외부 API로 보내는 순간 컴플라이언스팀이 뛰어옵니다. 이 경우 오픈웨이트 모델을 VPC 내부에서 직접 서빙하는 게 사실상 유일한 선택지입니다.

vLLM을 사용하면 프로덕션 수준의 추론 서버를 비교적 빠르게 올릴 수 있습니다.

bash
# vLLM 설치 및 DeepSeek-V3 서빙
pip install vllm
 
# GPU 4장 환경에서 분산 추론 (A100/H100 기준)
python -m vllm.entrypoints.openai.api_server \
  --model deepseek-ai/DeepSeek-V3 \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --port 8000
python
# OpenAI 호환 클라이언트로 내부 엔드포인트 호출
import os
from openai import OpenAI
 
# OpenAI 클라이언트는 api_key가 비어있으면 환경변수를 뒤지다가 예외를 던집니다
# 임의 문자열을 넣고, 실제 인증(Bearer 토큰, mTLS 등)은 reverse proxy 레이어에서 처리합니다
client = OpenAI(
    base_url="http://your-internal-host:8000/v1",
    api_key=os.getenv("INTERNAL_API_KEY", "EMPTY")
)
 
try:
    response = client.chat.completions.create(
        model="deepseek-ai/DeepSeek-V3",
        messages=[
            {"role": "user", "content": "환자 기록 요약: ..."}
        ],
        timeout=30
    )
    print(response.choices[0].message.content)
except Exception as e:
    print(f"추론 서버 오류: {e}")
    raise
선택 포인트 이유
--tensor-parallel-size 4 GPU 4장으로 대형 모델 분산 추론. GPU가 1~2장이라면 4-bit 양자화 버전(GGUF)이나 더 소형 모델을 고려할 수 있습니다
OpenAI 호환 엔드포인트 기존 클라이언트 코드 교체 없이 base_url만 변경하면 전환 가능
내부 VPC 서빙 데이터가 외부로 나가지 않아 HIPAA·SOC2 준수에 유리
인증은 별도 레이어 vLLM 자체 인증보다 Nginx·API Gateway에서 처리하는 게 일반적

예시 2: 고볼륨 자동화 — 비용이 결정적인 배치 워크로드

내부 문서 RAG, 코드 리뷰 봇, 회의록 자동 요약처럼 하루에도 수천~수만 번 LLM을 호출하는 워크로드라면 비용 계산을 먼저 해보시는 게 좋습니다. 처음엔 GPT-4 계열로 프로토타입을 만들다가 월말 청구서에 깜짝 놀라는 패턴, 저도 경험했고 주변에서도 자주 봅니다.

동일 프로덕션 워크로드 기준으로 GPT-5.2는 월 $2,275인 반면 DeepSeek V3는 월 $168입니다(Let's Data Science, 2026). 10배 이상 차이가 납니다.

python
# LiteLLM으로 클로즈드↔오픈웨이트 스위칭 — 코드 변경 최소화
import litellm
 
def call_llm(prompt: str, use_open_weight: bool = False) -> str:
    try:
        if use_open_weight:
            # 고볼륨 자동화용: Together.ai 경유 오픈웨이트
            response = litellm.completion(
                model="together_ai/deepseek-ai/DeepSeek-V3",
                messages=[{"role": "user", "content": prompt}],
                timeout=30
            )
        else:
            # 고복잡도 추론용: 클로즈드 모델
            response = litellm.completion(
                model="gpt-5.4",
                messages=[{"role": "user", "content": prompt}],
                timeout=30
            )
        return response.choices[0].message.content
    except litellm.Timeout:
        raise RuntimeError("LLM 응답 타임아웃")
    except litellm.APIError as e:
        raise RuntimeError(f"API 오류: {e}")

Together.ai나 DeepInfra 같은 관리형 오픈웨이트 API를 쓰면 GPU 인프라 없이도 이 가격대를 누릴 수 있습니다. 모델을 바꿀 때는 model 문자열 하나만 교체하면 됩니다.

예시 3: 로컬 개발 환경 — Ollama로 빠르게 실험하기

개인 프로젝트나 빠른 실험이 필요할 때 Ollama는 정말 Docker처럼 편합니다. API 비용 없이 로컬에서 돌릴 수 있어서 실험 속도가 확실히 빨라집니다.

bash
# Ollama 설치
# macOS는 Homebrew 권장 (신뢰할 수 있는 패키지 매니저 경로)
brew install ollama
 
# Linux는 공식 설치 스크립트 사용 가능
# curl -fsSL https://ollama.ai/install.sh | sh
 
# Mac M-series에서도 잘 동작하는 코딩 특화 모델 실행
ollama pull qwen2.5-coder:7b
ollama run qwen2.5-coder:7b
# OpenAI 호환 API 서버도 함께 뜸 (기본 포트 11434)
python
# Ollama를 OpenAI 클라이언트로 호출
from openai import OpenAI
 
# Ollama는 인증 불필요하지만, 클라이언트 예외를 막기 위해 임의 문자열을 넣습니다
client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="EMPTY"
)
 
try:
    response = client.chat.completions.create(
        model="qwen2.5-coder:7b",
        messages=[{"role": "user", "content": "Hello!"}],
        timeout=60  # 로컬 모델은 첫 응답이 느릴 수 있음
    )
    print(response.choices[0].message.content)
except Exception as e:
    print(f"오류: {e}")

단, 7B 이하 모델은 복잡한 추론 품질이 많이 떨어지므로 프로토타이핑 용도로 보시면 좋습니다. 로컬에서 품질 확인을 마쳤다면 base_url과 model만 바꿔 DeepInfra나 Together.ai의 더 큰 모델로 그대로 전환할 수 있습니다.


장단점 분석

오픈웨이트의 강점

비용 항목은 단순한 "저렴함"이 아닙니다. 고볼륨 워크로드에서 월 수천 달러의 차이가 나는 상황이라면 팀의 기술 선택 자체가 달라지는 수준이 됩니다.

항목 내용
비용 동일 성능 대비 클로즈드의 1/10~1/13 수준, 온프레미스 운영 시 전기세만
데이터 프라이버시 서드파티 전송 없음, HIPAA·SOC2 등 규제 준수 용이
커스터마이징 파인튜닝, LoRA 등 자유로운 모델 수정 가능
코딩·지식 벤치마크 클로즈드와 동등하거나 일부 분야(코딩, RAG)에서 우위
벤더 종속 탈출 API 정책 변경·서비스 종료 리스크 없음

클로즈드의 강점

고난도 추론과 멀티모달 쪽은 아직 클로즈드가 유의미한 리드를 갖고 있습니다. 저도 클로즈드 모델이 여전히 합리적인 선택인 상황이 분명히 있다고 생각합니다.

항목 내용
고난도 추론·수학 GPQA Diamond 등 복잡한 추론 벤치마크에서 여전히 3~8%p 리드
멀티모달 이미지·영상·오디오 처리 성숙도에서 명확한 우위
운영 단순성 인프라 없이 API 키 하나로 즉시 사용
안전성·필터링 RLHF 기반 콘텐츠 안전 필터가 더 성숙
엔터프라이즈 SLA 고가용성 보장, 제로 데이터 보존 계약 가능

단점 및 주의사항

항목 내용 대응 방안
[오픈웨이트] GPU 인프라 부담 모델 업데이트·보안 패치를 직접 관리해야 함 Together.ai·DeepInfra 관리형 API로 먼저 시작
[오픈웨이트] 라이선스 복잡성 모델마다 상업 이용 조건이 다름 배포 전 라이선스 원문 반드시 확인
[오픈웨이트] Instruction-following 특정 출력 형식 엄수, 제약 조건 준수 등 세밀한 지시 이행 수준에서 클로즈드 대비 격차 존재 도메인 파인튜닝 또는 시스템 프롬프트를 공들여 작성
[클로즈드] 고볼륨 비용 트래픽 증가 시 비용 급증 볼륨 구간별 오픈웨이트 혼용 전략
[클로즈드] 벤더 의존성 서비스 약관 변경·단종 리스크 LiteLLM 같은 추상화 레이어로 전환 비용 최소화
[클로즈드] 지정학적 위험 특정 국가·지역 서비스 제한 가능성 오픈웨이트 폴백 플랜 병행 준비

실무에서 가장 흔한 실수

이 세 가지는 팀에서 LLM을 도입할 때 실제로 가장 자주 걸리는 함정들입니다. 저도 직접 경험하거나 가까이서 지켜본 케이스들이라 별도로 정리해봤습니다.

  1. "오픈이니까 상업적으로 써도 되겠지" 가정하기 — Llama 4는 일정 규모(월 활성 사용자 7억 명) 이상의 서비스에서 Meta 별도 라이선스가 필요합니다. 스타트업 단계에선 해당되지 않아도, 스케일이 커지면 소급 적용 이슈가 생길 수 있습니다. 저도 초반에 이 부분을 대충 넘겼다가 배포 직전에 법무팀 검토를 다시 받게 된 적이 있어서, 처음부터 라이선스 원문을 확인해두시면 좋습니다.

  2. 벤치마크 숫자만 보고 선택하기 — MMLU에서 동등하다고 해서 실제 프로덕션 태스크에서도 동등한 건 아닙니다. 벤치마크는 일반 능력을 측정하지만, 여러분의 도메인 데이터와 프롬프트 패턴에서 어떻게 동작하는지는 직접 평가해보기 전까지 알 수 없습니다. 본인 도메인 케이스 50~100개를 직접 돌려보는 게 벤치마크 표보다 훨씬 신뢰도 높은 판단 근거가 됩니다.

  3. 처음부터 온프레미스로 시작하기 — GPU 클러스터 구축은 진입 비용이 상당합니다. Together.ai나 DeepInfra 같은 관리형 오픈웨이트 API로 먼저 검증한 뒤 내재화 여부를 결정하는 흐름이 리스크가 훨씬 적습니다. 관리형 API에서도 DeepSeek-V3 기준 입력 $0.14/M 토큰(2026년 6월 기준, 최신 가격은 DeepInfra 공식 페이지 확인) 수준이라, 대부분의 팀에선 직접 운영보다 관리형이 더 효율적입니다.


마치며

이 글을 쓰면서 한 가지 생각이 바뀌었습니다. 처음엔 "오픈웨이트가 충분히 좋아졌나?"가 핵심 질문이라고 생각했는데, 실제로는 선택의 축이 이미 "성능"에서 "비용·데이터 주권·운영 복잡도"로 이동해 있었습니다. 성능만으로 클로즈드를 정당화하기 어려운 워크로드가 2026년 현재 상당히 늘어났고, 많은 팀이 이미 두 가지를 상황에 따라 조합하는 하이브리드 전략으로 가고 있습니다.

지금 바로 시작해볼 수 있는 3단계를 상황에 맞게 제안합니다.

처음 LLM을 도입하는 팀이라면 1단계부터, 이미 클로즈드 API를 쓰고 있다면 2단계부터 시작해보시면 됩니다.

  1. 로컬 환경에서 오픈웨이트 체험해보기 — macOS라면 brew install ollama, Linux라면 공식 스크립트로 Ollama를 설치하고 ollama run qwen2.5-coder:7b를 실행해볼 수 있습니다. 본인이 자주 쓰는 프롬프트 몇 가지를 넣어보면 체감 품질을 빠르게 파악할 수 있습니다.

  2. 현재 워크로드의 월 API 비용 계산해보기 — OpenAI 대시보드에서 지난달 토큰 사용량을 확인하고, 같은 볼륨을 DeepInfra(DeepSeek-V3 기준 입력 $0.14/M 토큰, 2026년 6월 기준)로 돌렸을 때 비용을 비교해볼 수 있습니다. 차이가 크다면 고볼륨 배치 워크로드부터 전환을 검토해보시면 좋습니다.

  3. LiteLLM으로 추상화 레이어 도입 검토하기 — 지금 당장 전환하지 않더라도 litellm.completion(model="...") 한 줄로 100개 이상의 모델을 동일 인터페이스로 호출할 수 있게 감싸두면, 나중에 모델을 바꿀 때 model 문자열 하나만 교체하면 됩니다.


참고 자료

  • Open-Weight vs Closed-Source AI Models 2026: Gap Analysis | Digital Applied
  • Best AI Models May 2026: Closed vs Open-Weight Tested | Local AI Master
  • Open-Source vs Closed-Source AI in 2026: Enterprise Strategy | StratosAlly
  • Open Source vs Closed LLMs: The 2026 Decision Framework | Let's Data Science
  • Best Open Source LLM in 2026: Rankings, Benchmarks | BenchLM.ai
  • Open-Weight Models H1 2026: DeepSeek, Qwen, Llama Recap | Digital Applied
  • Open-Weight AI Models Are Catching Up: Enterprise Automation | MindStudio
  • How to Run Open-Weight AI Models Locally with Ollama and LM Studio | MindStudio
  • vLLM vs Ollama vs LM Studio: The 2026 Production Self-Host Benchmark | Codersera
  • 개방형 AI 모델도 급이 있다…'오픈소스'와 '오픈웨이트' 차이는? | ZDNet Korea
  • Open vs Closed Source AI Models: Intelligence, Price & Speed | DeepInfra
#LLM#오픈웨이트#vLLM#Ollama#LiteLLM#LoRA#RAG#파인튜닝#PagedAttention#데이터주권
공유하기

목차

목차핵심 개념오픈웨이트 ≠ 오픈소스: 실무에서 중요한 이유2026년 주요 모델 현황과 VRAM 요구사항추론 엔진 핵심 개념실전 적용예시 1: 규제 산업 내부 배포 — VPC 안에서 LLM 직접 운영하기예시 2: 고볼륨 자동화 — 비용이 결정적인 배치 워크로드예시 3: 로컬 개발 환경 — Ollama로 빠르게 실험하기장단점 분석오픈웨이트의 강점클로즈드의 강점단점 및 주의사항실무에서 가장 흔한 실수마치며참고 자료

추천 포스트

에이전틱 AI 설계 7대 패턴
AI

에이전틱 AI 설계 7대 패턴

Use + ReAct | KB, 티켓 DB 등 외부 시스템 반복 조회 | | 응답 작성 | 응대 에이전트 | Reflection | 발송 전 어조·정확도 자체 검토 | | 에스컬레이션 | 전체 파이프라인 | Human-in-the-Loop | 자동 해결 불가 시 담당자 연결 | ...

2026년 06월 06일읽는 데 9분
사내 REST API를 LLM이 직접 호출하게 만드는 법: TypeScript MCP 서버 구현과 Gateway 패턴
AI

사내 REST API를 LLM이 직접 호출하게 만드는 법: TypeScript MCP 서버 구현과 Gateway 패턴

팀에서 AI 에이전트를 도입하려다 "그래서 우리 내부 API는 어떻게 연결해?"라는 질문에 막혀본 적 있으신가요? 저도 처음엔 LLM에게 사내 API 문서를 통째로 붙여넣거나, 직접 fetch 코드를 프롬프트에 넣어주는 방식을 시도했습니다. 잘 됩니다—딱 한 번만요. 그 다음 요청부터는...

2026년 06월 07일읽는 데 19분
Pydantic AI로 LLM 응답을 타입 안전하게 검증하기
AI

Pydantic AI로 LLM 응답을 타입 안전하게 검증하기

LLM을 프로덕션에 붙여본 분이라면 이런 상황을 한 번쯤 겪어봤을 겁니다. GPT한테 JSON으로 응답하라고 시스템 프롬프트까지 꼼꼼히 썼는데, 정작 런타임에 가 터지는 상황. 아니면 가 어떤 날은 고 어떤 날은 인 상황. LLM 출력을 딕셔너리로 받아 쓰는 코드는 언제나 이런 시한폭탄...

2026년 06월 07일읽는 데 22분
Qwen3-Coder 로컬 실행: RTX 3090 한 장으로 SWE-bench 70% AI 코딩 에이전트 세팅하기
AI

Qwen3-Coder 로컬 실행: RTX 3090 한 장으로 SWE-bench 70% AI 코딩 에이전트 세팅하기

클라우드 AI 비용 청구서가 두 달 연속 두 배씩 오르는 걸 보면서 진지하게 대안을 찾기 시작했습니다. 솔직히 "오픈소스가 얼마나 하겠어"라는 편견보다, 이전에 몇 가지 오픈소스 코딩 모델을 써봤다가 실망했던 경험이 더 컸습니다. 특히 레거시 코드베이스에서 파일 여러 개를 넘나드는 리팩...

2026년 06월 06일읽는 데 22분
AI 에이전트 LLM 비용이 폭증하는 구조와 60~80% 절감 전략
AI

AI 에이전트 LLM 비용이 폭증하는 구조와 60~80% 절감 전략

에이전트형 AI 시스템을 프로덕션에 올려본 경험이 있다면, 한 번쯤은 청구서를 보고 멈칫했던 적이 있을 겁니다. "분명히 프롬프트 몇 번 날린 것뿐인데, 왜 이렇게 많이 나왔지?" 저도 처음에는 단순히 토큰 수를 줄이면 된다고 생각했는데, 실제로는 그게 아니었습니다. 문제의 핵심은...

2026년 06월 05일읽는 데 21분
LLM 에이전트 출력 검증: 할루시네이션이 JSON 스키마를 통과하는 이유와 3레이어 방어 설계
AI

LLM 에이전트 출력 검증: 할루시네이션이 JSON 스키마를 통과하는 이유와 3레이어 방어 설계

LLM 기반 에이전트를 프로덕션에 올리고 나면 생각보다 빨리 이상한 장애를 마주치게 됩니다. 로그를 뒤져보면 JSON 파싱은 성공했고, 스키마 검증도 통과했는데, 다운스트림 서비스에서 엉뚱한 값이 들어왔다며 에러가 납니다. 저도 처음엔 "스키마를 맞췄는데 왜?" 하고 한참을 헤맸는데, ...

2026년 06월 05일읽는 데 24분