들어가며: 개발자들의 아우성, "MSA... 너란 녀석... 🤯"

자, 여기 개발자 A씨가 있습니다. 야심 차게 시작한 프로젝트에 최신 트렌드인 마이크로서비스 아키텍처(MSA)를 도입했죠.
각 기능이 독립적인 서비스로 분리되니 개발도 빠르고, 배포도 유연하고, 장애가 나도 전체 시스템이 멈추지 않으니...
와, 이거 완전 신세계잖아? 🌈

하지만 행복은 잠시뿐. 서비스가 수십, 수백 개로 늘어나면서 A씨의 머릿속은 점점 복잡해집니다.

"아니, 유저 서비스가 주문 서비스랑 통신할 때 인증은 어떻게 하지?"
"갑자기 트래픽이 몰리면 특정 서비스가 죽어버리는데, 이거 어떡해야 해?"
"서비스마다 로깅, 모니터링 코드를 다 따로 짜야 한다고? 이건 완전 중복 작업이잖아!"
"A 서비스는 Java, B 서비스는 Python, C 서비스는 Go... 통신 프로토콜은 어떻게 통일하지?"

이 모든 서비스 간의 통신, 즉 '네트워킹'을 애플리케이션 코드 안에서 처리하려니 배보다 배꼽이 더 커지는 상황이 발생한 겁니다.
비즈니스 로직 개발에만 집중하고 싶은데, 온갖 네트워크 처리 코드가 스파게티처럼 얽히기 시작했죠.

바로 이때, 구원투수처럼 등장한 존재가 있습니다. 그의 이름은 바로 Envoy (엔보이)!
오늘은 바로 이 Envoy가 어떻게 MSA 세계의 골칫거리들을 해결해주는지, 친구에게 설명하듯 쉽고 재미있게, 하지만 누구보다 깊이 있게 파헤쳐 볼 예정입니다. 커피 한 잔 준비하시고, 지금부터 저와 함께 Envoy의 세계로 떠나볼까요? 🚀

Envoy 101: 그래서 Envoy가 정확히 뭔데? 🤔

Envoy는 한마디로 "MSA 환경을 위해 태어난 고성능 L7 프록시 및 통신 버스"라고 정의할 수 있습니다.
...네, 너무 어렵죠? 😅 다시 쉽게 풀어볼게요.

여러분이 사는 거대한 아파트 단지(MSA)가 있다고 상상해봅시다.
이 단지에는 수많은 아파트 동(마이크로서비스)이 있고, 주민들(요청)은 끊임없이 다른 동을 방문하며 소통합니다.

이때, 아파트 단지 정문에 서서 외부 방문객을 관리하고, 단지 내 동과 동 사이를 오가는 모든 사람들의 길을 안내하며 안전과 질서를 책임지는 '만능 관리소장님'이 바로 Envoy입니다.

Envoy는 원래 차량 공유 서비스로 유명한 Lyft에서 자신들의 급증하는 마이크로서비스를 감당하기 위해 2016년에 C++로 직접 개발한 프로젝트입니다.
그런데 이게 너무 잘 만들어져서, 2017년에 오픈소스로 공개했고 지금은 당당히 CNCF(Cloud Native Computing Foundation)의 Graduated 프로젝트로 인정받으며 클라우드 네이티브 시대의 표준으로 자리 잡았죠.

"어? 근데 Nginx나 HAProxy 같은 프록시도 있잖아요? 뭐가 다른 거죠?"

아주 좋은 질문입니다! 기존의 프록시들도 훌륭하지만, Envoy는 태생부터 '동적인(Dynamic)' 클라우드 네이티브 환경에 최적화되어 있다는 결정적인 차이가 있습니다.

기존 프록시들은 대부분 설정 파일을 변경하고 서비스를 재시작해야 변경 사항이 적용됩니다.
하지만 수시로 서비스가 생기고 사라지는 MSA 환경에서는 이런 방식이 매우 비효율적이죠.
Envoy는 API(xDS API)를 통해 실행 중에 모든 설정을 동적으로 변경할 수 있습니다. 서비스 재시작 없이도 라우팅 규칙을 바꾸고, 새로운 서비스를 추가하고, 정책을 업데이트하는 것이 가능하죠. 이걸 'Hot Restart' 기능과 결합하면, 말 그대로 무중단 운영이 가능해집니다. 🤯

