GL-MT6000 공유기 사용기

이제 거의 1년 전 그때까지 사용하던 VPS 서비스 대신 온프레미스로 이전하면서 매월 AWS에 납부하는 비용은 없어졌지만 대신 한 번에 큰 돈을 들여 하드웨어를 구입해야만 했고 또 앞으로는 이전에 비해 비록 작기는 하지만 여러 인프라를 유지하는데 신경을 써야 하는 대가를 치를 거라고 예상했습니다. 이 대가는 사실 각오한 것에 비해서는 훨씬 작았는데 크게 세 가지 특징 때문입니다. 먼저 제가 선택한 서버 하드웨어는 이제 나온지 몇 년 지난 M1 맥미니이기 때문에 하드웨어에 할 수 있는 일이 사실상 아무것도 없습니다. 그냥 전원을 켜면 동작하고 시스템을 종료하면 전원이 꺼지는데 이것 외에는 하드웨어에 아무것도 할 수 있는 일이 없습니다. 이는 장기적으로 SSD 수명이 끝날 때 심각한 문제로 돌아오겠지만 예상하기에 그런 시점은 상당한 미래에 있을 겁니다. 개인 파일을 관리하기 위해 퍼포스를 사용하면서 썬더볼트 인터페이스를 통해 연결되는 대용량 하드디스크를 연결한 것 외에는 하드웨어에 아무 변경도 없습니다. 또 애초에 이 기계가 워낙 저전력으로 설계되어 24시간 내내 켜 놓아도 전기요금에 유의미한 영향을 주지 않았습니다. 아마 서버 하드웨어로 다른 기계를 선택했다면 하드웨어에 이렇게까지 아무 신경 쓰지 않거나 이렇게까지 저전력으로 동작하지 않았을 겁니다.

두 번째 이유는 이전에는 비용 때문에 낮은 사양의 VPS를 사용해야만 했고 VPS 사양이 낮아 도커를 활용할 수 없었던 것에 비해 이제는 마음 놓고 도커를 활용할 수 있게 된 것입니다. 도커를 사용하기 전에는 같은 VPS 내에 여러 서비스를 돌리는데 피곤한 일이 자주 생겼습니다. 기억에 남는 문제로는 자동화에 사용하는 n8n과 uptime-kuma는 둘 다 node.js라는 환경에 의존성이 있었습니다. 그런데 이들 둘은 각자의 버전에 따라 서로 요구하는 환경 버전이 달라질 때가 있습니다. 그래서 n8n이 동작하는 환경을 만들어 놓으면 uptime-kuma가 동작하지 않거나 그 반대의 상황이 일어나곤 했는데 이를 해결하려면 이들이 의존하는 환경을 포함해 세 가지 소프트웨어의 버전을 잘 맞춰야만 했기 때문에 별 것 아니라고 예상한 소프트웨어 버전 변경은 항상 아주 골치 아픈 문제로 변하곤 합니다. 한 서버에서 동작하는 여러 소프트웨어가 비슷한 문제를 일으키곤 했기 때문에 과연 제가 편안하게 사용하는 주요 인프라를 위해 이 VPS를 계속해서 사용할 수 있을지 고민하게 만들었습니다. 이 상황을 돌파할 적당한 방법은 각각의 서비스를 서로 다른 VPS에 격리하는 것이지만 VPS 각각의 비용은 낮은데 비해 이들을 조금만 늘리면 VPS 자신의 비용 뿐 아니라 이들을 백업하고 또 이들에 큰 스토리지를 붙여야 하는 등 부수적인 비용이 늘어나 함부로 그런 결정을 할 수는 없었습니다. 하지만 온프레미스 환경으로 전환하자 사용할 수 있는 기계 사양이 확실히 높아져 도커를 사용할 수 있게 됐고 같은 기계에서 동작하는 여서 서비스가 서로 문제를 일으키지 않게 됩니다.

