FreePBX는 안전한가? VPS 운영자를 위한 공격면 3곳 점검

FreePBX는 안전한가: 먼저 짧은 답

FreePBX가 안전한지는 소프트웨어 자체보다 서버를 인터넷에 어떻게 열어 두었는지에 더 크게 달려 있다. 관리 화면을 공인 IP에 그대로 열어 둔 FreePBX는 2026년에만 여러 차례 원격 탈취가 가능한 취약점의 대상이 되었다. 반대로 관리 화면은 VPN 뒤에 두고, SIP는 통신사 IP에서만 받고, 모듈을 제때 올리는 FreePBX는 작은 사무실의 전화 시스템으로 충분히 쓸 만하다.

핵심 원리는 하나다. FreePBX에는 성격이 서로 다른 공격 면이 세 곳 있고, 통제 하나로 세 곳을 모두 막을 수는 없다. VPN은 관리 화면을 지켜 주지만 전화로 들어오는 공격은 막지 못한다. IP 제한은 SIP를 좁혀 주지만 이미 공개된 버그를 고쳐 주지는 않는다. 그래서 면마다 따로 통제를 둔다.

아직 PBX를 올리기 전이라면 VPS에 자체 VoIP 서버를 구축하는 방법으로 전체 구조를 먼저 잡고, 서버 기본 보안은 새 VPS를 받은 직후 10분 안에 할 일부터 끝내 두자. 아래 내용은 FreePBX 17이 이미 돌아가고 있다는 전제로 쓴다.

FreePBX의 공격 면은 어디에 있나

• 웹 관리 화면: 관리자용 GUI(Administrator Control Panel), 직원용 포털인 UCP(User Control Panel), 그리고 API다. 사람이 아이디와 비밀번호로 로그인하는 곳이다.
• SIP 시그널링: SIP(Session Initiation Protocol)는 통화를 시작하고 끝내는 신호를 주고받는 프로토콜이다. 여기에는 로그인 화면이 없다. 전화를 걸 수 있는 사람이면 누구나 서버에 데이터를 보낼 수 있다. 발신자 이름(Caller ID name)도 그 데이터의 일부다.
• 모듈: FreePBX는 수십 개의 모듈로 이루어진다. 보안 권고는 대부분 특정 모듈의 특정 버전을 지목한다. 그래서 패치도 모듈 단위로 나온다.

2026년 10월 기준 실제 사례로 보는 위험

아래 CVE는 최신 목록이 아니다. 각 공격 면이 실제로 어떻게 뚫리는지 보여 주는, 날짜가 붙은 예시다. FreePBX 보안 권고는 GitHub의 FreePBX/security-reporting 권고 목록에 계속 올라온다. 버전 번호는 이 GHSA(GitHub Security Advisory) 페이지에서 가져왔다. 취약점 정보를 모아 보여 주는 외부 사이트 중에는 GHSA와 다른 수정 버전이나 날짜를 표시하는 곳이 있다. 숫자가 다르면 FreePBX 프로젝트가 직접 올린 GHSA를 기준으로 삼자.

UCP 원격 코드 실행: CVE-2026-73665

GHSA-37j8-fhxx-9vhp는 2026년 7월 16일 게시된 치명적(critical) 등급 권고로, CVSS 4.0 기본 점수는 9.3이다. FreePBX 17의 ucp 모듈에서 socket.io 네임스페이스의 인증을 우회하고 AMI 명령을 주입할 수 있다. AMI(Asterisk Manager Interface)는 외부 프로그램이 Asterisk를 제어하는 인터페이스다. 영향을 받는 버전은 17.0.9 미만이고, 17.0.9에서 고쳐졌다.

권고가 밝힌 영향은 이렇다. 인터넷에 노출된 UCP가 있는 FreePBX 17에서, 인증 없이, 원격으로, 사용자 조작 없이 asterisk 사용자 권한으로 코드가 실행된다. 권고는 UCP Node 서버가 보통 8001번(TLS 없음)과 8003번(TLS) 포트에서 대기한다고 적는다.

missedcall SQL 인젝션: CVE-2026-73663

