Amazon의 운영 탁월성 – Operational Excellence (2) 개발 도구

2020-02-20 01:00:00

우리가 IT 시스템을 설계, 구현 및 테스트 후 배포를 하고 나면, 전체 수명 주기에서 가장 어려운 측면이 바로 운영을 통해 서비스를 유지 관리하는 것입니다. 이 글에서는 여러분이 개발한 서비스를 탁월하게 운영하는 방법(Operational Excellence)에 대해 세계 최대 전자 상거래 서비스 및 클라우드 컴퓨팅 서비스를 구축해 운영하고 있는 아마존의 모범 사례를 개발 문화, 도구 및 프로세스 등 3가지 필수 상호 연결 요소에 중점을 두어 살펴볼 예정입니다.

이 글은 AWS 클라우드 아키텍트 전담 에반젤리스트인 Adrian Hornsby의 Towards Operational Excellence Part 2 —On the importance of tools 의 한국어 번역 및 편집본입니다. 좀 더 정확한 의미를 확인하고 싶으신 분은 영어 원문을 참고하시기 바랍니다.

첫번째 글에서는 아마존의 운영 탁월성에 대한 문화적 측면을 다루고 리더십 원칙 (LP)의 맥락에서 기업 문화의 중요성을 살펴보았습니다. 기술적 성취를 위해서 우선 기업 문화가 어떻게 구성되어 있는지 성찰이 필요하다는 측면에서 기업의 DNA를 잘 만들어야 합니다. 이 글에서는 기술 도구에 대해 설명하지만, 이러한 도구를 만든 동기와 의사 결정을 이해하기 위해 아마존의 LP를 계속 활용할 것입니다.

1. 아마존의 초기 개발 및 배포 방식

IT 기업 시스템을 기존 데이터센터 기반 온-프레미스에서 운영하던지 클라우드를 활용하는지에 관계 없이 필요한 다양한 개발 및 운영 도구가 필요합니다.

테스트 자동화
구성 관리
소프트웨어 배포
모니터링 및 시각화
보고
변경 관리
사고 관리
문제 발권
보안 감사
예측 및 계획

이러한 개발 도구의 중요성을 이해하기 위해 소프트웨어 배포 방식이 시스템 아키텍처 변화 과정에서 어떤 의미를 가지는지 잠깐 살펴보겠습니다. 이전 글에서 언급한 대로 초기 amazon.com 서점을 운영하는 시스템은 비교적 단순하여 3 계층 아키텍처가 프론트 페이지, 웹 서버, 데이터베이스, 그리고 몇 가지 내부 도구와 통합되어 있었습니다.

단일 애플리케이션으로 작업 할 때, 공유 중인 출시 파이프라인에서는 특정 개발자의 변경 사항이 다른 개발자와 마찰을 일으킬 수 있습니다. 이를 때는 여러 가지 조정이 필요하죠.

우선 모든 팀이 다른 개발자의 코드를 위반하지 않도록 변경 사항을 조정해야 합니다. 보안 및 성능 목적으로 의존성 있는 라이브러리를 업그레이드하려면 모든 개발자가 동시에 업그레이드해야 합니다. 빠른 수정 및 패치가 필요할 때도, 유사한 검토 및 승인 과정이 필요합니다. 대개 이 문제를 해결하기 위해 주중에 일하고, 금요일 저녁이나 새벽 시간에 변경 사항을 병합하게 됩니다.

휴스턴 팀과 커맨드 라인 도구

각자 기능 개발 후, 배포 단계에서도 어려운 문제에 직면하게됩니다. 모든 자원이 공유되고 있으니, 배포 파이프 라인을 통해 전체 애플리케이션을 다시 빌드하고 테스트 후 컴포넌트를 다시 배포해야 합니다. 한 줄짜리 변경이나 약간의 코드 변경도 이 과정을 거쳐야 합니다. 고 비용의 “한 줄짜리 변경 프로세스”는 배포 파이프 라인의 품질 관리 부분에서 더 많은 위험과 장애 가능성을 높이고, 전체 배포 주기를 계속적으로 느리게 만드는 원인입니다.

당시 아마존에는 “웹 사이트 푸시 ”를 실행하는 Perl 스크립트를 사용하여 이러한 모놀리식 애플리케이션을 배포하기 위해 휴스턴(Huston)이라고 부르는 중앙 전담 팀을 구성하였습니다.모든 팀이 배포를 위해서는 휴스턴팀에 전화를 하게 되고, 이건 병목 문제를 발생시킵니다.

