안녕하세요. 무신사에서 주문을 담당하는 백엔드 엔지니어 박준호입니다.이번 글에서는 무신사의 주문 시스템이 수많은 변화에 대응하며 대규모 트래픽과 이벤트 시즌에도 안정적인 서비스를 유지하기 위해 어떤 방식으로 변화해왔는지, 그 여정을 공유하고자 합니다.왜 개선이 필요한가?무신사와 같은 커머스 플랫폼에서 주문 시스템은 핵심적인 역할을 담당합니다. 주문 처리 속도와 안정성은 고객 경험에 직접적인 영향을 미치며, 주문 데이터를 신뢰할 수 있어야 모든 비즈니스가 원활하게 운영될 수 있기 때문입니다.무신사는 블랙프라이데이(이하 무진장) 시즌마다 최고 매출과 주문 수를 경신하며 놀라운 성장세를 이어가고 있습니다. 이처럼 가파른 성장을 뒷받침하기 위해 주문 시스템도 지속적인 발전이 필요합니다.하지만, 주문 도메인은 복잡한 비즈니스 로직을 포함하기 때문에 보수적으로 개발되는 면이 있습니다. 버그나 장애가 발생할 경우 장애 정도나 발생 시간과 관계없이 치명적인 결과로 이어질 수 있기 때문입니다.예를 들어 무신사의 경우 2023년 겨울 무진장 기준으로 시간당 평균 주문액이 10억 원 이상으로, 15분의 장애를 가정했을 때 약 2억 5천만 원 이상의 손실이 발생한다는 계산을 할 수 있습니다.따라서 주문 도메인을 다룰 때는 안정성과 신뢰성을 유지하면서도 변화와 개선을 추구하는 것이 매우 중요한 과제이고, 이를 위해 강한 책임감을 가지고 시스템을 관리하는 자세가 필요합니다.무신사 2.0 주문서여정의 시작, 모놀리식 아키텍처와 그 한계초창기 무신사 스토어는 모놀리식 아키텍처 (Monolithic Architecture) 로 구성되어 있었습니다. 하나의 데이터베이스를 공유하며 매거진을 제외한 모든 도메인이 하나의 리포지토리로 관리되어 있었습니다.주문 외에도 결제, 재고, 상품, 회원, 쿠폰, 적립금 등 모든 주요 도메인이 하나의 어플리케이션 내에 통합되어 있었기 때문에 매우 복잡하고 유지보수하기 어려운 구조였습니다. 특히 주문 시스템은 스파게티 코드처럼 복잡하게 얽혀 있었고, 콜 스택이 지나치게 깊어 분석이 어려웠습니다. 이러한 복잡성은 새로운 기능 추가나 버그 수정 시 높은 리스크를 동반하게 만들었습니다.모놀리식 아키텍처 무신사 스토어이 시스템은 DB 의존도가 높은 구조로 모든 요청이 데이터베이스를 통해 처리되었기 때문에 성능 문제가 빈번히 발생했습니다. 특히 무진장과 같은 대규모 이벤트 시 요청이 데이터베이스로 몰리면서 사이트가 다운되는 일이 잦았는데, 서버 다운타임과 성능 저하는 매출에 직접적인 영향을 미치는 민감한 문제이므로 이벤트 시즌에는 안정적인 시스템 운영이 필수적이었습니다.매년 서버를 증설하고 시스템을 튜닝했지만, 가파르게 증가하는 트래픽을 따라잡지 못해 한계에 도달하기 일쑤였습니다. 최적화되지 않은 코드들이 성능적 한계를 보이면서 근본적인 아키텍처 변화의 필요성이 대두되었습니다.변화의 시작, 리팩토링성능 개선과 유지보수의 용이성, 그리고 개발 생산성 향상은 매우 중요한 개선의 시작이였습니다.이를 해결하기 위해 리팩토링을 시작했고, 첫 단계로 시스템의

