기업 환경을 위한 Zero Trust 원격접속 플랫폼 구축 - 1
Teleport, Tailscale, Jump Server
Jun 11, 2026
1. 왜 원격접속 플랫폼이 필요했을까?
원격접속은 개발자에게 너무나 익숙한 기술입니다. VPN에 접속하고 SSH를 실행하면 끝.
저 역시 오랫동안 그렇게 생각했습니다.
어느정도 보안 관리에 대한 책임이 생긴, 운영하는 입장이 되니 원격접속은 전혀 다른 문제였습니다. 개발자가 원하는 것은 "접속" 이었습니다. 반면 운영자는 "누가, 언제, 왜 접속했는가" 를 알고 싶어 했고, 보안 담당자는 "정말 승인된 사람만 접속하고 있는가" 를 확인하고 싶어 했습니다.
SSH는 이 질문들에 답해주지 못합니다. VPN도 마찬가지입니다.
이 문제를 본격적으로 고민하게 된 계기는, 문제를 해결하기 위해선 현장에 가야하는데, 정작 현장에 가서는 내부망에 접근해야 하는 아이러니한 상황이 발생했고 이에 따라 보안이 엄격한 내부망 환경에 접근할 필요가 발생했습니다.
개발자는 장애를 빠르게 대응하기 위해 원격접속이 필요했습니다. 반대로 보안 담당자는 외부에서 내부망으로 들어오는 모든 접근을 최소화하고 싶어 했습니다. 결국 개발 편의성과 보안이라는 두 가치가 계속 충돌하기 시작했습니다.
처음에는 VPN이 가장 현실적인 해결책처럼 보였습니다. 하지만 조금 더 생각해 보니 VPN은 연결은 해결해 주지만 관리는 해결해 주지 못했습니다.
- 누가 접속했는지,
- 왜 접속했는지,
- 승인된 사용자인지,
- 언제까지 접속을 허용해야 하는지.
이런 질문에는 여전히 답하기 어려웠습니다. 그래서 저희는 VPN 하나를 더 도입하는 대신, 관리 가능한 원격접속 플랫폼을 직접 만들게 됐습니다.
누군가에게 중요한 것은 "접속할 수 있는가" 였고, 또 다른 누군가에게 중요한 것은 "누가 접속하는가" 였습니다. 이 프로젝트는 그 두 질문을 동시에 해결하는 것에서부터 시작되었습니다.
2. 요구사항부터 다시 정의하기
원격접속 플랫폼을 만든다고 했을 때 가장 먼저 한 일은 요구사항을 정리하는 것이었습니다. 그런데 재미있게도 요구사항은 명확하면서도 모호했습니다.
- 개발자는 SSH만 되면 된다고 했고,
- 또 다른 개발자는 VSCode Remote 정도는 지원되어야 실제 업무에 사용할 수 있다고 했습니다.
- 반면 운영자는 누가 언제 접속했는지 기록이 남아야 한다고 했고,
- 보안 담당자는 승인받은 사용자만 최소 권한으로 접근해야 한다는 점을 가장 중요하게 생각했습니다.
여기서 더 어려웠던 점은 기존 환경을 크게 바꾸면 안 된다는 조건이었습니다.
기존 네트워크 환경을 수정하여 새로운 네트워크 환경을 구축하거나, 사용자들에게 전혀 다른 접속 방식을 강요하는 것은 현실적인 선택지가 아니었습니다.
결국 요구사항을 정리하면 다음과 같았습니다.
- SSH 중심의 개발 환경 지원
- VSCode Remote 지원
- Zero Trust 기반의 인증 체계
- Session Recording 및 Audit
- 최소 권한(Least Privilege)
- 기존 네트워크 구조를 최대한 유지
- 사용자가 새로운 사용법을 배우지 않아도 될 것
이 목록을 보면서 한 가지를 깨달았습니다.
이건 SSH 프로그램을 선택하는 문제보다는 여러 사람의 이해 관계를 만족시키는 절차에 가깝다고 느끼게 됐는데, 결국 개발자의 생산성과 운영의 편의성, 그리고 보안까지 모두 만족시키는 구조를 설계해야 하는 문제였습니다.
그래서 그때부터 "어떤 제품이 가장 좋은가?"보다 "어떤 구성이 우리 환경에 가장 잘 맞는가?"를 중점적으로 고민하기 시작했습니다.
3. Silver bullet 은 없다.
요구사항을 정리한 뒤에는 자연스럽게 하나의 질문으로 이어졌습니다.
그렇다면 어떤 도구를 사용해야 할까?
가장 먼저 검토한 것은 JumpServer였습니다.
권한 관리와 운영 기능은 상당히 인상적이었습니다. 왜 많은 기업에서 Bastion Host로 사용하는지 충분히 이해할 수 있었습니다.
하지만 실제 사용 환경에서는 몇 가지 아쉬운 점이 있었습니다. 저희가 중요하게 생각했던 VSCode Remote 활용에 제약이 있었고, SSH 중심의 개발 환경을 그대로 유지하기에는 다소 무겁다는 느낌을 받았습니다.
다음으로 Guacamole도 구축해 보았습니다.
브라우저만으로 RDP와 SSH를 사용할 수 있다는 점은 분명 매력적이었습니다. 별도의 클라이언트 설치 없이 접속할 수 있다는 것도 장점이었습니다.
하지만 실제 개발자들의 업무 방식과는 조금 거리가 있었습니다.
대부분의 개발자는 원격 데스크톱보다 SSH와 VSCode Remote를 사용하고 있었고, 당시 오피스 네트워크 환경에서는 기대했던 수준의 성능도 나오지 않았습니다. 결국 저희가 원하는 개발 경험을 제공하기에는 한계가 있었습니다.
그다음으로 Tailscale을 검토했습니다.
Mesh VPN이라는 개념은 상당히 인상적이었습니다. 방화벽이나 NAT를 크게 신경 쓰지 않아도 장치 간 연결이 가능했고, 사용자 경험도 매우 좋았습니다.
Mesh VPN이란?
Mesh VPN은 중앙 VPN 서버를 거치지 않고, 각 장치들이 서로 직접(Peer-to-Peer) 연결되는 VPN입니다.
기존 VPN이 모든 트래픽이 VPN 서버를 거치는 것에 비해, Mesh VPN은 컨트롤 서버가 인증과 장치 정보를 관리하지만 데이터는 가능한 장치끼리 직접 전송됩니다.
하지만 운영 관점에서는 또 다른 고민이 생겼습니다.
연결은 되는데, 접속은 어떻게 관리하지?
Tailscale은 네트워크 연결은 매우 잘 해결해 주었습니다.
하지만 누가 접속했는지, 언제 접속했는지, MFA는 어떻게 적용할 것인지, 세션을 어떻게 기록할 것인지와 같은 운영 기능은 별도의 고민이 필요했습니다.
이 질문의 답을 찾던 중 Teleport를 도입하게 되었습니다.
Teleport란?
Teleport는 SSH, Kubernetes, 데이터베이스 등 다양한 리소스에 대해 Zero Trust 기반의 접근 제어를 제공하는 원격접속 플랫폼입니다.
인증(MFA), 권한 관리(RBAC), 세션 기록(Session Recording), 감사 로그(Audit) 등을 하나의 플랫폼에서 관리할 수 있도록 설계되어 있습니다.
Teleport를 사용하면서 가장 인상적이었던 부분은 SSH 기능 자체보다 운영 기능이었습니다.
- MFA
- RBAC(Role-Based Access Control)
- Session Recording
- Audit Log
기업 환경에서 요구하는 기능들이 기본적으로 잘 갖춰져 있었습니다.
또 하나 중요했던 조건은 비용이었습니다.
가능한 한 추가 라이선스 비용 없이 사용할 수 있어야 했고, 자체 호스팅(On-Premise)이 가능해야 했습니다. 장기적인 유지보수와 운영 비용까지 고려했을 때 Free Tier만으로도 충분한 기능을 제공하는지 역시 중요한 판단 기준이었습니다.
여러 도구를 직접 구축하고 비교해 본 결과, 하나의 도구만으로 모든 요구사항을 만족시키기는 어려웠습니다. 그래서 방향을 조금 바꾸기로 했습니다. 도구를 하나 선택하는 것이 아니라, 각 도구를 적절히 합쳐 Tailscale은 네트워크 연결을 담당하고, Teleport는 사용자 인증과 접근 제어, 세션 관리를 담당하도록 역할을 분리했습니다.
최종 → Tailscale(Free tier) + Teleport Community edition
4. 발생한 문제들
처음에는 구조가 단순해 보였습니다. Tailscale은 네트워크를 연결하고, Teleport는 SSH 접속을 관리한다. 역할이 명확해 보였기 때문에 금방 끝날 줄 알았습니다.
하지만 실제로 붙여보니 문제는 도구 자체보다 두 도구 사이의 경계에서 많이 발생했습니다.
- Tailscale 승인이 곧 Teleport 접속 승인은 아니었습니다.
처음에는 Tailscale 접속을 승인하면 원격접속도 승인된 것처럼 볼 수 있다고 생각했습니다. 하지만 곧 애매한 지점이 생겼습니다. Tailscale은 네트워크 접근을 제어하지만, Teleport는 사용자와 SSH 세션을 따로 관리합니다.
즉, Tailscale에서 장비 접근이 가능하다고 해서 Teleport에서 접속 가능한 것은 아니고, 반대로 Teleport 권한이 있다고 해서 Tailscale 네트워크 정책까지 설명되는 것도 아니었습니다.
결국 승인의 기준을 어디에 둘 것인지 다시 정해야 했습니다.
네트워크 접속을 승인할 것인가, 사용자 접속을 승인할 것인가?
이 질문에서 구조가 바뀌기 시작했습니다.
- VPN을 끄면 세션도 끊길 것이라고 생각했습니다
처음에는 승인 시간이 끝나면 Tailscale 접근을 끊으면 된다고 생각했습니다. 하지만 실제 운영 관점에서는 이것만으로 부족했습니다. 이미 열린 SSH 세션이 있을 때, 네트워크 정책 변경이 즉시 원하는 방식으로 반영되지 않는 경우가 있었습니다. 그리고 더 중요한 문제는, 이 방식이 Teleport의 세션 관리와는 별개의 레이어라는 점이었습니다.
Tailscale은 네트워크를 막는 것이고, Teleport는 세션을 관리합니다.
결론적으로는, Teleport의 Session을 끊을 수 있다면.. 굳이 Tailscale을 함께 사용할 필요가 없다는 것이었습니다.
테스트 할 때는 Tailscale을 끊으면 Teleport 세션도 함께 끊겼는데, 이건 테스트 방법이 잘못된 방법을 사용했던 것이었죠. 상대 텔레포트 노드를 타겟으로 세션 접속을 실행해야 하는데 Tailscale IP를 기반으로 테스트 했으니 당연히 끊길 수 밖에 없었습니다.
이에 따라 최종 구조가 Tailscale + Teleport에서 Teleport 단일로 프로세스를 구성할 수 있는지 검토해보자는 얘기가 나왔고, 재검토 결과 원하는 수준의 접속 정책은 Teleport 단일 도구의 사용으로도 충분히 만들 수 있다는 결론이 나왔습니다.
이에 따라 Teleport 기반의 새로운 구조를 고민하게 됐습니다.
Share article