린 소프트웨어 개발 마스터하기: 2022년 롤리 CTO를 위한 실용 가이드

적합한 소프트웨어 개발 방법론을 선택하는 것은 어려울 수 있습니다.

어찌 보면 당연합니다. 소프트웨어 개발은 항상 비용이 많이 들고 종종 완료까지 수개월에서 수년이 걸리는 과정이기 때문입니다.

린(Lean)은 가장 신뢰할 수 있는 소프트웨어 개발 철학 중 하나로, 낭비 제거와 빠른 제품 전달 최적화에 초점을 맞춥니다.

그 핵심 아이디어는 제품에 불필요한 기능을 넣는 대신 가능한 한 빨리 가치를 전달하는 데 집중하는 것입니다. 이렇게 하면 계획했던 것보다 더 많은 가치를 제공할 수 있습니다.

어떻게 시작해야 할지 확신이 서지 않는다면, 여기 단계별 가이드가 있습니다.

린 소프트웨어 개발 개요와 필수 린 원칙을 모두 다루겠습니다. 이 철학이 애자일과 어떻게 다른지 설명하고 린 역할과 책임을 다루겠습니다.

시작해 보겠습니다!

린 소프트웨어 개발이란?

린 소프트웨어 개발(LSD)은 린 원칙을 소프트웨어 개발에 적용한 것입니다.

린 원칙은 일본의 자동차 제조 거대 기업인 도요타(Toyota)가 제조 공정에서 개발 시간과 자원을 최적화하고 낭비를 제거하기 위해 처음 제시했습니다.

린 소프트웨어 개발 방법론은 같은 원칙으로 소프트웨어 개발자의 작업을 간소화하고 최적화합니다.

이는 LSD가 MVP(Minimum Viable Product, 최소 기능 제품) 전략을 따른다는 의미입니다. 이를 통해 개발 프로세스를 가속화하고 제품의 최소 버전을 시장에 빠르게 출시할 수 있습니다.

구축된 MVP는 사용자 피드백으로부터 배우고, 그 피드백을 바탕으로 추가 반복을 수행하여 불필요한 사전 계획 프로세스 단계를 모두 제거합니다.

린 소프트웨어 개발의 7가지 원칙은 무엇인가?

효율적으로 소프트웨어 제품을 구축하는 데 도움이 되는 린 소프트웨어 개발의 7가지 확립된 원칙이 있습니다.

모든 원칙에는 즉시 적용할 수 있는 실천 방법과 전술이 포함되어 있어 고객 가치를 극대화하고 프로세스에서 낭비를 피할 수 있습니다.

이 원칙들을 더 깊이 살펴보겠습니다.

이미지 출처

원칙 1: 낭비 제거

소프트웨어 개발에서 낭비란 고객에게 비즈니스 가치를 제공하지 못하고 제품 품질을 개선하지 못하는 모든 것을 의미합니다.

낭비 제거 원칙에 따라 소프트웨어 개발에서 불필요한 활동을 체계적으로 식별하고 제거하는 것이 필수적입니다. 다음 소프트웨어 개발 활동이 낭비에 기여합니다.

불필요한 코드 또는 기능: 고객에게 중요한 가치를 더하는 기능 개발만 우선순위를 두세요. 그 외의 것은 논의, 개발, 테스트에 시간을 필요로 하여 제품의 TTM(출시 시간)을 지연시킵니다.
완료할 수 있는 것보다 더 많은 작업 시작: 이는 시스템에 불필요한 복잡성을 더해 컨텍스트 스위칭, 핸드오프, 워크플로 중단을 초래합니다.
소프트웨어 개발 프로세스 지연: 지연은 최종 제품 전달과 피드백 루프를 늦춥니다.
불명확하고 변경되는 요구사항: 이는 팀의 집중력 부족, 재작업, 좌절, 궁극적으로 제품 품질 저하로 이어집니다.
관료주의: 좋은 조직과 관리는 필수적이지만, 필요한 것보다 더 많은 관료주의는 전체 소프트웨어 개발 프로세스를 지연시킵니다.
열악한 커뮤니케이션: IT 팀과 이해관계자 간의 비효율적 커뮤니케이션이 포함됩니다. 불필요한 지연, 좌절, 집중력 저하를 초래합니다.
부분적으로 완료된 작업: 불완전하고 부분적으로 끝난 일은 고객에게 가치를 더하지 않으며 팀원이 작업으로부터 배울 수 없게 합니다.
작업 전환: 계획 부족으로 소프트웨어 팀원을 작업 간에 이동시키면 피할 수 있는 지연, 커뮤니케이션 단절, 낮은 팀 사기, 열악한 작업 품질로 이어집니다.
코드 오류 및 품질 문제: 결함과 버그는 추가 작업을 야기합니다. 프로그래머가 현재 작업을 중단하고 버그 수정에 집중하도록 강제합니다. 결과는 포기된 작업, 지연된 계획, 낮은 고객 만족도입니다.

