측정할 수 없는 데브옵스는 실패작입니다.

서론

많은 조직에서 보편적으로 사용하고 있는 시나리오는 있지만, 데브옵스(DevOps) 이니셔티브를 시작한지 몇 개월이 지나도 여전히 가시적인 성과가 없습니다. 자동화를 해서 리소스 프로비저닝은 쉬워졌지만, 다른 업무 흐름에서 병목 현상이 계속 발생하고, 엔지니어들은 예상치 못한 중단과 성능 문제를 해결하기 위해 고군분투합니다.

분산된 팀 간의 협업을 지원하는 데브옵스는 더 많은 코드 배포, 평균 장애복구시간(MTTR) 단축, 변화의 리드 타임 단축을 가능하게 하며, 궁극적으로는 비즈니스에도 많은 영향을 미칩니다. 1 그러나 이러한 결과를 달성하는 데 필요한 혁신을 한다는 것은 사실 쉽지 않은 일입니다. 전체 업무 흐름에 영향을 주는 사고 방식까지 전환해야 하기 때문입니다.

"이것을 어떻게 측정할 것인가?"라는 질문은 우수한 엔지니어링 문화의 핵심입니다. 새로운 기능을 운영 환경에 배포하는 것이든, 보다 광범위한 조직적 이니셔티브를 구현하는 것이든, 측정은 지금까지 기울인 노력을 모든 사람이 볼 수 있는 의미 있는 결과로 연결시켜줍니다. 반대로, 업무가 측정 가능한 목표와 연결되지 않으면, 팀이나 직원이 스스로 가치절하되었거나 노동 착취를 당하고 있다고(예: 업무시간 이후까지 대기 상태 유지) 느껴 반발이 일어날 수 있습니다. 그러므로, 팀과 직원이 공동 여정을 위한 일원이라는 느낌을 가질 수 있도록 데이터를 사용해 성공 여부를 측정하는 것이 필요합니다.

올바른 요소를 측정하고, 데브옵스 운영을 관리하여 핵심성과지표(KPI)를 지속적으로 파악하지 않으면, 데브옵스에 대한 접근 방식이 비즈니스에 효과적인지 확신할 수 없습니다. 즉, 측정 없는 데브옵스 또는 올바른 것을 측정하지 않는 데브옵스는 실패한 것입니다.

이 eBook에서는 데브옵스의 성공을 위한 5가지 핵심 요인을 소개하고, 비즈니스 성과, 고객 경험, 애플리케이션 및 인프라 성능, 엔지니어링 속도, 품질 등의 측면에서 그러한 성공을 측정하는 방법을 설명합니다.

첫 번째 요인: 비즈니스의 성공

가치 있는 소프트웨어의 의미는 기업이 가장 중요시하는 측정 가능한 목표들과 소프트웨어를 연관시켜 보면 알 수 있습니다.

예를 들어, 소프트웨어가 고객 기반과 매출을 늘려주고, 고객 서비스 비용을 절감하거나 기타 다양한 목표를 달성할 수 있도록 지원한다면 기업에 가치가 있는 것입니다. 기업의 비즈니스 이해 관계자나 경영진과 대화를 나누어 관련 비즈니스 목표가 무엇인지, 그리고 혁신적인 소프트웨어가 어떤 비즈니스 목표에 영향을 줄 수 있는지를 파악해야 합니다.

업종, 기업의 성숙도, 시장 점유율, 기타 변수에 따라 소프트웨어가 잠재적으로 영향을 줄 수 있는 핵심성과지표(KPI)는 다음과 같습니다.

• 구매 전환율

• 사용자당 평균 매출

• 고객 획득 비용

• 고객 이탈률 • 반복 구매 또는 매출 증가

• 갱신 및/또는 구독

소프트웨어에 대한 비즈니스 목표에 합의하면, 데브옵스 팀의 모든 구성원들이 자신이 하고 있는 일을 측정 가능한 성공 지표로 연관시킬 수 있습니다. 이러한 데이터 중심 접근 방식은 소프트웨어에 포함할 우선 기능을 선정하는 것에서 리소스 할당과 데브옵스 팀의 규모 산정까지, 우선순위 지정과 의사 결정을 향상시켜 줍니다.

비즈니스 성공을 위한 추가적인 노력

