전화 교환기와 '프리킹'이라는 단어
phreak.ing은 이름 그대로 인터넷 전화 교환기(Internet Phone Switch)를 내세운 프로젝트예요. 도메인부터 'phreaking'이라는 단어를 그대로 가져왔어요. 이 단어의 역사를 알면 프로젝트가 어떤 감성에서 나왔는지 바로 감이 오실 거예요. 개발자가 한 번쯤 알아둘 만한 이유도 같이 보이고요.
폰 프리킹(phone phreaking)은 1960~70년대 미국에서 시작된 일종의 해커 문화예요. 전화망 구조를 파고들다가, 때로는 허점을 이용해 공짜로 장거리 전화를 걸었거든요. 해커 문화의 원조로 꼽히기도 해요. 스티브 워즈니악과 스티브 잡스가 애플을 세우기 전에 '블루박스'라는 프리킹 장치를 만들어 팔았다는 일화도 유명하죠.
우리는 전화를 그냥 앱처럼 생각하지만, 그 뒤에는 교환기(switch)라는 기계가 있어요. A가 B에게 전화를 걸면 교환기가 두 회선을 이어주는 거예요. 처음엔 교환원이 손으로 케이블을 꽂았어요. 그다음엔 다이얼을 돌릴 때 나오는 펄스에 맞춰 기계식 스위치가 착착 돌아가는 교환기가 나왔고, 결국 컴퓨터가 연결을 제어하는 전전자 교환기까지 발전했죠.
2600Hz 톤 하나에 뚫린 전화망
프리킹이 가능했던 건 대역 내 시그널링(in-band signaling)이라는 설계 때문이었어요. 교환기끼리 '이 회선 비었어', '이 번호로 연결해줘' 같은 제어 신호를 주고받아야 하잖아요? 그런데 이 신호를 사람 목소리가 오가는 바로 그 음성 채널에 '소리'로 실어 보냈다는 뜻이에요.
미국 장거리망에서는 2600Hz 톤이 '회선이 비어 있다'는 신호였어요. 그래서 사용자가 수화기에 대고 이 소리를 내면 교환기가 진짜 제어 신호로 착각했어요. 시리얼 상자에 든 경품 호루라기가 정확히 2600Hz 소리를 냈다는 사실이 알려지면서 '캡틴 크런치'라는 별명의 전설적인 프리커가 생기기도 했죠. 이렇게 회선을 잡은 상태에서 MF(다중 주파수) 톤으로 번호를 보내면 원하는 곳에 마음대로 연결할 수 있었어요. 블루박스가 바로 이 톤들을 만들어내는 장치였고요.
개발자에게 이 이야기가 흥미로운 건 이게 SQL 인젝션과 똑같은 구조의 취약점이라서예요. 데이터(목소리)와 명령(제어 톤)이 같은 통로로 흐르니까, 사용자가 데이터 자리에 명령을 끼워 넣을 수 있었던 거죠. 사용자 입력을 쿼리 문자열에 그대로 이어 붙였다가 뚫리는 웹 취약점과 원리가 완전히 같아요.
전화 회사는 제어 신호를 음성 채널에서 아예 떼어내는 대역 외 시그널링(out-of-band signaling)으로 이 문제를 풀었어요. 그 흐름을 이어받은 표준이 지금도 통신사들이 쓰는 SS7(Signaling System No. 7)이에요. Prepared Statement로 쿼리와 데이터를 나누는 것과 똑같은 해법이죠.
이제는 소프트웨어가 교환기다
요즘 교환기는 상당 부분 소프트웨어로 바뀌었어요. 인터넷 전화에서는 SIP라는 프로토콜이 '누가 누구에게 거는지'를 협상하고, 실제 음성은 RTP라는 별도 스트림으로 주고받아요. 여기서도 제어와 데이터가 분리되어 있다는 게 포인트예요. Asterisk나 FreeSWITCH 같은 오픈소스 덕분에 리눅스 서버 한 대로 사내 교환기(PBX)를 꾸리는 것도 어렵지 않게 됐고요.
이 흐름 위에서 취미가들이 만든 '인터넷 위의 전화망'도 꾸준히 이어져 왔어요. ATA는 아날로그 전화기를 인터넷 전화망에 연결해 주는 작은 어댑터인데요, 오래된 다이얼식 전화기를 여기에 꽂아 서로 연결하는 C*NET이나 PhreakNet 같은 커뮤니티 네트워크가 대표적이에요. 미국 시애틀의 Connections Museum처럼 실제 기계식 교환기를 되살려 운영하는 곳도 있어요. phreak.ing도 이렇게 '전화망을 직접 만지고 탐구하는' 문화를 잇는 프로젝트로 보여요. 구체적인 접속 방법과 기능은 사이트에서 직접 확인해 보시길 추천해요.
한국 개발자에게 주는 시사점
한국에서도 교환기는 의미가 큰 이야기예요. 1986년 국내 연구진이 개발한 전전자 교환기 TDX-1이 '1가구 1전화' 시대를 열었거든요. 한국 IT 산업의 출발점으로 꼽히기도 하고요.
실무에서 가장 와닿는 건 보안이에요. SS7은 '통신사끼리는 서로 믿는다'는 전제로 설계됐어요. 그래서 망에 접근한 공격자가 위치를 조회하거나 SMS를 가로챈 사례가 꾸준히 보고돼 왔죠. 서비스를 만들 때 SMS 인증번호만으로 본인 확인을 끝내는 설계는 생각보다 약하다는 걸 알아두면 좋아요. TOTP 앱이나 패스키 같은 대안을 함께 고려해야 하는 이유예요.
콜센터나 070 인터넷전화, 각종 통신 API를 다루는 분이라면 SIP와 RTP 구조를 이해하는 것만으로 장애 분석이 훨씬 쉬워져요. 집에서 Asterisk와 중고 ATA 하나로 작은 교환기를 만들어 보는 것도 네트워크 공부 삼아 해볼 만한 재밌는 주말 프로젝트예요.
마무리
제어와 데이터를 한 통로에 섞지 마세요. 50년 전 전화망이 비싼 값을 치르고 배운 교훈인데, 지금의 웹에서도, LLM 프롬프트 인젝션 시대에도 그대로 통해요.
여러분은 실무에서 데이터와 명령이 뒤섞여 생긴 '인밴드 시그널링' 같은 문제를 겪어본 적 있으신가요? 그리고 SMS 인증, 아직 믿고 쓰시나요?
🔗 출처: Hacker News