나는 데스크톱(Windows)과 맥북(macOS)을 같은 네트워크에서 사용하고 있고, 진행 중인 개인 프로젝트에서 이걸 활용하고 있다. 데스크톱은 유선랜으로, 맥북은 와이파이로 연결되어 있고, 데스크톱에서 MinIO를 Docker로 구성하여 운영 중이다. 웹 콘솔(UI) 접근도 문제없이 잘 됐다.
맥북에서도 크롬을 통해 MinIO 웹 콘솔에 잘 접근할 수 있었고, Python 스크립트를 이용한 데이터 접근 및 Airflow로 데이터 수집과 변환도 문제없이 작동했다.
그런데 어느 순간부터 Airflow가 MinIO에 접근하지 못 하게 되었다. 당연히 데이터도 쌓이지 않았다.
난 그냥 자고 일어났을 뿐인데,,,,,, 너무 억울하다~ 하~
1. MinIO의 문제인가?
처음에는 MinIO 자체의 문제라고 생각해서 MinIO 호스트 머신인 Windows 데스크톱에서 Docker가 정상적으로 실행되고 있는지 확인했다. 데스크톱에서 크롬을 사용하여 MinIO 웹 콘솔에 접속해 보니 정상적으로 열렸다.
하지만 이상한 점이 있었는데 MinIO 서버의 접근 로그에 아무것도 남아있지 않았다. 즉, 네트워크 요청 자체가 MinIO까지 도달하지 않고 있었던 것이다. 이 때문에 네트워크의 어딘가에서 차단되고 있을 가능성을 의심했다.
2. 방화벽과 네트워크 문제인가?
Windows 방화벽과 macOS의 네트워크 설정을 확인했지만, 모두 정상적으로 설정되어 있었다.
이후, 맥북에서 다양한 방법으로 MinIO에 접근을 시도했다.
- 크롬으로 웹 콘솔 접속 → "페이지를 찾을 수 없음"
- VS Code에서 Python 스크립트 실행 → "no route to host"
- VS Code 터미널에서 curl, nc, ping 등 명령 실행 → 실패
- iTerm에서 curl, nc, ping 등 명령 실행 → 정상적인 응답 반환
방화벽이 문제였다면 맥북의 모든 프로그램에서 접근이 차단되어야 하지만, 일부 프로그램(iTerm)에서는 정상적으로 접속이 가능했다. 따라서 방화벽 문제일 가능성은 낮다고 판단했다.
일부 프로그램에서만 정상적으로 접속이 가능한 걸 난 처음 봤다. iTerm에서는 정상적으로 응답이 오지만, VS Code에서는 실패한다니,, 또 신기한 점은, VS Code에서도 sudo를 붙여 실행하면 정상적으로 작동한다는 점이었다. 예를 들어, sudo curl을 실행하면 MinIO에 정상적으로 접속할 수 있지만, curl만 실행하면 "no route to host" 오류가 발생했다.
이게 도대체 뭔 일인가,,,?
3. macOS에서 admin과 root의 차이?
나는 맥북에서 단 하나의 사용자 계정을 사용하고 있었고, 이 계정은 관리자(admin) 권한을 가지고 있었다. 하지만 sudo를 사용해야만 네트워크 요청이 성공한다는 점이 이상했다.
아는 분들이랑 얘기하다가 macOS 내의 admin과 root는 다르다는 이야기를 듣게 됐고, 좀 더 자세한 정보를 알기 위해 구글링을 하다가 관련 내용을 발견했다.(관련 글로 이동).
sudo를 사용하면 root 권한으로 실행되는데, 이게 admin과 어떻게 다른 걸까? 그리고 root 권한 여부가 네트워크 동작에 영향을 줄 수 있을까?
맥북에서 netstat -nr | grep <desktop-ip> 명령을 실행해 보니, sudo 여부와 관계없이 라우팅 정보는 정상적이었다. 즉, 패킷이 어디로 가야 하는지는 정해져 있지만, 특정 프로세스에서는 네트워크 요청이 차단되고 있는 것 같았다.
여기서 두 가지 가설을 세웠다.
- 특정 프로세스(VS Code, Chrome 등)가 iTerm과는 별도의 네트워크 환경을 가지고 있다.
- macOS의 방화벽 또는 보안 설정이 특정 프로세스의 네트워크 접근을 차단하고 있다.
4. 환경 변수 비교
VS Code 등의 특정 프로세스에서만 특정 설정(프록시, 네트워크 정책 등)이 적용되어 데스크톱(MinIO)에 접근하지 못 하는 걸까?
먼저 첫 번째 가설을 검증하기 위해 VS Code와 iTerm의 환경 변수를 비교했다.
# iTerm 환경 변수 저장
env | sort > ~/iterm_env.txt
# VS Code 환경 변수 저장
env | sort > ~/vscode_env.txt
# VS Code에서 sudo 실행 시 환경 변수 저장
sudo env | sort > ~/vscode_sudo_env.txt
# iTerm과 VS Code 비교
diff ~/iterm_env.txt ~/vscode_env.txt
# VS Code 내 일반 & sudo 차이 확인
diff ~/vscode_env.txt ~/vscode_sudo_env.txt
# iTerm과 VS Code의 sudo 환경 비교
diff ~/iterm_env.txt ~/vscode_sudo_env.txt
하지만 결과적으로 환경 변수는 동일했다. 즉, 네트워크 접근 차이는 환경 변수 때문이 아니었다.
5. macOS의 보안 기능과 방화벽 확인
두 번째 가설을 검증하기 위해 macOS의 방화벽 및 보안 기능을 살펴봤다.
- Application Firewall (소프트웨어 방화벽): 비활성화 상태 (/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate 확인)
- pf(Packet Filter, macOS 네트워크 필터링 시스템): pfctl -s rules를 확인했지만 MinIO 포트를 차단하는 규칙이 없었음.
- SIP (System Integrity Protection, macOS 시스템 보호 기능): csrutil status를 확인해 보니 활성화 상태였음.
혹시 SIP 때문인가 싶어서 복구 모드에서 SIP를 비활성화해 봤지만, 결과는 동일했다. 잘 모르는 시스템을 비활성화 해두는 게 무서워서 결국 다시 활성화했다.
(덕분에 macOS 복구 모드를 처음 사용해봄 ㅎ ㅎ;)
6. 해결 방법: 네트워크 접근 권한 설정
이제까지의 검사 결과, 네트워크 차단이 전체 시스템의 문제가 아니라 특정 프로세스(VS Code, Chrome, Docker)에서만 발생한다는 점을 확인했다.
이 문제를 해결한 방법은 의외로 간단했다.
iTerm은 로컬 네트워크 접근이 허용되어 있었지만, VS Code와 Chrome, 그리고 Airflow가 실행되는 Docker는 거부된 상태였다.
해결 방법: 시스템 환경설정 → 보안 및 개인 정보 보호 → 방화벽 → "프로그램별 네트워크 접근"에서 VS Code와 Chrome, Docker에 대한 네트워크 접근을 허용해 주면 된다.
7. 여담
이 문제가 처음 발생한 건 2025년 2월 2일이었는데, 한 달이 훌쩍 지난 3월 8일에서야 해결됐다.
사실 문제 자체가 어려웠다기보다는, 원인을 특정하기 어려워 해결이 계속 지연됐다. 특히 자고 일어나면 갑자기 해결되고 며칠간 멀쩡히 작동하다가 다시 동일한 문제가 발생하고,, 이게 반복되면서 혼란스러웠다. 복구되는 시점을 정확히 알 수 없으니, 내가 동일한 환경에서 문제를 재현하며 해결을 시도하고 있는지조차 확신할 수 없어서 내가 수행한 작업의 신빙성도 떨어졌다. 그리고 이게 과연 이전에 겪었던 문제와 동일한 문제인지 판단하는 데에도 시간이 꽤나 소요됐고,, 여기서도 꽤나 깨달은 게 많았다. ("8. 배운 점"에 작성)
문제 해결의 키를 얻은 건 여행 중이던 주의 어느 날이었다.
(해결된 3월 8일은 내가 여행을 마치고 집으로 돌아온 날이다.)
여행을 떠나면서 어쩔 수 없이 나의 5년지기 친구(?)인 데스크톱과 생이별을 했고, 맥북만 챙겨갔다. 문제는, 데스크톱 없이는 이 문제를 직접적으로 해결할 방법이 없다는 것이었다. 그래서 맥북만 가지고 할 수 있는 게 무엇일까 고민하다가, "3. macOS에서 admin과 root의 차이?"에서 세운 2가지 가설 중 첫 번째 가설을 검증해보기로 했다.(여행 전날, 두 번째 가설을 시도해봤다가 실패해서 다소 상심한 채 여행길에 올랐었다.) 하지만 여행 도중 첫 번째 가설까지 기각되면서 망연자실했다. (실패해서 X, 데스크톱 없이 더 이상 검증할 방법을 떠올릴 수 없어서 O)
결국 집에 가서 다시 고민해봐야겠다고 생각하며, superuser 커뮤니티에 문제를 정리해서 올렸다. 다행히 여행 중에 2개의 답변을 받을 수 있었고, 집에 도착하자마자 시도해본 결과 마침내 문제를 해결할 수 있었다. (내가 올린 게시글)
로컬에서 2대의 머신을 연결해서 사용하는 건 처음이라 평소보다 더 어벙하게 처리한 것 같지만,, 덕분에 클라우드 환경이 얼마나 편한지도 실감하게 됐다. 문득 데브코스 마지막 프로젝트 때 AWS를 공짜로 사용할 수 있었던 게 얼마나 좋았는지 추억에 빠졌다,, 아는 분이 AWS보다는 GCP의 무료 사용 범위가 더 넓다고 알려주셔서, 만약 이 프로젝트를 클라우드로 옮기게 된다면 이번엔 AWS 대신 GCP를 써볼 생각이다.
그나저나 로컬 네트워크 접근 여부는 내가 따로 건드린 적이 없는데 왜 문제가 발생했다가 해결됐다가 한 거지? 이게 진짜 미스터리다. 맥북에 귀신이 들었나,,? 갤럭시를 사용하지만 맥북을 사버린 삼성의 저주인가???????
두려움에 떨지 마라, 이재용. 난 아이폰은 사지 않을테니.
아무튼 이 미스터리는 코난, 김전일, Q 다 데려와도 해결 못 할 듯,, 난 맥북 업데이트 올라오면 바로바로 하는 편인데 그러면서 뭔가 바뀐 건가?
8. 배운 점
이번 문제를 겪으며 몇 가지 중요한 교훈을 얻었다.
- 문제가 발생하면 반드시 로그를 기록할 것
비슷한 문제가 다시 발생했을 때, 이전과 동일한 문제인지 판단하는 것이 예상보다 어려웠다. 정확한 시점과 증상을 기록하지 않으면, 문제를 재현하려 해도 동일한 상황인지 확신할 수 없었다. 앞으로는 주요 네트워크 설정, 오류 메시지, 환경 정보를 빠르게 기록하는 습관을 들여야겠다고 느꼈다. - 디버깅을 위한 코드를 별도로 작성해 둘 것
내가 작성한 대부분의 코드가 Airflow 내부에서만 실행되도록 되어 있었기 때문에, 문제가 발생하면 Airflow를 통해서만 테스트할 수밖에 없었다. 하지만 네트워크 이슈처럼 원인을 파악해야 하는 경우, Airflow와 별개로 독립적인 테스트 스크립트가 필요했다. 이를 해결하기 위해 MinIO에 접근하는 별도의 스크립트를 작성했는데, 이 경험을 통해 데이터 수집/처리 로직도 Airflow와의 강한 의존성을 줄이고, 독립적으로 테스트할 수 있도록 별도로 작성하여 개선해야겠다는 생각을 했다. - 문제를 해결하려는 시도보다, 우선 환경을 파악하고 문제를 재현하는 것이 중요
이번 문제의 가장 큰 어려움은 "이게 같은 문제인가?"를 판단하는 것이었다. 특히 원인을 특정할 수 없는 상황에서 문제 해결을 시도하는 것은 시간 낭비가 될 수 있다. 앞으로는 해결을 시도하기 전에 먼저 환경을 철저히 분석하고, 문제가 어떻게 발생하는지를 명확히 재현하는 데 집중해야겠다고 다짐했다.
이 경험을 통해 단순히 문제를 해결하는 것뿐만 아니라, 더 체계적으로 문제를 분석하고 해결하는 방법을 배웠다. 앞으로도 이런 문제를 겪을 때마다 기록을 남기고, 테스트 환경을 분리하며, 정확한 재현 과정을 먼저 설정하는 습관을 들여야겠다.