전문 리테일러 REI는 회원과 고객들에게 다양한 아웃도어 및 레크리에이션 제품과 서비스를 제공합니다. 이 기업의 IT 팀은 앱과 웹사이트가 뛰어난 디지털 고객 경험을 제공할 수 있도록 연속 배포 모델을 기반으로 하루 수차례 코드를 푸시하고 있습니다.

이 때문에 개발자들은 비즈니스 지표, 성능 및 오류의 변경 사항 확인을 위해 운영 환경에 대한 완전한 가시성이 필요했습니다. REI의 플랫폼 엔지니어링 디렉터인 토드 윌스(Todd Wilson)은 “REI는 사이트 성능을 하나의 기술적 요소에서 구매전환과 사용자 경험에 영향을 미치는 실질적인 비즈니스 원동력으로 진화시키고 있다”며 “성능을 비즈니스 투자로 생각하고 비즈니스에 활용할 수 있는 성능 대시보드를 생성하기 시작했다”고 말합니다.

두 번째 요인: 고객 경험

하지만, 고객들이 앱을 몇 번 시도해보고 그만 두는 것으로 나타났습니다. 실제로 많은 고객들이 앱을 기기에서 삭제했습니다. 무슨 일이 일어난걸까요?

한 가지 원인은 고객 경험이 기대에 미치지 못한 것이 될 수 있습니다. 앱이 너무 혼란스러웠나요? 너무 느렸나요? 중요한 상호작용을 하는 데 너무 많은 단계를 거쳐야 했나요? 출시 후 팀이 해체되어 다른 프로젝트로 이동했나요? 고객이 추가 수익을 창출해주는 트랜잭션을 완료하지 않고 짜증이 나서 포기해버렸다면, 이 데브옵스 접근 방식은 실패한 것입니다.

이 경우, 소프트웨어 내에서 올바른 KPI를 측정하고 추적하지 않는 한, 고객 경험이 문제인지 알 수 없을 것입니다. 고객 경험 KPI에는 다음이 포함될 수 있습니다.

• 주요 트랜잭션의 인지된 응답 시간

• 주요 트랜잭션의 빈도

• 사용자당/주당 방문 횟수

• 사용자 성장률 • 퍼널/구매 전환율

• 앱에서 보낸 시간

• A/B 테스트 결과

• 고객 만족

이 예시의 교훈은 혁신과 소프트웨어 개발을 비즈니스 목표와 연계시키는 것만으로는 충분하지 않다는 것입니다. 또한 이러한 성공의 측면들을 고객 경험의 핵심 영역에 연결하고 기업이 얼마나 잘 하고 있는지를 측정해야 합니다.

뛰어난 고객 경험을 위해 '기본 이상'을 수행해주는 기술

세계적인 스포츠 엔터테인먼트 기업 Topgolf 는 전 세계적으로 41개의 시설을 보유하고 있으며 매년 1,300만 명 이상의 고객이 시설을 방문합니다. 단 기간 내에 20개의 새로운 위치를 추가하면서, 본사의 데브옵스 팀은 각 새로운 시설에서 실행되는 소프트웨어에 대한 실시간 가시성이 필요하게 되었습니다.

성능 모니터링은 Topgolf의 기술 그룹이 고객이나 시설의 직원에게 영향을 미치기 전에 문제를 찾아 해결하는 데 도움이 됩니다. 또한 실시간 및 이력 추세 분석은 팀이 고객 경험을 선제적으로 개선하는 방법을 알려줍니다. Topgolf의 애플리케이션 디렉터인 케니 설리반(Kenny Sullivan)은 "각 시설에서 소프트웨어가 잘 실행되고 있을 뿐만 아니라 속도가 느려지거나 게임 플레이에 방해가 되지 않도록 해야 한다”며 “소프트웨어 성능은 고객에게 정말 즐거운 경험이냐 아니면 부정적인 경험이냐의 차이를 만들어 준다”고 설명합니다.

세 번째 요인: 애플리케이션 및 인프라 성능

선제적으로 인프라를 확장했음에도 불구하고, 고객 지원 센터에는 성능 저하와 오류에 대한 불만을 토로하는 화가 난 고객들의 전화가 쇄도합니다. 분산 아키텍처가 클라우드에 구축되어 있기 때문에 사고 대응 팀이 문제의 정확한 위치를 파악하기가 쉽지 않습니다. 새로운 코드가 문제일까요? 클라우드 서비스 확장이 부적절했을까요? 한 호스트에서만 문제가 있는 걸까요? 아니면 전혀 다른 문제일까요?