GHSA-g27h-xf3q-h3rm도 2026년 7월 16일 게시된 치명적 등급 권고이며 CVSS 4.0 점수는 9.3이다. 권고 제목은 "인바운드 Caller ID 이름을 통한 FreePBX missedcall의 인증 없는 SQL 인젝션이 관리자 탈취로 이어진다"는 뜻이다. 수정 버전은 FreePBX 17용 missedcall 17.0.6, FreePBX 16용 16.0.11이다.

이 버그가 중요한 이유는 입구가 웹이 아니기 때문이다. 공격 데이터는 전화 한 통의 발신자 이름 안에 실려 들어온다. 그러니 관리 화면을 VPN 뒤로 숨겨도 이 경로는 그대로 남는다.

관리 GUI 명령 주입: CVE-2025-64328

GHSA-vm9p-46mv-5xvw는 2025년 11월 5일 게시된 높음(High) 등급 권고로, CVSS 4.0 점수는 8.6이다. 관리 GUI에 로그인한 사용자가 운영체제 명령을 주입할 수 있다. GHSA는 패키지를 FreePBX 17의 filestore로 적고, 영향 범위를 17.0.2.36 이상 17.0.3 미만, 수정 버전을 17.0.3으로 밝힌다. 언론 보도 중에는 이 버그를 Endpoint Manager 문제로 소개한 곳도 있으니, 버전을 확인할 때는 GHSA의 filestore를 기준으로 하자.

미국 CISA(사이버보안·인프라보안청)는 2026년 2월 3일 이 CVE를 KEV(Known Exploited Vulnerabilities) 카탈로그에 올렸다. KEV는 실제 공격에 쓰인 것이 확인된 취약점 목록이다. 로그인이 필요한 버그라도 실전에서 악용되었다는 뜻이다.

피해 규모는 2차 보도로만 확인된다. The Hacker News는 2026년 2월 27일 기사에서 Shadowserver 재단을 인용해, 2025년 12월부터 이어진 명령 주입 공격으로 900개가 넘는 Sangoma FreePBX 인스턴스가 여전히 웹셸에 감염된 상태라고 보도했다. 웹셸은 공격자가 웹 서버에 심어 두고 원격으로 명령을 내리는 스크립트다. 이 숫자는 특정 시점에 관측된 IP 수이며, 검증된 피해 목록은 아니다.

그 뒤에도 권고는 계속 나온다

GHSA 목록에는 2026년 8월 21일 게시된, Sangoma Connect RT API 로그인의 SQL 인젝션을 통한 인증 없는 원격 코드 실행 권고가 있다. 9월 17일과 29일에도 권고가 이어졌는데, 그중에는 인바운드 CallerID가 CEL Reports에서 저장형 XSS(cross-site scripting)가 되는 버그와, 낮은 권한의 UCP 사용자가 일으키는 SQL 인젝션이 있다. CEL Reports 버그 역시 발신자 정보를 통해 들어온다. SIP 면을 따로 다뤄야 하는 이유가 하나 더 생긴 셈이다.

UCP 8003번 포트는 열어도 안전한가

Sangoma의 지식베이스(KB) 문서 Ports used on your PBX는 8003번(UCP용 HTTPS Node 서버)을 신뢰할 수 없는 네트워크에 열어도 안전하다고 적는다. 근거는 트래픽이 SSL로 암호화되고, 사용자 이름과 비밀번호 인증을 거친다는 것이다. 같은 문서는 8001번(HTTP)은 암호화되지 않으므로 여는 것을 권장하지 않는다. 관리 GUI용 80번과 443번, SIP용 5060, 5061, 5160, 5161번도 권장하지 않는다.

2026년 UCP 권고는 이 판단과 정면으로 충돌한다. 암호화는 오가는 내용을 제3자가 엿보지 못하게 할 뿐이다. 서버가 상대를 제대로 인증하는지와는 관계가 없다. CVE-2026-73665는 바로 그 인증 단계를 우회한다. 그래서 8003번이 TLS로 보호되어도 공격자는 암호화된 연결 위에서 인증 없이 명령을 보낼 수 있다. 이 KB 페이지의 최종 수정일은 2025년 11월 24일로, 2026년 7월 권고보다 앞선다. 결론은 KB가 아니라 권고를 따른다. 8001번과 8003번 모두 공인 인터넷에서 닫는다.