대부분의 빌드 및 배포 작업은 커맨드 라인 스크립트로 만들어서 중앙에 네트워크 파일 시스템(NFS) 서버에 모아 두고, 필요할 때 마다 복사해서 사용합니다. 만약 NFS 서버가 장애가 나는 경우에는 문제가 됩니다만…

커맨드 라인 도구는 간단한 서버 관리에서 고객 서비스 작업에 이르기까지 다양했습니다. 예를 들어, 고객에게 환불을 요청하려는 CS 운영자가 사용하는 명령은 다음과 같습니다.

> /opt/amazon/customer-service/bin/request-refund

비슷하게 쇼핑몰의 모든 기능, 고객 서비스 및 서비스 센터 도구까지 동일한 데이터베이스를 사용 했기 때문에 모두가 운영 서버에 로그인하여 Unix 명령을 실행해야 했습니다. 프로덕션에서 누구 하나 실수를 하면 꽤 위험한 상황이 연출될 수 밖에 없는 상황이죠.

서비스가 급격하게 성장함에 따라 고객 중심의 혁신을 시작하고 빠르게 기능을 발명하여 배포하려는 문화를 가진 아마존으로서는 용납 할 수 없는 구조였습니다. 따라서, 아마존은 전체적으로 시스템 구조와 기업 조직의 함께 바꾸기로 결정했습니다.

모놀리식 애플리케이션 쪼개기

이전 글에서 살펴본 대로 아마존닷컴의 단일 모놀리식 아키텍처는 비즈니스 도메인 및 기능별로 작게 쪼개 리팩토링을 시작했습니다. 모든 것이 한꺼번에 이루어진 것은 아니고, 당시에 서비스 지향(Service-Oriented, SOA), 그리고 오늘날 마이크로서비스 아키텍처라고 부르는 수준으로 지속적으로 진화하였습니다.

이러한 리팩토링 과정에는몇 가지 엄격한 요구 사항을 있었습니다. 개별 서비스는 (1) 소규모 , (2) 집중적 , (3) 단일 목적 및 (4) HTTP API로 연결 해야 한다는 것이었습니다. 2006년에 아마존의 독립적인 개발 서비스 숫자는 적어도 수백여 개 이상이었습니다.

Amazon.com 홈페이지를 방문하는 순간 적어도 100여개 이상의 개별 서비스를 호출하여 데이터를 수집하고 전체 페이지를 구성합니다. 상품 전시, 결제 페이지 등 호출한 서비스 종류에 따라 (호출 숫자는) 조금씩 다르며, 해당 페이지의 개체에 대한 캐싱 효과 및 기타 요인에 따라 다를 수 있습니다.
– A Conversation with Werner Vogels, ACM QUEUE 2006

예를 들어, 아래 아마존 상품 페이지 내에는 상품 정보, 리뷰 데이터, 전자책 제공 여부, 판매자 정보, 가격, 재고 여부 등 다양한 정보가 제공되는데 이러한 정보들은 개별 서비스팀이 독자적인 서비스로 만들어 API로 전달 하고 있으며, 우리가 보는 페이지는 이를 구성하여 만든 것입니다.

“지금 구매”서비스 및 반드시 읽어야하는 책. — 원-클릭 구매가 가능한 제품일 경우, “Buy Now” 버튼 생성

여기서 “Buy Now” 버튼은 원-클릭 주문 서비스에서 결과를 반환 받은 후 가능한 상품인 경우, 고객에게 보이게 되고 클릭 하면 주문이 바로 이루어집니다. 만약 현재 원-클릭 주문이 힘든 상황이라면, 버튼이 보이지 않게 되겠죠.HTTP API에 의해 정의된 호출을 통해 서비스 가능 여부를 파악하는 것이며, 각 서비스의 API가 안정적으로 유지되는 한, 정상적으로 서비스가 제공됩니다.

만약 개별 서비스가 새로 배포되거나 업데이트 중이라고 할지라도 상품 페이지의 극히 일부분이 제한되며, 고객의 쇼핑 경험을 크게 해치지 않습니다. 각 서비스 운영팀은 서비스 전체 중단 걱정 없이 더 빠르게 기능 구현 및 배포를 반복할 수 있게 됩니다.

