이굿위크란?이굿위크는 이커머스의 블랙프라이데이 행사를 29CM 에 맞게 재해석한 것을 말합니다. 23년 11월에 진행한 이굿위크는 많은 고객분들의 사랑에 힘입어 기대 이상의 성공을 거두었습니다. (다시 한번 29CM 을 사랑해주시는 많은 분들에게 감사의 말씀 드립니다)29CM, 블랙프라이데이 ‘이굿위크’ 오픈 하루 만에 거래액 120억 돌파29CM, 블랙프라이데이 ‘이굿위크’ 성료··· 열흘 간 판매액 3배 이상 증가이번 이굿위크에서는 29CM 만의 차별화된 브랜드 셀렉션을 고객들에게 다수 선보임과 동시에 플랫폼 관점에서도 이굿위크를 이용하는 고객을 위해 다양한 맞춤형 기능을 제공했습니다. 이굿위크 티져, 마이셀렉션, 럭키쿠폰과 하루특가, 이굿입점회와 이굿라이브, 브랜드 팝업과 이굿상품과 같은 다양한 기능을 통해 이굿위크에 대한 고객의 기대치를 충족시켰고, 거기에 더하여 고객분들이 선호하는 감도 높은 브랜드 상품을 좋은 가격에 다수 제공했던 것이 이굿위크의 성공 비결이라고 생각하고 있습니다. 그리고 실제로 23년의 이굿위크는 전년 대비 286% 증가한 판매액을 기록하게 되었습니다. (이굿위크를 준비했던 제품팀의 제품 전략과 실행 과정은 이굿위크 : 작년보다 2배 더 잘하기 위한 전략과 실행을 통해 자세하게 확인 가능합니다)하지만 29CM 의 시스템을 개발하고 운영하는 엔지니어의 관점으로 23년의 이굿위크를 돌아본다면, 이굿위크 시작과 동시에 발생했었던 장애 상황에 대한 아쉬움이 크게 남는 것은 어쩔 수 없을 듯 합니다.이 글에서는 오픈하자마자 평시 대비 7배 이상의 트래픽이 순간적으로 인입되면서 장애가 발생하고, 그러면서도 하루 거래액 121억을 돌파했었던 23년 11월 13일의 29CM 서비스 운영 과정을 공유하고자 합니다.Phase 1. 장애 발생 직후이커머스에서 블랙 프라이데이라는 행사는 1년 중 가장 큰 트래픽과 매출이 발생하는 프로모션입니다. 그 때문에 블랙 프라이데이를 준비하는 각 플랫폼 서비스들은 순간적으로 높게 튀는 트래픽 상황에서도 안정적인 서비스를 제공할 수 있도록 만반의 준비를 하게 됩니다. 예상하는 트래픽에 맞게 장비를 증설하고 병목이 발생할 수 있는 구간마다 이슈가 발생하지 않도록 사전에 개선 작업을 진행합니다.29CM 에서도 이굿위크를 준비하는 과정에서 예상하는 트래픽에 맞게 인프라를 증설하고, 병목 발생 가능성이 높은 구간마다 별도의 개선 작업을 진행하면서 고객분들을 맞이할 만반의 준비를 진행했습니다. 그럼에도 저희는 이굿위크 오픈과 동시에 약 26분 동안의 서비스 전면 장애를 경험하게 됩니다.이굿위크 시작과 동시에 장애 공지이굿위크 오픈 직후의 장애 원인은 크게 2가지입니다.장애의 첫 번째 원인은 예상보다 더 높은 수준의 트래픽이 순간적으로 인입된 상황 때문이었습니다. 오픈 직후 순간 트래픽이 높게 형성될 것을 예상하고 인프라 증설 등을 사전에 진행했지만, 전년 이굿위크의 패턴을 기반으로 예측했던 예상 트래픽을 상회하는 수준의 트래픽이 오픈 직후에 인입되었습니다. 이러한 Traffic Spike 는 서비스의

