애자일 소프트웨어 개발은 소프트웨어 구축 및 제공에 있어 패러다임의 전환을 의미합니다. 비즈니스 요구사항과 고객 선호도가 끊임없이 변화하는 세상에서 애자일 소프트웨어 개발은 적응성과 유연성에 대한 요구를 충족합니다. 이 가이드는 애자일 소프트웨어 개발 프로세스를 심층적으로 살펴보고, 핵심 개념, 방법론, 도구, 팀 역학, 과제, 그리고 최신 트렌드에 대한 통찰력을 제공합니다.
애자일 개발이란 무엇입니까?
애자일 개발은 점진적이고 반복적입니다. 접근 소프트웨어 개발에 있어서. 광범위한 계획과 예측 가능한 납품 일정을 강조하는 기존 방식과 달리, 애자일은 지속적인 피드백을 통한 적응력과 고객 만족에 중점을 둡니다.
애자일 개발의 중요성
애자일 소프트웨어 개발은 기존 폭포수형 소프트웨어 개발 모델의 많은 단점을 해결합니다. 신속한 반복과 조정을 통해 애자일은 최종 제품이 고객 요구를 충족하도록 보장하고, 더 나은 위험 관리, 제품 품질 향상, 프로젝트 가시성 향상, 그리고 프로젝트 통제력 강화를 제공합니다.
애자일 개발의 핵심 개념과 원칙
애자일 매니페스토에 명시된 12가지 원칙은 애자일 개발의 핵심입니다. 여기에는 초기 및 지속적인 고객 만족을 최우선으로 하는 것이 포함됩니다. 소프트웨어 제공변화하는 요구 사항을 환영하고, 자주 작동하는 소프트웨어를 제공하며, 프로젝트 전반에 걸쳐 비즈니스 담당자와 개발자 간의 긴밀한 협업을 장려합니다.
가치 중심 개발
애자일 개발 방법론의 주요 초점은 테스트된 소프트웨어를 실행하여 측정되는 비즈니스 가치를 지속적으로 제공하는 것입니다. 팀의 주요 초점은 계획, 추적 및 제공 단위인 제품 기능에 맞춰집니다. 팀은 실제 기능 외에도 이러한 기능을 지원하는 필수 문서와 아티팩트를 구축해야 합니다. 각 "기능"은 우선순위가 높은 비즈니스 가치에 초점을 맞춰야 하며, 단일 반복 작업으로 구현할 수 있을 만큼 작아야 합니다.
다양한 애자일 개발 방법론은 기능을 설명하기 위해 고유한 명명법을 사용하지만, 모두 동일한 것, 즉 제품 기능의 개별 단위를 다룹니다.
민첩한 소프트웨어 개발 방법론
여러 가지 방법론 스크럼, 칸반, 익스트림 프로그래밍(XP), 린 소프트웨어 개발(Lean Software Development)을 포함한 애자일 방법론은 여러 가지 범주로 나뉩니다. 각 방법론은 고유한 실행 방식을 가지고 있지만, 모두 고품질 소프트웨어의 신속한 생산을 촉진한다는 공통된 목표를 가지고 있습니다.
애자일 개발 프로세스
애자일 개발 프로세스는 순환적이며, 프로젝트 수명 주기 전체에 걸쳐 반복되는 여러 단계로 구성됩니다.
애자일 개발 주기 개요
이 주기는 프로젝트 계획으로 시작하여 기능을 설계, 개발, 테스트하는 반복적 개발 단계로 넘어가고, 다음 주기가 시작되기 전에 검토 및 회고로 마무리됩니다.
애자일 소프트웨어 개발은 릴리스와 반복이라는 두 가지 주요 단위로 구성된 제공 모델을 따릅니다. 릴리스는 여러 반복으로 구성되며, 각 반복은 마치 마이크로 프로젝트와 같습니다. 작업의 우선순위는 중요도에 따라 릴리스 내 반복에 할당됩니다. 이러한 맥락에서 작업은 기능, 개선 사항, 결함으로 정의될 수 있으며, 각 반복에 따라 구성됩니다. 다음은 이 프로세스를 설명하는 요약 다이어그램입니다.
애자일 개발 프로젝트는 고정된 길이의 반복이라는 꾸준한 리듬에 의존합니다. 각 반복은 팀이 목표를 달성할 수 있도록 새롭고 검증된 기능들을 끊임없이 생성합니다. 이러한 시간 제한 반복을 통해 도출된 기능들은 의미 있는 피드백을 제공하며, 이는 "지난달 예상 대비 얼마나 많은 작업을 완료했는가?", "전월 대비 얼마나 많은 작업을 완료했는가?", "이 반복 내에서 현실적으로 얼마나 많은 기능을 완료할 수 있는가?"와 같은 질문에 대한 답을 찾는 데 도움이 됩니다.
애자일 개발 릴리스 주기의 엄격한 마감일은 어려울 수 있지만, 팀의 집중력을 유지하는 데 도움이 됩니다. 긍정적이든 부정적이든 모든 사람이 확인할 수 있었던 마지막 반복 이후, 팀은 다음 반복을 위한 프로세스 개선에 집중합니다. 이를 통해 불필요한 기능 추가, 프로젝트 범위에 대한 모호함, 또는 범위 확장을 방지할 수 있습니다. 팀은 매주, 매일, 그리고 매 시간이 소중하다는 것을 이해하고 있으며, 정해진 시간 내에 비즈니스 가치를 극대화하기 위해 함께 노력합니다.
애자일 개발 프로세스의 반복적인 특성을 표현하기 위해, 서로 맞물리는 톱니바퀴를 비유적으로 사용할 수 있습니다. 각 톱니바퀴는 개발 주기의 각 단계를 나타내며, 톱니바퀴가 회전하는 속도는 해당 단계의 진행 속도를 나타냅니다. 각 톱니바퀴가 회전할 때마다 다음 톱니바퀴가 작동하고, 전체 시스템은 원하는 결과를 달성하기 위해 함께 작동합니다.
애자일 개발팀은 소프트웨어가 고객 수용을 위해 설계, 코딩, 테스트 및 통합되는 동안 매일 작업을 계획하고 완료합니다. 팀은 각 반복 작업에서 작동하는 소프트웨어를 계획, 테스트 및 제공합니다. 각 릴리스마다 팀은 소프트웨어를 계획, 테스트 및 프로덕션 환경에 배포합니다. 팀 협업과 소통은 애자일 개발 프로세스 전반에 걸쳐 이루어지며, 고도로 적응적이고 생산적인 라이프사이클 내에서 조율하고 성공적으로 제공합니다.
반복이 진행됨에 따라 팀의 효율성이 높아지고 각 반복의 마감일은 덜 부담스러워집니다. 팀이 프로세스에 익숙해지면 지속적인 개선, 학습 및 멘토링, 그리고 다른 모범 사례 구현에 집중할 수 있습니다.
애자일 프로젝트 계획
애자일 프로젝트 계획은 세부적이고 장기적인 계획을 세우는 것보다 제품 백로그를 구축하고, 기능의 우선순위를 정하고, 향후 반복 작업을 계획하는 것에 더 중점을 둡니다.
애자일 프로젝트 계획
애자일 프로젝트는 사전 계획을 허용하지만, 필요한 자원에 대한 책임을 져야 합니다. 애자일 계획은 추측이 아닌, 탄탄한 과거 데이터에 의존합니다. 애자일 계획의 가장 중요한 측면은 프로젝트 기간 내내 지속된다는 것입니다. 애자일 프로젝트에 참여하는 누구도 계획을 당연하게 여기지 않으며, 계획의 정확성을 지속적으로 입증해야 합니다.
애자일 프로젝트가 시작되면 초기 반복을 시작하고 고수준을 생성하기 위해 충분한 계획이 수행됩니다. 출시 계획 기능. 반복은 지속적인 계획의 주요 구성 요소입니다. 각 반복은 자체 계획에 "충분한" 분량을 할당받는 미니 프로젝트와 같습니다. 각 반복 시작 시, 팀은 구현할 기능 세트의 우선순위를 정하고 각 기능에 대한 기술 작업을 예측합니다. 이 계획 프로세스는 각 반복마다 반복됩니다.
애자일 개발 프로젝트는 일반적으로 워터폴 프로젝트보다 더 많고 더 나은 계획 수립을 필요로 합니다. 워터폴 프로젝트가 "성공적"이라고 여겨질 때, 프로젝트 라이프사이클 전반에 걸쳐 이해관계자들의 변화하는 요구와 발견 사항을 고려하지 않고 요구사항 문서에 처음 요청된 내용만 제공한다는 비판을 받는 경우가 많습니다. 이는 이해관계자들에게 최적의 결과를 제공하지 못할 수 있습니다. 워터폴 프로젝트는 원래 계획의 모든 결함을 그대로 반영하며, 원래의 정적인 상태에서만 "계획을 실행"할 수 있습니다. 견고하고 정확한 최신 데이터를 기반으로 하는 애자일 계획은 비즈니스 요구가 끊임없이 변화하는 불가피한 상황에 맞춰 우선순위와 범위를 합리적으로 조정할 수 있도록 합니다. 지속적인 계획은 팀과 시스템이 마감일까지 최대의 비즈니스 가치에 집중할 수 있도록 지원합니다.
애자일 프로젝트는 사전 계획 수립을 허용하지만, 필요한 자원에 대한 책임을 져야 합니다. 이러한 계획은 과거 데이터를 기반으로 하므로 정확성과 신뢰성을 보장합니다. 계획 프로세스는 프로젝트 전반에 걸쳐 지속되며, 각 반복은 하나의 미니 프로젝트처럼 기능합니다. 이 프로세스를 통해 팀은 기능 집합을 선택하고, 각 기술 작업을 파악 및 예측하며, 각 반복에 대해 계획 주기를 반복할 수 있습니다. 애자일 개발 프로젝트는 일반적으로 요구사항 문서의 초기 요청만 처리하는 워터폴 프로젝트보다 더 나은 계획 수립을 가능하게 합니다. 애자일 개발은 지속적인 계획 수립에 크게 의존하여 변화하는 비즈니스 요구에 유연하게 대응할 수 있습니다. 이러한 접근 방식은 필요에 따라 우선순위와 범위를 합리적으로 조정하는 데 도움이 됩니다.
애자일 개발에서는 릴리스와 반복, 이 두 가지 단계를 계획하는 것이 더 정확합니다. 릴리스 단계에서는 마감일까지 필요하고, 원하고, 없어도 되는 기능의 우선순위를 정합니다. 반복 단계에서는 우선순위에 따라 다음에 구현할 기능 세트를 계획합니다. 기능이 너무 커서 반복 단계에서 예측하거나 구현하기 어려운 경우, 기능을 더 세분화합니다. 기능은 반복 단계로 예약되고 작은 기술 작업으로 나뉩니다.
이러한 계획 방식은 적시 계획(Just-in-Time)이라고 하며, 대규모 선행 계획보다 더 정확합니다. 이 방식은 이용 가능한 정보의 수준을 필요한 세부 수준에 맞춰 조정합니다. 이렇게 하면 미래의 기능에 대해 추측하거나 이용 가능한 정보만으로는 뒷받침되지 않는 세부적인 계획에 시간을 낭비할 필요가 없습니다. 대신, 더 작고 관리하기 쉬운 단계로 계획을 세울 수 있습니다.
여러 팀, 제품 및 프로젝트에서 Agile 제품 요구 사항, 에픽, 스토리 및 목표를 관리하는 데 도움이 필요한 경우 Digital.ai Agility 그러나 권한을 얻는 것은 제작자와 사용자 모두에게 시간이 많이 걸리고 복잡할 수 있으며 크리에이티브 커먼즈 라이선스가 이를 해결할 수 있다.
상대 추정
애자일 개발팀은 계획을 간소화하고 복잡성을 줄이기 위해 상대 추정 기법을 자주 사용합니다. 특정 단위 길이를 기준으로 기능을 추정하는 대신, 소수의 상대 추정 단위로 분류합니다. 예를 들어, 팀은 1~5일, 1~3 스토리 포인트, 또는 4~80시간과 같은 범주를 사용할 수 있습니다.
상대 추정을 사용하면 각 범주가 서로의 대략적인 배수가 됩니다. 예를 들어, 3일짜리 기능은 1일짜리 기능보다 3배 더 오래 걸립니다. 상대 추정과 미리 정의된 추정 버킷이라는 개념이 이러한 논쟁을 방지하기 때문에, 기능의 단위가 17.5단위인지 19단위인지에 대한 논쟁을 피하는 것이 목표입니다. 각 개별 추정치가 정확하지 않을 수 있지만, 이러한 유형의 계획 프로세스를 사용하여 시간과 노력을 절약하는 전반적인 이점은 부정확한 추정치로 인한 비용보다 큰 경우가 많습니다. 팀은 프로젝트를 진행하면서 추정치를 점진적으로 개선할 것입니다.
특성이 최대 추정치를 초과하는 경우, 여러 특성으로 분할해야 합니다. 목표는 생성된 모든 특성을 단일 반복 작업 내에 제공하는 것입니다. 따라서 팀에서 특성이 최대 5일 이상이어야 한다고 판단하는 경우, 5일을 초과하는 특성은 더 작은 특성으로 분할됩니다. 이를 통해 특성의 세분성을 정규화하여 특성 크기 비율이 너무 크지 않도록 할 수 있습니다.
계획, 실행 및 검토
각 반복, 즉 스프린트는 수행할 작업을 결정하기 위한 계획 세션으로 시작합니다. 개발팀은 이 계획을 실행합니다. 스프린트가 끝나면 이해관계자들과 함께 작업을 검토하고, 성공 사례와 개선 영역을 파악하기 위한 회고가 진행됩니다.
애자일 소프트웨어 개발 방법론은 기능적이고 검증된 소프트웨어 기능의 제공을 진행 상황의 척도로 우선시합니다. 이러한 접근 방식을 통해 팀은 효과적으로 협업하고, 고객 피드백을 수집하며, 프로젝트 가시성을 향상시킬 수 있습니다. 기능적 기능의 제공은 프로젝트가 계획대로 진행되고 있으며 시스템이 제대로 운영되고 있음을 입증합니다.
프로젝트 초기 단계에서는 팀이 몇 가지 기능만 제공할 수 있습니다. 하지만 반복을 거듭할수록 팀의 효율성이 향상되고, 시스템이 완성됨에 따라 애플리케이션 설계, 아키텍처, 그리고 비즈니스 우선순위가 지속적으로 평가됩니다. 개발 프로세스 전반에 걸쳐 팀은 고객 피드백, 사용자 의견, 그리고 이해관계자 피드백을 바탕으로 최적의 비즈니스 솔루션을 도출합니다.
반복을 거듭할수록 프로젝트 목표 달성을 향한 진행 상황이 모든 참여자에게 더욱 명확하게 드러납니다. 경영진은 진행 상황을 평가하고 투자한 만큼의 가치가 있는지 확인할 수 있습니다.
애자일 개발 프로젝트는 기존 소프트웨어 개발 프로세스와는 다른 방식으로 기능을 발굴합니다. 요구사항을 자세히 설명하는 데 몇 주 또는 몇 달을 소비하는 대신, 애자일 개발 프로젝트는 기능의 우선순위를 신속하게 정하고 예상합니다. 각 기능의 세부 사항은 이후 반복 과정에서 필요에 따라 고객, 테스터, 개발자가 함께 협력하여 더욱 자세히 설명함으로써 개선됩니다.
애자일 개발은 실제 소프트웨어를 통해 성공 여부를 일관되게 측정할 수 있다는 점에서 뚜렷한 이점을 제공합니다. 이를 통해 프로그래머, 고객, 관리자 및 기타 이해 관계자 사이에 더 큰 집중력, 참여 및 확신을 얻을 수 있습니다.
Digital.ai Agility QA 테스트를 애자일 개발 프로젝트에 쉽게 통합할 수 있도록 하는 통합된 수용 및 회귀 테스트 계획, 추적 및 보고 제품군을 제공합니다.
하나의 애자일 개발의 이점 실제 소프트웨어를 통해 성공을 일관되게 측정할 수 있다는 것은 기존 프로젝트와는 다른 느낌을 주는 프로젝트라는 것입니다. 이러한 접근 방식은 프로그래머, 고객, 관리자 및 기타 이해관계자들의 집중력, 참여도, 그리고 자신감을 유지시켜 줍니다.
와 Digital.ai Agility애자일 개발 프로젝트에 QA 테스트를 통합할 수 있습니다. 이는 수용 및 회귀 테스트 계획, 추적 및 보고를 통합적으로 제공하는 솔루션을 통해 이루어집니다.
소프트웨어 개발에서 지속적인 테스트는 진행 상황을 측정하고 결함을 방지하는 데 필수적인 관행입니다. 개발 중인 기능을 테스트하는 것은 프로젝트 후반부 실패 위험을 줄이는 데 도움이 됩니다. 프로젝트가 끝날 때까지 모든 것을 테스트하는 것은 위험하며, 제때 수정할 수 없는 결함을 발견하게 될 수 있습니다. 애자일 개발은 이러한 위험을 피하고 프로젝트가 제대로 진행되도록 지속적인 테스트를 장려합니다. 개발 중인 기능을 테스트함으로써 문제를 조기에 파악하고 해결하여 프로젝트 후반부에서 비용이 많이 드는 지연과 재작업을 방지할 수 있습니다.
단위 기능 및 인수 기능 레벨 모두에서, 코드가 미리 작성된 것처럼 테스트를 작성합니다. 가장 민첩한 개발 프로젝트는 가능한 한 많은 테스트를 자동화하고, 필요한 경우에만 수동 테스트에 의존합니다. 이를 통해 테스트 속도를 높이고 예측 가능하게 동작하는 소프트웨어를 제공할 수 있으며, 이는 결과적으로 더욱 지속적이고 신뢰할 수 있는 피드백을 제공합니다. 엄격한 지속적 테스트를 위한 새로운 도구, 기술, 그리고 모범 사례가 끊임없이 등장하고 있으며, 이러한 혁신의 상당 부분은 테스트 주도 개발(TDD) 커뮤니티에서 비롯됩니다.
기능은 언제 완료되나요? 모든 단위 테스트와 인수 테스트를 통과하고 고객이 수락하면 완료됩니다. 이것이 바로 실행 중이고 테스트된 기능의 정의입니다. 의미 있고 가시성이 높은 프로젝트 지표를 제공하는 이보다 더 좋은 소스는 없습니다.
지속적인 개선 및 학습
지속적인 개선은 애자일 개발의 핵심 요소입니다. 팀은 효율성을 높이고 생산성을 향상시키기 위해 프로세스, 도구, 그리고 상호작용을 정기적으로 검토합니다.
저희는 시스템과 프로젝트를 지속적으로 개선해 나갑니다. 실행, 테스트된 기능, 그리고 보다 주관적인 측정 기준과 같은 구체적인 지표를 활용하여 지금까지의 성과를 되돌아보고 추산과 계획을 조정할 수 있습니다. 하지만 동일한 메커니즘을 사용하여 프로세스를 지속적으로 개선하고 개선해 나갑니다.
특히 주요 이정표(반복, 릴리스 등)가 끝날 무렵에는 반복 계획, 빌드 또는 통합 프로세스, 프로그래머 간의 지식 고립 등 여러 가지 문제가 발생할 수 있습니다. 이러한 문제를 해결할 수 있는 레버리지 포인트를 찾습니다.
우리는 공장의 기계를 조정하고, 새로운 기계를 도입하거나 개발하여 매번 제품을 출시할 때마다 더욱 향상된 성능을 유지합니다. 고객, 팀, 그리고 조직에 시간 단위당 더 많은 가치를 제공하기 위해 프로세스를 조정하는 방법을 끊임없이 모색합니다. 건강한 유기체처럼 우리도 끊임없이 성숙하고 진화합니다.
애자일 개발 도구
애자일 팀은 진행 상황과 협업을 추적하는 소프트웨어부터 빌드와 배포를 자동화하는 프레임워크까지 다양한 도구를 사용하여 프로젝트를 관리합니다.
인기 도구
같은 도구 AgilityJIRA, Trello, Asana, Slack은 프로젝트 추적, 협업, 커뮤니케이션을 위해 애자일 환경에서 널리 사용됩니다.
올바른 Agile 도구를 선택하는 방법
올바른 도구를 선택하는 것은 팀 규모, 프로젝트의 복잡성, 통합, 보고, 협업 기능에 대한 구체적인 요구 사항에 따라 달라집니다.
애자일 개발 팀
애자일 팀은 일반적으로 여러 기능이 복합적으로 구성되어 있으며, 팀원들은 제품 증분을 제공하는 데 필요한 모든 기술을 보유하고 있습니다.
역할과 책임
일반적인 역할에는 제품 책임자, 스크럼 마스터, 그리고 팀원(개발자, 디자이너, 테스터)이 포함됩니다. 각 역할은 고유한 책임을 맡지만, 서로 긴밀하게 협력합니다.
팀 구성 규모
소규모 애자일 개발팀은 대규모 팀보다 훨씬 더 생산적인 것으로 입증되었으며, 이상적인 규모는 5명에서 10명 사이입니다. 프로젝트 규모를 더 크게 해야 하는 경우, 각 팀의 규모를 최대한 작게 유지하고 팀 전체의 노력을 조율하는 데 최선을 다해야 합니다. 최대 800명 규모의 스크럼 기반 조직은 프로젝트 계획 및 조율에 "스크럼의 스크럼" 방식을 성공적으로 활용했습니다.
각 반복 단계가 끝날 때마다 프로덕션에 바로 투입 가능한 소프트웨어 증분을 제공하므로, 팀은 성공하기 위해 교차 기능적이어야 합니다. 애자일 개발팀은 분석, 설계, 코딩, 테스트, 작성, 사용자 인터페이스 설계, 계획 및 관리 등 소프트웨어를 성공적으로 제공하는 데 필요한 모든 기술을 갖춘 구성원으로 구성되어야 합니다. 이러한 역량이 필요한 이유는 각 반복 단계가 그 자체로 하나의 미니 프로젝트이기 때문입니다.
팀은 서로의 기술을 가장 잘 활용하는 방법을 찾고 서로 멘토링하기 위해 협력합니다. 팀은 지정된 테스터, 코더, 디자이너에서 통합 팀으로 전환되어 각 구성원이 반복 작업을 완료하는 데 필요한 모든 작업을 돕습니다. 개별 팀원은 특정 분야에만 집중하는 경쟁 전문가라는 정체성을 덜 느끼고, 매우 생산적이고 효율적인 팀의 일원이라는 정체성과 만족감을 점점 더 느낍니다. 반복 작업을 거듭할수록 긍정적인 강화가 축적됨에 따라 팀은 더욱 단결되고, 신뢰, 동료애, 공감, 협업, 그리고 직무 만족도가 높아집니다. 소프트웨어 개발은 다시 즐거워집니다. 이러한 결과는 보장되지는 않지만, 잘 관리된 애자일 개발 프로젝트에서 다른 곳보다 훨씬 더 높은 확률로 나타날 것입니다.
협업 및 커뮤니케이션
애자일 팀에서는 효과적인 협업과 소통이 필수적입니다. 매일 진행되는 스탠드업 미팅, 페어 프로그래밍, 그리고 열린 소통 채널을 통해 모든 구성원이 서로 협력하고 어려움을 신속하게 해결할 수 있도록 지원합니다.
과제 및 솔루션
애자일을 구현하는 데는 변화에 대한 저항부터 분산된 팀 관리까지 여러 가지 어려움이 따를 수 있습니다.
Agile 구현의 일반적인 장애물
변화에 대한 저항, 팀원의 헌신 부족, 전환의 어려움은 애자일을 도입하는 조직이 겪는 일반적인 장애물입니다.
솔루션 및 모범 사례
이러한 과제를 극복하려면 다음이 필요합니다.
- 종합 교육.
- 임원 지원.
- 개방성과 실험의 문화를 육성합니다.
- 애자일 코치나 멘토를 활용합니다.
애자일 개발의 현재 동향
The 17 위 State of Agile 신고, 후원 Digital.ai 기업에서 떠오르는 여러 가지 트렌드를 나열합니다. 민첩한 계획.
최근 동향은 다음과 같습니다.
- Agile과 통합 DevOps 관행.
- 자동화에 집중하고 지속적인 배달.
- 소프트웨어 개발을 넘어 다른 비즈니스 영역에도 애자일을 적용합니다.
맺음말
애자일 소프트웨어 개발은 역동적인 환경에서 고품질 소프트웨어 제품을 신속하게 제공하기 위한 강력한 프레임워크를 제공합니다. 조직은 애자일의 원칙, 방법론, 도구를 이해하고 수용하며, 협업, 지속적인 개선, 그리고 적응력을 중시하는 문화를 조성함으로써 소프트웨어 개발에서 더 큰 성공을 거둘 수 있습니다. 애자일로의 여정에는 어려움이 따를 수 있지만, 고객 만족도 향상, 제품 품질 향상, 그리고 팀 생산성 향상이라는 이점은 그만한 가치가 있습니다.
