title: “환경변수하고 Alias는 무슨 차이가 있는가?” date: 2025-02-24T08:34:00.000Z draft: false tags: [“Docker”] series: [“Infra & Network”] description: “콘텐츠 없음” notion_id: “1a41bab9-e3f8-804d-bb86-f63ca9263587” notion_url: “https://www.notion.so/Alias-1a41bab9e3f8804dbb86f63ca9263587"

환경변수하고 Alias는 무슨 차이가 있는가?

Summary 콘텐츠 없음

이 글은 Notion에서 가져왔습니다.

원본 보기

삽질에서 깨달음으로: Proxmox 홈서버 구축 여정기

시작은 단순한 호기심이었다

처음에는 정말 단순했다. 그냥 집에서 돌아가는 작은 서버 하나 만들어보고 싶었을 뿐이었다. 남는 컴퓨터 하나 있으니까, 그냥 Linux 깔아서 SSH 서버나 하나 열어볼까 하는 정도의 가벼운 마음이었다.

하지만 막상 시작하고 보니, 이게 어디 그렇게 간단한 일이었나.

첫 번째 벽은 하드웨어였다. 기존에 쓰던 H110M DGS 메인보드에 뭘 얹어야 할지부터 막막했다. CPU는 뭘 써야 하고, 메모리는 얼마나 필요하고, 스토리지는 어떻게 구성해야 하는지… 인터넷을 뒤져가며 Intel Pentium G4560이 괜찮다는 글을 보고 그걸로 정했는데, 정말 맞는 선택인지 확신이 서지 않았다.

그때 깨달았다. 완제품 NAS를 사는 게 훨씬 쉬울 텐데, 왜 굳이 이런 삽질을 하고 있는 걸까? 하지만 이미 시작한 이상 끝까지 해보고 싶었다. 아니, 정확히는 ‘제대로’ 해보고 싶었다.

하드웨어라는 현실의 벽

하드웨어 구성을 정하는 과정에서 수없이 많은 선택의 기로에 섰다. 케이스 하나 고르는 것도 이렇게 복잡할 줄 몰랐다. ITX 케이스가 좋을까, 아니면 일반 케이스에서 공간을 넉넉히 쓰는 게 나을까? HDD는 몇 개까지 확장할 수 있게 해야 할까?

특히 고민됐던 부분은 쿨링 시스템이었다. NAS용 쿨러를 찾아보니 높이 제한이 70mm 이하인 경우가 많았다. 그런데 성능 좋은 쿨러들은 대부분 그보다 컸다. 결국 150mm 높이의 쿨러로 정했는데, 케이스에 들어갈지 불안했다.

전원 공급 장치도 마찬가지였다. 기존에 쓰던 Antec VP500P V2가 있긴 했는데, 24시간 돌아갈 서버에 쓰기에는 효율성이 걱정됐다. 하지만 새로 사자니 비용이 부담스럽고…

이런 고민들을 하나하나 해결해가면서 느꼈다. 하드웨어라는 건 결국 타협의 연속이구나. 성능과 비용, 안정성과 확장성 사이에서 끊임없이 균형점을 찾아야 하는 것이었다.

Proxmox라는 새로운 세계

하드웨어가 준비되고 나서 다음 고민은 OS였다. 처음에는 그냥 Ubuntu Server 깔아서 Docker로 서비스들 올리면 될 줄 알았다. 하지만 조사해보니 Proxmox라는 게 있더라.

가상화? 집에서 가상화가 왜 필요하지? 라는 생각이 첫 번째였다. 하지만 Proxmox 문서들을 읽어보면서 점점 매력을 느꼈다. 하나의 물리 서버에서 여러 개의 독립적인 환경을 돌릴 수 있다니. 이거면 테스트 환경도 쉽게 만들 수 있고, 서비스별로 격리도 할 수 있겠다.

설치 과정은 생각보다 순조로웠다. 하지만 막상 웹 인터페이스에 들어가보니 또 다른 세계가 펼쳐졌다. VM 생성, LXC 컨테이너, 스토리지 풀… 뭐가 뭔지 하나도 모르겠더라.