✍️요약우리 앞에 주어진 모든 기술과 환경은 낯선 처음이 있었습니다. 웹과 인터넷이 태동하고, 모바일 혁명과 디지털 전환의 시대를 거쳐 AI가 열어가는 새로운 세상까지, IT 역사의 흐름을 직접 겪어온 기술 리더들이 티타임을 가졌습니다. 예전의 변화 앞에서 했던 도전, 오늘의 변화 앞에서 또다시 맞이하는 고민들을 공유합니다.PHP의 주역, 웹 개발의 선구자이며, 현재 구글 클라우드 데이터베이스를 총괄하는 🔵 앤디 구트만스(Andi Gutmans, 이하 Andi)와, 카카오의 기술을 총괄하는 🟡 정규돈 CTO(이하 GD)가 7월 30일, 카카오의 판교아지트에서 티타임을 가졌습니다.구글 클라우드의 모니카 굽타(Monica Gupta, 이하 Monica) 시니어 디렉터와 수바시 구아다드(Subhash Guaddad, 이하 Subhash) 디렉터, 카카오의 데이터플랫폼 조직을 이끄는 오민석 리더(이하 Vincent) 등 기술 리더들이 함께했어요.IT 기술이 태동하고 변화했던 시대를 거쳐온 리더들의 대화가, 또다시 변화 앞에 선 개발자 여러분께 의미 있는 메시지가 되면 좋겠습니다.Era of Web and internet: 역사의 시작웹과 인터넷이 등장한 1990년대에 두 분은 무엇을 하고 있었나요?그 시기의 고민과 가장 도전적인 과제는 무엇이었는지 들려주세요.🔵 Andi:1990년대면 저는 대학에서 컴퓨터공학을 공부하고 있었는데요, 공부하는 것보다 코딩을 더 좋아했습니다. 그래서 친구와 함께 수업을 듣는 대신 프로젝트를 하기로 했습니다. 당시로서는 꽤 선진적이었던, 쇼핑카트 웹사이트를 만드는 프로젝트였고, 지도교수님이 있었어요. 친구 Zeev가 hosting provider를 작업하면서, PHP/FI를 알게 되었고, 우리는 그 언어를 사용해서 쇼핑카트 웹사이트를 만들기로 했어요. 한 시간쯤 개발하다가 ‘우리가 이 언어를 더 잘 만들 수 있겠다’고 생각했어요. 그때 저희는 대학에서 막 컴파일러 수업을 이수한 상태였거든요. 그래서 쇼핑카트 프로젝트는 잠시 치워두고 이 언어를 다시 만들기로 했어요. 그렇게 PHP3가 탄생했습니다.PHP3를 들고 지도교수님께 가서, 우리가 새 언어를 만들었으니 이것을 새 프로젝트로 받아주실지 물어봤는데 거절하셨어요. 그래서 저희는 컴파일러 수업을 하셨던 교수님께 갔어요. 그 교수님은 이스라엘 IBM research의 리더이기도 했는데 흔쾌히 프로젝트를 맡아주기로 하셨어요. 그래서 저희는 PHP3를 들고 PHP/FI를 사용하는 사람들에게 가서, 우리가 새 버전을 만들었으니 여기로 옮겨오는 것이 어떨지 제안했고, 작은 커뮤니티였지만 사람들이 PHP3를 써주기 시작했어요. 그렇게 일 년 반 만에 약 4만 개의 웹사이트가 150만 개로 증가했고, 정말 재미있었어요. 그리고 잘 아시듯이 PHP3를 오픈소스로 공개했어요.그런데 PHP3를 오픈소스로 런칭하고 보니 여전히 ‘이것보다도 더 잘할 수 있겠다’는 생각이 들었어요. 그래서 저희는 바로 PHP4를 만들기 시작합니다. PHP4는 PHP3와 달리, 엔진을 분리하기로 했습니다.

