IT/작업기록

[인프라 공부] CI/CD, 혼자 개발해도 해야 하나?

aram 2026. 4. 22. 14:23

배경

CI/CD라는 말은 계속 들어봤는데, "이건 왜 하는 거지?" 싶었다. 특히 지금은 혼자 개발하는 상황이라 "팀 단위로 코드 충돌 막으려고 하는 거 아닌가, 나한텐 필요 없지 않나" 싶었는데, 찾아보니 오히려 1인 개발일수록 자동화의 가치가 크다는 이야기가 많아서 정리해봤다. (참고: elancer 블로그 - CI/CD란?)

CI/CD란

한 마디로 정리하면, 코드가 완성되어 사용자에게 전달되기까지의 모든 과정을 자동화하는 시스템이다. 코드를 수정해서 저장소에 올리기만 하면, 시스템이 알아서 빌드하고 테스트하고 서버에 배포까지 해주는 컨베이어 벨트 같은 개념이다.

CI (Continuous Integration, 지속적 통합)

코드를 자주, 자동으로 검사하고 합치는 과정이다.

  1. 코드를 공유 저장소(Git 등)에 올림
  2. 서버가 코드를 가져와서 실행 가능한 형태로 빌드
  3. 미리 짜둔 테스트를 자동으로 돌려서 버그 여부 확인

이 과정 덕분에 "내 컴퓨터에선 잘 되는데?" 같은 상황을 방지하고, 문제를 초기에 발견할 수 있다.

CD (Continuous Delivery / Deployment, 지속적 제공·배포)

CI를 통과한 코드를 실제 서비스 환경에 반영하는 과정이다.

  • 지속적 제공: 배포 직전 단계까지는 자동으로 진행하되, 실제 배포는 사람이 승인 버튼을 눌러야 진행되는 방식
  • 지속적 배포: 검증을 다 통과하면 사람 개입 없이 바로 실서버에 반영되는 방식

전체 파이프라인 흐름

일반적으로는 이런 단계를 거친다:

코드 Push (Source) → 빌드(Build) → 테스트(Test) → 배포(Deploy)
  • Source: 코드 수정 후 Git에 Push → 파이프라인이 트리거됨
  • Build: 소스 코드를 실행 파일이나 Docker 이미지로 생성
  • Test: 유닛/통합 테스트로 품질 검증
  • Deploy: 검증된 결과물을 운영/스테이징 서버에 반영

그래서 왜 하는가

  • 속도: 수동으로 하던 빌드/배포 시간을 크게 줄여준다
  • 안정성: 사람이 놓칠 수 있는 부분을 기계가 체크해서 배포 사고를 줄인다
  • 빠른 피드백: 코드를 올리자마자 테스트 결과가 나와서 문제 위치를 바로 알 수 있다

요약하면 "반복적인 빌드·테스트·배포는 기계에게 맡기고, 사람은 코드 짜는 데만 집중하자"는 게 핵심 철학이다.

1인 개발에도 필요한 이유

오히려 혼자 기획·개발·배포·운영을 다 책임지는 상황일수록 CI/CD의 가치가 더 크다는 게 요지였다. 몇 가지가 특히 와닿았다:

1. 실수 방지 — 혼자 작업하다 보면 배포 직전 긴장이 풀리거나 피로 때문에 사소한 실수를 하기 쉽다. 로컬 설정값을 그대로 배포해버리는 것 같은 환경변수 누락, "이건 간단하니까 괜찮겠지" 하고 테스트를 생략했다가 전체 기능이 마비되는 상황을 자동화된 테스트 단계가 막아준다.

2. 배포에 대한 심리적 장벽 제거 — 배포 과정이 수동(SSH 접속 → Git Pull → 빌드 → 서비스 재시작…)이면 점점 귀찮아지고 배포 주기가 길어진다. 코드 푸시 한 번으로 배포가 끝나면 작은 수정도 부담 없이 바로 반영할 수 있고, "저번에 어떻게 배포했더라" 하고 예전 메모를 뒤질 필요도 없어진다.

3. 개발에 쓸 시간 확보 — 파이프라인을 한 번 구축해두면 배포가 돌아가는 동안 다음 기능을 고민하거나 쉴 수 있다. 수동 배포에 드는 시간을 아껴서 실제 로직 구현에 더 쓸 수 있다는 것.

1인 개발 추천 전략 — 최소 비용, 최대 효율

처음부터 대규모 기업 수준의 복잡한 파이프라인을 만들 필요는 없다는 조언이 인상적이었다.

단계 추천 도구 특징

코드 관리 & CI/CD GitHub Actions 코드를 올리면 바로 실행, 설정이 간단
인프라 Docker 배포 환경 일관성 보장, "로컬에선 되는데 서버에선 안 됨" 방지
운영 Cloud PaaS/SaaS (Vercel, Render 등) 별도 설정 없이 자동 배포 환경 제공

결론

1인 개발에서 CI/CD를 처음 구축하는 데 드는 며칠의 시간은, 나중에 발생할 수십 시간의 삽질과 스트레스를 미리 막아주는 투자에 가깝다는 걸로 정리됐다. 일단 간단한 GitHub Actions 워크플로우부터 시작해보기로 했다.