소프트웨어 공학 100 주제 시리즈의 65번째 글이다. (카테고리: 프로세스와 방법론)

한 줄 요약

린은 “적은 인원으로 빨리” 가 아니라 고객이 가치로 인정하지 않는 모든 활동을 보이게 하고 없애는 것이다. 소프트웨어에서 가장 큰 낭비는 대개 코드를 짜는 시간이 아니라 기다리는 시간, 다 하다 만 일, 아무도 쓰지 않는 기능이다.

왜 필요한가

한 기능이 요청부터 운영 반영까지 6주 걸렸다고 하자. 그동안 누군가 실제로 손을 댄 시간을 모두 더하면 며칠이다. 나머지는 우선순위 회의를 기다리고, 설계 승인을 기다리고, 리뷰를 기다리고, QA 환경을 기다리고, 배포 창을 기다린 시간이다.

팀이 “더 빨리 코딩하는 법” 을 고민하는 동안 리드 타임의 대부분은 손대지 않은 채 흘러간다. 린의 시선은 사람이 아니라 일을 따라간다. 일 하나가 시스템을 통과하는 동안 무엇을 기다리는지 보면, 개선할 곳이 코드 밖에 있다는 것을 알게 된다.

핵심 개념

제조에서 온 말

“린 생산(lean production)” 이라는 말은 MIT 국제 자동차 프로그램(IMVP)의 연구 조교였던 John Krafcik 이 1980년대 후반에 만들었다고 Lean Enterprise Institute는 정리한다. 그 바탕은 토요타 생산 방식(TPS)이다. 토요타는 TPS 의 두 기둥을 이렇게 설명한다.

기둥 토요타의 설명 소프트웨어 대응
지도카(jidoka) 이상이 생기면 설비가 감지하고 스스로 멈춘다 빌드·테스트가 깨지면 파이프라인을 멈추고 고친다
저스트 인 타임 필요한 것을, 필요할 때, 필요한 만큼만 만든다 요청이 당길 때 작업하고, 미리 만들어 쌓지 않는다

토요타 페이지는 지도카의 뿌리를 Toyoda Sakichi 의 자동 직기(정지 장치를 단 직기, 1896)에서 찾고, 저스트 인 타임의 기본 틀은 Ohno Taiichi 가 만들었다고 쓴다.

무다·무라·무리

Lean Lexicon은 무다(muda)를 “고객을 위한 가치를 만들지 않으면서 자원을 소비하는 모든 활동” 으로 정의한다. 짝이 되는 두 말이 있다.

  • 무라(mura, 불균일): 고객 수요와 무관한 들쭉날쭉한 일정, 몰아치다 노는 작업 속도.
  • 무리(muri, 과부하): 사람·설비에 설계 이상의 속도·힘·시간을 요구하는 것.

용어집은 무리를 없애려 부하를 고르게 하면 무라와 무다도 함께 준다고 설명한다. 스프린트 마지막 이틀에 몰아치는 팀(무라)이 야근으로 버티고(무리) 결국 결함과 재작업(무다)을 만드는 흐름이 정확히 이 구조다.

무다는 다시 두 종류로 나뉜다. 당장 없앨 수 없는 1종(예: 현재 기술로는 피할 수 없는 재작업)과 개선 활동으로 금방 없앨 수 있는 2종이다. 감사 대응 문서처럼 고객 가치는 없지만 지금은 필요한 일은 1종이다. 없애려 하기보다 줄이고 자동화한다.

일곱 가지 낭비, 제조에서 소프트웨어로

Ohno 가 꼽은 일곱 가지 낭비는 Lean Lexicon에 정리돼 있다. Mary·Tom Poppendieck 은 Implementing Lean Software Development(Addison-Wesley, 2006)에서 이를 소프트웨어의 낭비로 옮겼다.