KB는 이 포트 번호가 신규 설치의 기본값이라고 밝힌다. 오래 업그레이드해 온 서버는 다른 번호를 쓸 수도 있다. 그러니 문서를 믿기 전에 내 서버가 실제로 어떤 포트에서 대기하는지 확인하자.

sudo ss -tulpn | grep -E ':(80|443|8001|8003|5060|5061|5160|5161)\b'

출력의 각 줄은 대기 중인 포트와 그 포트를 연 프로세스를 보여 준다. 주소가 0.0.0.0이나 [::]로 나오면 모든 네트워크 인터페이스에서 받는다는 뜻이다. 다음으로 Tailscale에 연결되지 않은 외부 컴퓨터에서 서버의 공인 IP로 접속을 시도한다.

nc -vz 203.0.113.10 8003
nc -vz 203.0.113.10 443

203.0.113.10 자리에 서버의 공인 IP를 넣는다. 방화벽을 정리한 뒤라면 두 줄 모두 연결 실패나 시간 초과로 끝나야 한다. succeeded, Connected, open 같은 단어가 보이면 그 포트는 아직 인터넷에 열려 있다. 외부에서 포트를 확인하는 다른 방법은 리눅스에서 포트가 열려 있는지 확인하는 방법에 정리되어 있다.

관리 화면을 Tailscale 뒤로 옮기는 방법

관리 GUI, UCP, API를 인터넷에서 내리고 VPN으로만 접속하게 하는 것이 첫 번째 면의 통제다. VPN을 쓰라는 것은 이 글의 제안이며, UCP 권고 자체는 신뢰할 수 없는 네트워크에서 UCP 포트로의 접근을 막으라고 쓴다. missedcall 권고는 관리 화면 접근을 User Management, VPN, MFA(다중 인증), SAML 같은 수단으로 제한하라고 권한다. WireGuard를 직접 운영해도 되지만, 서버 한 대와 직원 몇 명 규모라면 Tailscale이 설정할 것이 적다. Tailscale 공식 문서의 리눅스 설치 명령은 다음과 같다.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale ip -4

sudo tailscale up을 처음 실행하면 로그인용 URL이 출력된다. 그 URL을 브라우저에서 열어 승인하면 서버가 tailnet(Tailscale 사설망)에 들어온다. tailscale ip -4는 서버가 tailnet 안에서 받은 IPv4 주소를 보여 준다. 이제 관리자 PC에도 Tailscale을 설치하고, 브라우저에서 그 주소로 FreePBX 관리 화면이 열리는지 확인한다. 이 접속이 되는 것을 본 다음에만 공인 포트를 닫는다. 순서를 바꾸면 관리 화면에 들어갈 길이 사라진다.

공인 포트를 닫는 곳은 두 군데다. 하나는 VPS 업체 관리 패널의 네트워크 방화벽이다. 다른 하나는 FreePBX 자체의 Firewall 모듈이며, 두 권고 모두 이 모듈로 적대적인 네트워크를 차단하라고 권한다. UCP 권고는 특히 Firewall 설정의 Trusted 영역과 Local 영역에 들어 있는 IP 목록을 검토하라고 강조한다. 예전에 편의상 넣어 둔 넓은 대역이 남아 있으면 그 대역 전체가 관리 화면에 접근할 수 있기 때문이다. Firewall 모듈이 영역별로 기본 허용하는 항목은 Connectivity 메뉴의 Firewall 화면에서 직접 확인하자.

Tailscale이 어떤 포트를 쓰고 기존 방화벽 규칙과 어떻게 함께 동작하는지는 Tailscale 포트와 방화벽 규칙 정리를 참고하자. tailnet 안에서도 누구나 관리 화면에 들어올 필요는 없다. Tailscale 문서에 따르면 접근 규칙(ACL)은 명시적으로 허용하지 않은 접근을 기본으로 거부하고, 규칙에 쓰는 태그는 tagOwners에 먼저 정의해야 한다. 다만 같은 문서는 tailnet을 처음 만들 때의 기본 정책 파일이 tailnet 안의 모든 기기 간 통신을 허용한다고 밝힌다. 지금 내 tailnet에 어떤 정책이 적용되어 있는지는 관리 콘솔의 Access controls 화면에서 직접 확인하고, 관리자 기기만 443번과 UCP 포트에 닿도록 좁히자. Tailscale에 무엇을 맡기게 되는지는 Tailscale은 안전한가에서 따로 다룬다.

