[컴퓨터월드]

본 연재의 목적은 크게 두 가지였다. 현재 서비스 개발과 운영에 사용되는 기술을 소개하고, 그 구현에 있어 자바 기반의 스프링 기술이 어떻게 활용될 수 있는지에 대해 설명하고자 했다.

<그림1>은 얼마 전 황금연휴 때 국내 보험회사 서비스의 홈페이지 모습이다. 필자의 지인은 추석연휴동안 여행 관련 보험을 알아보고 또 필요하면 상품을 구매하고자 해당업체의 웹페이지를 방문했지만, 해당업체는 당연하다는 듯이 업무를 중단하고 있었다.

내용을 살펴보면, 시스템 성능 개선을 위해 홈페이지 서비스가 일시 중단되며, 일부 서비스는 다른 형태로 이용 가능하지만 나머지 모든 서비스는 이 수리가 끝나면 다시 찾아오라고 하고 있다. 서비스 중단 기간은 추석연휴 전체로 잡혀있는 것을 확인할 수 있다.

최근 컴퓨터를 사용한 서비스를 제공하는 업체에서 이런 식으로 전격적 서비스 다운타임을 가지며 업데이트하는 것은 찾아보기 힘든 일이다. 현재 미국에서는 4대 ‘신의 직장’이 있는데, 아마존, 페이스북, 구글, 그리고 넷플릭스가 바로 그들이다. 이들의 서비스 분야는 각각 다르지만, 다음 세 가지 공통점을 지녔다.

● 회사의 핵심 사업 모델이 컴퓨터 기반의 서비스를 통해 이뤄진다.
● 컴퓨터를 사용해 서비스를 만들고 다루는 기술이 (타의 추종을 불허할 만큼) 매우 뛰어나다.
● 시장에서 최고의 엔지니어를 찾기 위해 시간과 비용의 투자를 아끼지 않는다.

이 회사들의 서비스는 좀처럼 중단되지 않는다. 정기 업데이트도 없고, 차세대도 없다. 업데이트 이후에 서비스가 동작하지 않을까봐 미리 준비하는 롤백 계획서 같은 것들은 쓰지 않는다. 추석과 크리스마스, 새해와 같은 장기연휴나 명절은 이들 사업의 중요한 분수령으로, 절대 서비스를 중단할 생각도 하지 않는다. 만약 아마존이 블랙프라이데이에 서비스를 중단한다면 어떤 일이 벌어지겠는가.

이들의 서비스는 10분만 중단돼도 즉각 주가에 영향을 미친다. 뉴스에 나오고, 아마존에서 물건을 구매하지 못한 사람들의 불만 섞인 목소리가 수많은 언론에서 인용된다. 즉, 고객이 다운타임을 허용하지 않는다. 왜냐하면 이 회사들의 경쟁력은 바로 높은 기술력을 바탕으로 얻은 무중단 서비스, 그리고 이 무중단 상태에서도 지속적으로 서비스를 업데이트할 수 있는 능력이기 때문이다.

필자는 약 9년 전부터 아마존 쇼핑몰의 고객이었다. 이미 등록된 주소가 몇 개 있었는데, 재작년 즈음에 회사가 이사를 가게 돼 배송 받을 주소를 업데이트할 일이 있었다. 그런데 웬일인지, <그림2>와 같이 오류가 나면서 주소 입력이 안 되는 것이었다. 신규 주소 등록의 우편번호 부분에서 계속 오류가 나는데, 몇 번을 살펴봐도 뭐가 문제인지 모를 일이었다.

그렇게 수분을 씨름하다가, 이내 “5자리 ZIP코드(우편번호)를 넣으세요”라는 안내를 찾을 수 있었다. 미국의 배송대행지나 주소체계를 아는 이들이라면 익숙하겠지만, 5자리 집코드를 사용한다. 그래서 필자는 아마존이 더 이상 글로벌 배송을 하지 않기로 한 건지 의아해하며 그대로 창을 닫았다.

