레저큐 인턴기 5편 – 백엔드 개발 도전기 (1)

신이라면 믿겠지만 아니라면 데이터를 가져와야 합니다.

인터넷에서는 사용자의 결정과 행동을 추적하여 누적해두고 의미 있는 정보로 ‘데이터화’하는 것이 가능하다. 그리고 이런 데이터는 웹 쇼핑몰이라는 가상의 매장을 만들어놓고 상품을 판매하는 이커머스 서비스에게는 매우 강력한 무기가 된다. 웹사이트에서 어떤 사용자 경험성(UX, User Experience)을 제공할지, 어떤 상품을 노출할지, 어떤 가격으로 판매할지 등을 결정할 때 사용자의 구매 패턴과 행동 데이터들을 이용할 수 있고, 이를 통해 서비스의 매출을 극대화 시킬 수 있기 때문이다.

데이터를 기반으로 이커머스 서비스는 어떤 유저에게, 어떤 상품을, 어떤 가격으로(논쟁거리가 되기도 한다!) 노출할지 개인화할 수 있어서, 경제학에서 말하는 이상적인 판매 전략을 실현하여 큰 이익을 낼 수 있다. 따라서 데이터화와 분석은 이커머스가 기존의 상거래 시스템과 차별화되는 가장 주목할만한 요소 중 하나이며 기업의 성장과 직결되는 문제이다.

bigdata
빅데이터! 빅데이터! 빅데이터! 인터넷 세계에서 유저들이 만들어 내는 수많은 데이터들을 수집하고 잘 분석하는 것은 이제 이커머스 서비스에 필수적인 역량이 되었다. (이미지 출처 : LinkedIn post by Amarnath K Mattad)

이커머스 서비스는 사용자의 구매 패턴과 행동을 통계내고 분석하는 툴 혹은 시스템을 잘 구축해야 한다. 물론 사용자와의 인터랙션을 추적하는데 이용하는 Google Analytics과 같은 툴들도 훌륭하긴 하지만 아무래도 DB에서 가져오는 통계보다는 훨씬 부정확하고, 이커머스 운영의 의사결정에 활용하기 위한 정보들을 얻기에는 기능이 부족하다.

가자고 개발팀은 얼마 전부터 엘라스틱서치라는 검색엔진/데이터 저장소를 이용해서 매출과 실시간 판매 데이터등을 통계내고 비주얼라이제이션 하는 시스템을 구축하고 있다. 하지만 서비스 초창기에는 실시간으로 서비스 데이터를 수집하고 분석하는 시스템을 구축할 시간이 없었다. 대신 필요한 데이터가 있을 때 마다 SQL(Structured Query Language)코드로 직접 데이터베이스(DB)에서 판매 데이터나 매출 정보들을 긁어오는 ‘노동집약적인 방식'(^^;)으로 데이터를 수집하고 분석했다.

SQL
SQL은 관계형 데이터베이스 시스템을 관리하고, 조건에 맞는 데이터를 질의(Query) 하는데 이용되는 표준 언어이다.

나의 첫 백엔드 개발

나같은 새내기 개발자에게는 이런 작업이 좋은 기회가 될 수도 있다. DB에서 원하는 데이터를 가져오는 작업을 통해 시스템과 DB의 구조에 대해서 파악할 수 있었기 때문이다. 이커머스 서비스는 DB의 구조와 관계가 매우 복잡한데, 원하는 데이터를 얻기 위해서 어떻게 SQL 쿼리를 짤지 고민하는 것이 이 구조를 이해하는데 좋은 연습이 된다.

하지만 며칠이 지나자 통계를 얻기 위해서 SQL을 짜고, DB에 쿼리를 날리고, 얻어낸 데이터를 다시 스프레드시트에 정리하는 반복적인 작업들이 귀찮아지기 시작했다. 조금씩 조건이 바뀔 뿐, 매일 같이 반복적인 작업을 하는 것일 뿐인데, 수작업으로 SQL을 작성하고, 쿼리를 날리고, 데이터를 스프레드시트 포맷에 정리하는 일련의 일들이 생각보다 훨씬 번거롭고 지루했던 것이다.

이걸 자동화 할 수 있는 방법은 없을까? 당연히 있다. 가자고 백엔드 어플리케이션에 아예 이 통계를 내주는 기능을 추가하고 API를 만들어서 관리자 사이트에서 필요한 데이터의 종류와 검색 조건을 입력하면 해당하는 데이터를 엑셀로 정리해서 다운받을 수 있게 하면 된다.

