Blog

시스템 설정 및 관계 구조 요약: 본 기록은 시스템의 각 구성요소가 독립 서비스로 전환된 이후, 실제 운영 환경에서 안정적으로 동작하기 위해 설정된 구조와 관계를 다룬다. 모든 조정은 AI 에이전트 중심으로 이루어졌으며, 인프라 운영자의 수동 개입은 최소화되었다. 각 서비스 간의 데이터 연계, 글로벌 동기화, 캐시 구조, 그리고 AI 기반 검증 체계에 대해 실제 업무 진행 순서대로 기술한다. 1. 초기 상태 점검 및 서비스 간 데이터 경로 정의 프로젝트는 MCP 내부 서비스가 물리적으로 분리된 시점에서 시작되었다. 서비스는 정상적으로 기동되었지만, Redis와 MQ 사이의 데이터 경로가 불완전했다. 일부 이벤트는 발행되었으나 소비자 함수가 인식하지 못했고, 캐시 무효화 시점이 불일치했다. 문제의 원인은 큐 이름 충돌이었다. 6월 구조에서는 모든 이벤트가 default 토픽에 쌓였기 때문에, 이벤트 종류별 처리 우선순위를 분리할 수 없었다. 우리는 LavinMQ의 라우팅 키 구조를 다시 정의했다. 서비스 도메인별로 큐를 분리하여 이벤트 흐름을 시각적으로 구분했다. product.* → Translator-Agent session.* → Auth-Service / Redis Sync cache.* → Cloud Function(Cache Invalidator) log.* → Ops-Agent 이 설정을 적용한 후, MQ 메시지 지연은 평균 80ms 수준으로 안정화되었고, 이벤트 충돌 비율이 0.2% 미만으로 감소했다. 기존 수동 모니터링 대신 Ops-Agent가 주기적으로 큐 상태를 수집하고, 누락 이벤트가 10건 이상일 경우 자동 재전송하도록 설정했다. 2. Red...

글로벌 세션 동기화와 캐시 아키텍처 설계 요약: REINDEERS의 글로벌 인프라는 단일 DB 위에 다국가 트래픽이 동시에 얹히는 구조다. 이러한 환경에서 세션과 캐시의 일관성을 유지하는 것은 가장 중요한 기술 과제였다. 6월, 우리는 Redis·MQ·Cloud Function을 활용해 “글로벌 실시간 세션 복제”와 “이벤트 기반 캐시 무효화”를 완성했다. 이 구조는 서울과 홍콩, 두 리전이 200ms 이내로 데이터를 동기화하도록 설계되었다. 1. 문제 정의 — 글로벌 세션의 일관성 글로벌 사용자가 늘어나면서 문제가 발생했다. 한 사용자가 홍콩 리전에서 로그인한 뒤 곧바로 한국 리전 서비스로 접근하면, 세션이 존재하지 않아 재로그인이 필요했다. Redis가 지역 단위로 분리되어 있었기 때문이다. REINDEERS는 “어디서 로그인하든, 어디서든 세션이 유효해야 한다”는 원칙을 세웠다. 이를 위해 Redis 세션 클러스터 간 실시간 복제와, MQ 기반의 캐시 무효화 구조를 설계했다. 2. 전체 구조 개요 세션·캐시 구조는 다음 세 가지 계층으로 나뉜다. Redis Cluster: 리전별 세션/캐시 저장소 (HK, KR) MQ Broker: Redis 간 동기화 이벤트 전달 (LavinMQ) Cloud Function: 세션 복제 및 캐시 무효화 수행 [User Session] → [Redis HK] ↔ (MQ Event: session.update) ↔ [Cloud Function] → [Redis KR Replica] 모든 세션·캐시 변경은 “이벤트”로 MQ에 게시되고, Cloud F...

