당신의 개발/배포속도를 높일 9가지 방법 | 매거진에 참여하세요

“10배 개발자(10x developer)”는 실존하며, 그런 개발자가 되는 길은 하나가 아닙니다.
가장 현실적인 방법 중 하나는 다른 10명을 각자 10% 더 생산성 있게 만들어주는 것입니다.

이 글에서는 개인과 팀의 생산성을 높이는 방법을 다룹니다. 이는 회사에 큰 가치를 줄 수 있기 때문에, 당신의 커리어 성장에도 직접적인 도움이 될 수 있습니다.

우선 7가지 원칙을 소개하고, 이후 9가지 실질적인 실천 전략을 제시합니다.

소프트웨어를 잘 배포하기 위한 7가지 원칙

1. 속도 (Speed)를 빠르게

솔직히 말해서, 개발자들은 속도에 집착합니다.
만약 어떤 도구가 10ms 더 빠르다면, 전체 애플리케이션을 다시 작성할 의향까지도 있을 정도죠.

그런데 코드를 배포하는 빈도가 되면 우리는 훨씬 더 조심스러워집니다.
"혹시 문제 생길까봐 오늘은 넘기고, 내일이나 다음 주에 배포하자"는 식으로 말이죠.

Charity Majors가 말했듯, 조심스러움을 느낄 때 인간은 본능적으로 느려집니다.
우리 뇌에 각인된 “천천히 = 안전”이라는 감각 때문입니다.

하지만 소프트웨어는 다릅니다.
자전거를 타는 것과 같아서, 천천히 갈수록 더 위험하게 흔들립니다.

속도가 곧 안전이며, 작게 나누는 것이 곧 속도입니다.

왜 속도가 중요한가?

배포 속도가 느릴수록, 배포 전에 모든 걸 완벽히 확인하고 싶어지는 욕구가 강해집니다.
만약 몇 시간 걸려 배포한 직후에 치명적인 버그가 생긴다면,
그걸 고쳐 다시 배포하는 데 또 몇 시간이 걸리겠죠.

그래서 우리는 소프트웨어 개발의 모든 과정에서 속도를 추구해야 합니다:

• - 빠른 피드백 루프

• - 빠른 빌드

• - 빠른 테스트

• - 빠른 배포

• - 빠른 버그 수정

• - 빠른 롤백

속도는 단순한 편의가 아닙니다. 팀의 민첩성과 제품의 품질, 그리고 비즈니스 기회까지 좌우하는 핵심 요소입니다.

2. 신뢰성 (Reliability)을 높이자

두 번째 원칙은 신뢰성입니다. 우리의 시스템은 믿을 수 있어야 합니다.

특히 CI/CD 파이프라인이 불안정하다면, 그것만큼 치명적인 문제도 드뭅니다.

테스트가 가끔 실패하고, 다시 돌리면 통과되는 'Flaky 테스트',
배포할 때마다 무작위로 터지는 '불안정한 배포 환경'은 반드시 피해야 합니다.

"언제나 안정적으로 동작하는 시스템"을 목표로 삼아야 합니다.

3. 재현 가능성 (Reproducibility)을 높이자

복잡한 시스템을 만들고 유지하려면,
같은 행동(X)을 했을 때, 항상 같은 결과(Y)가 나와야 합니다.

만약 어떤 날은 X → Y이고, 또 어떤 날은 X → Z가 된다면,
그 시스템에 대한 신뢰는 무너질 수밖에 없습니다.

이를 위해 우리는 수작업이 아닌 스크립트와 코드로 모든 과정을 자동화해야 합니다.
즉, 수동 클릭, 콘솔 명령어 입력 없이 코드 기반의 인프라(IaC)와 자동화된 배포 프로세스를 갖춰야 합니다.

4. 평온한 온콜 근무 (Calm on-call rotations)

누구도 스트레스 가득한 온콜 근무를 원하지 않습니다.
만약 온콜이 항상 긴장되고 고통스럽다면, 팀의 사기는 떨어지고 이직률은 높아지며 기술 부채는 늘어납니다.

