9장. 웹 크롤러 설계

가상 면접 사례로 배우는 대규모 시스템 설계 기초를 읽고 정리한 글입니다.

 

이번 챕터를 읽으면서 가볍게 크롤링만 적용해 봤는데, 생각보다 고려할 부분이 정말 많구나 라는 걸 깨달았다.

 

 

크롤러는 ‘로봇’이나 ‘스파이더’라는 이름으로도 불리며, 검색 엔진을 비롯해 다양한 목적으로 사용된다.

주 목적은 웹에 새롭게 올라오거나 갱신된 콘텐츠를 빠르고 정확하게 수집하는 것이다.

크롤러는 특정 웹 페이지들에서 시작해, 그 안의 하이퍼링크를 따라가며 콘텐츠를 순차적으로 수집해 나간다.

크롤러 활용 예시

활용 예시	설명
검색 엔진 인덱싱	검색 엔진의 로컬 인덱스를 구축하기 위해 크롤러를 사용한다. 대표적인 예시가 구글의 google bot이다.
웹 아카이빙	웹페이지들을 주기적으로 수집, 저장하여 아카이빙하는 용도다. 각국 국립 도서관 등에서 많이 사용한다.
웹 마이닝	대량의 웹 데이터를 분석해 의미 있는 지식이나 패턴을 도출한다.
웹 모니터링	저작권, 상표권 침해나 특정 이슈의 모니터링 등에도 활용된다. (예: Digimarc의 웹 크롤러)

웹 크롤러의 복잡도는 처리해야 하는 데이터의 규모에 따라 천차만별이다.
학급 과제 수준으로 짧게 끝낼 수도 있고, 별도의 엔지니어링 팀이 24시간 관리해야 하는 대형 프로젝트가 될 수도 있다.
따라서 크롤러 설계에서 가장 중요한 첫 단계는 목표로 하는 데이터의 규모와, 필요한 주요 기능을 정확하게 정의하는 일이다.

 

 

1단계. 문제 이해 및 설계 범위 확정

웹크롤러의 기본 동작 원리

1. 입력으로 URL 집합이 주어진다.
2. 해당 URL들이 가리키는 모든 웹 페이지를 다운로드한다.
3. 각 페이지에서 새로운 URL을 추출한다.
4. 추출한 URL을 다시 수집할 URL 목록에 추가하며 이 과정을 반복한다.

겉보기에는 단순해 보이지만, 대규모 시스템으로 확장할 때 고려해야 할 변수들이 매우 많다. 따라서 설계 전, 아래와 같은 질문을 통해 요구사항을 확정하고, 설계 범위를 정한다.

 

질문 예시

• 크롤러의 주된 용도는 무엇인가요? 검색 엔진 인덱스 생성용인가요? 아니면 데이터 마이닝? 아니면 그 외의 다른 용도가 있나요?
• 매달 얼마나 많은 웹 페이지를 수집해야 하나요?
• 새로 만들어진 웹 페이지나 수정된 웹 페이지도 고려해야 하나요?
• 수집한 웹 페이지는 저장해야 합니까? 저장 기간은 어떻게 되나요?
• 중복된 콘텐츠는 어떻게 해야 하나요?

 

웹 크롤러는 아래와 같은 속성을 가져야 한다.

속성	설명
규모 확장성	웹은 방대하기 때문에, 병렬 처리 등으로 대량의 데이터를 빠르게 처리해야 한다.
안정성	비정상적 입력(잘못된 HTML, 장애 서버, 악성코드 등)에도 견딜 수 있어야 한다.
예절(Politeness)	수집 대상 서버에 부담을 주지 않도록 요청 빈도를 조절해야 한다.
확장성	새로운 타입의 데이터(예: 이미지) 등도 쉽게 수집할 수 있어야 한다.

 

개략적 규모 추정

면접관과의 질문/답변을 통해서 아래와 같은 규모 추정이 되었다고 가정한다.

항목	값 및 산출 근거
월별 다운로드 웹페이지 수	10억 (1,000,000,000) 개
QPS (초당 요청수)	10억 ÷ 30 ÷ 24 ÷ 3600 ≒ 400
피크 QPS	800
평균 웹페이지 크기	500KB
월별 전체 데이터	10억 x 500KB = 500TB
5년치 데이터	500TB x 12 x 5 = 30PB

 

 

