AWS를 학습하고 서비스를 빠르게 배포해보자

프로젝트 계기

(AWS) 데이터센터가 있는 IDC 환경에서 이미 구축된 시스템을 운영해보거나 클라우드 서비스를 사용하더라도 거대하지 않은 플랫폼에 간단한 3-tier 구조의 시스템을 구축해 본 경험 밖에 없었다. 새로운 서비스를 개발해야 할 때 비용 및 속도를 생각하면 클라우드 컴퓨팅 서비스를 이용하는 게 당연하다. 그래서 클라우드 컴퓨팅 서비스 학습의 필요성을 느꼈고, 스타트업과 신규 서비스에 맞는 강점(온디맨드, 엘라스틱)이 있고 가장 거대한 서비스인 AWS를 경험하기로 했다.

 

(해외여행) 부모님 세대가 아닌 많은 사람들이 해외여행을 쉽게 계획하고 방문한다. 유튜브나 블로그, 검색만 해도 많은 후기들이 있기 때문이다. 하지만 그런 검색을 통해 가는 여행은 비슷한 패턴 뿐이다. 우리나라를 예시로 들면 남산이나 광화문처럼 대표 관광지를 방문하고 핫플레이스에 가서 맛있는 식사를 하는 것을 들 수 있다.

이러한 여행은 몇 번이고 다시 가라고 하면 굳이 싶은 여행이다.

게다가, 여행 관련 컨텐츠를 선택한 이유는 생각보다 많은 사람들이 여행업을 간과하고 있을거라 생각했다. 나 또한 그랬다. 왜냐하면 직접 항공편 예약하고 호텔스컴바인같은 사이트에서 숙소 잡고 액티비티 따로 예약하고 스스로 다 할 수 있는데 왜 굳이 더 돈을 주고 여행을 가야 하는지 생각할 수 있기 때문이다.

하지만 스스로 찾아보고 가는 여행에는 한계(관광버스 예약같은 단체 여행의 편리함, 다향한 컨텐츠 등)가 있다. 모두투어, 하나투어 같은 대형 관광업 말고도 중소기업에서 운영하는 여행사가 엄청나게 생각 이상으로 많다. 그리고 생각 이상의 매출과 마진이 발생한다. 왜냐하면 대게 돈에 여유가 있는 중장년층이 이러한 여행사를 많이 찾기도 하고 편리한 여행 제공과 맞춤형 컨텐츠(트래킹, 온천 등) 구성이 좀 더 돈을 지불하더라도 합당하다고 느끼기 때문이다. 여행 상품들을 잘 살펴보면 생각 이상으로 컨텐츠가 좋다.

 

학습 목표

간단하게 기획한 신규 서비스를 AWS 인프라 구축 + 타임리프와 HTMX를 이용한 서버 사이드 렌더링 개발 방식을 통해 저렴하고 빠르게 배포한다.

프로젝트를 통해 바라는 점

이러한 여행 상품은 인터넷에 검색한다고 찾기 매우 어렵다. 왜냐하면 이런 상품 대부분은 네이버 카페를 통해 기존 고객들에게 알리기 때문이다. 한 번 방문했던 고객이라면 카카오톡 채널이라던지, 문자로 신규 상품에 대한 안내를 받을 수 있지만, 이외에는 지인을 통해 알게 되는 것 말고는 사실상 방법이 거의 없기 때문이다.

네카라쿠배당토와 같은 IT 대기업에서는 기술 블로그를 별도로 관리하고 운영하는데, 이러한 글들을 모아서 보여주는 사이트를 자주 이용하곤 했다. 그래서 이러한 방식으로 좀 더 다양하고 재밌는 여행 컨텐츠가 많다는 것을 공유하고 싶었다. 

프로젝트를 통해 배운 점

(AWS)

가상의 네트워크 망을 구축해보면서 실제 네트워크 구조를 간접적으로 느낄 수 있었다.