마지막으로 온프레미스 환경으로 전환하고도 생각보다 관리 부담이 크게 늘지 않았던 세 번째 이유는 여러 가지 문제를 각오하더라도 서버를 무선 네트워크를 통해 유지한 것입니다. 안정적인 연결, 빠른 응답을 위해서는 당연히 라우터에 유선으로 연결해야 했습니다. 하지만 여러 가지 이유로 집에서 거의 모든 기계를 무선으로 유지하고 있었는데 여기에 24시간 동작해야 하는 서버가 추가되었다 해서 이 규칙에 예의를 두기는 쉽지 않았습니다. 만약 서버를 유선으로 라우터에 연결하려고 마음 먹는다면 복잡한 절차를 거쳐야만 했고 그냥 쿨하게 그렇게 하지 않기로 합니다. 이 서버 기계는 끝없이 외부와 패킷을 주고 받았지만 이 모든 행동을 와이파이 네트워크를 통해 수행했는데 이 기계를 통한 서비스는 거의 저 혼자 사용했기 때문에 조금 느린 응답 속도나 종종 불안정한 상태를 눈감아줄 수 있었습니다. 일단 서버를 무선 네트워크만으로 유지하기로 결정하자 맥미니에는 전원 코드와 앞서 소개한 대용량 하드디스크 외에는 아무것도 연결되어 있지 않아 그냥 그 자체로 뭔가를 유지보수할 문제를 만들지 않습니다. 하다못해 케이블 위치를 수정하거나 기계의 물리적인 배치를 수정할 일도 일어나지 않았고 그냥 조용히 불이 들어와 켜진 채 동작하고 있다는 것을 알 수 있을 뿐 그 외에는 제 생활에 아무런 영향도 주지 않습니다. 오히려 맥미니 서버에 붙여 놓은 하드디스크가 내는 소음이 한동안 신경에 거슬릴 뿐입니다. 그 외에는 전원을 제외한 어떤 케이블 문제도 일으키지 않았고 그냥 아무 일 없이 멀쩡하게 동작했습니다.

이 평화는 한동안 유지되었지만 몇 달을 넘기지 못합니다. 문제의 원인은 그 동안 수 년에 걸쳐 무선 네트워크를 유지하는데 사용해 온 링크시스 벨롭이라는 제품이 슬슬 오동작하기 시작했기 때문입니다. 애초에 이 제품을 선택한 이유는 집 전체 공간에 걸쳐 일관성 있는 무선 네트워크 환경을 유지하기 위해서였습니다. 이 제품을 선택하던 시대에는 와이파이 신호를 받아 같은 네트워크 이름으로 재송신하는 일종의 리퍼터 역할을 하는 제품 중 원활하게 동작하는 제품이 드물었습니다. 각자 그런 역할을 할 수 있다고 주장했지만 실상 온갖 문제를 일으킵니다. 그런데 링크시스 벨롭이라는 제품은 처음부터 이런 목적에 사용할 것을 상정하게 개발한 것 같았는데 애초에 똑같은 기계 석 대가 한 상자 안에 들어 있었습니다. 셋 중 아무 기계나 외부 인터넷에 무선으로 연결하고 나면 나머지 두 기계는 간단한 설정 만으로 첫 번째 기계가 받은 인터넷을 무선으로 중계해 주었습니다. 제조사의 주장에 따르면 이들은 그때그때 각 기계의 신호 세기에 따라 라우팅 경로를 변경해 인터넷이 끊기지 않고, 또 가장 빠른 상태를 유지할 수 있다고 합니다. 사실 기계 석 대 가지고 그런 시나리오가 일어날 가능성이 높아 보이지는 않았지만 종종 제 방에 있는 기계가 직접 인터넷이 연결된 기계와 연결되다가도 어떤 이유로 옆 방에 있는 다른 기계를 경유하기도 하는 모습을 보며 그들의 주장이 완전히 허구는 아닌 것 같습니다.