소프트웨어 개발 프로세스에서 낭비를 식별하고 제거하려면 사전에 정교한 계획을 세우는 것을 피해야 합니다. 대신 짧은 반복 후 정기 회의를 개최하세요.

팀원들은 진행 상황을 보고하고, 병목 현상을 강조하며, 다음 반복에서 구현할 변경 사항을 제안할 수 있습니다. 이는 지속적인 코드 개선을 위한 여지를 만듭니다.

원칙 2: 품질 내재화

모든 조직이 제품에 품질을 내재화하고 싶어 하지만, 모두가 효율적으로 할 수 있는 것은 아닙니다. 우리의 품질 보증 활동 중 일부는 과도한 코드 테스트를 통해 다양한 종류의 낭비를 초래합니다. 이는 시간 소모적이며 개발 비용을 크게 높입니다.

'품질 내재화' 원칙은 그런 문제들을 발생하기 전에 해결합니다. 나중에 광범위한 테스트에만 의존하는 대신, 처음부터 품질을 중요한 요구사항으로 삼아 모든 단계에 추가합니다.

린 개발에서 프로세스 전반에 걸쳐 품질을 보장하기 위해 사용되는 도구와 기법은 다음과 같습니다.

리팩토링: 정기적으로 실천하여 코드를 깔끔하고 구조화되게 유지하세요.
페어 프로그래밍: 한 명의 개발자 대신 두 명의 전문성을 활용하는 훌륭한 방법입니다. 결과적으로 모든 작업이 두 개발자에 의해 수행되어 더 효과적인 솔루션을 얻을 수 있습니다.
테스트 주도 개발(TDD): 코드 작성 전에 테스트를 먼저 작성하여 품질 문제를 피할 수 있습니다. 개발자가 코드가 어떻게 테스트될지 알기 때문에 모든 시나리오를 충족하는 코드를 작성할 가능성이 높습니다.
점진적 개발과 지속적 피드백: 이러한 피드백은 소중하며 좋은 품질을 보장합니다.
대기 상태 최소화: 코드 작성, 테스트, 버그 수정 사이의 시간을 최소화하면 컨텍스트 스위칭과 개발 주기의 지식 격차를 낮출 수 있습니다.
테스트 자동화: 지루하고 수동적이며 인적 오류가 발생하기 쉬운 모든 프로세스를 자동화합니다.

원칙 3: 지식 창출

단순해 보이지만 구현하려면 규율이 필요한 또 다른 린 원칙입니다. 여기서 학습을 통해 지식을 창출합니다.

팀은 이 원칙에 따라 가치 있는 학습을 문서화하고 보존해야 합니다. 이는 다음 도구들의 조합을 적용하여 수행됩니다.

코드 리뷰
페어 프로그래밍
문서화
충분히 주석 처리된 코드
지식 공유 세션
교육
요구사항 관리를 위한 자산 기반 설계 같은 방법론

원칙 4: 의사결정 연기

이 린 원칙은 책임 있는 의사결정에 관한 것입니다. 그러나 팀이 업무 약속에 대해 변덕스럽고 무책임해도 된다는 뜻은 아닙니다.

반대입니다. 이 원칙을 사용하면 팀은 옵션을 열어두고, 필수 정보를 지속적으로 수집하며, 필수 데이터 없이 어떤 약속도 하지 않음으로써 책임 있게 결정하도록 장려됩니다.

이는 다음을 의미합니다.

사전에 지나치게 상세한 계획 없음.
비즈니스 요구사항에 대한 철저한 이해 없이 아이디어에 약속하지 않음.
중요한 결정에 관한 필수 정보의 지속적 수집과 분석.

원칙 5: 빠르게 전달

종종 치밀하고 장기적인 계획이 비즈니스 성공의 열쇠라고 믿습니다. 하지만 불행히도 이는 전략의 모든 측면이 철저히 검토되고 합의된 후에야 엄격한 개발 마일스톤이 설정되고 소프트웨어 시장에 진입할 수 있음을 의미하기도 합니다.

이론적으로는 훌륭해 보이지만 실제로는 종종 문제를 야기합니다. 이 접근법으로 엔지니어들은 불필요한 기능과 수정되지 않은 버그 백로그를 가진 복잡한 모놀리식 시스템을 구축하는 데 많은 시간을 씁니다.

또한 끊임없이 변화하는 시장 시나리오와 고객 요구사항에 제품을 적응시키는 것을 제약합니다.

