Shadowrocket
프로토콜 설정과 선택 기준

02 / 대칭키 암호화 프록시

Shadowsocks: 암호화 방식과 암호는 한 쌍

세션 계층을 간결하게 설계

Shadowsocks는 프록시 전달과 대칭키 암호화를 결합해 클라이언트와 서버가 약속된 방식과 키 정보로 데이터를 주고받도록 설계됐습니다. 표준 TLS 세션을 먼저 설정한 뒤 프록시 인증을 전달하는 방식과는 다릅니다. 기본 설정은 보통 주소, 포트, 암호화 방식, 암호를 중심으로 구성됩니다. 입력 항목이 적다고 해서 임의로 값을 넣어도 되는 것은 아닙니다. 각 항목이 함께 서버의 데이터 인식 여부를 결정하므로 하나라도 일치하지 않으면 연결 초기에 통신이 끊길 수 있습니다.

이러한 설계를 이해하면 사용 범위도 파악하기 쉽습니다. Shadowsocks는 주로 프록시 요청을 처리하며, 완전한 사설 네트워크를 자동으로 구성하지는 않습니다. 이름에 암호화가 들어간다고 웹사이트 인증서 확인까지 제공하는 것도 아닙니다. 웹사이트가 HTTPS를 사용하면 사이트와의 애플리케이션 계층 보안은 해당 연결에서 처리됩니다. 클라이언트와 프록시 서버 사이의 연결은 Shadowsocks의 구체적인 방식으로 보호됩니다. 계층별 보호 범위를 구분해야 프로토콜을 선택했다는 이유만으로 인증서나 대상 사이트의 경고를 무시하는 일을 피할 수 있습니다.

Method는 단독으로 조절하는 속도 설정이 아닙니다

기존 구성을 가져온 뒤에는 먼저 암호화 방식을 확인하세요. 방식마다 인증, 키 파생, 데이터 캡슐화가 다르므로 이름이 더 최신처럼 보인다는 이유만으로 클라이언트에서 임의로 바꿀 수는 없습니다. AEAD 방식은 기밀성과 무결성을 함께 처리하지만 프로토콜 세대에 따라 키 형식과 핸드셰이크 규칙이 다를 수 있습니다. 서버가 지정한 방식과 동일한 방식을 사용해야 합니다. 사용할 수 있는 항목은 현재 앱에 표시되는 유형과 기존 서버 정보를 기준으로 확인하세요.

암호 필드에 항상 임의의 짧은 텍스트를 입력할 수 있는 것은 아닙니다. 일부 방식은 정해진 형식의 인코딩 키를 요구하고, 다른 방식은 암호에서 키를 파생합니다. 끝의 등호를 지우거나 공백을 추가하거나 인코딩된 텍스트를 디코딩한 뒤 다시 붙여 넣지 마세요. 직접 입력할 때는 앞뒤 공백, 전각 문장 부호, 줄바꿈을 확인하세요. QR 코드나 공유 링크에서 가져온 경우에는 목록의 메모가 아니라 파싱된 실제 필드를 확인해야 합니다. 메모 이름은 자유롭게 바꿀 수 있으므로 인증 정보의 유효성을 판단하는 근거가 되지 않습니다.

TCP 연결 성공이 UDP 경로의 성공을 뜻하지는 않습니다

웹 요청과 실시간 앱은 서로 다른 전송 방식을 사용할 수 있습니다. 서버의 TCP 포트에 연결할 수 있어도 같은 포트에서 UDP 전달이 활성화됐다는 뜻은 아니며, 현재 네트워크에서 해당 데이터의 왕복이 허용된다는 뜻도 아닙니다. 웹페이지는 열리지만 음성 통화나 실시간 기능에 문제가 있다면 서버가 필요한 UDP 전달을 지원하는지 확인한 다음 클라이언트 설정과 네트워크 경로를 살펴보세요. 이 현상을 바로 암호 오류로 판단하지 마세요. 암호가 완전히 틀리면 기본 프록시 요청도 완료되지 않는 경우가 많습니다.