첫 번째 VM을 만들 때의 당황스러움을 지금도 기억한다. 네트워크 설정에서 Bridge 모드라는 게 기본으로 선택되어 있는데, 이게 뭔지 전혀 몰랐다. NAT는 뭐고, Host-only는 뭔지… 인터넷을 뒤져가며 하나씩 공부했다.

네트워크라는 복잡한 미로

Proxmox를 쓰면서 가장 많이 삽질한 부분이 바로 네트워크였다.

Bridge 모드로 VM을 만들면 자동으로 vmbr0에 연결된다는 건 알겠는데, 그래서 실제로 어떻게 동작하는 건지 이해하기까지 시간이 오래 걸렸다. VM이 마치 실제 네트워크에 직접 연결된 별개의 컴퓨터처럼 동작한다는 게 신기하면서도 헷갈렸다.

특히 NAT 모드와 Bridge 모드의 차이를 체감하기까지가 힘들었다. 이론적으로는 알겠는데, 실제로 써보니 미묘한 차이들이 있더라. 외부에서 VM에 접근할 때의 차이, 성능상의 차이, 보안상의 차이…

그러다가 독립된 네트워크를 만들어야 할 일이 생겼다. VirtualBox의 Host-only와 비슷한 환경을 Proxmox에서 구현하려면 어떻게 해야 할까? 결국 새로운 브리지를 만들되 물리 인터페이스와 연결하지 않는 방식으로 해결했다. 이런 작은 성취감들이 쌓여가면서 점점 더 깊이 들어가게 됐다.

LXC, 그리고 효율성에 대한 깨달음

VM만 쓰다가 LXC 컨테이너를 알게 된 건 우연이었다. Proxmox 인터페이스에서 “CT” 버튼이 있는 걸 보고 호기심에 눌러본 게 시작이었다.

Container Template을 다운로드하는 과정부터 신선했다. VM은 ISO 이미지 전체를 다운받아야 하는데, LXC는 훨씬 가벼운 템플릿 파일로 금방 설치가 끝났다. 부팅 속도도 VM과는 비교할 수 없을 정도로 빨랐다.

하지만 LXC가 만능은 아니더라. Tailscale을 LXC 컨테이너에서 돌리려고 했을 때 TUN 디바이스 문제로 한참 헤맸다. “/dev/net/tun does not exist"라는 에러 메시지를 보고 처음엔 뭔 소린지 몰랐다.

결국 Proxmox 호스트에서 LXC 설정 파일을 직접 수정해야 했다:

1
2

lxc.cgroup.devices.allow = c 10:200 rwm
lxc.mount.entry = /dev/net/tun dev/net/tun none bind,create=file

이런 저수준 설정을 만져야 한다는 게 처음엔 부담스러웠다. 하지만 해결하고 나니 LXC의 동작 원리를 더 깊이 이해하게 됐다. 결국 컨테이너도 호스트 커널을 공유하는 거고, 특정 디바이스에 접근하려면 명시적인 권한이 필요하다는 것.

미러 서버 구축: 예상치 못한 깊은 물

홈서버를 운영하면서 가장 예상치 못했던 프로젝트가 바로 미러 서버 구축이었다. 처음에는 단순했다. Rocky Linux ISO를 다운받아서 로컬에서 패키지를 설치할 수 있게 하자는 것이었다.

하지만 막상 해보니 생각보다 복잡했다. ISO를 마운트해서 저장소로 쓰는 것까지는 쉬웠는데, 실제 클라이언트에서 이 저장소를 쓰도록 설정하는 과정에서 여러 문제가 생겼다.

특히 RHEL 클라이언트에서 Rocky Linux 저장소를 쓸 수 있는지 확인하는 과정은 정말 흥미로웠다. 이론적으로는 바이너리 호환이 된다고 하는데, 실제로는 어떨까?

