90DaysOfDevOps (Day 37)

고태규·2025년 11월 2일

devops

DevOps

목록 보기

36/50

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 37 - The Lean DevOps Playbook: Make it a success from Day one

1. 린 데브옵스 (Lean DevOps)

전통적인 CI/CD 데브옵스 사이클은 아름답고 체계적이지만, 초기 스타트업에게는 맞지 않는 옷이다.

스타트업의 3대 원칙: 민첩성, 비용, 린(Lean) 스타트업의 성공은

가능한 한 민첩하게 (Agile)
가능한 한 저렴하게 (Cheap)
가능한 한 린 (Lean)하게

움직이는 것에 달려있다.

스타트업의 유일한 목표는 다음 펀딩(연료)을 받을 때까지 최대한 많은 사용자를 확보하며 생존하는 것이다.

따라서, 초기 스타트업은 대기업처럼 복잡한 빌드 사이클을 가질 필요가 없다.
대부분 하나의 모놀리식 앱이거나 소수의 MicroService이며, 수요 예측도 비교적 명확하다.

따라서, 복잡한 CI/CD 파이프라인과 유닛 테스트, 거대한 배포시스템은 스타트업에서는 오히려 속도를 저해하는 '기술 부채'가 된다.

2. 린 데브옵스 플레이북 6단계

해당 프레젠테이션에서는 복잡한 CI/CD 대신, 스타트업에 최적화된 단순하고 빠른 6단계 사이클을 제안한다.

1단계: Plan (계획)

목표: 정보 투명성, 불필요한 회의/문서 작업 최소화
핵심 전략:
- 명확한 제품 로드맵 : 린 제품 플레이북의 Kano 모델 (Must-have, Performance, Delighters)을 활용하여 분기별 릴리스 계획을 세워야함.
- 실행 관리 : 스프린트 (2주, 25 스토리 포인트)를 기반으로 무엇을 할지가 아닌 '언제까지 할지'를 명확히 정해야함.
- 회의 최소화 : 주간 스탠드업을 하되, 회의 전 메모를 공유하여 모든 논의가 빠르게 진행되도록 해야함.
추천 도구:
- 로드맵 : Notion, Miro
- 스프린트/실행 : Linear (강력 추천), Notion

2단계: Code (코드)

목표: 가독성, 협업 용이성, 모듈성 (스파게티 코드 방지)
핵심 전략:
- 모노레포 vs 폴리레포 : 앱이 여러 컴포넌트 (웹, 모바일 등)로 확장될 가능성이 있다면, 처음부터 폴리레포(Polyrepo) 구조를 고려해야함. (폴리레포 매니저는 변경된 부분만 빌드)
- 코드 구조 시각화 : 코드 구조를 시각화하면 신규 엔지니어의 온보딩이 빨라짐.
- 보안 내재화 : 배포 후가 아닌, PR과 CI/CD 파이프라인 단계에서 정적 분석 (Static Analysis)을 통해 보안 취약점을 즉시 확인
추천 도구:
- 폴리레포 매니저 : NX
- 코드 시각화 : Cod(e)See
- 보안 정적 분석 : Snyk (무료 플랜으로 시작 가능)

3단계: Test (테스트)

목표: 빠르고, 양보다 '질'이며, 고도로 자동화된 테스트
핵심 전략:
- 유닛 테스트의 함정 : "유닛 테스트는 스타트업 민첩성의 적이다."
  내부 로직을 증명하는 데 시간을 쏟기보다, 최종 사용자 경험이 완벽한지 확인하는 E2E 테스트가 훨씬 중요함.
- 정적 분석 : 코드 품질, 린팅, 복잡도 등을 CI 파이프라인에서 자동으로 검사
- E2E 테스트 자동화 : 코드 없는 (No-code) GenAI 기반 테스트 도구를 활용해 테스트 케이스 생성을 자동화할 수 있음.
추천 도구:
- 정적 분석 : Deep Source, Code Climate
- E2E 테스트 : Cypress, TestProject
- GenAI E2E 자동화 : Meticulous, OctoMind

4단계: Review (검토)