이들은 나름 아무 문제 없이 동작했지만 시간이 지나며 기계 자체가 낡아 문제를 일으킵니다. 특히 이 기계들은 웹사이트에서 보여주는 하얗고 예쁜 모양으로 시작했지만 세월이 흐르며 열을 받아 플라스틱이 변해 보기도 딱한 누리끼리한 색상으로 변했는데 변한 것은 껍데기의 색상 뿐만이 아니었습니다. 이들은 처음에는 몇 달에 한 번, 그 다음에는 몇 주에 한 번, 그리고 며칠에 한 번, 마지막에는 몇 십 시간에 한 번 씩 아무 말 없이 동작을 멈춰 집 안 공간에 인터넷 신호를 보내지 않은 채 그저 전기를 소모하는 기계로 바뀌었고 이 상태는 운이 좋으면 몇 분에서 몇 시간이 지나면 복구되기도 했지만 그렇지 않을 때는 사람이 직접 인터넷에 연결된 첫 번째 기계의 전원을 뽑았다가 다시 연결해 재시작해야만 했습니다. 이미 출시된지 오랜 시간이 흘러 더 이상 소프트웨어 업데이트가 없어 이런 상황이 개선될 가능성이 없어 보였고 슬슬 라우터를 교체해야 할지도 모른다는 생각을 하고 있었습니다. 비슷한 시기에 테일스케일이라는 VPN 서비스에 대해 알게 되었는데 저 혼자 사용하기 때문에 굳이 퍼블릭 인터넷을 통해 연결할 필요 없는 서비스들을 VPN을 통해 사용할 수 있으면서도 나머지 인터넷에 영향을 끼치지 않아 굉장히 편리했습니다. 이전에는 퍼블릭 인터넷에 노출되어야만 하는 서비스들은 클라우드플레어 터널을 경유했지만 퍼포스처럼 이런 형태를 지원하지 않는 서비스는 어쩔 수 없이 공인 아이피 기반에 포트를 직접 열고 사용해야만 했고 보안에 충분한 지식이 없는 입장에서 이런 사용 형태는 굉장히 마음에 안 들어 왔습니다.

테일스케일은 이런 상황으로부터 완전히 벗어나게 해 주었습니다. 클라우드플레어 터널을 사용할 때처럼 아무 포트도 열지 않고 그냥 VPN을 사용하는 것처럼 내부 네트워크 주소를 통해 퍼포스 서버를 비롯한 여러 자원에 접근할 수 있었습니다. 이들을 위해 포트를 열고 라우터로부터 서버까지 포트 포워딩을 할 필요도 없었을 뿐 아니라 DNS를 통해 제 라우터의 아이피를 광고할 필요도 없어집니다. 외부에서 스캔해보면 제 아이피는 아무 응답도 하지 않았지만 실제로는 클라우드플레어 터널을 통해 웹 서비스를 퍼블릭 인터넷에 노출하고 있었고 동시에 테일스케일을 통해 내부 네트워크 상의 자원을 여러 장소에서 사용하고 있었습니다. 하지만 이 상황 역시 뭔가 개선이 필요하다는 사실은 테일스케일을 사용하기 시작한지 몇 십 분 만에 깨달았는데 테일스케일이 나름 VPN 환경을 구축했다고 주장함에도 불구하고 전송 속도가 환장할 정도로 느렸기 때문입니다. 상황을 살펴보니 저와 똑같은 문제를 겪는 사람들이 구글에 우글대고 있었지만 다들 제가 실행할 수 있는 뾰족한 대책을 제시해 주지는 못하는 분위기였기 때문에 하는 수 없이 테일스케일 웹사이트에 있는 글 ‘How NAT traversal works’를 차근차근 읽으며 제가 어떤 상황에 처해 있는지 탐색해보기 시작합니다. 글을 읽으며 NAT 앞을 가로막고 있는 방화벽이 트래픽을 내보내고 이 결과로 돌아온 트래픽을 다시 받는 과정이 평소에는 잘 동작하며 마치 방화벽이 없는 것처럼 동작하지만 똑같은 환경일 때 외부에서 먼저 요청이 올 때 방화벽 설정 변경 없이 이를 수용하는 과정은 마치 아래 만화와 똑같은 상황이라는 사실을 깨달았습니다. 방화벽은 안에서 나간 패킷을 기억했다가 이 패킷에 의해 돌아온 결과를 다시 들여보내 주었지만 안에서 나간 기록 없이 밖에서 들어오기를 요청하는 패킷은 방화벽의 원래 기능 대로 완전히 막혔고 이를 해결할 방법이 없었습니다.

