전체 글

나는 그동안 AWS EC2 서비스를 활용해 여러 번 애플리케이션 서버를 배포해 왔다. EC2는 클라우드의 대표 서비스이자 단순한 컴퓨팅 대여 서비스로, 클라우드 환경에 최적화되어 있어 대표적인 사례가 많기 때문에 자연스럽게 사용한 것 같다. 사실 뭐 그 이상의 기능까지도 필요 없었던 것도 사실이다.. 하지만 기존에 내가 인프라를 구축하는 프로젝트들과는 달리 이번 프로젝트는 이미 기존에 ECS를 사용하고 있었다. 기존 시스템을 관리해야 하기도 하고, 새로 리팩토링을 하면서 새롭게 ECS를 사용할 예정이기 때문에 이 기회에 ECS를 정리하고 사용해보려 한다.  AWS는 결국 서비스를 판매하는 판매처이기 때문에 서비스에 대해서 잘 설명해주고 있다. 그래서 이 글은 AWS 공식 홈페이지와 설명서들을 기준으로 E..

Chapter 2. 객체의 종류VO(Value Object)란 어떤 객체인가?DTO(Data Transfer Object)란 어떤 객체인가?DAO(Data Access Objec)란 어떤 객체인가?엔티티(Entity)란 어떤 객체인가? 흔히 검색하면 나오는 개념으로는 다음과 같다.VO는 Value Object로 값 객체라는 뜻이다. 쓰기 작업이 불가한 읽기 전용 객체를 말한다. DTO는 계층 간 데이터 교환에 사용되는 객체이다. 대표적인 예로 DB에 데이터를 넣을 때나 DB에서 데이터를 불러올 때 DTO를 사용한다.DAO는 데이터베이스에 접근하는 데 사용되는 객체이다.엔티티는 JPA @Entity이며, 테이블에 1:1로 대응되고, 각각을 구별할 수 있는 식별자를 가지고 있다. 하지만 결코 충분하지 못하며..

늦은 신년 목표 한 달에 한 권 이상 읽기이다.. 잘 정리해보려 한다 ㅎㅎ1부 객체지향)객체지향 프로그래밍은 현실 세계의 복잡성을 풀어내는 방법 중 하나로, 현재 가장 인기 있는 프로그래밍 패러다임이라 해도 과언이 아니다. 1. 순차지향, 절차지향, 객체지향 프로그래밍이란?2. 객체지향 프로그래밍에서 역할, 책임, 협력을 강조하는 이유가 뭘까?3. VO, DTO, DAO, 엔티티란 뭘까?4. 행동이 강조되는 이유가 뭘까?5. SOLID와 디자인 패던은 어떻게 이해하는 게 좋을까?6. 순환 참조를 피해야 하는 이유가 뭘까? 책의 1부 객체지향을 읽으면 다음과 같은 질문에 대답을 할 수 있을 것이다. (물론 내 글은 Chpter1만 다루고 있다.)Chapter 1. 절차지향과 비교하기자바를 사용하면서도 절차..

그동안 EC2 인스턴스만 활용해 비교적 단순한 방식으로 서버를 배포해왔는데, 최근 새로운 프로젝트에 합류하면서 다양한 AWS 서비스(VPC, 서브넷, 가용 영역(AZ) 등)를 사용하는 클라우드 기반의 아키텍처를 접하게 되었다. 아키텍처를 보자마자 어느 정도 파악은 했지만, 온전히 이해하지 못한 부분이 많아 아쉬움이 남았다는 슬픔.. 하지만 이제 서버 개발자는 나 혼자이기 때문에 혼자서 유지보수와 확장을 담당해야 하므로, 각 기술이 어떤 역할을 하는지 이해해야 한다. 그래서 뜬금없지만 오늘은 AWS 인프라에 대해 정리해 보려고 한다. 1.  AWS 클라우드 아키텍처 살펴보기EC2 인스턴스만으로도 기본적인 서버를 구축할 수 있지만, 복잡한 애플리케이션 운영이나 보안, 고가용성, 확장성과 같이 요구 사항을 만..

이번 글에서는 운영 환경에서의 데이터베이스 최적화 작업 중 인덱스 설정이 제대로 반영되지 않은 문제를 겪으면서, ddl-auto update 옵션의 치명적인 단점과 그 원인에 대해 정리해보고자 한다.실제 운영 중인 서비스에서, 한 팀원이 인덱스 설정을 통해 데이터베이스 최적화를 시도한 적이 있었다. 나는 인덱스 설정을 보다 합리적으로 개선하고, 테스트 코드로 최적화 정도를 확인해 보고자 이걸 자세히 파보려 했다. 하지만 테스트를 진행하는 과정에서 실제 운영 데이터베이스에 인덱스 테이블이 존재하지 않음을 가장 먼저 발견했다. (매우 당황스러웠지만.. 블로그를 쓸 생각에 나름 재밌기도?!)문제의 원인을 찾은 결과, ddl-auto 설정이 update 옵션으로 되어 있었던 것이 큰 패착이라는 사실을 알게되었다..

