1인 개발자의 CI/CD 무중단 배포 구축기: GitHub Actions로 FastAPI 오라클 클라우드 서버 자동화하기

👤 인스피

조회 수 17

1. CI/CD 툴의 선택: 왜 무거운 젠킨스(Jenkins) 대신 GitHub Actions인가?

자동 배포를 구축하기 위해 구글링을 해보면 가장 많이 나오는 단어가 'Jenkins(젠킨스)'입니다. 하지만 젠킨스는 자바(Java) 기반의 꽤 무거운 프로그램입니다. 무료로 사용하는 오라클 클라우드 프리티어 인스턴스(RAM 1GB)에 젠킨스까지 올려서 돌리기엔 서버가 견디지 못하고 뻗어버릴 확률이 100%였습니다.

그래서 제가 선택한 대안은 GitHub Actions(깃허브 액션)입니다. 제 코드가 저장되어 있는 깃허브 자체에서 무료로 가상의 컴퓨터를 빌려주고, 코드가 업데이트될 때마다 제가 지정한 스크립트를 대신 실행해 주는 아주 고마운 녀석이죠. 제 서버 자원을 전혀 갉아먹지 않으면서도, 깃허브 저장소와 완벽하게 연동된다는 점이 1인 개발자에게는 최고의 메리트였습니다.

2. 배포 자동화의 로직 설계

파이프라인을 짤 때는 먼저 '사람(나)이 수동으로 하던 일'을 순서대로 나열해 보는 것이 좋습니다.

로컬(내 컴퓨터)에서 작업을 마치고 main 브랜치에 코드를 push 한다.
깃허브가 이를 감지하고, 가상의 우분투 컴퓨터를 켠다.
가상의 컴퓨터가 내 오라클 클라우드 서버에 SSH로 원격 접속한다.
오라클 서버 안에서 git pull을 받아 최신 코드를 덮어씌운다.
docker-compose up -d --build 명령어를 실행해 파이썬(FastAPI) 서버를 새롭게 띄운다.

이 흐름을 깃허브가 알아들을 수 있는 언어(YAML)로 번역만 해주면 됩니다.

3. 실전 적용: 배포 스크립트(Workflow) 작성하기

제 FastAPI 프로젝트 최상단에 .github/workflows/deploy.yml 이라는 폴더와 파일을 만들고, 아래와 같이 자동화 스크립트를 작성해 주었습니다.

코드에서 ${{ secrets... }} 부분은 제 서버의 IP나 암호 키가 대중에 노출되면 안 되기 때문에, 깃허브의 [Settings] -> [Secrets and variables] 메뉴에 안전하게 숨겨둔 환경변수들입니다. 이렇게 해두면 해킹의 위험 없이 안전하게 깃허브가 제 서버에 접근할 수 있습니다.

4. 첫 자동 배포의 쾌감: "진짜 알아서 켜지네?"

코드를 모두 작성하고 떨리는 마음으로 로컬 터미널에 git push를 입력했습니다. 그러고 나서 깃허브 저장소의 [Actions] 탭에 들어가 보니, 제가 짠 스크립트가 노란색 톱니바퀴를 돌리며 작동하기 시작했습니다.

약 30초 뒤, 톱니바퀴가 초록색 체크(✔) 마크로 변했습니다! 급하게 제 웹사이트 주소로 접속해 보았더니, 방금 제가 로컬에서 수정한 오타가 완벽하게 반영되어 운영 서버에 배포되어 있었습니다. 터미널 창을 열고, 접속하고, 명령어를 치며 기다리던 지루한 10분의 과정이, 그저 git push 명령어 단 하나와 30초의 기다림으로 단축된 것입니다. 눈앞에서 자동화의 기적이 펼쳐지는 순간이었습니다.

맺으며: 1인 개발자에게 자동화란 '선택이 아닌 필수'

흔히들 배포 자동화(CI/CD)는 덩치가 큰 실무 팀에서나 쓰는 거창한 기술이라고 생각합니다. 하지만 오히려 모든 것을 혼자서 다 해내야 하는 1인 개발자에게 시간은 가장 소중한 자원입니다. 배포에 쏟는 불필요한 에너지와 스트레스를 아껴서, 더 좋은 비즈니스 로직과 IT 칼럼을 쓰는 데 집중해야 하니까요.

"한 번도 수동으로 배포해보지 않은 자는 있어도, 한 번만 자동 배포를 해본 자는 없다."라는 개발자들의 농담이 무슨 뜻인지 이제야 뼈저리게 이해하게 되었습니다.

혹시 아직도 매번 서버에 SSH로 접속해 직접 코드를 끌어오고 서버를 껐다 켜는 노동을 반복하고 계신가요? 그렇다면 오늘 당장 GitHub Actions를 도입하여 여러분의 소중한 퇴근 시간을 10분 더 앞당겨 보시길 강력히 권장합니다.