현대적인 애플리케이션 아키텍처는 뛰어난 민첩성과 확장성을 제공하지만 그만큼 복잡성도 높습니다. 고객 경험은 서버 측 애플리케이션 서비스 네트워크에 걸쳐진 많은 요인, 타사 서비스의 종속성 그리고 자체 데이터센터나 퍼블릭 클라우드 제공업체의 컴퓨팅 리소스에 동적으로 할당되는 컴퓨팅 리소스 세트에 의해 영향을 받는 경우가 많습니다. 데브옵스가 영감을 주는 운영을 확실하게 바꾸려면, 애플리케이션 스택의 어떤 부분이 고객 경험 문제를 유발하는지 신속하게 피드백을 받을 수 있어야 합니다. 또한 IT 예산에서 클라우드 비용이 차지하는 부분이 갈수록 커지고 있기 때문에, 최대한 효율적으로 최상의 고객 경험을 제공하는 것도 중요합니다.

성능 문제가 드러나기 전에 파악하려면 애플리케이션과 인프라 전체에서 성능 KPI를 추적하고 모니터링해야 합니다. 팀이 이미 KPI의 일부 또는 전체에 집중하고 있어야 합니다.

• 앱 응답 시간

• 데이터베이스 응답 시간

• 타사 서비스 성능

• 리소스 활용

• 클라우드 비용

성능 문제를 위한 앱 감사

세계 최대의 조세 서비스 제공업체 H&R Block은 지난 50년 동안 캐나다에서 1,200개 이상의 사무실을 운영해 왔습니다. DIY 온라인 세금 보고 소프트웨어의 성능을 모니터링하는 기능은 주요 세금 보고 마감일 전후 몇 달 동안 수행되는 이 기업의 비즈니스에 매우 중요합니다.

H&R Block은 비즈니스에 핵심적인 사용자 트래픽의 폭증 문제를 해결하기 위해, 성능 문제를 즉시 처리하고 성능이 고객에 미치는 영향을 신속하게 파악할 수 있게 해주는 포괄적인 실시간 인사이트가 필요했습니다. H&R Block 캐나다의 제품 개발 및 규정 준수 디렉터인 데이브 포켄버그(Dave Falkenberg)는 “데브옵스 팀은 오류를 발생시키는 코드 줄을 세부적으로 분석해 오류를 트리거하는 데이터 모델을 파악해 낼 수 있다”며 “결과적으로 제품의 품질을 크게 개선할 수 있었다"고 말합니다.

네 번째 요인: 엔지니어링 속도

데브옵스 팀은 개발 속도, 배포 속도, 운영 과정에서 발생하는 문제에 대한 대응 속도에 초점을 맞춰야 합니다. 이 영역에서 진척상황과 성공을 추적하는 데 고려할 지표는 다음과 같습니다.

• 변화에 대한 리드 타임

• 코드 릴리스 빈도

• 평균해결시간(MTTR)

많은 조직은 클라우드 컴퓨팅에 의존해 소프트웨어 개발 및 배포를 간소화 및 가속화합니다. 데브옵스 팀은 서버, 네트워크 또는 스토리지를 프로비저닝하고 관리할 필요 없이 IaaS(서비스형 인프라) 및 PaaS(서비스형 플랫폼)를 통해 신제품의 시장 출시 시간을 단축하는 데 필요한 서비스를 이용할 수 있습니다.

데브옵스의 성공을 위한 다른 요인들과 마찬가지로 다른 목표(특히 소프트웨어 품질) 를 배제하고 속도에만 집중하면 안됩니다. 속도는 고객 경험 및 애플리케이션 성능과도 관련되기 때문입니다. 실제로 배포 품질이 좋지 않으면 개발 및 배포 속도가 저하되어 운영 과정에서 나타나는 품질 문제를 해결하는 데 시간과 노력이 더 많이 필요하게 됩니다.

속도에 대한 필요성

TREK Bicycle Corporation은 온라인 비즈니스를 통해 다양한 사이클링 관련 정보와 경험을 제공하는 자전거 및 자전거 제품 제조업체입니다. 증가하는 고객의 기대치를 충족하기 위해 지속적인 피드백과 민첩성이 뛰어난 시스템이 필요해졌습니다.