기존 설정에 추가 전송 또는 난독화 매개변수가 포함될 수도 있습니다. 이 항목들이 모든 Shadowsocks 서버에 필요한 것은 아니며 다른 설정을 보고 그대로 추가해서는 안 됩니다. 구독에서 가져온 설정은 작동하지만 직접 다시 만들면 실패하는 경우 두 설정의 방식, 암호, 주소, 포트, 추가 항목을 대조하세요. Global Routing 모드를 계속 바꾸는 것은 해결책이 아닙니다. 해당 설정을 사용하려면 서버에서 관련 기능을 활성화해야 합니다. 클라이언트 스위치만으로 서버에 기능을 추가할 수는 없습니다.

iPhone에서 성능 차이를 이해하는 방법

Shadowsocks의 실제 처리 비용은 사용 알고리즘, 기기 하드웨어, 데이터량에 따라 달라집니다. 외부 핸드셰이크 계층이 적으면 짧은 연결에 유리할 수 있지만 실제 웹페이지에는 DNS 조회, 사이트 응답, 여러 리소스 요청이 포함됩니다. 프로토콜 계층 수만으로 페이지 로딩 속도를 판단할 수는 없습니다. 장시간 전송 시 처리량은 서버 대역폭, 무선 신호, 대상 사이트의 영향을 받을 수 있습니다. 병목이 암호화 연산에 있지 않다면 다른 방식으로 바꿔도 서비스 속도가 자동으로 빨라지지는 않습니다.

배터리 사용량을 평가할 때는 연결 방식과 무선 환경도 함께 고려해야 합니다. 신호가 약하면 재전송과 무선 모듈의 지속 작동이 알고리즘 차이보다 더 큰 영향을 줄 수 있습니다. 잦은 테스트와 구독 새로고침도 활동량을 늘립니다. 비교할 때는 같은 네트워크와 비슷한 작업, 화면 상태를 유지하고 연결을 유휴 상태로 유지하는 경우와 계속 다운로드하는 경우를 구분하세요. 시스템 배터리 통계에서 앱이 차지한 비율을 프로토콜의 배터리 소모율로 바로 해석할 수는 없습니다. 통계 시간과 백그라운드 작업이 서로 다를 수 있기 때문입니다.

서버에서 해당 방식을 명시적으로 제공하고, 설정 항목이 간결하며 실제 작업에서 정상 동작한다면 Shadowsocks를 계속 사용할 수 있습니다. 문제가 생기면 먼저 설정값이 서로 일치하는지 확인한 다음 DNS와 전송 방식을 점검하세요. 공유 링크의 접두사, 인코딩, 암호 부분을 확인하기 어렵다면 공유 링크와 구독 형식 안내에서 자료 유형을 확인할 수 있습니다. 공유 링크 전체를 암호 필드에 넣거나 구독 주소를 서버 주소로 사용하지 마세요.

04 / TLS 신원 확인

Trojan: TLS 내부에서 이루어지는 암호 인증

보안 연결을 먼저 설정한 뒤 프록시 정보를 주고받습니다

Trojan은 먼저 TLS로 보호된 연결을 설정한 다음 그 안에서 인증과 프록시 요청을 전달하도록 설계됐습니다. 표준 보안 전송과 프록시 프로토콜을 결합하므로 암호가 맞는 것만으로는 충분하지 않습니다. 인증서, 이름, 외부 연결 설정도 일치해야 합니다. TLS 핸드셰이크에서 이미 실패했다면 프록시 암호를 바꿔도 대개 해결되지 않습니다. 핸드셰이크는 성공했지만 인증이 거부됐다면 인증서 이름을 반복해서 바꿔도 잘못된 암호를 바로잡을 수 없습니다.

이 설계는 대칭키로 프록시 페이로드를 직접 보호하는 방식과 다릅니다. TLS는 서버가 검증 가능한 신원을 제공하고 연결에 필요한 매개변수를 협상하도록 합니다. 클라이언트와 서버 사이의 구간을 보호하지만 대상 웹사이트 자체의 HTTPS 검증을 대신하지 않으며, 서버에서 대상 사이트까지의 모든 동작을 보장하지도 않습니다. 오류를 확인할 때는 프록시 서버 인증서 문제인지 브라우저에 표시된 대상 사이트 인증서 문제인지 먼저 구분하세요. 서로 다른 연결에서 발생한 문제입니다.

Server Name은 인증서와 일치해야 합니다