2단계 개략적 설계안 제시 및 동의 구하기

아래 다이어그램에서 각 컴포넌트가 어떤 역할을 하는지, 그리고 전체 작업의 흐름을 함께 살펴본다.

시작 URL 집합

웹 크롤러는 ‘시작 URL 집합’을 출발점으로 삼는다.

가장 단순하게는 특정 대학 사이트처럼 한정된 도메인의 모든 페이지를 대상으로 시작 URL을 설정한다.

만약 전 세계의 웹을 대상으로 한다면, 주제별로 다른 시작 URL을 선택하거나, URL 공간을 여러 부분집합으로 나누어 관리한다.

즉, 어떤 URL을 시작점으로 사용할지에 대한 정답은 없으며, “왜 이런 방식으로 시작 URL을 뽑았는지” 그 의도를 설계 단계에서 잘 설명할 수 있어야 한다.

 

미수집 URL 저장소

대부분의 현대 웹 크롤러는 크롤링 상태를 2가지로 나눠 관리한다.

1. 다운로드할 URL
2. 다운로드된 URL

그리고 첫 번째 상태를 저장하는 컴포넌트를 미수집 URL 저장소 (URL frontier)라고 부른다.
FIFO 큐라고 생각하면 된다.

 

HTML 다운로더

웹페이지를 실제로 다운로드하는 컴포넌트. 다운로드 대상 URL은 앞서 말한 URL Frontier에서 받아온다.

 

도메인 이름 변환기

URL로 접근하려면 먼저 도메인 이름 → IP 주소 변환이 필요하다.
HTML 다운로더는 도메인 이름 변환기를 호출해 해당 URL의 IP를 얻어온다.

 

콘텐츠 파서

다운로드한 HTML을 파싱(구문 해석)하고, 올바른 형식인지 검증한다.
콘텐츠 파서를 별도 컴포넌트로 분리하는 이유는, 파싱 과정이 느려질 경우 크롤링 전체 성능에 영향을 줄 수 있기 때문이다.

 

중복 콘텐츠인가?

웹의 29%가량이 중복 콘텐츠라는 연구 결과가 있다.
중복 저장을 막으려면, 수집한 HTML이 이미 저장된 적이 있는지 빠르게 판단해야 한다.
이를 위해 해시 함수 등을 활용해 콘텐츠 중복 여부를 빠르게 검사한다.

 

콘텐츠 저장소

크롤러가 수집한 HTML, 혹은 기타 데이터를 저장하는 공간이다.
설계에서는 데이터의 양, 유형, 접근 빈도, 유효 기간 등을 고려해

• 대부분은 디스크 저장
• 인기 콘텐츠는 메모리에 보관

등의 계층형 저장 구조를 쓴다.

 

URL 추출기

저장한 HTML 문서들을 파싱해 링크들을 골라내는 역할.
상대경로는 전부 절대경로로 변환해 준다.

URL 필터

새로 추출한 URL을 아래 기준에 따라 걸러낸다.

• 특정 파일 타입/확장자(예:. jpg,. zip 등)는 제외
• 접근이 불가능한(오류 발생) URL은 제외
• 접근 제한 목록(deny list)에 포함된 URL은 제외

 

이미 방문한 URL?

동일 URL을 여러 번 수집하지 않으려면

• 이미 방문한 URL 저장소
• 미수집 URL 저장소

이 두 자료구조를 잘 구현해 추적한다.
블룸필터나 해시 테이블 등 메모리 효율적인 구조가 많이 쓰인다.

 

URL 저장소

URL 저장소는 이미 방문한 URL을 보관하는 저장소다.

 

전체 작업 흐름