정리하자면, Envoy는 단순한 프록시를 넘어, MSA의 복잡한 네트워크 문제를 애플리케이션 개발자가 신경 쓰지 않도록 '추상화'해주는 강력한 인프라 레이어라고 할 수 있습니다.

Envoy 아키텍처 파헤치기: 만능 관리소장님의 업무 시스템 🛠️

자, 이제 Envoy가 어떻게 일하는지 그 내부 구조를 들여다볼 시간입니다.
조금 기술적인 내용이 나오지만, 최대한 쉽게 비유를 들어 설명해 드릴 테니 겁먹지 마세요! 😉

Envoy의 동작 방식은 크게 Listener → Filter Chain → Route → Cluster → Endpoint 순서로 이어지는 파이프라인으로 이해할 수 있습니다.

1. 리스너 (Listener): "어서 오세요, 무엇을 도와드릴까요?" 🚪

리스너는 Envoy가 특정 IP 주소와 포트에서 들어오는 다운스트림(downstream), 즉 클라이언트의 연결을 기다리는 첫 관문입니다.
아파트 정문에서 "몇 동 몇 호 찾아오셨어요?"라고 묻는 경비원 아저씨와 같아요.
Envoy는 여러 개의 리스너를 가질 수 있어서, 예를 들어 80 포트로는 HTTP 요청을, 443 포트로는 HTTPS 요청을 동시에 처리할 수 있습니다.

리스너가 연결을 수락하면, 그 다음 일은 '필터 체인'에게 넘깁니다.

2. 필터 & 필터 체인 (Filters & Filter Chains): "신분증 검사, 방문 목적 확인하겠습니다." 👮

필터는 Envoy의 핵심 기능이 모여있는 곳입니다. 리스너를 통해 들어온 요청을 실제로 처리하고 조작하는 다양한 부품들이죠.
이 필터들이 체인처럼 순서대로 연결되어 요청을 처리하는데, 이걸 필터 체인이라고 부릅니다.

필터는 크게 세 종류로 나눌 수 있습니다.

• 리스너 필터: TCP 연결 자체에 대한 초기 데이터를 처리합니다. (예: TLS 핸드셰이크)
• 네트워크 필터 (L4): TCP 패킷 수준에서 작동합니다. 가장 중요한 네트워크 필터가 바로 `http_connection_manager`인데, 이 녀석이 L4 요청을 L7(HTTP) 요청으로 해석해서 HTTP 필터들이 처리할 수 있게 해줍니다.
• HTTP 필터 (L7): HTTP 요청/응답에 대해 작동합니다. 우리가 생각하는 대부분의 기능이 여기에 해당합니다.
  • 라우터 필터 (Router Filter): 필터 체인의 가장 마지막에 위치하며, 들어온 요청을 어떤 클러스터로 보낼지 결정합니다. (필수!)
  • RBAC 필터 (Role Based Access Control): 역할 기반으로 접근을 제어합니다. "관리자만 이 API에 접근할 수 있어!"
  • JWT 인증 필터: JWT 토큰의 유효성을 검사합니다.
  • 속도 제한 필터 (Rate Limit Filter): "초당 100개 이상의 요청은 안돼!" 와 같은 속도 제한을 겁니다.
  • Gzip 필터: 응답을 압축해서 전송 효율을 높입니다.

이 필터들을 레고 블록처럼 조합해서 원하는 기능을 자유자재로 구현할 수 있다는 것이 Envoy의 강력한 장점입니다.

3. 라우트 (Routes): "손님, 5번 게이트로 가시면 됩니다." 🗺️

HTTP 요청이 필터 체인을 통과하면, `http_connection_manager`는 라우팅 테이블을 보고 이 요청을 어디로 보내야 할지 결정합니다.
요청의 도메인, 경로(path), 헤더 값 등 다양한 조건을 보고 "아, `/api/users`로 들어온 요청은 `user-service-cluster`로 보내야겠군!" 하고 판단하는 거죠.
공항의 관제탑처럼 교통 정리를 해주는 역할입니다.

4. 클러스터 (Clusters): "저기 보이는 A 부서로 가세요." 🏢

