NGINX Plus R7 출시 발표

NGINX | 2015년 9월 16일

NGINX, Inc.는 자사의 애플리케이션 전송 플랫폼 최신 버전인 NGINX Plus Release 7(R7)의 출시를 자랑스럽게 발표합니다. 이번 업데이트는 주요 웹 서버 중 최초로 새로운 HTTP/2 웹 표준을 완벽하게 지원합니다. NGINX Plus는 신규 및 기존 웹 서비스 모두를 위한 프런트엔드 HTTP/2 게이트웨이이자 가속기로 배포할 수 있습니다.

[편집자 주 – 이 게시물은 원본에서 언급된 별도의 상태 모듈을 대체하며 해당 모듈의 사용 중단을 알리는 NGINX Plus API를 참조하도록 업데이트되었습니다.]

이번 최신 업데이트에는 조직이 엔터프라이즈 애플리케이션에 요구되는 성능, 보안 및 안정성을 갖춰 애플리케이션을 제공할 수 있도록 대폭 개선된 기능과 새로운 역량도 추가되었습니다. 여기에는 애플리케이션 모니터링, 관리 및 디버깅을 더욱 간편하게 해주는 주요 개선 사항과 보안 및 성능 최적화를 위한 추가 기능이 포함됩니다.

편집자 주 – NGINX Plus R7의 주요 신규 기능에 대한 자세한 내용은 다음 관련 블로그 게시물을 참조하세요:

온디맨드 웨비나도 확인해 보세요. NGINX Plus R7의 새로운 기능은 무엇인가요?

이번 릴리스의 주요 기능은 다음과 같습니다:

  • HTTP/2의 완전 지원 구현 – 이제 NGINX Plus는 새로운 HTTP/2 웹 표준을 완벽하게 지원합니다. NGINX Plus는 신규 및 기존 웹 서비스 모두를 위한 프런트엔드 HTTP/2 게이트웨이 및 가속기로 배포할 수 있습니다.

    HTTP/2 지원은 선택 사항인 nginx-plus-http2 패키지에서만 제공됩니다. nginx-plus 및 nginx-plus-extras 패키지는 SPDY를 지원하며, 더 폭넓은 브라우저 지원과 코드 성숙도를 갖추고 있어 현재 프로덕션 사이트에 권장됩니다.참고: 사용자의 알파 수준 패치 테스트 결과와 기업 공동 후원사인 Automattic 및 Dropbox의 초기 지원을 바탕으로, HTTP/2의 최종 오픈 소스 버전은 R7 출시 후 제공될 예정입니다.
  • 대폭 향상된 성능 – NGINX Plus R7은 스레드 풀을 활용한 비동기 I/O를 지원합니다. 이를 통해 콘텐츠 캐싱처럼 디스크 I/O가 많은 워크로드의 처리 속도가 향상됩니다. 벤치마크 결과에 따르면 스레드 풀을 통해 특정 워크로드의 성능을 최대 9배 향상할 수 있습니다.

    NGINX Plus R7은 멀티코어 서버의 성능을 높이기 위한 소켓 샤딩 최적화도 지원합니다. 벤치마크 결과에 따르면 이를 통해 초당 요청 수를 3배 이상 늘리고 지연 시간을 3배 이상 단축할 수 있습니다. 소켓 샤딩은 SO_REUSEPORT 옵션을 사용하며, 현재 Linux 3.9 이상 또는 DragonFly BSD가 필요합니다.
  • 액세스 제어 및 보안 강화 – NGINX Plus의 새로운 기능과 확장된 기능은 애플리케이션의 보안과 안정성을 향상하는 데 도움이 됩니다. TCP 서비스에 대한 액세스 제어 및 연결 제한을 통해 NGINX에서 관리하는 모든 서비스에 보호 규칙을 적용할 수 있으며, NT LAN Manager(NTLM) 인증을 지원하므로 레거시 Microsoft 애플리케이션 앞단에 NGINX Plus를 배포할 수 있습니다.
  • 향상된 모니터링 및 진단 – NGINX Plus는 기존 상태 및 대시보드 도구에 더욱 상세한 모니터링 및 통계 데이터를 추가합니다. 클라이언트 오류, NGINX 내부 활동 및 서비스의 SSL 부하를 추적하여 문제를 파악하고 구성을 최적화할 수 있습니다.
  • 업데이트된 대화형 NGINX Plus 대시보드 – NGINX Plus의 실시간 활동 모니터링 대시보드가 대폭 확장되어, 이제 탭 인터페이스를 통해 NGINX의 성능과 상태를 더욱 상세하게 확인할 수 있습니다. 세부 정보를 살펴보며 인프라의 문제를 파악하고 이해할 수 있으며, 구성을 신속하게 변경할 수 있습니다.