웹 개발을 처음 시작할 때는 Django를 배우며 서버에서 HTML을 직접 렌더링하는 방식이 당연하다고 생각했다. 프론트엔드와 백엔드가 하나의 프로젝트 안에서 함께 동작하며, 데이터베이스에서 가져온 정보를 그대로 템플릿을 통해 사용자에게 보여주는 방식이 일반적이라고 여겼다. 하지만 이후 Spring을 배우면서 API 개발이라는 개념을 접하게 되었고, Django에서의 웹 개발 방식과는 확연히 다른 구조라는 것을 알게 되었다.처음에는 단순히 "프론트엔드와 백엔드를 분리하면 API가 필요하다" 정도로만 이해했다. 하지만 정작 SSR(Server-Side Rendering)과 RESTful API가 정확히 무엇인지, 이 둘이 어떤 차이를 가지는지 명확하게 알지 못했다. SSR은 서버에서 HTML을 렌더링해서 ..

미들웨어는 Django에서 요청(request)과 응답(response)을 처리할 때 개입해 특정 작업을 수행할 수 있도록 만들어진 플러그인 시스템이다. 요청이 서버에 도달하거나, 응답이 클라이언트로 전달되기 전에 미들웨어가 이를 가로채서 필요한 작업을 수행한 뒤 다음 단계로 넘긴다고 보면 된다. 이 글에서는 공식문서를 기반으로 Middleware가 무엇인지, 기본 동작 방식은 어떤지, 어떻게 Custom Middleware를 작성하는지에 대해 정리할 예정이다. 1. Middleware란?Django 공식 문서에서는 미들웨어를 다음과 같이 설명한다."미들웨어는 Django의 요청 및 응답 처리 과정에 훅(hook)을 제공하는 가볍고 저수준의 플러그인 시스템이다." 이를 통해 요청(request)이 들어오..

Django를 통해 개발을 처음 접하다 보면 종종 Django로 만든 프로젝트가 바로 사용자와 직접 통신하며 모든 요청을 처리한다고 생각한다. 하지만 실제 배포 환경은 단순하지 않다. Django는 단독으로 모든 요청을 처리하기에 적합한 구조가 아니며, 웹 서버(Web Server)와 WSGI 서버 같은 중간 계층이 필요하다. 이러한 계층들은 요청을 효율적으로 처리하고, 애플리케이션의 성능과 안정성을 보장하며, 확장성을 제공하는 중요한 역할을 한다.이 글에서는 Django와 HTTP Request-Response Lifecycle을 통해 요청이 Django 내부에서 어떻게 처리되고 응답으로 이어지는지, 그리고 이 과정에서 웹 서버와 WSGI 서버가 어떤 역할을 하는지를 살펴보려 한다. 이러한 원리를 이해..

Django URL Dispatcher 란?Django는 웹 프레임워크로, 웹 애플리케이션 개발을 단순화하고 유지보수를 쉽게 만든다. 그중 URL Dispatcher는 사용자가 웹사이트에서 특정 URL을 요청했을 때, 해당 요청을 적절한 뷰(view)와 연결하는 Django의 핵심 기능이다. 오늘은 Django의 URL Dispatcher가 어떻게 동작하는지, 왜 중요한지, 그리고 효과적으로 사용하는 방법을 Django 공식 문서를 기반으로 정리해 볼 예정이다. Django의 URL Dispatcher는 사용자가 웹사이트에서 특정 URL을 요청했을 때, 해당 요청을 처리할 적절한 뷰(view)와 연결해주는 시스템이다. 웹 애플리케이션의 URL 관리는 개발자가 코드를 관리하기 쉽게 만드는 중요한 요소이기 ..

내가 Django 처음 배울 땐 settings.py가 진짜 무서웠다. 괜히 잘못 건드렸다가는 프로젝트가 아예 안 돌아갈 것 같았다. 근데 이번에 이 글 준비하면서 다시 보니까 그때 뭐가 그렇게 어려웠나 싶다. 사실 보면 별 거 없고 말 그대로 설정하는 파일일 뿐인데, 그땐 서버에 대한 기초 지식이 부족해서 더 어렵게 느껴졌던 것 같다. 그래서 이번 기회에 Django를 다시 제대로 공부해보고, Django를 입문하는 사람들에게 조금이나마 도움이 됐으면 하는 마음으로 이 글을 써본다. Django 프로젝트의 settings.py 파일은 프로젝트의 전반적인 설정을 정의하는 핵심 파일이다. 대부분 입문용 웹 개발로 Django를 배우기 때문에, 시간 내에 기능을 구현하고 간단하게 코드를 작성하는 경우에는 s..