← Back to list

“이 장애, 얼마나 심각한가요?” 사용자 경험을 기준으로 비즈니스 심각도를 정의하다

안녕하세요, 큐레이터 서비스를 담당하고 있는 Partner Growth PM 최혜원, Backend Engineer 권혁주입니다.

Hyewon Choi in MUSINSA techblog — 무신사 테크 블로그 · 2026-02-24 22:01 · 4 claps · 16.0 min read
#비즈니스심각도 #cuj #csp #sev #장애대응프로세스
Open on Medium ↗
Wiki topics: 🌐 · Web Development

“이 장애, 얼마나 심각한가요?” 사용자 경험을 기준으로 비즈니스 심각도를 정의하다

안녕하세요, 큐레이터 서비스를 담당하고 있는 Partner Growth PM 최혜원, Backend Engineer 권혁주입니다.

큐레이터 서비스는 인플루언서가 SNS를 통해 상품을 소개하고, 해당 경로를 통해 발생한 구매 성과에 대해 수수료를 지급받는 팀 무신사의 공식 어필리에이트 서비스입니다. 인플루언서 커머스가 성장함에 따라, 큐레이터를 통한 매출 기여 역시 팀 무신사 비즈니스에서 점차 중요한 영역으로 확대되고 있습니다.

서비스의 비즈니스적 중요도가 높아지면서, 장애 발생 시 어떤 이슈를 우선적으로 대응해야 하는지에 대한 명확한 판단 기준과 이를 뒷받침할 체계적인 관리 프로세스의 필요성도 함께 커졌습니다. 이러한 배경에서 큐레이터 서비스의 비즈니스 심각도 정의를 시도하게 되었습니다.

이번 프로젝트는 프로덕트에서 비즈니스 관점의 핵심 사용자 여정(Critical User Journey) 을 정의하고, 이를 기준으로 엔지니어링과 함께 서비스 SLI(Service Level Indicator), SLA(Service Level Agreement) 기준을 수립하고 SEV(Severity) 심각도를 판단하여, 대시보드 및 얼럿 시스템 구축으로 확장한 협업 프로젝트입니다.

이 글에서는 CUJ, CSP, SLI, SLA, SEV 등 다소 생소할 수 있는 용어들이 함께 등장합니다. 각 개념은 서로 다른 역할을 가지지만, 비즈니스 심각도를 정의하고 장애를 판단하는 과정에서는 긴밀하게 연결되어 있습니다.

본격적인 내용에 앞서, 이후 설명을 보다 쉽게 이해하실 수 있도록 이번 프로젝트에서 언급되는 주요 용어들을 먼저 간단히 정리해보고자 합니다.

이제 공통의 용어를 정리했으니, 실제 서비스 운영 과정에서 우리가 마주했던 질문으로 들어가보겠습니다.

“이 장애, 그래서 얼마나 심각한가요?”

*서비스를 운영하면서 장애 상황을 마주할 때마다 반복적으로 등장하던 질문이 있었습니다. *“이 장애는 어느 정도로 심각한가요?” “지금 바로 대응해야 하나요, 아니면 조금 지켜봐도 되나요?”

기존에도 에러율, 지연시간 등 SEV 지표를 기준으로 한 장애 레벨은 존재했습니다. SEV(Severity)는 장애가 서비스와 비즈니스에 미치는 영향도를 기준으로 한 심각도 등급입니다. 장애 발생 시 대응 우선순위, 커뮤니케이션 범위, 투입 리소스를 결정하기 위해 사용됩니다. 하지만 큐레이터 서비스에서는 기술적으로 동일한 장애라도 비즈니스 영향은 크게 달라지는 경우가 자주 발생했습니다.

예를 들어,

  • 특정 페이지의 에러율이 일시적으로 상승했지만 큐레이터 서비스의 핵심 기능인 수익 발생 및 기여 측정에 영향 없는 경우
  • 고객이 경험하는 페이지는 아니지만, 구매 기여 누락이나 수익 오집계로 이어지는 경우

이처럼 장애의 ‘기술적 크기’와 ‘비즈니스적 치명도’가 항상 일치하지 않는 상황에서, 우리는 점점 더 자주 장애의 우선순위를 두고 논의하게 되었습니다.

기존 심각도 기준이 충분하지 않았던 이유