엔지니어링 노력에 대한 빠른 피드백은 개발 주기를 단축하는 데 매우 중요합니다. Trek의 웹 기술 관리자인 제이슨 앤드레스(Jason Endres)는 "주요 플랫폼 업그레이드를 수행하는 과정에서 성능 문제가 발생했는데, 뉴렐릭이 없었다면 디버깅하는 데 아마 1~2주나 더 시간을 소비해야 했을 것”이라며 “자세히 살펴봐야 할 곳을 정확히 파악해주어 개발 주기를 단축할 수 있었고 그 덕분에 데브옵스 팀도 보다 전략적인 프로젝트에 집중할 수 있게 되었다”고 말합니다

협업을 위한 조력자 챗옵스(ChatOps)

시스템 장애는 피할 수 없는 일입니다. 장애가 발생하면 인시던트 응답을 신속하게 활성화해 문제를 해결하는 것 중요합니다. Slack과 같은 챗옵스 툴은 장애 발생 시 데브옵스 팀이 커뮤니케이션의 효율성을 극대화하는 데 중요한 역할을 합니다. 그룹 채팅방은 감사가 가능하고 인시던트 대응과 관련된 모든 이해 관계자가 상황을 파악할 수 있도록 합니다. 다양한 개발 및 운영 툴에서 플러그인과 통합을 활용하면 채팅 이외에도 실시간 정보를 확보할 수 있습니다. 중앙화되고 시간 스탬프가 찍힌 커뮤니케이션 로그, 데브옵스 툴과의 실시간 상호 작용, ‘챗옵스’는 데브옵스 팀의 새로운 협업 방식입니다 .

챗옵스는 개인과 툴 모두의 정보를 실시간으로 기록할 수 있는 단일한 중앙 위치를 제공합니다. 이벤트 기록은 작동 상태나 문제 발생 시 해결 방법에 대해 많은 투명성을 제공합니다. 대화 중심의 개발 및 운영 툴인 챗옵스는 속도와 민첩성은 물론 실시간이라는 특징을 제공하여 데브옵스 팀과 이들의 성공에 책임이 있는 사람들을 효과적으로 지원합니다

다섯 번째 요인: 품질

소프트웨어 배포를 더 빠르고 더 낫게 만들어야 한다는 데브옵스의 기본 전제는 사실 모순적이라고 할 수 있습니다. 두 가지 목표는 상호 배타적이지 않습니까? 데브옵스 접근 방식 하에서 개발 주기를 단축하고 더욱 긴밀하게 협업한다는 것은 문제가 발생하기 전에 문제를 파악할 수 있으므로 문제를 해결하는 데 드는 시간을 줄일 수 있다는 것을 의미합니다.

운영 환경에서 소프트웨어를 효과적으로 지원하려면, 사후 대응에 드는 시간과 구축 및 테스트 등 사전 대응적인 노력 사이에서 균형을 맞춰야 합니다. 소프트웨어 품질은 고객에 영향을 미치는 인시던트와 직접적으로 관련이 있기 때문에, 개발 주기 초기에 품질 문제를 해결하는 데 시간과 에너지를 투자해야 합니다. 그리고 고객이 문제를 발견하는 상황이 되면 안됩니다! 테스트 중심 개발, 연속 통합, 연속 개발 등의 접근 방식은 모두 품질 향상에 중점을 둔 작업의 우선 순위를 정하는 데 도움이 됩니다.

다음은 소프트웨어에 대한 연속 개선 노력의 품질을 정량화하는 데 도움이 되는 측정 지표입니다.

• 업타임

• 배포 성공률

• 오류율(클라이언트 및 서버 측 모두)

• 모바일 충돌 수

• 인시던트의 심각도

많은 품질들은 소프트웨어가 운영 환경에 도달해서야 나타나기 때문에, 배포 전과 후의 모든 지표를 비교하는 기능은 특정 릴리스의 영향을 이해하는 데 매우 유용합니다. 또한 팀은 이러한 접근 방식을 통해 신속하게 대응하고 릴리스를 롤백하거나 발생한 모든 인시던트에 대한 신속한 해결책을 제공할 수 있습니다.

완벽한 증류 공정