엔지니어들이 직접 준비한 밋업, 그 뒷이야기안녕하세요. 무신사 SRE팀의 안다혜, 이병우입니다.무신사 테크에서는 매달 1회, 구성원 간에 정기적인 소통을 위한 모임인 엔지니어링 밋업을 정기적으로 진행합니다. 밋업의 주제는 누구나 제안할 수 있으며, 엔지니어링 직군 구성원들에게 꼭 알려야 하는 공지 사항들을 공유하고 각 팀의 성과나 밋업 주제로 발의된 계획에 대한 진행 상황을 나누는 자리가 엔지니어링 밋업입니다.무신사 엔지니어링 조직의 2023년을 결산하며, 각 조직에서 어떤 일들을 했는지 공유하며 축하하는 자리를 약 1달간에 걸쳐, 엔지니어들끼리 만들어갔던 내용을 공유하고자 합니다.AWS 사용자 모임 — 성수 소모임무신사 SRE팀원 중 일부는 AWS 한국 사용자 소모임인 성수 지역 모임을 운영하며 기술 주제에 대해 발표를 하고 논의할 수 있는 자리를 만들어 다른 회사의 개발자 및 학생들과 기술적인 교류를 나누어왔습니다. 평소 소모임을 꾸준히 운영해 온 SRE 팀원들에게 밋업 운영에 대한 제안을 주셨고 무신사 엔지니어링 조직이 2023년간 한 일들과 성과를 공유할 수 있는 자리를 만들어 보기로 했습니다.총 4번의 회의를 거쳐서 밋업 구성에 대한 내용을 점차 발전시켜 나갔습니다. 이번 밋업의 목적이 무신사 테크의 각 팀이 2023년의 성과를 공유하며 축하하는 자리인 만큼, 먼저 밋업에서 관련 내용을 발표할 발표자가 필요했습니다. 먼저 무신사 내의 모든 엔지니어를 대상으로 공개적으로 모집했습니다.그리고 밋업을 준비하는 운영진들이 평소 알고 있는 성과를 낸 팀들을 대상으로도 섭외에 들어갔습니다.결과적으로 14개의 발표 주제가 모였고, 아쉽게도 엔지니어링 밋업의 시간이 한정되어 있기 때문에 발표 주제의 선별이 필요했습니다. 주제 선정 과정에서 오랜 시간을 고민하고 토론하여 합의한 기준은 다음과 같습니다.내용 면에서 기술적으로 의미 있는 성취인가무신사 테크가 나아갈 방향에 부합하는가발표 기회가 각 팀에게 균등하게 분배되었는가아쉽게도 이번에 선정되지 않은 발표자분들에게는 다음 기술 발표 세션에서 발표를 부탁드렸습니다.밋업에서 발표만큼 중요한 요소는 ‘장소’입니다. 장소에 따라서 모임의 분위기, 참여자의 집중 가능 여부, 만족도 등이 완전히 달라지기 때문입니다.​​최근 E1 건물이 신설되기도 했고, 영상·음향 등의 설비가 더 좋아서 이번 밋업은 E1의 라운지에서 진행하기로 하였습니다.밋업 시간과 참석 인원, 그리고 참여자에게 제공하는 간식은 밋업 만족도에 영향을 미치는 중요한 요소입니다. 사소한 부분이지만 이런 부분도 몇 차례의 회의를 거쳐 선정한 뒤에 밋업 일정을 공지하였습니다.오프라인 약 50명, 온라인 약 150명 참석하여 총 200 명 내외로 참석해주셨습니다. 보통 밋업을 진행하면 오프라인 참석 인원 중 노쇼가 있기 마련인데, 신청하신 인원과 참석자 수가 같았다는 점이 밋업을 준비하는 입장에서 뿌듯한 결과였습니다.발표 준비 과정에서는 1차 자료 피드백 & 2차로 리허설 일정을 통해서 발표의 구성과 내용에 대하여 피드백을 드렸습니다.처음 내용을

