카카오뱅크 MySQL 도입의 주역, DBA 성동찬

IT 인력 존중문화가 카카오뱅크의 MySQL 도입 성공을 이끌었다

- DB 자동화, 성능 관리 등 대부분의 도구 직접 개발
- 서비스 6개월 동안 채널계 시스템 무장애 실현
- 데이터 업무를 하면서 IT 관련 시야 넓어져
- DBA는 늘 새로운 시도를 할 수 있는 전문가
- 관행에 의문을 던지고 새로 접근하면서 성취감 느껴

카카오뱅크는 인터넷은행 업계에서는 두 번째이지만 IT 측면에서 첫 번째 타이틀이 많다. 그 중에서 IT 분야, 특히 DB 분야의 전문가들에게 신선한 충격으로 다가온 이슈가 있다. 바로 상용 DBMS가 당연하게 받아들여진 기존 관행을 깨고 오픈소스 DBMS인 MySQL을 성공적으로 도입 / 운영하고 있다는 점이다. 카카오뱅크 인프라파트의 성동찬 DBA와 만나 오픈소스 DB와 DBA에 대해 얘기를 나눴다.



성동찬 한국카카오은행 인프라파트 DBA

명함에 소속이 나와 있지 않은데 소속과 하고 있는 일을 소개하면.

"한국카카오은행(카카오뱅크)의 인프라파트 소속의 DBA로서 DB와 관련된 모든 업무를 하고 있다. DB 설계와 모델링을 검토하고, 튜닝이나 인덱스 구조 리뷰도 하며, 장애가 났을 때 대응을 한다. 카카오뱅크는 업무 특성상 정책적으로 각 업무를 완전하게 구분 짓지 않는다. 따라서 DA(data architect)나 DBA(database administrator) 같은 직함으로도 표현하지 않는다.

카카오뱅크의 DB 관련 조직은 어떻게 구성됐나.

회사 정책상 모두 소개하기는 곤란하지만, DBA들이 카카오뱅크의 계정계, 채널계, 정보계의 DB를 모두 개발·운영한다. 카카오뱅크는 개발자들과 DBA들이 함께 일하는 체제다. DB도 RDBMS만 보지 않고 파일이든 NoSQL이든 해당 서비스에 적합한지 여부를 기준으로 선택한다. 계정계 시스템은 SI 업체와 함께 개발했지만, 채널계 시스템은 내부 IT팀 독자적으로 개발했다.

채널계 시스템이라는 용어가 낯설다.

한마디로 인터넷은행의 창구를 담당하는 시스템이다. 카카오뱅크에게는 앱이 고객과 만나는 접점, 즉 창구다. 로그인 인증 관리와 앱에서의 입금 내역 등을 받아 채널계 DB에 넘겨준다. 여기다 문자 발송, 핀테크, 고객지원 등이 채널계 업무다. 그동안 금융권 IT 시스템은 OLTP 중심의 계정계와 OLAP 업무 중심의 정보계로 양분됐다. 하지만 인터넷 뱅킹이 널리 쓰이면서 고객과의 접점이 객장뿐 아니라 인터넷으로 확장되면서 인터넷 이용 고객의 접점 관리 측면에서 채널계라는 새로운 영역이 등장한 것으로 알고 있다.

카카오뱅크는 오픈소스 DBMS인 MySQL을 도입해 관심을 끌고 있다. 보수적으로 접근하는 은행 업계에서는 이례적인 일로 받아들이는 모습이다.

그러는 것 같다(웃음). 인터넷은행은 채널계 시스템이 중단되면, 전 지점의 시스템이 중단된 거나 마찬가지이므로 시스템 무중단이 매우 중요하다. 일반은행보다 (채널계) 시스템 안정성을 더 강화해야 할 입장이었다. 그럼에도 기존 시중은행에서 적용하지 않던 오픈소스 DB를 선택한 이유에 대해 궁금해 하더라. 결론적으로는 비용을 절감하기 위해서다. (카카오뱅크는) 선발 은행들처럼 몇십 조원 단위의 거대 조직이 아니므로 카카오뱅크만의 방식대로 접근할 필요가 있었다. 이미 카카오에서 오픈소스 DBMS로 카카오페이나 결제 시스템 등을 구현해 잘 운영했던 경험이 있으므로 DBMS를 포함해 오픈소스 소프트웨어가 상용에 비해 덜 안정적이라고 생각하지 않았다. 오픈소스로 할 수 있는데 굳이 상용 DBMS를 쓸 필요가 있을까? 하는 생각에서 (MySQL을) 선택했다. 일시에 몰려드는 트래픽도 충분히 감당할 수 있다고 봤다.

