Jenkins를 세팅하고 빌드 성공이라는 초록색 불을 볼 때의 쾌감은 잠시뿐입니다. 실제 서비스 반영 단계에서 계속 멈추거나, 배포는 되었는데 정작 서비스가 죽어버리는 현상을 몇 번 겪고 나면 현타가 오기 시작합니다. 결국 CI/CD 자동화를 위해 썼던 시간보다, 실패한 배포를 수동으로 복구하는 시간이 더 길어지는 주객전도의 상황이 벌어지는 것이죠. CI/CD가 아니라 수동 작업이 하나 더 늘어난 셈입니다.
이 글에서는 저 또한 FreeBSD 환경에서 Jenkins와 GitLab Runner를 연결하며 고민했던 지점들을 공유합니다. 단순한 설치법이 아니라, SSH 배포부터 ZFS 롤백까지, 운영 서버다운 ‘지속 가능한 파이프라인’을 어떻게 설계했는지 그 전체 흐름을 정리합니다.
1. FreeBSD에서 CI/CD 구조를 먼저 설계해야 하는 이유
많은 사람이 Jenkins 설치부터 시작하지만, 실제로는 서버 역할을 먼저 나누는 것이 더 중요합니다. 한 대의 서버에 빌드, 테스트, 배포를 모두 몰아넣으면 처음엔 편하지만 장애가 생기면 복구가 훨씬 어려워집니다.
기본 구조는 보통 이렇게 나뉩니다. Jenkins는 작업 흐름을 관리하고, GitLab Runner는 실제 빌드를 수행하며, 운영 서버는 배포만 담당합니다. 여기에 ZFS 스냅샷을 추가하면 롤백까지 준비됩니다.
특히 FreeBSD에서는 Docker 중심 구조보다 Jail 기반 분리가 더 예측 가능한 경우가 많습니다. 테스트 환경을 분리하고 제거하는 흐름이 단순해서 장기 운영에 유리합니다.
겉으로는 설치 문제가 아닌데 배포가 실패하는 경우가 많습니다. 대부분은 구조를 먼저 잡지 않고 도구부터 설치했기 때문입니다.
놓치기 쉬운 포인트는 “자동화”보다 “복구 속도”입니다. 배포가 빨라도 되돌리기 어렵다면 운영팀은 결국 수동 배포를 선택하게 됩니다.
2. Jenkins 설치와 초기 설정에서 자주 막히는 부분
Jenkins 설치 자체는 어렵지 않습니다. 문제는 Java 환경과 권한 설정, 그리고 서비스 자동 실행입니다.
FreeBSD에서는 pkg를 통해 Jenkins와 OpenJDK를 설치하고 rc.conf에 서비스 등록을 진행합니다. 여기서 자주 발생하는 실수는 root 계정 기준으로만 테스트하는 것입니다.
실제 운영에서는 Jenkins 전용 사용자 권한이 중요합니다. Git pull은 되는데 deploy.sh 실행이 안 되는 경우가 여기서 자주 나옵니다. 조회는 되는데 실행이 안 되는 상황이라 처음 보면 원인을 찾기 어렵습니다.
실무에서 자주 생기는 장면
웹 UI에서는 정상인데 실제 배포만 실패합니다. 대부분은 Jenkins 계정이 SSH 키를 제대로 읽지 못하거나 실행 경로가 달라서 발생합니다.
또 하나는 재부팅 이후 자동 실행 여부입니다. 서비스가 한 번 실행됐다고 끝이 아닙니다. 운영 서버에서는 서버 재시작 후에도 같은 상태가 유지되어야 합니다.
헷갈리기 쉬운 부분은 설치 성공과 운영 가능을 같은 의미로 보는 점입니다. 실제 차이는 재시작 이후에 드러납니다.
3. GitLab Runner 연동 시 실제로 중요한 설정
GitLab Runner는 등록보다 executor 선택이 더 중요합니다. shell executor를 쓸지, Jail 기반 분리를 할지에 따라 이후 유지보수 난이도가 달라집니다.
프로젝트가 하나라면 shell executor도 충분합니다. 하지만 여러 팀이 동시에 사용하는 환경이라면 빌드 환경 충돌이 자주 발생합니다. 이때 Jail 분리가 운영 안정성을 크게 높여줍니다.
특히 테스트 환경마다 다른 패키지 버전을 요구하는 경우, 단일 shell 구조는 생각보다 빨리 한계가 옵니다. 빌드 성공률보다 환경 일관성이 더 중요해지는 순간입니다.
많이 놓치는 부분은 Runner 등록 토큰보다 권한 범위입니다. 등록은 됐는데 실제 artifact 접근이 안 되는 경우가 자주 있습니다.
대부분 조건 자체보다 실행 순서에서 막힙니다. 먼저 프로젝트 구조를 보고 executor를 결정해야 덜 헤맵니다.
여기서 갈리는 핵심은 “지금 편한 방식”이 아니라 “6개월 뒤에도 유지 가능한 방식”입니다.
4. SSH 기반 자동 배포를 안정적으로 만드는 방법
CI/CD에서 가장 많은 실패는 배포 단계에서 발생합니다. 빌드는 성공했는데 운영 서버 반영이 안 되는 경우입니다.
보통 Jenkins에서 SSH Key를 통해 운영 서버에 접속하고, pull 또는 release 스크립트를 실행하는 방식으로 구성합니다. 여기서 중요한 것은 sudo 사용 여부와 배포 사용자 분리입니다.
운영 서버에서 root 직접 배포는 편하지만 위험합니다. deploy 전용 계정을 만들고 필요한 범위만 허용하는 방식이 더 안전합니다.
실제로 자주 막히는 지점은 파일 권한입니다. 새 버전은 올라갔는데 nginx가 읽지 못하거나 서비스 재시작 권한이 없는 경우가 많습니다.
실수 방지 포인트
배포 스크립트는 “성공했을 때”보다 “실패했을 때 무엇을 남기는가”가 더 중요합니다. 로그가 없으면 자동화는 오히려 더 위험해집니다.
자동 배포는 버튼 하나가 아니라 책임 흐름입니다. 누가, 어디까지, 어떻게 되돌릴 수 있는지가 보여야 실제 운영이 됩니다.
놓치기 쉬운 포인트는 성공 로그보다 실패 로그입니다. 장애는 항상 성공 화면 밖에서 시작됩니다.
5. ZFS 스냅샷으로 빠른 롤백 준비하기
배포 자동화만 있고 롤백 전략이 없다면 운영팀은 결국 배포를 두려워하게 됩니다. 그래서 FreeBSD에서는 ZFS가 사실상 CI/CD의 마지막 단계가 됩니다.
배포 직전에 snapshot을 만들고, 문제가 발생하면 즉시 rollback 하는 구조를 준비합니다. 이 방식은 백업과 다릅니다. 복구 시간을 줄이기 위한 운영 전략입니다.
많은 사람이 백업 파일만 있으면 된다고 생각하지만, 실제로는 복구에 몇 분 걸리는지가 훨씬 중요합니다. 새벽 장애에서 10분과 2시간은 완전히 다른 이야기입니다.
스냅샷은 많이 만드는 것보다 정리 정책이 중요합니다. 오래 쌓이면 오히려 관리가 어려워지고 저장 공간 문제로 이어집니다.
복구 절차를 한 번도 테스트하지 않은 롤백 전략은 사실상 없는 것과 비슷합니다. 문서보다 실제 복구 시간이 더 중요합니다.
헷갈리기 쉬운 부분은 snapshot 생성 자체가 아니라 rollback 기준입니다. 언제 되돌릴지 기준이 없으면 결정이 늦어집니다.
FAQ
Q1. FreeBSD에서도 Jenkins를 실무에 사용할 수 있나요?
가능합니다. 오히려 장기 운영에서는 안정성이 높다고 느끼는 경우가 많습니다. 다만 설치보다 Java 환경과 권한 구조를 먼저 정리해야 합니다.
Q2. Docker 없이도 CI/CD 구성이 충분한가요?
네, 가능합니다. FreeBSD에서는 Jail 기반 분리가 더 단순하고 예측 가능한 운영이 되는 경우가 많습니다. 특히 운영 서버에서는 이 차이가 크게 느껴집니다.
Q3. GitLab Runner는 shell executor만 써도 괜찮나요?
작은 프로젝트라면 충분합니다. 하지만 팀이 늘어나거나 테스트 환경이 달라지면 Jail 분리를 함께 고려하는 편이 유지보수에 유리합니다.
Q4. ZFS를 꼭 써야 하나요?
필수는 아니지만 FreeBSD에서 빠른 롤백을 고려한다면 거의 항상 검토하게 됩니다. 배포 실패 이후 대응 속도에서 체감 차이가 큽니다.
Q5. 자동 배포에서 가장 먼저 확인할 것은 무엇인가요?
SSH Key보다 권한 흐름입니다. 누가 어떤 사용자로 접속하고 어디까지 실행 가능한지부터 명확해야 이후 문제가 줄어듭니다.
마무리
FreeBSD 환경에서 CI/CD를 구축하는 것은 도구 설치 자체가 아니라, ‘운영 구조 설계’를 완료하는 과정입니다. Jenkins를 설치하는 것보다 더 중요한 것은, 배포가 실패했을 때 얼마나 빠르게 예전 상태로 되돌릴 수 있느냐는 점입니다. 배포 속도는 중요하지만, 장애 복구가 느린 자동화는 오히려 독이 됩니다. 운영 서버에 필요한 가치는 ‘속도’가 아니라 ‘예측 가능성’입니다. 지금 Jenkins가 아니라 배포 이후의 불안감이 계속된다면, 플러그인 설정을 건드리기보다 전체 구조를 다시 돌아보는 것이 먼저입니다. 그 지점에서 FreeBSD와 Jail, ZFS가 보여주는 정직하고 견고한 운영 방식은 분명 이 글을 보시는 분들에게도 큰 해답이 될 것입니다.
면책 문구
CI/CD 구성 방식은 서비스 규모, 팀 구조, 보안 정책, 운영 인력에 따라 달라질 수 있습니다. 본 글은 일반적인 운영 방향을 정리한 정보성 가이드이며, 실제 적용 전에는 공식 문서와 현재 인프라 환경을 함께 검토하시기 바랍니다.