서버 주소는 지정된 진입점으로 연결을 보내고 Server Name은 일반적으로 TLS의 이름 표시와 인증서 검증에 사용됩니다. 기존 설정에서 주소로 연결하면서 TLS용 도메인을 별도로 지정했더라도 잘못된 설정은 아닐 수 있습니다. 서버가 해당 도메인 이름으로 인증서를 제공할 수 있기 때문입니다. 반대로 대상 웹사이트의 이름을 임의로 입력해도 의미가 없습니다. 판단 기준은 서버 인증서에 포함된 이름과 원본 설정에 지정된 값이지, 익숙한 도메인인지 여부가 아닙니다.

인증서 검증에는 유효 기간, 신뢰 체인, 도메인 이름, 기기 시간이 영향을 줍니다. 기기의 날짜와 시간이 크게 어긋나면 유효한 인증서도 오류로 처리될 수 있습니다. 서버에서 인증서를 교체했거나 중간 인증서 체인이 누락된 경우에도 클라이언트가 연결을 거부할 수 있습니다. 인증서 오류가 나면 자동 날짜 및 시간, 서버 설정값, 인증서 상태를 먼저 확인하세요. 안전하지 않은 연결 허용을 일반적인 해결 방법으로 사용해서는 안 됩니다. 이는 기존 설정을 복구하는 것이 아니라 신원 확인 조건을 바꾸는 것입니다.

암호와 추가 매개변수를 하나씩 확인하세요

Trojan 암호는 서버 인증 정보이지 기기 잠금 암호나 App Store 구매 정보가 아닙니다. 복사해 붙여 넣을 때 전체 내용을 유지하고 끝에 줄바꿈이 들어가지 않도록 주의하세요. 암호에 특수 문자가 있으면 공유 링크의 인코딩 및 디코딩에 따라 표시가 달라질 수 있습니다. 가져온 뒤 실제 입력 필드를 확인하고 이미 이스케이프된 텍스트를 다시 이스케이프하지 마세요. 메모에 Trojan이라고 적혀 있다는 사실만으로 링크 내용과 클라이언트의 Type이 일치한다고 볼 수는 없습니다.

기존 서버 구성에 추가 전송 옵션이 포함될 수 있으며 서버도 해당 기능을 지원해야 합니다. 관련 안내가 없다면 WebSocket을 임의로 추가하거나 Path를 바꾸거나 알 수 없는 협상 값을 입력하지 마세요. 외부 진입점에서 특정 호스트, 경로, 핸드셰이크 조건을 요구하는 경우 하나라도 빠지면 요청이 다른 서비스로 전달될 수 있습니다. 같은 도메인의 일반 웹페이지가 열려도 웹사이트 진입이 가능하다는 것만 확인된 것이며 프록시 인증 경로나 해당 포트가 올바르게 설정됐다는 뜻은 아닙니다.

핸드셰이크, 연결 재사용, 백그라운드 활동의 차이

TLS 핸드셰이크에는 암호화 연산과 네트워크 왕복이 필요하므로 새 연결을 설정할 때 비용이 듭니다. 연결이 한 번 설정된 뒤 데이터를 재사용하는 방식은 프로토콜과 구현에 따라 달라집니다. 가끔 웹페이지를 여는 사용 방식에서는 지속적인 전송량보다 연결 설정 시간이 더 두드러질 수 있습니다. 장시간 재생이나 전송에서는 전체 작업 중 핸드셰이크가 차지하는 비중이 작아집니다. Connectivity Test의 한 번 측정한 값만으로 전체 영상 재생 경험이나 하루 동안의 배터리 사용량을 판단하지 마세요.

iOS의 백그라운드 네트워크 활동은 앱 작업, 시스템 스케줄링, 현재 네트워크에도 영향을 받습니다. 연결을 자주 끊고 다시 설정하면 핸드셰이크 횟수가 늘어날 수 있고, 활성 요청을 오랫동안 많이 유지하면 무선 모듈이 더 오래 작동할 수 있습니다. 적절한 설정은 무조건 연결을 유지하거나 끊는 것이 아니라 실제 사용 방식에 맞게 연결을 관리하는 것입니다. On Demand는 연결이 시작되는 조건을 제어합니다. Trojan 암호나 인증서를 바꾸지 않으며 핸드셰이크 비용을 자동으로 없애는 기능도 아닙니다.

