💡 핵심 인사이트
지속적 통합(CI)은 여러 명의 개발자가 각자 짠 코드를 한 달 뒤에 한 번에 합치지 않고, 하루에도 수십 번씩 중앙 저장소(Git)에 올리면(Merge), 봇(Bot)이 알아서 코드를 조립(Build)하고 에러가 없는지 자동 테스트(Test)해 주는 XP의 핵심 실천 문화입니다.
나중에 코드가 충돌하여 터지는 '통합의 지옥(Integration Hell)'을 사전에 방지합니다.

Ⅰ. CI가 없던 시절의 "통합의 지옥 (Integration Hell)"

과거에는 프론트엔드 개발자 A, 백엔드 개발자 B, DB 관리자 C가 한 달 동안 각자 자기 자리(로컬)에서 코드를 짰습니다. 각자의 PC에서는 완벽하게 돌아갔습니다. 출시 전날인 D-1일, 3명이 모여 코드를 하나의 폴더에 합치고(통합) 서버를 구동시켰습니다.

  • 결과: 화면은 안 뜨고, 변수명은 충돌하고, DB는 터졌습니다. 이를 고치려면 수만 줄의 코드 중 어디서부터 꼬였는지 찾을 길이 없어 며칠 밤을 새우며 출시를 미뤄야 했습니다. 이것이 통합의 지옥입니다.

Ⅱ. CI(지속적 통합)의 원리와 파이프라인

"나중에 한 번에 아프지 말고, 매일매일 조금씩 아프자(Fail Fast)." 이것이 CI의 핵심 철학입니다.

CI의 3단계 톱니바퀴 (자동화 파이프라인)

  1. 커밋 (Code Commit): 개발자는 자기가 짠 작은 기능(예: 결제 버튼 추가)을 완성하자마자 퇴근 전에 중앙 Git 리포지토리(GitHub, GitLab)에 병합(Merge/Push)합니다.
  2. 자동 빌드 (Auto Build): 중앙 서버에 코드가 올라오는 순간, 젠킨스(Jenkins)나 GitHub Actions 같은 CI 로봇이 깨어나서 모든 개발자의 최신 코드를 한데 모아 실행 가능한 프로그램으로 컴파일(조립)해 봅니다.
  3. 자동 테스트 (Auto Test): 조립이 끝나면 CI 로봇이 수백 개의 '자동화된 테스트 스크립트(Unit Test)'를 돌려봅니다.
    • 성공 (Green): "코드 병합 성공! 안전합니다!"
    • 실패 (Red): 방금 철수가 올린 코드 때문에 결제 로직이 깨졌습니다! 로봇이 슬랙(Slack) 메신저로 전 팀원에게 **"철수의 코드 때문에 빌드가 깨졌습니다. 당장 고치세요!"라고 즉시 사이렌(알람)**을 울립니다.

Ⅲ. CI 성공의 필수 전제 조건 (Rule)

툴(Jenkins)만 깔아놓는다고 CI가 되는 것이 아닙니다. 개발 조직의 문화가 뒷받침되어야 합니다.

  1. 자동화된 테스트(TDD)의 존재: 개발자가 테스트 코드를 안 짜놓으면 CI 로봇이 조립은 해도 이 기능이 진짜 맞게 동작하는지(버그 유무)를 검증할 수 없습니다. 빈껍데기 CI가 됩니다.
  2. 매일 커밋(Daily Commit)의 의무화: 개발자가 혼자 코드를 1주일 동안 쥐고 있다가 올리면 여전히 통합의 지옥이 열립니다. 최소 하루 1회 이상 메인 브랜치에 코드를 밀어 넣어야 합니다.
  3. 깨진 빌드 최우선 복구: 누군가 똥을 싸서 CI 서버의 빌드가 실패(Red)하면, 팀 전원은 하던 모든 코딩을 즉각 멈추고 그 깨진 빌드를 복구(Green)하는 데 총력을 다해야 합니다. (도요타 공장의 안돈 코드를 당기는 것과 같습니다.)

📢 섹션 요약 비유: CI는 레고 공장의 **'실시간 자동 조립/검수 로봇'**입니다. 10명의 아이들(개발자)이 각자 방에서 레고 팔, 다리를 만들어 매일 공장에 던져 넣습니다. 로봇(CI 툴)은 부품이 도착할 때마다 몸통에 꽂아보고, 구멍이 안 맞으면 즉시 경고음을 울려 "네가 만든 다리 치수가 틀렸어!"라고 그 자리에서 고치게 만들어 나중에 거대한 괴물이 탄생하는 것을 막아줍니다.