sgcWebSockets vs Indy — 2026년에 어떤 것을 선택할까요

· 리뷰

두 라이브러리, 두 가지 다른 작업

거의 모든 Delphi 개발자가 어느 시점에 Indy를 사용해 봤어요. IDE와 함께 박스에 들어 있고, 1990년대 후반부터 있었으며, 한 세대의 Delphi 네트워킹 코드가 TIdHTTP, TIdTCPClient, TIdSMTP 및 친구들 위에 구축되어 있어요. sgcWebSockets는 Indy가 원래 설계된 이후에 등장한 프로토콜에 초점을 맞춘 훨씬 더 새로운 상용 라이브러리예요 — WebSocket, HTTP/2, HTTP/3 / QUIC, MQTT 5, AMQP 1.0, SSE, WAMP, WebRTC, MCP — 그리고 REST API 통합의 큰 카탈로그.

Embarcadero 포럼과 Stack Overflow에서 가장 일반적인 질문은 “Indy가 무료인데 왜 sgcWebSockets에 비용을 지불해야 하나요?”의 변형이에요. 짧은 답변은 그들이 다른 문제를 해결하며, 많은 실제 프로젝트에서 결국 둘 다 사용하게 될 것이라는 거예요. 이 기사는 2026년의 실용적인 차이점을 살펴봐서 어떤 것(또는 어떤 조합)이 애플리케이션에 맞는지 결정할 수 있도록 해요.

각 라이브러리가 실제로 하는 일

Indy는 오랫동안 사용된 클래식 인터넷 프로토콜 목록이 있는 범용 TCP/UDP 툴킷이에요: HTTP/1.1, FTP, SMTP, POP3, IMAP, NNTP, DNS, IRC, Telnet, Whois, 그리고 TCP 서버 프레임워크. 디자인은 연결당 스레드 및 블로킹 I/O예요. 스톡 Indy에는 네이티브 WebSocket 클라이언트나 서버가 없어요 — 추가로 연결해야 하며, 여러 커뮤니티 프로젝트가 정확히 그것을 혼합된 결과로 수행해요.

sgcWebSockets는 최신 클라이언트/서버 시나리오를 목표로 하는 집중적이고 프로토콜이 풍부한 라이브러리예요. HTTP/2, QUIC을 통한 HTTP/3, MQTT, AMQP, STOMP, SSE, WAMP, P2P/WebRTC, IoT(CoAP, AWS IoT, Azure IoT), 종단 간 암호화 및 30개 이상의 API 래퍼(OpenAI, Anthropic, Google, AWS, Azure, Binance, Coinbase, Kraken, Telegram, WhatsApp 등)에 대한 선택적 애드온이 있는 코어 TsgcWebSocketClient / TsgcWebSocketHTTPServer 쌍을 중심으로 구성되어 있어요.

중요하고 종종 놓치는 세부 사항: sgcWebSockets는 Indy를 내부적으로 전송 백엔드 중 하나로 사용해요. 여러 컴포넌트의 TCP/TLS 배관은 그 아래에 있는 Indy TIdTCPClient / TIdHTTPServer이므로, sgcWebSockets를 설치한다고 해서 Indy가 대체되지 않아요 — 그 위에 구축돼요. 라이브러리는 또한 Indy가 가장 적합하지 않은 시나리오를 위해 대체 전송(Synapse 스타일, ICS, SChannel)을 제공해요.

기능별 비교

기능Indy (스톡)sgcWebSockets
HTTP/1.1 클라이언트예 (TIdHTTP)예 (TsgcHTTPComponentClient, Indy 또는 ICS 백엔드 사용 가능)
HTTP/1.1 서버예 (TIdHTTPServer)예 (TsgcWebSocketHTTPServer, 동일한 포트에서 HTTP + WS 처리)
WebSocket 클라이언트/서버네이티브 지원 없음전체 RFC 6455, permessage-deflate, 서브 프로토콜, autobahn 테스트됨
HTTP/2 (h2 + h2c)아니오예, 사용자 정의 HPACK + 프레임 계층
HTTP/3 / QUIC아니오예 (msquic 기반)
MQTT 3.1.1 및 5.0아니오예, 클라이언트 및 브로커
AMQP 1.0 / 0.9.1아니오예
STOMP, SSE, WAMP아니오예
WebRTC / P2P / STUN / TURN아니오예
CoAP 및 IoT 클라우드 (AWS, Azure)아니오예
OpenAI, Anthropic, Gemini, MCP아니오예, 전용 컴포넌트
FTP / SMTP / POP3 / IMAP예아니오 (이를 위해 Indy 사용)
무료 / 상용무료, MIT 스타일상용, Free 포함 여러 에디션
Delphi 버전D7 이상 (포크별 다름)D7부터 D13까지
활발한 유지 관리커뮤니티 (GitHub의 IndyProject)공급업체, 월간 릴리스

