스타벅스를 통해서 소프트웨어 확장성 배우기

엔지니어 게시판
[엔지니어 게시판 글쓰기 사용 방법]

[code]
게시글을 쓰실때 여기에 소스코드를 넣어주시면 코드가 깔끔하게 정리되어 보여집니다 :)
[/code]

스타벅스를 통해서 소프트웨어 확장성 배우기

출처:

What Starbucks can teach us about software scalability (2016-04-07) by Weronika Łabaj

Originally posted on Particular Software blog

많은 사람들은 확장성 있는 소프트웨어를 만들려고 하지만, 처음 생각했던 것보다 매우 어려울 수 있다. 개별 작업을 하면서 "모든 것의 중요성은 동일하고, 동일한 자원을 필요로하고, 정해진 순서대로 동기적으로 진행한다" 라고 생각하는 함정에 빠져 버리는 것이다.

사실, 적어도 확장성 있는 시스템에서는 적용되지 않는다. 물론 스타벅스에서도 그렇다.

 

커피를 내는 단계

 

스타벅스는 4개의 단계를 거쳐 커피가 나온다.

첫째로, 선착순 규칙에 따라 고객이 카운터 앞에서 행렬(큐)를 만들고 주문한다.

그러면 점원(바리 스타)가 고객으로부터 주문을 받고 대금을 받는다.

3단계에서는 점원이 음료를 준비한다.

4단계에서는 준비가 된 곳에서 음료수를 카운터에 놓아 두고 고객의 이름을 부른다.

이것은 이치에 맞는 모델 같지만 순식간에 긴 줄이 생긴다. 1명의 인간이 한번에 하나 이상의 기능을 수행 할 수 없다. 결국 바리스타가 차례대로 하나씩 주문을 소화하고 있는 가운데 고객들은 열을 만들기 시작한다. 만약 더 많은 고객을 지원하려면, 확장성을 확장해야 한다. 거기에 어떤 방법이 있는지 살펴보자.

바리 스타의 확장성 확장

스타벅스가 확장성을 확장하는 방법 중 하나는 슈퍼 바리스타 , 즉 재능 있고, 일을 재 빠르게 해낼 총명한 인물을 고용하는 것이다. 슈퍼 바리스타는 스스로의 성장을 매우 중요시 하고, 모든 측면을 최적화하고, 항상 효율성을 높여야한다. 소프트웨어 세계에서는 이러한 접근 방식을 확장(수직 스케일) 이라고 한다.

확장 전략은 "1명이 작업 할 수 있는 속도(및 시간)에는 한계가 있다" 라는 문제점이 있다. 슈퍼 바리스타라고 해도, 어떤 시점에서는 요구에 응할 수 없게 되어 버린다. 그렇게 되었을 경우에는 고객이 좌절감을 느끼고 가게를 떠나 돌아 오지 않을지도 모른다.

마찬가지로 모두가 순차적으로 진행하는 소프트웨어는 최적화 할 수 있는 범위에 한계가 있다. 200GHz의 CPU는 살 수 없다. 최대 CPU 군조차도 최고에서도 클럭 주파수가 3 ~ 4GHz 이하의 코어에 의한 멀티 코어이다.

스타 벅스에서 스케일 하는 방법으로 보통 점원을 증원 할 수 있는 업무 체계로 하는 방법도 있다. 이것은 소프트웨어에서 말하는 동시성 그 자체이다. 구체적으로는 1명의 바리 스타가 주문을 받으면 또 한 명의 바리 스타가 그것을 만들기 시작한다. 그러면 첫 번째 주문을 준비하는 동안, 1번째 바리 스타는 동시에 다음의 주문을 받을 수 있다.

수요가 어느 수준에 도달했을 때만 병렬 처리를 고려하는 것이 최선이라고 생각하는 분도 있을 것이다. 하지만 불행히도 그렇게 쉽지 않다. 필요할 때만 동시 처리로 전환하는 마법의 스위치는 없다. 따라서 미리 준비해야 한다.