서버에서 유효한 인증서와 명확한 암호, 완전한 설정을 제공한다면 Trojan은 표준 TLS 신원 확인을 기준으로 관리할 수 있는 선택지입니다. 선택할 때는 TLS라는 이름을 품질 등급처럼 받아들이기보다 인증서를 확인할 수 있는지, 오류가 발생한 계층을 구분할 수 있는지를 살펴보세요. 인증서 오류와 도메인 조회 오류는 겉으로 비슷하게 보일 수 있습니다. DNS 조회 실패 문제 해결도 참고해 어느 단계에서 문제가 발생했는지 먼저 확인하세요.

06 / 네트워크 계층 터널

WireGuard: 키, 주소, 라우팅을 함께 이해하세요

암호만 바꾸는 프록시 유형이 아닙니다

WireGuard는 네트워크 계층 암호화 터널을 위한 프로토콜로, 공개 키를 사용해 신원을 확인하고 정해진 암호화 설계에 따라 피어 간 연결을 설정합니다. 요청마다 프록시 대상을 지정하는 프로토콜과 달리 터널 내부 주소, 피어, 허용 주소 범위도 설정해야 합니다. 따라서 구성에 주소 대역과 키가 포함되는 것은 불필요한 정보가 아니라 네트워크 관계를 설명하는 데 필요한 항목입니다. 서버 주소와 암호만으로는 일반적으로 WireGuard 설정을 복원하기 어렵습니다.

이 설계는 터널 구성이 명확한 네트워크에 적합하지만 양쪽에서 주소와 라우팅을 동일하게 이해해야 합니다. Shadowrocket에서 WireGuard를 경로로 사용하는 경우 앱의 규칙 선택과 WireGuard 설정의 주소 제한을 따로 확인하세요. 전자는 요청을 해당 경로로 보낼지 결정하고, 후자는 터널이 관련 트래픽을 어떻게 수신하고 전달할지에 영향을 줍니다. 두 계층에 제한이 모두 있을 때 한쪽만 확인하면 서로 모순되는 결론에 이를 수 있습니다.

Private Key와 Public Key는 서로 바꿔 쓸 수 없습니다

Private Key는 이 기기의 신원 정보이므로 안전하게 보관해야 합니다. Public Key는 피어가 해당 신원을 확인하는 데 사용됩니다. 클라이언트는 서버의 공개 키를 알아야 하고, 서버에도 해당 클라이언트의 공개 키가 설정돼 있어야 합니다. 서버 공개 키를 이 기기의 Private Key 필드에 입력하지 마세요. 문자열 모양이 비슷해도 서로 교환할 수 있는 키가 아닙니다. Preshared Key를 사용한다면 추가 공유 키도 양쪽에서 일치해야 합니다. 근거 없이 새로 만들거나 한쪽에만 입력하지 마세요.

터널 내부 주소는 서버의 공인 주소와 다릅니다. 전자는 터널 내부의 네트워크 관계에 사용되고 후자는 UDP 데이터를 실제로 받을 Endpoint를 찾는 데 사용됩니다. 주소를 입력할 때 원본 설정의 프리픽스 길이를 그대로 유지하세요. 터널 내부 주소를 Endpoint로 잘못 입력하면 클라이언트가 현재 네트워크에서 서버에 연결하지 못할 수 있습니다. 포트도 Endpoint의 일부이므로 흔한 예시를 보고 임의로 입력하지 마세요. 기존 설정에 도메인이 사용됐다면 연결 전에 해당 도메인을 조회할 수 있어야 합니다.

Allowed IPs와 연결 유지 설정의 범위

Allowed IPs는 피어와 관련된 허용 주소 범위를 지정하며 라우팅 선택과 출발지 제한에도 적용됩니다. 구체적인 동작은 구현 방식에 따라 달라집니다. 범위가 너무 좁으면 터널을 거쳐야 하는 대상이 빠질 수 있고, 너무 넓으면 기존 네트워크 설계와 충돌할 수 있습니다. ‘모두 연결되게’ 하려고 원래 값을 임의로 덮어쓰지 마세요. 사설 주소에 접속해야 한다면 로컬 네트워크에 겹치는 주소 대역이 있는지도 확인하세요. 주소 충돌은 트래픽 경로를 잘못 설정할 수 있지만 키 인증 실패와는 다른 문제입니다.