투-피자(Two Pizza)팀 조직의 변화

기존 시스템의 아키텍처를 바꾼다고 해서 좋은 결과를 얻을 수 없습니다. 1967년 Melvin Conway의 이름을 딴 “콘웨이의 법칙”은 기업 시스템과 조직 문화를 고민하는 분들에게 매우 중요한 깨달음을 줍니다.

“모든 소프트웨어 구조는 그것을 만드는 개발 조직의 커뮤니케이션 구조를 닮는다 — M. 콘웨이

즉, 소프트웨어가 제대로 개발되고 작동하려면 개발자가 서로 자주 의사 소통해야 합니다. 분산 아키텍처를 만들고 싶다면, 팀 조직도 분산해야 합니다.소프트웨어 인터페이스 구조는 이를 개발하는 팀의 커뮤니케이션 방식과 닮아있기 때문입니다. (예를 들어, 어떤 팀의 협업 방식이 메일이나 전화로 승인 요청을 한 후 제공하는 패턴이 있다면, 데이터 공유 방식은 REST API 보다는 FTP나 배치 엑셀 파일 같을 것으로 전달할 가능성이 매우 큽니다.)

모놀리식 아키텍처를 쪼갠 후, 아마존은 각 팀도 독립적이면서 자율적으로 서비스를 만들고 운영할 만한 (두 개의 피자로 점심을 먹을 만큼) 작은 소규모 팀으로 나뉘어졌습니다. 투 피자(Two Pizza) 팀은 내부 및 외부 고객과의 협력, 로드맵 설정, 서비스 사양, 코드 작성, 테스트 실행, 프로덕션에 배포 및 운영까지 완전한 자율권 을 부여 받았습니다 .

투-피자팀은 오로지 자신의 서비스에만 집중하고, 다른 팀의 서비스와 API로 소통하는데 집중할 수 있었습니다. 인원이 매우 작기 때문에 개발에 필요한 각종 개발 도구 등은 직접 만드는 여력을 가지고 있지 않았습니다. 따라서, 수백 개의 투-피자팀을 지원할 셀프 서비스 도구를 만드는 것은 초기 아마존 시스템에서 매우 중요한 일이었습니다.

2. 자동화된 개발 및 배포를 위한 도구

새로운 개발 도구를 만들 때 여러분은 어떻게 하시나요? 도구가 필요한 개발팀에 가서 어떤 것이 필요한지 인터뷰를 하고 기능 목록을 만듭니다. 그리고, 기술적인 난이도에 따라 우선 순위를 정합니다. (그 중에는 내가 하면 재미있을 것도 잠깐 끼워 넣을 수도 있겠죠.)

어떤 것이 필요하다는 것을 데이터로서 정량적으로 수집 및 측정하는 것이 매우 중요합니다. 단순히 인터뷰 만으로서는 개발팀의 요구 사항은 아마 상상하는 모든 것을 만들어야 할 가능성이 높으니까요. (고객은 가끔 자기가 필요한 건지 아닌지 모를 때가 많습니다.)

“저는 결코 미리 추측하지 않습니다. 데이터가 없이 이론을 만드는 것은 큰 실수입니다. (데이터가 없으면) 사실에 맞는 이론 대신 사실을 왜곡하기 시작합니다.” – 아서 코난 도일 경

아마존은 데이터 기반으로 의사 결정을 하는 기업입니다. 따라서, 데이터를 수집하고 이를 통한의사 결정을 하는데는 아래 두 가지 리더쉽 원칙(LP)이 필수적입니다.

딥 다이브 (Deep Dive)

리더는 모든 영역에서 세부 정보에 파악하고, 지속적으로 데이터를 감시하면서, 모든 데이터에 대해 회의적인 시각을 견지합니다.

높은 수준의 기준 목표 (Insist on the Highest Standards)

리더들은 끊임없이 높은 수준의 목표를 가지고 있습니다. 많은 사람들이 그 기준이 너무 높다고 생각할 수도 있습니다. 하지만, 리더는 지속적으로 그 기준을 높이고 팀을 이끌고 고품질 제품, 서비스 및 프로세스를 제공합니다. 리더는 결함을 지속적으로 살펴보고, 문제가 해결되도록 합니다.