1. 시작 URL들을 미수집 URL 저장소에 저장한다.
2. HTML 다운로더는 미수집 URL 저장소에서 URL 목록을 가져온다.
3. HTML 다운로더는 도메인 이름 변환기를 사용하여 URL의 IP 주소를 알아내고, 해당 IP 주소로 접속하여 웹 페이지를 다운받는다.
4. 콘텐츠 파서는 다운된 HTML 페이지를 파싱 하여 올바른 형식을 갖춘 페이지인지 검증한다.
5. 콘텐츠 파싱과 검증이 끝나면 중복 콘텐츠인지 확인하는 절차를 개시한다.
6. 중복 콘텐츠인지 확인하기 위해서, 해당 페이지가 이미 저장소에 있는지 본다. 이미 저장소에 있는 콘텐츠인 경우에는 처리하지 않고 버린다. 저장소에 없는 콘텐츠인 경우에는 저장소에 저장한 뒤 URL 추출기로 전달한다.
7. URL 추출기는 해당 HTML 페이지에서 링크를 골라낸다.
8. 골라낸 링크를 URL 필터로 전달한다.
9. 필터링이 끝나고 남은 URL만 중복 URL 판별 단계로 전달한다.
10. 이미 처리한 URL인지 확인하기 위하여, URL 저장소에 보관된 URL인지 살핀다. 이미 저장소에 있는 URL은 버린다.
11. 저장소에 없는 URL은 URL 저장소에 저장할 뿐 아니라 미수집 URL 저장소에도 전달한다.

 

3단계. 상세 설계

가장 중요한 컴포넌트 & 구현 기술을 상세하게 보자

• DFS vs BFS
• 미수집 URL 저장소
• HTML 다운로더
• 안정성 확보 전략
• 확장성 확보 전략
• 문제 있는 콘텐츠 감지 및 회피 전략

 

DFS를 쓸 것인가, BFS를 쓸 것인가

웹은 유향 그래프나 같다. 페이지는 노드, 하이퍼링크는 엣지라고 보면 된다.

즉, 크롤링 == 그래프를 탐색하는 과정이다

DFS, BFS는 바로 이 그래프 탐색에 널리 사용되는 두 가지 알고리즘이다.

하지만 DFS는 좋은 선택이 아닐 가능성이 높다. 그래프 크기가 클 경우 어느 정도로 깊숙이 가게 될지 가늠하기 어려워서다.

따라서 웹 크롤러는 보통 BFS를 사용한다.

큐를 사용하는 알고리즘으로, 한쪽으로는 탐색할 URL을 집어넣고, 다른 한쪽으로는 꺼내기만 한다.

 

그런데 이 구현법에는 두 가지 문제점이 있다.

1. 한 페이지에서 추출한 링크 대부분이 같은 호스트(서버)로 향하는 경우가 많아, 특정 서버에 짧은 시간에 여러 요청이 몰릴 수 있다. 이것은 크롤러 예절(politeness)에 위배된다.
2. 기본 BFS 큐는 우선순위를 다루지 못한다. 실제로는 페이지의 중요도(예: PageRank), 트래픽 양, 업데이트 빈도 등 여러 기준을 반영해 탐색 순서를 조절해야 한다.

 

미수집 URL 저장소

미수집 URL 저장소를 활용하면 위의 문제를 좀 쉽게 해결할 수 있다.

 

앞서 살펴본 대로 URL 저장소는 다운로드할 URL을 보관하는 장소다.
이 저장소를 잘 구현하면 politeness를 갖추면서, 우선순위를 구별하는 크롤러를 구현할 수 있다.

 

예의

동일 웹사이트에 대해서는 한 번에 한 페이지만 요청한다. 같은 페이지를 다운로드하는 태스크는 시간차를 두고 실행한다.
구현 방법 👉🏻 웹사이트의 호스트명과 다운로드를 수행하는 작업 스레드 사이의 관계를 유지하면 된다.

 

각 다운로드 스레드는 별도 FIFO 큐를 가지고 있어서 해당 큐에서 꺼낸 URL 만 다운로드한다.

호스트별로 들어가는 큐를 지정해 주면 됨. 같은 큐에서 나온 것은 동시에 접속하지 않는다.

• queue router: 같은 호스트에 속한 URL은 언제나 같은 큐로 가도록 보장하는 역할
• mapping table: 호스트 이름과 큐 사이의 관계를 보관하는 테이블
• FIFO 큐: 같은 호스트에 속한 URL은 언제나 같은 큐에 보관된다.
• queue selector: 큐 선택기는 큐들을 순회하면서 큐에서 URL을 꺼내서 해당 큐에서 나온 URL을 다운로드하도록 지정된 작업스레드에 전달하는 역할을 한다.
• 작업스레드(worker thread): 작업 스레드는 전달된 URL을 다운로드하는 작업을 수행한다.
  전달된 URL은 순차적으로 처리될 것이며, 작업들 사이에는 일정한 지연시간을 둘 수 있다.

 

우선순위

유용성에 따라 URL의 우선순위를 나눌 때는 페이지 랭크, 트래픽 양, 갱신 빈도 등 다양한 척도를 사용할 수 있을 것이다.