그리고 바로 다음날, 회사 주소가 바뀌었기 때문에 다시 다른 서비스에 주소 등록을 하려고 회사 우편번호를 검색해보니, ‘새 우편번호’라는 단어가 보였다. 뭔지 알아보려 우체국 페이지에 방문하니 <그림3>과 같이 안내돼있었다.

당시에는 6자리로 돼있는 구 우편번호가 검색되는 사이트가 더 많았기 때문에, 당장 5자리 우편번호를 복사해서 어제 실패한 아마존의 주소 업데이트 창에 넣어봤다. 그랬더니 한국 배송지 추가가 아무 문제없이 진행되는 것이었다. 놀랍기도 하고 궁금해져서 쇼핑몰, 포털, 금융 등등 국내 여러 유명 사이트를 돌아봤는데, 그 많은 곳들이 아직 업데이트되지 않은 상태였다. 갑자기 아마존이 대단하다는 생각이 드는 동시에 무서웠다.

아마 이 글을 읽고 있는 독자들은 ‘아마존 한국 진출’과 같은 뉴스를 한번이라도 접했던 이들이 많으리라 생각한다. 재미있는 사실은, 국내 고객이 아마존에서 구매하는 물건의 규모가 수천억 원을 상회한지 이미 오래이며, 아마존은 그런 한국 고객들을 이런 식으로 계속 확보하고 있다는 것이다. 아직 업데이트도 되지 않은 한국 서비스들보다 빨리 자사 서비스를 업데이트하는 형태로 말이다.

두 가지 사례를 살펴봤다. 국내 모 보험 페이지와 아마존의 서비스, 이 서비스들의 중단과 무중단이 고객에 미치는 영향, 그리고 고객이 갖는 신뢰에 영향을 미치는 부분도 함께 생각해볼 수 있다. 다른 서비스들도 마찬가지다. 주말에 넷플릭스가 다운된다면? 아마 계획에 없는 외출을 감행하는 사람들이 늘어날 것이다. 넷플릭스의 주말 트래픽은 미국 전체의 2/3를 차지할 정도로 많다.

여러 요인들이 많지만, 우리나라의 수많은 서비스들은 왜 이런 업데이트를 수행하는 게 어려울까. 그 해답은 의외로 간단하다. 기존에 구성하던 방식의 서비스 시스템에 대한 업데이트와 다운타임의 상관관계 때문이다.

모든 기능이 거대한 코드베이스에서 다시 거대한 데이터베이스(DB)의 복잡한 로직을 참조하고 있는 형태에서, 업데이트란 공포 그 자체다. 공포란 바로 ‘서비스 다운’이다. 이 복잡계에서 서비스 다운은 매우 다양한 원인으로 발생할 수 있기 때문에, 이를 방지하려는 수많은 단계들이 존재한다.

QA팀은 ‘충분히 테스트되지 않아 서비스가 다운됐다’는 책임을 지는 것을 원하지 않는다. 개발팀은 ‘코드가 잘못돼 서비스가 중단됐다’는 말을 듣기 싫어한다. 운영팀은 ‘배포를 잘못해서’, ‘서비스에 필요한 자원이 충분히 준비돼있지 않아서’라는 이유로 책임지게 되는 것을 싫어한다.

복잡계 시스템은 모두가 책임지기 싫어하는 구조 속에 수많은 기능이 담겨 한꺼번에 돌아가고 있으며, 이로 인해 업데이트로부터 보호받게 된다. 문제는 업데이트 없이 서비스 개선이나 보안 패치가 이뤄질 수 없다는 점이다. 경영진이나 고객이 원해서 추가한 새로운 기능들도 필요한 시점에 업데이트될 수 없다.

개인적으로 아이러니하다고 여기는 부분인데, 빠른 기능 개발을 위해 테스트코드를 넣을 수는 없지만, 그렇게 ‘빠르게’ 개발된 코드의 업데이트 수행이 언제 되냐면 바로 서비스를 중단해도 된다는 공감대가 형성된 ‘명절’이다. 그래서 6개월에 한 번, 즉 추석과 설날에 한 번씩 진행하는 업데이트를 위해, 테스트코드 없는 프로덕션코드를 수백 명이 수천만 줄 속에서 DB의 스토어드프로시져 및 ERD(개체-관계 다이어그램)와 싸워야 하는 현실을 만들어낸다.

