12. 개발 프로세스와 협업

데브옵스는 도구 묶음이 아니라 만드는 쪽과 운영하는 쪽 사이의 벽을 없애는 방식입니다. 도구는 그 방식을 떠받칠 뿐입니다.

벽이 있을 때 생기는 일

• 개발은 기능을 빨리 내보내려 하고, 운영은 바뀌지 않기를 바랍니다
• 장애가 나면 코드 문제인지 인프라 문제인지로 시간을 씁니다
• 배포 요청서를 넘기는 데 며칠이 걸립니다
• 운영에서 겪는 문제가 설계에 반영되지 않습니다

같은 팀이 만들고 운영하면 이 비용이 사라집니다. 자기가 새벽에 깨어나야 하는 코드는 애초에 다르게 짜게 됩니다.

애자일과 작업 흐름

	방식	맞는 자리
스크럼	고정된 주기로 묶어서 계획	범위를 미리 정할 수 있는 일
칸반	흐름에 따라 당겨서 처리	운영·대응처럼 예측이 어려운 일

운영 업무가 섞인 팀은 칸반 쪽이 맞는 경우가 많습니다. 스프린트 중간에 장애가 끼어들면 계획이 매번 깨지기 때문입니다.

둘 중 무엇을 쓰든 핵심은 진행 중인 일의 개수를 제한하는 것입니다. 여러 개를 동시에 붙잡으면 전부 느려집니다.

이슈와 변경을 잇기

작업과 코드와 배포가 서로를 가리켜야 추적이 됩니다.

이슈 PROJ-142
 └─ 브랜치 feature/PROJ-142-rate-limit
     └─ PR #318  (본문에 "Closes PROJ-142")
         └─ 커밋 a1b2c3d
             └─ 배포 v1.4.0

장애가 났을 때 "이 변경이 왜 들어갔는지"를 몇 초 안에 찾을 수 있습니다. 반대로 끊겨 있으면 커밋 메시지만 보고 추측하게 됩니다.

환경 분리

환경	쓰임	데이터
개발	각자 작업	가짜 데이터
스테이징	운영과 같은 구성으로 검증	익명화한 복사본
운영	실제 서비스	실제 데이터

스테이징이 운영과 많이 다르면 검증의 의미가 없습니다. 차이는 규모(인스턴스 수, 사양)에만 두고 구성은 같게 맞춥니다. 같은 코드형 인프라 모듈을 변수만 바꿔 쓰면 자연히 그렇게 됩니다(08. 코드형 인프라).

운영 데이터를 스테이징으로 그대로 복사하지 않습니다. 개인정보가 통제가 약한 환경으로 넘어갑니다. 익명화하거나 생성한 데이터를 씁니다.

코드 리뷰와 병합 정책

리뷰에서 사람이 볼 것은 의도와 설계입니다. 포맷·린트·테스트는 사람이 보기 전에 도구가 끝내야 합니다.

• PR을 작게 유지합니다. 500줄이 넘으면 리뷰가 형식적으로 변합니다
• "왜 이렇게 했는지"를 PR 본문에 적습니다. 코드만으로는 안 보입니다
• 막는 의견과 제안을 구분해 표시합니다
• 인프라 변경은 plan 출력을 PR에 붙입니다

테스트 자동화의 범위

파이프라인에 무엇을 넣을지 정합니다.

종류	비중	도는 시점
단위	많이	모든 PR
통합	적당히	모든 PR
E2E	적게	병합 후, 배포 전
부하	가끔	큰 변경, 정기

E2E를 늘리면 느려지고 불안정해집니다. 핵심 사용자 흐름 몇 개로 제한합니다. 범위를 늘리고 싶으면 단위·통합 쪽을 늘립니다.

런북

장애 대응을 기억에 맡기지 않습니다. 알림마다 대응 문서를 연결해 둡니다(10. 모니터링과 관측).

## API 오류율 급증

### 먼저 확인
1. 최근 30분 내 배포가 있었는가 → 있으면 롤백부터
2. DB 커넥션 수와 응답 시간
3. 외부 결제 API 상태 페이지

### 롤백
kubectl rollout undo deploy/api -n prod

### 그래도 안 되면
@백엔드-온콜 호출, #incident 채널 생성

새벽 3시에 읽을 문서입니다. 배경 설명이 아니라 다음에 할 일을 순서대로 적습니다.

온콜

• 순번과 교대 시간을 정해 둡니다
• 대응하면 보상합니다. 당연한 일로 두면 사람이 떠납니다
• 깨어난 알림은 다음 날 검토합니다. 울릴 만했는지, 자동화할 수 있는지
• 교대할 때 진행 중인 일을 넘깁니다

알림이 잦아 잠을 못 자는 상태가 이어지면 알림을 줄이는 일 자체를 작업으로 올립니다.

변경 관리

무엇이 언제 나갔는지 남깁니다. 릴리스 노트는 사용자용이기도 하지만, 장애 조사에서 먼저 보는 문서이기도 합니다.

위험이 큰 변경은 시점을 고릅니다.

• 금요일 오후와 연휴 직전은 피합니다. 문제가 생겨도 대응할 사람이 없습니다
• 트래픽이 적은 시간대에 내보냅니다
• 큰 변경은 되돌릴 방법을 먼저 적고 시작합니다

지표로 보는 팀

DORA에서 정리한 네 가지가 널리 쓰입니다.

지표	보는 것
배포 빈도	얼마나 자주 내보내는가
변경 리드 타임	커밋에서 배포까지 걸리는 시간
변경 실패율	배포 중 장애로 이어진 비율
평균 복구 시간	장애에서 회복하는 데 걸리는 시간

앞의 둘은 속도이고 뒤의 둘은 안정성입니다. 보통 상충한다고 생각하지만, 자주 작게 내보내는 쪽이 복구도 빠릅니다. 변경 폭이 작으면 원인을 찾기 쉽기 때문입니다.

숫자를 목표로 걸면 왜곡됩니다. 배포 빈도를 평가에 넣으면 의미 없는 배포가 늘어납니다. 흐름을 보는 용도로만 씁니다.