테일스케일은 이런 방화벽 뒤에 있는 네트워크에 여러 가지 똑똑한 방법을 통해 방화벽을 우회하는 여러 가지 방법을 사용해 방화벽 설정을 변경하지 않고 서로 다른 네트워크 상에 있는 자원을 VPN 모양으로 묶어 접근할 수 있게 해 주는 소프트웨어였지만 테일스케일이 해볼 수 있는 모든 방법을 동원했음에도 방화벽을 속이는데 실패하고 또 여러 단계의 NAT로 구성된 네트워크에서 패킷을 주고 받을 올바른 대상을 추적하는데 실패하면 마지막 방법으로 패킷을 외부 릴레이 서버를 통해 패킷을 주고 받게 된다는 것을 알게 됩니다. 방화벽은 안에서 나간 패킷에 근거해 돌아오는 패킷을 들여보내 주므로 테일스케일 서버에 신호를 보내 미리 약속한 두 클라이언트가 방화벽에 가로막힐 것이 분명한 상대의 패킷을 기다리는 대신 먼저 패킷을 내보내 방화벽에 구멍을 낸 다음 통신을 시도해 대부분의 문제를 해결하는 것처럼 보입니다. 하지만 위 ‘How NAT traversal works’에서 언급하는 도저히 어쩔 수 없는 시나리오에는 로컬 네트워크 내부가 2중 이상의 NAT로 구성되어 있을 때가 있었는데 테일스케일이 환장할 정도로 느리게 동작한 원인이 바로 이것이었습니다. 테일스케일은 2중 NAT 상에서 어떻게든 클라이언트들을 직접 연결 시킬 방법을 찾아봤지만 도저히 방법을 찾을 수 없는 나머지 외부의 릴레이 서버를 통해 패킷을 전송했고 제 퍼포스 서버로부터 출발한 파일은 도쿄의 릴레이 서버를 거쳐 다시 클라이언트로 돌아왔는데 이 과정이 아무리 빨리 동작해도 대략 15MB/s를 넘기지 못합니다. 속도와 제 혈압을 위해 보안을 포기해야 할지 진지하게 고민하던 찰나 네트워크의 여러 포인트에 테일스케일의 존재를 알고 있는 기계가 위치하고 있으면 이런 문제를 해결할 수 있다는 사실을 알게 됩니다.