상용 DB에서 강조하는 안정성을 어떻게 오픈소스 DB에서 확보했나.

상용 DB는 서버 장애에 대응한 몇 가지 기능을 제공한다. 그 중 일반적으로 쓰이는 게 RAC(Real Application Clusters)로, 이는 하나의 DB를 여러 서버가 공유하는 기술이다. 서버 한 대에서 장애가 나더라도 데이터 정합성을 유지하기 위해서다. 돈과 관련된 데이터를 처리하려면 데이터 정합성이 매우 중요하다. 반면 MySQL은 서버들이 하나의 DB를 공유하는 구조가 아닌, 마스터와 슬레이브 구조다. 마스터 서버에서 DB를 운영하면서 슬레이브 서버에 실시간으로 DB를 복제한다. 이때 마스터 서버에서 장애가 발생하면, 복제 데이터를 갖고 있는 슬레이브 서버에서 서비스를 이어받는 구조다. 문제는 마스터와 슬레이브 서버의 데이터가 완전 동기화되지 않을 수 있다는 점이다. 즉 마스터 서버에서 데이터가 생성돼 슬레이브 서버에 복제되기 전에 장애가 발생하면, 그 데이터는 유실 가능성이 있다는 것이 그동안의 통설이었다. 카카오뱅크는 이 문제를 해결함으로써 MySQL을 적용할 수 있었다. MHA(master high availability)와 LR(lossless replication)을 결합해 데이터 손실 없이 비동기 데이터 복제를 구현했다. LR은 마스터에서 변경 완료된 내역을 슬레이브 어딘가에 반드시 로그로 남겨주는 개선된 비동기 복제 기능이다. 즉 슬레이브 서버에서 마스터 서버의 데이터를 복제하기 전에 마스터 서버에서 장애가 나더라도 슬레이브 서버의 릴레이 로그를 활용해 마스터 서버와 똑같은 데이터를 생성할 수 있는 기능이다. MHA는 LR을 기반으로 신속히 데이터를 복구하는 역할을 한다.

DB 엔지니어의 영역이라 할 수 있는 DBMS 패치까지 내부 인력이 하는가.

상용 DBMS이든 MySQL이든 내부 인력으로 진행한다. 특히 MySQL의 경우 버그 패치나 수정은 MySQL 배포판을 공급한 퍼코나(Percona)에게 의뢰하고 있다. 내부적으로 패치하더라도 퍼코나의 검토 과정을 거치며, DB 운영부서에서 임의적으로 절대 수정하지 않는다.

카카오뱅크가 오픈한 지 반년이 다 되어간다. DB 담당자 입장에서 내부적으로 어떻게 평가하나.

성공적이라고 평가한다. 채널계 서비스의 DB는 모두 MySQL로 구현했는데도 오픈 이래 한 번의 장애도 없었다. 고객이 몰릴 것에 대비한 시나리오에 맞춰 시스템 자원을 단계적으로 늘려가면서 유연하게 대응하고 있다.

DB 관리도구들이 대부분 상용 DBMS에 맞춰져 있을 텐데 개발 시 어려움으로 작용하지 않았나.

질문한 대로 오픈소스 DBMS를 쓰면서 가장 어려웠던 점이 바로 관리도구였다. 현재 기존 금융권에서 주로 쓰는 서드파티 DB 관리툴은 모니터링 등 단순 업무에 적용하고 있다. 이는 기존 모니터링 솔루션의 기능이 문제가 되었기 때문이 아니다. 카카오뱅크 IT 시스템의 구조와 기존 관리 도구는 맞지 않았다. 카카오뱅크는 기본적으로 스케일아웃 관점에서 시스템을 구현했다. 다시 말하여 서버의 사양을 높이는 대신, 서버 대수를 단계적으로 늘리는 접근이므로 수많은 장비를 동시에 관리할 수 있어야 한다. 제한된 DB 인력으로 효율적으로 수많은 서버를 관리하려면 자동화 도구가 필수적이다. 기존 상용 관리도구에서 이런 부분까지 커버할 수 없었으므로 대부분 직접 개발했다.

이 정도라면 기존 시스템으로부터 탈피가 아닌가.

그렇게 볼 수도 있다. 개인적인 생각이지만, 금융권에서는 IT 엔지니어들을 단순 비용 측면에서 바라보는 경향이 있는 것 같다. 이에 대해 다시 한번 생각해 볼 필요가 있는데, 개발자들의 노고를 단순히 비용으로 인정하다 보니 개발자가 나이 들어 할 수 있는 일이라고는 치킨집 오픈이라는 말이 오가는 경우도 들었다. 그러나, 카카오뱅크는 IT 성격을 가진 인터넷은행이다 보니 기술자들의 의견을 중시하고 있어 이러한 부분이 카카오뱅크의 강점이라고 생각한다.

