실무

시공관리 종합 솔루션 — 인프라 구축 & 배포 자동화

Data/Infra Engineer · 2024 · 1명 · 4 min read 읽기

베어메탈 서버 3대(Linux 2대, Windows 1대)를 직접 발굴해 OS 설치부터 RAID/LVM 구성, 컨테이너 기반 배포 환경까지 전체 인프라를 구축하고, 이종 OS(Linux/Windows) 간 아키텍처를 설계했으며, 이 위에 GitLab CI/CD 배포 파이프라인과 Apache Airflow 기반 운영 자동화를 구축해 개발~운영 전 주기를 담당했습니다.

Overview

사내 시공관리 종합 솔루션 개발을 위해, 서버실에 수년간 OS조차 설치되지 않은 채 방치되어 있던 베어메탈 서버 3대(Linux 전용 2대, Windows 전용 1대)를 직접 발굴하여 처음부터 끝까지 인프라를 구축했습니다. 솔루션 내 도면 변환 기능이 Windows 환경(Revit/애드인)에 종속되는 제약이 있어, Linux/Windows 이종 OS 간 아키텍처를 직접 설계해 하나의 파이프라인으로 통합했습니다. 이 인프라 위에 GitLab CI/CD 기반 배포 자동화와 Apache Airflow 기반 운영 자동화(라이센스 만료 알림, 일일 서버 점검 리포트)를 구축해, 인프라 설계부터 배포·운영까지 전 과정을 담당했습니다.

Constraints

별도 인프라 담당자 부재 — 서버 셋업부터 운영까지 단독 담당
도면 변환 모듈이 Windows(Revit/애드인)에 종속 → Linux 기반 웹 서비스와 이종 OS 아키텍처 필요
개발용/운영용(영업·현업 확인용) 배포 환경 분리 요구
라이센스 만료, 서버 상태 점검 등 반복적 운영 업무의 누락 리스크

Tech Stack

Ubuntu Server
Docker / Docker Compose
RAID 1 / RAID 5
LVM
Samba (SMB)
GitLab CI/CD
GitLab Runner
Apache Airflow
Shell Script
SMTP
Nginx

Learnings

인프라와 애플리케이션 아키텍처는 분리된 문제가 아니라 하나의 설계라는 것을 체감했습니다 — 이종 OS 제약을 먼저 이해해야 애플리케이션 구조(리소스 공유 방식, API 분리)가 나옵니다.
자동화는 편의 기능이 아니라 운영 리스크를 줄이는 핵심 장치입니다 — 사람이 매번 확인해야 했던 라이센스·서버 상태 체크를 Airflow로 자동화하면서 반복 업무 부담과 휴먼 에러 가능성을 크게 낮췄습니다.
방치된 자원을 활용 가능한 인프라로 되살리는 과정에서, 표준 셋업 문서화의 중요성을 다시 확인했습니다.

Problem

서버실의 서버 3대는 수년간 OS조차 설치되지 않은 상태로 방치되어 있었고, 별도 인프라 담당자가 없어 제가 직접 A부터 Z까지 구축해야 했습니다. 이 서버들은 데이터 플랫폼뿐 아니라 사내 핵심 솔루션인 시공관리 종합 솔루션의 개발/운영 인프라로도 함께 활용해야 했는데, 이 솔루션은 도면 변환(Windows 종속)과 웹 서비스(Linux 기반) 두 축을 모두 갖고 있어 이종 OS 간 안정적인 리소스 공유와 배포 전략이 필요했습니다. 또한 개발 중인 버전과 영업·현업이 확인하는 운영 버전의 배포를 분리해 안정성을 확보해야 했고, 라이센스 만료나 서버 이상 징후처럼 사람이 매번 수동으로 체크해야 했던 운영 업무는 반복성과 누락 리스크가 컸습니다.

Approach

