[요즘 우아한 개발] 메인 데이터베이스 IDC 탈출 성공기

2023년 10월 30일조회 133

이 글은 《요즘 당근 AI 개발》에서 발췌했습니다.

요즘 당근 AI 개발

ISBN 9791194383475지은이 당근 팀₩22,000

2019년을 마무리하는 시점에 우아한2010년 6월 출범한 배달의민족은 앱 누적 다운로드 4000만 건 돌파, 메인 데이터베이스를 IDC(Internet Data Center) 환경에서 탈출시킨 과정을 공유하려고 합니다.

[요즘 우아한 개발] 메인 데이터베이스 IDC 탈출 성공기

이 글은 《우아한 요즘 개발》에서 발췌했습니다.

골든래빗 출판사

#루비 #데이터베이스 #IDC

박주희 2019.12.19

우아한형제들의 메인 데이터베이스, 루비

2010년 6월 출범한 배달의민족은 앱 누적 다운로드 4000만 건 돌파, 월간 순 방문자 수 900만 명, 전국 등록 업소 수 30여만 개, 거래액 기준 연간 약 5조 원의 배달 주문을 처리합니다(2018년 12월 기준). 이런 성장을 뒷받침하기 위해 소수의 개발자가 빠르게 서비스를 개발했고, 하나의 메인 데이터베이스(Microsoft SQL Server)에 모든 데이터와 로직을 집중시키는 모노리틱 아키텍처(Monolithic Architecture) 방식을 택했습니다. 루비는 메인 데이터베이스의 사내 명칭입니다.

빠른 개발과 관리 포인트 집중을 위한 선택이었지만, 시간이 지나면서 소수 인원이 빠르게 개발할 수 있던 과거와 달리 여러 서비스가 동시다발적으로 메인 데이터베이스를 사용하면서 예상하지 못한 부작용이 발생했고, 사소한 기능 하나를 추가하는데도 분석하고 수정할 개발 범위는 상상을 초월했습니다. 새로운 기술을 도입하거나 새로운 기능을 오픈할 때마다 미처 확인하지 못한 부분이 발목을 잡았고, 복잡한 로직과 구조 때문에 장애 상황에 빠르게 대응하지 못했습니다. 또, 메인 데이터베이스에 이슈가 생기면 배달의민족 전체 장애로 확산되기도 했습니다.

루비에서 탈출할 수 있을까?

이 상황을 타개하기 위해 변화에 유연하지 못한 IDC를 벗어나서 모든 데이터베이스를 클라우드 환경에서 운영하고자 했고, 우아한 개발자들은 3년이 넘는 시간 동안 하나의 거대한 시스템을 작은 서비스 단위로 나눠서 구현하는 메인 데이터베이스 탈출 프로젝트를 진행해왔습니다. 포인트 시스템 개편 등 크고 작은 프로젝트가 이 기간에 20~30개 정도 진행되었고 몇 달, 몇 년에 걸친 꾸준한 작업의 결과로 2019년 하반기에 접어들면서 서비스 영향도가 많이 줄었습니다.

정말 어쩌면 메인 데이터베이스를 없앨 수도 있을 것 같다는 작은 희망을 품게 되었습니다. 서비스 영향도가 많이 낮아진 것이 수치로 확인되었기에, 과감하게 메인 데이터베이스를 종료하고 싶다고 이메일을 한 통 보냈습니다. ‘안녕하세요. 시스템신뢰성개발팀 박주희입니다. 2019년 10월 31일 루비를 종료하고 싶습니다!’

여러 부서에서 아직 메인 데이터베이스에 대한 의존성이 있다는 회신을 받았습니다. ‘일부 데이터는 메인 데이터베이스에 동기화하고 있어요.’, ‘아직 일부 기능은 메인 데이터베이스를 참조해요.’, ‘메인 데이터베이스 사용은 하지 않는데 혹시 몰라서 아직 커넥션은 남겨뒀어요.’, ‘과거 데이터는 메인 데이터베이스에서 조회해야 해요.’