안녕하세요. LINE+ ABC Studio에서 앱을 개발하고 있는 김종식, 남상혁, 박연호입니다. 저희 팀은 현재 일본에서 운영하는 배달 서비스 '데마에칸(Demaecan, 出前館)' 프로덕트를 개발하고 있습니다. 데마에칸은 2000년부터 서비스를 시작한 일본의 No.1 음식 배달 서비스로 2020년에 LINE에서 인수했고, ABC Studio는 2021년 봄부터 프로덕트 개선에 참여하고 있습니다.일본 1위 배달 앱, 바닥부터 다시 짠다 - Recode 프로젝트, 멀쩡한 앱을 Flutter 앱으로 다시 짠 이유 - 일본 1위 배달 앱, 두 번째 Recode 글을 통해 각각 React Native(이하 RN)에서 Kotlin Multiplatform Mobile(이하 KMM), KMM에서 Flutter로 기술 전환 사례를 공유드린 적이 있습니다. 이번 글에서는 RN으로 작성되어 있던 데마에칸 ConsumerApp을 Flutter로 변환한 사례를 공유드리고자 합니다.참고로, 저희는 음식이나 리테일 상품을 주문할 수 있는 소비자용 앱을 'ConsumerApp'이라고 부르고 있습니다. 이후 이 글에서 ConsumerApp이라고 지칭하겠습니다.이전 Recode 프로젝트와의 차이점 및 프로젝트 방향 설정ABC Studio는 데마에칸 개발에 참여하면서 더 나은 배달 서비스를 제공하기 위해 '모든 앱을 하나의 기술로 제공한다'라는 목표를 세우고 많은 앱에서 Recode 프로젝트를 시작해 성공적으로 Flutter 전환을 완료했습니다.하지만 ConsumerApp은 이전에 진행한 Recode 프로젝트와는 조금 차이가 있었습니다. ConsumerApp은 데마에칸 내 다른 도메인의 앱보다 사용자 수가 많고 트래픽도 훨씬 높아서 민첩한 운영 대응이 필요한 앱입니다. 또한 여러 사업 부서에서 집중적으로 요구 사항이 몰려드는 앱이기도 합니다. 따라서 이미 일본 현지에 개발 팀이 갖춰져 오랜 시간 운영돼 왔는데요. 그렇다 보니 제품의 스펙은 서비스가 빠르게 성장하는 동안 시도된 수많은 프로젝트별로 파편화돼 있었고, 히스토리조차 찾을 수 없는 경우도 많았습니다.또한 2022년 즈음부터 사용자들의 피드백이나 만족도 분석 등을 통해 데마에칸 내부에서 UI/UX 개선이 필요하다는 의견이 대두되기 시작했습니다. 데마에칸 서비스는 앱과 웹을 거의 동일한 경험으로 제공하며, 실제 주문이 발생하는 비율은 약 8:2 정도였고, 향후 앱에 더 집중하는 것으로 방침이 결정됐습니다. 이에 따라 앱 서비스 사용 경험을 향상시키면서 동시에 사업적 목표까지 달성하기 위해서는 ConsumerApp의 기술적 쇄신을 더 이상 미루기 힘든 시점이 되었습니다.기술 스택 변경이 꼭 필요한가?기술 쇄신이 필요하다는 것은 확인했지만 그 과정에서 기술 스택을 변경하는 것이 과연 미래를 위해 더 나은 선택일지는 다시 고민해야 했습니다.ConsumerApp은 RN으로 구현되어 있었고, 나머지 도메인의 앱들은 모두 Flutter로 전환이 완료된 상태였습니다. 이와 같이 기술 스택이 나뉘어 있으면 각 도메인 영역 간

