Session

여기서 말하는 Session은 웹/네트워크에서 흔히 말하는 일반적인 세션(session) 개념이 아니라, 전화번호나 이메일 없이 계정을 만들 수 있는 프라이버시 메신저를 뜻한다. 메시지 내용은 종단간 암호화로 보호하고, 메시지 전송 경로는 기본적으로 어니언 라우팅(onion routing)으로 감춰서 "누가 누구와 언제 대화했는가" 같은 메타데이터 노출도 줄이려는 것이 핵심이다. 공식 소개 문구도 Send Messages, Not Metadata이다.

블록체인/IT 맥락에서 Session이 자주 언급되는 이유는, 이것이 단순히 "암호화된 채팅 앱"이 아니라 분산 노드 네트워크와 토큰 인센티브 위에서 돌아가는 메신저이기 때문이다. 즉, 겉으로는 메신저 앱이지만, 그 뒤의 운영 구조는 탈중앙화 네트워크와 꽤 강하게 연결돼 있다.

Session의 문제의식은 비교적 단순하다. 기존 메신저는 메시지 내용을 암호화하더라도, 가입 과정에서 전화번호를 요구하거나, 중앙 서버가 대화 상대·접속 시점·IP 주소 같은 주변 정보를 많이 쥐고 있는 경우가 많다. Session은 이런 구조에서 한발 더 나아가, 내용 보호뿐 아니라 관계 정보와 네트워크 정보의 노출 축소까지 목표로 삼았다. 공식 문서도 전화번호 없는 가입, 메타데이터 최소화, 어니언 라우팅을 정체성의 핵심으로 설명한다.

프로젝트는 2020년 1월 공개 출시되었고, 초창기에는 Signal 코드베이스를 바탕으로 빠르게 출발했다. 다만 공식 설명에 따르면, 이후 다중 기기 지원·복구·분산 네트워크 적합성 같은 문제 때문에 Session 전용 프로토콜과 공용 라이브러리 쪽으로 무게중심이 이동했다. 운영 측면에서도 2024년 10월부터는 스위스 재단인 Session Technology Foundation (STF)이 공식 운영 주체 역할을 맡고, 2025년에는 기존 Oxen 기반 네트워크에서 Session Network로의 전환이 진행되었다.

Session을 이해할 때 가장 먼저 잡아야 할 포인트는 메타데이터(metadata)이다. 이는 메시지 본문이 아니라, 누가 누구에게 보냈는지, 언제 보냈는지, 어떤 IP에서 접속했는지 같은 주변 정보를 뜻한다. Session은 메시지 본문을 암호화하는 데서 멈추지 않고, 이런 주변 정보까지 최대한 적게 남기려는 설계를 앞세운다. 쉽게 말해 "대화 내용이 안 보인다"를 넘어서 "대화 사실 자체도 덜 드러나게 하자"에 가깝다.

Session은 가입에 전화번호나 이메일이 필요하지 않다. 대신 공개키 기반의 Account ID를 식별자로 사용하며, 계정 복구는 일반적인 아이디/비밀번호 방식이 아니라 복구 문구(recovery password, mnemonic seed)를 통해 이뤄진다. 이 설계는 익명성 측면에서는 강점이지만, 반대로 복구 문구를 잃어버리면 중앙 사업자에게 "비밀번호 재설정"을 요청하는 식의 복구는 기대하기 어렵다.

Session의 백엔드는 중앙 서버 한 대가 아니라 커뮤니티가 운영하는 Session Node들로 구성된다. 이 노드들은 메시지 같은 데이터를 검증·처리하고, 토큰 스테이킹과 보상 구조를 통해 인센티브를 받는다. 이 때문에 Session은 프라이버시 메신저이면서도, 동시에 토큰 기반 인프라 프로젝트라는 성격을 함께 가진다.