본 절에서 설명할 prioritizer는 URL 우선순위를 정하는 컴포넌트다.

큐에 URL을 저장하기 전에 prioritizer(순위 결정 장치)를 거치도록 설계를 변경한다.

1. 순위 결정 장치: URL을 입력으로 받아 우선순위를 계산.
2. 우선순위 별로 큐가 하나씩 할당된다. 우선순위가 높으면 선택될 확률도 올라간다.
3. 큐 선택기: 임의 큐에서 처리할 URL을 꺼낸다. 순위가 높은 큐에서 더 자주 꺼내도록 프로그램되어있다.

 

이 둘을 반영한 전체 설계는 다음과 같다.

• 전면 큐 (front queue): 우선순위 결정 과정을 처리한다.
• 후면 큐 (back queue): 크롤러의 politeness를 보장한다.

 

신선도

웹페이지는 수시로 추가되고, 삭제되고, 변경되므로 데이터의 신선함(freshness)를 유지하기 위해서 이미 다운로드한 페이지라고 해도 재수집할 필요가 있다.

 

이 작업을 최적화하기 위한 전략으로는 다음과 같은 것들이 있다.

• 웹 페이지의 변경 이력 활용
• 우선순위가 높은 페이지는 더 자주 재수집

 

미수집 URL 저장소를 위한 지속성 저장장치

대규모 시스템은 수억 개의 URL을 다루므로,

• 모든 URL을 메모리에 저장: 안정성·확장성에 문제
• 모든 URL을 디스크에 저장: 느려서 성능 저하
• 절충안:
  • 디스크에 대부분의 URL을 저장
  • 메모리에는 ‘버퍼 큐’를 두어, 자주 쓰는 URL만 관리
  • 버퍼에서 데이터가 일정량 쌓이면 디스크로 flush

 

HTML 다운로더

HTML 다운로더는 실제로 HTTP 요청을 보내 페이지를 내려받는 역할을 한다.

 

Robots.txt

로봇 제외 프로토콜이라고도 불린다. 웹사이트가 크롤러와 소통하는 표준.

웹사이트마다 robots.txt 파일을 통해 “크롤러가 어디까지 접근해도 되는가”를 명시한다.
따라서 크롤러는 사이트를 다운로드하기 전에 해당 파일에 나열된 규칙을 먼저 확인해야 한다.

 

같은 호스트에서 Robots.txt 파일을 중복으로 다운로드하는 것을 피하기 위해, 이 파일은 주기적으로 다시 다운로드하여 캐싱한다.

 

성능 최적화

HTML 다운로더에 사용할 수 있는 성능 최적화 기법들

 

1. 분산 크롤링
성능을 높이기 위해 크롤링 작업을 여러 서버에 분산.

 

2. 도메인 이름 변환 결과 캐시
DNS resolver는 크롤러 성능의 병목 중 하나인데, 이는 DNS 요청을 보내고 결과를 받는 작업의 동기적 특성 때문이다.
스레드는 DNS 요청의 결과를 받기 전까지는 다음 작업을 진행할 수 없다

크롤러 스레드 가운데 어느 하나라도 DNS resolver에 요청을 보내면, 이 요청이 완료될 때까지 다른 스레드의 요청이 모두 block 된다.
따라서 DNS 조회 결과로 얻어진 도메인 이름과 그에 상응하는 IP 주소를 캐시에 보관, 주기적으로 갱신하도록 구현하여 성능을 높일 수 있다.

 

3. 지역성
크롤링 작업을 수행하는 서버를 지역별로 분산하는 방법이다.

크롤링 서버가 크롤링 대상 서버와 지역적으로 가까우면 페이지 다운로드 시간이 줄어들 것이다. 지역성을 활용하는 전략은 크롤서버, 캐시, 큐, 저장소 등 대부분의 컴포넌트에 적용 가능하다.

 

4. 짧은 타임아웃
어떤 웹서버는 응답이 느리거나 아예 응답하지 않는데, 이런 경우를 대비해
크롤러가 최대 얼마나 기다릴지를 미리 정해두는 것이다. 타임아웃의 경우 해당 페이지 다운로드를 중단한다.

 

안정성

안정성은 성능 최적화만큼 중요하게 고려해야 할 부분이다.
시스템 안정성을 향상하기 위한 접근법 중 몇 가지를 보자.

