딜리셔스 이용화 CTO 인터뷰

지난 6월, 패션 도소매 플랫폼 '신상마켓'은 모든 서비스 인프라를 AWS 클라우드로 전면 이전했습니다. 신상마켓을 운영하는 딜리셔스가 밝힌 그 이유는 서비스 안정성과 개발 생산성입니다. 이용화 딜리셔스 CTO에게 자세히 물었습니다. 클라우드 파트너십, 개발 생산성과의 관계 그리고 신상마켓과 딜리셔스의 개발 아젠다에 대해 이야기합니다.

• 클라우드 도입을 고민하는 기업 리더에게 권합니다.
• 비즈니스와 개발이 어떻게 융합하는지 궁금한 이에게 권합니다.
• 생산성에 대해 관심 많은 개발 조직 리더와 개발자에게 권합니다.

Q. 딜리셔스는 신상마켓 서비스를 AWS 클라우드 환경으로 전면 이전했다. 이유가 궁금하다.

이전에 신상마켓은 AWS 클라우드와 다른 클라우드 서비스를 절반씩 이용했다. 작은 규모일 때는 큰 문제가 없었지만, 서비스가 성장하며 트래픽이 늘어나는 환경에서는 운영 안정성을 담보하기 어려운 부분이 있었다. 이에 사용 편의성 및 안정성 측면에서 검증된 AWS로 인프라를 전면 이전하기로 결정했다. 제가 CTO 맡기 전에 결정된 이전이지만, 저 역시 당연히 AWS로 옮겨야 한다고 생각했다.

또 연계된 AWS 클라우드 서비스들이 지속적으로 출시되다 보니 대응이 확실히 좋다고 느낀다. AWS는 클라우드 산업 초창기부터 서비스를 제공해왔기 때문인지, 개발하던 중에 '어떤 클라우드 서비스가 있었으면 좋겠다'하는 개발자 니즈를 굉장히 빨리 캐치해서 서비스화 시키는 것 같다. 물론 AWS 자체적으로 고민해 만들어 내기도 하겠지만, 고객의 피드백을 굉장히 적극적으로 수집하는 기업 중 하나라고 생각한다.

AWS 어카운트 매니저와 파트너사인 베스핀글로벌에서 계속 새로운 서비스를 제안해주고, '혹시 필요한 부분은 없나', '다른 서비스를 내면 써보지 않겠냐'는 피드백을 귀찮을 정도로 물어본다. 물론 다 쓰지는 못하지만, 개발 중 서비스 안내가 떠오르면 바로 적용해보곤 한다. 당장은 아니더라도 언젠가 쓰게 될 기술 서비스들이 많다.

Q. 최근 그런 서비스 도입 사례가 있었나?

AWS EC2는 인텔 칩을 기반으로 돌아가고 있는데, 작년 말 ARM 기반 칩인 그라비톤 2(Graviton 2)를 도입한 신규 인스턴스가 나왔고 서울 리전에 적용이 됐다. 그걸 적용해본 기업이 있었던 것 같다. 그 피드백을 우리 회사 어카운트 매니저가 듣고, 그라비톤 2 타입의 신규 인스턴스를 제안했다.

벤치마크를 해봤더니 도입해도 좋겠다는 판단이 들었다. DB 같은 경우, CPU와 메모리를 많이 쓰는데, 또 AWS RDS가 굉장히 비싸다. 그래서 반대로 성능이 좋아질수록 비용 절감 효과가 좋아진다. 그래서 일부 DB를 그라비톤 2 타입의 신규 인스턴스인 R6g로 바꿀 계획을 가지고 있다.

^{* RDS: Amazon Relational Database Service, 아마존 관계형 데이터베이스 서비스}
* ^{R6g: AWS Graviton2 프로세서로 구동되는 메모리에 최적화된 Amazon EC2 인스턴스}

Q. AWS 클라우드를 사용하면 비용 절감 측면이 크다고 볼 수 있나?

오히려 AWS는 비싸다. 더 중요한 것은 개발 생산성이다. 시간을 살 수 있는 서비스라고 생각한다.

Q. 개발 생산성에 대해 좀 더 자세히 설명해달라.