다만 여기서 자주 생기는 오해가 하나 있다. Session이 블록체인과 연관되어 있다고 해서, 채팅 메시지 자체가 블록체인에 올라가는 것은 아니다. 공식 FAQ도 메시지는 블록체인에 저장되지 않으며, 별도의 저장 계층에서 일정 기간 보관된다고 설명한다. 블록체인/토큰은 주로 노드 인센티브, 검증, 네트워크 운영과 연결되고, 실제 메시지 저장은 다른 계층에서 처리된다.

Session의 메시지는 기본적으로 onion requests라는 방식으로 전송된다. 이는 보통 3개의 노드를 거치는 임의 경로를 만들고, 각 홉마다 암호 레이어를 벗겨 가며 전달하는 구조다. 이 덕분에 어느 한 노드도 메시지의 출발지와 도착지를 동시에 완전하게 알기 어렵다. Session이 "IP를 숨긴다"거나 "메타데이터를 줄인다"고 말할 때 핵심이 되는 부분이 바로 이것이다.

상대방이 오프라인이어도 메시지를 받을 수 있으려면 어딘가에 잠시 저장해둘 장소가 필요하다. Session에서는 이를 swarms가 맡는다. 스웜은 소수의 Session Node 묶음이며, 특정 Account ID 범위의 메시지를 임시 저장하고 서로 복제해 장애에 대비한다. 메시지는 이 스웜에 저장되며, 공식 FAQ 기준 고정된 TTL(time-to-live)에 따라 삭제된다. 계정 복구 시 최근 메시지만 복원되는 이유도 여기에 있다.

Session에는 둘 이상의 사람과 대화하는 방식이 크게 Groups와 Communities로 나뉜다. Groups는 앱 내부에서 만드는 종단간 암호화 그룹 채팅이고, Communities는 대규모 공개 채널에 가까운 구조다. 중요한 점은 두 기능의 프라이버시 수준이 같지 않다는 것이다. 공식 문서에 따르면 Communities는 self-hosted 서버(SOGS)에 의존하며, 메시지가 서버에 저장될 때는 종단간 암호화되지 않는다. 즉, Session 안에 있다고 해서 모든 대화 공간이 같은 보안 성질을 가지는 것은 아니다.

메시지와 통화도 같은 방식으로 작동하지 않는다. Session의 음성/영상 통화는 FAQ 기준 아직 beta 성격이며, 현재 구현은 WebRTC 기반 P2P(peer-to-peer) 호출이다. 그래서 메시지처럼 어니언 라우팅되는 것이 아니라, 통화 상대와 STF 운영 STUN/TURN 서버에 IP가 노출될 수 있다. 이 차이를 모르고 "Session이니까 통화도 당연히 완전 익명"이라고 생각하면 오해가 된다.

Session의 대표적인 활용처는 전화번호를 주고받기 싫은 1:1 연락이다. 상대에게 내 실명 번호를 넘기지 않고도 Account ID만으로 대화를 시작할 수 있기 때문이다. 이 때문에 프라이버시 민감 사용자는 물론, 단순히 업무 외 연락처 노출을 줄이고 싶은 사람에게도 의미가 있다.

또 다른 활용은 소규모 보안 대화와 대규모 공개 커뮤니티 운영을 분리해서 다루는 것이다. 소규모로는 종단간 암호화 그룹을, 대규모로는 Communities를 쓰는 식이다. 이 구분이 중요한 이유는 기능이 비슷해 보여도 보안 속성이 다르기 때문이다. 즉, Session은 "하나의 앱 안에 여러 커뮤니케이션 모델이 공존하는 구조"로 보는 편이 맞다.

블록체인 쪽에서는, 메시지 앱 그 자체보다도 토큰 인센티브를 붙인 프라이버시 통신 인프라 사례로 자주 언급된다. 노드 운영·스테이킹·네트워크 검증 로직이 별도 네트워크와 앱체인 구조에 연결돼 있기 때문에, 단순한 앱 비교를 넘어서 "탈중앙화 네트워크가 실제 사용자용 서비스를 어떻게 떠받치는가"라는 관점에서 보는 경우가 많다.