자, 그렇다면 이제 드디어 첫 백엔드 개발을 시작할 때가 되었다. 일찍이 난무하는 자바 어노테이션(Java Annotation)들과 복잡한 구조에 기죽어서 포기했었던 백엔드 개발에 다시 도전하게 된 것이다.

그 첫번째 미션은 바로 입력한 조건에 따라 DB에서 서비스 운영에 필요한 통계자료를 추출하는 웹 API를 새로 만들기!

백엔드와 프론트엔드

여기서 잠깐 백엔드(Back-end)나 프론트엔드(Front-end)라는 용어를 정리하고 넘어가자. 위키피디아에 따르면 백엔드와 프론트엔드는 이렇게 정의되어 있다.

In software engineering, front end and back end distinguish between the separation of concerns between the presentation layer (the front end) – which is the interface between the user – and the data access layer (the back end). The front and back ends may be distributed among one or more systems.

갓 위키피디아 님에 따르면, 어플리케이션에서 엔드 유저의 눈에 보이지 않는 쪽을 백엔드(back end), 반대로 웹 브라우저 등을 통해서 유저에게 보여지는 쪽을 프론트엔드(front end)라고 한단다. 즉, 브라우저에서 유저와 인터랙션 하는 웹사이트의 UI를 구현하는 것은 프론트엔드 개발이고, 그 UI에 데이터를 뿌려주고, 사용자의 요청을 받아 비지니스 로직대로 처리할 수 있도록 구현하는 것은 백엔드 개발이라고 할 수 있다.

프론트엔드 개발자는 JavaScript, HTML, CSS 등을 이용해서 사용자 친화적인 UI(User Interface)를 구성하는데 주안점을 둔다. 반면에 백엔드 개발자는 사용하는 웹 프레임워크에 따라 Java(Spring, Spark…) 혹은 Python(Django, Flask …) 혹은 JavaScript(NodeJS) 혹은 Ruby(Ruby on Rails)를 이용해서 개발한다. 백엔드 개발자들이 가장 중요하게 생각하는 것은 웹 어플리케이션의 성능과 안정성, 그리고 아키텍쳐이다.

최근엔 백엔드, 프론트엔드, DB 관리, 서버 관리 등 웹 개발에 필요한 기술 전반을 모두 다룰 수 있는 풀스택 개발자(Full-stack developer)들도 시장에서 각광을 받고 있지만, 스타트업의 개발자들은 보통 백엔드 개발 전문 혹은 프론트엔드 개발 전문으로 역할을 나눈다. 백엔드 개발과 프론트엔드 개발은 요구하는 기술이 다르고 초점을 맞추는 것도 다르기 때문에 철저히 전문화된 개발자를 필요로 하기 때문이다.

web dev
웹 개발자들에게 요구되는 기술들. 보통은 한 명의 개발자가 이 모든 것을 다 하기 쉽지 않기 때문에 프론트엔드 개발, 백엔드 개발로 역할을 나누고는 한다. 좀 더 자세히 알고 싶다면 Michael Wales가 Udacity 블로그에 쓴 3 Web Dev Careers Decoded: Front-End vs Back-End vs Full Stack을 참조하자.

가자고는 8명의 개발자가 함께 개발하고 있는데 프론트엔드에 치중하는 개발자가 2명, 백엔드에 치중하는 개발자가 4명, 그리고 그 모두를 개발하고 있는 풀스택 개발자가 1명 있다.

나머지 1명인 나의 역할? 어디에도 속하지 않지만 어디에도 속할 수 있으니 풀스택 개발자라고 치자. ^^

백엔드 개발하기

백엔드 어플리케이션은 서버에서 데이터를 비지니스 로직대로 처리하고 처리한 데이터를 웹 API(Application Program Interface)를 통해 제공하는 역할을 한다. 프론트엔드 개발자들이 우리 눈에 보이는 UI 껍데기를 만들어 놓으면 백엔드 개발자가 개발한 API로 데이터와 리소스들을 불러와서 뿌려주는 것이다.

가자고는 백엔드 프레임워크로 스프링 프레임워크 (Spring Framework)를 쓴다. 스프링은 Java 진영에서 가장 널리 쓰이는 오픈소스 웹 어플리케이션 프레임워크이다. 엔터프라이즈 용으로 개발된 웹 프레임워크이기 때문에 방대하고 기능이 매우 다양하며 유지보수가 쉬운 (쉽나…?) 프레임워크이다. 다만 방대하고 기능이 많은 만큼 진입장벽이 높고, 배우기 어려운 프레임워크이기도 하다.

