코딩기록장

[Infra/DevOps] 사이드 프로젝트를 위한 AWS 인프라 구축 가이드 (2026 ver.) #3- CICD, Github Actions, Docker

이전 글에서는 RDS를 생성하고 SSH 터널링을 이용해 데이터베이스에 안전하게 접근하는 환경을 구축했다.이제 애플리케이션 서버와 데이터베이스까지 모두 준비되었으므로 서비스를 실제로 운영할 수 있는 기본적인 인프라가 완성되었다. 하지만 서버와 데이터베이스를 구축했다고 해서 배포까지 끝난 것은 아니다. 서비스를 운영하다 보면 새로운 기능을 추가하거나 버그를 수정해야 하고, 수정된 코드를 서버에 반영하는 작업이 반복적으로 발생한다. 프로젝트 초기에는 서버에 직접 접속하여 코드를 업데이트하고 애플리케이션을 재시작하는 방식으로도 충분히 운영할 수 있다. 하지만 개발이 계속 진행될수록 배포 횟수가 증가하고, 매번 같은 작업을 반복하는 과정에서 실수가 발생할 가능성도 높아진다. 특히 사이드 프로젝트나 개인 프로젝트라..

지난 글에서는 AWS 인프라의 기본이 되는 네트워크 환경을 구성했다.VPC를 생성하고, Public / Private Subnet을 분리했으며, 인터넷 게이트웨이(IGW)와 라우팅 테이블을 통해 네트워크 흐름을 설계했다. 또한 보안 그룹을 이용해 외부 접근과 내부 통신을 제어하고, 실제 애플리케이션이 실행될 EC2 인스턴스까지 생성해보았다. 이제 기본적인 서버 실행 환경은 갖춰진 상태다. 하지만 실제 서비스 구조를 생각해보면, 애플리케이션 서버만으로는 부족하다.대부분의 서비스는 사용자 요청을 처리하는 백엔드뿐 아니라, 데이터를 저장하고 관리하는 데이터베이스가 반드시 필요하다. 이번 글에서는 그 다음 단계로, AWS의 관리형 데이터베이스 서비스인 RDS (Relational Database Service)..

프로젝트를 시작하면 가장 먼저 고민하게 되는 부분 중 하나는 배포 환경이다. 개인 프로젝트나 해커톤처럼 규모가 크지 않은 경우에는 복잡한 인프라를 처음부터 구축할 필요는 없다. 하지만 로컬 환경에만 의존하거나 수동 배포 방식으로 운영하게 되면, 협업이나 실제 서비스 단계에서 불편함이 생기기 쉽다. 이번 글에서는 작은 규모의 프로젝트를 기준으로 AWS와 GitHub Actions를 활용해 기본적인 배포 환경을 구성하는 과정을 정리한다. VPC 기반의 네트워크 분리부터 EC2와 Docker를 이용한 애플리케이션 배포, RDS를 활용한 데이터베이스 구성, 그리고 CI/CD 파이프라인 구축까지 전체 흐름을 단계적으로 살펴볼 예정이다. 또한 AWS 콘솔은 업데이트에 따라 화면 구성이나 설정 위치가 달라지는 경우가..

최근 다시 제대로 만들어보고 싶은 프로젝트가 생겨서 기록 겸 글을 남겨보려고 합니다.바로 BriPong 이라는 뉴스 요약 서비스 프로젝트입니다.시작 계기멋쟁이사자처럼 클라우드 엔지니어링 4기 당시, 최종 프로젝트로 뉴스 요약 서비스를 진행했었습니다.“오늘의 뉴스를 간편하게 요약하고, 퀴즈로 재미있게 제공하는 서비스”를 주제로 진행했던 Newsugar라는 이름의 프로젝트였습니다. 당시 프로젝트에서는 뉴스 요약 기능과 뉴스 퀴즈 기능을 중심으로 서비스를 기획했고,Docker 기반 MVP 환경 구성, AWS 인프라 설계, EKS 및 CI/CD 구성까지 프로젝트 범위에 포함되어 있었습니다. 감사하게도 프로젝트는 최우수상을 수상할 수 있었습니다.그런데 프로젝트가 끝난 뒤에도 아쉬움이 남았습니다 . . 사실 결과와..

앞선 글들에서 정리했다시피 DispatcherServlet에서 요청이 전달되는 흐름을 따라가다 보면 자연스럽게 ``HandlerMapping``과 ``HandlerAdapter``라는 개념을 만나게 된다. 이전 글에서는 전체 요청 흐름을 중심으로 살펴보았기 때문에 DispatcherServlet 내 코드 역시 단순히 "Handler를 실행하기 위한 Adapter를 찾는 과정" 정도로 이해하고 넘어갔을 수 있다. 실젤 ``DispatcherServlet`` 내부에서의 흐름을 살펴보면, `doService` 메서드 내에서 `doDispatch()` 라는 메서드를 호출하게된다. `doDisptach()` 메서드 내 흐름은 다음과 같다. 실행할 Handler를 찾는다. 클라이언트 요청이 들어오면 먼저 어떤..