그래서 온콜을 더 평온하고 지속 가능하게 만드는 것은 개발 문화에서 명확한 우선순위로 다뤄져야 합니다.

온콜의 품질은 우리가 만든 시스템의 진짜 상태를 보여주는 리트머스 시험지가 될 수 있습니다.

5. 디버깅이 쉬운 시스템 (Easy to debug)

모든 개발자는 버그를 만듭니다.
시니어도, 테스트를 다 해도, 테스트 커버리지가 100%여도 버그는 발생합니다.
그래서 우리는 프로덕션 버그를 빠르게 고칠 준비를 항상 해야 합니다.

이때 중요한 것이 바로 속도와 디버깅 편의성입니다.

디버깅이 어렵고 수정 배포 속도까지 느리다면, 팀은 자연스럽게 QA 과정을 더 붙이고, 배포 주기는 길어지게 됩니다.
결과적으로 몇 주에 한 번만 배포하는 팀이 될 수 있습니다.

하지만 아무리 많은 QA를 해도 프로덕션에서만 발견되는 버그는 존재합니다.
결국 진짜 버그는 실제 환경(프로덕션)에서만 다 드러납니다.

따라서 우리는 디버깅이 쉬운 구조를 목표로 해야 합니다.

6. 셀프서비스형 인프라와 배포 (Self-serve infrastructure and deployments)

예전의 인프라/배포 방식은 이랬습니다:

• - 개발자가 데이터베이스가 필요하면 Ops 팀에 티켓 제출

• - 새로운 서비스가 필요해도 티켓 제출

• - 배포도 티켓 제출

이 방식의 문제는 명확합니다:

• - 개발자는 항상 대기 상태에 놓입니다.

• - 개발자는 인프라 성능을 직접 체감하지 못합니다.

• - 조직 전체가 느려집니다.

그래서 업계는 결론을 내렸습니다:
- 개발자가 직접 배포하고, 인프라도 자율적으로 운영할 수 있어야 한다.

이 방식은 더 빠르고, 병목이 적고,
실제 환경에서 코드가 어떻게 작동하는지에 대한 피드백도 더 빠르게 받을 수 있습니다.

7. 금요일에도 배포하라 (Ship on Fridays)

건강한 엔지니어링 조직은 하루에도 여러 번 배포합니다.
그리고 금요일에도 마찬가지입니다!

"금요일 배포는 금기다"라는 말이 있다면, 그건 아마 아래 중 하나 이상의 문제가 있다는 신호일 겁니다:

• - 배포가 신뢰할 수 없다

• - 배포 속도가 느리다

• - 모니터링과 알림 시스템이 없다

• - 앱이 디버깅하기 어렵다

• - 테스트가 없다

이 모든 것들은 반드시 해결해야 할 기술 부채입니다.

금요일 배포를 두려워하지 않을 때,그 팀은 진짜 성숙한 개발 문화를 가지고 있다고 말할 수 있습니다.

9가지 소프트웨어 배포 개선 전략

위의 원칙들을 바탕으로, 실제로 이를 실천에 옮기기 위한 9가지 구체적인 전략을 살펴보겠습니다.

1. 배포와 출시를 분리하라 (Decouple deploys from releases)

배포(Deploy)는 사용자 경험에 영향을 주는 코드 변경과는 다른, 소프트웨어의 빌드, 테스트 및 롤아웃 과정입니다.
하지만 출시(Release)는 사용자가 실제로 경험하는 중요한 코드 변경입니다.

전통적인 방법은 코드가 준비되면 이를 머지하고 배포한 후, 사용자가 새로운 기능을 보게 되는 방식입니다.

하지만 오늘날 기능 플래그(Feature Flag)를 활용하는 방법이 대세입니다.

기능 플래그란 무엇일까요?

기능 플래그를 사용하면 새 코드를 기존 코드와 병행하여 작성하고, 런타임에 기능 플래그를 통해 새 코드가 실행될지 구 코드를 실행할지 결정할 수 있습니다.

이 방식의 장점은 배포와 출시를 분리할 수 있다는 점입니다.

• - 배포 속도 향상: 코드를 준비되면 즉시 배포할 수 있습니다.