이러한 리더쉽 원칙을 기반으로 아마존은 팀이 나뉜 후 소프트웨어 개발 프로세스를 데이터로서 측정했습니다. 그 결과, 각 서비스는 코드 커밋부터 배포까지 평균 16일이 걸렸습니다. 상당한 팀의 운영 담당자가 이메일과 이슈 티켓을 포함하여 다양한 수동 작업으로 배포를 진행한 것으로 나타났습니다. 다시 말해, 각 팀의 개발자들은 배포 과정의 대부분의 시간을 기다리면서 보냈습니다.

아마존이 해결해야 할 문제는 개발자들이 기다리지 않도록 모든 과정을 자동화하는 것이었습니다. 여기서 바로 개발 문화와 개발 도구가 서로 밀접한 관계가 있다는 점을 깨닫기 시작했습니다. 문제가 무엇인지 깊이 들여다 보고, 데이터로서 이를 증명하지 하는 문화적 지향이 없었다면, 아마 아마존은 오늘날의 위치에 있지 않을 것입니다.

빌드 및 배포 – 브라질(Brazil) 및 아폴로(Apollo)

아마존에서는 개별 팀의 개발자가 빌드 명령을 실행하는 데 시간을 낭비하지 않도록 브라질(Brazil) 이라는 중앙 집중식 호스팅 빌드 시스템을 만들었습니다. 브라질 의 주요 기능은 반복적인 빌드 재현성에 중점을 두고 컴파일, 버전 및 종속성 관리를 해 주는 것입니다. 브라질 은 일련의 명령을 실행한 후, 배포를 위한 아티팩트 생성 및 저장소를 제공합니다.

각 개발팀이 브라질에서 생성된 아티팩트를 배포하기 위해 아폴로(Apollo)를 개발했습니다. 아폴로는 개별 서비스 서버에 소프트웨어 아티팩트를 단계 별로 안정적으로 배포할 수 있습니다. 개발자가 하나의 서버 배포 작업만 정의하면, 전체 서버 호스트에 자동으로 동일하게 배포됩니다. 따라서, 개발자는 애플리케이션을 테스트, 스테이지, 프로덕션 환경에 배포할 때, 개별 호스트에 로그인하거나 커맨드를 실행할 필요가 없죠. 이러한 자동 배포는 병목 현상을 제거하고 각 서비스 팀이 고객에게 새로운 기능을 신속하게 제공 할 수 있게 해줍니다.

현재 모든 아마존 개발팀은 Apollo 를 광범위하게 사용하고 있으며, 엄청난 기능 개선이 이루어졌습니다. 예를 들어, 상태 확인을 통해 롤링 업데이트를 수행하여 업그레이드 중에서도 애플리케이션을 계속 사용할 수 있습니다. 또한, 서버 집합이 별도의 데이터 센터에 분산된 경우, 각 위치의 여러 호스트에 동시에 배포 할 수 있습니다. 이러한 기능을 사용하면 배포 중에 애플리케이션 서비스 로드 균형을 유지하고, 어떤 위치에서 장애가 발생할 경우 서비스 가용성을 유지할 수 있습니다. Apollo 는 각 호스트의 배포 상태를 추적하고, 모든 작업을 수행하는 중 정보를 수집하여 배포 중 발생할 수 있는 문제를 해결합니다.

클라우드 환경에서 흔히 쓰이는 방식인 사전에 제작된 사용자 지정 Amazon Linux Image (AMI)를 배포 방식이 Apollo로 부터 시작됐다는 점에 주목할 가치가 있습니다. 이러한 사용자 지정 이미지는 필수 구성 요소가 포함 된 표준 OS 환경을 함께 배포할 수 있어 쉽게 표준화 할 수 있습니다 Apollo 에 대한 더 자세한 내용은 Werner Vogels의 블로그 게시물을 참조하시기 바랍니다.

맞춤형 배포 구성 – 파이프라인 (Pipeline)

자동화 된 빌드와 배포만으로 모든 것을 해결할 수 없습니다. 빌드와 배포는 더 큰 과정의 일부입니다. 개발자가 소스 코드를 커밋하는 순간을 시작하고 변경 사항이 프로덕션 환경에서 성공적으로 배포되는 과정에는 여러 가지 작업 단계가 있고, 이는 팀마다 제각각입니다.

