Cursor/Copilot에 어떤 VPN을 선택할지는 속도 측정 페이지의 최고 속도보다 코드 자동 완성, 대화, 코드 인덱싱 중 연결을 계속 유지할 수 있는지가 더 중요합니다. AI 코딩 도구가 전송하는 텍스트 자체는 크지 않지만, 한 번의 요청에 현재 파일과 관련 코드, 대화 컨텍스트가 함께 포함될 수 있습니다. 회선이 잠시 끊기면 화면이 생성 중인 상태에서 멈추거나 요청을 다시 보내게 되며, 이미 전송한 컨텍스트를 다시 처리해야 할 수 있습니다.
개발 환경에는 웹 탐색보다 변수가 많습니다. 편집기, 확장 프로그램, 터미널, Git, 패키지 관리자가 같은 네트워크 설정을 사용하지 않을 수 있기 때문입니다. 브라우저에서 서비스 페이지가 열린다고 해서 편집기 확장 프로그램이나 터미널이 프록시를 사용한다는 뜻은 아닙니다. 이 글에서는 한 번의 다운로드 속도가 아니라 연결 유지, 사용량이 많은 시간대의 변동, 프로토콜 호환성, 분할 라우팅, 터미널 설정 상속 관계를 기준으로 점검합니다.
AI 코딩 도구에 실제로 필요한 네트워크
일반 웹페이지는 로딩이 끝난 뒤 연결이 잠시 흔들려도 이미 표시된 내용을 대체로 읽을 수 있습니다. 하지만 AI 대화와 코드 자동 완성은 다릅니다. 클라이언트가 컨텍스트를 보내면 서버가 결과를 스트리밍 방식으로 조금씩 반환합니다. 이 과정에서는 왕복 연결의 안정성, 패킷의 지속적인 도착, 연결 중간의 리셋 여부가 중요합니다. 최고 대역폭은 높지만 지연 변동이 큰 회선보다, 대역폭은 적당해도 연결이 안정적인 회선이 실제 사용감에서 더 나을 수 있습니다.
Cursor의 채팅, 코드 편집, 인덱싱 기능은 모두 하나의 요청으로 처리되지 않으며, GitHub Copilot도 편집기 확장 프로그램·인증·추천 요청이 함께 작동합니다. 구체적인 전송 방식은 클라이언트 버전과 서비스 변경에 따라 달라질 수 있지만 판단 기준은 같습니다. 인증 요청이 완료되고, HTTPS 트래픽이 지속적으로 전달되며, 편집기 하위 프로세스가 올바른 프록시와 DNS 결과를 받아야 합니다.
| 확인 항목 | 일반적인 증상 | 가능성이 높은 원인 | 대응 방향 |
|---|---|---|---|
| 로그인 및 인증 | 웹 인증은 완료됐지만 편집기에는 로그인되지 않음 | 콜백, 시스템 프록시 또는 편집기 프로세스가 같은 경로를 사용하지 않음 | 시스템 프록시와 클라이언트 인증 상태를 다시 확인 |
| 인라인 자동 완성 | 추천이 가끔만 표시되고 대기 시간이 일정하지 않음 | 회선 지연 변동, DNS 조회 변동 또는 연결 재수립 | 안정적인 회선을 비교하고 원격 DNS를 확인 |
| 장시간 대화 생성 | 콘텐츠 생성이 중간에 멈춤 | 장시간 연결이 리셋됐거나 현재 네트워크에서 프로토콜이 제한됨 | 회선 유형을 바꾸거나 TCP 계열 프로토콜 사용 |
| 터미널 및 Git | 편집기는 작동하지만 터미널 요청은 실패 | 터미널이 시스템 프록시 설정을 상속하지 않음 | 환경 변수를 설정하거나 도구 자체의 프록시 구성 사용 |
| 코드 인덱싱 | 작은 파일은 정상이나 대규모 프로젝트에서 더 자주 멈춤 | 지속적인 요청 중 패킷 손실, 절전 또는 네트워크 전환 발생 | 클라이언트를 계속 실행하고 절전 및 네트워크 전환을 점검 |
‘실측’ 결과는 한 번의 지연 시간이나 다운로드 결과만 잘라 보여서는 안 됩니다. 같은 기기·네트워크·개발 작업에서 회선을 비교하는 편이 더 정확합니다. 인라인 자동 완성을 연속으로 실행하고, 여러 파일 컨텍스트가 포함된 대화를 시작한 뒤, 통합 터미널에서 원격 요청을 실행해 보세요. 반복 재시도나 생성 중단이 발생하는지, 편집기와 터미널 결과가 일치하는지 확인하면 최고 속도보다 실제 개발 환경에 가까운 결과를 얻을 수 있습니다.
직결·중계·IEPL 전용 회선 선택법
직결 회선은 로컬 네트워크에서 공용 인터넷으로 바로 나가 출구 노드로 연결되는 방식으로, 경로 구조가 비교적 단순합니다. 중간 단계가 적어 국내 통신사 라우팅이 양호하면 응답이 빠르고 직접적이라는 장점이 있습니다. 반면 국제 인터넷 경로는 지역·통신사·사용량이 많은 시간대에 따라 달라집니다. 낮에는 정상인데 밤에 변동이 커진다면 대개 편집기 문제가 아니라 공용 인터넷 경로 품질이 변한 것입니다.
중계 회선은 트래픽을 더 적합한 진입 지점으로 먼저 보낸 뒤 최적화된 경로를 통해 출구로 전달합니다. 전달 단계가 늘어나지만 품질이 낮은 공용 인터넷 구간을 우회할 수 있습니다. 개발 환경에 중계 회선이 적합한지는 지리적 거리만으로 판단할 수 없습니다. 로컬에서 진입 지점까지, 진입 지점에서 출구까지, 출구에서 대상 서비스까지 각 구간이 조화를 이루는지 확인해야 합니다. 진입 지점이 가깝다고 전체 경로가 반드시 짧은 것은 아닙니다.
IEPL 전용 회선은 주요 국제 구간을 보다 통제하기 쉬운 전송 경로에 배치하는 경우가 많아, 사용량이 많은 시간대의 지연 변동을 관리하기 쉽습니다. 장시간 대화, 원격 저장소, 개발 문서를 동시에 이용해야 하는 환경에 적합합니다. 다만 ‘전용 회선’이라고 해서 기기부터 대상 서비스까지 모든 요청이 폐쇄형 네트워크를 통과하는 것은 아닙니다. 로컬 접속과 출구에서 대상 서비스까지의 구간도 최종 사용감에 영향을 줍니다. 선택할 때는 실제 연결 유지 상태를 기준으로 판단하세요.
- ✅ 평소 개발하는 시간대에 테스트하고, 네트워크가 한산할 때만 비교하지 마세요.
- ✅ 편집기 대화, 인라인 자동 완성, 통합 터미널을 함께 테스트해 같은 안정적인 경로를 사용하는지 확인하세요.
- ✅ 먼저 프로토콜을 고정한 뒤 회선을 바꾸세요. 여러 변수를 동시에 변경하면 원인을 판단하기 어렵습니다.
- ✅ 체감 속도만 기록하지 말고 중단, 재시도, 인증 만료 현상도 기록하세요.
- ❌ 노드 이름만으로 회선 품질을 판단하지 마세요. 같은 지역이라도 서로 다른 경로를 사용할 수 있습니다.
- ❌ 대용량 파일 다운로드 결과를 스트리밍 생성 경험과 동일하게 보지 마세요.
업무 네트워크에서 특정 직결 경로가 계속 안정적이라면 직결을 사용해 전달 단계를 줄일 수 있습니다. 사용량이 많은 시간대에 생성이 자주 멈춘다면 중계 회선을 비교해 볼 가치가 있습니다. 국제 공용 인터넷의 변동이 업무 흐름에 계속 영향을 준다면 IEPL 전용 회선을 추가로 테스트할 수 있습니다. 네트워크 환경과 무관한 정답은 없으며, 회선 선택은 로컬 접속 환경과 실제 개발 시간대를 바탕으로 해야 합니다.
Shadowsocks·VMess·Trojan·VLESS의 차이
프로토콜은 클라이언트가 트래픽을 캡슐화하고 전송하는 방식을 결정하지만, 프로토콜 이름만으로 회선 품질을 대신할 수는 없습니다. Shadowsocks는 가벼운 프록시 프로토콜로 클라이언트 지원 범위가 넓으며, 네트워크 환경이 비교적 정상이고 추가 처리를 줄이고 싶은 경우에 적합합니다. 올바른 암호화 방식·서버 설정·클라이언트 구현과 함께 사용해야 하며, ‘가볍다’는 이유만으로 모든 네트워크에서 더 빠르다고 판단해서는 안 됩니다.
VMess는 여러 전송 방식을 지원하는 클라이언트 생태계에서 흔히 사용되며, 기존 구독과 호환할 때도 자주 접하게 됩니다. VLESS는 신원 확인과 데이터 암호화의 역할을 분리하며 TLS 또는 다른 보안 전송 방식과 함께 사용하는 경우가 많습니다. 실제 성능은 전송 계층·서버 배포·클라이언트 버전·회선에 따라 달라지므로, 프로토콜 핵심 이름과 완성된 연결 구성을 혼동해서는 안 됩니다.
Trojan은 일반적으로 TLS 연결 위에서 실행되며 TCP 호환성이 필요한 네트워크에 적합합니다. UDP가 제한되거나 QUIC에 비우호적이고 네트워크 전환이 잦은 업무 환경에서는 TCP 계열 방식이 안정적인 기준선이 되기 쉽습니다. 다만 하위 네트워크의 패킷 손실이 뚜렷하면 TCP의 재전송과 혼잡 제어로 인해 스트리밍 응답이 연속적으로 대기할 수 있습니다.
Hysteria2와 TUIC는 모두 QUIC와 UDP를 기반으로 하며, 지연 시간이 길고 패킷 손실이 있는 경로에서 전송 효율을 높이는 것을 목표로 합니다. 네트워크에서 UDP가 허용되고 경로 품질이 적합하면 전송을 더 빠르게 복구해 하나의 데이터 스트림 대기로 전체 요청이 지연되는 현상을 줄일 수 있습니다. 그러나 일부 업무·공용 네트워크와 라우터는 UDP를 제한합니다. 이때 연결 실패, 불안정한 품질, 또는 TCP로 전환한 뒤 오히려 낮아지는 안정성이 나타날 수 있습니다.
| 프로토콜 | 전송 특성 | 우선 테스트하기 좋은 환경 | 주의할 점 |
|---|---|---|---|
| Shadowsocks | 가벼운 프록시, 폭넓은 클라이언트 지원 | 일반 가정용 네트워크와 일반적인 개발 접속 | 구체적인 보안성과 성능은 암호화 및 배포 방식에 따라 달라짐 |
| VMess | 다양한 전송 방식 조합 가능 | 기존 구독 및 클라이언트 설정과의 호환성 확인 필요 | 설정 계층이 많아 문제 해결 시 단계별 확인 필요 |
| Trojan | TLS 기반 TCP 연결 | UDP가 제한되거나 호환성이 중요한 업무 네트워크 | 하위 네트워크에서 패킷 손실이 발생하면 연속 대기가 나타날 수 있음 |
| VLESS | 핵심 구성이 간결하며 보안 전송과 함께 사용하는 경우가 많음 | 클라이언트와 서버 모두 해당 조합을 지원해야 함 | 전송 계층과 분리해 단독으로 비교할 수 없음 |
| Hysteria2 | QUIC 및 UDP 기반 | UDP를 사용할 수 있고 국제 경로에 변동이 있는 환경 | 제한된 네트워크에서는 차단되거나 품질이 낮아질 수 있음 |
| TUIC | QUIC 및 UDP 기반 | 빠른 복구와 다중 스트림 전송이 필요한 환경 | 클라이언트 구현과 UDP 경로도 동일하게 중요함 |
실용적인 선택 순서는 호환성이 좋은 TCP 계열 연결로 기준선을 먼저 만든 다음, UDP 사용 가능 여부를 확인하고 Hysteria2 또는 TUIC를 비교하는 것입니다. 가정용 네트워크에서 QUIC 계열 프로토콜이 잘 작동하다가 업무 네트워크에서 자주 끊긴다면 편집기를 반복해서 재설치하기보다 UDP 경로와 네트워크 정책을 먼저 의심하세요. 프로토콜을 바꾼 뒤에는 DNS와 분할 라우팅도 다시 확인해야 합니다. 클라이언트가 다른 네트워크 스택을 사용할 수 있기 때문입니다.
분할 라우팅 규칙과 DNS 누출이 결과에 미치는 영향
전역 프록시는 지원되는 대부분의 트래픽을 같은 출구로 보내 문제를 찾기 쉽고, 서비스 사용 가능 여부를 처음 확인할 때 적합합니다. 하지만 개발 환경에는 로컬 서비스·LAN 기기·코드 저장소·패키지 관리자·AI API가 함께 존재하므로, 장기간 전역 전달을 사용하면 국제 접속이 필요 없는 요청까지 우회할 수 있습니다. 분할 라우팅은 도메인·주소·프로세스에 따라 경로를 정해 효율적이지만, 규칙이 누락되면 ‘웹페이지는 정상인데 확장 프로그램은 실패하는’ 분리된 상태가 발생합니다.
AI 코딩 도구의 도메인과 서비스 의존성은 변경될 수 있으므로, 지나치게 좁은 도메인 목록을 수동으로 관리하면 인증·모델 API·정적 리소스를 놓치기 쉽습니다. 먼저 전역 모드로 문제를 찾아 기능이 정상인지 확인한 뒤 규칙 모드로 전환하는 편이 안전합니다. 분할 라우팅을 적용할 때는 관리되는 규칙 세트를 우선 사용하고, 클라이언트 연결 로그에서 편집기 프로세스와 관련 요청이 실제로 프록시 규칙을 적용받았는지 확인하세요.
DNS 누출은 여기서 단순한 개인정보 보호 문제가 아니라 사용 가능성에도 직접 영향을 줍니다. 도메인 조회는 로컬 DNS가 처리하면서 실제 연결은 원격 출구를 통해 이루어지면 로컬 조회 결과가 출구 지역과 맞지 않거나, 접속할 수 없는 주소가 반환될 수 있습니다. 로그인 페이지는 열리지만 API 연결이 실패하거나, 같은 회선이 때로는 정상이고 때로는 시간 초과되는 식으로 나타날 수 있습니다.
원격 DNS, 암호화 DNS 또는 클라이언트의 프록시 DNS를 사용하면 조회 경로 불일치를 줄일 수 있습니다. TUN 모드에서는 클라이언트가 시스템 DNS를 인계받는지, 규칙 모드에서 DNS 조회와 대상 연결이 같은 경로를 사용하는지도 확인해야 합니다. Fake IP는 일부 클라이언트가 도메인 요청을 가로채는 방식으로, 도메인을 내부 주소에 매핑한 뒤 클라이언트가 대상 도메인을 복원해 규칙을 적용합니다. LAN 애플리케이션이나 개발 도구가 호환되지 않는다면 모든 DNS 인계를 끄기보다 예외 규칙을 사용하세요.
- 중복 실행 중인 프록시 도구를 먼저 종료해 시스템 프록시, TUN, 브라우저 확장 프로그램이 서로 설정을 덮어쓰지 않게 하세요.
- 전역 모드에서 로그인·자동 완성·대화·터미널 요청이 모두 완료되는지 확인하세요.
- 클라이언트 연결 로그를 확인해 편집기 주 프로세스, 확장 프로세스, 대상 도메인이 실제로 프록시를 통과하는지 확인하세요.
- 분할 라우팅 모드로 전환하고 로컬 서비스와 LAN은 직접 연결한 뒤 같은 작업 흐름을 다시 테스트하세요.
- 간헐적으로 DNS 조회가 실패한다면 DNS를 클라이언트가 인계받는지, 조회 경로와 연결 경로가 일치하는지 확인하세요.
- 유선·무선 네트워크 또는 절전 상태에서 복귀한 뒤 자동 완성을 다시 실행해 기존 연결이 정상적으로 재수립되는지 확인하세요.
터미널 프록시는 시스템 설정만으로 판단할 수 없습니다
Cursor의 통합 터미널은 본질적으로 Shell과 각 명령줄 도구가 네트워크를 처리합니다. 시스템 프록시가 켜져 있어도 Git, curl, Node.js 런타임, 패키지 관리자가 반드시 이를 상속하는 것은 아닙니다. 어떤 도구는 환경 변수를 읽고, 어떤 도구는 자체 설정을 사용하며, HTTP 프록시만 지원해 SOCKS 엔드포인트를 직접 인식하지 못하는 도구도 있습니다. 편집기 대화는 정상인데 의존성 설치가 실패한다면 먼저 이 계층을 확인하세요.
먼저 프록시 클라이언트에서 실제로 제공하는 로컬 HTTP 프록시 주소를 복사한 뒤 현재 Shell의 환경 변수에 저장하세요. 아래 방식은 클라이언트 포트에 고정되지 않으며, 변수 값은 실행 중인 프록시 클라이언트가 제공해야 합니다:
export LOCAL_PROXY="$(proxy-client-command)"
export HTTP_PROXY="$LOCAL_PROXY"
export HTTPS_PROXY="$LOCAL_PROXY"
env | grep -i proxy
git config --global --get http.proxy예시의 proxy-client-command는 프록시 클라이언트가 제공하는 주소 조회 명령을 뜻합니다. 클라이언트에 명령줄 인터페이스가 없다면 설정 화면에서 로컬 HTTP 프록시 주소를 직접 복사해 LOCAL_PROXY에 할당하세요. 다른 기기의 포트를 그대로 사용하지 마세요. 로컬 리스닝 방식이 다를 수 있습니다. 환경 변수는 현재 Shell과 그 하위 프로세스에만 적용되며, 바탕 화면 아이콘으로 실행한 편집기가 터미널의 변수를 상속한다는 보장도 없습니다.
Git은 환경 변수를 읽을 수도 있고 자체 프록시 설정을 사용할 수도 있습니다. 문제를 해결할 때는 서로 다른 주소를 두 곳에 동시에 남겨 두지 마세요. npm, pnpm과 기타 패키지 관리자는 환경 변수·사용자 설정 파일·프로젝트 설정의 영향을 동시에 받을 수 있습니다. 요청이 여전히 잘못된 경로로 나간다면 먼저 유효한 설정을 확인한 뒤 더 이상 사용하지 않는 기존 프록시를 정리하세요. SOCKS 프록시 지원 여부는 도구 구현에 따라 다르므로 SOCKS 주소를 HTTP 주소처럼 입력해서는 안 됩니다.
또한 컨테이너, 원격 개발 환경, 하위 시스템이 독립적인 네트워크 네임스페이스를 사용한다면 호스트의 루프백 주소가 프록시 클라이언트를 가리킨다고 보장할 수 없습니다. 해당 환경에서 호스트에 접근 가능한 주소를 사용하거나 클라이언트가 명시적으로 제공하는 LAN 리스닝 기능을 사용하세요. 리스닝을 켜기 전에는 접근 범위를 이해하고 시스템 방화벽을 설정해야 하며, 로컬 프록시 포트를 신뢰할 수 없는 네트워크에 노출하지 마세요.
- ✅ 브라우저·편집기·확장 프로세스·터미널을 각각 검증하세요. 서로 대신할 수 없습니다.
- ✅ 환경 변수 이름, 프로토콜 유형, 클라이언트의 로컬 리스닝 방식이 서로 맞는지 확인하세요.
- ✅ 설정을 변경한 뒤 관련 프로세스를 다시 시작해 새 환경 변수가 실제로 적용되게 하세요.
- ✅ 설정 파일만 보지 말고 도구의 설정 조회 명령으로 최종 값을 확인하세요.
- ❌ 서로 다른 포트를 가리키는 프록시 설정을 여러 개 동시에 유지하지 마세요.
- ❌ 호스트의 루프백 주소가 컨테이너나 원격 환경에서 기본적으로 호스트 주소라고 간주하지 마세요.
Windows·macOS·Linux 클라이언트 차이
Windows에서는 시스템 프록시와 TUN을 함께 사용하는 경우가 많습니다. 시스템 프록시는 시스템 설정을 따르는 데스크톱 애플리케이션에 적합하지만 일부 명령줄 프로그램과 자체 네트워크 스택을 사용하는 앱은 이를 우회할 수 있습니다. TUN 모드는 적용 범위가 넓은 대신 가상 머신·컨테이너 네트워크·보안 소프트웨어와 라우팅 충돌을 일으키기 쉽습니다. 문제가 생기면 라우팅 테이블에 다른 네트워크 도구가 남긴 가상 네트워크 어댑터나 기본 경로가 없는지 먼저 확인하세요.
macOS의 시스템 프록시는 네트워크 서비스별로 적용되므로 무선 네트워크에서 유선 네트워크로 전환하면 설정이 같지 않을 수 있습니다. 터미널 프로그램도 그래픽 인터페이스의 프록시 설정을 반드시 읽는 것은 아닙니다. TUN 클라이언트는 일반적으로 시스템 네트워크 확장 권한이 필요합니다. 권한이 꺼지면 시스템 프록시만 계속 작동해 브라우저는 연결되지만 다른 프로세스에서 문제가 발생할 수 있습니다.
Linux 데스크톱 환경의 시스템 프록시 지원은 통일되어 있지 않으며, 명령줄 도구는 환경 변수나 애플리케이션 설정에 더 의존합니다. 컨테이너·원격 SSH 개발·그래픽 편집기를 사용할 때는 프록시 설정이 로컬·원격·컨테이너 중 어디에 있는지 확인해야 합니다. 가장 중요한 원칙은 요청이 시작된 환경에서 DNS·라우팅·프록시 변수를 점검하는 것입니다.
구독 링크는 호환 클라이언트에 노드와 프로토콜 설정을 제공하는 역할을 합니다. 접근 자격 증명으로 취급하고 공개 질문, 코드 저장소, 스크린샷, 온라인 변환 페이지에 붙여 넣지 마세요. 클라이언트로 가져올 때는 신뢰할 수 있는 클라이언트에 내장된 구독 기능을 사용하고 출처를 확인하세요. 구독을 업데이트하면 노드 설정은 새로 고쳐지지만 시스템 프록시 충돌, 잘못된 분할 라우팅, 터미널 환경 변수까지 자동으로 해결되지는 않습니다.
구독 가져오기가 성공했다는 것은 클라이언트가 설정을 읽었다는 뜻일 뿐, 모든 애플리케이션이 해당 클라이언트를 통해 인터넷에 연결된다는 의미는 아닙니다. 최종적으로 실제 개발 요청을 실행해 라우팅이 적용되는지 확인해야 합니다.
재현 가능한 가속 실측과 최종 선택
재현 가능한 결과를 얻으려면 테스트 중 기기·로컬 네트워크·편집기 버전·개발 작업을 고정해야 합니다. 후보 회선 하나를 선택해 로그인과 인증을 완료한 뒤 인라인 자동 완성, 장시간 대화, 코드 수정, 통합 터미널을 연속으로 사용하세요. 요청할 때마다 노드를 바꾸지 마세요. 기존 연결이 아직 해제되지 않았다면 관찰된 오류가 새 회선이 아니라 전환 과정에서 발생했을 수 있습니다.
테스트의 핵심은 첫 응답이 원활하게 도착하는지, 긴 응답이 중간에 멈추는지, 연속 자동 완성에서 속도가 크게 오르내리는지, 편집기가 절전에서 복귀한 뒤 다시 연결되는지, 터미널의 원격 저장소와 패키지 소스 접속이 편집기와 일치하는지입니다. 클라이언트에서 연결 로그를 제공한다면 연결 리셋·DNS 조회 실패·규칙 적용 내역을 기록하세요. 이런 정보가 막연한 ‘끊김’보다 문제 위치를 파악하는 데 유용합니다.
실제 선택 순서로 보면 안정적인 직결은 복잡도가 낮은 방식의 기준이 될 수 있습니다. 사용량이 많은 시간대에 공용 인터넷 경로가 흔들리면 중계를 테스트하고, 국제 연결이 장시간 연결에 계속 영향을 줄 때 IEPL 전용 회선을 비교하세요. 프로토콜은 먼저 TCP 기준선을 만든 뒤 UDP 사용이 가능할 때 Hysteria2 또는 TUIC를 테스트합니다. 회선과 프로토콜을 확인한 다음 분할 라우팅 규칙을 좁히고 터미널 상속 문제를 처리해야 하며, 순서를 바꾸지 않는 것이 좋습니다.
여러 개발 기기 사이를 오가야 한다면 구독 업데이트 방식과 분할 라우팅 원칙도 통일해야 합니다. 단, 로컬 경로·리스닝 주소·기존 포트가 포함된 설정 파일을 그대로 복사하지 마세요. 플랫폼마다 클라이언트 권한, 시스템 프록시, TUN 상태, 터미널 변수를 다시 확인해야 합니다. 이렇게 해야 우연히 한 번 작동하는 연결이 아니라 지속적으로 문제를 해결하고 재테스트할 수 있는 개발 네트워크 구성을 만들 수 있습니다.