multi-modal-fraud-project

안녕하세요. 오늘은 자바로 만든 메인 서버와 파이썬으로 만든 AI 서버를 서로 통신하게 만드는 방법을 정리해 보겠습니다. 프로젝트를 진행하다 보면 비즈니스 로직은 spring boot로 처리하고, 인공지능 모델이나 복잡한 데이터 분석은 파이썬의 FastAPI로 처리해야

메서드 기본 틀 잡기가장 먼저 클라이언트가 업로드한 파일을 서버가 받을 수 있도록 출입구를 만듭니다.Spring에서 클라이언트가 업로드한 파일은 MultipartFile 객체로 들어옵니다. 이는 메모리나 디스크에 임시 저장된 파일의 바이너리 데이터와 파일명 등의 메타데

Endpoint 기본 틀 잡기가장 먼저 Spring Boot가 던진 HTTP Request를 파이썬 서버가 받을 수 있도록 router(출입구)를 만듭니다. FastAPI에서는 @app.post 데코레이터를 사용하여 POST 방식의 endpoint를 생성합니다. 괄호

FastAPI가 기존 프레임워크들을 밀어내고 선택받는 3가지 핵심 원리와 아키텍처를 정리해 봅니다.FastAPI의 가장 큰 무기는 이름 그대로 속도입니다.기존 Flask는 동기 방식으로 동작하여, 한 번에 하나의 request만 처리하고 다음 request는 대기해야

단일 이미지 파일을 Spring Boot에서 Python(FastAPI)으로 넘겨 JSON 응답을 받아오는 데 성공했다. 하지만 기쁨도 잠시, 실무 환경을 가정해 보니 새로운 의문이 들었다.당근마켓이나 인스타그램처럼 사용자가 한 번에 수십 장의 사진을 업로드하는 상황을

이전 포스팅에서 대용량 이미지 분할 전송(Chunking)과 413 에러를 해결하며 파이썬(FastAPI) AI 서버와의 통신 길을 뚫었다. 이제 파이썬이 보내주는 AI 분석 결과(JSON)를 자바에서 어떻게 하면 가장 안전하고 깔끔하게 받을 수 있을지, 아키텍처 리팩

굉장히 간단할 줄 알았으나 꽤 오랫동안 삽질을 하는 바람에 기록해야겠다는 생각이 들었다.Spring Boot의 build.gradle 내 dependencies에 다음 코드를 추가한다.runtimeOnly 대신에 첫 번째 줄과 마찬가지로 implementation을 써

관계형 데이터베이스(PostgreSQL)에 이미지 파일의 이진 데이터를 직접 넣는 것은 성능상 매우 비효율적입니다. 따라서 실제 파일은 클라우드 스토리지인 Supabase Storage의 버킷에 업로드하고, 데이터베이스에는 해당 이미지를 렌더링할 수 있는 접속 URL만

프로젝트를 진행하며 기존 컨트롤러에 혼재되어 있던 로직(Supabase 업로드, AI 서버 통신, DB 저장)을 Service 계층으로 분리하고, DB 저장을 위해 JPA Entity를 도입하는 refactoring을 진행했다.그동안은 남들이 쓰니까, 혹은 IDE가 자

기존에는 사진 한 장을 받아서 Supabase 스토리지에 올리고, 파이썬 서버로 보내고, DB에 저장하는 로직을 사용했습니다.이번에는 여러 장의 사진(List)을 한 번에 받아서 처리해야 하는 상황이 되었습니다. 단순히 파라미터만 List<MultipartFile

Spring Boot 서버에서 여러 장의 이미지 리스트(files)와 텍스트 옵션(scam_type, image_type)을 전송했습니다.단일 JSON 데이터가 아닌 바이너리 파일과 텍스트가 혼합된 복합 데이터를 파이썬(FastAPI) 서버에서 어떻게 안전하게 파싱하고

다중 이미지 업로드 기능을 구현하던 중, 이미지들의 Supabase URL을 하나의 문자열로 합쳐 DB에 저장하려다 다음과 같은 에러가 발생했다.원인은 JPA @Column의 기본 길이 제한(255자)을 초과했기 때문이다. 파일 3개만 합쳐도 300자가 훌쩍 넘어가면서

FastAPI에서 multipart/form-data 형식의 파일을 수신할 때, 데이터 타입으로 단순한 bytes를 사용할 수도 있고 FastAPI 내장 객체인 UploadFile을 사용할 수도 있습니다.Spring Boot의 MultipartFile과 유사한 이 Up

새로운 AI 프로젝트를 시작할 때, 백엔드 개발자가 가장 먼저 마주하는 벽은 메모리 초과(OOM, Out Of Memory)와 응답 지연(Latency)이다. 특히 8GB RAM이라는 제한된 하드웨어에서 무거운 이미지 처리와 AI 추론을 동시에 처리하려면 뼈대부터 극단

새로운 프로젝트를 시작해서 마감 기한에 쫓기다 보면, 가장 먼저 실행 파일인 main.py 하나에 모든 코드를 때려 넣는 유혹에 빠지기 쉽다. 데이터 규격 검증부터 AI 모델 로딩, 이미지 전처리, 벡터 데이터베이스 검색, 그리고 API 통신까지 전부 한 곳에 모아두면

main.py에 합쳐져있던 코드를 분리했습니다.이미지를 처리하고 텍스트를 추출하는 엔진입니다. 무거운 ONNX 세션을 전역으로 한 번만 띄우고, 8GB 램 최적화 로직을 함수 하나로 깔끔하게 묶었습니다.ChromaDB 데이터베이스와 임베딩 모델을 담당합니다. 텍스트를