# 느린 배포로 인한 회의 (2015)

> Clean Markdown view of GeekNews topic #18400. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=18400](https://news.hada.io/topic?id=18400)
- GeekNews Markdown: [https://news.hada.io/topic/18400.md](https://news.hada.io/topic/18400.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-12-23T10:13:46+09:00
- Updated: 2024-12-23T10:13:46+09:00
- Original source: [tidyfirst.substack.com](https://tidyfirst.substack.com/p/slow-deployment-causes-meetings)
- Points: 4
- Comments: 2

## Topic Body

##### 느린 배포가 회의를 유발함

- 소프트웨어 설계는 인간 관계의 연습임. 소프트웨어 개발에 사용하는 다른 기술들도 마찬가지임.
- "코드를 배포할 수 없을 만큼 회의가 많다"는 엔지니어의 불만은 배포 용량의 한계로 인해 발생할 수 있음.
- Chuck Rossi는 Facebook에서 한 번의 배포에 처리할 수 있는 변경 사항의 수가 고정되어 있다고 관찰함. 더 많은 변경 사항을 원하면 더 많은 배포가 필요함.
- Facebook은 지난 5년 동안 배포 속도를 주간에서 일일, 하루 세 번으로 증가시켰으며, 모바일 앱 배포 주기도 6주에서 4주, 2주로 줄였음.
- "배포당 변경 사항"은 비탄력적인 지표로, 개선은 가능하지만 시간이 걸림. 변경 사항이 현재 임계값을 초과하면 변경 사항 수를 줄여야 함.
- 조직적 오버헤드를 증가시키면 긍정적 피드백 루프가 시작됨: 작업량 감소 -> 압력 증가 -> 실수 증가 -> 배포당 변경 사항 감소 -> 오버헤드 증가 -> 작업량 감소.
- 더 많은 변경 사항을 처리하려면 배포 용량을 늘려야 함. 배포 주기를 줄이거나, 배포당 변경 사항을 늘리는 방법이 있음.
- 오버헤드를 줄이려는 시도는 결국 회의로 이어질 수 있음. 이는 너무 많은 코드를 배포하려는 시도를 막아줌.

##### 소프트웨어 설계: Tidy First?

- 소프트웨어 설계는 인간 관계의 연습임. 기술을 향상시키는 것이 관계를 개선하는 방법 중 하나임.

## Comments



### Comment 32666

- Author: roxie
- Created: 2024-12-24T15:21:04+09:00
- Points: 1

이 의견 좋네요

### Comment 32600

- Author: neo
- Created: 2024-12-23T10:13:46+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=42484139) 
- 배포의 위험을 줄이는 방법으로 테스트와 조직적 특성을 개선하는 것이 중요하지만, 유일한 접근법은 아님
  - 배포당 변경 사항의 수를 줄이는 것이 더 효과적임
  - 작은 변경 사항을 자주 배포하면 더 빨리 가치를 전달하고 작은 실패를 경험할 수 있음
  - 카나리 배포 및 점진적 롤아웃과 결합하면 배포가 더 이상 큰 위험이 아님
  - DORA 연구와 Accelerate, The Phoenix Project, The Goal에서 이 접근법을 지지함

- "소프트웨어 문해력"이라는 개념을 설명하려고 함
  - 회사가 코드로 운영될 수 있는 능력을 의미함
  - 모든 의사 결정자가 코드에 집중하지 않으면 소프트웨어 문해력이 부족한 것임
  - 회사는 새로운 개념으로 운영될 수 있어야 함

- CI 파이프라인에서 테스트 시간이 길어져 회복에 집중하기로 결정함
  - 테스트를 단순화하고 회복에 집중하여 배포 전략으로 카나리를 사용함
  - 이 접근 방식이 신선한 경험이었음

- 조직은 배포 개선을 방해할 수 있음
  - 관료주의와 싸우는 것은 대부분의 조직에서 불가능함
  - 느린 배포가 문제이지만 유일한 문제는 아님

- 큰 변화에 대한 두려움으로 인해 테스트가 증가함
  - 회의가 목표가 되는 경향이 있음
  - 비기술적 관리와 기술적 변화를 이끄는 방법에 대한 조언이 필요함

- CloudFormation이 느린 이유에 대한 질문

- 마이크로서비스는 배포 빈도를 수평적으로 확장할 수 있게 함

- 소프트웨어 성능, 즉 인간의 성능이 중요함
  - 빠른 반복과 위험 감소를 위해 빠른 테스트 자동화가 필요함

- 빠른 배포는 사건 대응 회의를 유발함