클러스터는 논리적으로 동일한 서비스를 제공하는 업스트림(upstream), 즉 백엔드 서버들의 그룹입니다.
예를 들어, `user-service`가 3개의 인스턴스(서버)로 실행되고 있다면, 이 3개를 묶어서 `user-service-cluster`라고 부르는 식이죠.

클러스터는 어떤 로드 밸런싱 정책을 사용할지(Round Robin, Least Request 등), 각 서버의 상태를 어떻게 확인할지(Health Checking), 연결 시간은 얼마나 할지(Timeout) 등의 중요한 정보를 담고 있습니다.

5. 엔드포인트 (Endpoints): "A 부서의 김대리님께 전달하겠습니다." 👨‍💼

엔드포인트는 클러스터에 속한 개별 백엔드 서버의 실제 IP 주소와 포트입니다. 요청이 최종적으로 도달하는 목적지이죠.
이 엔드포인트 목록은 정적으로 설정할 수도 있지만, 보통은 서비스 디스커버리(Service Discovery)를 통해 동적으로 관리됩니다.

실전! Envoy 설정 파일(YAML) 맛보기 👨‍💻

백문이 불여일견! 이제 직접 Envoy 설정 파일을 보면서 위에서 배운 개념들이 어떻게 녹아있는지 확인해봅시다.
가장 간단한 시나리오를 가정해볼게요. 클라이언트가 `localhost:10000`으로 보내는 모든 요청을 `httpbin.org`라는 외부 서비스의 80 포트로 전달(프록시)하는 설정입니다.

아래는 `envoy.yaml` 파일의 내용입니다.

# 이 설정은 정적(static)으로 정의되었음을 의미합니다.
# 동적 설정을 사용하려면 xDS를 가리키는 dynamic_resources를 사용합니다.
static_resources:
  # 1. 리스너 설정: 어디서 요청을 받을 것인가?
  listeners:
  - name: listener_0
    address:
      socket_address:
        address: 0.0.0.0  # 모든 IP에서 들어오는 요청을 받음
        port_value: 10000 # 10000번 포트에서 리스닝
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager # 가장 중요한 필터!
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          # 2. 라우트 설정: 요청을 어디로 보낼 것인가?
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"] # 모든 도메인에 대해 적용
              routes:
              - match:
                  prefix: "/" # 모든 경로("/")에 대해 매칭
                route:
                  # "service_httpbin" 이라는 클러스터로 라우팅
                  cluster: service_httpbin 
          http_filters:
          - name: envoy.filters.http.router # 라우터 필터는 필수!
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  # 3. 클러스터 설정: 목적지 그룹은 무엇인가?
  clusters:
  - name: service_httpbin
    connect_timeout: 0.25s
    type: LOGICAL_DNS # DNS를 통해 엔드포인트를 찾음
    # Note: LOGICAL_DNS는 프로덕션 환경에서는 권장되지 않을 수 있습니다.
    # STRICT_DNS나 EDS를 사용하는 것이 일반적입니다.
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN # 로드 밸런싱 정책은 라운드 로빈
    load_assignment:
      cluster_name: service_httpbin
      # 4. 엔드포인트 설정: 최종 목적지는 어디인가?
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: httpbin.org
                port_value: 80

어때요? 위에서 배운 개념들이 그대로 보이죠?

1. listeners 섹션에서 `0.0.0.0:10000`으로 들어오는 연결을 받도록 설정했습니다.
2. 리스너 안의 filter_chains에는 `http_connection_manager` 필터가 있고, 이 필터는 `local_route`라는 라우팅 규칙을 사용합니다.
3. 라우팅 규칙은 모든(`*`) 도메인의 모든 경로(`/`) 요청을 `service_httpbin`이라는 cluster로 보내라고 지시합니다.
4. clusters 섹션에는 `service_httpbin`이 정의되어 있고, 이 클러스터의 endpoint는 `httpbin.org:80`으로 설정되어 있습니다.

docker run --rm -it -p 10000:10000 -v $(pwd)/envoy.yaml:/etc/envoy/envoy.yaml envoyproxy/envoy:v1.24.0

curl http://localhost:10000/get

Envoy 활용법 1: 엣지 프록시 (API 게이트웨이) 🛡️