외근 직원의 스마트폰 소프트폰도 같은 원리를 따른다. 휴대전화에 Tailscale을 설치하고, 소프트폰이 서버의 tailnet 주소로 등록하게 하면 SIP 포트를 직원용으로 인터넷에 열 필요가 없다. 그러면 공인 인터넷에 남는 SIP는 통신사 트렁크 하나뿐이다.

SIP는 왜 통신사 IP에서만 받아야 하나

missedcall 사례가 보여 주듯, SIP로 들어오는 데이터는 VPN을 거치지 않는다. 통화는 원래 외부에서 들어와야 하는 것이기 때문이다. 그래서 두 번째 면에는 다른 통제가 필요하다. missedcall 권고가 직접 제시하는 완화책 가운데 SIP와 관련된 것은 다음과 같다.

• 알려진 신뢰할 수 있는 SIP 트렁크와 단말에서만 인바운드 통화를 받는다.
• 인바운드 콜 흐름의 가능한 한 이른 단계에서 Caller ID Name을 덮어쓴다.
• FreePBX 앞에 SBC를 두어 트래픽을 거르고 From 헤더를 정리한다.
• 모듈을 수정 버전으로 업데이트한다.

첫 번째 항목부터 적용하자. 통신사(트렁크 사업자)에 시그널링과 음성(RTP) 트래픽이 출발하는 IP 목록을 요청한다. 그리고 VPS 업체 방화벽과 FreePBX Firewall 모듈 양쪽에서 SIP 포트와 RTP 포트를 그 IP에만 연다. 앞의 Sangoma KB도 5060, 5061, 5160, 5161번을 신뢰할 수 없는 네트워크에 여는 것을 권장하지 않는다. RTP 포트 범위는 설치마다 다를 수 있으니 내 서버의 SIP 설정에서 확인한다. 이 규칙이 막는 것은 아무 IP에서나 서버로 직접 보내는 SIP 요청이다. 공격자는 From 헤더와 발신자 이름을 마음대로 쓴 SIP INVITE를 서버에 바로 보낼 수 있는데, 출발지가 통신사 IP가 아니면 방화벽에서 버려진다.

이 규칙의 한계도 분명히 알아 두자. 공격자가 일반 전화망을 통해 정상적으로 전화를 걸면, 그 통화는 통신사 IP에서 들어온다. 이때 발신자 이름이 얼마나 걸러지는지는 통신사의 처리 방식에 달려 있고, 내 방화벽이 판단할 수 있는 일이 아니다. 권고가 IP 제한과 함께 이름 덮어쓰기와 SBC를 권하는 이유가 이것이다.

Caller ID Name 덮어쓰기는 들어온 이름을 믿지 않고 고정값이나 발신 번호로 바꾸는 것이다. Asterisk 다이얼플랜에서는 CALLERID(name) 함수로 이름을 바꾼다. 이 작업은 인바운드 통화가 다른 모듈에 닿기 전에 해야 의미가 있다. 발신자 이름 표시가 업무에 꼭 필요하지 않다면 가장 손쉬운 방어다. SBC(Session Border Controller)는 PBX 앞에 서서 SIP 메시지를 검사하고 정리하는 전용 장비나 소프트웨어다. 트렁크가 여러 개이거나 지점이 여러 곳이라면 검토할 만하다.

missedcall 모듈을 쓰지 않는다면 패치한 뒤 꺼 두는 것도 공격 면을 줄이는 방법이다. 쓰지 않는 모듈은 업데이트를 놓치기 쉽고, 놓친 모듈이 다음 권고의 대상이 된다.

sudo fwconsole ma disable missedcall

fwconsole로 모듈 버전을 확인하고 업데이트하는 방법

세 번째 면은 습관이다. 새 권고가 나오면 내 서버의 해당 모듈 버전을 확인하고, 수정 버전 이상으로 올린다. FreePBX 17은 이 작업을 fwconsole moduleadmin 명령으로 하며, 줄여서 fwconsole ma라고 쓴다. 아래 하위 명령은 FreePBX 17.0 framework 소스 코드와 Sangoma의 fwconsole 문서를 기준으로 골랐다. 이 글을 쓰면서 이 명령들을 실제 FreePBX 17 서버에서 실행해 보지는 않았다. 그래서 예상 출력은 싣지 않는다. 먼저 내 서버의 도움말로 하위 명령과 옵션을 확인하자.