서버 인프라 구축. Ubuntu Server 이미지를 직접 USB로 구워 베어메탈 서버에 OS를 설치하고, 용도별로 RAID 레벨(RAID1: OS 영역, RAID5: 데이터 영역)을 구분해 구성했습니다. LVM을 도입해 스토리지를 유연하게 확장·재배치할 수 있도록 했고, 모든 서비스는 컨테이너(Docker) 기반으로 배포해 서버 재구성·마이그레이션에 유연하게 대응할 수 있게 했습니다. Windows에 종속된 도면 변환 작업은 별도 Windows 서버에서 처리하고 Samba(SMB)로 Linux-Windows 간 리소스를 공유하는 이종 OS 아키텍처를 설계해, 여러 변환·비교 모듈이 하나의 파이프라인으로 동작하도록 통합했습니다. GitLab CI/CD. GitLab Runner를 Docker 컨테이너 기반으로 Ubuntu 서버에 올리고, master/develop 브랜치별로 `.gitlab-ci.yml`을 구성해 각각 운영(prod/stage) 서버와 개발(dev) 서버로 자동 배포되는 파이프라인을 구축했습니다. Apache Airflow 운영 자동화. 두 가지 자동화를 구현했습니다. 첫째, 솔루션에 연동된 각 모듈의 라이센스 만료가 임박하면 SMTP 연동으로 담당자에게 자동 알림 메일을 발송합니다. 둘째, 서버 운영에 필요한 정보(리소스 사용량, 상태 등)를 쉘 스크립트로 수집해 매일 오전 9시 출근 시간에 맞춰 요약 리포트를 이메일로 자동 발송하도록 스케줄링해, 팀 주간보고와 서버 점검 업무를 반자동화했습니다.

Key Decisions

스토리지 구성 — RAID1(OS) + RAID5(데이터) + LVM 이원화

Reasoning:

OS 안정성과 데이터 가용량을 동시에 확보하기 위해, OS 영역은 미러링(RAID1)으로 장애 시 즉시 복구가 가능하도록 하고 대용량 데이터 영역은 RAID5로 스토리지 효율과 이중화를 함께 확보했습니다. 여기에 LVM을 적용해 볼륨 크기를 유연하게 조정할 수 있게 해, 서비스 확장 시 재구축 없이 대응 가능하도록 했습니다.

Alternatives considered:

단일 RAID 레벨로 전체 디스크 통합 구성
파티션 고정 방식 (LVM 미사용)

이종 OS 아키텍처 — Linux 컨테이너 + Windows 전용 서버 + Samba 연동

Reasoning:

도면 변환 모듈은 Windows 환경에서만 동작해 완전한 Linux 통합이 불가능했습니다. 무리하게 하나의 OS로 통합하기보다 각 워크로드에 맞는 OS를 유지하면서 Samba로 파일 리소스를 공유하는 방식을 택해, 운영 복잡도를 낮추면서도 변환 파이프라인이 끊김 없이 동작하도록 설계했습니다.

Alternatives considered:

Windows 서버에 컨테이너 가상화 도입
별도 외부 변환 전용 서비스 사용

GitLab CI/CD — 브랜치 기반 자동 배포 (develop→dev, master→prod)

Reasoning:

개발 중인 기능과 영업·현업이 확인하는 최신 배포 버전이 섞이면 사고 위험이 커진다고 판단해, 브랜치 전략과 배포 대상 서버를 1:1로 매핑했습니다. Runner를 컨테이너 기반으로 올려 배포 환경 자체도 서버 재구성 없이 이식 가능하도록 했습니다.

Alternatives considered:

수동 배포(스크립트 실행) 유지
Jenkins 기반 파이프라인 도입

운영 자동화 도구로 Apache Airflow 채택

Reasoning:

라이센스 만료 알림과 일일 서버 점검 리포트 모두 "정해진 시각에, 실패 시 이력·로그 확인이 가능한" 스케줄링이 필요했습니다. 단순 Cron보다 실행 이력과 실패 여부를 UI에서 바로 확인할 수 있는 Airflow가 운영 안정성 측면에서 더 적합하다고 판단했습니다.

Alternatives considered:

Cron + 커스텀 로깅 스크립트
외부 SaaS 알림 서비스 연동

Result & Impact

방치된 베어메탈 서버 3대 → 개발/운영 인프라로 전환

서버 자산 재활용
develop/master 브랜치 기반 dev/prod 자동 배포 파이프라인 구축

CI/CD
라이센스 만료 알림 + 매일 09:00 서버 점검 리포트 자동화

운영 자동화

수년간 방치되어 있던 베어메탈 서버 3대를 처음부터 직접 구축해 시공관리 종합 솔루션의 개발/운영 인프라로 전환했습니다. Windows 종속 모듈과 Linux 웹 서비스를 아우르는 이종 OS 아키텍처를 설계하고, GitLab CI/CD로 브랜치별 자동 배포 체계를, Apache Airflow로 라이센스 만료 알림과 일일 서버 점검 리포트 자동화를 구축해 인프라 설계부터 배포·운영 자동화까지 전 과정을 단독으로 담당했습니다.

전체 프로젝트