갬짱의 개발기록

1. 구축배경PicPle의 서버는 사용자에게 안전하고 효율적인 서비스를 제공하기 위해 HTTP 통신의 불안정성을 해결하고,HTTP에서 HTTPS로의 전환을 구현하고자 했습니다.특히 보안 문제와 성능 문제를 동시에 해결하기 위해 SSL 암호화 통신과 리버스 프록시를 도입하게 되었습니다. 2. 문제 분석: 기존 구조에서의 한계 문제 1: 백엔드 포트 노출 기존 구조에서는 업로드 API를 직접적으로 클라이언트와 연결하는 방식이었습니다.이 경우, 서버가 공인 IP와 직접 연결되어 외부에서의 공격에 취약한 보안 리스크가 존재했습니다.즉, 외부로부터의 접근을 제한할 방법이 필요했습니다. 문제2: HTTPS 미적용 기존 시스템은 HTTP만을 사용하고 있었기 때문에, 전송된 데이터가 도청이나 변조될 위험이 있었습니다..

PicPle의 “실시간 핫플레이스 Top10” 기능은 단순한 조회 기능이 아니다.사진 업로드가 일어날 때마다 통계를 즉시 갱신하고, 이 변화가 지도 UI에 반영되어야 한다.즉, 쓰기(write)가 매우 빈번한 실시간 랭킹 시스템이다. 처음에는 이 기능을 DB 기반 집계 + Redis 캐시로 구현하여 꽤 나쁘지 않은 성능을 얻었지만더욱 고도화된 전용 Redis 자료구조를 통해 더욱 향상된 랭킹 시스템 통계계산으로 성능을 향상하고자했다. 1. 기존 HotPlace 구조의 한계조회는 Redis, 정렬 계산은 DB→ DB에서의 정렬계산 작업은 큰 병목지점이다! 이전 플로우[서버 부팅]↓DB에서 TOP10 조회 : calculateTop10FromDB() → Redis 저장↓📱 클라이언트 [GET /v1/sta..

PicPle은 사진 기반 SNS이기 때문에 사진 업로드는 서비스 전체의 성능을 결정하는 핵심 기능이다. 사진업로드는 두 단계로 구성된다 (1) 사진 컨텐츠(jpg, png, jpeg)를 S3스토리지에 업로드하는 과정(2) 업로드된 사진의 메타데이터( 좌표, 지역라벨링, 스토리지 키, 사용자 정보 )를 MySQL 데이터 베이스에 저장하고 통계정보 LocationStat을 업데이트하는 과정이다. 각 단계에서 성능 지연 최소화와 안정화를 위해 Presigned URL, 비동기 스레드와 바운디드 큐 도입을 한 과정을 설명한다.사진업로드 : 프론트가 직업 Presigned URL로 S3 bucket에 직접업로드 ( 서버 부하 제거 )업로드 API는 최소정보만 저장하고 즉시응답 ( 30 ~ 40ms )reverse..

PicPle은 “지금 이 순간”의 현장감을 지도 위에 기록하는 SNS다.이 경험을 완성하려면 단순 사진 업로드를 넘어서 보다 많이 업로드되는 장소를 실시간으로 계산하고, 이를 즉시 지도 UI에 반영하는 실시간 핫플레이스 기능이 필수였다. 이 글에서는 사진 업로드 → HotPlace 계산 → WebSocket 브로드캐스트로 이어지는 PicPle의 실시간 HotPlace 계산 및 브로드캐스트 파이프라인을 어떻게 설계·구현했는지 기록한다. 1. 기능도입 배경 : 왜 실시간 HOT Place 기능이 필요한가?사진 SNS는 대부분 “정적 피드” 기반이다.그러나 PicPle의 핵심 컨셉은 “지금 이 순간 사람들이 어디에 모여 있는지 지도에서 바로 보고 싶은 경험.” 이다. 따라서 단순히 DB에 모아놓고 조회하는..

SIGMA version2를 준비하면서 서버/백앤드 영역에서 가장 큰 변화는 바로 EKS 기반 인프라를 ECS Fargate 기반으로 완전히 재구성한 것이다.이글에서는 단순히 "EKS→ECS로 옮겼다"가 아니라 네트워크, IAM, Secrets, ALB, HTTPS, CI/CD, Redis까지 연결된 전체적인 대규모 마이그레이션 여정을 기록한다. SIGMA의 V2는 사실상 백엔드 인프라를 AWS 네이티브 방식으로 재설계한 버전이라고 보면 된다.1. 왜 EKS를 떠나 ECS로 가는가?SIGMA V1은 이런 구조였다.Client → ALB → Ingress → Service → Pod(EKS) 쿠버네티스 자체는 매우 강력했지만SIGMA 서비스 스케일에서는 오히려 과한 부분이 많았다. ( 오버엔지니어링 ) 현..

SIGMA Version 2에서는 "데스크탑에서 모바일 플랫폼으로의 확장"과 "이전 버전의 불안정 요소들을 실제 서비스 수준으로 강화하는 것"을 목표로 개선을 진행했다.AI 팀은 얼굴인증 다각화, STT노이즈 제거, 모션 인식 후보정과 모델 파이프라인 최적화에 집중했고서버/인프라 담당자인 나는 비용 절감(ECS 마이그레이션), 통신 구조 개선, WebSocket 보안 강화를 맡아 완성도 높은 인프라 구조를 만들었다.그중에서도 이번 글에서는 기존 WebSocket 음성 인식 구조의 보안 문제를 해결한 과정을 정리한다.1. 왜 WebSocket 보안 강화가 필요했는가?SIGMA의 음성 인식 흐름은 실시간성이 절대적으로 중요했다.그래서 초기 버전(V1)은 다음과 같은 구조로 단순하게 설계하였다.Frontend..

SIGMA는 로컬기기를 제어하는 서비스라는 특성으로 보안성 강화가 매우 중요했고비접촉 제어 서비스라는 특성으로 사용자 인증절차도 비접촉식 얼굴인증을 도입하고자했다. 특히 얼굴정보는 민감한 데이터이기 때문에 다음 두 가지를 모두 만족해야했다.보안 - privacy부하분산 - performance지연 최소화 - low latency이를 위해 Presigned URL 업로드 → WebClient기반 Lambda Rekognition 호출 → FaceSession 발급으로 이어지는 독립적인 보안 인증 파이프라인을 설계했다. 이번 글에서는 SIGMA 얼굴 인증이 어떻게 동작하는지, 왜 이렇게 설계했는지에 초점을 두고 정리한다.1. 설계목표SIGMA의 얼굴인증 설계 목표는 5가지 (1) 서버 부하없는 확장성서버는 ..

이전 글에서는 EKS에 서비스를 배포하고, 임시로 Service(type=LoadBalancer) + NLB 구조로 API를 외부에 노출했다. 이 방식은 가장 빠르게 외부에 API를 여는 데에는 적합하지만,SIGMA 서비스가 요구하는 도메인 기반 라우팅 / HTTPS / 프론트–백 분리 / 외부 AI 서버 통신 관점에서는 구조적 한계가 있었다. 또한 SIGMA는 하나의 백앤드 서비스 안에서 여러 종류의 엔드포인트가 등장한다.Flutter 클라이언트가 호출하는 백엔드 APIPresigned URL 발급얼굴 확인/인증을 위한 Rekognition Lambda 호출등 다양한 엔드포인트를 사용하므로 도메인 기반 트래픽 분기(L7 Routing) 와 HTTPS 보안 적용이 필수 조건이었다.이를 위해 Ingress..

SIGMA는 얼굴 인증(Rekognition), 음성 인식(Transcribe), 제스처 인식(MediaPipe), AI 명령 변환(Bedrock) 기능을 하나의 서비스 흐름으로 묶어 사용자가 “비접촉 제어(Non-Contact Control)”를 수행하도록 만드는 서비스입니다. SIGMA의 백엔드는 AI 연산을 직접 수행하지 않는다.AI 연산은 모두 AWS Lambda + Bedrock, Rekognition, Transcribe에서 이루어진다. 백엔드의 역할은 다음과 같다:OAuth 기반 사용자 인증Presigned URL 발급 (얼굴 등록/인증용 이미지 업로드)얼굴 인증 요청 중계 (WebClient → Rekognition Lambda)WebSocket Gateway 연결 전에 HMAC 발급 (v..

FinanceDoc MSA에는 “금융 리터러시 교육(Edu-Service)”이라는 중요한 기능이 있습니다.사용자가 금융을 어렵게 느끼지 않고, 쉽게 접근할 수 있도록 금융 용어 카드뉴스, 4지선다 퀴즈, 랜덤 학습 경험을 제공하는 모듈입니다. 이 서비스를 구현하기 위한 일련의 전체 흐름을 기록합니다크롤링 서버(python) 구축 → Kubernetes Job 실행 → PostgreSQL 적재(pv)→ 랜덤 카드뉴스 API(spring), 퀴즈 생성 API(spring) 1. Edu-Service의 목표와 기능 구성Edu-Service는 크게 두 부분으로 나눕니다. 기능설명기술 포인트기능설명기술포인트① 금융용어 사전(카드뉴스)한국은행·KDI 금융/경제 사전 데이터 자동 수집 → DB 저장 → 프론트에서 랜..