• - 출시 속도 향상: 기능 플래그를 사용해 언제든지 기능을 활성화하거나 롤백할 수 있습니다.

• - 점진적 출시(Progressive Rollout): 일부 사용자에게만 기능을 제공해 문제가 발생하면 소수의 사용자만 영향을 받도록 할 수 있습니다.

기능 플래그는 긴 생애를 가진 기능 브랜치보다 더 우수합니다. 병합 충돌을 줄이고, 오래된 코드 문제를 없애며, 팀의 효율성을 크게 향상시킵니다.

2. 지속적 배포 (Continuous Deployment, CD)

배포는 엔지니어링 조직의 심장과 같습니다. 일관된 배포 리듬을 유지하면 모멘텀이 생기고, 이는 조직에 필수적인 생명력입니다.

지속적 배포(CD)를 통해 코드를 가능한 자주 배포하세요.

매일 여러 번 배포가 가능해야 합니다. 모든 커밋은 배포되어야 하며, 작은 변경은 디버깅이 용이하고 이해하기 쉬운 배포를 가능하게 합니다.

코드를 작성한 엔지니어가 직접 PR을 머지하고, 실시간 모니터링을 통해 문제를 신속히 해결해야 합니다.

기능 플래그는 지속적 배포를 위해 필수적입니다. 긴 생애를 가진 기능 브랜치 대신, 팀은 작은 변경을 지속적으로 배포할 수 있습니다.

3. 알림 설정 (Set up alerts)

다음과 같은 이상 현상에 대해 알림 시스템을 설정하세요:

• - 빌드 실패

• - 배포 실패

• - 서비스 다운타임

• - 서버 비정상 상태

• - 예기치 않은 오류

• - 비정상적인 트래픽

• - 서드파티 서비스 상태 (많은 서비스는 상태 페이지를 제공하며, 이를 Slack에 구독할 수 있습니다)

알림을 설정하면 문제를 신속하게 인지하고 대응할 수 있습니다. 이미 알림이 설정되어 있다면, 이를 점검하고 개선할 필요가 있습니다.

• - 알림이 유용한지

• - 잘못된 알림이 너무 많이 발생해 무시되고 있는지

• - 추가해야 할 알림 항목은 없는지

4. 배포 속도 최적화 — 15분 이내가 목표

행복한 팀을 위한 배포 목표는 15분 이내입니다. 물론 배포 속도를 가능한 한 빠르게 하는 것이 중요하지만, 15분은 기본 목표로 설정할 만한 기준입니다.

이보다 길어지면 상당히 불편하고, 이보다 너무 빠르게 배포하려다 보면 추가적인 작업이 필요할 수 있습니다.

배포 속도를 향상시킬 수 있는 몇 가지 방법을 살펴보겠습니다.

a. 현재 배포 시간을 추적하고 측정하기

배포 시간을 측정해 현재 어떤 부분에서 시간이 많이 소요되는지 파악하는 것이 첫 번째 단계입니다.

이를 통해 개선이 필요한 부분을 집중적으로 개선할 수 있습니다.

b. 의존성 설치 속도 향상

의존성 설치는 시간이 많이 소요될 수 있는 부분이므로 이를 최적화하는 것이 좋은 첫 번째 단계입니다.

• 1) 더 빠른 패키지 관리자 사용
  - JavaScript를 사용하는 경우, pnpm으로 전환하는 것을 추천합니다. pnpm은 npm과 yarn을 대체할 수 있으며, 성능과 캐싱에서 큰 향상이 있습니다.

• 2) 설치 단계를 캐시하기
  의존성 설치 단계를 빌드 시스템을 이용해 캐시하면, 의존성이 변경되지 않은 경우 설치 단계를 다시 실행하지 않도록 할 수 있습니다.

  (도커 사용)

• c. 빌드 속도 향상

빌드 속도를 향상시키는 주요 방법은 더 빠른 번들러로 전환하는 것입니다.

• 1) Vite 사용하기
  만약 create-react-app을 사용하고 있다면, Vite로 전환하는 것이 훨씬 빠릅니다. Vite는 웹팩보다 월등히 빠른 성능을 자랑합니다.