1. 안정 해시(consistent hashing): 다운로더 서버(분산 HTML 다운로더)들에 부하를 고르게 분산하기 위해 적용가능한 기술.
2. 크롤링 상태 및 수집 데이터 저장: 장애가 발생한 경우에도 쉽게 복구할 수 있도록
   • 크롤링 상태
   • 수집된 데이터

를 지속적 저장장치에 기록해 두는 것이 바람직하다.

1. 예외처리: 예외가 발생해도 전체 시스템이 중단되지 않도록 미리 처리
2. 데이터 검증: 시스템 오류를 방지하기 위한 중요 수단. (비정상정 입력이나 환경을 대비)

 

확장성

앞선 요구사항에서 이미지를 예로 든 것처럼, 이런 시스템을 설계할 때는 새로운 형태의 콘텐츠를 쉽게 지원할 수 있도록 신경써야한다. 본 예제의 경우에는 새로운 모듈을 끼워 넣음으로써 새로운 형태의 컨텐츠를 지원할 수 있도록 설계하였다.

• PNG 다운로더는 PNG 파일을 다운로드하는 plug-in 모듈이다
• 웹 모니터는 웹을 모니터링하여 저작권이나 상표권이 침해되는 일을 막는 모듈이다.

 

문제 있는 콘텐츠 감지 및 회피

1. 중복 콘텐츠(웹 컨텐트의 30%가량은 중복)
   • 해시
   • 체크섬
     등의 방법을 사용해 중복 콘텐츠를 보다 쉽게 탐지할 수 있다.
2. 거미 덫(spider trap)
   크롤러를 무한루프에 빠뜨리도록 설계한 웹 페이지다.
   spidertrapexample.com/foo/bar/foo/bar/foo/bar/...
   • URL의 최대 길이를 제한 (모든 경우를 다 피할 수는 없음..)
   • 그래서 사람이 수작업으로 찾아낸 후 이런 사이트를 크롤러 탐색 대상에서 제외하거나 URL 필터 목록에 걸어둔다.
3. 데이터 노이즈
   어떤 콘텐츠는 거의 가치가 없다.
   (광고, 스크립트 코드 등) 이런 콘텐츠를 가능한 제외 해야 한다.

 

4단계. 마무리

좋은 크롤러가 갖추어야 하는 특성

특성	설명
규모 확장성 (Scalability)	수억~수십억 개의 웹 페이지를 수집·처리할 수 있도록 분산 시스템 구조와 확장 가능한 저장소 설계가 필수다.
예의 (Politeness)	크롤러는 대상 서버에 과도한 부하를 주지 않도록, 한 호스트에 일정 시간 이상 간격을 두고 접근한다. robots.txt 등 업계 표준을 반드시 지킨다.
확장성 (Extensibility)	새로운 콘텐츠 유형(이미지, PDF, 동영상 등)이 추가될 때 시스템 전체를 뜯어고치지 않고도, 플러그인 모듈 등으로 손쉽게 기능을 확장할 수 있다.
안정성 (Robustness)	예외 상황(네트워크 장애, 데이터 중복, 크롤러 자체 장애 등)에서도 서비스가 멈추지 않도록 장애 대응과 데이터 무결성, 자동 복구 기능을 갖춘다.

규모 확장성이 뛰어난 웹 크롤러 설계 작업은 단순하지 않다. 웹이 워낙 방대한 데다, 수없이 많은 덫이 도사리고 있기 때문이다.

 

추가로 논의하면 좋은 설계 이슈

1. 서버 측 렌더링(Server-side Rendering)

최근 많은 웹사이트가 자바스크립트, AJAX 등 클라이언트 기술을 활용해 페이지를 ‘실시간’으로 조립해서 보여준다.
즉, HTML을 그대로 받아와 파싱 해봤자 실제로 사용자가 보는 콘텐츠나 링크(동적 내비게이션, 무한 스크롤, 팝업 등)는 나타나지 않는다.

 

이 문제를 해결하려면

• 서버 측에서 실제로 브라우저를 실행시키듯 JS 실행 환경을 만들어
• 해당 페이지를 렌더링(rendering) 한 후
• 그 결과 HTML에서 링크를 추출하는 전략을 쓴다.
  대표적으로 Selenium, Puppeteer, Playwright 같은 Headless Browser를 활용할 수 있다.

 