사실 저와 비슷한 문제를 겪는 사람들이 받는 답변들은 제 관점에서는 네트워크에 대한 상당한 지식과 스킬을 요구하는 것처럼 보였습니다. 특정 기계에서 특정 포트를 열고 네트워크 구성을 이렇게 변경하고 저렇게 변경하고 또 이런 저런 명령어를 입력해 어떤 프로세스가 어떤 포트를 열고 또 이를 통해 어떤 서버들이 연결되어 있는지 확인하고 이들을 조절하는 과정을 거치면 테일스케일을 경유하면서도 클라이언트가 직접 연결되어 서로 데이터를 바르게 주고 받을 수 있다는 것 같았습니다. 하지만 저는 그런 스킬이 전혀 없어 누군가 제 상황을 정확히 해결할 수 있는 튜토리얼을 제공해준다면 모를까 제 상황을 해결할 수 있을 것 같지 않았습니다. 하지만 네[트워크의 주요 위치마다 테일스케일의 존재에 대해 알고 있고 이를 어떻게 처리해야 하는지 알고 있는 기계를 배치하는 것은 네트워크를 잘 몰라도 할 수 있는 일처럼 보였습니다. 그렇잖아도 이 즈음 ‘GL-MT3000’이라는 휴대용 라우터를 사용하고 있었는데 이 기계는 베타 소프트웨어라고 주장하기는 했지만 테일스케일을 지원했고 이 기계 뒤에 있는 기계들을 다른 설정 없이 테일스케일 네트워크에 묶어 주었습니다. 이전에 사용하던 링크시스 라우터가 슬슬 망가지고 있는 상황에서 라우터를 교체해야겠다고 마음 먹은 상황이었지만 국내에서 구입할 수 있는 제품 중에는 테일스케일을 지원한다고 주장하는 제품은 아무 것도 없었기에 하는 수 없이 같은 회사에서 나온 ‘GL-MT6000’을 선택합니다. 이미 이 제품이 테일스케일을 어떻게 지원하는지는 알고 있었기에 이번의 목표는 내부 네트워크에 있는 서버에 테일스케일을 통해 접근하더라도 빠르게 동작하는 것, 그리고 낡은 링크시스 공유기가 계속해서 오동작하는 문제를 해결하는 것의 두 가지로 설정합니다.

먼저 공유기 자체만으로 이야기하면 제가 처음으로 링크시스 벨롭을 선택하며 메시 공유기를 궁립하던 시대와 지금은 많은 것이 달라졌는데 그 중 하나는 이전에 비해 메시 네트워크의 각 노드를 거쳐야만 유지할 수 있었던 신호 강도와 속도는 이제 기계 안테나가 여러 개 달린 기계 하나만으로도 충분히 커버하고도 남는다는 것입니다. 이전에는 기계 석 대를 각기 다른 위치에 놓고 각기 전원을 연결하고 그 중 한 대에 인터넷을 연결해야 간신히 필요한 모든 공간에 일관성 있는 네트워크 성능을 부여할 수 있었지만 이제는 그럴 것 없이 그냥 적당한 위치에 유선 네트워크에 연결된 공유기 하나만 있으면 이전에 메시 네트워크를 사용해야 하던 무선 네트워크의 일관성과 속도를 얻을 수 있었습니다. 제조사의 주장에 따르면 무선 네트워크를 통해 여러 기계가 연결되더라도 이들을 잘 처리할 수 있다고 했는데 풀타임으로 그렇지는 않지만 무선 네트워크를 사용하는 기계는 20여대에 달했고 이들 중 일부는 거의 풀타임에 가깝게 연결되어 있었습니다. 이는 이전에 사용하던 링크시스 공유기 역시 무리 없이 처리해 내고 있었고 새로 바꾼 공유기 역시 별 문제 없이 처리해 냈습니다. 사실 여기까지만 보면 백 달러가 남는 기계를 구입해 얻은 결과가 기껏해야 기존 전원 플러그 세 개를 사용하던 것을 한 개만 사용하면서 비슷한 네트워크 성능을 얻은 것 뿐이어서 가성비가 그리 좋은 결정은 아니었다고 생각할 수 있습니다. 하지만 이 공유기의 핵심은 베타 태그를 달고 있기는 하지만 라우터가 테일스케일에 대해 알고 있다는 점입니다.

앞서 개인 인프라를 VPS에서 온프레미스로 옮기며 도커를 사용하기 시작했다고 했는데 2중 NAT는 여기서 생겨난 결과입니다. 만약 도커 네트워크를 고려하지 않는다면 외부에서 인터넷이 들어오면 라우터 한 대가 관장하는 NAT 한 겹을 통해 모든 기계에 접근할 수 있고 이런 시나리오는 테일스케일이 어렵지 않게 해결할 수 있는 상황이었습니다. 그런데 도커를 통해 돌아가는 컨테이너들은 여러 가지 이유로 별도의 브릿지 네트워크에 위치했고 이들은 도커가 관장하는 가상 네트워크 안에 있었으며 별도의 아이피를 부여 받습니다. 그래서 외부에서 도커 브릿지 네트워크 안에 있는 자원에 접근하려면 2중 NAT를 거쳐야 했고 이 시나리오는 앞서 테일스케일이 어떻게 해도 해결할 수 없는 상황이어서 하는 수 없이 마지막 방법으로 릴레이 서버를 통해 패킷을 전송해야 하는 상황입니다. 그리고 저는 이 상황을 해결할 네트워크에 대한 지식과 문제 해결을 위해 설정을 변경할 스킬이 없었습니다. 하지만 이 상황에서 네트워크가 변경되는 각 단계에 테일스케일에 대해 알고 있고 테일스케일의 요청을 처리할 수 있는 하드웨어와 소프트웨어를 배치할 수는 있을 것 같아 보였습니다. 이는 단지 새 라우터를 구입해 설치하거나 도커 브릿지 네트워크에 테일스케일 컨테이너를 추가하는 것 정도여서 제 수준에서 어떻게든 해볼 수 있을 것 같았습니다.

일단 새 공유기는 테일스케일에 대해 알고 있습니다. 테일스케일 메뉴에서 로그인 해 테일스케일에 기계를 등록하면 이 공유기가 관장하는 NAT에 있는 기계들은 테일스케일을 통해 직접 연결될 수 있습니다. 다음 문제는 도커가 관장하는 두 번째 NAT인데 이 문제는 도커 네트워크 안쪽을 관장하는 테일스케일 컨테이너 하나, 도커 호스트 네트워크를 관장하는 테일스케일 컨테이너 하나를 띄워 네트워크에 변화가 일어나는 각 지점마다 테일스케일에 대해 알고 있는 하드웨어와 소프트웨어를 배치하는 식으로 대응합니다. 사실 이들 중 어느 단계는 의미 없을 가능성이 있습니다. 하지만 네트워크 지식이 거의 없는 사람 입장에서 네트워크에 변화가 일어나는 각 단계에 테일스케일에 대해 알고 있는 하드웨어와 소프트웨어를 위치 시킴으로써 외부에서 접근할 때, 그리고 내부에서 접근할 때 양쪽 시나리오 모두 클라이언트가 서로 직접 연결되어 빠르게 동작하는 상태가 됩니다. 테일스케일에 대해 알고 있는 라우터는 반드시 필요한 것 같으니 이를 고민할 필요는 없었지만 도커 네트워크 내부에 있는 테일스케일 컨테이너와 도커 호스트에 있는 테일스케일 컨테이너 중 어느 하느는 필요 없을 수도 있지 않을까 싶었는데 도커 네트워크 내부에 있는 자원에 접근해 파일을 많이 전송할 때 서로 다른 네트워크에 있는 두 테일스케일 컨테이너 모두 활발하게 자원을 소모하고 있는 것으로 미루어 둘 다 필요한 상황이라고 평가하기로 하고 이 상태를 유지하기로 결정합니다.

제목을 ‘GL-MT6000 공유기 사용기’라고 했지만 결국 공유기를 교체하고 이를 사용하며 느낀 점은 드물고 내용의 거의 대부분이 테일스케일이 빠르게 동작하도록 만들기 위한 방법을 찾는 과정이 되어 버렸지만 테일스케일 지원이 없다면 굳이 비싼 돈을 내며 이 장치를 살 이유는 크지 않다고 생각합니다. 물론 국내에서 쉽게 구할 수 있는 국내 회사의 낡고 직관적이지 않은 관리 화면을 생각하면 새 공유기를 선택하는 쪽이 훨씬 낫다고 생각하기는 하지만 그 썩은 관리 화면을 견딜 수만 있다면 훨씬 비싼 돈을 낼 필요가 없습니다. 테일스케일 지원 없이 공유기 자체의 기능만으로 보면 이전에 같은 네트워크 이름과 같은 크리덴셜을 사용하던 모든 기계들이 똑같이 새 기계의 네트워크를 사용해 이전과 똑같이 동작하기 시작했고 이전에 사용하던 낡은 공유기가 가끔 저 혼자 먹통이 되어 모든 네트워크가 사용 불가능하게 되는 문제 역시 더 이상 일어나지 않게 되었지만 이건 이 공유기의 장점이라기 보다는 모든 공유기가 도달해야만 하는 최저선이라고 봅니다. 여기에 테일스케일을 공유기 수준에서 별다른 소프트웨어 트윅 없이 그냥 메뉴를 눌러 설정할 수 있는 점은 큰 장점입니다. 공유기 펌웨어를 트윅 해 서드파티 소프트웨어를 설치할 수 있다는 사실을 알고 있지만 제 기술 수준에서 그 정도 접근은 그리 편안하지 않을 것이 분명했는데 이 공유기는 그럴 필요 없이 처음부터 테일스케일이 사용하기 좋은 상태로 지원되니 그럴 필요가 아예 없었습니다.

추가로 서드파티 VPN이나 Tor 등의 다른 서비스 역시 테일스케일과 같은 수준으로 지원하고 있어 각 서비스를 사용하고 있다면 공유기 수준에서 각 서비스를 배포할 수 있는 점도 큰 장점입니다. 개인적으로 이 공유기에서 직접 지원하지는 않는 VPN 서비스를 사용하는데 이를 OpenVPN 설정으로 만들어 공유기에 올려 공유기 수준에서 VPN을 제공하도록 설정했는데 이는 집에서 사용하는 큰 공유기에 적용하기에는 썩 적절하지 않지만 트래블 라우터로 분류되는 ‘GL-MT3000’은 여기 저기 들고 다니며 사용하므로 공유기 수준에서 VPN을 지원하는 것은 큰 장점입니다. 물론 조금 더 생각해보면 테일스케일이 매우 원활하게 동작하는 시점에서 네트워크에 있는 기계 중 하나를 엑시트 노드로 설정하면 굳이 트레블 라우터에 VPN을 설정할 필요 조차 없다는데 생각이 미치고 보니 딱히 장점이 아닐 수도 있겠다는 생각이 들긴 합니다. 그냥 잘 돌아가는 무선 공유기를 구입해야 한다면 ‘GL-MT6000’은 나쁘지는 않지만 가성비가 안 나오는 선택입니다. 하지만 제 경우처럼 테일스케일이 잘 동작하게 만들되 공유기 소프트웨어를 트윅하고 싶지 않고 또 네트워크에 대한 지식이나 스킬이 없는 상황이라면 가성비가 떨어지기는 하지만 잘 동작하는 선택입니다.

참고로 이전에 사용하던 링크시스 벨롭 공유기는 이번에 완전히 정이 떨어졌습니다. 혹시나 싶어 남겨놨다가 와이파이 리피터 정도로 활용할 수 있을 거라고 예상했습니다. 그런데 이들은 인터넷 연결 없이는 공유기를 설정 조차 할 수 없었습니다. 분명 이들 각각은 로컬 네트워크를 통해 공유기 자체의 메뉴에 진입할 수 있게 만들어졌지만 어느 버전부터인가 반드시 스마트폰 앱을 통해서만 설정할 수 있도록 바뀌었고 공유기 자체의 로컬 인터페이스에 접근하려고 하면 심지어 파일 이름이 block.html인 페이지를 띄워 메뉴 접근을 막아버렸습니다. 하지만 링크시스 스마트폰 앱은 모든 것이 완벽하게 시나리오에 일치할 때만 동작할 뿐 이번의 제 시도처럼 인터넷 직접 연결 없이 리퍼터로 사용하려고 하는 식으로 시나리오에서 벗어난 행동을 시도할 때 절대 의도 대로 동작하지 않습니다. 아마도 링크시스 공유기 대부분이 이렇게 앱 사용을 강제 받을 것 같은데 그렇다면 이 회사 제품은 사용해서는 안 됩니다. 시나리오에 완벽하게 일치할 때는 동작하겠지만 그 순간이 지나면 아무 것도 할 수 없는 마치 OS 업데이트가 종료되어 켜지기는 하지만 아무 것도 할 수 없는 애플 제품과 비슷합니다. 이 기준에서 링크시스는 벽돌 제조 공장과 같고 이 회사 제품을 사용해서는 안됩니다.