[🛠] IT Operations #2: 회사 서비스용 Linux 서버, 설치보다 운영 구조를 먼저 세웠다

✨ GPT-5.6 Sol의 요약 　

전용 Ubuntu Server의 디스크·내부 SSH·고정 주소를 구성하고, 사람·AI Cell·업무 자동화 Runtime의 권한을 나눈 뒤 네트워크 전체를 Codex가 이어받을 운영 기반으로 정리한 기록.

드디어 회사 서비스 전용 Linux 서버를 세웠다.

그런데 이번에 만든 것은 Ubuntu가 부팅되는 컴퓨터 한 대가 아니었다. 사람과 AI, 업무 자동화 서비스가 한 서버 안에서 동시에 돌아가더라도 서로의 권한과 상태를 침범하지 않게 만드는 운영 기반에 가까웠다.

처음 SSD를 구했을 때만 해도 생각은 단순했다. Windows PC에 Linux를 깔고 SSH로 접속하면 서버가 되는 것 아닌가 싶었다. 곧바로 GUI부터 고민했다. 괜히 서버답게 보이겠다고 CLI만 고집하다가 나중에 브라우저 로그인이나 Computer Use가 필요해지면 피 보는 것 아닐까 싶었다.

막상 하나씩 따져보니 서버에 GUI가 있어야 할 이유와 내가 GUI를 써야 할 이유는 전혀 다른 문제였다. OAuth나 Codex 로그인이 필요하면 SSH 화면에 나온 주소를 MacBook 브라우저에서 열면 된다. Computer Use가 필요하면 내 Mac이나 업무용 기기에서 실행하고, Linux는 그 결과가 배포될 Runtime으로 두면 된다.

서버는 화면을 보여주는 기계가 아니라 계속 실행되는 환경이었다.

Windows 디스크를 지키는 UEFI·GPT·LVM 구성

설치 USB부터 헷갈렸다. Ventoy USB가 MBR이면 Ubuntu도 MBR로 설치되는 줄 알았고, 부팅 메뉴에 UEFI: USB, Partition 2가 나타나자 이것이 맞는 경로인지도 불안했다.

USB의 partition 방식과 Ubuntu를 설치할 SSD의 partition 방식은 별개였다. UEFI 항목으로 installer를 시작한 뒤 설치 대상 SSD만 정확히 고르면 됐다. 기존 Windows NVMe는 건드리지 않고, 새로 구한 250GB SSD에만 EFI System Partition, /boot, LVM과 root filesystem을 만들었다.

이 과정에서 가장 무서웠던 것은 Linux가 어려운 것이 아니라 엉뚱한 디스크를 지우는 일이었다. Windows의 시스템 예약 partition까지 보이니 지워도 되는 것처럼 느껴졌지만, installer에서 디스크 모델과 용량을 다시 대조하고 Ubuntu 전용 SSD만 선택했다. 기존 Windows 디스크는 그대로 남았다.

설치는 Ubuntu Server 24.04.4 LTS의 일반 구성을 선택했다. minimized도, Desktop image도 아니었다. GUI가 빠진 대신 SSH와 systemd를 중심으로 관리하고, 이후 Docker Runtime을 올리기 좋은 바닥만 남겼다.

고정 주소보다 먼저 필요했던 DHCP 예약과 내부 SSH

설치 중 유선 LAN은 DHCP로 바로 주소를 받았다. 처음에는 여기서 Create bond를 누르면 SSH가 더 잘 연결되거나 주소가 고정되는 줄 알았다. 하지만 bond는 여러 NIC를 묶어 이중화하거나 대역폭을 합칠 때 필요한 기능이었다. 단일 유선 NIC 한 장의 주소를 고정하는 문제와는 관계가 없었다.

서버 안에 임의의 static IP를 박는 대신 메인 공유기에서 NIC의 MAC 주소와 내부 IP를 DHCP 예약으로 묶었다. 서버는 계속 DHCP client로 남지만 재부팅해도 같은 주소를 받는다. 공유기에서 다른 예약 장비와 충돌하는지도 함께 볼 수 있다.

SSH도 인터넷에 열지 않았다. MacBook에서만 쓸 전용 Ed25519 key를 만들고, 서버 host key를 콘솔에서 대조한 뒤 내부망 주소에 고정했다. 공유기의 외부 22번 port forwarding은 만들지 않았다.

설치 직후 ssh.service가 disabled라고 나와 잠깐 잘못 설치한 줄 알았다. 실제로는 ssh.socket이 활성화돼 22번 port를 듣고 있었고, 재부팅 뒤에도 public-key login이 반복해서 성공했다. socket activation은 요청이 들어올 때 해당 service를 시작할 수 있으므로 service 한 줄만 보고 장애라고 판단하면 안 됐다.¹