스타벅스는 이것을 알고, 심지어 점원이 1 명 밖에 시프트에 들어 있지 않아도, 병행 처리에 필요한 것은 새로운 매장의 개점 첫날부터 모두 갖추고 있다. 즉, 언제든지 증원 할 수 있는 체제를 갖추고 있는 것이다.

교훈: 원활하게 동시성을 도입하기 위해 병행 처리를 지원하는 시스템 구축이 필요하다.

이것을 스타벅스가 어떻게 실현하고 있는지 살펴 보자.

 

메시지의 전달이 기본

 

스타벅스에서 커피를 주문한 경험이 있는 분이라면, 컵의 사각 마크에 기호가 적혀 있는 것을 본 적이 있을 것이다. 이 기호는 바리 스타가 사용하는 약어로 음료와 토핑(휘핑 크림 폼 우유 등)을 한눈에 파악하기 위해 사용되고 있다.

컵 혹은 메시지는 점원끼리 의사 소통을 위해 필수적이다. 컵은 바리스타에게 음료를 준비 할 필요가 있음을 알리는 신호가 되고, 거기에 쓰인 기호를 보면 준비하는 음료 종류가 자세히 알 수 있다. 가게가 혼잡하지 않고 카운터에서 접객 중의 점원이 1 명 밖에 없을 때도 점원은 반드시 컵에 기호를 쓴다.

언뜻 보면 이것은 불필요한 작업이라고 생각할 수 있다. 하지만 이 작업을 하고 있으면 갑자기 많은 손님이 입점했을 때, 대기하고 있던 점원은 즉시 도와 줄 수 있다. 그들은 물론 전달 사항을 듣지 않고도 메시지대로 음료수를 만드는 것을 시작할 수 있다.

교훈: 점원을 증원하고 작업을 분담 할 준비가 항상 갖추어져 있으면, 갑자기 바빠져도 문제는 발생하지 않는다. 이를 방법으로 메시지 사용이 있다.

분할 통치

상술한 바와 같이, 커피를 만드는 일련의 작업은 점원, 즉 바리스타 혼자서 담당 할 수 있다. 그러나 스타벅스의 기본 인력은 1명의 점원(계산대 담당)이 주문 및 회계 처리하고 다른 점원 (바리스타)이 음료를 만들 수 있게 되어 있다.

일반적으로 커피를 만드는 공정에 가장 시간이 많이 걸리기 때문에 가게가 혼잡하게 되면 여러 사람의 바리스타가 음료를 준비한다. 그들은 대개 같은 장소에서 컵을 가지고 일을 공평하게 분담한다. 이것은 Competing Consumers(경쟁하는 이용자) 패턴의 예이다.

그러나 이 방법으로 문제가 생기는 경우도 있다. 예를들면 바리스타가 3명 있고, 커피 기계 및 프라푸치노 머신이 각각 1대씩 있는 경우를 생각해 보자. 이 상황에서 3 명의 손님이 커피를,  그 다음 손님이 프라푸치노를 주문했다고 한다. 주문을 받는 직원이 각각 해당 기호를 쓴 컵을 4개 차례로 나열하면 바리스타는 각자 커피를 만들기 위해 컵을 손에 든다. 이 경우, 1번째가 커피를 만들기 시작하면 다른 두 사람은 커피 머신을 사용할 수 있을 때까지 기다릴 수 밖에 없다.