메인 데이터베이스를 중단한다고 이메일을 보낸 후 약 3개월 동안 서비스 간 의존성을 확인하고, 서비스 범위를 확인하고, 각 시스템으로 이관할 데이터를 분리해서 나누고 옮기는 과정을 반복했습니다. AWS DMS와 mysqldump를 사용해서 신규 데이터베이스로 데이터를 이관하고, 신/구 데이터베이스에 동시에 데이터를 적재하고 데이터를 검증할 수 있는 로직을 만들고, SQL 서버에서 커넥션을 확인한 후 사내 플랫폼 포털을 통해 AWS 리소스를 찾고, 수많은 소스 코드를 수정하고, 메인 데이터베이스에 의존적이던 (구) 어드민 시스템까지 통폐합하면서, 3개월이라는 짧고도 긴 시간에 정말 많은 변화가 생겼습니다. 개발, 기획뿐만 아니라 고객 서비스, 광고 계약 등을 담당하고 있는 여러 부서의 많은 분과 함께 정신없는 3개월을 보냈습니다.

과제와 교훈

그리고 3개월 후, 영원히 불가능할 줄 알았던 그 일이 정말로 일어나고야 말았습니다. 2019년 11월 1일 메인 데이터베이스로 유입되던 모든 커넥션이 제거되었고, 2019년 11월 26일 마침내 배달의민족 서비스의 한 축을 담당했던 메인 데이터베이스가 IDC에서 철수하게 되었습니다. 하나의 큰 데이터베이스는 여러 개의 데이터베이스로 분리되었고, 메인 데이터베이스 하나에 의존했던 배달의민족 서비스는 이제 100개 이상의 데이터베이스가 빠른 비즈니스 변화에 맞춰서 유기적으로 움직이고 있습니다. 이번 프로젝트를 진행하면서 발견된 몇 가지 문제점과 배운 점을 부끄럽지만 공유하려고 합니다.

서비스는 종료되었지만, 소스 코드는 그대로 남아 있다

프로시저 내부 로직은 전부 주석 처리했지만 호출하는 부분은 미처 제거하지 못해서 아무런 기능도 없는 프로시저가 호출되는 경우도 있고, 프로시저를 호출하는 부분까지 정리가 되었지만 정작 프로시저는 그대로 남겨둔 경우도 있습니다. 서비스가 종료되거나 아키텍처 개선 등으로 인해 리팩터링되었지만, 레거시를 정리하지 않았기 때문에 발생하는 현상입니다. 그렇다고 그냥 안 쓰는 건데 그냥 좀 두어도 괜찮다고 생각하고 넘기기엔 발생하는 문제가 생각보다 컸습니다. 신규 개발 후 QA 과정에서 새로 개발한 시스템이 아닌 레거시 시스템으로 연결되어 테스트 당시에는 오류를 발견하지 못했지만, 시간이 지나면서 데이터에 누수가 생기기도 하고, 불필요한 부분에서 병목이 발생해서 전체 서비스 레이턴시에 문제가 생기기도 합니다. 관리 포인트는 점점 늘어나고 다음 프로젝트를 위한 개발 범위 산정이 계속해서 커지는 것도 레거시를 정리하지 못해서 생기는 부작용입니다.

테이블 이름, 프로시저명, 변수명 등 ‘이름’만으로 목적을 알 수 없다

여러 명이 동시다발적으로 개발/운영을 하다 보니 명명 규칙에 대한 협의가 사전에 이뤄지지 않았습니다. 각자 편한 대로 혹은 쓰던 대로 이름 붙이다 보니 오타나 오기로 인해 의미가 왜곡되기도 했고, 이름만으로는 절대 목적을 알 수 없는 특수한 컬럼이나 테이블도 있습니다. 빠르게 개발하고 즉시 투입해서 운영하다 보니 테이블의 용도나 목적, 의미에 대한 기록이 남아 있지 않아서 지라, 위키, 구글을 하나하나 검색하고, 수십 명의 개발자에게 하나하나 확인해야 했습니다.

모두가 주인인 듯 아무도 주인이 아니다

하나의 프로시저를 여러 시스템에서 호출하고, 여러 개발자가 동시에 수정하면서 모두가 사용하지만 아무도 오너십을 가지지 않는 상황이 되었습니다. 여러 팀에서 같은 코드를 사용하면서 전체 로직 확인 없이 각자 필요한 부분만 조금씩 수정하는 과정이 반복되었습니다. 그리고 결국, 내가 수정한 코드가 다른 부분에서 어떤 문제를 야기할 수 있는지 파악하기 힘들어지고, 이로 인해 전체 시스템에 대한 불확실성이 증가했습니다.