며칠 전 회사 공유기의 인터넷 장애를 고치면서 배운 DHCP lease, reservation, IP–MAC binding의 차이가 이번에는 그대로 서버 기반을 만드는 데 쓰였다. 주소 하나를 받았다는 사실과 그 주소로 안전하게 관리할 수 있다는 사실은 달랐다.

한 계정에 섞지 않은 사람·AI Cell·서비스

SSH가 붙고 나니 평소 하던 대로 Oh My Zsh, Powerlevel10k와 개인 alias부터 넣으려 했다. 여기서 다시 멈췄다.

설치할 때 만든 첫 계정은 bootstrap과 복구를 위한 회사 소유 관리자다. 내가 매일 쓰는 shell과 AI Runtime, Operations Automation까지 이 계정 하나에 몰아넣으면 편하기는 하다. 대신 누가 어떤 권한으로 무엇을 실행했는지 구분할 수 없고, 나중에 담당자가 늘거나 계정을 회수할 때 전부 얽힌다.

그래서 계정부터 다음 규칙으로 나눴다.

bootstrap 관리자
└─ 설치·복구에만 사용

usr-<person>
└─ 사람이 SSH·sudo·개발 작업에 사용하는 계정

aio-cell-<person>
└─ 개인 AI Cell이 계속 실행되는 계정

svc-<domain>-<purpose>
└─ 앱 Runtime, 데이터 importer, 제한된 operation broker

회사명이나 직무를 username에 넣지 않은 것도 의도적이었다. 사람은 같은 사람인데 소속과 역할은 바뀔 수 있다. Linux login은 안정적인 신원만 나타내고, 관리자·개발자·프로젝트 참여 같은 권한은 group과 RBAC에서 따로 바꾸는 편이 낫다.

내가 쓰던 OMZ·P10K·alias는 사람 계정에만 두기로 했다. AI Cell과 service account는 대화형 shell 설정을 읽지 않고, 고정된 systemd unit과 EnvironmentFile, 절대 경로로 실행할 계획이다. 예쁜 prompt는 내 작업 효율을 높이지만 서비스 안정성과는 아무 관계가 없다.

아직 이 계정들을 급하게 전부 생성하지는 않았다. 대신 이름, 소유할 파일, 로그인 가능 여부, sudo와 Docker 접근 범위를 먼저 확정했다. 빈 서버일 때 이 경계를 잡아두는 편이 이미 모든 것이 한 계정에 섞인 뒤 떼어내는 것보다 훨씬 단순했다.

AI Cell의 경계는 UID·HOME·OAuth까지 이어진다

이번에 가장 크게 이해가 바뀐 부분은 다중 사용자였다.

데스크톱 GUI만 보다 보면 지금 화면에 로그인한 사용자가 컴퓨터 전체를 점유하는 것처럼 느껴졌다. Linux에서는 보이는 로그인 화면과 실행 중인 사용자가 별개였다. 여러 사용자가 동시에 SSH로 접속할 수도 있고, 로그인하지 않은 service account의 process도 systemd 아래에서 계속 작동할 수 있다.

이 구조는 macOS 사용자 단위로 다시 정의했던 AI Cell을 Linux로 확장할 때 특히 중요했다. AI Cell 하나는 단순한 process 이름이 아니었다.

AI Cell 1개
= Linux UID·HOME 1세트
= OAuth·CODEX_HOME 1세트
= Gateway·Port 1세트
= Session·Memory·Workspace 1세트
= systemd unit·cgroup budget 1세트

사람별 Cell이 각각 다른 UID와 HOME을 가지면 인증과 기억, 작업 공간이 자연스럽게 갈린다. 각 Cell은 서로 다른 port나 Unix socket으로 뜨고, 사용자가 SSH에 로그인하지 않아도 부팅 뒤 systemd가 계속 실행한다. 한 서버 안에서 여러 Cell이 동시에 살아 있어도 한 Cell의 OAuth나 Memory가 다른 Cell의 fallback으로 사용되지 않는 구조다.

반대로 AI Cell에는 sudo, NAS 전체 mount, 운영 DB 관리자 credential, Docker socket을 주지 않기로 했다. Docker 공식 문서도 docker group이 사용자에게 root 수준의 권한을 준다고 경고한다.² 편하다고 사람·AI·service 계정을 그 group에 넣으면 앞에서 나눈 경계가 사실상 사라진다.

Docker 작업은 사람 관리자가 명시적으로 sudo를 쓰거나, root가 소유한 제한된 helper와 systemd unit이 정해진 operation만 수행하게 만들 예정이다. AI가 배포를 조율할 수는 있어도 임의의 shell과 Docker 전체 권한을 직접 갖지는 않는다.