전사 공통의 SEV 기준은 이미 존재했고, 에러율, 지연시간 등 객관적인 지표를 기반으로 판단할 수 있었습니다. 하지만 큐레이터 서비스에 그대로 적용해보니 한계가 분명해졌습니다.

  • 동일한 에러율이라도 어떤 기능에서는 단순 불편에 그치고, 어떤 기능에서는 즉각적인 수익 손실로 이어졌습니다.
  • 어떤 장애는 빠르게 복구하면 영향이 제한적이었지만,어떤 장애는 고객 경험 및 신뢰를 훼손해 회복 비용이 훨씬 컸습니다.

결국 문제는 ‘기술 지표가 부족해서’가 아니라, 비즈니스 관점에서 무엇이 치명적인지에 대한 기준이 명시적으로 정의되지 않았다는 점이었습니다.

그래서 본 프로젝트의 출발점은 기술이 아니라, 비즈니스가 성립되는 구조를 다시 바라보는 것이었습니다.

비즈니스 심각도 정의 접근 방식

“그렇다면, 비즈니스 관점에서의 심각도는 어디서부터 어떻게 정의해야 할까?”

이번 비즈니스 심각도 정의 프로젝트에서는 개별 장애나 지표를 바로 정의하기보다, 비즈니스가 성립되는 구조를 단계적으로 분해하는 방식을 선택했습니다. 이를 위해 아래와 같은 4단계 프로세스로 비즈니스 심각도 정의를 진행했습니다.

비즈니스 심각도 정의 4단계

  1. 핵심 사용자 여정(CUJ) 정의 고객이 서비스를 통해 핵심 목표를 달성하는 경로를 정의하고, 서비스의 핵심 가치와 반드시 지켜져야 할 단계들을 식별합니다.
  2. CSP / NON-CSP 구분 핵심 사용자 여정 중에서도, 장애 발생 시 매출·전환에 직접적인 영향을 주는 핵심 경로(CSP)와 그렇지 않은 경로(NON-CSP)를 서비스 Function 단위로 구분합니다.
  3. CSP Priority 정의 CSP로 분류된 기능들 사이에서도 고객 경험과 비즈니스 영향도의 크기에 따라 대응 우선순위를 나누고, 비즈니스 가치에 critical한 기준을 등급화합니다.
  4. SEV 설계 및 시스템 연결 앞서 정의한 기준을 기반으로 SLI(Service Level Indicator) 지표를 수립합니다. SLI는 서비스의 현재 상태를 수치로 측정하기 위한 지표이며, 서비스가 얼마나 잘 동작하고 있는지를 객관적으로 나타냅니다. 도출된 SLI를 근거로 엔지니어링의 SEV(Severity, 장애 심각도 등급) 판단 체계를 수립하고, 이를 모니터링 및 알림(alert) 시스템으로 연동합니다.

이러한 단계적 접근을 통해, ‘장애를 어떻게 감지할 것인가’가 아니라 ‘무엇을 기준으로 중요하다고 판단할 것인가’에 초점을 맞추었습니다.

1. 출발점: 큐레이터 서비스의 핵심 사용자 여정(CUJ)

프로덕트 관점에서 서비스의 장애를 판단하기에 앞서, 우리는 먼저 서비스가 언제 ‘정상적으로 작동하고 있다’고 말할 수 있는지에 대한 기준이 필요하다고 느꼈습니다. 이 기준이 없다면, 에러율이나 지연시간 같은 수치는 존재하더라도 그것이 비즈니스적으로 얼마나 중요한 문제인지 설명하기 어렵기 때문입니다.

그동안 프로덕트에서는 서비스 장애가 실제로 발생한 이후 대응 과정에서 판단을 내리는 경우가 대부분이었고, 사전에 장애를 구조적으로 분석하는 깊은 고민으로는 이어지지 못했습니다. 그 결과 어떤 장애가 정말 중요한지, 무엇을 먼저 개선해야 하는지에 대한 판단 기준이 명확하지 않았고, 이를 정리하기 위해 고객 경험 관점에서 서비스가 전달해야 하는 가장 중요한 가치가 무엇인지부터 다시 고민하게 되었습니다.

이 고민의 출발점으로 선택한 것이 바로 핵심 사용자 여정(Critical User Journey, CUJ) 입니다.