이전 글에서는 Interceptor를 중심으로 요청 처리 흐름과 실행 구조를 살펴보았다.이를 통해 Spring MVC에서 요청이 어떻게 전·후 처리되는지 전반적인 흐름을 이해할 수 있었다. 하지만 해당 흐름을 보다 깊이 이해하기 위해서는 그 기반이 되는 Servlet에 대한 이해가 필요하다.Spring MVC는 결국 Servlet 위에서 동작하는 구조이며, DispatcherServlet을 중심으로 요청을 처리한다. 이번 글에서는 Servlet이 무엇인지 살펴보며 Spring MVC의 내부 동작 구조를 한 단계 더 깊이 이해해보려 한다. Servlet 이란 ?클라이언트의 요청을 받아 처리하고, 그 결과를 응답으로 반환하는 자바 기반의 웹 컴포넌트이다. 서블릿은 서버에서 대기하고 있다가 클라이언트 (브라우..

이전 글에서는 Filter를 통해 요청이 DispatcherServlet에 도달하기 전에 어떻게 가로채지고 처리되는지 살펴보았다.Spring을 공부하다 보면 Filter와 함께 자주 등장하는 개념이 하나 더 있는데, 바로 Interceptor 이다. Interceptor 역시 요청을 가로채 처리한다는 점에서 Filter와 비슷해 보이지만,실제로는 동작 위치와 역할에서 분명한 차이를 가진다. 이번 글에서는 Interceptor가 무엇인지, 어떻게 동작하는지, 그리고 Filter와는 어떤 차이가 있는지 중심으로 살펴보려 한다. Interceptor 란 ?웹 애플리케이션 내에서 특정한 URI 호출을 가로채는 역할을 한다. Interceptor를 활용하면 기존 컨트롤러의 로직을 수정하지 않고도, 사전이나 사후..

이전 글에서는 Spring MVC의 전체적인 요청 처리 흐름을 중심으로, 요청이 어떻게 Controller까지 전달되고, 어떤 과정을 거쳐 응답이 생성되는지에 대해 살펴보았다. 하지만 흐름을 따라가다 보니Spring MVC와 함께 자주 듣게 되는 Filter에 대해서도 공부해봐야겠다는 생각이 들었다. 또한 이전에 Figma로 그려본 Spring MVC 구조를 기준으로,이 요소가 실제로 어느 위치에서 동작하는지도 함께 정리해보고 싶었다.Filter 란 ?Servlet에 도달하기 전, 요청을 가로채 로직을 수행하는 객체를 말한다. 서버로 요청이 들어오는 경우, `Dispatcher Servlet`을 거치기 전에 요청 사항에 대한 공통 관심사를 처리하기 위한 필터 로직을 수행한다. 대표적으로 `Spring ..

Spring Boot로 웹 개발을 해보면, Controller를 만들고, API를 구현하는 과정은 생각보다 빠르게 익힐 수 있다. 하지만, 이면에서 요청이 어떤 흐름을 거쳐처리되는지, DispatcherServlet이 어떤 역할을 하는지 는 정확히 이해하지 못한 채 사용하는 경우가 많다. (특히, 나 ...... ) 그래서 휴학도 했다 ! , Spring 워크북도 하고 있다 ! 이 참에 이 과정에 대해서 깊게 정리해보려고 한다. 그 과정에서 가장 먼저 짚고 넘어가야 할 개념이 바로 MVC 패턴이다.MVC는 단순히 Spring MVC에서만 사용하는 개념이 아니라, Spring을 처음 공부할 때 반드시 이해하고 넘어가야 하는 핵심 개념이다. 이번 글에서는 Spring MVC의 흐름을 이해하기 위한 첫 단계로..

지금까지 진행했던 대부분의 프로젝트는 Layered Architecture 기반으로 서버를 설계하고 구현해왔다. Controller, Service, Repository와 같이 역할에 따라 계층을 나누는 구조는 이해하기 쉽고 구현하기도 비교적 명확하기 때문에 초기 프로젝트를 진행할 때 자연스럽게 선택하게 되었다. 하지만 프로젝트를 경험하면서 계층 간 의존성이 복잡해지거나, 비즈니스 로직이 특정 계층에 집중되는 구조를 보며 “서버 구조를 더 잘 설계할 수 있는 방법은 없을까?”라는 고민이 생기기 시작했다. 이러한 고민을 하던 중 Hexagonal Architecture 라는 구조를 접하게 되었다. 비즈니스 로직을 중심에 두고 외부 시스템과의 의존성을 분리한다는 점에서 기존의 Layered Architect..