Persistent Keepalive는 필요할 때 NAT 매핑을 유지하는 기능입니다. 특히 이 기기가 특정 NAT 장비 뒤에 있고 피어에서 보내는 데이터를 수신해야 하는 상황에서 사용합니다. 주기를 짧게 설정한다고 항상 더 안정적인 것은 아닙니다. 간격이 너무 짧으면 유휴 상태에서도 데이터 활동이 늘고 모바일 네트워크에서는 무선 모듈이 절전 상태에 들어가는 것을 방해할 수 있습니다. 원본 설정에 요구가 없다면 먼저 NAT 매핑 만료로 연결 복구에 문제가 생기는지 확인한 뒤 실제 네트워크 조건에 맞게 설정하세요. 무조건 고정 주기를 추가하지 마세요.

MTU와 ‘일부 웹페이지가 멈추는’ 현상

터널에서는 캡슐화 오버헤드가 추가되므로 실제 경로에서 전달할 수 있는 패킷 크기를 고려해야 합니다. MTU가 맞지 않으면 작은 요청은 정상인데 큰 응답이나 특정 사이트에서 멈추는 현상이 나타날 수 있습니다. 이런 상황에서 바로 키를 바꾸지 말고 경로와 캡슐화 조건을 먼저 확인하세요. MTU를 조정하려면 기존 값과 반복 가능한 테스트를 기준으로 조금씩 확인하고 변경 사항을 기록해야 합니다. 다른 환경에서 가져온 숫자를 임의로 사용하면 문제를 감추거나 다른 네트워크에서 분할과 효율 저하를 일으킬 수 있습니다.

WireGuard는 UDP로 데이터를 전달하므로 네트워크에서 해당 데이터의 왕복을 허용해야 합니다. Wi-Fi와 셀룰러 네트워크를 전환하면 Endpoint와 NAT 매핑 상태가 달라지고 복구 여부도 네트워크 정책의 영향을 받습니다. UDP 연결이 차단돼 있다면 Keepalive를 추가해도 경로 차단을 해결할 수 없습니다. 먼저 Endpoint, 포트, 네트워크 조건을 확인한 다음 핸드셰이크와 실제 서비스 요청을 점검하세요. 클라이언트에 연결 상태가 표시된다고 터널 내부 라우팅까지 성공한 것은 아닙니다.

속도와 배터리 사용량 측면에서 간결한 프로토콜 설계는 계산량을 줄일 수 있지만 기기의 전체 부담에는 사용자 공간 처리, 무선 송수신, 연결 유지, 실제 트래픽이 포함됩니다. 모든 상황에서 앱 계층 프록시보다 뛰어나다는 뜻은 아닙니다. 기존 네트워크에서 완전한 키와 주소 계획을 제공한다면 그 설계에 따라 사용하세요. 일반 프록시 공유 링크 하나를 가져오기 위해 WireGuard로 억지로 바꾸지 마세요. 선택 기준은 설정 항목 수나 프로토콜의 인지도가 아니라 서버 기능과 네트워크 목적입니다.

08 / 선택과 재검토

기존 조건에 맞춰 선택한 뒤 실제 작업으로 확인하세요

먼저 서버에서 지원하지 않는 조합을 제외하세요

프로토콜을 선택할 때는 이름을 비교하기 전에 기존 서버에서 실제로 제공하는 진입점을 확인하세요. Shadowsocks 설정만 있다면 해당 암호화 방식부터 확인하면 됩니다. 완전한 WireGuard 설정이 있어야 터널 주소와 키를 검토할 수 있습니다. 구독에 여러 유형이 포함돼 있어도 각 항목이 같은 서버, 경로, 네트워크 조건을 사용하는 것은 아닙니다. 비교 결과는 배포 환경 전체의 차이를 반영할 수 있으므로 프로토콜 자체의 차이로만 설명할 수 없습니다.

다음으로 필요한 작업을 구체적으로 정하세요. 주로 웹을 탐색한다면 첫 로딩, DNS 조회, 짧은 연결의 성능을 살펴보세요. 장시간 전송에서는 안정적인 처리량과 기기 온도가 중요합니다. 실시간 앱은 UDP나 관련 데이터 전달을 지원하는지 확인해야 합니다. 기존 사설 네트워크에 접속해야 한다면 한 번 측정한 지연 시간보다 주소 계획과 라우팅이 더 중요할 수 있습니다. 모든 상황을 아우르는 순위를 찾기보다 검증할 수 있는 작업을 기준으로 선택하세요.

반복 가능한 테스트 순서를 정하세요

