간단한 실험을 하나 해보시죠. 좋아하는 검색 엔진을 열고 "utorrent upload download speed problem tweak"라고 입력해 보세요. 그러면 폭발적인 결과를 목격하게 될 겁니다. 이 특정 문제를 다루는 글, 가이드, 포럼 게시물이 너무나 많아서 오히려 압도당하기 때문입니다.
솔직히 말하면 저 역시 같은 문제를 겪었습니다. 형편없던 1.5Mbps 회선에서 12Mbps로 대역폭을 바꾸고, ISP를 갈아타고, 공유기를 교체하고, 운영체제를 바꾸고, 마침내 새 버전의 uTorrent을 설치하면서 과거에는 잘 작동하던 일부 설정까지 변경하고 나니, 설정한 제한보다 훨씬 낮고 들쭉날쭉한 업로드·다운로드 속도를 경험하게 되었습니다. 그래서 문제의 원인조차 정확히 모른 채 해결책을 찾기 시작했습니다.
이런 종류의 문제가 발생하면 자연스럽게 자신의 환경 설정 전반을 의심하게 됩니다. 따라서 길을 잃지 않고 신중하고 체계적으로 문제에 접근하는 것이 매우 중요합니다. 제가 어떻게 접근했고 어떤 결론에 도달했는지 소개해 드리겠습니다.
uTorrent 버전 변경 여부
네트워크 연결 스택의 가장 위에 있는 것은 프로그램 자신입니다. 2.0 버전 전후로 uTP, 대역폭 관리 등 상당한 변화가 도입되었기 때문에, 이 글을 쓰던 시점의 최신 버전인 3.1.3이 범인일 수 있다고 의심할 만합니다.
대응 방법: 구버전을 설치해서 테스트해 봤지만, 차이는 없었습니다.
잘못된 설정일까?
혹시 제 설정이 잘못된 걸까요? 사실 이건 카오스 이론에 가깝습니다. 올바른 설정값이 무엇인지 확실하게 알려주는 가이드는 세상에 단 하나도 존재하지 않는다고 생각합니다. 대부분의 사람들은 uTorrent FAQ의 설명을 그대로 암송한 뒤, 자기 멋대로 설정법을 설명할 뿐입니다. 그리고 나면 수백 개의 댓글이 달리는데, 절반은 "속도가 34KB/s에서 56KB/s로 늘었다"며 감사를 전하고, 나머지 절반은 "오히려 51.37%나 느려졌다"며 탄식합니다.
특히 많은 주목을 받는 항목들은 업로드 대역폭을 얼마나 허용할지, 전체 연결 수(집에서 흔히 쓰는 공유기가 버티기 어려워지기 전까지 안전하게 처리할 수 있는 수준을 감안), 토렌트당 연결 수, 업로드 슬롯 수 등입니다.
저는 솔직히 모든 걸 시도했습니다. 먼저 업로드 속도를 무제한에서 전체 대역폭의 33%까지 내려봤고, 연결 수는 최소 100개부터 최대 1,000개까지 바꿔봤으며, 연결 피어 값과 업로드 슬롯도 미친 듯이 조정해 봤습니다. 그러나 아무것도 변화를 만들지 못했습니다.
이후 좀 더 꼼꼼히 자료를 읽으면서 속도 제한, 암호화, 고급 옵션까지 세밀하게 다듬어 봤습니다. 여기에는 들어오고 나가는 프로토콜 유형을 결정하는 유명한 '전송 방식(transport disposition)' 설정과, Windows XP 사용자를 위한 반개방 연결(half-open connection) 제한도 포함됩니다.
그래도 여전히 아무런 차이가 없었습니다. 결국 프로그램과 모든 설정 파일을 완전히 삭제하고 처음부터 다시 시작해 봤지만, 세상은 눈 깜짝할 새에 지나갈 뿐 아무 일도 없었다는 듯했습니다.
다른 소프트웨어와 비교
이쯤 되면 네트워크 스택의 다른 무언가, 예컨대 방화벽 설정이나 공유기 구성이 문제일 수 있다고 의심하기 시작합니다. 이 단계에서는 통계적 접근에 시간을 투자해 구성 요소별로 하나씩 검증해야 합니다.
저는 Deluge를 설치하고 eMule도 실행해 보았습니다. Deluge는 uTorrent와 완전히 동일한 결과를 보였습니다. 반면 eMule은 아무 끊김 없이 순식간에 배정받은 다운로드 속도를 꽉 채웠습니다. 이는 Windows의 네트워크 스택이 정상이며 잘 작동한다는 뜻이므로, 더 이상 이 부분에 노력을 쏟을 필요가 없다는 결론을 내릴 수 있었습니다.
그렇다면 문제의 초점은 여전히 uTorrent, 공유기, 기타 구성 요소 중 어딘가에 남습니다.
Linux에서의 확인
확실히 하기 위해 같은 네트워크에 Linux 배포판을 연결하고 Transmission으로 처리량을 확인해 봤습니다. 결과는 마찬가지로 인상적이지 못했고, 이는 문제가 BitTorrent 프로토콜 쪽 어딘가에 있음을 더욱 시사하며 Windows의 혐의를 벗겨주었습니다. 하지만 정말 BitTorrent 탓일까요? 서로 다른 세 가지 프로그램이 모두 같은 증상을 보이면서도, 세상에는 저와 같은 고통을 호소하지 않는 만족스러운 사용자들이 얼마든지 있습니다.
공유기 점검
이제 한 단계 더 내려가 공유기를 살펴볼 차례입니다. 잘 작동했던 eMule과 uTorrent의 큰 차이는 uTorrent가 훨씬 많은 연결을 사용한다는 점입니다. 즉, 성능이 부족한 장비라면 단일 스레드 HTTP 연결이나 오버헤드와 연결 수가 적은 P2P 공유는 잘 처리하더라도, BitTorrent의 다운로드와 업로드에서는 목이 조일 수 있습니다. 또한 지난 1년여 동안 네트워크 구성이 여러 번 바뀌면서 제 개입 때문에 뭔가 달라졌는지 의문이 들었고, 메모리 부족 문제 가능성도 분석에 도움이 되지 않았습니다.
회선 업그레이드, ISP 교체, 공유기 변경, 각종 구성 요소나 서비스 추가 날짜를 정리한 의존성 그래프까지 그려봤지만, 명확한 결론은 나오지 않았습니다. 그래서 공유기에 집중했습니다.
이 경우 해당 장비는 Linksys WRT54GL이었지만, 실질적으로는 어떤 브랜드든 마찬가지일 겁니다. 공유기가 구형 펌웨어로 돌아가고 있었기에, 업그레이드를 하기로 전술적으로 결정했습니다. 참고로 제 사전에서 하드웨어 펌웨어 플래싱은 무마취 상태로 신장 수술을 받는 것과 맞먹는 행위입니다. 게이밍 PC의 BIOS를 플래싱한 것이 유일한 경험이었고, 다행히 그때는 유익한 작업이었습니다.
다만 강조하고 싶은 점은, 저에게는 설정 백업이 있었고 비상시나 하드웨어 고장에 대비해 새 공유기 한 대가 포장된 채 예비로 준비되어 있었다는 것입니다. 그래서 실행에 옮겼습니다. 제조사의 지침에 따라 공유기를 플래싱했고, 아무 문제 없이 성공했습니다. Tomato 펌웨어를 시도할까도 고민했지만, 방정식에 또 다른 불확실한 변수를 추가하지 않기 위해 포기했습니다.
플래싱 후 공유기는 더 빠른 반응 속도의 관리 화면과 몇 가지 추가 기능을 제공했지만, 전반적인 네트워크 성능은 변함이 없었습니다. 토렌트를 제외한 모든 용도로는 완벽히 만족스러운 수준이었습니다.
ISP 문제일 가능성
이제 슬슬 실마리에 다가섭니다. 제 특이한 필요 때문에 집에 두 개의 초고속 인터넷 회선이 있습니다. 하나는 케이블, 다른 하나는 전화선을 통해 서로 다른 ISP로 연결되어 있고, 전화선 회선은 사업자 계정으로 등록되어 있습니다. 물론 공유기도 두 대입니다.
그래서 데스크톱을 한 공유기에서 다른 공유기로 옮기는 데 총 4초를 들인 뒤 uTorrent 연결을 테스트했습니다. 이번에는 모든 것이 순조롭게 진행되었습니다. 몇 초 만에 프로그램이 배정된 전체 대역폭을 꽉 채웠고, 파일 다운로드가 끝날 때까지 그 속도를 꾸준히 유지했습니다. 업로드 역시 시딩이 시작되는 순간 바로 작동했고 문제없이 진행되었습니다. 결론: ISP가 범인으로 보입니다.
그래서 다음 날 바로 ISP를 다른 회사로 교체했습니다. 결과는 당연히 그래야 했던, 그리고 설정이 크게 바뀌기 전처럼 토렌트 풀 속도였습니다. 원인이 무엇이었는지 잊어버릴 만큼 환경이 바뀌었었지만, 다시 넉넉한 속도를 되찾았습니다. 참고용 스크린샷은 다음과 같습니다.
추가 테스트
이제 안정적인 회선을 확보했고 다른 모든 요소를 점검·재점검했으니, 다양한 uTorrent 설정이 처리량에 어떤 영향을 주는지 더 실험해 볼 시간을 투자하기로 했습니다. 리눅스 배포판을 한 번에 1개에서 6개까지 동시에 다운로드하면서, 하나부터 시작해 다운로드 중에 설정을 조정하고, 토렌트를 추가하며 과정을 반복했습니다. 동시에 인기 웹사이트 몇 곳에 대한 지연 시간(latency)을 측정하고 웹서핑도 해봤습니다. 과학적인 실험까지는 아니고, 기본적인 테스트 수준이었습니다.
제 요약 및 추천은 다음과 같습니다. 극단적으로 낮은 대역폭이거나 100Mbps급의 아주 높은 대역폭이 아닌 한, uTorrent 성능에서 눈에 띄는 차이를 느끼기 어렵습니다. 극단적인 설정들 사이에는 넓은 평탄 구간이 존재하며, 이 구간에서는 어떤 튜닝을 해도 반응이 없습니다. 전반적으로 상당한 유연성이 허용되므로, 연결 수가 301개든 331개든 걱정할 필요가 없습니다.
또한 제 Linksys 공유기는 약 650개 연결까지는 큰 문제 없이 처리하다가, 그 이상에서 지연 시간이 20~30% 범위로 유의미하게 증가한 뒤 더 떨어진다는 사실도 알게 되었습니다. uTorrent는 80개 연결만 넘어도 회선을 쉽게 최대치로 끌어올렸습니다. 업로드 상한은 다운로드에 전혀 영향을 주지 않았는데, 오버헤드가 대부분의 시간에 겨우 5~6KB/s 수준이었기 때문입니다.
결론
다소 씁쓸한 결론은 이렇습니다. uTorrent 튜닝은 Windows 튜닝과 마찬가지로, 위약 효과에 대한 만족감을 얻는 무의미한 행위라는 것입니다. 대부분의 경우 기본 설정이 훌륭하며, 98%의 사용자에게 잘 맞습니다. 또한 상당한 유연성이 있고, 프로그램은 여러분이 생각하는 것보다 설정 변경에 훨씬 둔감합니다.
이 글은 또한 당황하지 말고 문제 해결에 철저하고 체계적으로 임하라는 교훈도 줍니다. 괴짜들은 고급 설정, QoS 같은 세부 사항에 매달리며 일을 불필요하게 복잡하게 만드는 경향이 있지만, 때로는 진실이 훨씬 더 크고 단순하며, 완전히 여러분의 통제 밖에 있는 경우도 있습니다.
ISP가 BitTorrent 프로토콜을 제한(throttling)하는지 확인할 수 있는 도구를 찾아보길 권합니다. 온라인 테스트를 이용하거나, 악명 높은 사업자들이 등재된 잘 알려진 목록을 참고하면 됩니다. 그럼에도 항상 직접 테스트하고 올바른 판단을 내려야 합니다. 모든 것을 두 벌씩 갖추면 도움이 됩니다. 두 개의 프로그램, 두 개의 운영체제, 두 개의 공유기, 두 개의 회선. 그렇게 하면 문제를 쉽게 좁혀 나갈 수 있습니다.
즐겁게 읽으셨기를 바랍니다.
감사합니다.