이굿위크란?이굿위크는 이커머스의 블랙프라이데이 행사를 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 대응되는 계층이에요. 이 계층에서는

다들 2024년 잘 보내고 계신가요? 새해를 잘 보내기 위해서는 한 해를 되돌아보면서 새해를 맞이할 준비가 필요하다고 생각합니다. 그래서 오피지지는 2024년 새해를 잘 맞이하기 위해서 지난 12월에 All Hands Meeting을 진행했습니다! 오랜만에 진행한 오프라인 모임이라서 많은 구성원분들이 참석해 주셨습니다😊우리가 가는 방향성2022년도부터 스타트업 시장이 예측할 수 없는 상황으로 바뀌면서 오피지지 역시 전략을 수정할 수밖에 없었습니다. 그래서 2023년 오프라인 시무식에서 대표이사이신 상락님께서 앞으로의 오피지지의 새로운 방향성에 대해서 얘기를 해주셨습니다. 1년이라는 시간이 지나게 되었고 이번 All Hands Meeting에서 오피지지가 방향성대로 잘 성장을 하고 있는지 공유하는 시간을 가졌습니다. 이 역시 상락님이 발표를 진행해 주셨고, 회사 사정에 대한 QnA도 같이 진행을 해주셨고 솔직하게 조직 개편이나 채용계획 등에 대해서 말씀해 주셨습니다.• 새로운 시작을 알리는 2023 시무식 : 바로가기OP.GG는 타운홀 미팅인 옵지데이를 운영하고 있어 All Hands Meeting 때, 별도로 공유를 할 게 있을까? 하는 의문을 가지고 계신 분들도 있으실 것 같습니다. 옵지데이는 10초 발표, 1분 발표, 자유발표 등 구성원의 부담은 줄이면서 서로 소통하며 연결성을 강화할 수 있는 방향으로 계속 발전해가고 있습니다. 그런 의미에서 All Hands Meeting은 타운홀 미팅을 보완하기 위해서 운영하는 옵지데이의 연장선이라고 할 수 있습니다.• 다양한 공유와 소통으로 이루어지는 오피지지의 타운홀미팅, 옵지데이 : 바로가기그렇기에 평소에는 발표하기 쉽지 않은, 긴 호흡을 가지고 지켜봐야 하는 주제에 대해서 All Hands Meeting 때 발표하고 있습니다. 예를 들면 타 Cell 과의 커뮤니케이션 오류 해결 방법, 목표 달성, 셀 내부 문제 해결 방법 등 한 해를 돌아봐야지 답을 찾게 되는 주제 의 경우에는 All Hands Meeting 자리를 빌려서 발표를 할 수 있습니다.Platform Cell의 셀장님이신 재성님의 경우, 올해 셀장으로 일을 하시면서 느꼈던 점과 타 Cell과 업무를 하면서 겪었던 커뮤니케이션 문제 등에 대해서 공유해 주셨습니다. 유쾌하게 이야기를 풀어주셨지만 그 안에 내용은 많은 고민이 느껴졌습니다. 각 Cell의 회고를 통해서 각자 어떤 고민을 가지고 한 해를 보냈는지 알 수 있었던 시간이었습니다.• 소통을 위한 오피지지의 노력 : 바로가기한 해를 돌아보며한 해를 돌아보니, 정말 많은 동료들의 도움을 받았다는 사실을 깨닫게 되었습니다. 많은 Cell에서 발표 말미에 감사한 분들께 고마움을 표현해 주셨지만, 회사 차원에서도 감사함을 표현하고자 Award를 진행 하였습니다.Award는 총3개 주제로 진행을 하였고 첫 번째 주제는 가장 칭찬하고 싶거나 고마운 동료, 두 번째는 나에게 가장 많은 동기부여를 해준 동료, 3번째는 소속 셀 사람 외에 나와 가장 많이 소통을 한 동료를 선정하는것이었습니다.