Irish Distillers는 아일랜드 최고의 증류주 및 와인 공급업체로, 세계에서 가장 잘 알려진 아이리시 위스키를 생산하고 있습니다. 빠른 성장을 이끌고 있는 아이리시 위스키 브랜드인 제임슨을 필두로 Irish Distillers는 자사의 브랜드를 130개 이상의 시장으로 수출하고 있습니다. 소비자들을 대상으로 한 마케팅 사이트의 배포 속도가 늘어나면서, 디지털 자산의 품질이 제품의 품질과 매치되도록 하기 위해 이 기업은 엔드유저 환경 및 백엔드 코드 성능 측면에서 인사이트가 필요했습니다.

Irish Distillers의 IT 마케팅 및 영업 솔루션 책임자인 피트 맥비카(Pete McVicar) 는 팀들이 새로운 기능에 대한 소유 의식을 갖고 연속적인 애자일 데브옵스 모델을 수용하도록 장려하고 있습니다. 맥비카는 "뉴렐릭의 주간 이메일 보고서가 중요한 역할을 하는 2주간의 짧은 프로젝트를 통해 새로운 기능이 얼마나 잘 작동하고 있는지 뿐만 아니라 다른 사이트에 어떤 영향을 미치고 있는지 확인할 수 있었다”고 말합니다.

모든 요소의 종합

비즈니스 성공, 고객 경험, 애플리케이션 및 인프라 성능, 엔지니어링 속도, 품질 등 데브옵스의 성공을 위한 다섯 가지 요인을 종합하여, 모니터링 및 추적해야 할 영역들을 하나의 총체적인 그림으로 살펴보겠습니다. Gamechanger Industries의 사례에서 볼 수 있듯이, 데브옵스가 약속하는 혜택을 이끌어내고 측정 가능한 비즈니스 성과를 내려면 이 모든 분야에 중점을 두어야 합니다.

기업의 목표를 달성하는 데 어느 정도 진척이 되었는지에 따라, 현재 추적해야 할 가장 중요한 KPI를 결정해야 합니다. 추적하지 않거나 일부만 추적하고 있다면, 지금 시작해야 합니다. 먼저 기준을 설정하고 지표를 모니터링하여 수치가 증가하거나 감소하는지 확인해야 합니다.

지금까지 언급하지 않은 한 가지 사항은 데브옵스의 성공 요인들 간에 리소스와 시간을 균형 있게 배분해야 한다는 것입니다. 이러한 배분은 고정된 것이 아니라, 비즈니스 환경과 전반적인 전략이 진화함에 따라 바뀌어야 합니다. 예를 들어, 제품 개발 주기의 초기 단계에 있는 기업은 새로운 기능을 개발하기 위한 혁신에 대부분의 시간을 투자할 것입니다. 성장 단계에 있는 제품은 제품이 성숙도가 높아지고 보편화되면서 성능과 안정성을 고려해야 합니다. 특히 성숙 단계에 있는 제품은 혁신과 품질 모두에 우선순위를 두어야 합니다. 혁신은 경쟁력을 유지하고 제품을 발전시키기 위한 것이고 품질 개선은 ‘기술적 부채’를 줄이기 위한 것입니다.

기술적 부채(최초의 wiki 개발자이자 뉴렐릭의 프로그래머인 워드 커닝햄(Ward Cunningham)이 만든 용어)는 코드를 빠르게 릴리스하기 위해 편한 해법을 선택한 결과로 추후 발생하는 추가적인 코드 수정 작업을 의미합니다. 데브옵스 전문가 진 킴(Gene Kim) 은 부채 감면세 20%를 지불하지 않으면 누적 문제를 해결하기 위해 100%를 지출하게 된다고 말합니다. 성공 요인들 간에 적절한 균형과 배분을 유지하려면, 비즈니스 전략, 경쟁 환경 및 제품의 수명 주기 단계를 고려하고 이해해야 합니다. 요인들은 기본적으로 제약 조건에 맞게 다양한 수준으로 설정할 수 있으며, 비즈니스의 우선순위를 지원하도록 수준을 변경해야 합니다.

올바른 데이터 확보

다음은 성공적인 측정의 가장 중요한 부분인 데이터 측정입니다. 데브옵스가 성공하려면 올바른 데이터에 대한 액세스가 필요합니다. 기본적으로, 추적 및 모니터링해야 하는 모든 KPI와 엔지니어링 속도, 품질, 애플리케이션 및 인프라의 성능, 고객 경험, 비즈니스 성공에 대한 인사이트가 필요합니다.

