기록 개요
- 기록일: 2026년 8월 24일
- 진행: 김희성
- 질문·학습: 홍용재
- 성격: 네트워크와 서버 운영을 개별 명령이 아니라 전체 계층과 신뢰성 관점에서 이해하기 위한 인프라 입문 1차 스터디
스터디 목표와 요청
홍용재는 다음 주제를 하나의 구조로 연결해 이해하고 싶다고 요청했다.
- 공인·사설 IP, 호스트 이름, 라우팅, 터널
- Linux 서버와 프로세스
- VM, Container, Docker의 차이
- Database, Cache, Queue
- CI/CD와 배포
- Traffic, Load Balancing, Scaling과 HPA
- 이후 직접 풀 수 있는 과제와 2차 스터디
김희성은 한 번에 Kubernetes 세부 기능까지 외우기보다 Unix와 Linux, 가상화, 네트워크, 인프라 신뢰성의 큰 지도를 먼저 잡는 것을 이번 범위로 정했다.
각 사람의 관점
김희성
- Linux는 단순히 가벼운 Windows가 아니라, 작은 프로그램을 안정적으로 실행하고 여러 노드를 묶어 운영하기 좋은 Unix 계열 환경이라는 관점으로 설명했다.
- 용어를 외우기보다 각 계층이 왜 생겼는지 아래에서 위로 추론해야 인프라 설계를 판단할 수 있다고 강조했다.
- 최고의 인프라 구조는 존재하지 않으며, 가용성·안정성·확장성 사이에서 현재 요구에 맞는 트레이드오프를 선택하는 일이라고 했다.
- 이번 시간에는 Kubernetes 명령보다 전체 클러스터와 서비스 운영 구조를 이해하는 데 집중하고, 세부 구조는 2차로 넘겼다.
홍용재
- Docker와 VM, Linux Kernel과 Hypervisor의 경계를 기존에 단편적으로 이해하고 있었다고 밝히고, 각 개념이 어느 계층에서 동작하는지 반복해서 확인했다.
- Ingress, Load Balancer, VNet, Subnet, Queue, Worker를 자신의 Runtime과 Viewer 구조에 대응시켜 이해했다.
- 에이전트 작업 상태를 JSON으로 남기고 프론트에서 시각화하는 구조가 Monitor Worker와 관측 시스템에 연결된다는 점을 확인했다.
- 다음에는 Kubernetes를 실제 배포 단위와 설정 관점에서 더 배우고 싶다고 했다.
학습 내용
1. Unix, Linux와 실행 환경
- Unix, POSIX, C와 Kernel·OS의 관계를 역사적 맥락에서 살폈다.
- 데스크톱 OS는 상호작용과 여러 사용자 프로그램에 최적화되어 있지만, Linux 서버는 작은 프로그램을 지속적으로 실행하고 조합하는 데 적합하다는 관점을 잡았다.
- Bare Metal 위에 Hypervisor를 두고 물리 자원을 분리하면 각각 독립 Kernel을 가진 VM을 만들 수 있다.
2. VM, Container와 Docker
- VM은 Hypervisor가 물리 자원을 나눠 독립 OS 환경을 제공하는 단위다.
- Container는 OS 위에서 프로세스와 의존성을 격리해 배포하는 더 가벼운 단위다.
- Docker는 Container 이미지를 만들고 실행하기 쉽게 하는 도구이며, Orchestrator는 여러 Node에 필요한 Container를 배치하고 관리한다.
- Kubernetes에서는 배포의 핵심 단위를 Pod로 부르고 여러 Node를 Cluster로 묶어 운영한다.
3. Traffic과 네트워크 진입
- Traffic은 같은 시간대에 들어오는 요청의 양으로 이해했다.
- Ingress는 외부 요청이 들어오는 진입점이며 Nginx 같은 구성 요소가 Routing과 Proxy 역할을 수행할 수 있다.
- Load Balancer는 같은 서비스를 수행하는 여러 Instance에 요청을 나눠 한곳에 부하가 집중되지 않게 한다.
4. 공인 IP, 사설 IP와 가상 네트워크
- ISP가 제공하는 공인 IP와 내부에서 재사용할 수 있는 사설 IP를 구분했다.
- IPv4 주소의 Network 영역과 Host 영역, IP 대역과 Subnet의 기본 개념을 살폈다.
- VNet은 물리 Host 안에 논리적 네트워크와 Subnet을 만들고, 격리된 영역 사이의 경로를 통제하는 구조로 이해했다.
- 큰 네트워크가 더 작은 네트워크로 반복해서 나뉘는 계층 구조를 확인했다.
5. 인프라의 신뢰성
- 인프라의 목적은 코드를 계속 살아 있게 하고 불특정 다수에게 예측 가능한 서비스를 제공하는 것이다.
- 가용성은 필요한 구성 요소가 꺼지지 않고 사용할 수 있는 상태를 유지하는 능력이다.
- 안정성은 요청과 결과가 서비스 전체를 거쳐 일관되고 적절한 시간 안에 전달되는 성질이다.
- 확장성은 Traffic과 기능이 늘어날 때 구조를 키우거나 변경할 수 있는 능력이다.
- 실제 서비스에서는 Compute, Database, Storage, Network 등 모든 계층의 가용성이 함께 보장되어야 한다.
6. Scaling, Queue와 Worker
- 운영 데이터가 있으면 부하를 예측해 사전 확장할 수 있고, 장애가 나면 Failover 전략으로 다른 경로를 사용할 수 있다.
- Kubernetes의 HPA는 CPU 사용량 같은 지표를 기준으로 Pod Replica 수를 자동 조절한다.
- 동기 작업을 길게 연결하면 앞 단계가 끝날 때까지 다음 단계가 막히므로 Queue를 사용해 비동기 처리할 수 있다.
- Redis, RabbitMQ, Kafka 같은 구성 요소는 규모와 요구에 따라 Queue 또는 Stream 역할을 맡을 수 있다.
- Worker는 Queue에서 작업을 가져와 처리하고, 성공·실패·지연 시간을 Monitor로 관측할 수 있다.
Flogy 작업과 연결한 내용
- 에이전트 Runtime의 각 작업을 Worker가 처리하는 Job으로 볼 수 있다.
- State와 Event를 파일 또는 구조화된 데이터로 기록하고 Monitor가 주기적으로 읽으면 Viewer에서 현재 단계와 성공·실패를 표시할 수 있다.
- Viewer는 화면만 만드는 일이 아니라, Runtime이 일관된 Event와 상태를 내보내야 가능한 관측 계층이다.
결론과 다음 행동
- 이번 1차에서는 Linux, 가상화, Container, Cluster, Network, 신뢰성의 큰 구조를 잡는 것으로 마무리했다.
- Kubernetes의 상세 Resource, Service, Ingress, PVC 등은 2차 스터디에서 다룬다.
- 홍용재는 배운 용어를 기존 서버와 Flogy Runtime 구조에 직접 대응해 보고 질문을 정리한다.
- 김희성은 다음 시간에 Kubernetes의 기본 구성과 실제 운영 사례를 이어서 설명한다.