<div id="readability-page-1" class="page"><article><div><div><div><div aria-hidden="false"><a rel="noopener follow" href="/@hangjun.cho_49348?source=post_page---byline--e689d7d932b5--------------------------------"><div><p><img alt="Hangjun Cho" src="https://miro.medium.com/v2/da:true/resize:fill:88:88/0*FaME4tGv8Ypt_2vN" width="44" height="44" loading="lazy" data-testid="authorPhoto"></p></div></a></div><div aria-hidden="false"><a href="https://medium.com/musinsa-tech?source=post_page---byline--e689d7d932b5--------------------------------" rel="noopener follow"><div><p><img alt="MUSINSA tech" src="https://miro.medium.com/v2/resize:fill:48:48/1*Qs-0adxK8doDYyzZXMXkmg.png" width="24" height="24" loading="lazy" data-testid="publicationPhoto"></p></div></a></div></div><p id="dece">안녕하세요, 무신사 캠페인개발팀에서 무신사의 최대 이벤트인 무진장과 여러 이벤트들을 담당하고 있는 조항준입니다. 이번 글에서는 오래된 레거시 시스템 중 하나였던 쿠폰 시스템을 개선하는 과정에서의 실패와 성공 사례를 공유하고자 합니다.</p></div><div><p id="5860"><strong>왜 개선이 필요한가?</strong></p><p id="e175">과거에는 사용자가 쿠폰을 사용할 때만 자신이 보유한 쿠폰을 확인하는 구조였습니다. 그러나 Musinsa 2.0이 도입되면서, Musinsa에서 가장 트래픽이 높은 페이지인 상품 상세 페이지에서 <strong>최적의 쿠폰을 실시간으로 제공</strong>해야 하는 요구가 생겼습니다.</p><p id="4f53">Musinsa의 빠른 성장과 함께 트래픽이 폭발적으로 증가했고, 단순했던 쿠폰 쿼리가 점점 복잡해져 결국 600줄에 달하는 거대한 코드로 변모했습니다. 이러한 거대한 쿼리는 더 이상 높은 트래픽을 감당하기 어려웠고, 계속해서 유지하기 위해 막대한 인프라 비용을 지불해야 한다는 문제가 있었습니다.</p><p id="10cb">지금까지 거대해지면서도 버티고 있었던 개인적인 생각은<br>막대한 인프라 비용과 오래 함께한 팀원들의 노력으로 유지 되고 있었다고 생각합니다.</p></div><div><p id="bd2d"><strong>어떻게 개선하기로 했나?</strong></p><p id="ef7a"><strong>1. 쿼리 분할</strong></p><ul><li id="3f3d">단일책임원칙은 객체지향 프로그래밍의 SOLID 원칙 중 하나로, 각 클래스나 함수가 하나의 책임만 가져야 한다는 원칙입니다. 각각의 기능이 고유한 책임을 가질 때 코드의 재사용성과 유지보수성이 높아지는 것이 핵심입니다.</li><li id="c5dc">긴 쿼리를 하나의 책임을 가진 여러 개의 짧은 쿼리로 분리하는 작업을 단일책임원칙으로 비유할 수 있습니다. 즉, 각 쿼리는 특정한 데이터나 기능에만 집중하도록 설계하여 효율적으로 필요한 데이터만을 반환할 수 있게 만드는 것입니다.</li><li id="1846">위와 같은 이유로 600줄짜리 거대한 쿼리를 여러개의 짧은 쿼리로 쪼개어 자신만의 데이터를 가져오고 그 데이터를 조합하여 <strong>Application에서 계산</strong>하도록 변경했습니다. 이를 통해 쿼리의 복잡성을 줄이고, 처리 속도를 크게 개선할 수 있었습니다.</li></ul><p id="a08b"><strong>2. 캐싱 처리</strong></p><ul><li id="9449"><strong>캐싱을 통한 조회 최적화 모델 구성:</strong> 캐싱을 적극적으로 활용해 변화가 많치않고 자주 요청되는 데이터는 캐시된 결과를 반환하도록 최적화, 데이터베이스에는 변화가 적은 데이터만 접근하도록 하여, 데이터베이스 부하를 줄이고 응답 속도를 높히는데 집중을 했습니다.</li></ul><p id="66ea"><strong>3. Application 자원 활용</strong></p><ul><li id="5e77"><strong>데이터베이스의 책임</strong>은 주로 데이터를 안전하게 저장하고, 빠르고 효율적으로 조회하는 데 집중</li><li id="f52c"><strong>애플리케이션의 책임</strong>은 비즈니스 로직과 관련된 연산과 데이터 조작을 담당하며, 데이터베이스로부터 데이터를 받아 필요한 연산을 수행하는 역할</li><li id="4fec">각 자원의 특성을 생각해서 데이터베이스는 안전하고 빠르게 데이터를 주는데 집중하고 Application은 연산을 집중적으로 담당해서 처리 하였습니다.</li><li id="926f">Application 자원의 사용은 비용이 더 저렴하고, 운영 측면에서도 더 효율적이라는 장점이 있었습니다.</li></ul></div><div><div><p id="1220"><strong>실패 사례</strong></p><p id="51b6"><strong>첫 번째 시도: S3</strong></p><ul><li id="1803">모든 쿠폰 데이터를 배치로 생성해 S3에 업로드</li><li id="7d7d">문제점: 다운로드 지연과 네트워크 비용 증가 <br>(1480개 쿠폰 데이터 용량: 5MB)</li></ul><p id="6613"><strong>두 번째 시도: Memcached</strong></p><ul><li id="d62c">Memcached에 쿠폰 데이터를 저장</li><li id="054a">문제점: 단일 Key 최대 용량 1MB의 한계에 부딪힘</li></ul><p id="27c1"><strong>세 번째 시도: Memcached 분산 저장</strong></p><ul><li id="1e64">데이터를 분산해 저장한 후 조합</li><li id="4e2b">문제점: 조합 과정의 시간 소요 증가 및 호출 횟수 증가</li></ul><p id="b648"><strong>최종 개선 방향: 최소한의 DB 사용</strong></p><p id="dca6"><strong>1. 쿼리 구성 요소 분석</strong></p><ul><li id="b148"><strong>쿼리 구성 요소</strong>: JOIN, SubQuery, UNION, GROUP BY, ORDER BY, CASE등<br>쿼리를 짜면서 볼수있는 모든것의 집합</li><li id="f50a"><strong>문제점</strong>: 쿼리의 복잡성과 무거운 구조가 성능 저하와 유지보수 비용을 증가</li></ul><figure></figure><p id="6fde"><strong>2. 개선 방안</strong></p><ul><li id="26f5"><strong>쿼리 분리</strong>: 가벼운 쿼리로 나누어 개별 성능 향상.</li><li id="1f2b"><strong>캐싱 처리</strong>: 캐싱할 수 있는 데이터는 최대한 캐싱.</li><li id="b7d9"><strong>로직 처리</strong>: 특정 조건은 쿼리가 아닌 로직으로 처리해 복잡성 경량화.</li></ul><p id="0150"><strong>3. 구체적 개선 방법</strong></p><ul><li id="db1a"><strong>사용 가능한 쿠폰 필터링 및 캐싱</strong>: 쿠폰 유형으로 필터링한 후 캐싱하여 효율성을 높임</li><li id="9652"><strong>회원 등급 캐싱</strong>: 개별 회원의 등급 정보를 캐싱하여 조회 성능을 향상</li><li id="c2d9"><strong>쿠폰 조건 로직 처리</strong>: 온라인 쿠폰 및 등급 쿠폰의 다양한 조건을 로직으로 처리하여 복잡성을 경감</li><li id="e75b"><strong>회원 보유 쿠폰 처리</strong>: 회원이 보유한 쿠폰을 실시간으로 조회하고 로직을 통해 필터링</li></ul><p id="4c05"><strong>4. 결과</strong></p></div><div><ul><li id="6d71">평균 Latency가 110ms → 83ms 로 응답속도 약 24.55% 향상</li><li id="8651">최초 진입시에는 약 150ms로 기존로직 약 110ms로 기존 보다 조금 느려졌지만 이후 캐싱을 통해서 서비스하면서 속도가 향상됨.</li><li id="ff88">쿼리를 단순화시켜서 여러번 수행시키면서 기존 사용가능한 쿠폰의 데이터를 구하는 쿼리가 60ms걸렸지만 개선 후 20ms로 쿼리가 가벼워짐</li><li id="4322">동일한 로직을 수행시 기존 DB사용량의 변화<br>- 개선 전 로직 DB 사용률 72.5% <br>- 개선 후 최초 호출시 49.5%<br>- 캐싱이 된 후에는 13.6%</li></ul><p id="eaf0">쿼리를 분할하고 Application 로직을 사용하면서 데이터베이스 부하는 줄어들고, 인프라 비용 역시 절감할 수 있었습니다. 이 과정을 통해 무거웠던 600줄짜리 레거시 쿼리와의 아름다운 이별이 가능했습니다.</p></div></div><div><p id="a675"><strong>마무리</strong></p><p id="1560">이번 개선 작업을 통해 쿼리의 속도가 빠르다고 해서 그 복잡성이 괜찮다고 여기는 것은 잘못된 생각이라는 것을 깨달았습니다. 단순히 성능만을 추구하는 것이 아닌, 더 효율적이고 관리하기 쉬운(유지보수가 용이한) 대안을 찾아야 한다는 중요한 교훈을 얻었습니다.</p><p id="09d1">이번 개선에서의 경험은 다양한 접근 방식이 존재한다는 것을 느끼게 해주었고, 복잡한 쿼리를 단순화하는 것이 기술적 부채를 줄이고 향후 유지보수를 용이하게 한다는 것을 느끼게 해준 개선 작업이었습니다.</p><p id="b0c7">앞으로도 다양한 방법과 유지보수가 용이하도록 지속적인 개선을 통해 더 나은 시스템을 구축해 나갈 것입니다.</p></div><div><h2 id="7e8a">MUSINSA CAREER</h2><p id="3fe0">함께할 동료를 찾습니다.</p><p id="af5a">무신사의 폭발적인 성장에는 매년 말 진행 했던 무진장(블랙프라이데이)가 큰 역할을 했습니다. 해당 이벤트로 매출 부스팅 및 신규 유저를 확보 했고, 이렇게 증가된 매출과 유저로 인해 매년 높은 매출 성장을 이뤘으며, 지금의 무신사가 만들어졌습니다. 캠페인개발팀은 무신사의 핵심 행사인 무진장(블랙프라이데이) 캠페인을 주도적으로 개발 및 운영지원 하고 있습니다. 그 외에도 무신사에서 전개 하는 다양한 캠페인 및 이벤트를 적극적으로 지원하고 있습니다. 우리는 팀원 각자 전문성과 열정을 바탕으로 다양한 캠페인을 성공적으로 오픈하고 있으며, 파트너와 함께 고민하며 성장하기 위해 최선을 다하고 있습니다.</p><p id="c898"><em>🚀 </em><a href="https://corp.musinsa.com/ko/career/" rel="noopener ugc nofollow" target="_blank"><em>팀 무신사 채용 페이지</em></a><em> (무신사/29CM 전체 포지션 확인이 가능해요)</em></p><p id="34e3"><em>🚀 </em><a href="https://kr.linkedin.com/company/musinsacom" rel="noopener ugc nofollow" target="_blank"><em>팀 무신사 테크 소식을 받아보는 링크드인</em></a></p><p id="5e2d"><em>🚀 </em><a href="https://medium.com/musinsa-tech" rel="noopener"><em>무신사 테크 블로그</em></a></p><p id="ab9c"><em>🚀 </em><a href="https://medium.com/29cm" rel="noopener"><em>29CM 테크 블로그</em></a></p><p id="ce61"><em>🚀 </em><a href="https://www.youtube.com/@MUSINSATECH" rel="noopener ugc nofollow" target="_blank"><em>무신사 테크 유튜브 채널</em></a></p><p id="ce82"><em>채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요!</em></p></div></div></article></div>