파이프 라인(Pipeline) 도구는 전체 워크 플로를 수행하는 모델을 도식화 하고, 이를 통해 개발자가 수동 개입 없이 모든 과정을 자동화 할 수 있는 연속 배포 시스템입니다. 물론 모든 것을 완전히 자동화 할 수 있는 것은 아닙니다. 중요한 시스템을 가진 팀의 수동 승인 같은 작업도 파이프 라인 에 포함 시켜, 팀이 원하는 가장 편한 단계를 자동화 및 체계화합니다.

파이프 라인 은 테스트, 보안 및 감사 등 컴플라이언스 검증 또는 수동 승인 등 검증 단계가 모두 이루어질 수 있습니다.

샘플 파이프 라인 — 아마존의 파이프라인 도구를 통해 도식화한 샘플 배포 과정

위의 예제는 패키지를 버전 세트로 빌드한 다음, 감마(Gamma) 단계에서 다양한 규정 준수 여부를 검사한 후 프로덕션 단계를 거치고 있습니다 각 화살표는 다음 단계로 진행되기 전에 유효성 검사 게이트 역할을 하는 과정입니다.

초기 파이프 라인 시스템은 소수의 팀을 위한 파일럿 프로그램으로 개발 되기 시작하였습니다. 파일럿이 끝날 무렵, 코드 커밋에서 배포까지 걸리는 총 시간이 90% 단축 되었습니다. 파이프라인 시스템의 성공 덕분에 다른 아마존 서비스팀도 자연스럽게 배포 프로세스를 파이프 라인으로 마이그레이션하기 시작했습니다. 덕분에 자체적인 출시 프로세스가 있는 팀들도 모든 사람이 사용하는 표준화 방법으로 통합할 수 있었습니다.

파이프라인으로 마이그레이션을 통해 각 서비스 팀은 전체 배포 프로세스를 간소화 할 수 있었을 뿐 아니라 공통 로깅, 모니터링 등 다른 시스템과도 긴밀하게 통합되어 있습니다.

3. 전사 도구 적용 및 표준화

브라질, 아폴로 및 파이프 라인 같은 공통 개발 도구들은 각 서비스팀의 배포 주기를 더 빠르게 함으로서 아마존과 고객 모두에게 큰 혜택을 가져 왔습니다. 많은 소프트웨어 기능 변경이 손쉽고 빠르고 이루어졌으며, 2014년에만 수천 여개 마이크로서비스 팀이 연간 5천만회 이상의 배포를 진행했습니다. 2019년에는 이것이 수억 회의 배포로 성장했습니다.

무엇 보다 중요한 것은 소프트웨어 제공 속도를 높이는 동시에 이러한 도구를 전사적으로 광범위하게 채택하여 배포 프로세스 일관성, 표준화 및 단순화를 통해 배포 실패의 위험이 현저히 줄었습니다. 그 결과, 고객 경험이 크게 향상되었으며, 이것이 운영 탁월성의 본질입니다.

각 서비스팀의 기술 플랫폼에 대해서는 자율성을 주되, 공통 개발 도구에 대해서는 고객 중심의 사고를 통해 효율성과 표준화를 이루는 것이 중요합니다.

아마존처럼 회사 내에서 개발 도구를 “광범위하게 채택”하여 일관성, 표준화 및 프로세스 단순화를 실현하려면 어떻게 해야 할까요? 이 질문에 대한 해답은 다음 글에서도 충분히 다룰 예정으로, 아마존에서는 이를 프로세스 혹은 메커니즘이라고 부르고 있습니다.

좋은 메커니즘은 개발 도구 개발, 채택 및 검증의 세 단계로 원활이 돌아가면서 만들어집니다. 도구가 만들어졌다면, 이를 채택 할 수 있는 교육 및 방법을 제공해야 하며, 각 도구에 대한 피드백을 거쳐 다시 개선하는 작업이 진행되어야 합니다.

아마존에는 여러 방법으로 기술 지식을 이전할 수 있도록 개발자들이 교육하고, 사례를 공유하는 문화를 가지고 있습니다. 이 부분이 매우 중요합니다:

아마존은 누구나 등록 할 수 있는 수많은 교육 및 부트 캠프를 제공하고 있습니다. 각 역할에 따라 일부는 강제적이며 일부는 자발적입니다. 필수 세션은 소위 학습 과정이 자동으로 표시되고, 역할을 따른 역량을 강화하는 표준 방법입니다.
아키텍처 패턴 및 코딩 모범 사례에 이르기까지 다양한 주제를 다루는 동영상, 기술 백서, 교육 훈련 및 위키 페이지를 공유하는 내부 저장소가 있습니다.
아마존에서는 다양한 피드백을 수집할 수 있는 데이터 기반의 조사 도구를 가지고 있으며, 이를 정량화 하여 기능 개선에 활용할 수 있습니다.