그렇기 때문에 린 엔지니어는 필수 기능만 가진 MVP(최소 기능 제품)를 구축하고 가능한 한 빨리 시장에 출시합니다. 사용자 피드백은 엔지니어가 배우고 그에 따라 수정하는 데 도움을 줍니다.

이는 고객 피드백을 기반으로 코드를 점진적으로 개선하고 가치가 없는 모든 것을 버리는 데 효과적입니다.

원칙 6: 사람 존중

린은 팀원을 통제하는 대신 권한을 부여하는 것을 목표로 합니다.

이 원칙은 기본적인 인간 예의를 넘어 프로젝트 내 신뢰를 생성합니다.

어떻게?

엔지니어는 자신의 지식과 판단에 기반해 결정을 내릴 자유를 얻습니다. 물론 충분히 경험이 있다는 전제하에 말입니다.

이런 접근법은 소프트웨어에 필요한 변경 사항을 빠르게 적용하는 데 크게 기여하며 개발자의 동기 부여도 유지합니다.

개발자를 코드만 쓰는 로봇이 아닌 유능하고 동기 부여된 전문가로 대우하는 것이 핵심입니다.

원칙 7: 전체 최적화

이는 소프트웨어 전달 프로세스 전체를 개선하는 데 집중해야 하며 개발 단계만 보는 것이 아님을 의미합니다.

서브 최적화(Suboptimization)는 소프트웨어 개발의 큰 문제입니다. 린 개발 팀이 서브 최적화 때문에 빠지기 쉬운 두 가지 악순환이 있습니다.

첫째는 속도를 위해 품질 기준을 충족할지 모를 열악한 코드 제품을 출시하는 것입니다. 개발자에게 어떤 대가를 치르더라도 전달하라고 압박하면 품질 기준을 충족하지 못할 수 있는 코드를 출시하게 됩니다.

이는 코드 복잡성을 증가시켜 더 많은 버그를 만듭니다. 이는 개발자에게 더 많은 일을 주고 빠르게 전달하라는 압박을 가중시킵니다… 그래서 순환이 멈추지 않고 계속됩니다.

두 번째 문제는 테스트에서 옵니다. 테스터가 과부하되면 개발자가 코드를 쓰고 테스트하고 피드백을 주는 사이에 긴 지연이 발생합니다. 이는 개발자가 결함이 있을 수 있는 코드를 계속 작성하게 만들어 많은 버그를 초래하고 더 많은 테스트를 필요로 합니다.

전체 최적화 원칙은 린 팀이 용량과 영향을 더 잘 이해하며 운영함으로써 그런 문제들을 제거하도록 장려합니다.

린 vs. 애자일: 주요 차이점

린과 애자일은 인기 있는 소프트웨어 개발 방법론입니다. 두 방법 모두 생산성과 빠른 전달을 장려하지만, 올바른 적용을 위해 차이점을 이해하는 것을 강력히 권장합니다.

살펴보겠습니다.

	린	애자일
기반	제조 부문에서 시작해 다른 부문으로 확장되었습니다.	소프트웨어 개발 부문에서 탄생해 다른 부문으로 확장되었습니다.
핵심 철학	이 방법론은 낭비 제거와 소프트웨어 개발에 대한 미니멀리즘 접근에 초점을 맞춥니다.	협업이 애자일 방법론의 핵심입니다.
원칙	린 소프트웨어 개발에는 7가지 원칙이 있습니다. 1. 낭비 제거 2. 품질 내재화 3. 지식 창출 4. 의사결정 연기 5. 빠르게 전달 6. 사람 존중 7. 전체 최적화	애자일 소프트웨어 개발에는 12가지 원칙이 있습니다. 1. 최우선은 고객 만족 2. 요구사항 변경 환영 3. 소프트웨어 자주 전달 4. 비즈니스 담당자와 개발자 일일 협력 5. 동기 부여된 개인 중심으로 프로젝트 구성 6. 대면 대화가 최선 7. 작동하는 소프트웨어가 진척의 주된 척도 8. 지속 가능한 개발 속도 9. 기술적 우수성과 좋은 설계에 지속적 주의 10. 단순성 11. 자기 조직화 팀 12. 정기적 반성과 적응
기타 차이점	1. 린은 안정적 워크플로에 관한 것입니다. 2. 린은 소프트웨어 개발 프로세스를 더 중요시합니다. 3. 린은 비용 절감에 적용 가능합니다. 4. 린은 불필요한 것을 제거하는 체계적 접근으로 제품을 만듭니다.	1. 애자일은 변화에 더 적응적입니다. 2. 애자일은 프로세스보다 작동하는 제품에 더 가치를 둡니다. 3. 애자일은 비용 절감에 사용할 수 없습니다. 4. 애자일은 지속적인 반응과 피드백을 통해 제품을 만듭니다.