sudo fwconsole ma --help
sudo fwconsole ma list
sudo fwconsole ma showupgrades

fwconsole ma list는 설치된 모듈을 Module, Version, Status, License 열이 있는 표로 보여 준다. fwconsole ma showupgrades는 업데이트할 수 있는 모듈마다 로컬 버전(Local Version)과 온라인 버전(Online Version)을 나란히 보여 준다. 주의할 점이 하나 있다. 소스 코드상 list의 Version 열은 모듈의 dbversion 값에서 오고, 그 값이 없으면 빈칸으로 나온다. showupgrades는 다른 버전 필드를 쓴다. 두 명령의 숫자가 다를 수 있으니 둘 다 보고, GHSA의 수정 버전과 비교하자.

관심 있는 모듈만 골라 보려면 다음처럼 거른다.

sudo fwconsole ma list | grep -Ei 'ucp|missedcall|filestore'

2026년 10월 기준으로 앞의 세 권고와 비교할 기준은 이렇다. ucp는 17.0.9 이상, missedcall은 FreePBX 17에서 17.0.6 이상(FreePBX 16이면 16.0.11 이상), filestore는 17.0.3 이상이어야 한다. 기준보다 낮으면 업데이트한다. 업데이트 전에 VPS 스냅숏을 먼저 떠 두면, 모듈 업그레이드가 다른 모듈과 충돌할 때 되돌릴 수 있다.

sudo fwconsole ma upgrade ucp
sudo fwconsole ma upgrade missedcall
sudo fwconsole ma upgrade filestore

모든 모듈을 한 번에 올리려면 sudo fwconsole ma upgradeall을 쓴다. 업데이트가 끝나면 sudo fwconsole ma showupgrades와 sudo fwconsole ma list를 다시 실행해 버전이 기준 이상인지 확인한다. 서명이 유효하지 않은 모듈이 있다는 경고가 보이면, 소스 코드 설명상 sudo fwconsole ma refreshsignatures가 그런 모듈을 다시 내려받는 명령이다. 모듈 파일이 바뀌었다는 뜻일 수도 있으니, 아래 침해 점검도 함께 하자.

FreePBX 모듈 버전과 별개로 Debian 패키지 자체의 취약점도 따로 본다. 그 방법은 서버의 알려진 CVE를 점검하는 방법에 있다. 참고로 FreePBX 17의 공식 설치 경로는 Debian 12 서버나 VM에서 Sangoma가 제공하는 GPL 설치 스크립트를 돌리는 방식이고, 설치 문서는 Debian 12 ISO 경로도 함께 설명한다.

이미 뚫렸는지 확인하는 방법

패치는 앞으로의 공격을 막을 뿐, 이미 들어온 공격자를 내보내지는 않는다. 위의 권고가 나오기 전부터 관리 화면이나 UCP가 인터넷에 열려 있었다면 다음 항목을 직접 점검하자. 아래는 리눅스 웹 서버에 일반적으로 적용하는 점검이며, FreePBX 고유의 동작을 설명하는 것은 아니다.

1. 계정: 관리자 계정 목록과 User Management(userman) 모듈의 사용자 목록을 연다. 만든 기억이 없는 관리자, 최근에 생긴 사용자, 권한이 바뀐 사용자가 있는지 본다.
2. 웹 루트의 PHP 파일: 웹셸은 보통 웹 루트 안의 PHP 파일로 숨는다. 웹 루트 경로는 설치마다 다를 수 있으니 먼저 확인한 뒤, 최근 30일 안에 바뀐 PHP 파일을 찾는다.
3. 예약 작업: 공격자는 재부팅 후에도 살아남으려고 cron 항목이나 systemd 타이머를 추가한다. asterisk 사용자와 root의 crontab, 시스템 cron 디렉터리, 타이머 목록을 확인한다.
4. 통화 기록(CDR): CDR(Call Detail Record)에서 업무 시간 밖의 발신, 처음 보는 내선의 발신, 국제 발신 접두번호로 시작하는 통화를 찾는다.