안녕하세요. 인프랩 데브옵스 엔지니어 선비입니다.오늘은 AWS CDK에서 Terraform으로 글에서 다룬 AWS CDK/Terraform, 그리고 인프콘 2022에서 발표했던 Terragrunt를 지나서 Pulumi에 정착하게 된 인프랩의 IaC 구축기를 풀어보고자 합니다.이번 Part 1 글에서는 Terragrunt를 두고 또 한 번 새로운 도구로 넘어오게 된 배경과 과정, 그리고 이제는 정착할 수 있을 것이라고 생각하는 이유에 대해 한 번 이야기해보려고 합니다.먼저 이 글을 통해서 IaC를 처음 접하시는 분들을 위해 IaC에 대한 간략한 소개와, 인프랩 데브옵스 팀이 어째서 IaC를 정말 중요하게 생각하고 있는지에 대해 말씀드리겠습니다.IaC는 Infrastructure as Code(코드형 인프라)의 약자로, 코드를 통해서 인프라를 관리하는 것을 의미합니다. IaC는 인프라 관리를 자동화하는 다양한 방법 중에서도 소프트웨어 개발 방법론 등 소프트웨어 개발을 위한 수많은 기술과 도구들을 인프라 관리에 적용할 수 있도록 하므로 특히 강력한 방법이라고 할 수 있습니다.제가 인프랩에 합류한 2021년 9월 당시까지만 하더라도 인프랩의 인프라 구성은 메인 서비스 컨테이너와 Redis 캐시, PostgreSQL 데이터베이스, 람다 함수 몇 가지 정도로 그다지 복잡하지 않았습니다. 또한 변화가 일어나는 경우도 많지 않았기 때문에 이 때의 인프라 구성 작업은 대부분 웹 콘솔에서 수동으로 진행되었고 몇 개의 리소스만 AWS CDK를 이용하여 구성하는 상태였습니다.하지만 2021년 말부터 랠릿이 개발되면서 인프라 구성 업무가 급속도로 늘기 시작했습니다. 그 때는 제가 인프랩에 데브옵스로 합류하면서 팀 내 비효율을 기술로 해결하겠다는 당찬 포부와 함께 2년 내에 만들고자 했던 두 가지에 집중하던 시기였는데요,• 전문 지식이 없이도 팀원들이 고수준의 자동화를 직접 구축할 수 있도록 도와주는 추상화가 잘 된 신뢰할 수 있는 파이프라인 시스템• 팀원들이 방향 설정과 동기 부여에 사용할 만한 모든 데이터를 일관적인 방식으로 수집하고 시각화하는 모니터링 시스템몇 가지 조사를 한 후 단기간 내에는 이러한 목표를 달성하기 어렵다는 결론을 내림과 동시에, 이들을 달성하기 위해서는 첫째로 반드시 개인이 아닌 팀으로서 효율적으로 협업할 수 있어야 하고, 둘째로 내일은 오늘보다 더 효율적으로 일할 수 있게 만드는 환경이 준비되어야 한다는 생각을 하게 되었습니다. 즉, 시행착오를 통해 알아낸 정보를 일시적으로 활용하는 것을 넘어 업무 흐름에 적용함으로써 팀원들의 노력을 차곡차곡 쌓아나갈 수 있는 업무 방식이 기반이 되어야 한다고 생각하였습니다.그리하여 시급한 업무를 진행하는 시간을 빼고는 대부분의 시간과 노력을 업무 방식 개선에 투자하게 되었고, IaC 도입은 가장 핵심적인 업무 방식 개선 방안이었습니다.이 때 생각했던 원하는 수준의 IaC는 다음과 같았습니다.• 특별한 경우를 제외하고는 모든 인프라 구성을 IaC를 이용해서 할 수 있다.• 팀에서 한 번 구축해본 구성의

안녕하세요. 저는 29CM Activation Squad의 프로덕트 디자이너 김소원입니다. 지난 이굿위크 : 작년보다 2배 더 잘하기 위한 전략과 실행 글에 이어 이굿위크 사전 탐색과 바이럴을 위해 설계된 ‘마이셀렉션’에 대해 소개하겠습니다.내 취향으로 가득한 나만의 셀렉션여러분은 어떤 취향을 갖고 있나요? 지금 입고 있는 옷, 개인 공간을 채우는 인테리어 아이템 모두 우리의 취향을 나타내고 있습니다. 최근에는 취향에 진심인 사람들이 더욱 늘어나고 있으며, 취향이 곧 ‘나’라고 생각하는 ‘취향 세대’라는 용어까지 생겨났습니다. 이들은 음악, 영화, 책, 브랜드에 이르기까지 다양한 분야의 취향을 깊게 탐구하며, 자아 표현의 도구로 활용합니다.마이셀렉션은 취향에 진심인 고객들에게 취향을 발견하고, 탐구하며, 자신을 표현할 수 있는 도구입니다. 자신의 취향을 대변할 수 있는 ‘미니멀라이프’, ‘캐주얼룩’ 과 같은 테마를 설정하고, 그에 맞는 상품을 선택하여 셀렉션(상품 리스트)을 만들 수 있습니다. 이는 음악 플레이리스트를 만드는 경험과 유사한데요, 고객에게 셀렉션은 1)개인 용도에 맞게 상품을 아카이빙할 목적이거나 2)앞서 언급한 ‘취향 세대’로서 상품을 선택하는 안목을 자랑하고 취향을 표현하기 위한 수단일 수 있습니다. 생성된 셀렉션을 구경하는 고객은 새로운 취향을 발견할 수 있고, 테마를 통해 특정 상황(집들이, 하객룩 등)에서 필요한 상품을 선택하는데 힌트를 얻을 수도 있습니다.누구나 쉽게 참여할 수 있는이벤트 설계 과정에서 중요하게 생각했던 것은 ‘쉬운 참여 방법’이었습니다. 고객들이 이벤트를 참여하기 위해 복잡한 단계를 거쳐야 한다면, 그만큼 도중에 이탈할 확률이 높기 때문에 참여율에 가장 큰 영향을 줄 수 있다고 판단했습니다. 따라서 마이셀렉션은 고객이 상품을 LIKE(좋아요)한 후 셀렉션을 생성하기만 해도 이벤트에 참여할 수 있는 쉬운 구조로 설계했습니다.이굿위크 마이셀렉션 참여 방법이굿위크 사전 탐색을 위한 아카이빙마이셀렉션의 핵심 전략은 이굿위크 티징 기간부터 상품을 미리 탐색하고 아카이빙 하는 것입니다. 이를 위해 고객이 이굿위크 상품을 티징 기간동안 충분히 탐색한 뒤 마음에 드는 상품을 LIKE(좋아요)하고, 본 행사가 시작되면 LIKE한 상품의 할인 알림을 받고 구매까지 할 수 있는 심리스한 경험을 제공하는 것에 집중했습니다.이굿위크 바이럴마이셀렉션을 기획하는 과정에서 이굿위크를 홍보할 수 있는 바이럴 요소가 있다는 것을 발견했고, 이를 적극 활용했습니다. 셀렉션 생성 후 리워드를 받기 위해서는 일정 조회수를 달성해야만 합니다. 내가 만든 셀렉션을 다른 사람들이 많이 보게 하려면 어떻게 해야 할까요? 보다 확실한 방법은 커뮤니티를 비롯한 외부 채널로 나의 셀렉션을 적극적으로 공유하고 홍보하는 것입니다. 해당 기능을 통해 고객의 자발적인 공유와 홍보가 이루어지면서 자연스러운 바이럴이 형성될 수 있었습니다.결과 및 인사이트마이셀렉션은 이벤트의 핵심 전략과 이를 반영한 제품 설계로 이굿위크 성공에 크게 기여했으며, 아래의 결