업데이트와 다운타임의 상관관계, 즉 잦은 업데이트는 잦은 다운타임을 가져올 것이라는 경험적 불안으로 인해, 업타임을 늘리기 위해서는 업데이트를 막아야 한다는 슬픈 현실이 바로 우리나라에 존재하는 대부분 서비스의 현주소인 것이다. 같은 맥락에서, 보안 담당자를 만나면 꼭 물어보는 것이 있다. “마지막 CVE 업데이트는 언제였습니까?” 또는 “마지막 윈도우 서버 업데이트는 언제였습니까?”

IPS나 IDS 설치 같은 것으로 완성되는 게 보안이 아닐 텐데, 당장 서비스에 대한 인증서 롤링 업데이트에 대한 방법조차 구비되지 않은 조직에서, 그리고 업데이트로 인한 다운타임을 걱정하는 조직에서 CVE 업데이트를 수행했을 리 없다. 하물며 Java 6·7 또는 닷넷 프레임워크 3.x 이런 것들을 사용하고 있는데 보안성이 웬 말이랴.

이러한 문제들은 현업에서 현재, 그리고 오늘도 만들고 있는 신규 서비스에서 발생하고 있다. 오늘날 대부분의 회사가 만들고 있는 서비스들도 이렇게 업데이트가 힘든 형태로 만들어지고 있다고 감히 장담할 수 있다. 만드는 시점에 이미 보안에 취약하고, 업데이트에 취약한 상태로 만들어진다.

우리는 금융이라, 제조라, 특정 분야라 다르다는 생각은 더 이상 통용되지 않는다. 최근의 GE 디지털트윈(Digital Twin)과 같은 서비스를 본 일이 있는가. 최근 JP모건이나 씨티, 웰스파고와 같은 회사들이 무엇을 하고 있는지 들어본 일 있는가. ‘디지털 트랜스포메이션’이나 ‘4차 산업혁명’이라는 말을 사용하는 사람들이 정말 많은데, 물어보면 아무도 명확한 답을 주지 못한다. 그게 대체 무엇인가.

● 첫째, 현대의 모든 산업 또는 사업의 핵심은 SW와 데이터 기술이 결합되지 않으면 경쟁력을 잃기 쉽다.
● 둘째, 하지만 대부분의 대형 기업들은 자사의 사업 핵심을 위해 SW를 사용하지 않았다. 즉, 핵심 역량 기술이 아니었으므로 그동안 주로 외주를 주고 있었다.
● 셋째, 따라서 그동안 외주를 통해 진행했던 ‘서포트’ 역할의 IT가 아니라, 사업의 핵심을 전산 기술로 통합하는 게 매우 중요하다. 이것을 수행할 수 있는 팀, 기술, 프로세스, 그리고 문화를 확보하려는 것이 바로 디지털 트랜스포메이션이며, 이를 통해 확보된 경쟁력의 발현이 4차 산업혁명의 핵심이라 볼 수 있다.

보험회사라고 해서 사용자들이 서비스 다운타임을 겪어도 이해해주진 않는다. 아마 ‘페이스북은 잘만 돌아가는데 여기 앱은 왜 이래’ 식으로 생각할 것이다. 서비스 정기점검으로 인한 다운타임은 더 이상 고객들이 용인해주지 않는 사유가 된다. 예기치 않은 중지나 실패야 납득할 만한 사유가 있다면 문제가 없겠지만, ‘정기점검’은 더 이상 아니라는 것이다. 그것도 명절에.