CUJ는 사용자가 서비스에서 핵심 가치를 경험하기 위해 반드시 거쳐야 하는 필수 경로이며, 프로덕트 관점에서 ‘이 서비스가 제대로 가치를 전달하고 있는가’를 판단하는 기준선에 해당합니다.

큐레이터 서비스에서 이 기준은, 큐레이터가 자신의 활동을 통해 수익을 창출하고 그 결과를 신뢰할 수 있는 경험을 제공하는지로 이어집니다. 즉, 서비스의 성공 여부는 개별 기능의 정상 동작이 아니라, 수익이 발생하고 그 기여가 정확히 측정 되는 경험이 끊김 없이 이어지는지에 달려 있다고 보았습니다.

이 관점에서 정의한 큐레이터 서비스의 핵심 사용자 여정(Critical User Journey)은 다음과 같습니다.

“큐레이터가 링크를 공유하고, 해당 링크를 통해 유입된 고객이 주문을 완료하며, 그 주문의 구매 기여가 정확히 측정된다.”

  • 서비스 핵심 가치: 큐레이터가 추천한 상품 판매로 수익을 얻는 경험을 한다.
  • 핵심 단계: 제휴 링크 생성 → 고객 유입 → 구매 발생→ 기여 측정
  • 성공 조건: 구매 기여 측정이 정확하게 이루어지고, 수익이 정상 반영되는 것
  • 비즈니스 영향: 해당 여정이 정상 작동하지 않으면 서비스 핵심 가치(수익 창출)가 중단됨

이 여정은 큐레이터 서비스가 제공하는 핵심 가치가 완성되는 최소 경로입니다. 따라서 이 흐름 중 어느 하나라도 정상적으로 동작하지 않는다면, 이는 단순한 기능 장애가 아니라 서비스가 본래 제공해야 할 가치를 전달하지 못하는 상태에 가깝다고 판단했습니다.

이렇게 정의된 CUJ는 이후 단계에서 어떤 기능이 비즈니스적으로 치명적인지(CSP), 그리고 장애 발생 시 무엇을 먼저 대응해야 하는지(SEV)를 판단하는 기준으로 활용되었습니다.

2. CSP/NON-CSP 정의: 무엇이 정말 치명적인가를 구분하기

*핵심 사용자 여정(CUJ)을 정의하고 나니, 다음 질문이 자연스럽게 이어졌습니다. *“이 여정을 구성하는 모든 기능이 동일한 수준으로 중요한가?”

CUJ는 큐레이터 서비스의 비즈니스가 성립되기 위한 최소 조건을 설명해 주지만, 실제 서비스는 이 여정을 구성하는 여러 기능과 시스템 위에서 동작합니다. 그리고 이들 중 일부는 장애 발생 시 곧바로 수익 손실이나 기여 누락으로 이어지는 반면, 일부는 불편을 유발하더라도 비즈니스 영향은 제한적인 경우도 있었습니다.

이 차이를 명확히 구분하기 위해 도입한 개념이 CSP(Critical Serving Path) 입니다. CSP란, 고객의 핵심 행동에서 장애 발생 시 직접적으로 매출·전환에 영향을 주는 핵심 경로를 의미하며, 큐레이터 서비스에서 CSP는 다음과 같이 정의했습니다.

큐레이터 서비스의 CSP는 수익 발생과 구매 기여 측정에 직접적인 영향을 주는 핵심 서비스 경로에 해당하며, 즉, 장애가 발생했을 때 큐레이터의 수익이 발생하지 않거나, 구매 기여가 누락되거나, 수익 집계의 정합성이 깨질 수 있는 경로를 CSP로 보았습니다.

이에 따라 다음 기능들이 CSP로 분류되었습니다.

  • 제휴 링크 생성
  • 고객 유입 트래킹
  • 구매 기여 측정

반대로, 큐레이터 수익 활동 이전에 발생하는 사용자 경험 관련 기능이나 장애 발생 시 내부 운영으로 대체·보완 가능한 기능은 NON-CSP로 분류했습니다. 이 구분을 통해, 모든 장애를 동일한 기준으로 바라보는 대신 비즈니스적으로 반드시 지켜야 할 경로를 명확히 식별할 수 있었습니다.

3. CSP Priority: 고객 경험과 비즈니스 영향을 함께 고려하다