유저 리서치 팀(User Research Team)에서는 작년 하반기에 처음으로 신입 리서처를 채용했어요. ‘UX 리서치 파트너(UX Research Partner)’라는 이름으로요.UX 리서처(UX Researcher)가 되기를 희망하는 분들을 만나보면 학부에서 리서치를 배웠지만, 실제 사용자를 만나기 어려운 점, 실무 프로젝트에서 리서치를 진행할 기회가 적다는 점을 많이 이야기해 주셨어요. 그리고 이 부분은 저희 리서치팀도 크게 공감이 되었어요.유저 리서치 팀에서는 신입 리서처가 되기를 희망하는 분들의 어려움을 조금이라도 개선하여, UX 리서치 생태계의 성장과 확장을 바라는 마음이 있었어요.이에 새로운 채용 형식을 설계하여 역량 있는 신입 분들을 모셨는데요. 그 과정에 대해 상세하게 설명드릴게요!토스의 핵심 가치 중 ‘Question Every Assumption’이 있어요. 모든 가정에 근원적인 물음을 제기하는 것인데요. 문제를 해결하고, 다르게 생각할 수 있는 제일 좋은 방법이에요.이처럼 신입 UX 리서처들이 겪고 있는 문제에 대해서도 “경험이 없어도 UX 리서처로서 잠재력이 있다면 금방 성장할 수 있지 않을까? 꼭 실무 경험이 필요한 걸까? 아직 시장에서 기회가 주어지지 않은 것이니, 토스 팀에서 시도해 볼 수 있지 않을까?”라는 물음을 던지게 되었어요.UX 리서처로 커리어를 쌓고 싶은 분들을 만나보면 역량과 잠재력이 있는 분들이 많았어요. 그렇기에 실무 경험이 충분하지 않아도, 빠르게 성장할 것으로 생각했어요. 토스팀은 이분들의 성장곡선에 따른 단계별 *온보딩프로그램을 지원해 드리면 되거든요.뿐만 아니라 이런 시도와 기회들이 많아지면, 새로운 리서처들이 시장에 유입되어, UX 리서치 산업이 확장하는데 기여할 수 있겠다는 기대도 갖게 되었어요.그런데 UX 리서처 커리어를 시작하실 분을 채용하려고 보니, 어떤 포트폴리오를 봐야 할지 막막했어요. 대부분이 실무 포트폴리오를 준비하기 쉽지 않을 테니까요.팀에서 치열하게 논의한 결과, 포트폴리오의 유무가 중요한 것이 아니라 잠재력, 즉 러닝 커브가 중요하다는 결론에 이르게 되었어요. 기존 UX 리서처 채용과는 다른 방식과 선정 기준이 필요했던 거죠.저희도 리서치를 할 때 [초기 목적에 맞게 리서치가 진행되는지? 문제가 맞게 정의된 것인지? 가설은 무엇인지?] 등의 질문들을 해보거든요. 끊임없이 질문에 스스로 답하며 논리적으로 문제를 정의하고, 리서치 결과를 만들어가는 능력이 향상되더라고요.이러한 사고의 흐름들이 지원서에도 잘 담길 수 있으면 좋겠다고 생각했어요. 그렇게 하려면 토스에서 리서치 할 때 고민하는 부분 위주로 지원서를 설계해서 제공하면 어떨까? 의견이 모아지게 되었어요.이 과정에서 지원자분들이 문제를 접근하는 방식과 러닝 커브를 발견할 수 있고요.지원서는 5가지 질문에 답변하는 형태에요.[리서치 배경 - 핵심 고민 - 인사이트 - 회고 - 러닝]의 흐름으로 구성되어 있는데요.리서치 과정을 단계별로 짚어보시며, 중점적인 문제와 해결 과정들을 생각하실 수 있어요. 스스로 리서치