목표: 짧은 검토 주기, 쉬운 협업, 수동 작업 배제
핵심 전략:
- 기능 브랜치(Feature Branch) 전략 : main - staging - dev - feature 구조를 사용. 핵심은, 릴리스 단위가 아닌 개별 기능(Feature) 단위로 PR을 병합해야함. (Linear 사용 시 해당 방식이 강제)
- 원클릭 배포 및 리뷰 : PR이 생성될 때마다 '미리보기 링크'가 자동으로 생성되어야 하며, 이해관계자 (디자이너, 기획자 등)가 해당 링크를 보고 앱 UI에 직접 코멘트를 남길 수 있어야 한다.
추천 도구:
- 원클릭 배포/리뷰 : Vercel

5단계: Deploy (배포)

목표: CTO와 개발자의 정신적 부담을 줄이는, 빠르고 간단하며 확장 가능한 배포.
핵심 전략: 배포를 3가지 유형으로 단순화
- 유형 1: 프론트엔드 (Front-end)
  - Vercel을 사용을 하는 것을 추천.
  - 깃허브와 연동되고 확장성(Scalability)을 알아서 책임져 줌.
- 유형 2: 미디엄 리소스 (Middleware/Microservices)
  - Stripe 연동이나 간단한 API 같은 미들웨어
  - Digital Ocean Apps 또는 Google App Functions를 추천 (Vercel Edge Functions도 가능)
- 유형 3: 라지/헤비 리소스 (Heavy Backend)
  - 해당 경우 Docker와 Docker Compose를 첫날부터 사용하는 것이 맞음.
  - 글로벌 서비스가 필요하다면 Digital Ocean Droplets를 추천 (Droplet 이미지를 복사하여 전 세계 어디든 빠르게 배포 가능)

6단계: Observe (관찰)

목표: 투명하고, 단순하며, 통합된 모니터링.
핵심 전략: 프론트엔드, 백엔드, 오류, 개발자 생산성을 모두 관찰해야 함.
추천 도구:
- 프론트엔드 성능:
  - Vercel Analytics (실제 경험 점수 제공)
  - LogRocket (사용자 세션 녹화 및 네트워크 로딩 실시간 확인)
- 백엔드 성능:
  - New Relic (코드에 SDK 플러그인)
  - Sematext (도커 컨테이너 모니터링)
- 오류 추적:
  - Sentry (오류 우선순위 지정 및 개발자 할당)
- 개발자 생산성:
  - Code Climate (누가 막혀있는지, 생산성을 높일 방법은 없는지 확인)

3. 린 데브옵스 현실 조언

해당 프레젠테이션 발표자는 린 데브옵스 사이클의 모든 과정을 겪으며 CTO로서 배운 5가지 핵심 원칙을 공유하였다.

"무료 크레딧을 믿지 마세요."
AWS 같은 클라우드 스타트업 크레딧은 언젠가 만료된다. 그는 크레딧만 믿고 리소스를 관리하지 않았다가 크레딧 만료 후 엄청난 '요금 폭탄'을 맞았던 경험을 공유하였다.
따라서 발표자는 첫날부터 모든 것을 비용으로 간주하라고 조언하였다.
"멋져 보인다고 추가하지 마세요."
CTO 친구가 추천한다고 쿨해 보이는 기술을 스택에 추가하지 말 것을 조언하였다.
도구를 하나 추가할 때마다 기술 부채와 관리 오버헤드가 늘어난다.
꼭 "이 도구가 없으면 안 되는가?"를 자문함을 조언하였다.
"이해하지 못하면 추가하지 마세요."
단순함이 최고이다.
CTO인 당사자보다 완전히 이해하지 못하는 기술은 스택에 추가하는 것이 아니라고 조언하였다.
"혼자 하지 마세요."
CTO가 모든 데브옵스 짐을 혼자 짊어지는 실수를 저지르지 말라고 조언하였다.
팀을 신뢰하고, 모범 사례를 공유하며, 모두가 데브옵스 사이클에 참여하도록 해야 한다.
"수동적인 것을 자동화하고, 정기적으로 검토하세요."
배포, 테스트 등 수동으로 하는 모든 것은 자동화할 방법을 찾아야 한다.
그리고 이 린 데브옵스 사이클 자체를 6개월에 한 번씩, 또는 스타트업이 다음 마일스톤에 도달할 때마다 정기적으로 검토하고 개선해야 한다고 조언하였다.