이제 Envoy의 구체적인 활용 사례를 살펴봅시다. 첫 번째는 바로 엣지 프록시(Edge Proxy) 역할입니다.
엣지 프록시는 이름 그대로 시스템의 가장 '가장자리(edge)'에서 외부 세계와 내부 마이크로서비스 세계를 연결하는 관문 역할을 합니다.

마이크로서비스들은 시스템 내부에 안전하게 숨어있고, 오직 엣지 프록시인 Envoy만이 외부에 노출되어 모든 요청을 받습니다.
이렇게 하면 어떤 장점이 있을까요?

• 단일 진입점(Single Point of Entry): 클라이언트는 수많은 마이크로서비스의 주소를 일일이 알 필요 없이, 오직 엣지 프록시의 주소만 알면 됩니다. 내부 구조가 바뀌어도 클라이언트는 영향을 받지 않죠.
• 공통 기능 중앙 처리: 인증, 인가, TLS 암호화, 속도 제한, 로깅, 메트릭 수집 등 모든 서비스에 공통적으로 필요한 기능들을 엣지 프록시 한 곳에서 처리할 수 있습니다. 각 서비스는 오직 자신의 비즈니스 로직에만 집중하면 되니 개발이 훨씬 깔끔해집니다.
• 스마트 라우팅: `/users` 요청은 User 서비스로, `/orders` 요청은 Order 서비스로 보내는 등, 요청 경로에 따라 적절한 마이크로서비스로 요청을 분배해줍니다. 카나리 배포나 A/B 테스팅 같은 고급 배포 전략도 엣지 프록시에서 구현할 수 있습니다.

예를 들어, 아래와 같이 라우팅 규칙을 조금 더 복잡하게 만들 수 있습니다.

# ... (리스너 설정은 위와 동일) ...
          route_config:
            name: local_route
            virtual_hosts:
            - name: backend
              domains: ["*"]
              routes:
              # /service1으로 시작하는 요청은 service1_cluster로 라우팅
              - match: { prefix: "/service1" }
                route:
                  cluster: service1_cluster
                  # 라우팅 시 /service1 접두어는 제거
                  prefix_rewrite: "/" 
              # /service2로 시작하는 요청은 service2_cluster로 라우팅
              - match: { prefix: "/service2" }
                route:
                  cluster: service2_cluster
                  prefix_rewrite: "/"
# ... (클러스터 설정에 service1_cluster와 service2_cluster를 추가) ...

이렇게 설정하면 클라이언트는 `http://my-gateway.com/service1/users` 와 같이 요청을 보내지만, Envoy는 이 요청을 받아 `/service1` 부분을 제거하고 `/users` 경로로 `service1_cluster`에 전달해줍니다.
내부 서비스들은 자신이 어떤 경로로 외부에 노출되었는지 전혀 신경 쓸 필요가 없게 되는 것이죠.

Envoy 활용법 2: 서비스 프록시 (사이드카 패턴) 🤝

Envoy의 진정한 힘은 서비스 프록시(Service Proxy) 역할에서 드러납니다. 특히 사이드카(Sidecar) 패턴으로 배포될 때 그 위력이 극대화되죠.

사이드카 패턴이란, 오토바이 옆에 붙어있는 '사이드카'처럼, 우리의 애플리케이션 컨테이너 바로 옆에 Envoy 컨테이너를 함께 배포하는 방식입니다.
애플리케이션(메인 컨테이너)은 외부와 직접 통신하지 않습니다. 애플리케이션이 내보내는 모든 네트워크 트래픽(Egress)은 사이드카 Envoy가 가로채서 대신 보내주고, 애플리케이션으로 들어오는 모든 트래픽(Ingress)도 사이드카 Envoy를 거쳐서 들어옵니다.

이렇게 하면 뭐가 좋을까요? 네트워크와 관련된 모든 골치 아픈 문제들을 애플리케이션 코드에서 완전히 분리할 수 있습니다.

📈 관찰 가능성 (Observability) 확보

모든 서비스의 트래픽이 Envoy를 거치기 때문에, 우리는 일관된 형식의 로그, 메트릭, 추적(Trace) 데이터를 손쉽게 얻을 수 있습니다.
개발자가 서비스마다 Prometheus 메트릭을 노출하고, Jaeger 트레이싱 코드를 심는 수고를 할 필요가 없습니다. Envoy가 알아서 다 해주니까요!

