💡 핵심 인사이트
린(Lean) 소프트웨어 개발은 원래 도요타(Toyota) 자동차의 재고 관리 철학인 '린 생산 방식(낭비 제거)'을 메리 포펜딕 부부가 소프트웨어 공학에 이식한 방법론입니다.
핵심 철학은 **"고객에게 가치를 주지 않는 모든 군더더기(낭비)를 철저히 제거하고, 배움을 증진하며, 최대한 늦게 결정하고 최대한 빨리 배포하라"**는 7가지 원칙에 있습니다.

Ⅰ. 애자일(Agile)과 린(Lean)의 관계

애자일과 린은 종종 섞여 쓰이지만 뉘앙스가 약간 다릅니다.

• 애자일 (스크럼, XP): 짧은 주기로 변화에 유연하게 '적응'하는 실천적인 행동 방식에 가깝습니다.
• 린 (Lean): "군살 없는, 낭비 없는"이라는 뜻으로, 전체 시스템 관점에서 무엇이 낭비이고 무엇이 가치인지를 철학적으로 최적화하는 거시적인 원리입니다. 칸반(Kanban)이 린 사상을 구현하는 대표적인 도구입니다.

Ⅱ. 린 소프트웨어 개발의 7대 원칙 (필수 암기)

1. 낭비 제거 (Eliminate Waste) ★가장 핵심

소프트웨어에서 낭비란 '고객이 당장 원하지 않는 모든 것'입니다.

• 안 쓸 것 같지만 혹시 몰라서 미리 짜둔 코드(Extra Features), 결재 대기 시간, 쓸데없이 두꺼운 요구사항 명세서, 미해결된 결함(버그)은 모두 쓰레기통에 버려야 할 낭비입니다.

2. 학습 증진 (Amplify Learning)

소프트웨어는 건축처럼 한 번에 완성되는 게 아니라, 끝없는 실험과 피드백의 연속입니다. 짧은 반복(Iteration)과 프로토타입(MVP)을 통해 끊임없이 고객 반응을 측정하고 팀의 지식을 확장(학습)해야 합니다.

3. 결정 지연 (Decide as Late as Possible)

이 원칙이 제일 오해를 많이 받습니다. 일을 미루라는 뜻이 아닙니다. 비즈니스 환경은 매일 변하므로, 시스템의 핵심 아키텍처나 기술 스택을 프로젝트 첫날에 확정(성급한 결정)해 버리면 나중에 수정 비용이 막대합니다. 따라서 결정을 내릴 수 있는 구체적인 정보(데이터)가 완벽히 수집될 때까지 중요한 결정을 안전하게 가장 마지막 순간까지 미루라는 전략입니다.

4. 빠른 배포 (Deliver as Fast as Possible)

빨리 시장에 내놓아야 고객이 이 제품을 원하는지 안 원하는지 피드백(학습)을 빨리 받을 수 있고, 그만큼 코드가 낭비(Waste)되는 것을 막을 수 있습니다.

5. 팀에 권한 위임 (Empower the Team)

현장 상황은 실무 개발자들이 제일 잘 압니다. PM이나 경영진이 마이크로 매니징(지시)하지 말고, 실무자들에게 스스로 결정하고 툴을 선택할 수 있는 막강한 권한과 책임을 쥐여주어야 합니다.

6. 무결성 내재화 (Build Integrity in)

나중에 버그를 찾아서 고치지 말고(테스트 팀 의존), 애초에 코드를 짤 때부터 TDD(테스트 주도 개발)나 자동화된 CI/CD 파이프라인을 도입하여 제품 내부에 흠집 없는 품질(무결성)이 스스로 녹아들게 만들어야 합니다.

7. 전체 최적화 (Optimize the Whole)

DB팀은 최고인데 프론트엔드 팀이 느리면 결국 배포는 늦어집니다. 내 부서(Silo)만의 부분 최적화에 빠지지 말고, 가치 스트림 맵을 통해 기획부터 배포까지 회사 '전체 시스템의 병목'을 찾아내어 뚫어야 합니다.

📢 섹션 요약 비유: 린(Lean) 사상은 **'초밥 장인의 오마카세'**입니다. 손님이 남길지도 모르는 반찬 10개를 미리 만들어두는 낭비(Waste)를 하지 않고, 손님이 생선을 씹는 속도(학습)를 보며 가장 맛있는 밥알의 온도를 끝까지 고민하다가(결정 지연) 가장 신선한 1점을 1분 만에 쥐어서(빠른 배포) 손님 입에 바로 넣어주는 군더더기 없는 장인 정신입니다.