제조 (Ohno) 소프트웨어 (Poppendieck) 흔한 모습
재고 다 하다 만 일 머지 안 된 브랜치, 배포 안 된 기능, 테스트 안 된 코드
과잉 생산 추가 기능 “혹시 몰라” 만든, 아무도 안 쓰는 옵션
과잉 처리 재학습 잊어서 다시 파악, 문서 없는 결정을 다시 추론
운반 인계(handoff) 기획 → 설계 → 개발 → QA → 운영으로 넘길 때마다 맥락 손실
동작 작업 전환 한 사람이 동시에 네 프로젝트
대기 지연 승인, 리뷰, 환경, 배포 창 기다리기
수정(결함) 결함 늦게 발견될수록 비싸지는 버그

“다 하다 만 일” 이 재고라는 대응이 특히 중요하다. 재고는 돈이 묶여 있고, 낡고, 결함을 숨긴다. 머지 안 된 3주짜리 브랜치도 똑같다.

일곱 원칙

Poppendieck 의 원칙은 2003년 첫 책과 2006년 책에서 표현이 조금 다르다. 2006년판 기준으로 정리한다.

원칙 실무 질문
낭비 제거 이 단계는 고객이 돈을 낼 가치를 만드는가?
품질 내재화(Build Quality In) 결함을 찾는 것이 아니라 애초에 못 생기게 하고 있는가?
지식 창출 실험·피드백으로 배우고, 배운 것을 남기고 있는가?
결정 미루기(Defer Commitment) 되돌리기 어려운 결정을 정보가 충분해질 때까지 미루고 있는가?
빠른 인도 아이디어에서 사용자 손까지 얼마나 걸리는가?
사람 존중 일하는 사람이 개선할 권한과 시간을 갖고 있는가?
전체 최적화 부분(내 팀, 내 단계)이 아니라 흐름 전체를 보고 있는가?

“결정 미루기” 는 오해가 잦다. 결정을 회피하라는 뜻이 아니라, 되돌릴 수 없는 결정을 그 결정이 필요한 마지막 책임 있는 시점까지 열어 두라는 뜻이다. 되돌리기 쉬운 결정은 빨리 내리고 바꾸면 된다.

“전체 최적화” 는 린의 핵심이다. 개발 팀만 빨라지면 QA 앞에 재고가 쌓이고, 리드 타임은 그대로다. 부분 최적화는 흔히 전체를 더 나쁘게 만든다.

실무 적용

가치 흐름 지도 그리기

Lean Lexicon 은 가치 흐름 지도(VSM)를 “제품을 주문에서 인도까지 가져가는 데 필요한 물질·정보 흐름의 모든 단계를 도식화하는 것” 으로 정의하고, 현재 상태 지도를 먼저 그린 뒤 목표 이미지인 미래 상태 지도를 그리라고 한다. 소프트웨어 팀용으로 단순화하면 이렇다.

요청 ─▶ 우선순위 ─▶ 설계 ─▶ 개발 ─▶ 리뷰 ─▶ QA ─▶ 배포
작업    0.5일       1일     3일    0.5일   1일    0.5일    = 6.5일
대기    10일        4일     2일    3일     5일    7일      = 31일

여기서 흐름 효율을 계산한다.

\[\text{흐름 효율} = \frac{\text{작업 시간}}{\text{작업 시간} + \text{대기 시간}} = \frac{6.5}{37.5} \approx 17\%\]

(위 수치는 예시다.) 이 지도가 말해 주는 것은 분명하다. 개발 3일을 2일로 줄이는 것보다 우선순위 대기 10일과 배포 대기 7일을 줄이는 쪽이 훨씬 크다.

미래 상태로 가는 처방

