[P2P 딥다이브] P2P가 강한 경우와 약한 경우

P2P를 공부하다 보면 한동안 모든 문제를 직접 연결로 풀고 싶어진다. 서버 대역폭을 줄이고, 사용자끼리 바로 주고받고, 중앙 병목도 피한다는 설명은 꽤 매력적이다. 하지만 제품에 넣을 기능을 고를 때는 그 매력부터 의심해야 했다. P2P가 강한 장면은 분명히 있지만, 약한 장면에서 억지로 쓰면 서버 비용보다 더 비싼 실패 처리와 운영 복잡도가 돌아온다.

언제 P2P를 다시 꺼내 보게 됐나

P2P가 강한지 약한지 판단할 때 데이터 수명도 자주 빠진다. 파일을 한 번 보내고 끝나는지, 서버가 나중에 다시 제공해야 하는지, 법적 보존이나 감사 요구가 있는지에 따라 답이 달라진다. 일회성 전송은 직접 경로와 잘 맞지만, 며칠 뒤 같은 링크로 다시 내려받아야 한다면 중앙 저장이나 별도 cloud 경로가 필요하다. “서버에 저장하지 않는다”는 약속은 사용자의 기대와 충돌하지 않아야 한다.

그래서 P2P의 강점과 약점은 표로 한 번 정리하고 끝낼 문제가 아니었다. 기능을 바꿀 때마다 다시 보는 렌즈에 가깝다. 데이터가 커졌는지, 사용자가 늘었는지, 보존 요구가 생겼는지, 지원해야 할 네트워크가 넓어졌는지에 따라 답이 달라진다. 처음 선택이 맞았더라도 제품이 자라면 topology와 책임 배치를 다시 봐야 한다. 서버 비용 절감만 보고 P2P를 고르는 것도 위험하다.

절감되는 대역폭은 눈에 잘 보이지만 새로 생기는 비용은 나중에 보인다. TURN relay 사용료, 연결 실패 문의, 다양한 네트워크 환경을 재현하는 QA, 브라우저별 차이, 사용자 문구와 로그 설계가 모두 비용이다. 특히 회사망과 모바일망에서 relay 비율이 올라가면 “서버를 덜 쓴다”는 계산은 쉽게 깨진다. 짧게 보태면, 선택 기준은 기능이 커질수록 더 자주 다시 확인해야 한다.

계속 본다.

처음에는 P2P면 만능인 줄 알았다

성능을 이야기할 때는 평균 사용자보다 가장 나쁜 10%를 더 자주 봐야 한다. 좋은 네트워크의 사용자에게 P2P는 빠르고 조용하다. 문제는 회사망, 기숙사망, 공용 와이파이, 해외망, 모바일 테더링 같은 환경이다. 이 사용자를 지원 대상에서 제외할 것인지, 느리지만 우회 경로를 줄 것인지, 특정 기능만 제한할 것인지 미리 정해야 한다. 모두를 완벽하게 지원할 수 없더라도 어디까지 약속하는지는 분명해야 한다.

운영팀 입장에서는 fallback이 있는 기능과 없는 기능의 차이가 크다. 직접 연결이 실패해도 사용자가 링크 전송이나 서버 경유 업로드로 계속 진행할 수 있으면 문의는 줄어든다. 반대로 직접 연결만 제공하면 네트워크가 까다로운 사용자는 아무것도 할 수 없다. P2P를 작게 시작한다는 말에는 기능 범위를 줄인다는 뜻뿐 아니라 실패해도 빠져나갈 길을 준비한다는 뜻이 들어 있다.

특히 선택 기준 글은 결론보다 조건이 중요하다. 조건을 함께 남겨야 나중에 다른 기능에 같은 이름을 붙이더라도 무리하게 확장하지 않는다. P2P가 맞는 순간과 맞지 않는 순간을 둘 다 기억하는 것이 이 노트의 목적이다. 반대로 P2P를 쓰기로 했다면 작게라도 제대로 써야 한다. 직접 경로만 열고 fallback과 로그를 빼면 절반짜리 구현이다. 사용자 문구 없이 내부 로그만 있으면 운영자는 알아도 사용자는 불안하다.

권한 확인 없이 파일 바이트만 직접 보내면 보안 경계가 흔들린다. 강점이 있는 곳에 쓰되, 그 강점을 제품 약속으로 만들 장치까지 같이 넣어야 한다. *P2P 적합성은 기술 취향보다 데이터 성격과 실패 허용 범위에서 갈린다.