현대 클라우드 기반 서비스는 개발자들의 구현 없이는 그저 레거시 구현 패턴의 반복일 뿐이다. 개발자나 개발팀, 개발 리드가 알고 공부하는 만큼 서비스가 좋아진다. 인메모리 데이터그리드를 사용하면 DB의 오프로딩에 매우 좋겠지만, 개발팀이 오라클 사용방법만 알고 있다면 그 회사는 계속 오라클만 사용할 수밖에 없는 서비스가 만들어질 것이다. 같은 맥락에서, 자바/스프링 개발자들에게 스프링 부트, 스프링 클라우드, 그리고 이것과 연계된 다양한 데이터 저장·사용방식에 대한 이해는 서비스 구현에 굉장한 유연성을 제공할 것이다.

필자는 본 연재를 정리하며, 다음과 같은 내용을 강조하고자 한다.

● 디지털 트랜스포메이션이란 사업의 핵심 도메인과 전산의 결합을 의미한다. 즉, 아웃소싱했던 전산을 인소싱해야 한다는 의미다.
● 하지만 실전된 무림비급에 적힌 구양진공을 아는 이가 많지 않으면 우리 문파에서 가르칠 수 없는 것과 마찬가지로, 그동안 아웃소싱으로 90년대 기술만을 사용해 전산을 이용했던 기업들이 여기에 어려움을 겪는 것도 당연한 일이다.
● 지금 사용되고 있는 개발, 테스트, 배포, 피드백의 방법은 기존 회사에서 사용해온 프로세스와는 완전히 다른 것이다. 따라서 이 프로세스 문제 때문에 실패할 확률이 높을 것이다.
● 지금은 업데이트를 하면서 다운타임을 갖지 않는 방법이 있다. 거꾸로 말하면, 다운타임 없이 업데이트할 수 있는 세상이 됐다.

필자는 피보탈이라는 회사에서 근무하고 있다. 애자일, TDD(테스트주도개발), BDD(행위주도개발) 등과 같은 개발 관련 프로세스와 문화 등을 실현하고 있는 글로벌 기업이다. 즉, 개발에서 배포 이후, 피드백을 받는 것 까지를 ‘애자일’이라고 하는 것이다. 개발방법‘론’이라는 말은 그저 서류에 적는 말일 뿐이다.

다시 말해, 코드를 써야 하는 기능의 정의와 어떻게 코드를 쓸 것인가에 대한 정리부터, 실제로 코드를 쓰는 방법, 테스트를 하는 방법, 그리고 빌드 이후 특정 버전의 프로덕션 코드를 업데이트하는 방법에 대해 프로세스와 도구를 보유하고 있다. 수많은 도구들 가운데 무엇을 선택할지 어려움을 겪을 수 있는데, 피보탈은 이에 대해 의견을 제시해줄 수 있는 곳이다. 다양한 도구를 사용해보고, 수많은 오픈소스 코드를 생산해본 경험을 바탕으로 기존에 없는 도구들을 만들어왔다. <그림4>가 바로 그 파이프라인이다.

아이디어가 있다면 이 아이디어를 어딘가에 코드화할 수 있도록 적어야 한다. 아이디어를 구현할 때 우리는 반드시 테스트코드를 함께 작성한다. TDD로 주로 알려진 이 방법은 기능을 하는 코드를 작성하면 반드시 그 기능을 검증하는 테스트코드를 함께 작성하도록 요구한다.

‘페어프로그래밍’ 모델을 사용하고 있는 피보탈에서는 코드리뷰 시간이 따로 없다. 우리의 경험에서 코드리뷰란, 5줄의 신규코드가 있으면 여기저기서 이의를 제기하지만, 500줄의 신규코드가 있으면 괜찮은 거 같다면서 넘어가는 일이었다. 일이 많아지면 소홀해지기 쉬운 유형의 작업이라는 것이다.

따라서 우리는 이 중요한 코드리뷰 과정을 특정 시간에 국한시키는 게 아니라, 코드가 작성되는 100%의 시간 내내 코드리뷰가 되도록 구성했다. 페어프로그래밍이란, 두 명이 동일한 모니터를 보면서 테스트코드와 작성되는 코드를 함께 보는 것이다. 이를 통해 우리의 코드품질은 매우 높아지게 됐으며, 어떤 문제를 해결하기 위해 회사에서 ‘학습’하는 시간을 획기적으로 줄일 수 있었다.