“공기와 마찬가지로 지식은 생명에 필수적입니다. 공기가 살아가는데 필수 있듯 누구도 거부해서는 안됩니다.” ― 앨런 무어

배울 점

마지막으로 아마존의 운영 탁월성의 두번째 주제인 개발 도구 측면에서 우리가 배워야 할 점은 무엇일까요? 먼저 여러분의 고객을 위해 서비스 품질에 대한 높은 기준을 세우고 이를 달성하기 위해 함께 노력해야 합니다. 이를 달성하려면, 어떤 데이터를 측정해야 하는지 그 결과에 따라 문제를 해결하고, 이를 전사적으로 표준화 하는 것이 필요합니다.

아마존의 사례 처럼 코드 커밋에서 배포에 걸리는 시간을 알고 계십니까? 배포 중에 몇 단계를 거치고, 그 과정에서 얼마 만큼 장애가 발생하는지 알고 계신가요? 탐지되지 않은 보안 위협이 몇 개인지 알고 있습니까?

(1) 개발 조직이 잘 할 수 있는 가장 중요한 것 중 하나는 모든 것을 데이터로 측정하는 문화를 육성하는 것입니다. 데이터를 측정하지 않으면 아무것도 알 수 없습니다. 데이터 측정을 통해서만 조직에서 누락된 사항을 파악하고 개선에 필요한 도구를 개발할 수 있습니다.

(2) 데이터 측정 결과를 기반으로 구축된 개발 도구가 올바른 도구인지 확인하려면, 먼저 소수의 팀에서 시범 운영하고 성공 사례가 너무 좋아서 다른 팀에게도 자연적으로 전파 될 때까지 개선을 반복하시기 바랍니다. 이를 위해서는 계속 데이터를 측정해야 합니다. “충분히 좋은 상태”에 만족하지 말고 기준을 더욱 높이 올리시기 바랍니다.

(3) 회사 전체에 지속적으로 개선되는 표준화된 도구 체인 을 보유하는 것이 중요합니다. 때로는 개발자들은 개발 도구의 표준화를 싫어하지만, 일관되게 단순화 시키고 도구를 개선하면 모든 개발자와 팀 생산성에 즉시 도움이 됩니다.

(4) 전체 개발 조직에 도움이 되도록 지속적으로 개발자를 교육시키고, 회사 내 지식 공유를 장려하십시오. 이를 위해 위키나 블로그 (Slack, Notion 같은 도구도 좋습니다) 뿐만 아니라, 사내 세미나 등 공유할 수 있는 시간과 기회를 늘리시기 바랍니다.

아마존이 만든 Brazil, Apollo 및 Pipeline은 같은 공통 개발 도구들은 AWS 개발자 도구 서비스를 만드는데 큰 영감을 주었습니다. 여러분 회상에서 AWS를 사용하신다면, 코드 레포지터리(CodeCommit), 빌드(CodeBuild), 배포(CodeDeploy), 파이프라인(CodePipeline), 테스트(X-Ray), 모니터링(CloudWatch)를 통해 장점을 경험해 보실 수 있습니다. 만약, 소규모 팀인 경우, 모든 개발 도구를 통합한 AWS CodeStar와 같은 통합 도구를 권장합니다 .

이들 도구는 아마존이 경험한 방식 그대로 차용하여 애플리케이션을 개발 및 배포할 수 있도록 설계되었습니다. 특히, 클라우드가 제공하는 가장 큰 혜택 중 하나인 인프라 자원을 코드로 직접 프로그래밍 할 수 있는 Infra as Code(IaC)를 활용하여 지속적인 통합 및 배포(CI/CD)를 통해 소프트웨어 개발 주기를 더 빠르게 가속화 할 수 있습니다.

다음 글에서는 운영 탁월성(Operational Excellence)을 지속적으로 달성할 수 있는 가장 중요한 부분 프로세스와 메커니즘에 대해 알려드리도록 하겠습니다.

더 읽어 볼 글

- Channy Yun (윤석찬);

※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)