MUSINSA tech - Medium

안녕하세요, 무신사 캠페인개발팀에서 무신사의 최대 이벤트인 무진장과 여러 이벤트들을 담당하고 있는 조항준입니다. 이번 글에서는 오래된 레거시 시스템 중 하나였던 쿠폰 시스템을 개선하는 과정에서의 실패와 성공 사례를 공유하고자 합니다.
왜 개선이 필요한가?
과거에는 사용자가 쿠폰을 사용할 때만 자신이 보유한 쿠폰을 확인하는 구조였습니다. 그러나 Musinsa 2.0이 도입되면서, Musinsa에서 가장 트래픽이 높은 페이지인 상품 상세 페이지에서 최적의 쿠폰을 실시간으로 제공해야 하는 요구가 생겼습니다.
Musinsa의 빠른 성장과 함께 트래픽이 폭발적으로 증가했고, 단순했던 쿠폰 쿼리가 점점 복잡해져 결국 600줄에 달하는 거대한 코드로 변모했습니다. 이러한 거대한 쿼리는 더 이상 높은 트래픽을 감당하기 어려웠고, 계속해서 유지하기 위해 막대한 인프라 비용을 지불해야 한다는 문제가 있었습니다.
지금까지 거대해지면서도 버티고 있었던 개인적인 생각은
막대한 인프라 비용과 오래 함께한 팀원들의 노력으로 유지 되고 있었다고 생각합니다.
어떻게 개선하기로 했나?
1. 쿼리 분할
단일책임원칙은 객체지향 프로그래밍의 SOLID 원칙 중 하나로, 각 클래스나 함수가 하나의 책임만 가져야 한다는 원칙입니다. 각각의 기능이 고유한 책임을 가질 때 코드의 재사용성과 유지보수성이 높아지는 것이 핵심입니다.
긴 쿼리를 하나의 책임을 가진 여러 개의 짧은 쿼리로 분리하는 작업을 단일책임원칙으로 비유할 수 있습니다. 즉, 각 쿼리는 특정한 데이터나 기능에만 집중하도록 설계하여 효율적으로 필요한 데이터만을 반환할 수 있게 만드는 것입니다.
위와 같은 이유로 600줄짜리 거대한 쿼리를 여러개의 짧은 쿼리로 쪼개어 자신만의 데이터를 가져오고 그 데이터를 조합하여 Application에서 계산하도록 변경했습니다. 이를 통해 쿼리의 복잡성을 줄이고, 처리 속도를 크게 개선할 수 있었습니다.
2. 캐싱 처리
캐싱을 통한 조회 최적화 모델 구성: 캐싱을 적극적으로 활용해 변화가 많치않고 자주 요청되는 데이터는 캐시된 결과를 반환하도록 최적화, 데이터베이스에는 변화가 적은 데이터만 접근하도록 하여, 데이터베이스 부하를 줄이고 응답 속도를 높히는데 집중을 했습니다.
3. Application 자원 활용
데이터베이스의 책임은 주로 데이터를 안전하게 저장하고, 빠르고 효율적으로 조회하는 데 집중
애플리케이션의 책임은 비즈니스 로직과 관련된 연산과 데이터 조작을 담당하며, 데이터베이스로부터 데이터를 받아 필요한 연산을 수행하는 역할
각 자원의 특성을 생각해서 데이터베이스는 안전하고 빠르게 데이터를 주는데 집중하고 Application은 연산을 집중적으로 담당해서 처리 하였습니다.
Application 자원의 사용은 비용이 더 저렴하고, 운영 측면에서도 더 효율적이라는 장점이 있었습니다.
실패 사례
첫 번째 시도: S3
모든 쿠폰 데이터를 배치로 생성해 S3에 업로드
문제점: 다운로드 지연과 네트워크 비용 증가 
(1480개 쿠폰 데이터 용량: 5MB)
두 번째 시도: Memcached
Memcached에 쿠폰 데이터를 저장
문제점: 단일 Key 최대 용량 1MB의 한계에 부딪힘
세 번째 시도: Memcached 분산 저장
데이터를 분산해 저장한 후 조합
문제점: 조합 과정의 시간 소요 증가 및 호출 횟수 증가
최종 개선 방향: 최소한의 DB 사용
1. 쿼리 구성 요소 분석
쿼리 구성 요소: JOIN, SubQuery, UNION, GROUP BY, ORDER BY, CASE등
쿼리를 짜면서 볼수있는 모든것의 집합
문제점: 쿼리의 복잡성과 무거운 구조가 성능 저하와 유지보수 비용을 증가
2. 개선 방안
쿼리 분리: 가벼운 쿼리로 나누어 개별 성능 향상.
캐싱 처리: 캐싱할 수 있는 데이터는 최대한 캐싱.
로직 처리: 특정 조건은 쿼리가 아닌 로직으로 처리해 복잡성 경량화.
3. 구체적 개선 방법
사용 가능한 쿠폰 필터링 및 캐싱: 쿠폰 유형으로 필터링한 후 캐싱하여 효율성을 높임
회원 등급 캐싱: 개별 회원의 등급 정보를 캐싱하여 조회 성능을 향상
쿠폰 조건 로직 처리: 온라인 쿠폰 및 등급 쿠폰의 다양한 조건을 로직으로 처리하여 복잡성을 경감
회원 보유 쿠폰 처리: 회원이 보유한 쿠폰을 실시간으로 조회하고 로직을 통해 필터링
4. 결과
평균 Latency가 110ms → 83ms 로 응답속도 약 24.55% 향상
최초 진입시에는 약 150ms로 기존로직 약 110ms로 기존 보다 조금 느려졌지만 이후 캐싱을 통해서 서비스하면서 속도가 향상됨.
쿼리를 단순화시켜서 여러번 수행시키면서 기존 사용가능한 쿠폰의 데이터를 구하는 쿼리가 60ms걸렸지만 개선 후 20ms로 쿼리가 가벼워짐
동일한 로직을 수행시 기존 DB사용량의 변화
- 개선 전 로직 DB 사용률 72.5% 
- 개선 후 최초 호출시 49.5%
- 캐싱이 된 후에는 13.6%
쿼리를 분할하고 Application 로직을 사용하면서 데이터베이스 부하는 줄어들고, 인프라 비용 역시 절감할 수 있었습니다. 이 과정을 통해 무거웠던 600줄짜리 레거시 쿼리와의 아름다운 이별이 가능했습니다.
마무리
이번 개선 작업을 통해 쿼리의 속도가 빠르다고 해서 그 복잡성이 괜찮다고 여기는 것은 잘못된 생각이라는 것을 깨달았습니다. 단순히 성능만을 추구하는 것이 아닌, 더 효율적이고 관리하기 쉬운(유지보수가 용이한) 대안을 찾아야 한다는 중요한 교훈을 얻었습니다.
이번 개선에서의 경험은 다양한 접근 방식이 존재한다는 것을 느끼게 해주었고, 복잡한 쿼리를 단순화하는 것이 기술적 부채를 줄이고 향후 유지보수를 용이하게 한다는 것을 느끼게 해준 개선 작업이었습니다.
앞으로도 다양한 방법과 유지보수가 용이하도록 지속적인 개선을 통해 더 나은 시스템을 구축해 나갈 것입니다.
MUSINSA CAREER
함께할 동료를 찾습니다.
무신사의 폭발적인 성장에는 매년 말 진행 했던 무진장(블랙프라이데이)가 큰 역할을 했습니다. 해당 이벤트로 매출 부스팅 및 신규 유저를 확보 했고, 이렇게 증가된 매출과 유저로 인해 매년 높은 매출 성장을 이뤘으며, 지금의 무신사가 만들어졌습니다. 캠페인개발팀은 무신사의 핵심 행사인 무진장(블랙프라이데이) 캠페인을 주도적으로 개발 및 운영지원 하고 있습니다. 그 외에도 무신사에서 전개 하는 다양한 캠페인 및 이벤트를 적극적으로 지원하고 있습니다. 우리는 팀원 각자 전문성과 열정을 바탕으로 다양한 캠페인을 성공적으로 오픈하고 있으며, 파트너와 함께 고민하며 성장하기 위해 최선을 다하고 있습니다.
🚀 팀 무신사 채용 페이지 (무신사/29CM 전체 포지션 확인이 가능해요)
🚀 팀 무신사 테크 소식을 받아보는 링크드인
🚀 무신사 테크 블로그
🚀 29CM 테크 블로그
🚀 무신사 테크 유튜브 채널
채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요!
무신사 성장과 함께 거대해져온 600줄짜리 쿠폰 쿼리와의 아름다운 이별 was originally published in MUSINSA tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

무신사 성장과 함께 거대해져온 600줄짜리 쿠폰 쿼리와의 아름다운 이별

댓글