그렇게 테스트코드와 함께 작성된 코드는 자동화된 테스트 도구에 들어간다. <그림4>에서는 선풍기 모양으로 표현됐다. 컨코스(Concourse)라고 불리는 이 도구의 역할은, 코드 형상관리소에 새로운 코드가 들어오면 팀에서 지정한 테스트를 자동으로 수행하는 것이다. 이는 매번 새로운 코드가 들어올 때마다 수행되며, 문제없이 수행됐을 경우에만 다음 단계로 진행하는 구조를 가진다.

<그림5>와 같이, 여기서 만약 붉은색이 보였다면 매우 좋은 일이다. 왜냐하면 어떤 문제가 실제 서비스에 반영되기 전에 발견됐다는 것을 의미하기 때문이다. 실제코드에 테스트코드를 붙이는 것은 처음에는 오버헤드가 있을지 모르겠지만, 나중에 프로젝트가 커져 코드베이스가 함께 커진 경우에도 처음 프로젝트를 시작했을 때 속도를 유지할 수 있도록 도와주는 방법이다.

예를 들어 천만줄짜리 서비스 코드가 테스트코드 없이 작성됐다면, 이는 아마 지옥 그 자체일 것이다. 어떤 기능이 어디서 반영됐는지 알아내기 위해 수많은 사람에게 메일과 질의가 필요할 것이며, 기능 추가를 위한 DB 컬럼 변경은 아마도 서브 프로젝트 단위의 거대 일감이 될 지도 모른다. ‘페이스북 연동’과 같은 간단한 기능 추가를 위해 어떤 회사는 40분이면 될 일을 4개월 동안 진행해야 한다는 의미가 되는 것이다.

