원격 Mac에 SSH 연결은 되지만, 누가 어떤 계정으로 접속하는지와 CI 작업에 쓸 인증 수단이 정리되지 않아 배포를 미루고 있나요?
가장 빠른 해결책은 Tunnel을 네트워크 경로로만 사용하고, 대화형 운영과 무인 CI를 분리해 각각의 인증·권한·회수 절차를 검증하는 것입니다. Tunnel과 Access는 Mac의 로컬 계정이나 SSH 권한을 대신하지 않습니다.
이 글은 원격 Mac의 SSH 접속 경계를 정하는 기업 IT 책임자를 위한 안내입니다.
개발자 접속과 CI 서비스 계정의 권한을 분리하려는 플랫폼 엔지니어도 대상입니다.
보안 담당자는 신원 정책, 감사 기록, 접근 회수 절차를 검토할 때 활용할 수 있습니다.
연결 전에 역할과 운영 경계를 나눕니다
Cloudflare Tunnel은 Mac에서 외부로 연결을 만들어 원격 SSH 경로를 제공할 수 있습니다. 따라서 SSH를 위해 Mac의 인바운드 포트를 인터넷에 직접 공개할 필요가 없습니다. 다만 이 네트워크 경로를 마련해도 macOS의 사용자 계정, SSH 허용 대상, CI 자격 증명은 별도로 관리해야 합니다. Tunnel의 연결 구조와 동작 방식을 기준으로 네트워크 경계를 설계하세요.
개발자 기기
│ 사용자 인증
▼
Cloudflare Access
│ 허용된 SSH 경로
▼
cloudflared가 실행되는 장치
│ Tunnel을 통한 전달
▼
Mac의 SSH 서비스 ── macOS 로컬 계정과 권한
이 구성에서 Access는 사용자 신원을 확인하고 정책에 따라 접근을 허용합니다. SSH 서비스는 Mac의 계정으로 접속을 처리하며, 해당 계정이 수행할 수 있는 작업은 macOS 권한에 좌우됩니다. 따라서 Access 로그인이 성공해도 Mac의 관리자 권한이 주어지는 것은 아닙니다. Access 정책 문서에 따라 신원과 접근 조건을 정하고, Mac에서는 별도로 SSH 계정과 권한을 정해야 합니다.
| 구분 | 담당하는 일 | 별도로 확인할 항목 |
|---|---|---|
| Tunnel | Mac으로 이어지는 네트워크 경로 제공 | Tunnel을 실행하는 장치가 목표 Mac에 도달 가능한지 |
| Access | 정책에 따른 사용자 인증과 접근 제어 | 허용 대상, 신원 제공자, 인증 기록 |
| macOS SSH | Mac의 로컬 사용자 인증과 세션 제공 | 원격 로그인 설정, 허용 사용자, 계정 권한 |
| CI 인증 | 자동화 작업에서 사용할 별도 자격 증명 | 보관 위치, 사용 범위, 폐기 담당자 |
개발자가 직접 터미널에서 접속하는 대화형 운영과, Runner가 사람의 입력 없이 수행하는 CI 작업은 인증 주체부터 다릅니다. 한쪽의 로그인 성공을 다른 쪽의 준비 완료로 판단하지 마세요.
배포 전에는 Mac과 인증 방식을 먼저 정합니다
먼저 Tunnel을 실행할 장치가 목표 Mac의 SSH 서비스에 네트워크로 접근할 수 있는지 확인합니다. Tunnel을 Mac 자체에서 실행하는 구성이라면 서비스 실행 문맥과 설정 파일을 살펴야 합니다. 다른 장치에서 실행한다면 그 장치에서 목표 Mac까지의 내부 경로와 방화벽 규칙을 별도로 검증합니다.
macOS에서는 시스템 설정에서 원격 로그인을 켜고, 접속을 허용할 사용자를 확인합니다. Apple의 원격 로그인 설정 안내에 따라 설정하되, 모든 사용자에게 SSH를 열기보다 업무상 필요한 계정만 허용하는 편이 안전합니다.
사용자 접속 방식은 서로 바꿔 쓸 수 있는 동일한 선택지가 아닙니다.
| 방식 | 적합한 상황 | 운영 전 확인 사항 |
|---|---|---|
클라이언트 cloudflared |
개발자 기기에서 SSH 클라이언트를 이용하는 대화형 접속 | 사용자 기기별 클라이언트 설정과 Access 인증 절차 |
| 브라우저 터미널 | 브라우저에서 제한된 터미널 작업을 수행하는 경우 | 터미널의 기능·입출력 제약이 실제 운영 작업에 맞는지 |
| 인프라 접근용 SSH | 사용자와 대상, 사용자 이름 등의 정책을 더 세밀하게 다뤄야 하는 경우 | 적용할 정책 기능, 인증 방식, 감사 기록 범위 |
브라우저 터미널은 로컬 SSH 클라이언트를 그대로 대체하지 않습니다. 필요한 개발 도구나 파일 이동이 브라우저 방식에서 가능한지 브라우저 렌더링 문서의 제약과 대조하세요. 더 세분화된 사용자·대상 정책이 필요하다면 인프라 애플리케이션의 정책 범위와 인프라 SSH 접근 기능을 따로 검토합니다.
주의: 직원의 퇴사나 역할 변경 때 누가 Access 정책과 Mac 계정을 각각 회수할지 먼저 정하세요. 한 시스템에서 사용자를 삭제해도 다른 시스템의 계정이나 자격 증명이 자동으로 정리된다고 가정해서는 안 됩니다.
첫 번째 단계: Tunnel 경로와 SSH 서비스를 연결합니다
Cloudflare 대시보드 또는 관리 방식에 따라 Tunnel을 구성하고, SSH 요청이 목표 Mac의 SSH 서비스로 전달되도록 경로를 설정합니다. Tunnel 실행 장치와 목표 Mac이 다르면 라우팅 대상에 목표 Mac의 올바른 호스트 이름 또는 내부 주소를 지정해야 합니다. 설정한 이름이 DNS 경로, Access 애플리케이션, 클라이언트 설정에서 일치하는지도 확인합니다.
Mac에서 cloudflared를 서비스로 실행한다면 로그인한 사용자의 셸에서만 동작하는지, 재시작 후에도 기대한 설정과 권한으로 실행되는지 점검합니다. macOS에서 서비스를 실행하는 공식 안내를 확인하고, 서비스의 실행 문맥과 설정 파일 경로가 실제 배포 환경에 맞는지 검증하세요.
두 번째 단계: 클라이언트와 Access 정책을 연결합니다
클라이언트 cloudflared를 이용하는 SSH 구성은 대체로 SSH 클라이언트의 호스트 항목과 ProxyCommand로 연결됩니다. 실제 경로 이름과 호스트 값은 조직 설정에 맞춰야 합니다. 아래는 구성을 읽기 위한 최소 예시입니다.
Host mac-build.example.com
ProxyCommand cloudflared access ssh --hostname %h
이 설정을 적용한 뒤에는 등록한 호스트 별칭으로 SSH 연결을 시도합니다. Access 인증이 완료되는지와 Mac에서 지정한 로컬 계정으로 SSH 로그인이 되는지는 별도로 확인하세요. Cloudflare의 SSH 클라이언트 인증 및 라우팅 안내에 나온 클라이언트 구성과 실제 조직 정책이 일치하는지 대조합니다.
다른 직원이 다른 Mac에만 접근해야 한다면, 공통 정책 하나로 모든 대상을 열지 말고 사용자 그룹과 대상 호스트의 관계를 정책에 반영합니다. 또한 각 Mac에서 허용된 로컬 계정이 무엇인지 확인해야 합니다. SSH 접속이 성공하는 것만으로 사용자별 대상 분리가 작동한다고 판단할 수는 없습니다.
세 번째 단계: macOS SSH 권한을 Access와 별도로 확인합니다
원격 로그인 설정에서 SSH 접속을 허용할 계정과 그룹을 점검합니다. 각 계정의 권한은 맡은 업무에 필요한 수준으로 제한하고, 일반 개발자 계정과 관리자 계정이 섞여 사용되지 않도록 구분하세요. 계정 생성·변경·비활성화 책임도 Access 정책 관리자와 Mac 관리자 사이에 명확히 배정합니다.
검증 기록에는 다음을 따로 남기면 좋습니다.
- Access에서 허용한 사용자와 대상 Mac
- Mac에서 원격 로그인을 허용한 계정
- 해당 계정의 관리자 여부와 작업 범위
- SSH 키나 인증서의 발급·보관·회수 담당자
- 정책 변경과 인증 기록을 확인하는 담당자
Access 인증 로그는 사용자 인증 관련 정보를 살펴보는 자료입니다. 로그에 기록되는 필드 설명을 확인하고, Mac의 SSH 인증 기록과 같은 사건을 연결해 볼 수 있도록 시간과 사용자 식별 기준을 정하세요. 인증 로그만으로 Mac 내부에서 실행한 모든 명령을 확인할 수 있다고 확대 해석해서는 안 됩니다.
네 번째 단계: CI는 사람의 로그인과 분리해 시험합니다
Cloudflare Tunnel 원격 Mac SSH 구성이 대화형 운영에 성공해도 무인 CI 작업까지 준비된 것은 아닙니다. 별도의 비생산 파이프라인에서 서비스 계정으로 필요한 연결이 되는지 시험하고, 인증 방식과 자격 증명 저장 위치, 회수 절차를 기록하세요. 개발자의 개인 키를 Runner에 복사해 공유하는 방식은 피해야 합니다.
검증 결과도 한 덩어리로 처리하지 않습니다. 네트워크를 통한 SSH 연결, CI 에이전트 동작, 빌드 완료, 서명 및 배포 완료는 각각 다른 상태입니다. 각 단계가 실패했을 때 로그에서 원인을 구분할 수 있도록 파이프라인 결과를 남기세요. 대화형 Access 인증을 사람이 없는 작업에 그대로 적용할 수 있다고 가정하지 말고, 조직에서 선택한 자동화 인증 흐름을 공식 문서와 실제 시험으로 확인합니다.
참고: CI에는 사람 계정과 다른 인증 주체, 제한된 권한, 명시적인 폐기 절차가 필요합니다. 이 조건을 시험하지 못했다면 해당 Mac을 무인 배포 작업에 승인하지 말고 대화형 운영으로만 제한하세요.
다섯 번째 단계: 복구 시험과 증거를 확인합니다
운영 승인을 내리기 전에 사용자 철회, Tunnel 연결 중단, Mac 재시동, SSH 허용 계정 변경을 각각 시험합니다. 각 시험에서 담당자가 경보를 확인하는지, 정상 연결을 복구할 수 있는지, 권한 회수가 로그에 남는지 점검하세요. 실제 시험 결과가 없는 가용률이나 복구 시간을 문서에 약속값처럼 적어서는 안 됩니다.
다음 항목을 완료 기록으로 남깁니다.
- [ ] Tunnel 실행 장치에서 목표 Mac의 SSH 서비스에 도달할 수 있습니다.
- [ ] Access 정책에서 허용한 사용자만 의도한 Mac에 접근할 수 있습니다.
- [ ] macOS에서 허용하지 않은 계정은 SSH 로그인에 실패합니다.
- [ ] 개발자 계정과 관리자 계정의 작업 범위가 구분되어 있습니다.
- [ ] CI 서비스 계정은 개인 계정과 분리되어 있고 회수 담당자가 지정되어 있습니다.
- [ ] Tunnel 단절과 Mac 재시동 후의 복구 경로를 실제로 시험했습니다.
- [ ] Access 인증 기록과 Mac의 SSH 기록을 조사할 책임자가 정해져 있습니다.
- [ ] 문제가 생겼을 때 우회 접속을 허용할지, 서비스를 중단할지 결정되어 있습니다.
판정은 세 가지로 정리할 수 있습니다. 연결과 권한 회수, 장애 복구까지 확인되면 운영 승인을 검토합니다. 필수 기록이나 권한 분리가 빠졌다면 기한을 정해 수정한 뒤 재검증합니다. CI 인증만 검증되지 않았다면 대화형 접속으로 한정하고, Tunnel 복구나 계정 권한을 통제할 수 없다면 운영에 투입하지 않습니다.
각 개발자에게 Mac을 구매해 직접 관리하면 장비 조달과 교체, 설정 변경, 퇴사자 접근 회수까지 조직이 맡아야 합니다. 자체 운영 환경은 내부 네트워크와 정책을 세밀하게 통제할 수 있지만, 운영 책임과 장애 대응 부담도 내부에 남습니다. 이런 부담을 줄일 임시 개발·검증 환경이 필요하다면 NodeMini의 실제 접속 방식과 제공 조건을 확인한 뒤 팀의 SSH·CI 정책에 맞는지 비교하세요. NodeMini의 원격 Mac 주문 안내와 서울 지역 주문 정보를 검토하면 됩니다. 물리 장비 접근이나 장기간 고정 부하가 필수라면 직접 구매가 더 적합할 수 있지만, 사용 기간에 따라 환경을 마련해야 하는 팀에는 원격 Mac 임대가 장비 조달과 유지관리 부담을 덜어주는 선택지가 될 수 있습니다.