2. 원치 않는 페이지 필터링

• 품질이 낮거나 스팸성 페이지(광고, 미끼 사이트 등)는 데이터베이스에 저장하기 전에
  스팸 필터 컴포넌트를 둬서 자동 감지·제거하도록 구현하면 데이터 품질을 높일 수 있다.
• 머신러닝이나 규칙 기반 필터 등 다양한 방법을 활용할 수 있다.
• 이 컴포넌트는 보통 콘텐츠 파서 → 데이터 저장소 단계에서 삽입한다.

 

3. 데이터베이스 다중화 및 샤딩

크롤러가 수집한 데이터의 양이 방대하다면 DB 다중화(Replication)와 샤딩(Sharding)을 활용해

• 데이터 저장소의 가용성(장애 대비)
• 규모 확장성
• 안정성

를 확보할 수 있다.
예를 들어 인기 많은 도메인별로 데이터를 분산 저장하거나, 해시 기반 샤딩으로 처리한다.

 

4. 수평적 규모 확장(Stateless & Scale-out)

웹 크롤러의 각 컴포넌트(다운로더, 파서 등)를 무상태(stateless) 서버로 설계하면

• 서버를 추가하는 것만으로도 처리량을 쉽게 늘릴 수 있다.
• 분산 큐, 분산 파일시스템, 메시지 중개인 등을 활용하면 서버 간 상태 동기화도 용이해진다.

 

5. 가용성, 일관성, 안정성(ACID vs. BASE)

• 가용성(Availability): 일부 노드에 장애가 생겨도 시스템이 중단되지 않도록 설계한다.
• 일관성(Consistency): 데이터가 여러 저장소에 분산되어 있을 때, 각 노드 간 데이터 불일치가 생기지 않도록 동기화한다.
• 안정성(Reliability): 장애 발생 시 데이터 유실을 막고, 빠른 복구가 가능하도록 한다.

 

6. 데이터 분석 솔루션(Analytics)

크롤러의 데이터를 분석하여

• 유용한 정보 추출(트렌드, 인기도, 스팸 탐지 등)
• 크롤링 정책/전략 자동화
• 데이터 정제/요약

등에 활용할 수 있다.
대표적으로 대시보드, 로그 분석, 실시간 모니터링 시스템과의 연동이 필요하다.

 

+ 스터디원과 나눴던 내용들

💬 URL의 우선순위를 나눌 때 트래픽의 양을 알아낼 수 있는 방법이 뭐가 있을까요?

유튜브 같은 경우는 조회수나, 좋아요 수..? 구글 해서 나오는 검색 결과 수?
그 외에는 잘 모르겠다..

 

💬 다른 언어들도 많은데 주로 크롤링하는데 왜 파이썬을 사용할까요?

파이썬이 크롤러 개발에 가장 널리 사용되는 이유는 풍부한 라이브러리 생태계와 간결한 문법 때문이다.
BeautifulSoup, Scrapy, Requests, Selenium 등 강력한 크롤링/파싱 라이브러리를 손쉽게 사용할 수 있고, 데이터 처리와 머신러닝까지 연동이 쉽다.

코드가 짧고 생산성이 높아서 빠른 프로토타이핑과 유지보수가 유리하며, 대규모 분산 크롤링도 Celery, asyncio 같은 프레임워크를 활용해 효율적으로 구현할 수 있다.
또한, 파이썬은 커뮤니티와 자료가 많아 에러 해결이나 샘플 코드 확보가 쉽고, 웹 자동화/테스트와도 자연스럽게 연동된다.

 

💬 요즘은 SPA 프레임워크를 사용해서 동적 페이지를 주로 구성하는 데 그럼 크롤링은 어떻게 하는지?

Selenium 같은 툴을 활용해 동적 콘텐츠를 렌더링 해서 크롤링한다.
서버에서 API 형태로 데이터를 내려주는 숨은 엔드포인트를 분석해 직접 호출하는 방식도 병행한다.

 

 

출처
https://velog.io/@kyy00n/%EB%8C%80%EA%B7%9C%EB%AA%A8-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%84%A4%EA%B3%84-%EA%B8%B0%EC%B4%88-9%EC%9E%A5.-%EC%9B%B9-%ED%81%AC%EB%A1%A4%EB%9F%AC-%EC%84%A4%EA%B3%84