대기 원인 처방 관련 원칙
우선순위 회의가 격주 백로그 상위 몇 개를 항상 준비 상태로, 당기면 바로 시작 빠른 인도
리뷰 대기 작은 PR, 리뷰를 새 작업보다 우선하는 팀 정책 다 하다 만 일 줄이기
QA 환경 부족 PR 마다 임시 환경, 테스트 자동화 품질 내재화
배포 창 주 1회 자동 배포 파이프라인, 피처 플래그(SE100 #057) 빠른 인도
개발 → QA 인계 QA 엔지니어를 팀 안으로, 인수 기준을 먼저 합의 인계 낭비 제거

추가 기능 낭비를 재는 법

# 기능 플래그별 지난 90일 사용 이벤트로 "아무도 안 쓰는 기능" 후보 찾기
usage = {"export_pdf": 1840, "bulk_edit": 12, "legacy_theme": 0, "api_v1": 3}
candidates = [f for f, n in usage.items() if n < 20]
print("제거 검토 대상:", candidates)   # ['bulk_edit', 'legacy_theme', 'api_v1']

안 쓰는 기능도 테스트·보안 패치·마이그레이션 비용을 계속 낸다. 지우는 것도 개선이다.

흔한 오해와 함정

  • “린 = 인력 감축.” 원칙 목록에 “사람 존중” 이 들어 있다. 개선을 하는 주체가 현장의 사람이기 때문이다. 감축 수단으로 쓰면 아무도 낭비를 드러내지 않는다.
  • 활용률을 올리면 빨라진다. 모두를 100% 바쁘게 만들면 대기열이 길어진다(SE100 #064 의 리틀의 법칙). 린은 사람의 활용률보다 일의 흐름을 본다.
  • 낭비를 문서·회의로만 본다. 소프트웨어에서 가장 비싼 낭비는 다 하다 만 일, 추가 기능, 지연이다. 회의 하나 줄이는 것보다 3주짜리 브랜치를 없애는 쪽이 크다.
  • 도구를 사면 린이 된다. 가치 흐름 지도는 화이트보드로 충분하다. 핵심은 일 하나를 처음부터 끝까지 따라가 보는 것이다.
  • 1종 무다를 무리하게 없앤다. 규제 문서처럼 지금은 필요한 일을 “낭비” 라며 빼면 나중에 더 큰 비용이 든다. 줄이고 자동화하는 것이 맞다.

확인 문제

  1. 무다·무라·무리를 각각 소프트웨어 팀의 예로 설명하라.
  2. 제조의 “재고” 에 대응하는 소프트웨어 낭비는 무엇이고, 왜 위험한가?
  3. 작업 시간 4일, 대기 시간 16일일 때 흐름 효율은? 개발을 1일 줄이는 것과 대기를 8일 줄이는 것 중 리드 타임에 더 큰 효과는?
  4. “결정 미루기” 원칙이 우유부단과 다른 점은?
  5. 개발 팀만 두 배 빨라졌는데 리드 타임이 거의 그대로인 이유를 린의 원칙으로 설명하라.

풀이

  1. 무다: 아무도 안 쓰는 기능을 만드는 일. 무라: 스프린트 끝에 몰아치고 초반엔 한가한 리듬. 무리: 장기간 야근으로 버티는 일정.
  2. 다 하다 만 일(머지 안 된 브랜치, 배포 안 된 기능). 투입한 노력이 가치로 바뀌지 않은 채 묶여 있고, 시간이 지날수록 충돌·낡음이 생기며, 결함을 숨긴다.
  3. 4 / 20 = 20%. 개발 1일 단축은 리드 타임 20일 → 19일, 대기 8일 단축은 20일 → 12일. 대기 단축이 훨씬 크다.
  4. 결정 자체를 피하는 것이 아니라 되돌리기 어려운 결정만 정보가 충분해질 때까지 열어 두고, 되돌리기 쉬운 결정은 빨리 내린다.
  5. 전체 최적화 원칙. 병목이 개발이 아니라 리뷰·QA·배포 대기에 있었다면, 개발만 빨라져도 그 앞에 재고만 늘고 리드 타임은 줄지 않는다.

더 읽을거리 (References)