공부? 공부?

#개요 어제 AWS로 확인해보니 저번달보다 요금이 또 많이 나온 것을 확인했다.기존에 1~2만원 나오던게 이번에 갑자기 10만원 가량이 나온것이다.저번에 봇들로 인한 트래픽 과사용으로 과금이 발생했던 것에 비하면 낮은 금액이지만무언가 이상했기 때문에 원인을 찾고 있었다.근본 원인은 모르지만 어떠한 이유에서인지 CPU가 버스팅 되어 과금이 발생한 것이라고 해서CPU의 버스팅 기능을 OFF 하였다. 그런데 오늘 갑자기 사이트가 들어가지지가 않아서 AWS EC2 콘솔을 통해 확인해 보았다.인스턴스는 정상 작동이라고 했고, 인증서도 어제 새로 갱신했었다. #문제파악 1. 도커 nginx 로그를 확인했다.ubuntu@ip-172-31-61-55:~/project/study-mate$ docker compose ..

문제1. 하던 것과 같이 FSD 구조에 리팩토링을 함.2. Post 생성 기능을 구현 후 UI를 분리하던 중, 게시글 작성에 필요한 해당 유저의 생성 Study를 SSR로 불러서 받는 StudySelectField.tsx를 분리 후 아래와 같은 에러가 발생함. 문제 파악파악 결과Public API를 차용하여 도메인별로 index.ts파일에 export 할 컴포넌트와 함수를 정의해놨는데여기서 supabase의 createClient()가 실행되는 코드가 같이 있는 것이 문제.createClient는 'use server'에서 실행 되어야 하는데 'use client'인 StudySelectField가 컴파일 되면서해당 컴포넌트가 정의 되어 있는 index.ts가 같이 컴파일 되고 그 안에 있는 creat..

문제점Entities/도메인/model과 Entities/도메인/service에 UseCase에서 사용할 함수들을 만듦.예를들어 model 경로에는 create를 하기 위한 여러 작은 동작의 함수를 구현하고 service에서 이를 사용해 create를 한다면사용자는 이런 흐름을 알아야 한다는 문제점이 발생함.(UseCase에서 model의 create 함수를 사용할 수 있음) 그리고 Entity의 내부 함수가 전부 노출이 된다는 문제가 발생함. 문제 해결나의 프로젝트의 entities의 구성은 DDD 아키텍처에 따르지만 이 부분에 한해서는 위와 같은 문제를 해결하기 위해 FSD의 PUBLIC API 방법을 쓰기로 함(사실 기능 추상화 Interface 제공과 다르지 않다.) 1. PUBLIC APIF..

나에게 적용한 DDD 아키텍처 FSD에 따라 폴더를 App(NextJS App 라우터)Processes(더 이상 사용하지 않음)Pages (NexjtJS App 라우터로 흡수)Widgets(보통 app/page.tsx에 사용될 컴포넌트)Features(사용자 사용 기능별 분류)Entities(도메인에 따른 Entity 분류)Shared(공용 파일 및 라이브러리) 이렇게 나누었다.그리고 공용파일을 제외한 가장 하위에서 의존성의 뿌리를 담당하는 Entities 폴더를 먼저 리팩토링 하기로 하였다. 나는 Entities 폴더를 리팩토링을 하며 DDD 아키텍처를 참고,적용하기로 했다.FSD는 폴더 분류를 어떻게 할 것인가? 에 대한 방법론이라면DDD는 각 Entity들을 어떻게 분류하고 어떻게 정의하여 사용할 ..

기존 프로젝트기존 프로젝트의 대략적인 구조는 이러했다.src/├─ hooks/│ └─ useStudy/│ ├─ useStudyList.ts│ ├─ useStudyCreate.ts│ └─ useStudyJoin.ts├─ components/│ ├─ study/│ │ ├─ StudyCard.tsx│ │ └─ StudyFilter.tsx│ └─ participant/├─ actions/│ ├─ studyAction.ts│ └─ participantAction.ts├─ utils/│ └─ studyValidator.ts├─ types/│ └─ study.ts└─ constants/ └─ studyStatus.ts 역할별 계층 분리 + 기능별 응집내가 원래 Study-..

FSD란?프론트엔드 애플리케이션을 기능(feature)을 중심으로 나누어 설계하는 방법론이다.기존 나의 프로젝트도 그렇고 프론트엔드 개발에서 종종 겪던 문제 중 하나로코드간의 응집도가 낮고, 결합도가 높다는 문제가 있었다. 응집도가 낮다는 것은 필요한 요소끼리 흩어져 있다는 뜻이고, 결합도가 높다는 것은 컴포넌트끼리 정확히 파악하고 있어야 한다는 것이다.이는 결국 유지보수성을 떨어뜨리는 결과로 나타났다.나 같은 경우에도 그랬었다.특정 내용을 수정할 때, 관련된 요소가 다른 곳에는 없는지 내가 직접 생각을 해야했다.수정하고 나서도 더 이상 수정할 곳이 없다는 확신이 서질 않으며 실제로 계속해서 빠뜨린 부분이 나타났었다.이를 해결하기 위한 방법 중 하나로 FSD 아키텍처를 알아보게 되었다. FSD의 3가지 ..

발단평소처럼 평온하게 개발하던 어느 날, AWS로부터 청구서를 받았다. 400달러가 넘는 금액이었다.개인 토이 프로젝트 한 대 굴리는 정도로 이런 금액이 나올 리 없었다. 뭔가 잘못됐다. 결제 대시보드를 열어 항목을 들여다봤다.요금의 대부분은 데이터 전송(Data Transfer Out) 항목이었고, CloudWatch 지표를 확인해보니 EC2의 NetworkOut이 비정상적으로 높게 찍혀 있었다. 가설 세우기원인을 좁히기 위해 AI의 도움을 받아 가능한 시나리오를 정리했다.봇/스크래퍼 트래픽: 외부 봇이 API나 페이지를 지속 호출하며 응답 데이터 송신량이 폭증퍼블릭 리소스의 무한 다운로드: 이미지·정적 파일이 의도치 않게 외부에 대량 전송됨잘못된 보안 그룹 설정: 인바운드 포트(예: 22, 300..

문제의 시작내 프로젝트의 핵심 흐름은 이렇다. 로그인 → 스터디 생성 → 게시글 생성(스터디 선택) → 글 생성 완료 다른 유저가 참가 신청을 하고, 호스트가 수락하면 스터디의 정원이 차오른다. 정원이 가득 차면 스터디 상태는 자동으로 completed가 되고, 참가 인원이 빠지면 다시 recruiting으로 돌아간다. 나는 이 로직을 SQL 트리거 함수로 구현했다. participants 테이블에 변화가 생길 때마다 studies 테이블의 현재 인원을 갱신하고, current == max가 되면 상태를 자동 전환하도록 했다. 성능 면에서는 합리적인 선택이었다. 하지만 개발을 하면서 점점 문제가 드러났다. 첫 번째 문제: DB 처리와 서버 처리의 경계"어디까지 DB에서 처리해야 하지?" 트리거 함수가 늘..