NGINX, Inc.의 CEO인 Gus Robertson은 “지난 한 해 동안 수백 곳의 신규 고객이 NGINX Plus를 통해 애플리케이션을 배포할 수 있도록 지원해 왔으며, 이번 최신 릴리스는 고객이 사용자에게 최상의 경험을 제공할 수 있도록 더 많은 도구를 제공하는 데 중점을 두었습니다.”라고 말했습니다. “NGINX는 고객 인프라의 근간을 이루고 있기 때문에 고객이 배포하는 애플리케이션에 대해 독보적인 가시성과 제어 기능을 제공할 수 있는 특별한 위치에 있습니다. 당사는 고객의 비즈니스에서 맡고 있는 핵심적인 역할을 중요하게 여기며, NGINX Plus R7의 새로운 기능에는 이러한 자세가 반영되어 있습니다.”

최근 몇 달 동안 NGINX 도입이 크게 증가했습니다. NGINX는 상위 10만 개 웹사이트에서 1위를 차지한 웹 서버로, 전 세계에서 가장 트래픽이 많은 사이트 중 거의 절반이 NGINX를 사용하여 수십억 명의 사용자에게 애플리케이션을 제공하고 있습니다. NGINX, Inc.는 가장 작고 가벼운 앱부터 세계 최대 규모의 플랫폼에 이르기까지 누구나 완벽하게 애플리케이션을 제공할 수 있도록 오픈 소스 도구와 상용 지원 도구 모두에 지속적으로 대규모 투자를 하고 있습니다.

NGINX Plus R7 기능 상세

이 섹션에서는 NGINX Plus R7의 모든 새로운 기능을 자세히 살펴봅니다.

HTTP/2의 완전 지원 구현

NGINX Plus R7은 새로운 nginx-plus-http2 패키지를 통해 최신 HTTP 프로토콜 버전인 HTTP/2를 지원합니다. HTTP/2는 최신 웹 애플리케이션의 성능과 보안을 향상합니다. NGINX Plus의 HTTP/2 지원은 기존 사이트 및 앱을 변경할 필요 없이 원활하게 연동되며, NGINX Plus 구성도 아주 조금만 변경하면 됩니다. NGINX Plus R7은 완벽한 하위 호환성을 제공하며 HTTP/1.x와 HTTP/2 트래픽을 동시에 처리할 수 있어, 사용자가 어떤 브라우저를 선택하든 최상의 환경을 제공합니다.

서버 수준에서 구현된 HTTP/2는 HTTP/2 및 HTTP/1.x를 사용하는 브라우저를 모두 지원합니다

HTTP/2로 원활하게 전환할 수 있도록 NGINX Plus는 ‘HTTP/2 게이트웨이’ 역할을 합니다. 프런트엔드에서 NGINX Plus는 HTTP/2를 지원하는 클라이언트 웹 브라우저와 HTTP/2로 통신하고, 백엔드에서는 이전과 마찬가지로 HTTP/1.x(또는 FastCGI, SCGI, uWSGI 등)로 통신합니다. 따라서 NGINX Plus가 프록시하는 서버와 애플리케이션은 HTTP/2로 전환해도 영향을 받지 않으며, 클라이언트가 어떤 HTTP 버전을 사용하는지 알 필요조차 없습니다.