핵심 경로(CSP)로 분류된 기능들이라 하더라도, 장애가 발생했을 때 고객 경험 저하로 인해 발생하는 비즈니스 영향의 크기는 달랐습니다. 이에 따라 CSP 내부에서도, 사용자 경험과 비즈니스 영향을 함께 고려한 Priority 구분이 필요했습니다.

CSP Priority 정의 단계에서는 장애로 인해 어떤 사용자의 어떤 경험이 중단되는지를 기준으로 삼고, 그 경험 단절이 매출·신뢰·운영 비용 등 비즈니스 전반에 미치는 영향을 함께 고려해 정의했습니다.

  • P0: Customer 구매 경험 단절 고객이 제휴 링크를 통해 유입된 이후 구매를 완료하지 못하거나, 구매 기여가 정상적으로 측정되지 않는 경우입니다. 고객의 핵심 구매 경험이 직접적으로 중단되며, 서비스 신뢰와 성과에 즉각적인 영향을 미칩니다. (예: 제휴 링크 접근 불가, 구매 기여 누락, 기여 측정 불일치 등)
  • P1: Curator 수익 활동 경험 단절 고객의 구매는 가능하지만, 큐레이터가 상품을 탐색하거나 링크를 생성·관리하는 과정에서 장애가 발생해 수익 활동이 제한되는 경우입니다. (예: 추천 상품 탐색 불가, 큐레이터샵 관리 오류, 제휴 링크 생성 불가 등)
  • P2: Curator 일반 서비스 이용 경험 단절 큐레이터의 일부 기능 이용에 불편이 발생하지만, 구매 발생이나 기여 측정에는 직접적인 영향이 없는 경우입니다. (예: 큐레이터 회원 가입/정보 수정 불가 등)
  • P3: 운영·관리 경험 단절 서비스의 핵심 기능에는 영향이 없으나, 내부 운영이나 관리 과정에서 불편이 발생하는 경우입니다. (예: 내부 어드민, 대시보드 오류 등)

이렇게 CSP Priority를 정의함으로써, 장애 발생 시 고객 경험과 비즈니스 영향 관점에서 무엇을 먼저 보호해야 하는지를 명확히 판단할 수 있게 되었습니다.

4. 비즈니스 심각도를 SEV로 연결하기

CUJ와 CSP, Priority 정의까지는 장애를 비즈니스 관점에서 해석하기 위한 기준을 세우는 과정이었다면, 다음 단계는 이를 엔지니어링의 SEV 기준으로 연결하는 것이었습니다.

SEV는 장애 대응 시 얼마나 빠르게, 어디까지 대응해야 하는지를 결정하는 기준이기 때문에 비즈니스 심각도가 엔지니어링에서 바로 활용 가능한 형태로 번역될 필요가 있었습니다. 기존 SLI인 Availability, Latency(P95)를 그대로 사용하되, CSP 여부와 Priority를 함께 고려해 SEV를 판단하도록 기준을 정렬했습니다.

SEV 레벨 정의 (요약)

SEV 판단의 핵심 기준: 무엇을 기준으로 장애라 부를 것인가?

서비스를 운영하다 보면 크고 작은 문제들이 발생합니다. 하지만 모든 문제를 ‘장애(Severity, 이하 SEV)’로 규정하고 모든 엔지니어가 달려들 수는 없습니다. 리소스는 한정되어 있기 때문이죠. 그렇다면 어떤 기준으로 SEV 등급을 결정해야 할까요? **Google의 SRE(Site Reliability Engineering) 방법론 **에서는 서비스의 건강 상태를 정량적으로 측정하고, 이를 바탕으로 객관적인 판단을 내릴 것을 권장합니다. 그 중심에는 다음 두 가지 핵심 요소가 있습니다.

1) SLI (Service Level Indicator): 서비스의 ‘건강 지표’ SEV를 판단하기 위한 첫 번째 단계는 ‘무엇을 측정할 것인가’입니다. SLI는 서비스 수준을 나타내는 정량적인 측정치를 의미하며, 쉽게 말해 우리 서비스의 현재 건강 상태를 보여주는 ‘체온계’와 같습니다. 활용 목적은 SLI는 단순히 숫자를 나열하는 것이 아니라, 서비스의 상태를 객관적으로 측정하고 뒤에서 설명할 SLO 달성 여부 및 SEV 등급을 결정하는 가장 기초적인 근거 데이터가 됩니다.