[기술블로그] 쿼리(Query) 바인딩 자동 추출 기능 구현 회고 - PDO(PHP Data Objects)는 어떻게 쿼리를 파싱하고 있을까? [기술블로그] 쿼리(Query) 바인딩 자동 추출 기능 구현 회고 - PDO(PHP Data Objects)는 어떻게 쿼리를 파싱하고 있을까? 안녕하세요. 엔터플 백엔드 개발자 Hamill입니다. 싱크트리 4.0 은 눈에 띄는 성능 개선이 있었는데요(자세한 내용은 기술블로그 집필진 'Wally'님의 싱크트리 4.0 업데이트를 위한 <런타임 개선 과정> 회고 포스팅을 참고해 주세요😄), 그 이후에도 사용자에게 개선된 기능을 제공하기 위해 노력하고 있습니다. 오늘은 작년 5월에 릴리스된 SyncTree 4.0.1 버전에 포함되었던 '쿼리 기능 고도화' 중, '바인딩 자동 추출 기능 구현 과정'을 되돌아보려고 합니다. 추가로 PHP 내부 코드, 그중에서도 PHP 개발자라면 DB 데이터를 조작할 때 한 번쯤은 직간접적으로 사용해 보았을 'PDO'를 함께 살펴볼게요. 1️⃣ 본 글은 작년 12월, 제가 'ModernPHP 유저 그룹'에서 발표한 내용을 포함하고 있습니다.😊 2️⃣ 싱크트리 '쿼리 바인딩 추출 기능' 설명을 위해 아래 내용들도 함께 다루고 있습니다. 글을 이해하는데 어려움이 없을 정도로만 다루고 있으니 추가 정보가 필요한 분들은 다른 자료를 함께 참조해 보세요! 싱크트리는 원하는 데이터베이스와 쿼리를 관리하고 블록으로 사용할 수 있는 'Storage'와 'Query'라는 강력한 기능을 제공합니다. 자주 사용하는 쿼리를 저장/관리할 수 있는 '쿼리' 메뉴는 사용자가 편하게 사용하는 기능 중 하나였는데요, 다만, 바인딩을 수동으로 지정해 줘야 한다는 부분이 아쉬웠습니다. 만약 바인딩 정보가 많아지면 입력한 쿼리를 보면서 하나씩 블록을 만들어야 했고 바인딩이 많으면 꽤 번거로울 수 있는 작업이기 때문입니다. 그래서 사용자가 쿼리에 바인딩을 지정하면 블록 사용 시 자동으로 바인딩 정보를 추출하여 블록이 생성되는 기능을 제공하기로 했습니다. 사용자가 아래와 같은 쿼리를 저장했다고 가정한다면, 바인딩이 2개이므로, 최종적으로는 :email 와 :name 2개를 바인딩 할 수 있는 블록이 자동으로 생성되어야 합니다. 최종 형태는 위와 같이 쿼리 블록으로 쿼리 선택 시, 자동으로 바인딩 정보를 추출해서 블록이 생성되는 것입니다. 그럼, 사용자가 입력한 쿼리에서 어떻게 바인딩 정보를 추출하면 될까요? 아이디어 자체는 단순해 보입니다. 정해진 바인딩 규칙으로 사용자가 쿼리를 입력하면, 해당 쿼리를 파싱 하여 필요한 부분만 추출하면 될 것입니다. 고려해야 할 사항은 어떤 것들이 있을까요? 우선 문자열에 포함된 바인딩 규칙 문자열은 무시해야 합니다. 이 경우, 문자열에 포함된 바인딩 규칙 :변수명 또는 ? 와 사용자가 바인딩으로 사용하기 위해 지정한 바인딩 정보를 어떻게 구분할 수 있을까요? 가장 먼저 나온 의견은 이것이었습니다. 문자열은 우선 다 제거하고 남아있는 쿼리에서 바인딩 규칙을 추출하면 되지 않을까요?