통합 회원 관리(SSO/OIDC)와 로컬스토리지 기반 인증 구조 요약: REINDEERS의 글로벌 플랫폼 운영을 위해 회원, 조직, 권한, 인증 시스템이 통합되었다. 6월, 기존의 국가별 로그인 구조를 모두 폐기하고, OIDC(OpenID Connect) 기반의 단일 인증 서버(MCP Auth)를 구축했다. 인증 토큰은 PASETO와 JWT를 병행해 발급되며, 클라이언트 단에서는 LocalStorage를 이용해 토큰을 안전하게 저장·관리한다. 모든 인증 알림은 Telegram을 통해 운영자에게 전송된다. 1. 배경 — “로그인은 하나, 서비스는 전 세계” 이전까지는 각 국가별로 별도의 회원 시스템을 운영했다. 태국, 한국, 중국, 말레이시아의 서비스가 모두 다른 사용자 DB를 가졌고, 글로벌 공급사는 국가별로 중복 계정을 등록해야 했다. 또한 로그인 토큰이 서버별로 상이해 SSO가 불가능했다. 6월에 이 구조를 완전히 개편하며, 단일 로그인으로 모든 국가의 서비스에 접근할 수 있도록 통합 작업이 진행되었다. 2. MCP Auth 아키텍처 인증 서버는 MCP Auth라는 이름으로 독립 구축되었다. 모든 프런트엔드(Nuxt/Vue3), API Gateway, Cloud Function은 이 Auth 서버를 통해 인증을 수행한다. Auth Server: FastAPI + PostgreSQL + Redis Token: PASETO(v2.local) + JWT(v5 hybrid) Cache: Redis 복제 (홍콩 ↔ 서울) SSO Provider: Google, LINE, WeChat, Kakao Notification: Telegram Bot (...

데이터 품질관리, CI/CD 검증, Telegram 알림 및 Rollback 구조 요약: REINDEERS는 6월 말, 데이터 품질을 코드 품질과 동일한 수준으로 관리하기 시작했다. 모든 배포는 이제 코드 테스트뿐 아니라 데이터 정합성 검증을 통과해야만 진행된다. 오류가 발생하면 Drone CI 단계에서 자동으로 중단되며, Telegram Bot을 통해 운영자에게 즉시 보고된다. Telegram 명령어를 통해 승인·롤백까지 원격으로 처리할 수 있다. 1. 배경 — “데이터가 코드다” REINDEERS 플랫폼은 다국가·다통화 데이터를 실시간으로 처리한다. 그러나 시스템이 복잡해질수록 코드보다 더 위험한 것은 “데이터 불일치”였다. 6월 초, PO 테이블의 통화 코드 누락으로 결제 금액 계산 오류가 발생했다. 개발 로직에는 문제가 없었지만, 데이터 무결성이 깨져 있었다. 이 사건을 계기로 REINDEERS는 데이터 품질관리(DQM, Data Quality Management)를 DevOps 파이프라인에 통합하기로 했다. 2. 품질관리 체계의 원칙 ① 모든 품질검증은 SQL 기반 선언형 규칙으로 정의된다. ② 검증은 Drone CI 단계에서 자동으로 실행된다. ③ 오류 발생 시 Telegram으로 실시간 보고된다. ④ Telegram 명령을 통해 승인·롤백을 원격 수행할 수 있다. 이로써 “사람이 직접 확인하는 검증”은 사라지고, 시스템이 스스로 데이터의 정합성을 감시하는 구조로 바뀌었다. 3. Quality Schema — SQL 기반 검증 정의 모든 데이터 ...

i18n·다국어·다통화 엔진 및 DTS/Redis 일관성 구조 요약: REINDEERS의 글로벌화를 가능하게 한 핵심은 단순히 데이터베이스 확장이 아니었다. 언어(i18n)·통화(currency)·데이터 일관성(DTS/Redis)이 완벽하게 연결된 하나의 기술 체계였다. 이번 편에서는 다국어/다통화 엔진의 내부 구조와, 홍콩-서울 리전 간 동기화 및 캐시 일관성을 유지하는 기술을 다룬다. 1. 문제 정의 — “언어, 통화, 그리고 시간” 글로벌 플랫폼을 설계할 때 가장 어려운 점은 단순히 번역이 아니다. 사용자의 언어와 통화, 그리고 거래가 발생하는 시간대(timezone)가 동시에 일관성을 가져야 한다 는 것이다. 예를 들어, 태국 고객이 THB(바트)로 주문을 생성하고, 한국 공급사가 KRW(원화) 기준으로 송장을 발행하면, 모든 계산은 “실제 결제일 환율”을 기준으로 변환되어야 한다. 또, 시스템은 태국어·영어·한국어로 각각 동일한 상품 정보를 제공해야 한다. 이 복잡성을 해결하기 위해 REINDEERS는 6월에 **i18n + Currency + DTS + Redis** 통합 구조를 완성했다. 2. i18n 엔진 — 언어 데이터의 추상화 REINDEERS의 다국어(i18n) 엔진은 단순한 문자열 번역이 아니다. 언어 데이터는 모든 비즈니스 엔터티(Product, Category, Notice 등)와 독립적으로 관리된다. 이를 위해 i18n_text 테이블을 도입했다. CREATE TABLE i18n_text ( id BIGINT PRIMARY KEY AUTO_INCREMENT, key_name VARCHAR(255) NOT NU...

글로벌 DB 레이어링과 데이터 구조 재설계 REINDEERS TECH CHRONICLES 요약: 2025년 6월, REINDEERS 개발팀은 플랫폼의 핵심 구조를 완전히 재설계했다. 목표는 단순했다 — “다국가, 다언어, 다통화를 단일 DB 모델 안에서 일관성 있게 운영하자.” 그 결과, 총 250개 이상의 테이블이 계층적 레이어로 구분되었고, 각 레이어는 서로 독립적으로 확장 가능한 구조로 설계되었다. 1. 데이터 구조 개편의 배경 기존 구조는 AWS 싱가포르 단일 리전에 집중되어 있었고, 데이터 테이블은 약 50~60개 수준이었다. 문제는 명확했다. 각국의 통화, 언어, 세율, 운송 단가 등이 모두 하드코딩 되어 있었고, 국가별 운영 정책에 맞춘 데이터 확장이 사실상 불가능했다. 특히, PO(구매 주문)와 Invoice(송장) 간 데이터 일관성이 보장되지 않아, 회계/정산 단계에서 오류가 빈번하게 발생했다. CEO가 제시한 요구사항은 간단했지만 깊었다. “데이터의 출발점이 한국이 아니라, 세계 어디서든 동일한 구조 로 작동해야 한다.” 이 한 문장이 전체 리디자인의 기준이 되었다. 2. 6-Layer Architecture: 데이터의 논리적 분리 DB 구조는 기능적 목적에 따라 6개의 계층으로 나뉘었다. 각 계층은 물리적으로 같은 MySQL 인스턴스 내에 존재하지만, 논리적으로는 독립된 스키마로 분리되어 있다. Layer-M: Master — 국가, 통화, 세율, 언어 등 글로벌 기준값 Layer-P: Partner — 고객사/공급사, 연락처, 계약정보 La...

개발 환경과 문화의 표준화 — 코드, 협업, 그리고 사람의 일하는 방식 요약: REINDEERS는 5월, 시스템 구조뿐 아니라 ‘개발 문화’ 자체를 새로 만들었다. 기획자·개발자·디자이너 구분을 없애고, AI 기반 워크플로우와 자동화된 리뷰·배포·검증 체계를 도입해 “사람이 아니라 시스템이 일하는 조직”을 완성했다. 1. 개발 환경의 목표 — ‘사람 없이도 일관된 결과’ REINDEERS의 개발 환경은 단 하나의 목표를 갖고 설계되었다. “사람이 없어도 코드 품질과 배포 결과가 동일해야 한다.” 이를 위해 모든 개발 환경은 완전히 동일한 컨테이너 기반으로 세팅되었고, 환경 편차나 로컬 의존성 문제는 제거되었다. 개인의 환경은 존재하지 않으며, 모든 환경은 dev , staging , production 세 단계로 통합 관리된다. 표준 개발 환경 구조 # Dockerfile (공용 개발환경) FROM node:20-bullseye RUN apt-get update && \ apt-get install -y python3 python3-pip vim curl git && \ pip install pre-commit flake8 WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . CMD ["npm", "run", "dev"] 모든 개발자는 동일한 컨테이너 이미지를 사용하며, 코드 수정 시 Drone의 pre-flight build 가 자동 수행되어 린트, 테스트, 의존성 검증이 완료되어야만 PR이 생성된다. ...