개발하나도모르겠다

웹 서비스를 개발하면서 마주친 이슈와 개선 과정을 정리했습니다.문제 발견네트워크 탭을 열고 메뉴를 클릭했더니 API 요청이 한꺼번에 여러 개 쏟아졌습니다. 원인을 추적해보니 프론트엔드 코드에 이런 패턴이 있었습니다.const codes = ['CODE_A', 'CODE_B', 'CODE_C', 'CODE_D', 'CODE_E'......];for (const code of codes) { const result = await fetchCommonCode(code); // 매번 API 호출}메뉴에 진입할 때마다 공통코드 개수만큼 API를 반복 호출하고 있었습니다. 공통코드가 10개면 10번, 20개면 20번.왜 문제인가단순히 "호출이 많다"는 것을 넘어, 각 API 호출마다 브라우저와 서버 양쪽에 비용이..

이슈QA 서버에서 특정 API(예약 API)를 약 1초 간격으로 여러 번 호출했을 때, CPU 사용량이 idle 30~40m에서 380~450m(밀리코어)까지 치솟았다. (2core Pod 기준) 동시 요청도 아니었고 요청 수 자체도 많지 않았는데, CPU가 누적되듯 오르다가 호출을 멈추고 잠시 기다리자 서서히 내려갔다.단순히 "요청이 많아서"가 아니라, 요청이 쌓일수록 비용이 누적되는 구조적인 문제임을 의심했다.문제 파악1. API 호출 한 번에 일어나는 일이 너무 많다예약 API는 단순히 예약을 저장하는 것 이상의 작업을 하나의 트랜잭션 안에서 처리하고 있었다.회원 정보 조회위약 이력 조회예약 가능 조건 검증예약 저장외부 메시지 발송 (SQS 등)이 중 외부 메시지 발송까지 @Transactional..

비동기 분석 프로세스를 붙이면서 처리해야할 수많은 내용중에 하나는SSE로 진행 상황을 알리면서 해당 상태를 DB에도 남기는 것이다 그래서 오늘은AnalysisJob Persistence 구조 보강Async Processor에서 DB 상태 업데이트까지 책임지기이 두 가지를 했다.1. AnalysisJobPersistencePort 역할 정리기존에는 save() 위주였는데,비동기 프로세스에서 쓰기엔 부족해서 의도를 드러내는 메서드들을 추가했다.Persistence Portpackage com.woopi.safehome.domain.deed.application.port.outboundimport com.woopi.safehome.domain.deed.model.AnalysisJobimport com.woop..

프로세스사용자가 PDF 업로드분석은 오래 걸림 → 비동기 처리분석 진행 상태를 SSE로 실시간 전달PDF가 잘못되었으면 즉시 실패 처리이제 PDF 검증부분을 추가해야하는데, 아래과 같은 고민이 생김“PDF 검증은 어디서 해야 하지?”“비동기 프로세스는 유스케이스가 직접 호출해도 되나?” 전체 흐름최종적으로 정리된 흐름은 아래와 같다.[Controller] ↓[DeedUseCase] - Job 생성 - SSE 연결 - 분석 실행 지시 ↓[AnalysisJobExecutorPort] ↓[AnalysisAsyncProcessor (@Async)] - PDF 검증 - 단계별 분석 - SSE 알림유스케이스는 ‘시작’까지만 책임지고,실제 처리는 전부 비동기 프로세서로 위임한다.Job..

jobId 생성 API는 만들었다.그 뒤엔 어떤 프로세스를 거쳐야 하는지 검점하고자 한다. 우선 전체 흐름은 SSE 기반 비동기 PDF 분석 프로세스를 설계했다.PDF 분석처럼 시간이 오래 걸리는 작업을 처리할 때'SSE로 진행 상황을 보여주고, 결과는 DB 기준으로 관리하는 구조'로 설계했다.추가로, 앱 온/오프라인 대응까지 고려한 흐름으로 설계했다. 기본 설계분석 진행 상황을 SSE로 실시간 전달실패 시 즉시 중단하고 원인 전달성공 결과는 DB에 영속화앱이 켜져 있든 꺼져 있든 동일한 결과 조회 가능전체 처리 흐름1. SSE 연결클라이언트가 분석 요청과 함께 JobId생성 및 SSE 연결서버는 jobId를 기준으로 분석 작업 관리초기 이벤트로 연결 성공 알림 전송2. 비동기 분석 시작실제 분석 로직은..

React Native 프로젝트 시작1. React Native를 선택한 이유이번 프로젝트는 웹이 아닌 앱만 제공하는 설치형 서비스를 목표로 했다.iOS와 Android를 각각 네이티브로 개발하기엔 개발·유지 비용이 부담되기 때문에,하나의 코드베이스로 두 플랫폼을 동시에 지원할 수 있는 React Native를 선택했다.React Native는 이라는 특징이 있다.JavaScript / TypeScript 기반React 문법 그대로 사용실제 네이티브 컴포넌트로 렌더링웹(React) 경험을 그대로 활용하면서도 네이티브 앱에 가까운 성능과 UX를 낼 수 있다.2. 프로젝트 시작 시 Expo를 사용한 이유React Native는 순수 CLI 방식으로 시작할 수도 있지만,초기 환경 설정과 네이티브 빌드 설정이 ..

개인 프로젝트에서 비동기로 시간이 걸리는 작업을 진행중일때, 진행 상황을 클라이언트에게 실시간으로 알려주는 기능이 필요했음.초기에는 WebSocket을 고려했으나, SSE(Server-Sent Events)로 방향을 전환하게 됨 1. WebSocket이란?간단 설명양방향 실시간 통신 프로토콜.클라이언트와 서버가 서로 자유롭게 메시지를 주고받을 수 있음.동작 방식1. 클라이언트 → 서버: WebSocket 연결 요청 (HTTP Handshake)2. 서버 → 클라이언트: 연결 승인 (프로토콜 업그레이드)3. ↔ 양방향 통신: 클라이언트 ↔ 서버 자유롭게 메시지 전송4. 연결 종료: 어느 쪽에서든 종료 가능특징양방향 통신: 서버 → 클라이언트, 클라이언트 → 서버 모두 가능프로토콜: ws:// 또는 wss:..

MySQL 쿼리 성능 개선 분석1. 기존 쿼리 (느림)sqlSELECT store_repo_rfc.id AS storeRepoId , store_repo_rfc.name AS storeRepoName , SUM(dsst.tot_amt) AS totAmt , SUM(dsst.net_amt) AS netAmt FROM day_sum_sale_teams dsst INNER JOIN minor_codes store_mnc ON dsst.store_cd_id = store_mnc.minor_id INNER JOIN ( SELECT rfc.ref_code AS code , mnc.minor_name AS name , mnc.minor_id ..

등본 분석 상황을 실시간으로 알려주기 위해서웹소켓을 사용할려고한다,웹소켓이 아닌 SSE(Server Sent Event)를 활용할 예정 (중간에 앱을 종료했을때는, 알림을 사용하려고 한다) SSE(Server-Sent Events)가 더 적합한 이유- 단방향 통신만 필요 - 서버에서 프론트로만 진행 상황을 전송 - 더 간단한 구현 - WebSocket보다 설정이 단순함 - 자동 재연결 - 연결 끊김 시 브라우저가 자동으로 재연결 시도 - HTTP 기반 - 별도의 프로토콜이나 복잡한 설정 불필요 예를 들어---1. PDF 파싱 --> "첨부된 파일을 분석중이에요"2. LLM 분석--> AI가 등본을 분석중이에요"3. 이후 처리--> "분석한 내용을 정리중이에요"4. 완료 --> "완료 됐습니다!" 1. ..

분석 요청 API 동작 시 비동기로 처리를 할건데처리를 위한 job 을 관리하는 DB를 만들것이다. 1. analysis_jobs 테이블 설계schema.sql-- 분석 job 테이블CREATE TABLE IF NOT EXISTS analysis_jobs ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT 'ID', job_id VARCHAR(255) NOT NULL COMMENT '작업 ID(UUID)', file_name VARCHAR(255) NOT NULL COMMENT '파일명', file_size BIGINT NOT NULL COMMENT '파일 크기', status VARCHAR(50) NOT NULL COMMENT '상태(예: PE..