WEBROOT=/path/to/your/webroot
sudo find "$WEBROOT" -name '*.php' -mtime -30 -ls
sudo crontab -l -u asterisk
sudo crontab -l -u root
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily
systemctl list-timers --all

find 결과에 FreePBX 업데이트 날짜와 맞지 않는 파일, 이름이 무작위 문자열인 파일이 있으면 의심하자. crontab에 curl, wget, base64처럼 외부에서 무언가를 받아 실행하는 줄이 있으면 더 그렇다. no crontab for asterisk라는 메시지는 해당 사용자에게 crontab이 없다는 뜻이며, 그 자체로 문제는 아니다.

CDR 점검이 특히 중요한 이유는 돈이다. PBX를 장악한 공격자가 가장 흔히 노리는 수익은 요금 사기(toll fraud)다. 내 트렁크로 고액 국제전화나 유료 번호에 대량 발신을 하는 것이다. 그 요금은 공격자가 아니라 계약자인 내게 원화로 청구된다. 청구서가 나오기 전에 알아차리는 방법은 CDR을 보는 것뿐이다. 통신사에 국제전화 차단이나 발신 한도 설정이 가능한지도 문의해 두자.

하나라도 걸리면 그 서버는 침해된 것으로 보고 대응한다. 웹셸 하나를 지워도 공격자가 다른 곳에 심어 둔 백도어는 남을 수 있다. 증거 보존부터 재구축까지의 순서는 VPS가 해킹당했을 때 해야 할 일을 따르자. 새 서버에서는 처음부터 관리 화면을 Tailscale 뒤에 두고, SIP는 통신사 IP에만 연다.

FAQ

FreePBX 17은 어떤 운영체제에 설치하나요?

Sangoma 설치 문서가 안내하는 공식 경로는 Debian 12 서버나 VM에서 Sangoma의 GPL 설치 스크립트를 실행하는 방식이다. 같은 문서는 Debian 12 ISO로 설치하는 방법도 설명한다. VPS를 고를 때는 Debian 12 이미지를 제공하는지 먼저 확인하자.

UCP 8003번 포트는 TLS로 암호화되니 인터넷에 열어도 되지 않나요?

아니다. Sangoma KB는 암호화와 비밀번호 인증을 근거로 8003번을 열어도 안전하다고 적었지만, 2026년 7월 16일 게시된 CVE-2026-73665는 바로 그 인증 단계를 우회해 인증 없는 원격 코드 실행을 일으킨다. 암호화는 내용을 엿보지 못하게 할 뿐 인증 우회를 막지 못한다. ucp를 17.0.9 이상으로 올리고, 8001번과 8003번은 VPN으로만 접속하게 하자.

관리 화면을 VPN 뒤에 두면 missedcall 취약점도 막히나요?

막히지 않는다. CVE-2026-73663의 공격 데이터는 인바운드 통화의 Caller ID 이름 안에 실려 SIP로 들어오므로 VPN을 거치지 않는다. missedcall을 17.0.6 이상(FreePBX 16은 16.0.11 이상)으로 올리고, SIP는 통신사 IP에서만 받자. 여기에 더해 인바운드 콜 흐름 초기에 Caller ID 이름을 덮어쓰거나 SBC를 앞에 두면 통신사를 거쳐 들어오는 통화까지 대비할 수 있다.

FreePBX 모듈이 패치된 버전인지 어떻게 확인하나요?

서버에서 sudo fwconsole ma list로 설치된 모듈과 버전을 보고, sudo fwconsole ma showupgrades로 로컬 버전과 온라인 버전을 비교한다. list의 Version 열은 dbversion 값이라 비어 있거나 다를 수 있으니 두 명령을 함께 보자. 그 숫자를 해당 GHSA 권고의 수정 버전과 비교하고, 낮으면 sudo fwconsole ma upgrade 뒤에 모듈 이름을 붙여 올린다.

FreePBX가 해킹되면 어떤 피해가 가장 큰가요?

직접적인 금전 피해는 요금 사기다. 공격자가 내 트렁크로 국제전화나 유료 번호에 대량으로 발신하면, 그 요금은 계약자에게 원화로 청구된다. CDR에서 업무 시간 밖의 국제 발신을 정기적으로 확인하고, 통신사에 국제전화 차단이나 발신 한도를 설정할 수 있는지 문의해 두자.