NAS는 ingress로, Linux는 application Runtime으로

Linux 서버는 AI Orchestration만을 위한 장비가 아니다. Operations Automation의 Web·API·DB도 같은 장비에서 Docker Runtime으로 운영할 예정이다. 그렇다고 모든 것을 한 계정, 한 Compose project, 한 network에 넣는 것은 아니다.

외부 연결은 기존 NAS가 맡고 있는 HTTPS와 reverse proxy를 유지한다. Linux는 실제 application을 실행한다.

외부 사용자
→ HTTPS 443
→ 회사 공유기
→ NAS TLS·hostname reverse proxy
→ Linux frontend
→ Docker 내부 API
→ Docker 내부 DB

NAS의 관리 port, Linux SSH, API와 DB port를 인터넷에 직접 열 필요가 없다. NAS는 hostname과 인증서를 처리하는 ingress이자 storage·backup 지점으로 남고, Linux는 application Runtime을 맡는다. NAS로 연차 자동화를 옮기며 만들었던 외부 HTTPS 경로를 버리는 것이 아니라 최종 backend만 전용 서버로 옮기는 방향이다.

코드 배포와 NAS의 인사정보 반입도 같은 작업으로 묶지 않았다.

코드
→ release·artifact hash 확인
→ 제한된 deploy helper
→ health·rollback

인사 데이터
→ NAS의 승인된 read-only 폴더
→ staging·validation·preview
→ 승인
→ DB transaction·audit

AI Orchestration은 변경을 분석하고 승인을 요청할 수 있다. 하지만 실제 배포와 데이터 반입은 정해진 operation만 받는 broker와 importer가 나눠서 수행한다. MacBook은 개발과 dry-run, preview 확인, 승인된 작업의 시작점으로 쓸 수 있지만 운영 DB의 원본 변경 지점으로 두지 않는다.

현재 Linux 서버에는 아직 Docker와 application DB가 없다. 따라서 DHCP 예약과 SSH가 성공했다는 이유만으로 production backend라고 부르지도 않았다. 정확한 frontend port, health check, backup·restore와 rollback을 만든 뒤에만 NAS reverse proxy의 target을 바꿀 수 있다.

Codex Skill이 기억하는 전체 네트워크 topology

서버 설정만큼 중요하게 본 것이 다음 대화와의 연결성이었다.

공유기, 두 NAS, 기존 Mac Runtime, 새 Linux 서버, 외부 HTTPS와 내부 SSH가 어떻게 이어지는지를 회사 네트워크 전용 Codex Skill과 상세 인벤토리에 반영했다. 단순히 IP 목록을 적은 것이 아니라 각 장비가 맡는 역할과 트래픽의 시작점·중간 hop·최종 Runtime을 구분했다.

Skill에는 현재 완료된 사실과 앞으로 만들 구조도 섞지 않았다.

• Ubuntu 설치·재부팅·내부 SSH는 완료됐다.
• 다중 사용자 identity와 권한 경계는 결정했지만 계정은 아직 만들지 않았다.
• Linux의 Docker·AI Cell·Operations Automation은 아직 배포하지 않았다.
• NAS reverse proxy의 Linux 전환은 health와 rollback을 갖춘 뒤에만 진행한다.

이제 새 Codex 세션을 열어도 서버 IP가 무엇이었지?, NAS가 application을 실행하는 것인가?, SSH service가 왜 disabled였지?부터 다시 설명할 필요가 없다. Skill이 실제 topology와 보안 경계, 확인한 상태와 미완료 상태를 함께 전달한다.

그래서 지금의 서버는 완성된 production server는 아니지만, 그렇다고 Ubuntu만 깔린 빈 SSD도 아니다. 다음 작업은 이미 정해진 경계 안에서 사람 계정과 AI Cell, Operations Automation Runtime을 실제로 올리는 일이다.

이제부터는 무언가를 설치할 때마다 “어느 계정으로 실행할 것인가”, “어떤 HOME과 credential을 소유하는가”, “어느 port와 data flow만 허용할 것인가”를 먼저 묻게 될 것 같다. 서버를 한 대 만든 것보다, 서버를 계속 망가지지 않게 확장할 기준을 먼저 만든 느낌이 더 크다.

참고 자료

1. systemd의 socket unit은 socket을 감시하다 incoming traffic에 맞춰 대응 service를 활성화할 수 있다. systemd.socket 공식 매뉴얼 ↩

2. Docker daemon의 Unix socket에 접근할 수 있는 docker group은 root 수준의 권한을 부여한다. Docker Engine Linux 설치 후 단계 ↩