결국 직접 해보는 수밖에 없었다. RHEL 클라이언트를 설치하고, Rocky Linux 미러를 저장소로 등록한 다음 git 패키지를 설치해봤다. 성공했다! 하지만 이게 정말 Rocky 저장소에서 온 건지 확신이 없어서 네트워크 패킷까지 캡처해서 확인했다.

이 과정에서 깨달은 게 많다. EPEL과 Rocky Linux, 그리고 RHEL의 관계가 생각보다 복잡하다는 것. 같은 패키지라고 해도 어느 저장소에서 오는지에 따라 지원 정책이 달라진다는 것. 기술적으로는 호환되지만 법적, 정책적으로는 완전히 다른 영역이라는 것.

PowerTools와 하이브리드 저장소의 발견

미러 서버를 운영하다 보니 또 다른 문제가 생겼다. 기본 ISO에는 없는 개발 패키지들을 어떻게 제공할 것인가?

PowerTools 저장소라는 걸 알게 됐다. 이건 ISO에 포함되지 않은 추가 패키지들을 온라인으로 제공하는 저장소였다. 그러면 ISO 기반의 오프라인 저장소와 PowerTools 온라인 저장소를 동시에 쓸 수 있을까?

해보니 됐다! 클라이언트에서는 먼저 로컬 ISO 저장소를 확인하고, 거기 없는 패키지는 PowerTools에서 가져오더라. 이런 하이브리드 구성이 가능하다는 게 신기했다.

이때 깨달았다. 엔터프라이즈 환경에서 미러 서버를 운영하는 게 왜 복잡한지. 단순히 저장소를 미러링하는 게 아니라, 보안 정책, 업데이트 관리, 의존성 관리 등 고려할 게 너무 많다는 것을.

보안이라는 현실적 고민

서버를 외부에 노출하면서 보안에 대한 고민이 깊어졌다. 처음에는 SSH 포트만 열어두고 비밀번호 인증만 쓰고 있었는데, 로그를 보니 무차별 대입 공격이 엄청나게 들어오고 있더라.

Fail2ban을 설치해서 일정 횟수 이상 로그인 실패하면 IP를 차단하도록 했다. 하지만 이것만으로는 부족하다는 생각이 들었다.

결국 공개키 인증으로 바꾸고, 해외 IP는 아예 차단하기로 했다. iptables 규칙을 만져가며 국내 IP 대역만 허용하도록 설정했다. 하지만 이것도 완벽한 해답은 아니더라. 국내에서도 봇넷 공격이 들어올 수 있으니까.

가장 효과적이었던 건 VPN을 통한 접근이었다. WireGuard를 설치하고, 외부에서는 VPN을 통해서만 서버에 접근할 수 있게 했다. 이렇게 하니 훨씬 안심이 됐다.

GPU 패스스루와 성능의 한계

Windows 11 VM을 만들면서 GPU 패스스루를 시도해본 것도 기억에 남는다. 게임도 해보고 싶고, GPU 가속이 필요한 작업들도 VM에서 돌려보고 싶었다.

IOMMU를 활성화하고, GPU를 VM에 할당하는 과정 자체는 생각보다 어렵지 않았다. 하지만 실제 성능은 기대에 못 미쳤다. 네이티브 Windows에서 돌릴 때와 비교하면 확실히 성능 저하가 있었다.

게다가 GPU를 VM에 할당하면 호스트에서는 그 GPU를 못 쓴다는 한계도 있었다. 결국 실용적인 용도로는 쓰기 어렵겠다는 결론에 도달했다.

하지만 이 과정에서 하드웨어 가상화의 한계와 가능성을 동시에 경험했다. 기술적으로는 가능하지만, 실용성에는 한계가 있다는 것. 그리고 용도에 따라 적절한 선택이 필요하다는 것.

분산 시스템으로의 확장 꿈

맥미니를 여러 대 모아서 분산 시스템을 만들어보고 싶다는 생각이 들었다. 각각에 Proxmox를 설치하고, Terraform으로 VM 배포를 자동화하고, Ansible로 설정 관리를 하는 거다.

