해물파이의 괴발개발 TIL

Context문제 상황현재 시스템에서 다양한 외부 API(구글 트렌드, 유튜브 API, 네이버 뉴스 API)를 활용하고 있음. 이러한 외부 의존성을 효율적으로 관리하기 위해 아키텍처를 재설계하고자 함.각 외부 API의 변화에 유연하게 대응하고, 시스템의 확장성을 높이기 위해 헥사고날 아키텍처 도입을 고려Decision제안 내용 및 이유헥사고날 아키텍처 완전 도입: 시스템의 유연성을 높이고, 외부 API의 변화를 손쉽게 반영할 수 있도록 모든 외부 서비스 및 의존성을 어댑터와 포트로 분리하여 관리.장점: 외부 API의 변화가 시스템에 미치는 영향을 최소화하고, 테스트와 유지보수가 용이해짐.Consequences제안된 기술 도입의 장단점반대외부 API를 많이 사용하고 있어 코드가 복잡해지고 양이 많아질 수 ..

Context문제 상황개발 서버를 띄워야 하는데 어떻게 해야 할지 고민 중.Decision제안 내용 및 이유출처 수집 시 개수 줄이기: 데이터를 더 빠르게 얻기 위해 외부 출처의 데이터를 제한적으로 수집.로컬처럼 모킹 데이터 활용: 실제 데이터와 유사한 형태의 모킹 데이터를 활용하여 로컬 환경과 테스트 환경을 일치시킴.스케줄링 기간 늘리기 (하루 또는 4시간): 데이터를 최신화하는 주기를 조절하여 부하를 줄이면서 최신 데이터를 유지.Consequences제안된 기술 도입의 장단점 ✅출처 수집 시 개수 줄이기✅장: 실시간 데이터를 얻을 수 있음단: 컨텐츠의 부족으로 이어질 수 있음로컬처럼 모킹 데이터 활용✅장: 로컬과 환경변수 같이 가져갈 수 있음, 운영과 같은 주기로 테스트 가능함단: 실제 데이터를 사용..

Context문제 상황우리 프로젝트는 ‘구글 트렌드 api 기반으로 실시간 키워드로 AI 뉴스를 만들어주는 웹 페이지’이다.그럼 생각해보자. 구글 트렌드 api 기반으로 인기있는 키워드를 10개를 받아야한다. 그리고 그걸 기반으로 AI 뉴스를 만들고 페이지에 올려야 된다. 단순히 키워드를 10개 받고 끝내면 상관없지만, 여기서 주요로 봐야할 웹 페이지의 특징은 실시간이다.실시간으로 데이터를 받아, 실시간으로 그 데이터를 처리한다. 여기서 디스크 기반으로 데이터를 저장하는 MySql를 사용하여 실시간으로 데이터를 저장하고 읽는데 사용한다고 생각해보자! 데이터베이스를 처리하다가 컴퓨터가 처리될 것이다! 사실 지금 같은 소규모 프로젝트에서는 상관없겠지만, 사용자가 몇만 명이나 있는 웹 페이지에서는 MySql같..

문제 상황문제 상황예산 제약: 가능하다면 무료로 가능한 모니터링 대시보드 도입짧은 개발기한: 2주일 내에 DB·애플리케이션·OS 지표를 수집·시각화·알람까지 구축해야 함운영 방식: 팀은 Docker-Compose와 IaC(Terraform) 기반 배포에 익숙필요 기능시스템 / 애플리케이션 메트릭 수집대시보드 시각화임계치 기반 알림제안제안 내용 및 이유Prometheus 서버 + Grafana를 Docker-Compose에 배포한다.무료 & 오픈소스: 두 프로젝트 모두 라이선스 비용이 없어 벤더 의존 없이 확장 가능.간단한 배포: 공식 Docker 이미지만으로 2 컨테이너(Prometheus, Grafana) 구성 가능하며, 기존 docker-compose.yaml 에 추가한다.풍부한 Exporter: M..

Context문제 상황프로젝트 내에서 사용하는 API를 정기적 (1시간 단위)으로 불러올 스케줄러 작성의 필요성시간 단위로 작업 자동화의 필요성 有현재 다음과 같은 구조로 스케줄러의 작업이 진행됩니다.Keyword 추출 → Source 검색 → 조건 평가 → LLM 호출 → DB 저장위의 과정을 시간 단위로 자동화해야 하는 요구사항이 존재합니다.Decision제안 내용 및 이유Spring Batch 프레임워크를 도입하여 시간 단위 스케줄러를 구현배치 처리 특화 : Spring Batch는 대용량 데이터 처리 및 일련의 순차적인 배치 작업을 안정적이고 효율적으로 관리하는 데 특화된 프레임워크입니다. 현재 요구사항인 API 호출, 데이터 처리, DB 저장은 명확한 배치 처리 패턴에 해당합니다.Spring 생..