거의 비슷한 기능을 하는 조금씩 다른 코드가 있다

빠른 개발을 위해 기존의 코드를 복사해서 필요한 부분만 수정한 후 반영하게 되어 90%는 같지만 10%만 다른 코드도 많이 생겼습니다. 같은 소스 코드를 여러 방향으로 수정하다 보니 한 번 계산된 데이터를 거꾸로 다시 풀기도 하고, 조인하지 않아도 되는 테이블을 조인하기도 했습니다.

배운 점

프로젝트를 계획할 때 레거시 제거도 프로젝트 범위에 포함하자

수많은 레거시가 제거되지 못하는 가장 큰 이유는 바로 ‘일정이 부족해서’일 겁니다. 처음 프로젝트를 시작할 때 전체 일정을 산정하는데, 대부분 프로젝트에서 레거시 제거를 프로젝트 범위에 포함하지 않습니다. 하지만 이 과정이 생략됨으로 인해서 발생하는 부작용은 생각보다 큽니다.

명명 규칙을 미리 정하고 최대한 많은 사람에게 공유하자

명명 규칙, 자료형을 미리 정하는 것은 귀찮지만 중요한 일입니다. 혼자서 모든 것을 개발하고 유지보수할 수 있으면 좋겠지만, 우리는 함께 일을 하고 있기 때문에 규칙을 정하는 게 중요합니다. 미리 규칙을 정하고 정해진 약속대로 한다면 여러 명이 개발한 소스를 빠르게 머지할 수 있고, 자료형의 불일치도 최소화할 수 있어서 개발과 운영에 드는 리소스를 줄일 수 있습니다.

극단적인 예를 들자면 이렇습니다. 다섯 명의 팀원이 회원 시스템을 개발하기로 했는데 명명 규칙과 자료형을 미리 정하지 않았다면, member_number varchar(20), mem_no int, MemNo bigint, M_no varchar(50), member_no nvarchar(20) 이렇게 다른 다섯 개의 명명과 자료형을 가진 컬럼이 결과적으로 같은 회원번호를 의미하게 될 수 있습니다. 이러한 명명의 불일치로 인해서 최악의 경우에는 개발이 어느 정도 진행된 시점에 대대적으로 수정해야 할 수도 있고, 미처 눈치채지 못하고 서비스를 오픈했다가 개발이 어느 정도 진행된 시점에서 대대적으로 수정을 할 수도 있고, 모르고 서비스를 오픈했다가 시간이 지난 후 데이터 잘림 현상이 발생하거나, 구조적인 문제로 성능 저하가 발생할 수도 있습니다.

코드에 대한 오너십을 갖자

가급적 코드에 대한 오너십을 명확하게 정하는 것이 좋습니다. 공통으로 사용하는 기능이라고 하더라도 오너십을 부여하고 이를 주기적으로 관리하는 것과 관리하지 않는 것의 차이는 큽니다. 아무도 관리하고 있지 않은 때에 장애 인지 및 장애 복구가 전반적으로 늦어지고 장애 확산 가능성도 훨씬 커질 수 있습니다.

로직은 가급적 단순하고 명료하게 만들자

기존에 동작하던 것과 비슷한 기능을 구현할 때 보통 기존 소스 코드를 복사해서 필요한 부분을 수정합니다. 기존 소스 코드를 재사용할 때는 반드시 불필요한 로직이 수행되고 있지는 않은지, 다른 곳과 불필요한 의존성이 존재하지 않는지 점검해봐야 합니다. 필요도 없는 데이터를 계산하느라 발생하는 성능 저하는 생각보다 자주 볼 수 있습니다.

◆◆◆

메인 데이터베이스 탈출은 오랜 기간 많은 사람의 노력으로 이루어진 일입니다. 결코 순탄하지 않았던 과정을 성공적으로 마무리한 모든 우아한 개발자 여러분께 이 자리를 빌려 감사 인사와 박수를 보냅니다.

저자 우아한 형제들