주요 예시

  • 가용성(Availability): 전체 요청 중 성공한 요청의 비율
  • 응답 지연(Latency): 요청이 처리되는 데 걸리는 시간 (예: P95 latency — 하위 95%의 유저가 겪는 속도)
  • 에러율(Error Rate): HTTP 5XX 에러 등 실패한 요청의 비율
  • 처리량(Throughput): 초당 처리되는 요청 수 (QPS)
  • 이벤트 적재 성공률: 데이터 파이프라인에서 손실 없이 데이터가 쌓이는 비율

2) SLO (Service Level Objective)와의 결합: ‘장애의 경계선’ SLI가 체온계라면, SLO는 ‘어느 정도 온도부터 해열제를 먹을 것인가(장애인가)’를 결정하는 기준치입니다. SEV는 단순히 “속도가 느리다”가 아니라, “설정한 SLO를 얼마나 벗어났는가”를 보고 결정합니다.

판단 프로세스

  • SLI 관측: 현재 에러율이 5% 발생 중임 (SLI)
  • SLO 비교: 우리 서비스의 에러율 기준은 0.1% 미만임 (SLO)
  • SEV 결정: SLO를 심각하게 초과했으며, 영향 범위가 넓으므로 SEV 1 발령

3) 데이터 기반의 의사결정 결국 SEV 판단의 핵심은 “주관적인 느낌이 아닌, 정량적인 데이터(SLI)와 약속된 기준(SLO)에 의거하는 것”입니다.

  • SLI를 통해 실시간 데이터를 수집하고,
  • SLO를 통해 허용 가능한 범위를 설정하며,
  • 이 범위를 벗어난 정도와 사용자 영향도에 따라 SEV 등급을 부여합니다.

이렇게 체계화된 기준이 있다면, 긴박한 장애 상황에서도 팀 전체가 혼선 없이 빠르게 대응 우선순위를 정할 수 있습니다.

4) 비즈니스 영향 (CSP / NON-CSP Priority)

핵심 사용자 여정(CSP)에 직접 영향을 주는 기능은 더 높은 심각도를 가집니다. 이렇게 정의함으로써, 장애의 크기보다 ‘이 장애가 비즈니스에 어떤 영향을 주는지’를 기준으로 대응 우선순위를 정할 수 있게 되었습니다.

대시보드와 얼럿으로 운영하기

1)핵심 사용자 여정 기준 대시보드 대시보드는 핵심 사용자 여정(CUJ)을 구성하는 주요 기능별 SEV를 한눈에 볼 수 있도록 구성했습니다. 각 기능의 Error Rate, Latency(P95)을 함께 표시하여, 어떤 기능에서 문제가 발생했는지 빠르게 파악할 수 있습니다.

각 단계를 분리해 모니터링함으로써, 장애 발생 시 어느 지점에서 비즈니스 흐름이 끊어졌는지를 빠르게 파악할 수 있도록 했습니다.

2) 얼럿: 무엇이 끊겼는지를 바로 알 수 있게 얼럿은 단순한 에러 알림이 아니라, 문제의 위치와 심각도를 즉시 파악할 수 있도록 설계했습니다.

  • 어떤 기능에서 문제가 발생했는지
  • 문제의 유형이 무엇인지 (에러율 / 지연시간)
  • 즉시 대응이 필요한 수준(SEV)인지

alert message

alert message

알림을 받는 순간부터 “지금 무엇이 가장 중요한 문제인지”를 바로 판단할 수 있도록 하기 위함입니다.

3) 운영 관점에서 달라진 점

이 기준을 대시보드와 얼럿에 반영한 이후, 장애 대응 방식에도 명확한 변화가 있었습니다.

  • 장애 우선순위에 대한 논의 시간 감소
  • 프로덕트–엔지니어링 간 판단 기준 정렬
  • 기술 상태가 아닌 비즈니스 영향 중심의 대응 정착

결과적으로, 장애 대응이 더 빠르고 일관된 방향으로 이루어지기 시작했습니다.

비즈니스 심각도 정의 이후, 무엇이 달라졌는가: “장애 지표는 숫자가 아니라, 합의된 관점이다”