HTTPS와 HTTP/2를 함께 지원하기 위해 NGINX Plus는 TLS의 NPN(Next Protocol Negotiation) 및 ALPN(Application‑Layer Protocol Negotiation) 확장을 모두 지원합니다. 클라이언트와 서버가 모두 HTTP/2를 지원하는 경우, 이러한 확장을 사용하여 HTTPS 연결을 HTTP/2로 원활하게 업그레이드할 수 있습니다.

필요한 구성 변경은 기존 http2 매개변수를 listen 지시문에 추가하는 것뿐입니다. HTTP/2는 ssl 매개변수도 포함된 경우에만 지원됩니다:

server {    listen 443 ssl http2 default_server;
}

HTTP/2 지원을 활성화하려면 NGINX Plus 저장소에서 nginx-plus-http2 패키지를 설치하세요. 이 패키지는 SPDY/3.1을 지원하지 않습니다. 표준 nginx-plus 및 nginx-plus-extras 패키지는 HTTP/2 대신 SPDY/3.1을 지원하며, 브라우저 지원 범위가 더 넓고 코드의 완성도가 높기 때문에 현재 프로덕션 사이트에 권장됩니다. 현재 nginx-plus-extras 패키지의 HTTP/2 지원 버전은 빌드하지 않는다는 점에 유의하세요.

HTTP/2에 대해 자세히 알아보려면:

대폭 향상된 성능

NGINX Plus R7에는 애플리케이션의 성능을 한층 더 높이는 데 도움이 되는 다양한 성능 개선 사항이 포함되어 있습니다. 또한 스레드 풀 최적화를 지원하여 잠재적으로 차단을 일으킬 수 있는 디스크 작업을 오프로드하고, 콘텐츠 캐싱과 같이 디스크 I/O가 많은 워크로드의 성능을 향상합니다. NGINX Plus R7에는 소켓 샤딩 최적화(Linux 3.9 이상 또는 Dragonfly BSD 필요)도 포함되어 있어, 다수의 nginx 프로세스가 트래픽을 처리하는 대규모 멀티코어 서버의 효율성을 높입니다. 이러한 최적화 기능은 NGINX Open Source 배포 환경에서 실제 테스트를 거쳤으며, 이제 NGINX Plus의 일부로 완전히 지원됩니다.

스레드 풀

NGINX Plus에서 스레드 풀을 사용하면 성능을 9배 향상할 수 있습니다. NGINX가 연결 처리에 비동기식 이벤트 기반 접근 방식을 사용한다는 것은 잘 알려져 있습니다. 하지만 비동기식 이벤트 기반 접근 방식에도 여전히 블로킹이라는 문제가 있습니다. Linux에서는 디스크 작업이 블로킹 방식으로 수행되므로, 디스크 I/O가 많은 작업을 처리할 때 NGINX는 생산적인 작업을 수행하기보다 블로킹 상태에서 많은 시간을 보낼 수 있습니다.

디스크 I/O를 처리하는 스레드 풀을 할당하면 이 문제를 완화할 수 있습니다. NGINX 워커 프로세스는 디스크에 직접 액세스하는 대신 I/O 작업을 풀에서 사용 가능한 스레드에 넘긴 후 평소처럼 트래픽 처리를 계속합니다. 디스크 작업이 완료되면 NGINX 워커 프로세스에 알림이 전달되며, 요청을 처리하기 위해 남아 있는 작업을 계속 수행할 수 있습니다.

스레드 풀을 활성화하려면 aio threads 지시어를 location 블록에 추가하기만 하면 됩니다:

location / {    root /storage;
    aio threads;
}

NGINX의 스레드 풀에 대한 자세한 개요는 이 블로그 게시물을 참조하세요.

소켓 샤딩

소켓 샤딩은 NGINX 1.9.1에서 처음 도입되었습니다. 이 기능은 Linux 커널 버전 3.9에서 도입된 SO_REUSEPORT 소켓 옵션을 활용합니다. 이 옵션을 활성화하면 Linux 커널이 새 연결을 라운드 로빈 방식으로 NGINX 워커 프로세스에 균등하게 분배합니다. 그런 다음 워커 프로세스가 요청 제한, 캐싱, 부하 분산을 비롯해 구성된 다른 모든 작업을 수행합니다.

Without SO_REUSEPORT를 사용하지 않으면 새 연결을 사용 가능한 모든 워커 프로세스가 서로 가져가려고 경쟁하게 됩니다. 대기열에서 연결을 가장 먼저 가져가는 프로세스가 해당 연결을 처리합니다. 부하를 균등하게 분산하는 알고리즘이 없으므로 일부 워커 프로세스에 부하가 대부분 집중되고 나머지는 충분히 활용되지 않는 등 부하가 쉽게 편중될 수 있습니다. 또한 프로세스가 패킷을 두고 경쟁하면 잠금 경합이 발생할 수 있으므로 비효율적입니다.

소켓 샤딩은 작업이 NGINX 워커 프로세스 간에 고르게 분산되도록 하여 성능을 최대 3배까지 향상할 수 있습니다. 이 기능을 활성화하려면 기존 reuseport 매개변수를 listen 지시문에 추가하세요.

server {    listen 12345 reuseport;
    # ...
}

이 기능에 대해 자세히 알아보려면 이 블로그 게시물을 참조하세요.

참고: 이 기능을 사용하려면 Linux 커널 버전 3.9 이상이 필요합니다. Ubuntu 13.10 이상 및 Red Hat Enterprise Linux 7 이상에는 필요한 기능이 포함되어 있습니다.

액세스 제어 및 보안 강화

NGINX Plus R7에는 애플리케이션의 보안을 강화하기 위한 기능이 더욱 추가되었습니다. 이 섹션에서는 이러한 기능을 간략히 살펴봅니다.

TCP 액세스 제어 및 제한

TCP 프록시 및 로드 밸런싱의 새로운 기능을 통해 액세스 제어(IP 주소별 제한), 연결 제한(클라이언트 또는 서비스별 동시 연결 수 제한), 대역폭 사용량 제어(연결별 업스트림 또는 다운스트림 대역폭 제한)가 개선되었습니다. 이러한 기능은 이미 HTTP 로드 밸런싱에서 제공되고 있으며, API 사용량 측정 및 DDoS 방어에 매우 효과적으로 활용되고 있습니다.

자세한 내용은 관련 블로그 게시물인 NGINX Plus R7의 TCP 부하 분산<.htmlspan>을 참조하세요.

NTLM 지원

많은 요청에 따라 NGINX Plus R7은 인증에 Microsoft NT LAN Manager(NTLM)를 사용하는 애플리케이션을 프록시하고 부하를 분산할 수 있습니다. NTLM은 많은 Microsoft 제품, 특히 레거시 애플리케이션에서 사용되는 인증 프로토콜입니다.

NTLM 지원은 백엔드 서버에 대한 연결을 활성 상태로 유지하되 다중화하지 않아야 한다는 보안 요구 사항을 충족하므로, NTLM 인증을 받은 각 클라이언트는 백엔드 서버에 대한 고유한 전용 연결을 갖게 됩니다.

NTLM 지원을 활성화하려면 HTTP 업스트림 그룹 구성에 ntlm 지시어를 추가합니다:

upstream backend {    server 192.168.1.10;
    server 192.168.1.11;
    ntlm;
}