데이터 중심의 데브옵스 조직이 되면 팀의 노력과 성과를 추적하고 모니터링할 수 있을 뿐만 아니라 협업과 공감의 문화를 조성할 수 있습니다. 데이터는 의사 결정 과정에서 감정이나 책임 전가를 배제하고, 기술, 경험, 직책 전반에 걸쳐 공통된 언어를 구축할 수 있습니다.

올바른 데이터를 수집하기는 어렵지 않지만, 수집 이외에도 데이터를 자동으로 캡처하고 데이터를 빠르고 쉽게 분석, 확인 및 공유할 수 있도록 해주는 계측 기능이 있어야 합니다. 데브옵스 성공을 위한 5가지 핵심 요인에 대한 자세한 실시간 이력 데이터를 제공하는 솔루션을 선택해야 합니다. 솔루션은 최소한 다음과 같은 기능이 필요합니다.

• 선제적인 애플리케이션 중심의 성능 모니터링: 클라우드, 컨테이너, 서버리스 함수 같은 최신 기술로 인프라가 보편화됨에 따라, 애플리케이션의 성능을 이해하는 것이 점점 더 중요해지고 있습니다. 애플리케이션은 고객과 비즈니스 가치에 가장 가까이 있습니다. 고객에게 가장 중요한 것이라는 맥락에서 애플리케이션 및 인프라스트럭처 전반의 성능을 깊이 이해하는 데 도움을 주는 툴을 찾아야 합니다.

• 고객 경험 관리: 모든 디지털 채널에서 연중무휴(시스템에 사용자가 없는 경우에도) 고객 경험을 측정할 수 있는 데이터를 제공하는 툴을 선택해야 합니다. 툴은 점점 더 많은 코드가 위치하고 있는 프런트엔드 처리 계층을 관리하는 데 도움이 되어야 합니다.

• 강력한 분석: 개발자, 운영 및 비즈니스 이해 관계자를 아우르는 데이터 중심 문화를 조성하려면, 설정 가능한 대시보드 및 비즈니스 성공을 정량화하는 심도 있는 기술 분석 기능을 갖춘 유연한 툴이 필요합니다.

• 배포 관리: 발생한 오류 등 최근의 배포가 애플리케이션 성능과 엔드유저에 미친 영향을 비교해 보여주는 보고 기능이 필요합니다. 이러한 기능은 성능과 관련된 KPI를 추적하고 측정할 수 있게 해줍니다.

솔루션을 평가할 때는 단일 플랫폼을 통해 데이터를 추적하고 모니터링하면, 데브옵스의 관리 작업이 간소화되고 수월해진다는 사실을 염두에 두어야 합니다. 단일 플랫폼을 사용하면 팀과 비즈니스 전반에 걸쳐 통합된 소프트웨어 뷰를 공유하여 더 나은 의사 결정을 내릴 수 있습니다. 개발자와 운영 팀이 동일한 툴을 사용하면 소프트웨어의 배포 및 실행에 대한 정보를 공유하는 데 매우 효과적입니다. 통합 알림, 대시보드, 분석 기능은 모든 사람이 더 스마트하게 작업하고, 더 빠르게 대응할 수 있게 해줍니다. 뉴렐릭과 같은 소프트웨어 분석 플랫폼은 위에서 언급한 모든 기능들은 물론, 다른 유용한 기능들을 통합해 하나의 총체적 솔루션으로 제공합니다.

데이터를 통한 다양성 구축

데이터는 응집력 있고 협업적이며 높은 성과를 내는 데브옵스 팀을 만드는 데 도움이 됩니다. 또한 성격, 문화, 기술, 인종, 성별 등의 측면에서 다양성이 높은 팀을 만드는 데도 도움이 될 수 있습니다. 데이터는 팀 구성원들이 누군가에게 책임을 전가하려 하지 않고 능력주의를 촉진하는 방식으로 소통하는 데 사용할 수 있는 공통 언어가 되어줍니다. 팀의 다양성은 직원의 성장을 지원하고 포용력이 있으며 보람을 느낄 수 있는 성공적인 업무 환경을 조성함으로써 더 많은 직원을 보유하는 데 도움이 된다는 점에서 중요합니다.