• 2)Next.js 최신 버전으로 업그레이드
  Next.js를 사용하고 있다면 최신 버전으로 업그레이드하고, .babelrc 파일을 제거해 보세요.

• 최신 Next.js는 SWC를 사용하여 Babel보다 빠른 빌드를 제공합니다.

• 3) Turbopack 사용해 보기
  최신 Next.js는 --turbo 플래그를 사용하여 Turbopack을 사용할 수 있습니다. 하지만 아직 실험적 기능이라 모든 환경에서 완벽하게 동작하지 않을 수 있습니다.

d. 빌드 캐시 설정

도커를 사용할 경우, 빌드 캐시를 최적화할 수 있는 여러 가지 방법이 있습니다.

• - 빌드 레이어 최적화

• - 멀티 스테이지 빌드 사용

• - 원격 캐시 설정
  

• 도커는 기본적으로 로컬에서 캐시를 이용해 빌드를 빠르게 처리하지만, CI 환경에서는 원격 캐시를 설정해야 합니다. 이를 통해 CI 빌드를 더 빠르게 할 수 있습니다.

도커 문서를 참조하여 원격 캐시 설정 방법을 확인하세요.

e. 전체 캐시하기

만약 JavaScript 프로젝트를 진행 중이라면, 팀 전체와 CI가 공유하는 단일 캐시를 설정하는 방식으로 큰 성과를 얻을 수 있습니다.

이 방식은 매우 빠르게 빌드를 할 수 있게 도와줍니다.

• 1) 캐시 활용 방식:
  한 개발자가 로컬에서 빌드한 후 커밋을 CI에 푸시하면, CI는 로컬에서 캐시된 빌드를 다운로드하여 수초 내에 빌드를 완료할 수 있습니다.

• 또한, 팀원 중 다른 사람이 이미 빌드를 완료한 커밋을 CI에서 다운로드하여 동일한 방식으로 빠르게 처리할 수 있습니다.

• 2) 단일 패키지 작업:
  모노레포 환경에서는 한 번에 하나의 패키지에서만 작업하기 때문에, 캐시가 주로 한 패키지에 적용되므로 빌드 시간을 단축할 수 있습니다.

이 방식은 NX와 Turborepo와 같은 도구를 사용하여 구현할 수 있습니다.

• 주의사항:
  환경 변수 설정에 유의해야 합니다. 개발자가 로컬에서 프로덕션 빌드를 하면서 개발 또는 스테이징 환경 변수를 사용할 경우, CI에서 잘못된 환경 변수로 캐시된 빌드가 사용될 수 있습니다.

• 개발, 스테이징, 프로덕션을 위한 별도의 명령어를 설정해야 합니다.

5. 스테이징 환경을 미리보기 환경으로 대체

미리보기 환경은 풀 리퀘스트(PR)의 생애 주기와 연동된 임시 환경입니다.

PR을 열 때, 해당 PR을 위해 인프라가 자동으로 프로비저닝됩니다.

이 방법은 이해 관계자들이 코드를 머지하기 전에 생산 환경과 유사한 환경에서 변경 사항을 미리 볼 수 있게 합니다.

또한, PR이 머지되거나 닫히면 해당 환경은 자동으로 정리됩니다.

미리보기 환경은 오래 살아있는 스테이징 환경을 대체하는 더 나은 방법입니다.

스테이징 환경은 필요할 때만 실행되어야 하는데, 보통은 계속 실행됩니다. 또한 PR을 머지하기 전까지는 누구도 변경 사항을 검토할 수 없습니다.

미리보기 환경은 기능 플래그와 함께 사용됩니다.

더 큰 변경은 기능 플래그를 사용해야 하며, 해당 기능에는 여러 PR이 포함됩니다.

그러나 작은 변경 사항은 미리보기 환경에서 리뷰하는 것이 훨씬 효율적입니다. 기능 플래그를 관리하는 번거로움을 피할 수 있습니다.

6. 인프라 코드화 (Infrastructure-as-code, IaC)