개발자를 코드 짜는 사람이라고 생각하지만, 사실 신경 쓸 게 굉장히 많다. 예를 들어 간단한 MVP 하나만 돌려 본다고 하더라도, 인프라팀에 어느 서버 써야 하는지 물어보고, 권한을 받아 포트 확인해보고 부족하면 늘려 달라고 다시 요청하는 등 커뮤니케이션 비용이 굉장히 많이 들었다.

인프라 세팅에 있어서도 초당 1000회 정도 트래픽을 받을 거 같으니, 이 정도 규모의 서버가 필요하다고 의견을 줘야 인프라팀이 작업을 시작할 수 있다. 물론 그전에 예상 트래픽 산정하는 작업이 필요하고, 어느 정도까지 소화할 수 있게 할 것인지도 논의를 해야 한다. 또 보안 이슈가 있다면 보안팀과 협업을 해야 한다. 이런 운영과 관련된 리소스가 특히 많이 소모된다. 개발자가 무엇 하나 해보기 어려운 환경이다.

하지만 클라우드 환경에서는 개발자가 쉽게 구축할 수 있어 협업과 관련된 비용을 확실히 줄일 수 있다. 클라우드는 개발자에게 컨트롤 권한이 있어 바로 테스트해 볼 수 있고 수정도 빠르다. 운영에 있어서도 트래픽에 따라 바로 인스턴스를 조절하면 된다. 이게 개발 생산성에 있어 굉장한 차이다. 그래서 클라우드로 옮기는 것은 너무나 당연하다.

종합적으로 보면, 개발자가 자신의 비즈니스 로직을 구현하는 데 집중할 수 있도록 클라우드가 도와준다고 생각한다. 그리고 로직의 구현이 개발자의 본업이 되어야 한다.

Q. 이전 과정에 대해 물어보고 싶다. 혹시 트러블 슈팅이 있었나?

다행히 큰 규모의 장애는 없었다. DB부터 옮겨왔다. MySQL 호환 AWS 오로라로 이전을 먼저 했다. DBMS를 시작으로 신상마켓 내 애플리케이션 서버 및 ElasticSearch, Redis 등의 서비스도 AWS로 이전했다.

딜리셔스가 운영하는 신상마켓이라는 큰 서비스가 있고, 그 안에 어드민 등이 있다. 사실 DB 작업이 장애가 났을 때 가장 파급이 크기 때문에 가장 어려웠고, 또 우려했는데 큰 문제 없이 잘 끝났다.

Q. 파트너사인 베스핀글로벌과는 어떻게 맺어졌나?

처음 딜리셔스에 왔을 때는 다른 파트너 기업이 있었다. 이후 우연한 기회로 현재 담당자와 만나게 됐는데, 베스핀글로벌에서 해줄 수 있는 지원에 대해서 전해 듣고 파트너십을 체결한 계기가 됐다.

당시 파트너사 지원이 부족하다는 느낌을 많이 받았다. 딜리셔스는 이전부터 AWS 클라우드를 써오고 있었기 때문에 AWS 쪽에 문의를 해야 하는 상황이 생길 수밖에 없다. 예를 들어, 갑자기 DB가 페일오버(Failover) 됐을 때, 원인을 찾기 위해 기술 지원 티켓팅을 통해 AWS와 논의를 해야 한다. 이 과정에서 파트너사가 AWS와 중개를 해주거나 자체적으로 알고 있는 기술 지원을 해줄 것 기대했지만 충분하지 못했다. 이전 파트너사는 커뮤니케이션 자체가 많지 않았다.

원래 '파트너가 이 정도밖에 안 해주는 건가' 의아해 하는 와중에 베스핀글로벌과 만나게 됐다. 충분한 기술 지원이 그들의 강점이라서 선택했다. 베스핀글로벌은 새로운 서비스가 나오며 제안해주고, 관련 웨비나 정보까지도 굉장히 많이 제공해준다. 추가적으로 비용 할인 부분도 메리트가 있었다.

^{* 페일오버(Failover): 사용 서버가 장애로 사용이 어렵게 될 경우, 클론 서버로 그 일을 대신 처리하게 해서 무정지 시스템을 구축하는 상태를 의미한다. 기업에서는 서버가 다운되면 그 시간에 비례하여 기하급수적인 손해가 발생하기 때문에 반드시 Failover가 필요하다.}

Q. 이제 신상마켓 서비스에 대해 묻고 싶다. '신상마켓'은 도소매 B2B 플랫폼이라는 점에서, 유저 수도 적고 감당해야 할 트래픽이 크지 않을 거 같다.