spring_framework
스프링 프레임워크는 이제는 사실상 Java진영의 엔터프라이즈급 표준 웹 어플리케이션 프레임워크가 되었다. 무엇이든지 할 수 있는 스위스칼 같은 존재랄까…

가자고는 일반적으로 웹 어플리케이션에 적용되는 MVC 디자인 패턴에 따라서 어플리케이션을 뷰(View), 컨트롤러(Controller), 모델(Model)로 나눠서 개발을 하고 있다. 각 컴포넌트들의 역할을 정리해보면…

  • 모델: 관계형 DB에서의 테이블에 대응되는 개념이다. 즉 데이터 스키마라고 볼 수 있다.
  • 뷰: 브라우저를 통해서 유저의 눈에 보이는 UI를 구현한 소스코드와 그 컨테이너에 해당한다.
  • 컨트롤러: 유저의 요청사항(request)를 받아 데이터를 의뢰하고, 가공 후 웹 API의 형태로 돌려준다(response).

뷰가 프론트엔드(JSP, JS, HTML, CSS 등에 해당)에 해당한다고 하면 컨트롤러와 모델이 백엔드에 해당하는 컴포넌트이다. 따라서 웹 API를 만들기 위해서는 처리하고자 하는 데이터들의 스키마(설계도 혹은 틀 쯤으로 생각할 수 있다)를 모델로 정의 및 구현하고, 컨트롤러에서 요청을 받아 비지니스 로직대로 처리하여 돌려 줄 수 있어야 한다.

다만 가자고에서는 (일반적인 웹 어플리케이션들이 그렇듯이) 컨트롤러의 역할을 서비스(Service: 비지니스 로직을 구현한 부분. 추상화된 ‘모델’을 이용하여 이를 가공하고 컨트롤러에 돌려준다.), 리포지토리(Repository: DB와의 인터페이스를 담당한다. ‘모델’의 추상화를 담당하는 부분이다.) 등의 여러개의 레이어로 나누어 개발하고 있다. 이런 구조를 레이어드 아키텍쳐(Layered architecture) 라고 부른다….

mvc_pattern
MVC 패턴의 개념도. (이미지 출처: 구루비 위키)

spring_layered_archtecture
스프링 프레임워크의 레이어드 아키텍쳐. (이미지 출처: petrikainulainen.net)

아, 새로운 용어들이 나오니까 벌써 머리가 아파온다. 자세한 내용은 생략하자… 다음에 좀 더 자세히 얘기할 기회가 있을 것 같다. 여튼 백엔드 개발은 이렇게 복잡한 디자인과 구조, 그리고 웹을 이루는 기반 기술들에 대한 이해를 요구하는 작업이다. 하지만 (이 무렵의) 나에게 이러한 지식과 이해 따위가 있었을리 없다. 그래서…

일단 만들고 보자

그 많은 지식들과 기반 기술들에 대해서 습득할 시간도 없고, 방대한 개발 문서들을 읽을 수도 없다. 숙련된 개발자는 새로운 프레임워크나 라이브러리들을 익히기 위해서 개발문서를 차분히 읽어보면서 기능과 개념을 공부하겠지만 나와 같은 새내기 개발자에겐 아무리 잘 쓰여진 개발문서도 “흰것은 종이요 검은 것은 글자” 일 뿐이다. ‘내가 무엇을 아는지, 무엇을 모르는지’ 전혀 모르는 상태이기 때문이다.

그래서 일단 만들고 싶은 것을 땅바닥에 헤딩해가며 만들어보기로 했다. 그러다 보면 내가 무엇을 공부해야 하는지, 개발 문서에 잔뜩 써져 있는 외계어들이 무엇을 의미하는 것인지도 점점 알게 될 것이다. 다행히 이미 가자고 팀 개발자들이 짜놓은 API 코드가 아주 많으니 참고할 코드도 충분하다.

시작부터 험난하지만 이렇게 나의 첫 백엔드 개발이 시작되었다. 구체적으로 어떻게 했는지 계속 이어서 쓰고 싶지만 이미 충분히 길어졌으니 아 힘들다… 좋은 글귀를 남겨놓고 이번 편을 마무리하자. 다음편에서 계속…

정신적인 존재로서 드넓은 물을 향해 가자.
너는 거기에서 종횡무진으로 살아가며,
마음대로 움직이리라.

요한 볼프강 폰 괴테, “파우스트” 중

By EastskyKang