배포가 자동화되어 있기를 바랍니다. 하지만 인프라가 자동화되지 않았다면, 대개 대시보드를 통해 인프라 구성을 클릭하여 정의하는 방식이 사용됩니다.

인프라 코드화(IaC)를 도입하면 자동화된 인프라 구성을 통해 많은 이점이 있습니다. 이점은 다음과 같습니다:

• - 재현성 또는 재구성 가능성

• - 일관성 및 표준화

• - 예측 가능성

• - 버전 관리

• - 협업 및 검토

IaC는 여러 형태로 제공될 수 있습니다. AWS를 사용할 경우, CloudFormation 또는 Terraform과 같은 저수준 방식이 있을 수 있으며,

제품 개발자를 위해 설계된 고수준 추상화도 있습니다. 예를 들어, Flightcontrol의 flightcontrol.json 또는 Render의 render.yaml 등이 있습니다.

7. 플랫폼 엔지니어링

플랫폼 엔지니어링은 새로운 용어일 수 있지만, 그 배경을 설명해 드리겠습니다.

예전에는 데이터 센터에서 직접 서버를 rack에 넣어야 했습니다. 인프라의 추상화 수준은 매우 낮았습니다.

그 후, AWS가 클라우드를 도입하면서 추상화 수준을 높였지만, 여전히 일반 개발자에게는 낮았습니다.

이로 인해 Heroku가 개발자들 사이에서 큰 인기를 끌었습니다. 그러나 이 기쁨은 오래가지 않았습니다.

Ops 팀은 Heroku와 같은 추상화가 대기업에는 맞지 않다는 사실을 깨달았습니다.

그래서 Ops 팀은 AWS 위에 새로운 추상화를 추가하고, 인프라 코드화 및 Terraform을 사용하게 되었습니다. 이는 잘 작동했지만, 여전히 개발자들에게는 너무 번거로웠습니다.

회사의 리더십은 운영 효율성을 높이고자 했고, 그 방법 중 하나가 개발자들에게 자체 서비스 인프라를 제공하는 것이었습니다.

이를 통해 우리는 운영팀과 개발팀 모두가 어느 정도 만족할 수 있는 내부 플랫폼을 만들게 되었습니다. 이 개념이 바로 플랫폼 엔지니어링입니다.

지금 많은 대기업들이 내부 플랫폼, 또는 내부 개발자 플랫폼을 구축하고 있습니다. 이 플랫폼은 내부 Heroku와 비슷하거나 순수 Terraform에 더 가까울 수 있습니다.

어쨌든 이 플랫폼의 세 가지 핵심 개념은 다음과 같습니다:

1. - 자체 AWS/GCP 계정에 배포

2. - 훌륭한 개발자 경험을 제공하는 자체 서비스 인프라

3. - Ops 팀은 기본적인 원시 기능들을 지정하고 커스터마이즈할 수 있음

8. 팀으로 일하기

회사 초창기에는 공동 창업자와 저 둘만 있었습니다. 우리는 각자의 기술 세트를 기반으로 명확한 업무 분담을 했습니다.

그는 백엔드 및 인프라 작업을 맡았고, 저는 웹 앱과 프론트엔드를 담당했습니다. 그때는 정말 잘 맞았습니다!

그러나 점차 엔지니어들을 채용하면서 처음에는 같은 업무 모델을 유지했습니다. 각자가 자신의 프로젝트나 기능을 따로 작업하는 방식이었습니다.

하지만 점점 뭔가 잘못된 느낌이 들기 시작했습니다.

우리는 협업에서 얻을 수 있는 이점을 놓치고 있었습니다. 각자가 대부분 혼자 작업하였기 때문에 아키텍처 설계에서 코드 품질까지 다양한 분야에 대해 다른 사람의 전문성을 활용할 수 없었습니다.

우리는 서로의 코드를 리뷰하긴 했지만, 누군가가 프로젝트에 대한 전체적인 맥락을 알지 못하다 보니 피상적인 리뷰만 할 수 있었습니다. “LGTM!” 정도였죠.

그러던 중, Swizec Teller의 블로그 포스트를 읽게 되었습니다.

