이 가이드가 존재하는 이유
WebSocket은 더 이상 틈새 전송이 아니에요. 트레이딩 대시보드, 채팅 백엔드, 멀티플레이어 게임, IoT 제어 평면, AI 스트리밍 응답, 브라우저 기반 관리 콘솔 — 거의 모든 최신 인터랙티브 애플리케이션이 적어도 하나의 WebSocket을 열어요. 2026년에 “어떤 라이브러리를 사용해야 하나요?”라고 묻는 Delphi 개발자는 생각보다 작은 분야를 마주해요: 모든 클래식 Delphi 네트워킹 패키지가 RFC 6455를 따라잡지는 못했고, 그렇게 한 일부는 매우 특정한 틈새를 목표로 해요.
이 가이드는 2026년 현재 현실적인 옵션 — sgcWebSockets, Indy, TMS FNC WX, mORMot, Synapse — 을 조사하고 끝에 결정 매트릭스를 제공해요. 주장이 공급업체의 현재 릴리스에 따라 다른 경우 이 기사는 작성 시점의 상황을 설명해요; 항상 약속하기 전에 공급업체의 최신 변경 로그에 대해 세부 정보를 확인하세요.
경쟁자
sgcWebSockets (eSeGeCe)
WebSocket과 더 넓은 최신 프로토콜 패밀리(HTTP/2, HTTP/3, MQTT, AMQP, STOMP, SSE, WAMP, WebRTC, IoT, AI API)에 초점을 맞춘 상용 라이브러리. 전체 RFC 6455, 메시지별 deflate, 서브 프로토콜, 채널, 브로드캐스트 헬퍼, WatchDog 자동 재연결, IOCP 서버 확장, JavaScript 클라이언트 미러, .NET 포트. 비상업적 사용을 위한 Free 에디션; 네 가지 유료 에디션. Delphi 7부터 13까지, C++Builder 및 .NET 포함.
Indy (스톡)
Delphi와 함께 제공되는 스톡 Indy에는 네이티브 WebSocket 클라이언트나 서버가 포함되지 않아요. 여러 커뮤니티 애드온이 존재하지만(GitHub에서 “Indy WebSocket” 검색) 작성 시점 공식 IndyProject 배포에 포함된 것은 없어요. Indy 위에 직접 WebSocket을 빌드하면 본질적으로 프레이머를 직접 작성하는 것이에요. 무료, 박스에 포함.
TMS FNC WX (이전 TMS WEB Core / FNC WebSocket)
TMS Software는 FNC 패밀리의 일부로 크로스 프레임워크 WebSocket 컴포넌트(TTMSFNCWebSocketClient 및 TMS XData / TMS Sparkle을 통한 서버 측)를 제공해요. VCL, FMX, LCL 및 TMS WEB Core에서 작동해요. 클라이언트 측은 견고해요; 서버 측은 주로 해당 제품의 기능으로 TMS XData / Sparkle 스택을 통해 제공돼요. 상용, 개발자별 구독 가격. Delphi 10.x 이상.
mORMot 2
Synopse(Arnaud Bouchez)의 오픈 소스 풀스택 프레임워크. SOA/ORM/REST 인프라와 긴밀하게 통합된 WebSocket 클라이언트 및 서버 포함. mORMot의 WebSocket은 성숙하고, 빠르며, 이진 프레이밍 및 메시지별 deflate를 지원하고, 고규모 서비스의 프로덕션에서 널리 사용돼요. 트레이드 오프는 mORMot이 의견이 강하다는 것이에요 — WebSocket 계층만 사용하는 것은 가능하지만 자연스러운 적합성은 더 넓은 프레임워크를 채택할 때예요. 오픈 소스(MPL/GPL/LGPL 트라이 라이선스), Delphi 7 이상, FreePascal 포함.
Synapse
클래식 오픈 소스 Pascal 네트워킹 라이브러리. 작성 시점에 스톡 Synapse에는 WebSocket 구현이 포함되지 않아요. Synapse 위에 빌드된 일부 서드파티 WebSocket 계층이 존재하지만 유지 관리되지 않거나 단일 작성자 프로젝트예요. 무료.
기능 매트릭스
| 기능 | sgcWebSockets | Indy (스톡) | TMS FNC WX | mORMot 2 | Synapse |
|---|---|---|---|---|---|
| WebSocket 클라이언트 | 예 | 아니오 | 예 | 예 | 아니오 |
| WebSocket 서버 | 예 | 아니오 | TMS XData/Sparkle 통해 | 예 | 아니오 |
| RFC 6455 (프레임, 마스킹, 제어 프레임) | 예 | 해당 없음 | 예 | 예 | 해당 없음 |
| 메시지별 deflate (RFC 7692) | 예 | 해당 없음 | 부분적 | 예 | 해당 없음 |
| 서브 프로토콜 / 채널 / 브로드캐스트 | 예, 내장 | 해당 없음 | 수동 | 수동 | 해당 없음 |
| 자동 재연결 / WatchDog | 예 | 해당 없음 | 수동 | 수동 | 해당 없음 |
| TLS를 통한 WebSocket (wss://) | 예 (OpenSSL, SChannel, BoringSSL) | 해당 없음 | 예 | 예 | 해당 없음 |
| WebSocket-MQTT / STOMP / WAMP 서브 프로토콜 | 예 | 해당 없음 | 아니오 | 제한적 | 해당 없음 |
| HTTP/2, HTTP/3 | 예 | 아니오 | 아니오 | 제한적 | 아니오 |
| IOCP / epoll 서버 확장 | 예 (Windows IOCP, Linux epoll) | 연결당 스레드 | 호스트 서버에 따라 다름 | 예 | 해당 없음 |
| JavaScript 클라이언트 미러 | 예 (JS lib 제공) | 해당 없음 | 예 (TMS WEB Core 통합) | 수동 | 해당 없음 |
| .NET 포트 | 예 (동일 API) | 해당 없음 | 아니오 | 아니오 | 해당 없음 |
| Delphi 버전 | D7 - D13 | D7 - D13 | D10.x - D13 | D7 - D13, FPC | D7 - D13, FPC |
| 라이선스 | 상용 (Free 에디션 존재) | 무료, MIT 스타일 | 상용 | 오픈 소스 트라이 라이선스 | 무료 |
| 공급업체 지원 | 유료 에디션에 포함 | 커뮤니티 (IndyProject) | 구독에 포함 | Synopse를 통한 상업적 지원 | 커뮤니티 / 단일 작성자 |
| 활발한 유지 관리 | 월간 릴리스 | 느리지만 안정적 | 정기적 | 매우 활성 | 느림 |
시나리오별 선택
시나리오 1: 서드파티 WebSocket API에 연결하는 VCL 데스크톱 앱
wss://에 연결하고, JSON을 보내고, JSON을 받고, 연결 해제 시 재연결하고, TLS를 처리하는 클라이언트가 필요해요. 가장 짧은 경로는 sgcWebSockets(컴포넌트 드롭, URL 설정, WatchDog.Attempts 설정, 완료) 또는 이미 FNC 팩을 라이선스한 경우 TMS FNC WX예요. Indy와 Synapse는 프레이머를 직접 작성해야 하는데, RFC 6455 엣지 케이스를 올바르게 처리하는 데 많은 작업이 필요해요.
시나리오 2: 수백 명의 클라이언트를 위한 WebSocket 서버 빌드
채널과 브로드캐스트가 있는 동일한 포트에서 HTTP와 WebSocket을 제공하는 독립형 서버 컴포넌트를 원한다면 sgcWebSockets가 자연스러운 선택이에요. 이미 mORMot 프레임워크 내에서 SOA/REST 서비스를 빌드하고 있다면 mORMot 2가 자연스러운 선택이에요 — WebSocket 계층이 스택의 나머지와 통합되며 규모에서 실전 테스트되었어요.
시나리오 3: 수만 개의 동시 연결
sgcWebSockets(Windows에서 IOCP, Linux에서 epoll)와 mORMot 2 모두 그 규모로 프로덕션에 배포되었어요. 스톡 Indy의 연결당 스레드 모델은 상당한 아키텍처 작업 없이는 따라잡을 가능성이 낮아요. TMS FNC WX 확장성은 선택한 호스트 서버(XData/Sparkle)에 따라 달라요.
시나리오 4: Pascal 풀스택 프레임워크 내의 WebSocket (REST, ORM, SOA)
mORMot 2. mORMot이 그것을 위한 거예요. WebSocket 계층만 단독으로 채택하는 것은 가능하지만 더 넓은 프레임워크를 수용할 때 가장 큰 가치를 얻어요.
시나리오 5: 크로스 프레임워크 클라이언트 (VCL, FMX, LCL, TMS WEB Core)
TMS FNC WX는 정확히 그 경우를 위해 설계되었어요 — 네 가지 모두에서 하나의 API. sgcWebSockets는 VCL, FMX 및 C++Builder와 .NET 포트를 다루지만 Lazarus/FPC를 대상으로 하지 않아요.
시나리오 6: WebSocket 플러스 MQTT, AMQP, WebRTC, HTTP/2, AI API 필요
sgcWebSockets는 이 비교에서 위의 모든 것을 단일 제품과 단일 컴포넌트 모델 하에 제공하는 유일한 라이브러리예요. 프로젝트가 “단순한 WebSocket 클라이언트”에서 “전체 실시간 스택”으로의 궤적에 있다면 일찍 통합하는 것이 나중에 여러 라이브러리를 함께 붙이는 것보다 일반적으로 더 저렴해요.
시나리오 7: 빠듯한 예산, 오픈 소스만, 취미 프로젝트
mORMot 2(오픈 소스)는 진지한 WebSocket 구현을 무료로 제공해요. sgcWebSockets의 Free 에디션은 비상업적 사용을 위한 옵션이에요. 커뮤니티 WebSocket 애드온이 있는 Indy는 기술적으로 가능하지만 관련 RFC를 직접 읽어야 할 거예요.
결정 매트릭스
| 가장 중요한 것 | 권장 선택 |
|---|---|
| 작동하는 클라이언트까지 가장 빠른 시간 + 공급업체 지원 | sgcWebSockets |
| 오픈 소스 풀스택 프레임워크 | mORMot 2 |
| 크로스 프레임워크 (VCL/FMX/LCL/WEB Core) | TMS FNC WX |
| 최고 동시 연결, 상용 | sgcWebSockets |
| 최고 동시 연결, 오픈 소스 | mORMot 2 |
| WebSocket + MQTT + HTTP/2 + WebRTC + AI를 다루는 하나의 제품 | sgcWebSockets |
| 무료 / 약속 없는 취미 프로젝트 | mORMot 2 또는 sgcWebSockets Free 에디션 |
| 이미 TMS XData / Sparkle 프로젝트 내부 | TMS FNC WX |
| 이미 mORMot 프로젝트 내부 | mORMot 2 |
약속하기 전 체크리스트
- Delphi 버전 — 공급업체가 호환성 매트릭스에서 정확한 버전(D7/D10.4/D11/D12/D13)을 나열하는지 확인하세요.
- RFC 6455 준수 — 라이브러리가 Autobahn WebSocket 테스트 스위트를 통과하는지, 또는 적어도 단편화, 단편화 중 제어 프레임 및 UTF-8 검증을 올바르게 처리하는지 확인하세요.
- TLS 제공자 — OpenSSL이 가장 일반적이에요; OpenSSL DLL을 배포할 수 없다면 SChannel이 중요해요; QUIC이 필요하다면 BoringSSL/ngtcp2가 중요해요.
- 재연결 의미 — 자동 재연결, 지수 백오프, ping/pong 킵얼라이브는 코드가 아닌 구성이어야 해요.
- 서버 확장 모델 — 수만 개의 연결에는 IOCP/epoll; 연결당 스레드는 낮은 수천 개까지 괜찮아요.
- 라이선스 호환성 — 트라이 라이선스(mORMot), 상업적 구독(TMS), 상업적 에디션별(sgcWebSockets), 무료(Indy/Synapse).
- 유지 관리 신호 — 지난 12개월의 변경 로그를 살펴보세요. 활성 라이브러리는 적어도 분기별로 무언가를 출시해요.
맺음말
2026년의 Delphi WebSocket 환경은 처음 봤을 때보다 더 건강해요. 빠른 클라이언트의 경우 sgcWebSockets가 몇 분 안에 작동하게 해줘요. 오픈 소스 풀스택 프로젝트의 경우 mORMot 2를 이기기 어려워요. 크로스 프레임워크 GUI 클라이언트의 경우 TMS FNC WX가 자연스러운 적합이에요. 스톡 Indy와 Synapse는 클래식 인터넷 프로토콜에 대해 가치가 있지만 어느 쪽도 WebSocket을 소유하지 않아요. 올바른 선택은 프로젝트가 “단일 엔드포인트”에서 “전체 실시간 플랫폼”까지의 스펙트럼에서 어디에 위치하는지에 따라 달라요 — 오늘의 요구 사항과 2년 후 프로젝트가 있을 곳 모두에 맞는 라이브러리를 선택하세요.