신상마켓 서비스 모습만 보면 일반적인 온라인 쇼핑몰과 크게 다르지 않다. 다만 일반 온라인 쇼핑몰처럼 소매상이 상품을 올리고 개인이 구입하는 구조가 아니라, 신상마켓은 도매상이 상품을 올리고 소매상이 구입하는 구조다. 사용자 규모로 보면 B2B인 '투 사이드 플랫폼(Two-sided platform)'인데, 사용자인 도매상이 1~2만 개이고 소매상이 몇 십만 정도이니 그것도 B2C와 비교한다면 분명 적다.

다만 신상마켓의 큰 특징은 체류시간이 굉장히 길다는 점이다. 7월 평일 기준으로 신상마켓 소매상 유저가 평균 35분 가량 체류한다. 패션 플랫폼 중 순위로 보면 지그재그, 에이블리 등 B2C 플랫폼에 이어 5위다. 소매 유저가 상품 구매라는 명확한 목적을 가지고, 도매상들이 상품을 올리면 계속 상품을 탐색하는 것이다. 소매 유저가 자신들이 팔고 싶은 물건 찾을 때까지 탐색이 이뤄지기 때문에, 트래픽이 적게 나오지 않는다. 게다가 동대문 상가 도매상 중 80%, 전국 매장의 소매상 중 50%가 신상마켓의 유저다. 그래서 체류시간, 재방문율, 노출되는 스크롤도 압도적으로 높다.

그리고 트래픽이 강하게 오르는 시점이 있다. 신상마켓의 경우 밤 10시부터 올라가기 시작해서 자정에 이르면 최고점이 된다. 두 가지 이유가 있는데, 첫 번째는 동대문 시장은 밤에 시장이 열리고 신상마켓을 이용하는 도소매상들이 앱을 켜고 활동하는 시간대가 주로 밤 10시 부터다.

두 번째는 사입 시스템이다. 동대문 상가에는 소매상이 물건을 주문하면 도매상이 물건을 보내주는 과정에 사입이라는 프로세스가 있다. 주문을 받은 도매상이 물건을 포장해 두면 '사입삼촌'이라 불리는 분들이 이를 소매상에게 옮겨 배달하게 된다. 딜리셔스는 이와 비슷하게 '신상 배송'이라는 이름의 관련 서비스를 제공하고 있다. 도매상이 주문을 받아 물건을 포장해두면, 사입팀이 그걸 가져와 물류센터에 입고시키고, 물류팀에서 소매상에게 각각 보내주는 구조다.

이 과정에서 '사입 주문'이 이뤄진다. 대부분 소매사업자들이 아침부터 계속 도매 주문을 하면, 밤 10시에 주간에 쌓인 주문을 묶어 사입 주문서 형태로 생성을 한 다음에 도매로 보내준다. 그러다 보니 낮 동안 쌓였던 데이터를 한 번에 프로세싱하고 또 다른 형태로 묶어서 발송까지 한다. 게다가 이걸 도매상들이 확인하기 위해 동시에 앱에 접속하게 된다. 그래서 밤 10시에 트래픽이 급격하게 올라간다.

Q. 딜리셔스의 개발 조직은 어떻게 구성됐는지 궁금하다.

개발 조직원은 현재 60명이 넘는다. 신상마켓 서비스는 안드로이드, iOS, 웹으로 제공되고 있어 각 OS당 별도 팀이 구성돼 있다. 서버 개발팀은 3개로 나눠졌다. 하나는 기본적인 신상마켓의 백엔드 API를 처리하고 있는 팀과 검색이나 광고 플랫폼, 추천 등 도매 특화된 서비스를 담당하는 팀이 있다. 또 하나는 최근에 구성된 글로벌 사업 관련 프로덕트 팀이다. 다른 팀은 신상마켓의 안정성을 중시한다면, 이 팀은 도전적인 과제를 수행하는 팀이라고 볼 수 있다. 아직 동대문을 상품을 가지고 해외에서 성공 사례가 없다. 그래서 이를 도전적으로 추진할 계획이다. 이외에 QA 파트가 있고, 올해 2분기 보안팀을 신설했다.

Q. 목표로 하는 딜리셔스 개발팀의 기술 수준이 있나?