이러한 리소스 충돌은 작업을 분할하여 해결할 수 있다. 그 방법 중 하나가 메시지를 세분화 된 종류로 분할하여 별도로 처리 할 수 있도록 하는 것이다. 예를 들어 앞에서 언급한 바와 같이, 스타벅스 컵을 이용하여 음료 준비가 필요하다고 전하고 있다. 이 시스템은 동시에 따뜻한 음료와 차가운 음료를 구별하고 있다. 따뜻한 음료는 종이 컵에 차가운 음료는 플라스틱 컵이다. 즉 따뜻한 커피 3개, 그 다음에 프라푸치노 하나라는 순서로 주문이 들어오면 거기에는 종이 컵 3개와 플라스틱 컵 하나를 따로 나누어 둔 상태이다. 1 번째 바리스타가 먼저 놓인 종이 컵 속에서 컵을 하나 잡고 음료를 만들기 시작한다. 두 번째 바리 스타는 커피 머신이 사용 중임을 보면 다음에 놓인 플라스틱 컵 속에서 컵을 잡고 대신 프라푸치노 기계를 사용한다. 이렇게 하면 두 음료를 동시에 사용할 수 있다.

이렇게 바리스타가 작업을 분담해서 병행 처리를 하는 작업 분담을 파티셔닝 이라고 한다.

교훈: 파티션은 확장 전략에서 매우 중요한 요소라고 할 수 있다. 모든 작업을 같은 기준으로 확장할 필요는 없고, 곧 끝날 소규모 작업은 혼자서, 수고와 시간이 걸리는 작업은 여러 사람이 대응하도록 한다. 이렇게 파티셔닝을 하면 각각의 활동을 개별적으로 확장 할 수 있다.

작업마다 중요성은 서로 다르다

스타벅스의 성공 요인 중 하나는 단골 손님을 파악하는 것의 중요성을 교육을 통해 직원에게 인식시키고 있다는 점이다. 단골 손님은 예를 들어 매일 아침 팀을 위해 벤티 사이즈의 아메리카노와 그란데 사이즈의 커피를 2개씩 구입하러 오는 남성과 매주 수요일 톨 사이즈의 카라멜 마끼아또를 주문하고, 점내에서 1 시간 정도 독서하는 여성 등이다.

수요일에, "톨 사이즈의 카라멜 마끼아또의 여성"이 가게에 들어온 것을 바리스타가 알았다. 점원은 그녀가 카운터에 도착하기 전에 여성이 좋아하는 음료를 준비하기 시작한다. 원하는 상품을 이야기 하지 않아도 알고 있는 것에 여성 손님은 즐거운 놀라움을 느낀다. 검수 담당자는 그녀가 항상 요구하는 음료를 미리 알고 있었기 때문에 그녀에게 인사를 하고 대금을 받은 뿐이다. 지불이 끝나기 전에 그녀의 커피는 이미 카운터에 준비되어 있을 것이다.

스타벅스의 단골 손님의 비율이 얼마나 높은지를 알면 여러분은 놀랄 것이다. 단골 손님이 가능한 좋은 경험을 얻을 수 있는 것에 높은 우선 순위를 두고 있다. 단골 손님은 다른 손님보다 빨리 음료수를 받는 일이 자주 있다. 이를 통해 단골 손님은 자신이 소중히 여겨지고 있다고 느끼고 또 오고 싶어한다. 이렇게 하여 스타벅스에 대한 그들의 가치는 더욱 높아질 것이다.

교훈: 다른 것에 비해 중요도가 높은 작업이 있다. 표준적인 활동을 재사용 가능한 개별 기본적인 요소로 정리하면 필요에 따라 쉽게 프로세스를 수정할 수 있고, 보다 가치가 높은 작업에 뛰어난 서비스를 제공한다.

모든 실수를 방지 할 필요는 없다

지금까지 소개한 예는 어떤 경우에도 스타 벅스의 점원은 손님이 커피를 받기 전에 지불을 마쳤는지 확인해야 한다. 이를 위해 바리스타는 손님에게 음료를 건낼 때 영수증을 제시하도록 요청할 수 있다 . 그러나 실제로는 그런 것은 하지 않는다.