이번 비즈니스 심각도 정의 프로젝트를 통해 얻은 가장 큰 인사이트는 명확했습니다. 장애를 바라보는 기준은 기술 지표 자체가 아니라, 무엇을 먼저 지켜야 하는지에 대한 관점이라는 점이었습니다.

  • 장애 대응 기준의 전환: 장애 발생 시, “에러율이 몇 퍼센트인가?”보다 “고객 경험이 영향을 받는가?”를 먼저 묻게 되었습니다.
  • 대응 우선순위 체계화: 기술 상태가 아닌 고객 경험 저하가 비즈니스에 미치는 영향 기준으로 대응 순서를 판단할 수 있게 되었습니다.
  • 커뮤니케이션 리소스 감소: 합의된 비즈니스 심각도를 기준으로 대시보드 모니터링을 진행하므로 장애 우선순위에 대한 논의 비용이 눈에 띄게 줄었습니다.

장애의 심각도가 지표로 자동 결정되기에 앞서, 서비스의 핵심 가치와 사용자 여정을 기준으로 중요도를 판단하는 구조를 마련한 전환점이었습니다. 앞으로도 큐레이터 서비스에서는 핵심 사용자 여정을 중심으로, 비즈니스와 기술이 같은 질문을 던지고 같은 판단을 내릴 수 있는 운영 구조를 지속적으로 고도화해 나가고자 합니다.

Partner Growth 팀 소개

Partner Growth 인플루언서 플랫폼에서는 무신사의 핵심 비즈니스 모델인 인플루언서 마케팅 서비스를 담당하고 있습니다. 브랜드와 인플루언서 간 협업을 가장 합리적인 구조로 연결하여, 무신사/브랜드/인플루언서 모두의 성장을 돕는 것이 우리 팀의 미션입니다. 단순히 무신사의 핵심 수익원이 되는 것을 넘어서, 높은 기술력을 가지고 브랜드와 인플루언서의 성공을 돕는 플랫폼이 되는 것을 지향점으로 서비스를 만들어가고 있습니다. 2026년도에는 인플루언서 플랫폼의 스케일업을 본격적으로 추진합니다. 이 여정을 함께 이끌어갈 Backend, Frontend Engineer를 찾습니다. 많은 지원 부탁드립니다!

🔗 무신사 채용 페이지: https://corp.musinsa.com/ko/

🔗 (Backend)광고&인플루언서 개발팀 채용 공고: https://www.musinsacareers.com/ko/o/175930

🔗 (Frontend)코어 파트너 프론트엔드 채용 공고: https://www.musinsacareers.com/ko/o/169076

🚀 팀 무신사 테크 소식을 받아보는 링크드인

🚀 팀 무신사 뉴스룸


메타데이터
post_id
b13bf1d52b19
slug
이-장애-얼마나-심각한가요-사용자-경험을-기준으로-비즈니스-심각도를-정의하다-b13bf1d52b19
url
https://techblog.musinsa.com/%EC%9D%B4-%EC%9E%A5%EC%95%A0-%EC%96%BC%EB%A7%88%EB%82%98-%EC%8B%AC%EA%B0%81%ED%95%9C%EA%B0%80%EC%9A%94-%EC%82%AC%EC%9A%A9%EC%9E%90-%EA%B2%BD%ED%97%98%EC%9D%84-%EA%B8%B0%EC%A4%80%EC%9C%BC%EB%A1%9C-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EC%8B%AC%EA%B0%81%EB%8F%84%EB%A5%BC-%EC%A0%95%EC%9D%98%ED%95%98%EB%8B%A4-b13bf1d52b19
canonical_url
https://techblog.musinsa.com/%EC%9D%B4-%EC%9E%A5%EC%95%A0-%EC%96%BC%EB%A7%88%EB%82%98-%EC%8B%AC%EA%B0%81%ED%95%9C%EA%B0%80%EC%9A%94-%EC%82%AC%EC%9A%A9%EC%9E%90-%EA%B2%BD%ED%97%98%EC%9D%84-%EA%B8%B0%EC%A4%80%EC%9C%BC%EB%A1%9C-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EC%8B%AC%EA%B0%81%EB%8F%84%EB%A5%BC-%EC%A0%95%EC%9D%98%ED%95%98%EB%8B%A4-b13bf1d52b19
author_url
https://medium.com/@hyewon.choi_84241
status
ok
fetched_at
2026-06-20 20:29:01