산출량 최적화를 멈춰라 — 소프트웨어 엔지니어링은 '발견'의 문제다

본문

소프트웨어 조직이 딜리버리를 '생산 문제'로 오진한다는 진단에서 출발하는 글입니다. 공장처럼 핸들을 더 빨리 돌리면 기능이 더 많이 떨어질 것이라는 직관은 소프트웨어에서는 성립하지 않습니다. 코드 복제는 비용이 들지 않고, 우리가 시간을 들여 만드는 모든 것은 전례 없는 새로운 것이기 때문에, 엔지니어링은 생산 프로세스가 아니라 연속적인 발견(discovery)의 활동이라는 것이 저자의 핵심 논지입니다. 그리고 팀을 무작정 속도로 몰아붙이면 오히려 velocity가 떨어진다고 지적합니다.

일정이 밀릴 때마다 등장하는 세 가지 실패한 레버

첫째, 인력 추가입니다. Fred Brooks가 'The Mythical Man-Month'에서 수십 년 전에 확립한 원칙처럼, 늦어진 소프트웨어 프로젝트에 인력을 투입하면 더 늦어집니다. 둘째, 압박 추가입니다. 긴급함을 강제하면 엔지니어들은 테스트를 버리고 리팩터링을 건너뛰게 됩니다. 오늘 일주일의 산출물을 살 수 있을지 몰라도, 그 대가로 내일 수개월의 디버깅을 지불하게 됩니다. 소프트웨어 딜리버리는 마라톤이며, 지름길은 처리량을 영구적으로 갉아먹는 부채를 만듭니다. 셋째, 프로세스 게이트 추가입니다. 체크포인트와 CAB(Change Approval Board)는 통제의 환상을 만들 뿐, 실제로는 대기열(queue)만 추가합니다. 'Accelerate'에 문서화된 State of DevOps Report 데이터는 무거운 리뷰 게이트가 변경 승인 프로세스가 아예 없는 것보다 경험적으로 더 나쁘다는 점을 명확히 보여줍니다. 느리게 만든다고 통제가 생기지 않습니다.

공장 휴리스틱 vs 발견 휴리스틱

저자는 두 관점을 표로 대비합니다. 공장 휴리스틱은 리소스 활용률 최대화, 프로세스 게이트와 CAB 강제, 분기 단위 대형 배치 릴리스, velocity와 코드 라인 수 측정을 추구합니다. 반면 발견 휴리스틱은 피드백 지연 최소화, 자동화된 파이프라인으로의 통제 이전, 지속적인 소규모 배포, '아이디어에서 검증까지의 시간' 측정을 추구합니다. 발견이 본질이라면 목표는 학습 속도의 가속이 되어야 하며, 학습을 최적화하면 품질이 올라가고 계획 없는 재작업이 줄어들면서 속도는 자연스럽게 따라온다고 설명합니다.

실행을 위한 세 가지 운영 표준

첫째, 의미 있는 모든 변경을 가설(hypothesis)로 취급합니다. '이 코드가 X 결과를 낼 것이다. 배포하고 측정해 보자'라는 형식으로 작업을 프레이밍하고, 과학적 방법을 아키텍처와 제품 의사결정에 엄격히 적용합니다. 둘째, 학습 속도는 가설을 검증하는 속도에 의해 상한이 정해집니다. 결함 있는 설계가 드러나는 데 3개월이 걸리면 1년에 네 번만 배우지만, 20분이면 하루에 스무 번 배울 수 있습니다. 자동화된 테스트와 지속적 딜리버리 파이프라인은 바로 이 빠른 정보 수집을 위해 존재합니다. 셋째, 작은 단계로 배포해 변수를 격리합니다. 수백 개의 통제되지 않은 변수가 섞인 대형 분기 릴리스는 실패 시 '계획에 없던 미스터리'를 남기지만, 작은 반복 배포는 무엇이 왜 깨졌는지 즉각적인 명확성을 줍니다.

무엇을 측정할 것인가

추적하는 지표가 시스템의 행동을 결정합니다. 활용률, 스프린트 velocity, 코드 라인 수는 진전이 아니라 '바쁨(busyness)'을 추적하므로 그만 재야 합니다. 대신 검증의 지연 시간, 즉 아이디어가 사용자에게 도달하는 데 얼마나 걸리고 그것이 작동하는지 얼마나 빨리 확인할 수 있는지를 측정해야 합니다. 저자는 속도가 지친 엔지니어링 팀에 내릴 수 있는 명령이 아니라, 고빈도 학습에 맞춰 보정된 시스템의 자연스러운 부산물이라는 말로 글을 맺습니다. DevOps와 조직 운영에 관심 있는 독자라면 익숙한 주장들이지만, 생산 vs 발견이라는 프레이밍으로 깔끔하게 재정리한 글입니다.

원문: dev.to / 번역·요약: Trawling