대금을 지불하지 않고 커피를 받으려고 하는 사람은 거의 없다고 스타 벅스는 깨달았다. 그들의 분석에 따르면, 때때로 일어나는 커피 손실을 막으려고 주의하는 것 보다 주문에 대한 대응에 집중하는 것이 도움이 되는 것이다. 만약 누군가가 우연히 다른 사람이 주문한 커피를 받아 버리면(이것은 보통 착오가 발생한 경우에만 일어날 것이다) 바리스타는 그 사람을 위해 무조건 새로운 커피를 준비한다.

교훈: 확장 가능한 시스템을 구축하려면 어느 정도의 실수는 불가피하다는 생각을 받아 들일 필요가 있다. 실수를 완전히 막으려고 하면 비용이 너무 높아진다. 그 대신에 실수가 발생하면 즉시 문제를 발견하고 확실하게 보완에 주력해야 한다.

정리

일견 간단하게 보이는 커피를 만드는 4단계의 작업이 흥미로운 비즈니스 프로세스로 발전했다. 얼핏 보기에 예외적으로 레어 케이스라고 생각했던 것이 비즈니스의 필수적인 부분임을 알았다.

수요의 급증과 미스는 하루에도 몇 번씩 일어날 수 있는 상황이다. 이러한 사태에 잘 처리 할 수 있는 시스템을 디자인 하려면 일반적인 가정에 의문을 제기 해 볼 수 있어야 한다. 많은 경우 처음 생각해낸 모델은 그러한 과제에 대한 배려가 부족한다. 또한 고려해야 할 예외적인 상황은 많이 있다. 예를 들어, 주문의 취소는 그 자체가 매우 흥미로운 문제이다 .

스타벅스의 예에서 알 수 있듯이 비즈니스에서 간단한 대처를 하는 것으로는 더 많은 이용객으로 서비스를 확대 할 수 없다. 손님이 많을수록 서비스의 수준은 저하되고, 손님이 뜸하게 되어 버린다. 그렇게 되지 않게 증가하는 요구에 대응할 수 있도록 업무를 체계화해야 한다.

결국, 확장성 있는 시스템을 구축하는 것은 기술에 대해 다시 생각하는 것처럼 비즈니스 프로세스를 다시 생각하는 것이다.

확장성 있는 소프트웨어의 구축 방법에 대해 더 알고 싶은 분은 아래의 참고 자료를 참조한다.

 

 

 

<원문/출처:https://docs.google.com/document/u/0/d/1ejA5RRhvVRgkoIJN8Ll_7r5J82537EbRDFz0Y1BGsK0/mobilebasic>

Comments