오해가 만든 잘못된 구현

P2P 도입 전에는 강점보다 적용하지 말아야 할 경계를 먼저 확인하는 편이 안전하다. 다음에는 이 책임 배치에서 빠질 수 없는 signaling을 따로 봐야 한다. P2P가 강한 흐름을 골랐더라도 두 피어가 서로의 약속을 교환하지 못하면 데이터 경로는 시작되지 않는다. 직접 연결의 매력은 signaling, 권한, fallback과 함께 설계될 때만 제품에서 오래 버틴다. 제품 문구 역시 선택 기준이다.

직접 연결이 실패했을 때 “오류가 발생했습니다”만 보여 주는 기능은 아직 준비가 덜 됐다. “직접 경로가 막혀 서버 경유로 전환합니다”, “상대 기기의 업로드 속도에 맞춰 전송합니다”, “네트워크 제한 때문에 나중에 받을 수 있는 링크를 만들었습니다”처럼 사용자가 다음 행동을 알 수 있어야 한다. P2P는 내부 구조가 사용자 경험으로 번역될 때 제품 기능이 된다.

P2P가 약한 장면도 분명하다. 결제, 권한, 감사 로그처럼 중앙의 일관성이 필요한 정보는 피어에게 맡기기 어렵다. 공동 편집처럼 여러 사용자가 같은 문서를 동시에 바꾸는 기능도 단순 P2P만으로는 부족하다. CRDT, 이벤트 로그, 충돌 해결 규칙, 권한 검증이 같이 있어야 한다. 결과 검증이 어려운 계산을 피어에게 맡기는 것도 위험하다. 악의적인 피어가 거짓 결과를 내거나 일부 데이터를 숨겨도 서버가 알아차릴 수 있어야 한다.

P2P 선택 기준은 배포 뒤에도 바뀐다. 처음에는 직접 연결 성공률이 높아 보여도 사용자 지역이 넓어지거나 보안망 비중이 늘면 relay 사용량이 달라진다. 파일 크기와 세션 길이도 시간이 지나며 바뀐다. 그래서 기준표에는 현재 숫자뿐 아니라 다시 검토할 신호를 같이 적어 두는 것이 좋다. 선택 기준을 팀 안에서 공유할 때는 예시를 붙이는 편이 빠르다.

1:1 대용량 파일 전송은 P2P 후보로 둔다. 결제 승인, 권한 판정, 감사 로그는 중앙 서버에 둔다. 네 명 이하 임시 통화는 Mesh를 검토하되 인원 상한을 둔다. 대규모 회의는 처음부터 SFU를 본다. 공동 편집은 P2P 전파만 보지 말고 CRDT와 서버 동기화를 같이 본다. 이렇게 기능별로 적으면 “P2P를 쓸까 말까”라는 큰 질문이 작은 결정들로 바뀐다. P2P를 설명할 때 서버/클라이언트/사용자 중 누구 문장으로 말하는지 먼저 고르면 논쟁이 줄었다.

강한 경우와 약한 경우를 나누기

측정값도 선택 기준에 포함해야 한다. 직접 연결 성공률, relay 비율, p95 연결 시간, 전송 중단 후 복구율, 사용자 취소 지점은 꼭 본다. 파일 전송이라면 chunk 크기와 bufferedAmount, 무결성 검증 결과를 같이 남긴다. 미디어라면 packet loss, bitrate, RTT, 화면 공유 여부를 본다. 평균 성공률 하나만 보고 P2P 적용을 확대하면 가장 불편한 사용자들이 통계 뒤로 숨는다. 이 기준으로 보면 좋은 P2P 기능은 설명이 짧다.

“두 사람이 큰 파일을 잠깐 주고받는다. 권한은 서버가 확인한다. 직접 경로가 열리면 바이트는 피어 사이로 간다. 막히면 우회 경로를 쓴다.” 이 정도로 말할 수 있으면 구현과 문구가 함께 정리된다. 반대로 설명이 길어지고 예외가 계속 붙으면 중앙 서버가 맡아야 할 책임을 억지로 피어에게 넘기고 있는지 의심해 볼 필요가 있다. 내가 잡은 기준은 데이터의 무게, 일시성, 신뢰 경계, 실패 허용도다.