현재 정상 작동하는 설정을 먼저 저장하고 테스트 중 어떤 SERVER 항목이 선택돼 있는지 확인하세요. 네트워크, Global Routing 모드, 접속 대상을 고정하고 관련 없는 대용량 작업은 중지합니다. 기본 연결을 확인한 다음 실제 웹페이지나 앱을 열고 마지막으로 지속적인 데이터 전송을 테스트하세요. 각 회차에서 성공 여부, 첫 응답의 이상 여부, 일정 시간 후 연결이 끊기는지를 기록하세요. 단 한 번의 최저 지연 시간에 집착할 필요는 없습니다. 우연히 나온 최고 결과보다 반복해서 확인되는 현상이 더 유용합니다.

배터리를 테스트할 때는 유휴 상태에서 연결을 유지하는 경우와 실제로 계속 사용하는 경우를 분리하세요. 화면 밝기, 신호 상태, 작업 시간을 비슷하게 유지하고 기기 온도도 관찰하세요. 시스템 배터리 통계는 참고 자료이지 실험실 전력 측정기가 아닙니다. 통계에는 다른 백그라운드 작업이 포함될 수 있고 표시 비율은 전체 소비량에도 영향을 받습니다. 조건을 통제할 수 없다면 ‘현재 작업에서 관찰한 결과’로만 기록하고 특정 프로토콜의 고정된 특성으로 표현하지 마세요.

오류가 발생한 단계에 따라 진단하세요

전혀 연결되지 않으면 먼저 서버 주소의 DNS 조회와 포트 경로를 확인한 다음 프로토콜 유형, 인증 정보, 외부 전송을 점검하세요. 인증서 오류가 명확하면 이름, 기기 시간, 신뢰 체인을 확인하고 인증 거부가 발생하면 암호, UUID, 키 설정을 살펴보세요. 연결은 되지만 일부 대상에만 접속할 수 없다면 규칙 적용, DNS 결과, 대상 사이트 상태를 확인해야 합니다. 일정 시간 후 연결이 끊기면 네트워크 전환, NAT 매핑 만료, 지속적인 대용량 전송과 관련이 있는지 기록하세요. 매번 암호부터 다시 입력하지 마세요.

Connectivity Test는 해당 테스트의 결과만 보여 줄 뿐 모든 실제 작업을 대신하지 않습니다. 결과는 있지만 웹페이지가 열리지 않는다면 여러 도메인의 결과를 비교한 뒤 DNS 조회와 최종 정책을 확인하세요. Config에서만 실패한다면 임시로 Proxy 모드와 비교해 규칙 라우팅 문제인지 살펴볼 수 있습니다. 비교를 마친 뒤 원래 설정을 복원하고 효과가 확인된 변경 사항만 유지하세요. 단계별 절차가 필요하면 빠른 시작 안내로 돌아가세요. 여러 화면의 설정을 한꺼번에 바꾸지 마세요.

기록을 남겨 설정이 달라지는 일을 방지하세요

구독을 업데이트하면 진입점, 설정값, 메모가 바뀔 수 있습니다. 업데이트 후 문제가 생기면 먼저 기존 항목이 교체됐는지, 현재 어떤 항목을 선택했는지 확인하세요. 구독에서 생성된 항목을 직접 수정해도 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 민감한 정보를 제외한 테스트 기록에 설정 항목의 유형과 현상을 남겨 두세요. 암호, 개인 키, 인증 정보가 포함된 구독 주소 전체를 공개 문제 해결 게시물에 올리지 마세요. 화면을 공유하기 전에도 이런 정보가 보이는지 확인하세요.

용도가 분명하고 설정값을 추적할 수 있으며 실제 작업에서 검증된 구성을 유지하세요. 설명할 수 없는 시험 설정을 계속 쌓아 두지 마세요. 프로토콜은 연결 형식을, 전송 방식은 데이터 전달을, TLS는 해당 계층의 보호를 담당하고 규칙은 사용할 경로를 선택합니다. 어느 한 계층도 다른 계층을 대신할 수 없습니다. 구매와 복원 문제는 구매한 앱 복원 안내에서, 연결 문제는 자주 묻는 질문에서 확인하세요. 구성 파일의 구조는 관련 문서를 참고하면 됩니다. 이러한 역할을 구분하면 근거가 있는 설정만 조정할 수 있습니다.