execonnect 공개: 내부 API를 인터넷에 노출하지 않고 개발 VM에 연결하기

클라우드 개발 환경에서 필요한 내부 서비스만 연결하는 모습을 표현한 생성형 개념 이미지다. 실제 네트워크 구성이나 제품 화면이 아니다.

클라우드 VM의 개발 에이전트가 사설 API를 호출해야 한다고 해서 내부 서버를 인터넷에 공개할 필요는 없다. exe.dev가 2026년 10월 29일 발표한 execonnect는 내부망에서 시작하는 연결로 이 문제를 다룬다. 기존 exe.dev 소개와 달리, 이번 글의 초점은 사설 HTTP 서비스를 연결하는 새 경로와 권한 경계다. 공식 발표

1. 내부 서비스가 연결을 시작한다

execonnect를 서비스에 접근할 수 있는 내부 머신에서 실행한다. 공식 발표에 따르면 Go로 작성된 프로그램이며 userspace WireGuard를 사용한다. exe.dev 쪽 프록시 네트워크가 터널의 상대편이다. 동작 원리

공식 문서는 인바운드 포트·공인 IP·VPN 없이 연결하며, VM은 게시한 endpoint에만 접근한다고 설명한다. HTTP Proxy integration을 거치는 구조다. External Connections 문서

여기서 중요한 구분이 있다. 서비스가 인터넷에 공개되지 않는다는 것과 에이전트의 모든 요청이 안전하다는 것은 다른 문제다. 연결된 API에 삭제 기능이 있다면 네트워크 연결만으로 그 위험이 사라지지 않는다. 읽기 전용 API부터 연결하는 것을 권한다. 이는 이 글의 운영 제안이다.

2. 연결·endpoint·VM 연결 대상을 나눠 설정한다

다음은 공식 문서를 바탕으로 한 설정 예시다. 실제 설치나 계정 연결은 실행하지 않았다. 주소와 VM 이름은 예시이며 환경에 맞게 바꿔야 한다.

먼저 exe.dev의 Integrations 화면에서 External Connection을 만든다. 내부 머신에 공식 설치 절차를 적용하고, 화면에서 받은 일회용 enrollment 명령으로 등록한다. 토큰을 저장소나 문서에 남기지 않는다.

등록된 내부 머신에서 endpoint를 추가한다.

endpoint URL에는 경로를 넣지 않는다. IP 주소를 사용했다면 TLS 인증서 검증에 사용할 서버 이름을 명시한다. 위 api.internal도 실제 인증서 이름으로 바꿔야 한다. Endpoint 규칙

이후 Integrations 화면에서 해당 endpoint의 Add HTTP proxy를 선택하고 사용할 VM에 연결한다. 예를 들어 integration 이름을 internal-api로 정했다면 연결된 VM에서 다음처럼 호출한다.

3. 프록시 인증과 애플리케이션 권한을 구분한다

HTTP Proxy integration은 요청 헤더 주입과 basic auth를 지원한다. 인증정보를 담은 헤더는 서버 측에 저장되며 VM에서 보이지 않는다고 문서에 설명되어 있다. HTTP Proxy 문서

다만 키를 볼 수 없는 VM도 연결된 integration으로 요청은 보낼 수 있다. 따라서 비밀값 은닉만 확인하지 말고, 그 인증정보가 허용하는 작업을 함께 검토해야 한다.

운영 시 다음 정책을 권한다.

• 처음에는 테스트용 VM 하나와 읽기 전용 endpoint 하나만 연결한다.

• 팀 공유는 필요한 사람과 VM의 범위를 정한 뒤 적용한다.

• 쓰기·삭제 API는 별도 권한 또는 승인 경로로 분리한다.

• 요청 로그에는 토큰과 개인정보를 남기지 않는다.

경로 재작성도 접근 제한과 혼동하면 안 된다. HTTP Proxy의 --strip-prefix는 경로를 바꾸는 기능이며, prefix 밖의 경로도 그대로 전달될 수 있다. 특정 경로만 허용하려면 대상 서비스의 인가 정책을 별도로 검증해야 한다. 경로 재작성 동작

4. Online 표시 다음에 확인할 것

공식 문서의 Online은 연결 상태다. 요청 실패 시 내부 머신에서 대상 서비스에 직접 접근할 수 있는지도 확인하도록 안내한다. 상태 점검

추가로 다음 순서의 검증을 제안한다.

1. 내부 머신에서 health endpoint와 TLS 검증이 정상인지 확인한다.

2. 허용한 VM에서 같은 요청을 보내고 상태 코드·응답 내용을 비교한다.

3. 연결하지 않은 VM의 접근이 차단되는지 확인한다.

4. 읽기 전용 권한으로 변경 요청이 거부되는지 시험한다.

5. 연결 회수 후 더 이상 요청이 통과하지 않는지 확인한다.

이 글은 공식 공개 문서 검토와 운영 설계 제안을 구분해 정리했다. 실제 터널의 지연시간·안정성·차단 결과를 측정하지 않았다.

execonnect의 실용적 가치는 사설 서비스를 공개 서버로 바꾸지 않고 개발 환경에 연결할 수 있다는 데 있다. 도입의 완료 조건은 연결 성공 하나가 아니라, 필요한 요청만 통과하고 불필요한 요청은 거부되는지까지 확인하는 것이다.