# Shazam은 대체 어떻게 작동할까? > Clean Markdown view of GeekNews topic #28811. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28811](https://news.hada.io/topic?id=28811) - GeekNews Markdown: [https://news.hada.io/topic/28811.md](https://news.hada.io/topic/28811.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-04-23T15:47:30+09:00 - Updated: 2026-04-23T15:47:30+09:00 - Original source: [perthirtysix.com/how-the-heck-does-shazam-work](https://perthirtysix.com/how-the-heck-does-shazam-work) - Points: 2 - Comments: 1 ## Topic Body - 음악 인식은 마이크가 받은 공기 진동을 **파형**으로 바꾼 뒤, 이를 **스펙트로그램**과 소수의 강한 주파수 피크로 압축해 곡의 지문을 만드는 방식으로 이뤄짐 - 원시 파형은 볼륨과 재생 환경에 따라 쉽게 달라지므로 식별 기준으로 쓰기 어렵고, 짧은 구간마다 **FFT**를 적용해 시간별 주파수 구조를 드러내야 안정적인 비교가 가능해짐 - 남겨진 피크들은 단일 점이 아니라 **anchor**와 **target zone**의 쌍으로 묶여 해시가 되며, 이런 조합은 특정 녹음본을 구분할 만큼 구체적인 **지문 해시**로 작동함 - 검색은 곡을 하나씩 대조하지 않고 해시를 키로 바로 찾는 **hash-first** 구조를 쓰며, 마지막에는 일치한 해시들의 **시간 간격**까지 맞는지 확인해 신뢰도를 높임 - 서버 기반 대규모 데이터베이스와 온디바이스 방식은 규모와 제약이 다르지만, 핵심은 대부분의 정보를 버리고 **랜드마크 피크**만 남겨 짧고 시끄러운 클립에서도 빠르게 곡을 찾아내는 데 있음 --- ### 소리를 역으로 해석하는 과정 - 휴대폰 마이크는 매우 얇은 **다이어프램**으로 공기 진동을 측정하고, 이를 시간별 공기 압력을 나타내는 숫자열인 **파형**으로 바꿔 저장함 - 귀의 고막도 같은 압력파를 받지만, 휴대폰은 이를 소리 자체가 아니라 숫자 시퀀스로 다룸 - 들어온 소리는 초당 수만 번 샘플링되며, 보통 **44,100 Hz**를 사용함 - 원시 파형만으로는 곡 식별이 어렵고, 같은 곡도 더 크게 재생하면 전혀 다른 파형이 되며, 다른 곡끼리도 비슷한 파형을 만들 수 있음 - 재생 환경이 달라져도 동일한 곡의 파형이 달라질 수 있어 파형 자체는 식별 기준으로 부적합함 - 이 문제를 줄이려면 파형을 작은 조각으로 나눈 뒤 **FFT**를 적용해 각 시점에 어떤 주파수들이 들어 있는지 분해해야 함 - 질문으로 바꾸면, "이 짧은 소리 조각을 다시 만들려면 어떤 순수 톤들을 더해야 하는가"에 해당함 - 각 조각의 결과를 옆으로 쌓으면 시간축, 주파수축, 밝기축으로 이뤄진 **스펙트로그램**이 됨 - FFT는 아무리 복잡한 파형도 서로 다른 주파수, 진폭, 위상을 가진 사인파 합으로 표현할 수 있다는 점을 이용함 - 예시로 **1,024개 샘플**을 넣으면 각 주파수에 얼마나 많은 에너지가 있는지 나타내는 스펙트럼을 돌려줌 - 각 주파수 bin마다 모든 샘플을 그 주파수의 사인파와 곱해 더하고, 해당 주파수가 실제 신호에 있으면 합이 커지고 없으면 상쇄됨 - FFT의 핵심은 속도이며, 순진한 분해는 조각마다 수백만 번 연산이 필요하지만 FFT는 수학적 대칭성을 이용해 대략 **n log n** 수준으로 줄임 - 이 정도 속도라서 휴대폰에서도 초당 수백 번 실행 가능함 - 장치는 이 창을 오디오 위로 계속 이동시키며 각 조각에 FFT를 적용하고, 그 결과를 쌓아 스펙트로그램을 만듦 - 단순한 예시는 순수 주파수 하나로 이뤄진 합성음이라 이해에는 도움이 되지만 실제 음악은 훨씬 복잡함 - 실제 음악이나 허밍을 마이크로 넣으면 스펙트로그램이 훨씬 어수선하게 보이지만, FFT는 그 안에서도 실시간으로 구조를 드러냄 - 브라우저 예시에서는 모든 오디오가 브라우저 내부에서 처리되며, 녹음하거나 외부로 전송하지 않음 ### 적을수록 더 강해지는 지문 - 시스템은 스펙트로그램 전체를 저장하지 않고, 가장 큰 피크만 남겨 **희소한 점 집합**으로 압축함 - 약한 신호를 버리고 가장 강한 지점만 남기면 음향적으로 중요한 랜드마크만 남게 됨 - 이렇게 대부분을 버리는 이유는 전체 스펙트로그램을 저장하고 검색하는 일이 컴퓨터에도 지나치게 느리기 때문임 - 임계값을 높일수록 희미한 신호는 사라지고 큰 피크만 살아남는 구조임 - 이 방식은 **잡음 내성**을 높여줌 - 배경 잡음은 스펙트로그램 전반에 낮은 에너지를 더하지만, 보통 특정 영역의 최강 피크까지 만들지는 못함 - 남는 랜드마크는 잡음을 뚫고 드러난 지배적 주파수들임 - 대신 이 지문 방식은 노래를 직접 불러 넣을 때 성능이 떨어지기 쉬움 - 매우 잘 부르더라도 원곡과 다른 해시가 만들어질 가능성이 큼 - 그래서 더 새로운 **머신러닝 기반** 시스템은 정확한 주파수 대신 멜로디를 기준으로 허밍과 노래를 처리함 ### 점들을 연결해 해시 만들기 - 점 하나만으로는 구분력이 부족하지만, 두 점의 조합은 훨씬 덜 우연적이라 **지문 해시**로 쓰기 적합함 - 예시로 어떤 시점의 **1,200 Hz** 하나는 수천 곡에 등장할 수 있지만, 1,200 Hz 뒤에 0.3초 후 **2,400 Hz**가 오는 조합은 훨씬 더 구체적임 - 알고리듬은 각 피크를 차례로 **anchor**로 삼고, 그 오른쪽에 시간과 주파수 범위를 가진 **target zone**을 잡아 그 안의 모든 피크와 짝지음 - 각 쌍은 두 주파수와 시간 차이, 총 세 숫자로부터 짧은 **hash**를 만듦 - 해시는 같은 입력에서 항상 같은 결과가 나오고, 입력이 조금만 바뀌어도 완전히 다른 값이 나오는 짧은 코드로 동작함 - Shazam류 시스템은 작은 변동을 다루는 체계를 갖고 있지만, 기본적으로 해시는 정확한 주파수와 타이밍에서 만들어짐 - 그 결과 이 해시는 곡 자체보다는 **특정 녹음본**의 지문처럼 작동함 - 그래서 cover나 remix는 맞추기 더 어려워짐 - 3분짜리 곡 하나에서도 이런 지문 해시를 수천 개 만들 수 있고, 데이터베이스는 이를 모두 저장함 - 휴대폰은 5초 클립에서 얻은 소수의 해시를 들고, 데이터베이스는 방대한 수의 곡에서 뽑은 수백만 해시를 들고 매칭 단계로 넘어감 ### 정확한 매치 찾기 - 각 해시는 일종의 **주소**처럼 쓰이며, 시스템은 클립에서 얻은 해시마다 거대한 테이블을 바로 조회해 그 해시를 가진 곡을 찾음 - 곡 단위로 하나씩 훑는 대신 해시 자체를 키로 삼아 접근함 - 직관적인 **song-first** 방식은 모든 곡을 하나씩 검사하며 해시 겹침을 확인해야 해서 곡 수가 늘수록 느려짐 - 본문은 이를 **O(N)** 시간으로 표현함 - 예시 데이터베이스와 5초 클립 해시 목록으로 이런 비효율을 시각화함 - 컴퓨터는 이를 뒤집어 **hash-first** 방식으로 처리할 수 있음 - 각 해시에 대해 "어떤 곡들이 이 해시를 포함하는가"를 바로 물음 - 책 뒤의 색인처럼, 모든 페이지를 다시 읽는 대신 특정 단어 항목으로 곧장 이동하는 구조에 비유함 - 이 접근은 조회를 거의 **O(1)** 에 가깝게 만듦 - 곡이 100개든 1억 개든 대략 비슷한 시간 안에 처리됨 - 가능한 해시 수가 매우 많아, 수백만 곡이 있어도 각 주소에는 보통 소수의 항목만 들어감 - 단순히 같은 해시를 공유한다고 끝나지 않고, 마지막 검증은 **시간 간격**에서 이뤄짐 - 예시로 클립 안에서 17403C와 19A998가 1.2초 간격이면, 매칭 후보 곡도 같은 두 해시가 1.2초 간격으로 나와야 함 - 일치하는 해시들의 시간 차가 서로 맞아떨어지고 개수도 충분해야 신뢰도 높은 매치가 됨 - 시스템 전체는 컴퓨터가 특히 잘하는 작업에 맞춰 설계됨 - 숫자 비교와 주소 조회 중심으로 구성됨 - 그래서 수백만 곡을 상대로도 전체 조회가 **1초보다 훨씬 짧은 시간** 안에 끝남 ### 더 현대적인 접근 - Shazam 같은 다수의 곡 인식 서비스는 오디오 클립을 서버로 보내고, 서버에 있는 대규모 **지문 데이터베이스**에서 매칭을 수행함 - 데이터베이스가 매우 크고 계속 바뀌며, 검색에 상당한 연산 자원이 필요하기 때문에 이런 구조를 씀 - 반대로 Apple의 온디바이스 인식과 Google Pixel의 **Now Playing**은 휴대폰 안에서 전부 로컬로 실행됨 - 더 작고 선별된 데이터베이스와 최적화된 모델을 사용함 - 완전한 포괄성 대신 속도를 택하고, 잡음과 오디오 변형에 더 강한 정교한 머신러닝 접근도 포함함 - 온디바이스 방식은 더 빠르고 인터넷 연결 없이도 동작하지만, 매칭 가능한 곡 데이터베이스가 훨씬 작다는 제약이 있음 - 새 노래 반영도 일반적으로 더 느림 - 위치 변화가 감지되면 새로운 데이터를 다시 가져와야 할 수 있음 - 지역별 인기곡 차이도 온디바이스 데이터 구성에 영향을 줌 - 일본의 히트곡과 미국의 히트곡은 다를 수 있음 - 매칭이 서버에서 일어나든 기기 안에서 일어나든 핵심 기법은 같음 - 대부분의 정보를 버리고 소수의 **랜드마크 피크**만 남기면, 시끄러운 카페에서 얻은 5초 클립도 수백만 곡 중 한 곡을 짚을 만큼 정밀한 좌표 집합으로 바뀜 - 인식의 핵심은 많은 것을 듣는 일이 아니라, **무시할 것을 정확히 버리는 일**에 가까워짐 ### 기반이 된 논문 - 본문 상당수는 Avery Wang의 2003년 논문 **An Industrial-Strength Audio Search Algorithm**에 기반을 둠 - 신호 처리와 시스템 설계를 더 깊게 보고 싶다면 그 논문이 직접적인 출발점이 됨 - 전체 흐름은 파형 변환, 피크 선택, 피크 쌍 해시, 역색인 조회, 시간 정렬 검증으로 이어짐 - 이 단계들이 합쳐져 짧고 시끄러운 클립에서도 빠른 곡 식별을 가능하게 만듦 ## Comments ### Comment 56138 - Author: neo - Created: 2026-04-23T15:47:32+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47835366) - **Shazam 관련 자료**를 같이 보면 좋겠음 [https://www.ee.columbia.edu/~dpwe/papers/Wang03-shazam.pdf](https://www.ee.columbia.edu/~dpwe/papers/Wang03-shazam.pdf) 원 논문이 있고, 진짜 관심 있으면 저자의 YouTube 발표도 찾아볼 만함 [https://news.ycombinator.com/item?id=18069968](https://news.ycombinator.com/item?id=18069968) 에는 Shazam 직원 글이 있고, [https://news.ycombinator.com/item?id=38538996](https://news.ycombinator.com/item?id=38538996) 에는 공동창업자가 인정한 설명이 있으며, [https://news.ycombinator.com/item?id=41127726](https://news.ycombinator.com/item?id=41127726) 에는 Go로 만든 알고리즘 재현이 있음 결국 **ML**도 코드 자체보다 **데이터** 가치가 더 큰 경우가 많다고 봄 - 내 최근 추측은 **전혀 아닐 수도 있다**는 쪽임 대중음악에서는 대체로 잘 맞았는데, 아이스 스케이팅 대회 쉬는 시간에 나온 꽤 괜찮은 **신스 음악**들을 여러 번 Shazam 해봤더니 하나도 제대로 못 찾았음 아직 미발매 곡이었거나 극도로 니치한 음악이었을 수도 있지만, 그냥 Shazam이 크게 실패한 걸 수도 있어 보임 - 이건 당연히 **TV의 ACR**에도 쓰이는 같은 계열 기술임 그런데 Shazam이 온라인에서 평판이 훨씬 좋은 건 사용자의 **의도와 동의**를 존중하기 때문인 듯함 TV에서도 비슷한 구현을 하되 데이터가 광고 판매로만 가지 않는다면, 소비자에게 실제로 이득이 되는 형태가 가능하지 않을까 싶음 - 그 가치라는 게 결국 지금 재생 중인 **쇼나 영화 제목**을 알려주는 정도라면, 이미 일시정지 버튼 눌렀을 때 뜨는 정보와 크게 다르지 않은 것 아닌가 싶음 - 이 글은 아마 **2003년 Shazam 논문**의 원래 오디오 핑거프린팅 알고리즘을 시각적으로 설명한 자료 중 최고 수준 같음 다만 지금쯤은 어느 시점에 **ML 모델**로 갈아탔을 것 같기도 함 - **DTW(dynamic time warping)** 라는 알고리즘이 있는데 자주 간과됨 내 감으로는 Shazam에도 이게 어느 정도 쓰였을 것 같음 - 예전에 특정 소셜 미디어 사이트에서 **봇 추적**할 때 DTW를 썼음 봇들은 떼 지어 행동하는 경향이 있어서, 지연된 반복 행동을 부드럽게 맞춰 보는 데 DTW가 잘 먹힘 - **같은 녹음본 인식**은 그리 어렵지 않음 같은 녹음이라면 코드 진행과 타이밍이 정확히 반복 가능해서, 이런 식의 인식 기술은 이미 10년도 훨씬 전부터 있었음 반면 **커버 버전**처럼 다른 녹음으로 같은 곡을 알아맞히는 건 훨씬 더 어려움 Audible Magic은 [https://www.audiblemagic.com/2024/02/07/identifying-cover-songs-live-performances-ai-clones-and-more/](https://www.audiblemagic.com/2024/02/07/identifying-cover-songs-live-performances-ai-clones-and-more/) 에서 같은 곡의 여러 공연 버전이나 패러디까지 인식할 수 있다고 주장하는데, 당연히 **AI**와 더 많은 연산을 쓰는 방식임 - **어렵지 않다**는 표현이 너무 많은 걸 생략하고 있음 사회 전체 수준에서는 오래전에 해결한 단순한 기술처럼 보여도, 개별 개발자에게 답을 안 찾아보고 직접 만들라고 하면 실제로 해낼 사람은 많지 않을 거라 봄 - 적어도 **20년 이상** 된 얘기임 예전에 Gracenote 컨설팅할 때 그쪽이 어떻게 동작하는지 본 기억이 있음 - 그렇다면 그냥 **타이밍 정보 삭제**하면 되는 것 아닌가 싶음 - 또 이 주제인가 싶었는데, 보니 **SCP**였음 이 도메인은 좀 수상해 보임 CameronMacLeod의 2022년 글보다 더 완전한 분석으로는 [https://news.ycombinator.com/item?id=38531428](https://news.ycombinator.com/item?id=38531428) 이 있고, Slate의 2009년 글은 [https://news.ycombinator.com/item?id=893353](https://news.ycombinator.com/item?id=893353) 임 - 이 맥락에서 **SCP**가 뭔지 잘 모르겠음 평소 떠올리는 secure copy는 전혀 안 맞음 그래도 링크들 고마움, 제목의 질문은 예전부터 막연히 궁금했는데 제대로 파고든 적은 없어서 셋 다 읽어볼 생각임 - 그래도 이 글의 **인터랙티브 요소**들은 꽤 멋짐 - 내 프로젝트 목록에 추가해야겠음 **Dinosaur game**인데 점프를 키 입력이 아니라 **꼬끼오 소리**로 하게 만들면 재밌을 듯함 - **Shazam 같은 앱**이 탐지하지 못하게 막는 방법이 있는지 궁금함 노이즈를 섞는다든가 다른 기법이 가능한가 싶음 - 노이즈가 원본보다 특정 **지배적 주파수**에서 더 크게 나오지 않는 이상 어렵다고 봄 글에도 예시가 있는데, 이 알고리즘은 조회를 빠르게 하려고 기본적으로 **주파수 피크**만 남기고 나머지는 거의 버림 - 프로듀서나 DJ들은 이 문제를 보통 **아예 발매를 안 하거나** 한참 뒤에 내는 식으로 해결함 - 1986년에 **Apple ][c**로 이걸 과학 프로젝트로 해봤음