• 메트릭: 요청 성공/실패율, 지연 시간(latency) 등 수많은 통계 데이터를 자동으로 수집하여 Prometheus 같은 모니터링 시스템으로 보낼 수 있습니다.
• 분산 추적 (Distributed Tracing): 요청 하나가 여러 마이크로서비스를 거칠 때, 그 전체 경로와 각 단계에서 걸린 시간을 추적할 수 있습니다. Jaeger나 Zipkin과 연동하여 시스템의 병목 지점을 쉽게 찾아낼 수 있죠.
• 액세스 로그: 모든 요청/응답에 대한 상세한 로그를 원하는 형식으로 남길 수 있습니다.

💪 회복성 (Resilience) 강화

MSA 환경에서는 언제든 특정 서비스에 장애가 발생할 수 있습니다. Envoy는 이런 상황에 대처하는 다양한 회복성 패턴을 기본으로 제공합니다.

• 타임아웃 (Timeouts): 특정 서비스가 응답이 없을 때 무한정 기다리지 않고, 정해진 시간이 지나면 연결을 끊어 전체 시스템의 장애 전파를 막습니다.
• 재시도 (Retries): 일시적인 네트워크 오류 등으로 요청이 실패했을 때, 자동으로 몇 번 더 재시도합니다.
• 서킷 브레이커 (Circuit Breakers): 특정 서비스의 장애율이 일정 수준을 넘어서면, 아예 그 서비스로 가는 트래픽을 일시적으로 차단(회로를 끊음)합니다. 더 이상 장애가 난 서비스에 부하를 주지 않고, 시스템이 스스로 회복할 시간을 벌어주는 똑똑한 기능이죠.
• 속도 제한 (Rate Limiting): 특정 서비스로 가는 요청의 양을 제어하여 과부하를 막습니다.

이 모든 기능이 애플리케이션 코드 수정 없이, Envoy 설정 변경만으로 적용된다는 점이 정말 놀랍지 않나요? 🤯

🔒 강력한 보안 (Security)

서비스 간 통신을 Envoy가 담당하면서, 보안을 한 차원 높은 수준으로 끌어올릴 수 있습니다.
가장 대표적인 것이 바로 mTLS(Mutual TLS)입니다. 클라이언트와 서버가 서로를 인증하고 모든 통신 내용을 암호화하는 방식이죠.
과거에는 서비스마다 인증서를 발급하고 관리하는 것이 매우 번거로웠지만, 서비스 메쉬 환경에서는 컨트롤 플레인이 이 모든 과정을 자동화해주고, Envoy 사이드카들이 알아서 mTLS 통신을 수행합니다. 개발자는 그냥 `http://service-b/` 로 요청을 보냈을 뿐인데, 실제 네트워크 상에서는 모든 것이 암호화되어 안전하게 전달되는 것이죠.

이처럼 각 서비스에 Envoy 사이드카를 배포하고, 컨트롤 플레인을 통해 이들을 중앙에서 관리하는 아키텍처를 우리는 "서비스 메쉬(Service Mesh)"라고 부릅니다. Istio, Linkerd, Consul Connect 등이 대표적인 서비스 메쉬 구현체이며, 이들 모두 내부적으로 Envoy를 데이터 플레인(실제 트래픽을 처리하는 부분)으로 사용하고 있습니다.

한 걸음 더: Envoy의 고급 기능들 ✨

Envoy의 매력은 여기서 끝이 아닙니다. 개발자와 운영자의 삶을 윤택하게 해주는 몇 가지 고급 기능들을 더 소개해 드릴게요.

헬스 체킹 (Health Checking)

Envoy는 단순히 요청을 전달만 하는 것이 아니라, 백엔드 서비스(엔드포인트)들이 정말 건강하게 살아있는지 주기적으로 확인합니다.
능동적 헬스 체크(Active Health Checking)를 통해 주기적으로 `/health` 같은 특정 API를 호출해보고, 정상 응답이 오지 않는 엔드포인트는 로드 밸런싱 대상에서 일시적으로 제외합니다. 덕분에 장애가 발생한 인스턴스로는 트래픽이 전달되지 않죠.
또한, 실제 요청에 대한 응답을 분석하여 비정상적인 패턴을 보이는 엔드포인트를 격리하는 수동적 헬스 체크(Passive Health Checking, 이상치 탐지) 기능도 제공합니다.