이런 방식으로 개발되고 테스트된 코드는 배포돼야 한다. ‘다운 타임 없는 배포’ 중 일부는 여기서 이뤄진다. 대부분의 회사에서 개발·테스트·실제서비스용 하드웨어를 각각 보유하는 것은 매우 힘든 일이다. 그래서 클라우드 시대 이전에서는 서비스에 개발로 사용하던 하드웨어들이 거의 대부분 그대로 프로덕션이 됐다. 신규 개발과 서비스 코드가 프로덕션에서 수행되는 굉장한 일들을 우리 개발자들이 해온 것이다. 이 부분에 있어, 필자는 12팩터(https://12factor.net/ko/)를 마치 애자일 선언문처럼 읽어보는 것을 권고한다.

아무튼 서비스에 신규 코드의 반복 배포는 항상 일어나는 일이다. 이렇게 항상 일어나는 일에 사람이 관여하는 것은 매우 비효율적인 일이기도 하다. 비효율적일 뿐만 아니라, 배포의 횟수가 일정 수준을 넘어가기 시작하면 사람이 하는 것이 불가능해지기도 한다. 아마존은 지난 2011년 발표한 자료에서 14초에 1번씩 프로덕션 배포를 한다고 했다. 당장 지금 일하고 있는 회사에서 1분에 한번 꼴로 배포가 수행된다면 어떤 일이 벌어질지 생각해보라.

어떤 이들은 우리 서비스에 그리 많은 배포는 필요 없다고 말한다. 그러나 실제로 배포가 많이 필요하지 않은 경우는 없다. 어떤 문제로 하고 있지 않을 뿐이지, 할 수 있다면 얼마든지 많은 요청이 사업부와 다른 조직에서 발생할 수 있다. 그리고 전체 기업의 입장에서, 하나의 단일 서비스 업데이트는 하루에 몇 회일 수 있지만, 전체 서비스 업데이트는 수천 회일 수도 있다. 이게 자동화되지 않은 경우의 비효율은 상상할 수도 없다.

넷플릭스의 시니어엔지니어가 한 말이 있다. 우리는 밥을 먹고 의식적으로 ‘소화를 해야지’ 또는 ‘이제 소화된 음식을 소장을 거쳐 대장으로 보내야지’라고 생각하지 않는다. 이런 것들은 무의식 속에서 자동으로 이뤄지는 일들이다. 그리고 이런 방식으로 ‘이미 알려진’ 배포를 수행해야 한다는 것이다.

신규 버전이 있고, 이를 서버에 업로드하고, 밸런서나 도메인을 조정하고, 문제가 없으면 기존 버전을 제거하고, 새로운 버전을 사용하고, 문제가 있으면 기존 버전으로 돌아가는 이런 동작들은 [그림4]에서 클라우드 파운드리가 담당하는 부분이다. 그 외에 개발자 및 서비스에 필요한 다양한 데이터 도구나 APM(앱성능관리)과 같은 외부 도구들, 에이전트의 설치와 같은 부분을 개발자가 신경 쓰지 않아도 되게 해주며, 개발팀이 다시 운영팀에 요청해 리소스를 준비해야 하는 비효율을 줄여준다. 구글, 아마존, 마이크로소프트(MS), VM웨어, 오픈스택에서 동작한다.

문제없이 지속적으로 업데이트되며 배포됐다면? 다음은 바로 로깅이다. 애플리케이션 및 애플리케이션이 사용하는 저장소에 적재된 다양한 데이터는 서비스 개선을 위해 사용된다. 그린플럼은 현재 오픈소스로도 존재하며, 매드립(MADLib)과 같은 쿼리 기반 머신러닝 도구도 붙일 수 있는 MPP(대량병렬처리) DW(데이터웨어하우스) 도구다. 이 도구들은 스프링부터 ‘오픈소스’로 존재한다. 먼저 도커(Docker)와 같은 도구를 통해 각각의 사용성과 서로 연계했을 경우에 대해 살펴보고, 원하면 프로덕션 레벨로 확장하면 된다. 만약 이것이 힘든 엔터프라이즈나 지원이 필요하다면 피보탈로 연락하면 된다.

여기까지 설명한 과정들은 다음의 내용들을 포함하는 것이다.

● 애자일(Agile)/린(Lean), TDD
● 지속적 통합(Continuous Integration)
● 지속적 배포/전달(Continuous Deploy/Delivery)
● 클라우드 기반(Cloud Native)
● 데이터(Data)

본 연재에서는 기본적으로 넷플릭스의 오픈소스를 사용한 마이크로서비스 구조에 대해 주로 언급하고, 그 구현 방법과 사유를 설명했다. 그리고 이 최종회에서는 그 외 다른 부분들에 대해 추가적으로 언급해 전체적인 뷰를 제공하고자 했다.

필자는 국내 모든 서비스들의 품질이 페이스북이나 구글 수준이 되면 참 좋겠다고 생각한다. 아름다운 UI(사용자인터페이스)와, 내가 원하는 기능, 그리고 다른 누군가가 원했을법한 기능이 항상 추가되고, 나를 포함한 많은 사람들의 개인정보가 안전하게 관리되며, 한번 시작한 서비스는 공식적 폐쇄가 발표되기 전에 가급적이면 멈추지 않는 그런 서비스 말이다.

클라우드 시대 이후로 많은 이들이 마치 클라우드가 모든 것인 양 말하고 있지만, 사실 더 중요한 것은 애플리케이션을 만드는 방법을 바꾸는 것이다. 아직 많은 회사들이 이 영역에 미치지 못하고 있는 것으로 보인다. 이게 바로 우리가 매일 접하는 국내 서비스들의 안타까운 품질로 이어지고 있다.

이번 연재를 통해 이런 부분들의 개선을 위한 ‘제로 다운타임 업데이트’ 체계를 확보할 수 있는 신규 프로세스와 기술, 그리고 문화의 도입에 대해 생각해볼 수 있기를 기대한다. 모든 이가 모든 것을 배우기 쉬워진 클라우드 시대, 우리 서비스에 필요한 핵심 구현을 어떻게 빨리, 그리고 다운타임 없이 서비스할 수 있는지 살펴보고 아이디어를 얻을 수 있었기를 바란다.