안녕하세요. LINE+ Contents Service Engineering 조직에서 백엔드 개발을 하고 있는 김한솔, 문다정, 이현동, 조강훈입니다. 저희 조직에서는 그룹 구성원의 기술 성장을 돕고 향상된 능력을 적재적소에 활용할 수 있도록 Tech Group이라는 조직 내 스터디 그룹을 운영하고 있습니다. 이 글에서는 Tech Group을 운영하면서 다뤘던 여러 주제 중 하나인 Atlassian Jira의 랭킹 알고리즘, LexoRank를 소개하려고 합니다.LexoRank는 드래그 앤드 드롭(drag and drop) 정렬을 효과적으로 다룰 수 있는 정렬 알고리즘입니다. Atlassian에서 기존에 사용되던 다양한 드래그 앤드 드롭 정렬 방식의 단점을 보완해 개발했는데요. Atlassian에서는 Jira에서 LexoRank 알고리즘을 사용하는 방법과 기본적인 운영 메커니즘에 관한 정보만 제공할 뿐 별도로 라이브러리를 공개하지는 않았습니다.이 때문에 많은 사용자가 다양한 LexoRank 라이브러리를 개발해 공개했는데요. 대부분의 라이브러리가 운영 중인 서비스에 바로 적용하기에는 제약 사항이 많았습니다. 이에 저희는 다양한 서비스에 효과적으로 적용할 수 있는 LexoRank 라이브러리를 직접 개발했고, 이를 사내 임직원을 위한 사내용 오픈소스로 공개했습니다.본 글에서는 LexoRank가 무엇인지, 다른 랭킹 알고리즘과 비교해 어떤 장점이 있는지 설명하고, LexoRank 라이브러리를 개발하면서 마주한 여러 이슈와 그 해결 과정을 공유하고자 합니다. 이 글이 여러분께 유용한 인사이트 를 제공하기를 바라며, 그럼 LexoRank로 딥다이브해 보겠습니다!드래그 앤드 드롭 구현에 사용하는 기존 랭킹 알고리즘의 종류와 한계먼저 일반적으로 드래그 앤드 드롭 정렬을 구현하기 위해 사용하는 아래 세 가지 알고리즘이 어떻게 작동하는지 알아보고 각각 어떤 한계가 있는지 살펴보겠습니다.이해를 돕기 위해 할 일 목록(to-do list)에서 항목을 드래그 앤드 드롭으로 정렬하는 예시를 준비했습니다.첫 번째로 가장 고전적인 방식인 Integer 방식입니다. 이 방식은 아래 그림과 같이 각 항목의 순서를 연속된 정수로 저장하는 방법입니다.이 방식에는 어떤 한계가 있을까요? 예를 들어, 아래 그림과 같이 맨 아래에 위치한 Todo-E의 순서를 Todo-A와 Todo-B 사이로 변경하고 싶다고 가정해 봅시다. 이 경우 Todo-E의 순위값(order)이 에서 로 변경되며, 이후 기존 순서를 유지하기 위해 하위 항목들인 Todo-B, Todo-C, Todo-D의 순위값을 수정해야 하고, 수정하는 동안 시스템은 중단됩니다. 이런 방식은 데이터가 많은 경우 시스템의 성능 저하를 일으킬 수 있으며, 동시에 여러 사용자가 수정을 시도하면 빈번하게 충돌이 발생하기도 합니다.이 방식은 정 수 방식과 유사하지만, 각 항목 사이에 충분한 간격을 두고 순위값을 할당해서 새 항목을 중간에 삽입할 때 Todo-E외에 다른 항목의 순위값은 변경하지 않아도 됩니다. 예를 들어, Todo-E를

글. 소피(김경희) / UX Designer부제: 여기어때 웹, 새집 짓고 이사 가기까지여기어때는 앱뿐만 아니라 웹 서비스도 제공하고 있다는 사실 알고 계셨나요? 얼마 전까지 여기어때 웹은 이런 모습이었죠.리뉴얼 전 여기어때 웹기존 여기어때 웹은 사실상 오랫동안 개선이 되지 않아 앱의 경험과 차이가 큰 상태였고 기술적으로, 사용자 경험 측면에도 많은 개선이 필요했어요.리뉴얼된 여기어때 웹그리고 2023년 말, 새로운 웹으로 거듭나게 되었답니다.작년 초, 많은 도전과 기회를 안고 시작하여 약 80명의 실무자들이 1년 정도의 시간을 들여서 새로운 여기어때 웹을 론칭했어요.집을 올 리모델링 하듯 여기어때 웹의 완전한 변화를 만들게 되었어요. 이 프로젝트는 여러 명의 디자이너가 함께 작업하고 아이디어를 내며 만들어 나갔는데요. 프로젝트의 규모가 큰 만큼 디자인 일관성을 유지하는 것이 더 중요해졌어요. 여러 디자이너가 참여하고 다양한 아이디어가 발산되는 상황에서 어떻게 하면 프로젝트 전반에 걸쳐 일관성 있는 디자인을 유지할 수 있을까요?이번 글에서는 웹 개편처럼 규모가 큰 프로젝트에서 디자인 일관성을 유지하기 위해 시도한 방법에 대해 이야기해보려 해요.디자인 일관성을 위한 출발점프로젝트가 시작되고 모든 디자이너, PO가 모여 워크숍을 열어 프로젝트를 종합적으로 이해하고, 각 화면별 구성 요소와 플로우에 대한 공통된 이해를 형성했어요. 초기 워크숍은 프로젝트의 목표를 같은 선상에서 이해하고 하나의 프로덕트를 만들기 위해서 가장 중요한 단계예요. 공통된 이해가 바탕이 되어야지 전체의 일관성을 맞출 수 있기 때문이죠.그리고 여기어때 UX원칙을 기반으로 웹 개편 프로젝트의 목적에 맞춰 디자인 원칙을 Simplicity, Scalability, Continuity로 구체화하고 이를 함께 공유했어요. 이러한 디자인 원칙은 디자인 일관성을 유지하는 데 중추적인 역할을 한 것 같아요.여기어때 웹 디자인 원칙반응형으로 디자인하기모바일 기기부터 데스크톱까지 다양한 화면 크기에서 사용자들이 일관된 경험을 느낄 수 있도록 반응형으로 디자인을 진행했어요. 반응형 디자인은 그리드 시스템을 정의하고 브레이크 포인트를 설정하는 것이 중요해요. 일관된 그리드 패턴을 유지하여 디자인함으로써 사용자가 다양한 페이지를 탐색하더라도 익숙한 레이아웃이 유지되도록 하여 일관된 느낌을 줄 수 있어요. 메뉴의 구조별로 공통적인 디자인 패턴이 몇 가지로 정리가 되었고 동일한 패턴을 가진 페이지들은 같은 레이아웃과 규칙으로 적용될 수 있도록 했어요.여기어때 웹 디자인 시스템 구축하기여기어때 웹 디자인 시스템여러 디자이너 간의 협업을 용이하게 하기 위해 통합된 디자인 시스템을 도입했는데요. 여기어때에는 이미 YDS(여기어때 디자인 시스템)가 존재하고 있었지만 모바일 기반으로 정리되어 있어서 웹의 환경과 사용성을 고려한 보완이 필요했어요. 색상 팔레트, 텍스트 스타일, 아이콘 등과 같은 기본적인 파운데이션 요소는 YDS와 일관성을 맞추되 데스크톱 환경까지 고려했을 때 크기 조정 또는 사용성 보완이