이제 Microsoft 애플리케이션 앞단에 NGINX를 프록시, 로드 밸런서 및 HTTP/2 가속기로 안심하고 배포하여 가능한 한 폭넓은 클라이언트 기기를 지원할 수 있습니다.

향상된 모니터링 및 진단

NGINX Plus는 상세한 모니터링 및 통계 기능을 제공하여 애플리케이션과 인프라를 손쉽게 관찰하고 최적화하며 디버깅할 수 있도록 지원합니다. 이러한 기능을 기반으로 NGINX Plus R7에는 새로운 카운터와 통계가 대거 추가되었습니다. 이러한 카운터를 활용하면 NGINX Plus 배포를 조정하고, 더 많은 부하를 처리하기 위해 언제 스케일업 또는 스케일아웃해야 할지 합리적으로 판단할 수 있습니다. 새롭게 추가된 통계와 카운터는 다음과 같습니다:

  • 499 오류 – 클라이언트가 요청 처리를 완료하기 전에 백엔드 서버와의 연결을 종료할 때 발생하는 499 오류를 추적하는 서버별 카운터입니다. 소수의 499 오류는 허용 가능한 수준이지만(사용자가 세션 도중 웹 브라우저를 닫는 경우가 종종 있음), 오류가 많이 발생하면 서버가 과부하 상태여서 요청을 처리하는 데 오랜 시간이 걸리고 있음을 나타낼 수 있습니다.
  • NGINX Plus 워커 재시작 – NGINX Plus 워커가 재시작된 횟수입니다. 이 수치는 NGINX Plus 워커 프로세스의 비정상 종료를 감지하는 데 도움이 됩니다.
  • NGINX Plus 다시 로드 횟수 – NGINX Plus가 다시 로드된 횟수입니다. 이를 통해 NGINX Plus가 실제로 다시 로드되었는지 또는 잘못된 구성과 같은 여러 가지 이유로 다시 로드에 실패했는지 확인할 수 있습니다.
  • 큐 오버플로 – 서버가 부하를 얼마나 잘 처리하는지 측정하는 서버별 카운터입니다. 큐 오버플로 횟수가 많으면 서버가 부하를 감당하는 데 어려움을 겪고 있음을 나타냅니다.
  • SSL 핸드셰이크 – 완료된 SSL 핸드셰이크 수입니다.
  • 재사용된 SSL 세션 – 이전 세션에서 재사용된 SSL 세션 수입니다.
  • 새 SSL 세션 – 새로 협상된 SSL 세션 수입니다.

다른 모든 카운터와 마찬가지로, 구성에 api 지시어를 포함하면 새 카운터를 활성화할 수 있습니다.

업데이트된 대화형 NGINX Plus 대시보드

The NGINX Plus 대시보드는 R7에서 크게 개선되어, 규모가 크고 복잡한 구성에서도 주요 시스템 정보를 간결한 형식으로 표시합니다:

  • 새로운 대시보드 개요 탭에서는 NGINX Plus 활동과 애플리케이션 상태를 한 페이지에서 종합적으로 요약해 보여 줍니다.
  • 대시보드의 인터페이스를 사용하여 부하 분산 풀에서 서버를 일시적으로 추가하거나 제거할 수 있으며, 서버를 일시적으로 드레이닝 또는 비활성 상태로 표시할 수도 있습니다.
  • 새로운 필터를 사용하면 빠르게 범위를 좁혀 장애가 발생한 서버를 찾을 수 있습니다.
  • 새로운 탭 보기를 사용하면 대시보드 탭에서 영역, 업스트림 및 캐시 정보에 대한 더 상세한 보기로 빠르게 전환할 수 있습니다.
  • 대시보드 전반에 새로 추가된 도구 설명을 통해 업스트림 서버, 구성 다시 로드, 캐시 상태 및 오류 메시지에 대한 자세한 정보를 확인할 수 있습니다.