나만의 철학이 있다. 모든 신규 서비스 개발이나 기술 고도화는 운영이 토대가 되어야 한다. 운영은 효율성과 관련이 있고, 가장 리소스를 적게 들여서 문제 없이 돌아가는 게 운영의 기본이다. 이런 안정적인 운영이 바탕이 되어야만, 신규 개발도 따라갈 수 있다고 여긴다.

그래서 운영 부분에 필요한 것이 많다. 대표적으로 모니터링이 잘되어야 한다. 사람이 주시하거나 CS를 통해 대처하는 게 아니라, 사전에 개발팀에 전달된 정보를 바탕으로 오류를 찾아내서 신속하게 해결할 수 있는 구조가 만들어져야 한다. 이러한 장애 대응 프로세스, 모니터링 프로세스 등은 딜리셔스에 오자마자 신경 썼던 부분이기도 하다.

장애는 발생할 수 있다. 개발자는 누구나 버그를 만들고, 그 버그는 언젠가 문제를 일으킨다. 그러나 똑같은 장애가 다시 발생하면 안 된다. 이를 위해 '장애 회고' 프로세스를 도입해서 어떤 실수 때문에 문제가 발생했고, 이 정보가 다른 팀에도 공유가 되도록 해서 같은 문제가 발생하지 않도록 전파하고 있다.

예전에는 긴급 운영 채널 알림이 정말 많이 울렸다. 하지만 최근에는 안정화가 됐다. 현재 모니터링은 대부분 자동화됐고, 몇 달 동안 긴급 알림도 없었다. 이런 환경이 되어야만 신규 개발이 가능하다고 생각한다. 이제야 새로운 도전을 해볼 수 있게 됐다.

Q. '장애 회고'는 공식적인 프로세스인가?

'장애 회고'는 프로세스화 되어야만 의미가 있다. 슬랙에 회고 채널이 따로 두고 운영 중이다. 필수 회고 사항으로는 언제, 어느 부분에서 장애가 났고, 고객들이 어떤 불편을 겪었고, 그 원인은 무엇이고, 어떻게 해결했으며, 재발방지를 위해서 무엇을 해야 한다 등을 기록한다.

시스템 장애를 접근하는 마인드가 중요하다고 생각한다. 나 같아도 장애를 냈다면 '잠깐 안됐네 정도'로 숨기고 싶을 것 같다. 처음에는 운 좋게 작은 실수로 끝날 수 있지만 반복되면 크게 터지게 된다. 장애가 난 건 부끄러운 게 아니다. 앞서 말했 듯 개발자는 누구나 버그를 만들고, 그 버그는 언젠가 문제를 일으킨다. 그러나 두 번 발생 시킨다면 부끄러운 일이다.

개발 조직에 '장애 회고'를 도입할 때, 장문의 글을 직원들에게 남기기도 했다. 장애 회고를 쓰는 것은 장애를 일으켰다고 비난하기 위함이 아니라 재발 방지를 위한 것, 그리고 다른 사람과 공유해 다른 곳에서도 똑같은 장애가 일어나지 않도록 하기 위한 의도임을 전달하고 싶었다. 지금은 모두 부담 없이 장애 회고를 쓰고 있다. 또 요즘 장애가 잘 나오지 않는다.

Q. 마지막 질문으로, 올해 목표가 궁금하다.

올해 개발 조직의 목표를 세우기 위해 팀장님들과 이야기를 한 적이 있는데, '동대문 최고의 기술력을 가진 개발팀'이라고 말했다. 물론 이건 객관적인 척도로 정하기가 어렵지만 그래도 '무언가는 보여줄 수 있다'는 것이다.

그 '무엇'은 AI, 빅데이터와 같은 새로운 기술이 아니라 실제 경험이라고 생각한다. 우리가 개발한 레퍼런스를 적용했더니 달라졌다는 경험을 누군가에 전달하고 도움을 주는 것이 딜리셔스의 기술력을 입증하는 방법이다.

올해는 좋은 레퍼런스를 만들어 공유하는 시도를 많이 하려고 계획 중이다. 간편 결제, 채팅 서비스 등 우리가 직접 개발해 내재화한 기술 경험과 연말에 나오는 글로벌 프로덕트 등 우리가 겪었던 문제를 가지고 있는 분들에게 공유하고 도움을 주고 싶다. 그 시작으로 기술 블로그(링크)도 운영 중이다. 이런 방법으로 딜리셔스 개발팀을 최고의 팀으로 만드는 게 목표다.