그는 대부분의 팀이 실제로는 진정한 팀으로 일하지 않으며, 진정한 팀워크를 이루면 훨씬 더 효과적으로 일할 수 있다고 말했습니다.

우리는 이 포스트를 읽고 나서 진정한 팀워크로 일하는 방법을 선택했습니다.

이제는 여러 프로젝트를 동시에 진행하지 않고, 전체 팀이 하나의 프로젝트에서 시작부터 끝까지 함께 작업하는 방식을 채택했습니다.

처음에는 이 방식이 무섭고 어색했으며 잘 될지 의문이 들었습니다. 몇 달 동안 고생했지만, 이제는 몇 달이 지난 지금, 다른 방식으로 일하는 건 상상할 수 없습니다.

우리는 확신을 가지고 말할 수 있습니다. 팀은 팀으로 일해야 한다고. 모든 것이 개선되었습니다.

우리는 더 나은 기능을 출시하고, 버그는 줄어들었으며, 더 많은 엣지 케이스를 다루었습니다. 직무 만족도와 팀 사기는 증가했습니다.

이제는 진정한 협업을 하며, 슬랙 채널에서 마주칠 때 간단한 인사만 하는 수준의 관계가 아닙니다.

어떻게 이게 가능했을까요?

• - 작은 팀 (2-6명, 4명이 이상적)

• - 전체 팀이 하나의 프로젝트에 집중하고 함께 작업합니다.

• - Kickoff 미팅 (어떻게 빌드할지에 대해 깊이 논의)

• - 프로젝트를 작은 작업으로 분할 (보통 Kickoff 미팅에서)

• - 작은 PR을 하나씩, 하루에 적어도 하나씩

• - 빠른 리뷰: 블로커가 되지 않도록

• - 자신을 차단하지 않고 해결: 리뷰어가 없고 블로킹 상황이라면 안전한 PR을 직접 머지하세요

9. Trunk Based Development

다음 단계의 팀 생산성 향상 방법은 Pull Request를 없애고 main branch에 바로 커밋하는 것입니다.

진지하게 말하겠습니다.

이것을 트렁크 기반 개발(Trunk Based Development)이라고 합니다.

만약 이 개념이 처음이라면, 여러분은 아마 "이건 불가능하다. 어떻게 이런 방식이 될 수 있지?"라고 생각할 것입니다.

이 개념을 들어본 적이 있다면 아마도 “이 방식이 어떻게 가능한지 전혀 이해가 안 된다”는 생각을 하실 겁니다.

트렁크 기반 개발을 이해하기 쉽게 설명하자면, 마치 식당의 급식실처럼 생각할 수 있습니다.

여러분의 트레이가 바로 main branch입니다. 버거가 완성되면 트레이에 놓고, 감자튀김이 준비되면 트레이에 놓고, 밀크쉐이크가 준비되면 트레이에 놓습니다. 트레이가 가득 차면 끝입니다.

이것이 바로 트렁크 기반 개발입니다. 모든 기능은 준비되면 바로 main에 커밋됩니다.

서브태스크든 전체 프로젝트든, 상관없습니다. 왜냐하면 모든 것은 독립적이고 배포 가능한 상태로 작업되기 때문입니다.

main에 직접 커밋하는 것이 너무 급진적이라면, 그다음으로 가장 좋은 방법은 짧은 기간 동안만 존재하는 브랜치입니다.

여기서 말하는 짧은 브랜치는 정말 짧은 브랜치를 의미합니다.

가능한 한 pure trunk-based development에 가까운 방식을 원하셔야 합니다.

PR은 하루 이상 지속되어서는 안 됩니다. 프로젝트의 경우, 여러 개의 짧은 PR을 만들어 다른 사람들이 빠르게 리뷰하고 쉽게 머지할 수 있도록 합니다.

이렇게 해야 모멘텀이 생깁니다.

위는 원문을 번역 및 재가공한 글입니다. 원문은 아래에서 확인하실 수 있습니다.

https://dev.to/flybayer/9-ways-to-improve-how-you-ship-software-1pb9