대용량 파일처럼 무겁고 잠깐 지나가며 중앙 보관이 필수가 아닌 데이터는 직접 경로가 잘 맞는다. 반대로 모든 참여자가 같은 상태를 즉시 봐야 하거나, 감사와 보존이 핵심이거나, 악의적인 피어가 거짓 결과를 보내도 검증하기 어려운 흐름은 중앙 서버가 더 자연스럽다. P2P는 기본값이 아니라 특정 흐름의 도구다. 이 판단은 조직의 운영 방식과도 맞물린다.

작은 팀이 모든 네트워크 조합을 계속 재현하기 어렵다면 너무 넓은 P2P 기능은 부담이 된다. 반대로 사용자가 대부분 같은 사무실이나 같은 장치군에 있고, 실패 시 다시 시도해도 되는 기능이라면 직접 경로를 더 과감히 쓸 수 있다. 기술 적합성은 순수한 아키텍처 문제가 아니라 운영할 수 있는 범위의 문제이기도 하다.

판단을 내리는 순서

또 하나 남겨 둘 것은 중간 상태를 인정하는 태도다. 어떤 기능은 Direct가 기본이고 cloud fallback이 보조일 수 있다. 어떤 기능은 서버 저장이 기본이고 로컬 네트워크에서만 직접 전송을 보조로 쓸 수 있다. 둘 중 하나만 정답이라고 몰아갈 필요가 없다. 사용자가 끝내야 하는 작업, 데이터의 민감도, 비용 구조, 장애 대응 능력을 놓고 섞어 쓰면 된다. 하이브리드는 타협이 아니라 대부분의 제품에서 더 솔직한 형태다.

작게 시작하려면 전체 제품을 P2P로 바꾸지 말고 경계가 뚜렷한 흐름 하나를 고른다. 파일 전송, 임시 미디어, 같은 계정의 로컬 장치 동기화처럼 데이터의 시작과 끝이 분명한 곳이 좋다. 권한은 중앙에서 확인하고, 데이터만 직접 경로로 흘려 보낸다. 실패하면 서버 경유나 cloud 경로로 바꿀 수 있어야 한다. 사용자가 작업을 끝내는 것이 직접 연결 자체보다 중요하다.

P2P를 쓰지 않는 결정도 기술적으로 존중해야 한다. 중앙 서버 경유가 더 단순하고, 감사하기 쉽고, 고객 지원이 쉬운 경우가 많다. 특히 초기 제품에서는 운영 가능성이 성능 최적화보다 중요할 수 있다. 나중에 병목이 실제로 확인되면 그때 특정 흐름만 직접 경로로 빼도 늦지 않다. 처음부터 모든 것을 P2P로 만들면 배워야 할 문제가 너무 많아진다.

대용량 1:1 전송은 P2P가 빛나는 대표적인 장면이다. 두 사람이 10GB 파일을 한 번 주고받는다면 서버가 파일 전체를 받아 다시 보내는 방식은 부담이 크다. 직접 경로가 열리면 서버는 방과 권한, 연결 약속만 관리하고 바이트는 피어 사이로 흐른다. 파일이 전송 후 중앙에 오래 남을 필요도 없다면 장점이 더 커진다. 다만 이때도 중단 후 재개, 수신 속도, 파일 무결성 확인은 제품 책임으로 남는다.

결국 좋은 기준은 팀이 같은 결정을 반복하게 해 준다. 파일 전송에 적용하고, 내일은 미디어에 적용하고, 다음 달에는 협업 이벤트에 적용하더라도 질문의 순서가 같으면 판단이 크게 흔들리지 않는다. P2P는 한 번 정하고 끝내는 기술 스택이 아니라 기능마다 다시 적용하는 설계 기준이다. '[P2P 딥다이브 P2P가 강한 경우와 약한 경우'을 관통하는 질문은 이 섹션에서도 같았고, 답만 더 구체적이 됐다.

P2P의 장점은 중앙 서버의 부담을 줄이고 가까운 사용자끼리 빠른 경로를 쓸 수 있다는 데 있다. 단점은 그 부담이 사라지지 않고 사용자의 기기와 네트워크, 그리고 제품의 실패 처리로 옮겨 간다는 점이다. 그래서 나는 P2P를 “서버 비용을 아끼는 기술”보다 “책임을 잘라 배치하는 방식”으로 기억하려 한다. 어디까지 직접 맡길지, 어디부터 중앙에서 붙잡을지 정하는 일이 핵심이다.