번호 분류 제목 글쓴이 날짜 조회
288 코딩,소프트웨어 Enum 클래스를 활용한 상태 관리 Rakulee 00:42 8
287 IT,Tech 뉴스정보 KMM (Kotlin Multiplatform Mobile)을 이용한 공통 코드 개발 Rakulee 10.23 12
286 LeetCode솔루션 695. Max Area of Island Rakulee 10.21 29
285 IT,Tech 뉴스정보 Selenium을 활용한 브라우저 자동화 Rakulee 10.19 54
284 코딩,소프트웨어 Repository 패턴 Rakulee 10.19 56
283 코딩,소프트웨어 String 암호화 코드 Snippet Rakulee 10.17 62
282 IT,Tech 뉴스정보 Os.js, 자바스크립트 기반 운영체제 Rakulee 10.16 69
281 IT,Tech 뉴스정보 Postman을 이용한 RestAPI 테스트 Rakulee 10.13 82
280 코딩,소프트웨어 Android - Databinding 기능을 이용한 레이아웃 레벨에서의 값 변경 Rakulee 10.12 108
279 코딩,소프트웨어 Android 개발에서의 Navigation Graph 사용 Rakulee 10.11 136
278 코딩,소프트웨어 Android 개발에서 Countdownlatch를 활용한 디버깅 Rakulee 10.09 108
277 LeetCode솔루션 [10월 1주차] 995. Minimum Number of K Consecutive Bit Flips - Google, Ama… jack 10.04 165
276 LeetCode솔루션 [10월 1주차] 78. Subsets - Facebook, Amazon, ByteDance, Bloomberg, Google… 댓글+2 jack 10.04 445
275 LeetCode솔루션 [10월 1주차] 141. Linked List Cycle - Microsoft, Amazon, Bloomberg, Googl… 댓글+1 jack 10.04 167
274 코딩,소프트웨어 Android 개발에서의 Base 클래스 사용 Rakulee 10.03 119
273 LeetCode솔루션 136 Single Number 문제 풀이 영상 Rakulee 10.02 142
272 코딩,소프트웨어 Next.js 그거 어떻게 하는 건데. 룰루나비 09.30 142
271 LeetCode솔루션 [9월 5주차] 239. Sliding Window Maximum - Amazon, Facebook, Google, Goldm… 댓글+3 jack 09.27 403
270 LeetCode솔루션 [9월 5주차] 784. Letter Case Permutation - Amazon, Spotify, Apple, Micros… 댓글+2 jack 09.27 184
269 LeetCode솔루션 [9월 5주차] 338. Counting Bits - Google, Adobe 댓글+3 jack 09.27 177
268 LeetCode솔루션 [9월 4주차] 327. Count of Range Sum - Cisco jack 09.20 227
267 LeetCode솔루션 [9월 4주차] 128. Longest Consecutive Sequence - Google, Microsoft, Amazon… 댓글+4 jack 09.20 455
266 LeetCode솔루션 [9월 4주차] 303. Range Sum Query - Immutable - Facebook, Adobe 댓글+4 jack 09.20 429
265 LeetCode솔루션 235. Lowest Common Ancestor of a Binary Search Tree Rakulee 09.16 190
264 LeetCode솔루션 [9월 3주차] 632. Smallest Range Covering Elements from K Lists - Amazon, … jack 09.14 250
263 LeetCode솔루션 [9월 3주차] 79. Word Search - Amazon, Microsoft, Snapchat, Bloomberg, App… 댓글+2 jack 09.14 222
262 LeetCode솔루션 [9월 3주차] 53. Maximum Subarray - LinkedIn, Amazon, Microsoft, Apple, Ad… 댓글+2 jack 09.14 266
261 IT,Tech 뉴스정보 개발자 나이가 들면서 꾸준히 학습하고 운동해야 하는 이유 Doge 09.02 300
260 LeetCode솔루션 [9월 1주차] 23. Merge k Sorted Lists - Amazon, Facebook, Microsoft, Apple… 댓글+2 jack 08.31 346
259 LeetCode솔루션 [9월 1주차] 48. Rotate Image - Amazon, Microsoft, Apple, Google, Adobe, F… 댓글+2 jack 08.31 367
258 LeetCode솔루션 [9월 1주차] 121. Best Time to Buy and Sell Stock - Amazon, Apple, Microso… 댓글+1 jack 08.31 317
257 프로젝트 [web] 3일간 만들어본 채팅앱 달빛조각사 08.31 293
256 프로젝트 유럽 코로나 확진자 수 프로젝트 개발/실패기 룰루나비 08.29 270
255 프로젝트 프로덕트 중심적 사고 vs. 프로젝트 중심적 사고 룰루나비 08.25 279
254 LeetCode솔루션 [8월 4주차] 25. Reverse Nodes in k-Group - Microsoft, Amazon, Facebook, G… 댓글+1 jack 08.24 342
253 LeetCode솔루션 [8월 4주차] 54. Spiral Matrix - Microsoft, Apple, Amazon, Intuit, Bloombe… 댓글+3 jack 08.24 369
Category

State
  • 현재 접속자 74 명
  • 오늘 방문자 607 명
  • 어제 방문자 514 명
  • 최대 방문자 2,210 명
  • 전체 방문자 154,319 명
  • 전체 게시물 2,889 개
  • 전체 댓글수 375 개
  • 전체 회원수 478 명