“해보고 싶은 게 있다면 무조건 질러라”

어떤 계기로 DBA가 되었나.

대학에서 컴퓨터공학을 전공했다. 한 인터넷 포탈사이트 개발업체에서 일했다. 장애가 많았던 서비스였다. 일단 잠을 자고 살아야 할 것 같아서 DB를 공부하기 시작했다. 마침 팀장이 DBA 출신이라서 그가 가이드 해 준 바를 토대로 DB 공부를 해서 매일 장애가 났던 시스템을 안정화할 수 있었다. 새로운 부사장이 오고 나서 DB 전담 조직을 만들면서부터 시스템이 매우 안정화가 됐다. 개발자별로 관리하던 DB를 전담 조직에서 하면서 분명한 틀이 잡혔다. 이때 내가 MySQL 환경의 개발 표준화 등을 담당했다. 그때를 계기로 DB 중에서도 MySQL 등 오픈소스 DB와 가까워졌다.

그 업체에서 나와 한 소셜 쇼핑몰에서 잠깐 근무하다가 2012년부터 카카오로 자리를 옮겼다. 2016년 초, 카카오뱅크 TF가 생기자 참여하다가 회사가 설립되자 5월에 옮겨왔다. 당초 카카오뱅크도 기존 은행들처럼 상용 DBMS만 쓸 거라고 생각해서 별 관심을 두지 않았지만, 오픈소스도 적용 대상으로 고려되고 있어서, TF 시절부터 카카오뱅크에 합류했다.

DB를 잘 하기 위한 별도 비법이 있었나.

내가 DB를 잘한다고 말하기는 조금 그렇다. 당장 주변만 해도 DB를 잘 하는 사람이 너무나 많다. 다만 기존과 다르게 한번 해보고 싶었다.

DBA 업무를 하면서 느끼는 점이라면.

프로그램 개발을 하다가 DB 업무를 하면서 변화는 더 넓게 바라보게 됐다는 점이다. 개발자와 시스템 관리자가 IT 서비스를 위해 일하는 것처럼, DBA도 IT 서비스를 책임진다는 측면에서는 동일하다. 데이터 흐름을 제어하기 위해 개발자는 개발을 하고, 시스템 관리자는 네트워크와 서버가 원활하게 돌아가도록 관리한다. 무엇보다 서비스 기준으로 보는 게 DBA의 매력이지 않나 싶다. 단점은 안 해도 되지만 끊임 없이 해야 하는 업무라는 점이다. 하지만 재미 있고 즐겁기에 지치지 않고 할 수 있다. DBA도 개발자도 시스템 엔지니어도 데이터 관점에서 IT 서비스가 원활하게 이뤄지도록 접근해야 한다. 요즘 내비게이션도 교통 상황 정보를 토대로 최적의 경로를 안내하듯이, IT 시스템도 내가 원하는 데이터를 뽑기 위한 최적의 경로, 즉 방안을 강구해야 한다. 쿼리를 날리면 결과가 어떻게든 결과가 나오겠지! 하는 관점에서 벗어나 해당 쿼리가 전체 시스템에 어떤 영향을 미칠지를 봐야 하지 않을까! 해당 쿼리가 서버 I/O와 네트워크 부하에 부담을 줄지를 예측해 보려고 하면 좋겠다는 생각을 한 적이 있다. 아직 배우고 있고 부족하기에 IT를 전체 시스템 차원에서 보려고 노력하고 있다.

DB 전문가 자격증이 있나. 더불어 DBA라면 향후 DA에 대해서도 관심을 갖고 있을 거 같다.

DB 관련 자격증은 하나도 없다. DA(data architect)에 대해 생각해 보았는데 데이터 표준화를 포함한 메타 데이터 영역보다는 견고한 시스템 아키텍처와 효율적인 데이터 관리 방안에 더 관심이 간다.

사회 초년생 개발자나 DB 분야로 진출하고 싶은 대학생들에게 하고 싶은 얘기는.

배우는 단계라면 ‘해보고 싶은 건 무조건 지르라’고 말하고 싶다. 알아야 할 것들이 넘치므로 현재 구현했다고 만족하지 말고 적용해 보고 싶은 것을 찾아서 어려움을 무릅쓰고 해보면 즐거움과 발전이 함께할 것이라고 본다. (끝)

출처 : 한국데이터진흥원

제공 : 데이터 전문가 지식포털 DBguide.net