Session의 가장 유명한 쟁점은 오랫동안 PFS(Perfect Forward Secrecy, 완전 순방향 비밀성) 부재였다. 2020년 Session 전용 프로토콜로 넘어가면서 Signal 계열 프로토콜이 주던 일부 성질을 포기했고, 공식 문서도 그 대가로 PFS·부인 가능성(deniability) 같은 속성이 약해졌다고 설명한다. Privacy Guides 역시 2025년 말까지 이를 가장 자주 비판받는 약점 중 하나로 정리했다. 다만 Session 측은 2025년 12월 발표한 Protocol V2에서 PFS와 양자내성 암호(post-quantum cryptography)를 다시 도입하겠다고 밝혔으며, 외부 요약도 당시 기준으로 V2가 아직 최종 확정 단계는 아니라고 보았다.

두 번째 한계는 기능별 위협 모델이 다르다는 점이다. 메시지는 어니언 라우팅을 쓰지만, 통화는 P2P/WebRTC 기반이라 IP 노출 위험이 달라진다. 모바일의 fast mode 푸시 알림도 편의성을 얻는 대신 Apple/Google 푸시 인프라와 STF 푸시 서버에 일부 식별 정보가 전달된다. 즉, Session은 메타데이터를 줄이려는 앱이지만, 모든 기능에서 모든 메타데이터가 완전히 사라진다고 이해하면 곤란하다.

세 번째는 복구와 보존의 한계다. 공식 FAQ에 따르면 복구 문구로 되살릴 수 있는 메시지는 최근 14일치에 한정되며, 연락처/그룹 구성 정보는 30일 안에 한 기기라도 온라인이 아니었다면 복구가 되지 않을 수 있다. 이런 설계 때문에 중앙형 메신저식 "언제든 예전 기록을 다 되살리는 경험"과는 거리가 있다. 쉽게 말해 "덜 남기기 위해, 덜 복구된다"는 트레이드오프가 있다.

또 하나의 쟁점은 토큰과 탈중앙화의 관계이다. Session은 자체 토큰과 스테이킹 구조를 네트워크 보안·운영의 핵심으로 둔다. 지지하는 쪽은 이것이 지속가능한 분산 인프라의 해법이라고 보고, 비판하는 쪽은 메신저의 신뢰 기반이 결국 별도의 암호자산 경제에 의존한다는 점을 부담으로 본다. Privacy Guides는 2025년 말에도 Session의 탈중앙화가 자체 암호자산에 강하게 기대고 있다는 점을 논쟁거리로 언급했다.

그렇지 않다. 공식 FAQ는 메시지가 블록체인에 저장되지 않고, 스웜이라는 저장 계층에 일정 기간 보관된다고 명시한다. 블록체인은 주로 노드 등록·인센티브·검증 구조 쪽과 더 가깝다.

그렇지 않다. Session은 익명성이 강한 대신, 내가 대화하는 사람이 정말 그 사람인지의 확인은 별도 문제다. 공식 FAQ도 truly anonymous communications systems에서는 secure secondary channel로 상대를 확인하는 것이 좋다고 안내한다. 즉, 익명성과 신원 검증은 같은 말이 아니다.

아니다. Groups는 종단간 암호화 그룹이지만, Communities는 self-hosted 서버 모델이며 메시지가 저장 시점에는 종단간 암호화되지 않는다. 대규모 공개 채널과 소규모 민감 대화를 같은 기준으로 보면 안 된다.

이렇게 단순하게 보기는 어렵다. Session은 2020년 공식 소개에서 스스로 Signal 코드베이스를 출발점으로 삼았다고 설명하지만, 이후 목표를 전화번호 없는 익명성과 분산 네트워크 쪽으로 더 강하게 틀었다. 그 과정에서 Signal 계열 프로토콜이 주던 일부 성질을 포기했다가, 다시 V2에서 보완하려는 흐름이 이어졌다. 즉, 두 서비스는 겹치는 부분도 있지만 설계 우선순위가 완전히 같지는 않다.