특히, 여기서 사용하지 않았지만 AWS의 Role 개념에서 스프링의 의존성 주입의 느낌을 받을 수 있었다. 보안 그룹을 설정할 때, 규칙을 하나하나 추가하는 게 아니라, 규칙A에 규칙B을 추가하는 방식을 사용해 봤는데 정말 괜찮은 방식 같다.

만약 규칙A의 변경이 필요할 때, 규칙B를 갈아끼면 되는 것이고 만약 규칙B가 다양한 규칙으로 사용돼고 있어도 규칙B만 수정해도 전부 다 수정돼기 때문에 정말 용이한 것 같다.   

 

그리고 사실 로드 밸런서를 구성할 생각은 전혀 없었는데, Route 53에서 도메인을 구축하고 나니 HTTPS 통신을 하려면 ALB를 구성해야만 했다. 초반엔 생각지도 못해서 그냥 '후이즈'나 '가비아'에서 도메인을 구입해서 NGINX에 설정할 걸 하고 후회했다. 그런데 해보고 나니까 이 방식이 더 편한 것 같다.

 

(해외여행)

모바일 (반응형)

웹 브라우저

업력이 길어 만 개 이상의 데이터가 있을 줄 알았지만 데이터의 개수는 총 1천 개 정도였다. bulkInsert를 통해 데이터를 적재하기 위해 JdbcClient를 사용했다. 예전에 로컬에서 데이터 100만 개를 20만 개씩 bulkInsert 했었는데, 인텔리제이 메모리를 4048M로 설정해서 진행했었다. batchSize를 더 키웠을 때, 컴퓨터 CPU 사용량이 100%가 되는 걸 확인했다. (꽤나 좋은 PC인데..)

아무튼 그래서 프리티어 수준의 저성능 서비스를 사용하고 있기도 했고, 총 데이터 수도 적어서 batchSize는 100개로 설정해서 데이터를 생성했다. 신규 데이터는 가끔 카페 들어가서 확인하고 직접 추가했다. 휴가 시즌를 겨냥해야 일주일에 여행 상품이 3개 정도씩 등록되는 수준이어서 수동 데이터 삽입을 해도 무리가 없었다. 

 

코틀린, 스프링부트를 사용했고 특히 의존성 역전 원칙(DIP)을 고려하여 패키지 구조와 레이어드 아키텍쳐를 설계했다. 그리고 DB 접근 기술로 JPA와 JDBC를 혼용했는데, 레포지토리 어댑터 패턴을 사용해서 구조를 깨지 않고 잘 사용할 수 있었다. 

 

HTMX 관련 글이 레딧에서 자주 보여서 나도 한 번 사용해 봤다. 일반적으로 프레임워크의 서버 사이드 렌더링을 사용하면 HTML 화면을 리턴하는 API와 추가적인 API를 구성해야 하는데, HTMX 방식은 모두 HTML을 리턴하는 방식이다. 물론 데이터 변경 같은 경우에는 그렇지 않아도 된다. 예전 회사에서 JQuery를 사용해본 적이 있었는데 뭔가 더 고급지고 하이레벨의 기능을 쓰는 것 같은 느낌을 받았다. 간단한 MVP는 이렇게 2-tier (WEB, DB) 구조로 개발하면 관리 포인트도 적고 시간 소모도 적어서 정말 좋은 것 같다.

PS.

추가적으로 예전에 '페이히어' 면접 때 당시 근무하고 있던 회사에서 인프라 비용이 너무 많이 나와 고민이 있어서 조언을 부탁드렸는데, 서비리스 아키텍처를 고려해 보라는 말을 해주셨었다. 당시에는 사실 '서버리스면, Supabase나 Firebase같은 서비스 아니야?' 라고 생각하고 말았었다. AWS를 사용해 보고 나니까 서버리스를 적용해서 비용적으로나 관리적으로 많은 이득을 가질 수 있겠다고 생각했다. 특히, 스타트업이나 신규 서비스의 경우에 말이다. 기능이 적기 때문에 S3와 람다를 통해서 충분히 MVP 서비스를 개발할 수 있겠다고 생각했다. 그래서 다음 프로젝트를 한다면 서버리스 아키텍처로 구현해볼 생각이다.