아직 실현하지는 못했지만, 이런 생각을 하게 된 것 자체가 성장이라고 생각한다. 처음에는 단일 서버 하나 관리하기도 벅찼는데, 이제는 분산 시스템 아키텍처까지 고민하게 됐으니까.

Infrastructure as Code라는 개념도 이 과정에서 알게 됐다. 수동으로 하나하나 설정하는 게 아니라, 코드로 인프라를 정의하고 자동화하는 것. 이런 접근 방식이 확장성과 재현성 측면에서 훨씬 우수하다는 것을 깨달았다.

AI와 모니터링: 미래를 향한 시도

최근에는 AI를 활용한 모니터링 시스템을 구축해보고 있다. 시스템 메트릭을 수집해서 AI가 분석하고, 자연어로 질문하면 답변해주는 시스템을 만들어보고 싶었다.

Gemini API를 연동해서 로그를 분석하는 건 성공했다. 하지만 정말 유용한 인사이트를 제공하려면 더 많은 고민이 필요하겠더라. 단순히 로그를 요약해주는 수준이 아니라, 실제 문제를 예측하고 해결책을 제시할 수 있어야 하니까.

Go 언어로 커스텀 모니터링 시스템을 만들어보는 것도 재미있는 도전이었다. Python으로 프로토타입을 만들고, 성능이 중요한 부분은 Go로 재작성하는 식으로 접근했다.

삽질에서 얻은 것들

돌이켜보면, 이 모든 과정이 ‘삽질’이었다. 정답이 정해져 있는 걸 따라하는 게 아니라, 시행착오를 반복하면서 스스로 해답을 찾아가는 과정이었다.

하지만 이 삽질들이 나에게 준 것들이 많다. 기술적 지식은 물론이고, 문제 해결 능력, 그리고 무엇보다 끝까지 해내는 끈기를 길렀다.

특히 기업 환경에서 요구되는 실무 역량들을 자연스럽게 익히게 됐다. 가상화, 네트워킹, 보안, 자동화, 모니터링… 이런 것들이 각각 독립된 기술이 아니라 유기적으로 연결된 하나의 시스템이라는 것을 체감했다.

무엇보다 중요한 건, 모르는 걸 두려워하지 않게 됐다는 것이다. 새로운 기술이나 개념을 마주쳤을 때, 일단 해보고 삽질하면서 익혀나가는 자신감이 생겼다.

끝나지 않는 여정

지금도 이 홈서버는 계속 진화하고 있다. 새로운 서비스를 추가하기도 하고, 기존 설정을 최적화하기도 하고, 때로는 전체를 다시 구성하기도 한다.

이 과정에서 깨달은 건, 완벽한 시스템이란 존재하지 않는다는 것이다. 항상 더 나은 방법이 있고, 새로운 요구사항이 생기고, 기술은 계속 발전한다. 중요한 건 그 변화에 유연하게 대응할 수 있는 기초를 단단히 쌓는 것이다.

처음에는 단순한 호기심으로 시작했던 홈서버 프로젝트가, 이제는 내 성장의 플랫폼이 됐다. 새로운 기술을 실험해볼 수 있는 공간이자, 실무에 필요한 역량을 기를 수 있는 도구가 됐다.

앞으로도 이 여정은 계속될 것이다. 다음에는 어떤 새로운 도전이 기다리고 있을지 기대된다. 분산 시스템일 수도 있고, 더 고도화된 AI 시스템일 수도 있고, 아니면 아직 상상하지 못한 완전히 새로운 영역일 수도 있다.

하지만 어떤 도전이 와도, 이 삽질의 여정에서 쌓은 경험과 자신감이 있다면 해낼 수 있을 것이라 믿는다. 왜냐하면 이미 증명했으니까. 모르는 걸 알게 만들고, 안 되는 걸 되게 만드는 것. 그게 바로 엔지니어의 본질이 아닐까.

참고자료

효율적인 VMWare 인프라 운영을 위한 최적의 VM 집적도 테스트 - tech.kakao.com

Dynamic Memory Management - Proxmox VE