구조를 바꿔야 하는 순간도 미리 봐야 한다. 처음에는 직접 연결로 충분해 보여도 relay 비율이 높아지거나 그룹 기능이 붙으면 설계가 달라진다. 권한, 로그, 사용자 문구를 특정 topology에 묶어 두면 전환 비용이 커진다. 데이터 경로가 바뀌어도 제품 상태 이름은 유지될 수 있게 설계하는 편이 오래 간다. realtime-networ 법적 요구나 고객 약속도 빼놓으면 안 된다.

어떤 서비스는 파일을 서버에 보관하지 않는다는 점이 강한 장점이다. 다른 서비스는 반대로 전송 기록과 보존이 필수다. 같은 P2P 기술이라도 전자는 장점이 되고 후자는 위험이 된다. 그래서 기능 설명을 쓰기 전에 데이터 보존 정책과 감사 요구를 먼저 확인해야 한다. 나중에 바꾸기 어려운 약속이 여기서 생긴다. 이렇게 적어 두면 다음 구현에서 같은 질문을 다시 꺼내기 쉽다.

용어보다 책임, 성공보다 실패, 구조보다 사용자가 보는 상태를 먼저 확인하는 습관이 남는다. 내가 다시 볼 확인 목록는 네 줄이면 충분하다. 데이터가 무겁고 일시적인가. 중앙 일관성이 꼭 필요한가. 피어가 거짓 결과를 내도 검증 가능한가. 실패해도 사용자가 계속 진행할 경로가 있는가. 여기에 방 크기와 파일 크기, 네트워크 조건, 허용 가능한 지연을 붙이면 판단이 덜 흔들린다.

좋은 기술도 조건이 빠지면 나쁜 선택이 된다. 임시 미디어도 비슷하다. 통화나 화면 공유처럼 지나가면 사라지는 데이터는 중앙 저장보다 실시간 경로 품질이 중요하다. 참가자가 적고 각 피어가 감당할 업로드가 제한적이라면 직접 전송은 좋은 선택이 된다. 하지만 인원이 늘어나면 이야기가 바뀐다. Mesh에서는 각 참여자가 여러 명에게 동시에 보내야 하므로 업로드와 CPU 부담이 빠르게 커진다.

“P2P라서 가볍다”는 말은 참여자 수가 작을 때만 대체로 맞다.

P2P가 강한지 약한지는 성공 데모보다 경계 조건에서 드러난다. 작은 파일, 가까운 사용자, 안정적인 Wi-Fi에서는 장점이 먼저 보인다. 하지만 이동 중인 모바일, 회사 방화벽, 긴 세션, 큰 파일이 들어오면 다른 구조가 필요해진다. 그래서 판단표는 장점 목록이 아니라 “언제 서버 경유로 바꿀 것인가”라는 기준까지 포함해야 한다. *P2P를 잘못 고른 경우의 실패는 기술 오류보다 제품 책임의 혼동으로 나타난다.

협업 기능에서는 P2P의 매력이 특히 헷갈린다. 로컬 우선 동기화나 작은 그룹의 임시 이벤트 전파에는 잘 맞을 수 있다. 하지만 최종 권한, 충돌 해결, 기록 보존은 별개의 문제다. CRDT를 쓰더라도 서버가 전혀 필요 없어지는 것은 아니다. 동기화 지연을 흡수하고, 오프라인 사용자를 다시 붙이고, 악의적 업데이트를 거르는 정책이 필요하다. P2P는 협업의 한 부품이지 전체 답안지는 아니다.

실패 사례를 먼저 적어 보면 기준이 선명해진다. 권한 데이터를 피어에게 맡기면 사용자가 조작한 클라이언트를 믿어야 한다. 충돌 해결 없이 협업 이벤트를 직접 뿌리면 참여자마다 다른 상태를 볼 수 있다. fallback 없이 직접 연결만 제공하면 네트워크가 까다로운 사용자는 기능 자체를 못 쓴다. 결과 검증 없이 피어 계산을 믿으면 성능 최적화가 보안 문제가 된다.

모두 P2P 기술이 나빠서가 아니라 적용 경계가 흐려서 생기는 문제다.

마치며

이 글에서 확인한 경계는 다음 변경의 기준으로 남겼다.