문제 상황우리가 만드는 서비스는 **“실시간에 가까운 트렌드 데이터”**를 수집해 키워드·기사·영상·LLM 요약으로 변환해서 사용자에게 전송한다. 하루 24 번, 한 달이면 720 배치를 돌려야 하는데, 각 단계마다 속도가 제각각이다.한 번 호출에 200 ms인 Google Trends, 1 초쯤 걸리는 Naver News API기사 20건을 붙여서 요청해서 Summary를 생성해야 하는 LLM API(최대 15 초)장애가 터지면 지난 몇시간의 데이터을 다시 긁어 와야 하고, 운영팀은 성공·실패 알람을 한 곳에서 받고 싶어 했다.간단한 cron 잡으로도 시작할 수 있었지만, 이렇게 복잡해지는 워크플로를 사람이 손으로 리런(re‑run)하다 보면 금세 지옥이 된다. 그래서 “워크플로를 코드로 관리하면서 재..

문제 상황프로젝트를 진행하면서 DB를 변경하게 되면 DB 마이그레이션을 하게 될텐데, 그럴 경우 아래의 방법 둘 중 하나를 사용해야 한다.DB 마이그레이션 (DB 변경사항 관리) 방법spring.jap.hibernate.ddl-auto = create // update create로 DB의 변경사항을 관리하는 경우, 데이터를 유지할 수 없다.수동으로 schema 변경휴먼 에러가 발생할 가능성이 높다.제안FlywayDB 버전을 관리하기도 좋고, 개발 환경의 통일성을 제공해준다는 점이 있다.또한 새로운 기술을 경험해본다는 점에서 도입할 가치가 있다.장단점제안된 기술 도입의 장단점장점DB 버전을 관리하기 편하다.아래의 예시처럼 버전 정보, 스크립트 파일 정보, 변경자, 변경 일자, 성공 여부를 담은 metad..

문제 상황Swagger 도입 전 기존 상황은 다음과 같다:FE와의 협업을 위한 API 명세서 필요함API 개발 전 Mocking 툴로 Postman을 사용 중Postman은 동시 작업이 어렵고 휴먼 에러가 발생할 가능성이 높음이로 인해 API 문서 작성 툴 변경이 필요했고, 이를 위한 고려 사항은 다음과 같았다:실제 작성된 API 기반으로 자동 업데이트가 가능한 명세서가 필요함제안SwaggerAPI 작성 시, 의존성 및 관련 Annotation을 추가해 Swagger 문서로 API 명세서 제공장단점장점자동화된 문서화 API문서를 자동으로 생성해주기 때문에 개발자가 일일이 문서를 작성할 필요 없음시각적 인터페이스 Swagger UI를 통해 API를 시각적으로 테스트하고 탐색이 가능함표준화 OpenAPI S..

문제 상황본 프로젝트에서 DB에 적재해야 하는 테이블은 member, keyword, post, comment 등이 있다. 다양한 뉴스 채널의 실시간 속보 데이터를 수집 및 가공하여 제공하는 본 프로젝트의 특성상 관계형 데이터베이스(RDB)와 비관계형 데이터베이스(NoSQL) 모두 고려했다.제안MySQLS3 인스턴스 상에서 컨테이너로 구동팀원 모두에게 익숙하여 학습 및 운영 리소스 절감 기대프로젝트에서 요구되는 정합성 및 트랜잭션 처리에 적합한 구조를 제공장단점장점팀원들이 MySQL에 익숙하여 빠른 개발 및 유지보수가 가능함트랜잭션, JOIN, 정규화된 데이터 모델링 등 관계형 데이터베이스의 특성을 활용할 수 있음다양한 문서와 커뮤니티가 존재하여 문제 해결이 용이함컨테이너화가 용이하여 S3 환경에서도 유..

문제 상황본 프로젝트에서 제안된 기술과 관련된 주요 기능은 다음과 같다:자체 회원가입 및 로그인 (이메일 + 비밀번호)로그인 이후 JWT를 통한 사용자 인증회원 데이터는 자체적으로 관리인증 및 인가를 어떻게 구성할지 결정해야 했으며, 주요 고려 사항은 다음과 같았다:사용자 경험: 다양한 로그인 방식 제공보안: 토큰 탈취 방지 및 최소한의 저장 정보프론트엔드와의 통신: API 서버는 JWT를 이용해 사용자 식별프론트엔드 요구사항: JWT 사용 시 쿠키에 저장하는 것을 원함제안다음과 같은 구조로 인증 및 인가 방식을 구성한다:자체 회원가입/로그인이메일과 비밀번호 기반의 로그인 제공비밀번호는 해시(BCrypt) 후 저장로그인 성공 시 JWT Token 발급JWT 발급 및 검증로그인 성공 시 자체적으로 JWT ..