안녕하세요. 당근 데이터 가치화팀의 Henry예요.데이터 가치화팀의 비전은 매일 데이터를 통해 사용자를 위한 의사결정을 하는 것이고, 그러기 위해서는 신뢰할 수 있는 사용자에 대한 정보가 많아야 해요. 당근 사용자들에 대한 신뢰할 수 있는 정보들을 많이 생산하기 위해서는 (1) 사용자들에 대한 정보를 이해하고 정의할 수 있는 도메인 지식과 (2) 데이터를 모델링하고 변환하고 데이터 퀄리티를 체크하고 데이터 간 의존성을 확인해서 신뢰성 있는 정보를 만들 수 있는 데이터 엔지니어링 역량이 필요하다고 생각했어요.데이터 엔지니어링 역량과 도메인 지식을 갖춘 구성원들이 많다면 신뢰할 수 있는 정보를 만들고 사용하기가 쉽겠지만, 현실적으로는 도메인 지식을 가지고 있는 구성원들 비해 데이터 엔지니어링 역량이 있는 구성원들은 적어요. 그렇기 때문에 도메인 지식을 갖고 있는 구성원이 데이터 엔지니어링 역량이 없더라도 데이터 엔지니어링 작업을 수행할 수 있도록 도움을 주는 것이 더 확장성 있는 방안이라고 생각했고, DBT와 Airflow라는 도구를 문제 해결의 매개체로 활용하고자 했어요. 그 과정에서 여러 엔지니어링 문제를 만나고 해결했는데, 그 내용을 정리해서 공유하고 싶다는 생각해서 이 글을 썼어요.데이터 가치화 팀에서 DBT와 Airflow를 활용하면서 마주친 문제는 총 7개에요. 차근차근 하나씩 살펴볼게요.어떤 구조로 DBT 프로젝트를 구성할 것인가?DBT 모델을 어떻게 저장할 것인가?DBT와 Airflow를 어떻게 integration 할 것인가?DBT 모델을 어떤 프로세스로 개발하고, 테스트할 것인가?다른 파이프라인과 DBT 모델 간의 의존성은 어떻게 챙길 것인가?국가별로 같은 모델에 대한 정의를 어떻게 할 것인가?DBT 모델의 백필은 어떻게 할 것인가?1. 어떤 구조로 DBT 프로젝트를 구성할 것인가?DBT 프로젝트를 구성하는 기본 단위는 모델이에요. 처음 DBT 프로젝트를 구상할 때, 여러 모델을 어떤 구조로 배치하고 연결해야 하는지 고민했어요. 어떤 구조로 모델을 배치하는 것이 좋을까 생각할 때, 사내 구성원이 어떤 흐름으로 사용자에 대한 데이터를 얻는지 살펴봤어요. 왜냐하면 DBT 프로젝트는 사내 구성원이 데이터를 활용하는 방식을 자연스럽게 담아야 한다고 생각했기 때문이에요. 살펴보니 구성원들은 다음과 같은 흐름으로 사용자에 대한 정보를 얻었어요.앱이 보낸 데이터를 사람의 행동 단위로 치환해요.사용자의 행동을 여러 방법을 사용해서 살펴봐요.사용자 행동을 통해 사용자가 어떤 상태인지를 추론해요.사내 구성원이 사용자 정보를 파악하는 과정을 참고해서 당근의 사용자 정보를 base, dimension, fact라는 이름의 계층으로 구조화했어요. 다음에 mart, metric, semantic layer와 같은 계층도 필요하면 추가할 예정이지만, 처음 시작하는 것이기 때문에 당근 사용자들의 정보 그 자체를 모으는 것에 더 집중했어요.DBT 프로젝트 구조의 다이어그램Base는 Source(원천 데이터)와 1:1 대응되는 계층이에요. 이 계층에서는