기업은 영리를 목적으로 물품이나 서비스의 생산, 판매 활동을 지속적으로 하며 수익을 창출하는 집단이다. 그런 기업이 한 번의 수익이 아닌 지속적인 이윤 창출을 해가려면 혁신해야 한다. 여러 기업들과 경쟁하며 성장을 하는 과정에 지향점은 고객 가치 창출이다. 다른 기업이 주지 못하는 새로운 고객 가치를 정의해, 어떤 상품과 무슨 서비스로 제공할 것인지를 정하고 이를 추진하기 위한 방법을 찾는 과정이 바로 전략이다. 그렇게 고객 가치를 찾고 이를 구현하는 과정을 위한 방법론을 디자인 씽킹이라고 하며, 그렇게 고객 중심의 사고로 제품 디자인을 할 때 반드시 고려해야 하는 것이 온전한 고객의 모든 경험들을 아울러야 하고 이를 통합 경험(Total eXperience)라고 한다. 사업의 혁신 과정에 가장 중요한 방법론인 디자인 씽킹과 TX에 대해 자세하게 살펴본다.고객 중심의 사고, 디자인 씽킹이미 디지털 트랜스포메이션은 기업의 사업 혁신에 중요한 수단이 된 지 오래다. 하지만, 결국 기술은 도구일 뿐 핵심은 기술로 고객 경험을 어떻게 높여줄 것이냐 하는 점이다. 그런 측면에서 결국 중요한 것은 고객을 잘 이해하고 고객에게 어떤 경험을 어떤 기술로 제공할지를 디자인하는 역량이다. 이것을 디자인 씽킹이라고 한다. 사실 그런 디자인 씽킹으로 우버, 에어비앤비, 카카오뱅크, 배달의민족, 마켓컬리, 쿠팡 등의 서비스가 만들어지고 그것이 우리에게 새로운 고객 경험을 제공하고 있는 것이다. 그런 고객 가치의 실현 덕분에 이들 기업은 사업 혁신을 꾀할 수 있었다. 마켓컬리의 새벽배송, 쿠팡의 로켓배송 그리고 카카오뱅크의 빠른 송금과 간편한 인증, 우버와 배달의민족의 간편결제 등이 고객의 입장에서 무엇이 서비스를 사용하는 데 있어 최대의 pain points이고, 이를 해결하기 위한 솔루션이 무엇인지를 도출해, 테스트를 하고 개선해서 스마트폰 앱으로 구현해 냈기 때문에 고객의 문제가 해결되고 보다 나은 사용자 경험을 제공할 수 있었다. 이렇게 디자인 씽킹은 문제 해결과 혁신의 주요 도구로, 사용자의 요구와 경험을 근본적으로 이해하는 것에서 시작한다. 이 접근법은 고객의 시각에서 문제를 바라보고, 이를 해결하기 위한 창의적인 솔루션을 개발하는 데 중점을 둔다. 디자인 씽킹은 다음과 같은 몇 가지 핵심 단계로 구성된다.① 공감 : 사용자의 필요와 문제를 깊이 이해하기 위해 공감하는 단계. 사용자 인터뷰, 관찰, 설문조사 등을 통해 고객의 진짜 필요와 고민을 파악한다. ② 문제 정의 : 고객의 요구와 문제점을 명확하게 정의하는 단계. 여기서는 문제를 재정의하고, 핵심 문제에 집중한다. ③ 아이디어 도출 : 창의적인 해결책을 모색하는 단계. 브레인스토밍과 같은 기법을 사용하여 다양한 아이디어를 생성한다. ④ 프로토타입 제작 : 아이디어를 구체적인 형태로 만드는 단계. 신속하게 프로토타입을 제작하여 사용자의 피드백을 받는다. ⑤ 테스트 : 프로토타입을 사용자에게 테스트하고 피드백을 받는 단계. 이를 통해 아이디어를 지속적으로 개선한다. 이러한 단계를 통해 기업은 고객의