자세한 내용은 관련 블로그 게시물인 새로운 NGINX Plus 대시보드<.htmla>를 참조하세요.

몇 가지 유용한 기능 더

NGINX Plus R7에는 위의 어떤 범주에도 속하지 않는 여러 가지 추가 개선 사항이 있습니다:

NGINX Plus와 호환되도록 Phusion Passenger 오픈 소스 업그레이드

If you use Phusion Passenger Open Source를 NGINX Plus와 함께 사용하는 경우(구성에 passenger_root 지시문이 포함된 경우), NGINX Plus R7 nginx-plus-extras 패키지로 업그레이드하는 동시에 Passenger 런타임을 버전 5.0.15로 업그레이드해야 합니다. 다음 단계를 수행하십시오(명령은 Ubuntu에 적합함):

  1. NGINX Plus를 중지합니다:
# service nginx stop
  1. Phusion Passenger 런타임을 5.0.15로 업그레이드하세요:
# apt-get install passenger
  1. NGINX Plus Extras 패키지를 R7로 업그레이드합니다:
# apt-get install nginx-plus-extras
  1. Phusion Passenger 업그레이드 참고 사항에 설명된 대로 NGINX Plus 구성 지시문을 필요한 내용으로 업데이트합니다.
  2. NGINX Plus를 시작합니다:
# service nginx start

전체 설치 및 업그레이드 지침은 NGINX Plus 고객 포털에서 확인할 수 있습니다.

NGINX Plus로 업그레이드하거나 체험하기

NGINX Plus를 실행 중이라면 가능한 한 빨리 릴리스 7로 업그레이드하시기를 강력히 권장합니다. 업그레이드하면 여러 수정 사항과 개선 사항이 적용되며, 지원 티켓을 제출해야 할 때 더 원활하게 도움을 받으실 수 있습니다. 설치 및 업그레이드 지침은 고객 포털에서 확인할 수 있습니다.

아직 NGINX Plus를 사용해 보지 않으셨다면 웹 가속, 부하 분산 및 애플리케이션 전송을 위해 사용해 보시거나, 향상된 모니터링 및 관리 API를 갖춘 완전한 지원이 제공되는 웹 서버로 활용해 보시기 바랍니다. 지금 바로 무료 30일 평가판을 시작하여 NGINX Plus가 애플리케이션을 확장하고 전송하는 데 어떻게 도움이 되는지 직접 확인해 보세요.

주의 사항

  • 이러한 배포판에 대한 일반 지원이 종료됨에 따라 NGINX Plus R7에서는 더 이상 Debian 6, SLES 11 SP3, Ubuntu 10.04 LTS 및 14.10을 지원하지 않습니다. NGINX Plus R7로 업그레이드하기 전에 지원되는 운영 체제 배포판으로 업그레이드하십시오.
  • NGINX Plus R7은 nginx-plus-lua 패키지가 포함되는 마지막 릴리스입니다. 이 패키지를 사용 중이라면 NGINX Plus 릴리스 8에서 nginx-plus-extras 패키지로 마이그레이션할 계획을 세우십시오.
  • nginx-plus-http2 패키지를 설치하기 전에 구성의 모든 spdy 매개변수를 listen 지시문에서 제거해야 합니다(HTTP/2 지원을 활성화하려면 이 매개변수를 http2 및 ssl 매개변수로 대체하십시오). nginx-plus-http2 패키지를 사용하는 경우 listen 지시문에 spdy 매개변수가 하나라도 있으면 NGINX Plus가 시작되지 않습니다.


공유

작성자 소개

관련 블로그 게시물

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
NGINX | 2023. 11. 30.

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric

이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
NGINX | 2023. 03. 23.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법

앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
NGINX | 2021. 09. 27.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션

개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX | 2021. 07. 06.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법

NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX | 2021. 06. 30.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리

NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
NGINX | 2015. 03. 25.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유

Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.