Indy가 여전히 승리하는 곳

프로젝트가 클래식 인터넷 클라이언트 — HTTP를 통해 파일 다운로드, 폼 게시, SMTP 이메일 전송, IMAP을 통해 메일 가져오기, 오래된 FTP 서버와 통신 — 라면 스톡 Indy가 올바른 답이에요. 무료이고, IDE와 함께 번들로 제공되며, API가 익숙하고, 다른 것이 필요하지 않아요. Indy가 네이티브로 제공하는 취미 TCP 서버 및 프로토콜(NNTP, IRC, Telnet, Whois)도 마찬가지예요. 이러한 사용 사례의 경우 유료 라이브러리를 추가하는 것은 과도해요.

Indy는 또한 이미 Indy 타입을 사용하는 코드와 상호 운용해야 할 때 명백한 선택이에요 — 예를 들어 TIdSSLIOHandlerSocketOpenSSL 또는 TIdHTTPServerCommandHandler를 예상하는 컴포넌트.

sgcWebSockets가 올바른 도구인 곳

최신 웹 스택과 관련된 모든 것이 sgcWebSockets로 훨씬 쉬워요. 구체적으로:

성능 및 확장성

Indy의 연결당 스레드 모델은 단순하고 올바르지만, 컨텍스트 스위칭이 병목이 되기 전에 일반적인 Windows 서버에서 수천 개의 동시 연결 정도로 실용적인 처리량을 제한해요. sgcWebSockets는 호환성을 위해 동일한 Indy 백엔드를 제공하며, Windows에서 IOCP 기반 서버 전송도 제공해요. 이 전송은 프로세스당 수만 개의 동시 WebSocket 연결로 벤치마크되었어요. 순수 HTTP 처리량의 경우 차이가 작지만 장기 연결(WebSocket, MQTT, SSE)의 경우 아키텍처 격차가 중요해요.

유휴 연결당 메모리 풋프린트도 소켓당 전용 OS 스레드가 없기 때문에 IOCP 전송으로 더 낮아요. Linux에서는 sgcWebSockets가 제공하는 Indy 포크를 통한 epoll 기반 서버로 그림이 유사해요.

유지 관리 및 릴리스 주기

Indy는 IndyProject GitHub 저장소의 소규모 자원 봉사자 그룹이 유지 관리해요. 릴리스는 느리지만 코드베이스는 안정적이에요. 중요한 수정 사항(TLS 호환성, 최신 OpenSSL 바인딩)은 도착하지만 항상 빠르지는 않아요.

sgcWebSockets는 월간 릴리스, 공개 기록 파일 및 직접 공급업체 지원이 있는 eSeGeCe의 상용 제품이에요. 새 Delphi 버전은 일반적으로 첫째 날에 지원돼요 — Delphi 13은 첫 베타부터 지원되었어요 — 그리고 새 프로토콜 개정(MQTT 5.0.1, HTTP/3 최종, MCP 사양 업데이트)이 몇 년이 아닌 며칠 내에 출시돼요.

라이선스 및 가격

Indy는 무료이며 Delphi와 함께 제공돼요. sgcWebSockets는 상용이지만 비상업적 사용을 위한 Free 에디션이 있으며, 점진적으로 더 넓은 프로토콜 적용 범위를 가진 유료 에디션(Standard, Professional, Enterprise, All-Access)이 있어요. 대부분의 상업적 프로젝트는 단일 배포된 고객이 있는 단일 개발자 Professional 라이선스를 정당화할 수 있어요.

간단한 결정 규칙

실용적인 2026년 경험 법칙:

맺음말

Indy는 어디로도 가지 않아요 — 모든 Delphi 툴박스의 신뢰할 수 있는 망치예요. 그러나 2026년 인터넷을 정의하는 프로토콜(WebSocket, HTTP/2/3, MQTT, WebRTC, AI API)은 Indy가 설계되었을 때 단순히 존재하지 않았어요. sgcWebSockets는 유용한 곳에서 Indy 위에 구축되고 필요한 곳에서 대체하는 집중적이고 활발히 유지 관리되며 상업적으로 지원되는 라이브러리로 그 격차를 메워요. 최신 백엔드를 대상으로 하는 새 프로젝트의 경우 질문은 더 이상 Indy 또는 sgcWebSockets?가 아니에요 — 어떻게 결합할까요?예요.