우아한형제들은 배달이 일상을 조금 더 행복하게 하도록 오늘도 달리고 있습니다. 평범한 사람들이 모여 비범한 성과를 만들어 내는 곳이될 수 있도록 건강한 조직문화를 만드는 일에 진심을 다합니다. 2016년부터 ‘우아한형제들 기술블로그’를 운영하며 개발 조직의 성장 과정을 기록하고 있습니다.

AI AWS DevOps IDC IT IT기업 JIRA JPA Next.js 개발 개발 실무 개발자 개발팀장 경력 경력관리 관리자 기업문화 기획 데브옵스 리액트 리팩터링 리팩토링 매니저 머신러닝 문제해결 배달의민족 배민 백엔드 블로그 사내문화 성장 소프트스킬 스크럼 스타트업 스프링부트 시니어 애자일 온보딩 우아한형제들 유니콘 이력관리 이직 인공지능 자기계발 젠킨스 조직문화 주니어 지라 취업 커리어 커리어패스 코드리뷰 코딩 프런트엔드 프로그래머 프론트엔드

📚 더 읽기

저자 소개

당근 팀

당근의 여러 부서에서 각자 다른 문제를 풀던 11명이 하나의 질문으로 모였습니다. “AI로 더 잘 해결할 수 없을까?” 우리는 직군의 경계를 넘어 함께 고민하고 실험하며, ‘동네를 여는 문’이라는 당근의 비전을 AI로 구현해가는 사람들입니다. 이웃과 이웃을 더 따뜻하게 연결하고, 당근에서의 삶을 더 편리하게 만드는 일. 그 중심에서 AI가 할 수 있는 역할을 찾아가고 있습니다.

📚《요즘 당근 AI 개발》 자주 묻는 질문

Q.당근에서 AI를 어떻게 활용하고 있는지 궁금합니다. 구체적인 사례를 알고 싶어요.

당근은 AI를 다양한 방식으로 활용하여 사용자 경험을 향상시키고 내부 업무 효율성을 높이고 있습니다. 외부 사용자를 위한 사례로는 AI 물품 추천, AI 게시글 작성, AI 시세 조회, CS 챗봇 등이 있습니다. AI 물품 추천은 사용자의 검색 기록, 관심 카테고리 등을 분석하여 개인에게 최적화된 물품을 추천합니다. AI 게시글 작성은 사용자가 원하는 물품 정보를 입력하면 자동으로 제목과 상세 설명을 생성해줍니다. AI 시세 조회는 과거 거래 데이터를 기반으로 현재 시세를 예측하여 사용자에게 정보를 제공합니다. CS 챗봇은 사용자의 문의에 24시간 응대하여 빠른 문제 해결을 돕습니다. 내부 구성원을 위한 사례로는 리뷰 자동 리포트 발행, 온콜 업무 단축, 임베딩 시멘틱 캐싱, 운영업무 자동화 등이 있습니다. 리뷰 자동 리포트 발행은 사용자 리뷰를 분석하여 핵심 내용을 요약하고 트렌드를 파악하여 개선점을 도출합니다. 온콜 업무 단축은 AI를 활용하여 문제 발생 시 담당자에게 자동 알림을 보내고 초기 대응을 지원합니다. 임베딩 시멘틱 캐싱은 검색 속도를 향상시켜 사용자 경험을 개선합니다. 운영업무 자동화는 반복적인 작업을 자동화하여 효율성을 높입니다. 이러한 다양한 사례를 통해 당근은 AI를 적극적으로 활용하여 사용자 만족도를 높이고 내부 효율성을 개선하고 있습니다. 더 자세한 내용은 《요즘 당근 AI 개발》에서 확인하실 수 있습니다.

Q.AI 에이전트와 MCP 개발이 무엇인지, 당근에서는 어떻게 활용하고 있는지 알고 싶습니다.