다양한 로드 밸런싱 정책

클러스터 내의 여러 엔드포인트에게 트래픽을 분산하는 로드 밸런싱 정책도 다양하게 선택할 수 있습니다.

• ROUND_ROBIN: 가장 기본적인 방식으로, 엔드포인트들에게 순서대로 돌아가며 요청을 보냅니다.
• LEAST_REQUEST: 현재 처리 중인 요청 수가 가장 적은 엔드포인트에게 요청을 보냅니다. 각 요청의 처리 시간이 다를 때 유용합니다.
• RING_HASH: 요청의 특정 정보(예: 헤더 값, 쿠키)를 해싱하여 항상 동일한 엔드포인트로 요청이 가도록 보장합니다. 세션 유지가 필요한 경우에 유용합니다.
• MAGLEV: 구글이 개발한 로드 밸런싱 알고리즘으로, 엔드포인트가 추가되거나 제거될 때 재분배되는 연결을 최소화하여 캐시 효율을 높입니다.

핫 리스타트 (Hot Restart) 🔥

Envoy의 가장 강력한 기능 중 하나입니다. Envoy의 설정을 변경하거나 버전을 업그레이드해야 할 때, 서비스 중단 없이 이를 수행할 수 있게 해줍니다.
새로운 Envoy 프로세스가 기존 프로세스의 소켓을 이어받아 새로운 연결을 처리하기 시작하고, 기존 프로세스는 처리 중이던 연결을 모두 마친 후에야 우아하게(gracefully) 종료됩니다. 이 과정에서 단 한 개의 요청도 유실되지 않기 때문에, 진정한 의미의 무중단 운영이 가능해집니다.

WebAssembly (Wasm)를 이용한 확장

"Envoy의 기본 필터만으로는 부족해! 우리 회사만의 특별한 로직을 추가하고 싶어!" 라고 생각하시나요?
과거에는 C++로 직접 필터를 개발해야 해서 진입 장벽이 높았지만, 이제는 WebAssembly(Wasm)를 통해 Go, Rust, C++ 등 다양한 언어로 커스텀 필터를 개발하고 동적으로 Envoy에 로드할 수 있습니다.
이는 Envoy의 확장성을 무한에 가깝게 만들어주는 혁신적인 기능입니다.

마치며: Envoy, 단순한 프록시를 넘어선 표준으로

지금까지 우리는 MSA 시대의 복잡한 네트워크 문제를 해결하기 위해 등장한 Envoy에 대해 정말 깊이 있게 알아보았습니다.
단순한 프록시 서버로 시작했지만, 이제 Envoy는 클라우드 네이티브 환경의 네트워킹을 정의하는 사실상의 표준(de facto standard)이 되었습니다.

Envoy를 이해한다는 것은 단순히 하나의 툴을 배우는 것을 넘어, 현대적인 분산 시스템이 어떻게 상호작용하고, 어떻게 안정성과 확장성을 확보하는지에 대한 근본적인 원리를 이해하는 것과 같습니다.

물론 오늘 다룬 내용이 전부는 아닙니다. Envoy의 세계는 훨씬 더 깊고 방대하죠.
하지만 오늘 저와 함께한 이 시간이 여러분이 Envoy라는 강력한 도구를 이해하고, 여러분의 프로젝트에 적용해 볼 자신감을 얻는 첫걸음이 되었기를 바랍니다.

혹시 더 깊이 있는 지식이나 실제 프로젝트 적용에 대한 도움이 필요하신가요? 뛰어난 전문가들이 모여있는 지식 공유 플랫폼 재능넷에서 여러분의 다음 스텝을 도와줄 멘토를 찾아보는 것도 좋은 방법이 될 수 있습니다. 이런 Envoy 전문가가 되어 여러분의 능력을 재능넷에서 펼쳐보는 건 어떨까요? 🌟

복잡한 네트워크의 세계, 더 이상 두려워하지 마세요. Envoy와 함께라면 여러분도 MSA 시대의 진정한 마스터가 될 수 있습니다. Happy Hacking! 💻