키즈노트 CI/CD 파이프라인 진화기(1)
키즈노트 CI/CD 파이프라인 진화기: 없던 것을 만들고, 만든 것을 통합하기까지
Part 1 — 시작 전야: 플랫폼마다 달랐던 배포 풍경
1. Background
키즈노트, 그리고 그 안의 사람들
키즈노트는 어린이집과 유치원의 알림장을 디지털화한 서비스다. 선생님이 아이의 하루를 기록하면 부모에게 실시간으로 전달되는, 수백만 가정이 매일 사용하는 플랫폼이다.
서비스 규모만큼 개발 조직도 작지 않았다. 당시 개발자만 20~30명. iOS, Android, Frontend, Backend 네 개 파트가 각자의 영역을 맡고 있었고, Backend는 6개의 독립 서비스로 쪼개져 서비스마다 1~2명의 담당자가 붙어 있었다.
배포는 자주 일어났다. 개발 환경은 매일, 스테이징은 주 2~3회, 운영 배포는 월 1회. 작은 것 같지만 플랫폼 네 개, 백엔드 서비스 여섯 개를 합산하면 매주 수십 번의 배포가 조직 어딘가에서 일어나고 있었다.
각자의 방식으로
문제는 그 배포들이 저마다 다른 방식으로 이루어지고 있었다는 점이다. 
Frontend는 Jenkins Freestyle Job이 있었다. 버튼을 누르면 돌아가는 수준이었지만, 그나마 자동화의 형태를 갖추고 있었다.
Backend는 달랐다. 일부는 Fabric의 fabfile로 배포 스크립트를 관리했고, 일부는 그조차 없었다. 서비스 담당자가 직접 서버에 SSH로 접속해 명령어를 하나씩 입력하는 방식이었다. 배포가 사람의 손과 기억에 종속되어 있었다.
iOS는 Jenkins 연동 자체가 없었다. 파트장이 직접 자신의 노트북에서 Xcode를 열고, Apple 계정으로 로그인해 수동으로 빌드하고 배포했다. Mac Mini가 있긴 했지만 그냥 개발 머신이었다.
Android도 다르지 않았다. Jenkins와 연결된 것이 없었고, 빌드와 배포 모두 수동이었다.
| 플랫폼 | 배포 방식 | 자동화 수준 |
|---|---|---|
| Frontend | Jenkins Freestyle Job | 버튼 실행 수준 |
| Backend | fabfile 또는 SSH 직접 접속 | 사람 의존 |
| iOS | Xcode 수동 빌드 / 수동 배포 | 없음 |
| Android | 수동 빌드 / 수동 배포 | 없음 |
수백 대의 VM, 그리고 복잡함
이 혼란을 더 키운 건 인프라 규모였다. 서비스별, 빌드 환경별, 파트너사별로 VM이 세세하게 쪼개져 있었고, 그 수가 수백 대에 달했다. 어느 서버가 어떤 서비스를 담당하는지, 어떤 방식으로 배포가 이루어지는지는 담당자 외에는 알기 어려웠다.
팀이 늘고 서비스가 늘어날수록 이 복잡함은 선형으로 커지지 않았다.
- 담당자가 바뀌면 배포 방법을 다시 파악해야 했다
- 장애가 나면 어떤 시점의 어떤 배포가 원인인지 추적하기 어려웠다
- 새 서비스가 추가될 때마다 배포 방식을 처음부터 다시 만들었다
- 팀 간에 서로 어떻게 배포하는지 알지 못했다
왜 지금인가
“하나의 공통된 도구로 관리해야 한다”는 인식은 서서히 공유되고 있었다. 각 팀이 제각각의 방식으로 배포를 유지하는 데는 한계가 있었고, 그 한계가 점점 눈에 보이기 시작했다.
선택지는 Jenkins였다. 이미 Frontend에서 사용 중이었고, 조직 내 인지도가 있었다. 또한, 명령어 위주인 배포 방식의 서비스들이 많은 특성상, 각기 다른 서비스들 배포 방식을 하나로 묶을 수 있는 툴은 Jenkins가 이점이 있었다. 문제는 Jenkins를 쓴다는 것 자체가 아니라, 어떻게 쓰느냐였다.
Freestyle Job은 스크립트가 Jenkins UI 안에 박혀 있어 코드 리뷰도, 이력 추적도 어려웠다. 배포 로직을 코드로 관리하고, 변경 이력을 남기고, 누구나 읽을 수 있는 구조가 필요했다.
그래서 Jenkins Scripted Pipeline으로의 전환이 시작됐다. 파이프라인 스크립트를 Git 레포에서 관리하는 것을 원칙으로 삼고, 네 개 플랫폼 전체를 하나의 방식으로 통일하는 작업이 본격적으로 시작된 것이다.
다음 글에서는 가장 먼저 손을 댄 Frontend Pipeline 구축 과정을 다룬다. Freestyle Job을 어떻게 Scripted Pipeline으로 전환했는지, 그리고 그 과정에서 팀과 어떤 대화를 나눴는지를 이야기할 것이다.
본 시리즈는 총 6부로 구성됩니다.
| 파트 | 제목 |
|---|---|
| Part 1 | 시작 전야: 플랫폼마다 달랐던 배포 풍경 ← 현재 글 |
| Part 2 | 첫 번째 삽: Frontend Pipeline 만들기 |
| Part 3 | Mobile로의 확장: iOS와 Android Pipeline 구축 |
| Part 4 | 마지막 퍼즐: Backend Pipeline 구축 |
| Part 5 | 중복을 코드로: Shared Library와 Git 기반 전환 |
| Part 6 | 회고: 없던 것을 만들고 통합하기까지 |