AI 에이전트와 MCP(Message Composition Platform)는 AI 기술을 활용하여 사용자 경험을 혁신하는 핵심 요소입니다. AI 에이전트는 사용자의 의도를 파악하고 작업을 자동화하는 지능형 시스템입니다. 당근에서는 AI 에이전트를 활용하여 사용자 문의에 자동 응답하거나, 개인 맞춤형 추천을 제공하거나, 특정 작업을 대신 수행하는 등 다양한 서비스를 제공합니다. MCP는 메시지 작성 및 관리를 위한 플랫폼으로, AI 기술을 활용하여 메시지 내용을 자동 생성하거나, 최적의 메시지 형식을 추천하거나, 메시지 전송 시점을 예측하는 등 다양한 기능을 제공합니다. 당근에서는 MCP를 활용하여 사용자에게 보다 효과적이고 편리한 커뮤니케이션 환경을 제공합니다. 예를 들어, 물품 판매 게시글을 작성할 때 AI가 자동으로 제목과 설명을 제안해주거나, 구매자와 판매자 간의 채팅 내용을 분석하여 사기 위험을 감지하는 데 활용될 수 있습니다. 이와 관련된 자세한 내용은 《요즘 당근 AI 개발》에서 확인하실 수 있습니다.

Q.바이브 코딩이 무엇인가요? AI 코딩 도구와 어떤 관련이 있나요?

바이브 코딩은 개발자가 코딩 과정에서 느끼는 즐거움과 몰입감을 극대화하는 것을 의미합니다. AI 코딩 도구는 이러한 바이브 코딩을 지원하기 위해 개발되었으며, 코드 자동 완성, 오류 검출, 코드 제안 등 다양한 기능을 제공하여 개발자가 보다 쉽고 효율적으로 코딩할 수 있도록 돕습니다. 당근에서도 AI 코딩 도구를 적극적으로 활용하여 개발 생산성을 향상시키고 있습니다. 예를 들어, AI가 코드를 자동으로 완성해주거나, 흔히 발생하는 오류를 미리 감지하여 수정하도록 제안함으로써 개발 시간을 단축하고 코드 품질을 향상시킬 수 있습니다. 또한, AI는 다양한 코딩 패턴을 학습하여 개발자에게 최적의 코딩 방식을 제안함으로써 개발자가 보다 창의적인 문제 해결에 집중할 수 있도록 돕습니다. 바이브 코딩과 AI 코딩 도구에 대한 더 자세한 내용은 《요즘 당근 AI 개발》에서 확인하실 수 있습니다.

Q.프롬프트 엔지니어링 기법 고도화는 무엇이며, 왜 중요한가요?

프롬프트 엔지니어링은 AI 모델, 특히 대규모 언어 모델(LLM)에 효과적인 프롬프트를 설계하고 최적화하는 기술입니다. 이는 AI 모델이 원하는 결과를 정확하고 효율적으로 생성하도록 유도하는 데 매우 중요합니다. 프롬프트 엔지니어링 기법을 고도화한다는 것은, 단순히 질문을 잘 던지는 것을 넘어, AI 모델의 작동 방식을 이해하고, 모델이 가진 강점과 약점을 파악하여, 모델이 가장 잘 수행할 수 있는 형태로 질문을 구성하는 것을 의미합니다. 당근 팀은 사용자 경험을 극대화하기 위해 프롬프트 엔지니어링 기법을 고도화하는 데 많은 노력을 기울였습니다. AI 모델을 활용하여 물품 추천, 게시글 작성, 시세 조회 등 다양한 서비스를 제공하면서, 각 서비스에 최적화된 프롬프트 엔지니어링 기법을 개발하고 적용했습니다. 이 과정에서 얻은 경험과 노하우는 《요즘 당근 AI 개발》에 자세히 담겨 있습니다. AI 모델을 활용한 서비스 개발에 관심 있는 분이라면, 이 책을 통해 프롬프트 엔지니어링 기법 고도화의 중요성과 실제 적용 사례를 배울 수 있을 것입니다.

Q.AI를 활용한 개발을 배우고 싶은데, 어디서부터 시작해야 할지 막막합니다.

AI 활용 개발을 시작하는 것은 흥미로운 여정이 될 것입니다. 먼저 AI의 기본 개념과 원리를 이해하는 것이 중요합니다. 온라인 강의, 책, 튜토리얼 등 다양한 학습 자료를 활용하여 AI의 핵심 개념을 습득하세요. 그다음, 파이썬과 같은 프로그래밍 언어를 익히는 것이 좋습니다. 파이썬은 AI 개발에 가장 널리 사용되는 언어 중 하나이며, 다양한 AI 관련 라이브러리와 프레임워크를 제공합니다. 텐서플로우, 파이토치, scikit-learn과 같은 AI 라이브러리를 사용해 간단한 AI 모델을 직접 만들어보는 것이 좋습니다. 이러한 경험을 통해 AI의 작동 방식을 더 깊이 이해할 수 있습니다. 또한, AI 관련 프로젝트에 참여하거나, 오픈소스 프로젝트에 기여하면서 실력을 향상시킬 수 있습니다. 당근 팀의 경험을 통해 배우는 것도 좋은 방법입니다. 《요즘 당근 AI 개발》에는 당근 팀이 사용자 문제를 AI로 해결해나가는 여정이 담겨 있습니다. 이 책을 통해 실제 서비스에 AI를 적용하는 방법을 배우고, AI 개발에 대한 영감을 얻을 수 있을 것입니다.

Q.AI 모델을 서비스에 적용할 때 성능 문제를 어떻게 해결할 수 있을까요?

AI 모델을 서비스에 적용할 때 성능 문제는 흔히 발생합니다. 이를 해결하기 위해서는 다양한 접근 방식이 필요합니다. 먼저, 모델의 복잡도를 줄이는 방법을 고려해볼 수 있습니다. 모델의 레이어 수를 줄이거나, 파라미터 수를 줄이는 등의 방법을 통해 모델의 연산량을 줄일 수 있습니다. 또한, 데이터 전처리 과정을 최적화하여 모델의 학습 효율성을 높일 수 있습니다. 불필요한 데이터를 제거하거나, 데이터의 형식을 통일하거나, 특성 스케일링을 적용하는 등의 방법을 통해 모델의 성능을 향상시킬 수 있습니다. 임베딩 시멘틱 캐싱과 같은 기술을 사용하여 검색 속도를 향상시킬 수도 있습니다. 또한, 모델을 경량화하거나 양자화하는 방법을 고려해볼 수 있습니다. 모델 경량화는 모델의 크기를 줄여 메모리 사용량을 줄이고, 연산 속도를 높이는 기술입니다. 모델 양자화는 모델의 파라미터를 저정밀도로 표현하여 모델의 크기를 줄이고, 연산 속도를 높이는 기술입니다. 당근 팀은 AI 모델을 서비스에 적용하면서 다양한 성능 문제를 해결해왔습니다. 이러한 경험은 《요즘 당근 AI 개발》에 자세히 소개되어 있습니다. 이 책을 통해 AI 모델 성능 문제 해결에 대한 인사이트를 얻을 수 있을 것입니다.

Q.당근 팀은 AI를 개발하고 적용하면서 어떤 어려움을 겪었으며, 어떻게 극복했는지 궁금합니다.

당근 팀도 AI를 개발하고 적용하는 과정에서 많은 어려움을 겪었습니다. 'AI로 과연 될까?'라는 의문에서 시작하여 'AI로 어떻게 하면 될까?'라는 고민을 거듭했습니다. 데이터 부족, 모델 성능 문제, 인프라 제약 등 다양한 문제에 직면했습니다. 하지만 엔지니어, 프로덕트 매니저, 운영 매니저 등 다양한 팀원들이 협력하여 문제 해결에 나섰습니다. 데이터 확보를 위해 다양한 방법을 시도하고, 모델 성능 향상을 위해 끊임없이 실험하고, 인프라 제약을 극복하기 위해 기술적인 혁신을 이루어냈습니다. 예를 들어, AI 물품 추천 시스템을 개발할 때 초기에는 데이터가 부족하여 추천 성능이 낮았습니다. 이를 해결하기 위해 사용자 행동 데이터를 수집하고 분석하는 시스템을 구축하고, 외부 데이터 소스를 활용하여 데이터 부족 문제를 해결했습니다. 또한, 모델 성능 향상을 위해 다양한 모델 구조와 학습 방법을 시도하고, A/B 테스트를 통해 최적의 모델을 선택했습니다. 이러한 노력 덕분에 AI 물품 추천 시스템은 사용자 만족도를 크게 향상시켰습니다. 이처럼 당근 팀은 AI 개발 과정에서 겪는 어려움을 창의적인 아이디어와 끊임없는 노력으로 극복해왔습니다. 자세한 내용은 《요즘 당근 AI 개발》에서 확인하실 수 있습니다.