Skip to main content

Posts

글로벌 DB 레이어링과 데이터 구조 재설계

글로벌 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이 생성된다. ...

데이터와 자동화 — 요구조건을 만족시키는 '새로운' 플랫폼만이 해답이었다

데이터와 자동화 — 요구조건을 만족시키는 '새로운' 플랫폼만이 해답이었다 핵심: 기존 결과물의 플랫폼 구조로는 CEO가 요구한 서비스를 만들 수 없다. 우리는 아키텍처·데이터·자동화·보안을 전부 새로 설계 했고, 그 설계만이 글로벌·다국어·다통화·실시간 흐름(Quote→PO→Invoice→Delivery→Settlement)을 단일 트랜잭션 체인으로 구현한다. 1. 요구조건에서 시작한 ‘새 플랫폼’ 선언 Quote → PO → Invoice → Delivery → Settlement 전체 흐름이 단일 데이터 체인 으로 연결될 것 국가/언어/통화/세율/물류 규칙을 데이터 레이어 에서 통합 관리할 것 데이터 변화가 이벤트(AMQP) 를 통해 실시간 전파되고 캐시와 UI가 자동 갱신될 것 사람이 문서/툴을 조작하지 않아도 AI 워크플로우 가 명세→스키마→API→배포를 자동 생성할 것 이 요구는 곧 플랫폼의 재정의 였다. “코드가 데이터를 설명”하던 과거에서, “ 데이터가 코드를 지배 하는” 구조로의 전환. 이 관점에서 전 계층을 다시 설계했다. 2. 새로운 기술 스택(Infra/Runtime/Automation/Security) Infra & Network Tencent Cloud : ap-hongkong(Primary), ap-seoul(DR) DNSPod Geo Routing + Health Check COS + CDN : 정적 자산 전세계 엣지 배포 TKE/CVM : API 모듈 컨테이너 오케스트레이션 Data & Messaging ...

MCP 아키텍처 설계기 — 글로벌 인프라의 뼈대를 세우다

MCP 아키텍처 설계기 — 글로벌 인프라의 뼈대를 세우다 2025년 5월, REINDEERS 플랫폼의 인프라 재설계가 본격적으로 시작되었다. 4월 한 달 동안 우리는 기존 시스템을 전면 점검했고, AWS 싱가폴 리전에 산재된 비효율적인 구조를 확인했다. CI/CD는 단순 스크립트 수준에 머물렀고, 운영 스테이지도 명확히 구분되지 않았다. 소스 관리조차 통합되지 않아 빌드가 환경마다 달랐다. 결국 우리는 아키텍처를 완전히 다시 세워야 했다. 새로운 MCP(Multi-Cloud Point) 구조는 “홍콩을 메인 리전, 서울을 DR 리전” 으로 설정하고, 각 지역의 접속은 DNSPod의 Geo Routing을 이용해 가장 가까운 리전으로 유도하도록 설계했다. 프런트엔드는 COS(Object Storage)에 정적 배포 후, Tencent CDN으로 자동 퍼블리시되며, Git push 한 번으로 모든 리전이 갱신된다. CI/CD는 Drone 을 도입했다. 단순히 스크립트를 실행하는 수준이 아닌, YAML 기반의 self-service CI로 바꿔서 모든 빌드/배포 파이프라인을 코드로 관리한다. kind: pipeline type: docker name: frontend-build steps: - name: install image: node:20 commands: - npm ci - name: build image: node:20 commands: - npm run build - name: deploy image: tencentcloudtools/cli environment: COS_BUCKET: reindeers-front-hk commands: - tccli cos cp ./dist cos://${COS_BUCKET}/ --recursive 이 Drone 설정은 GitHub Action보다 훨씬 단순하면서도 빠르다. 서버 자원은 모두 CV...

팀과 기술의 리빌드 — 다시 일하는 법을 정비하다

팀과 기술의 리빌드 — 다시 일하는 법을 정비하다 요약: REINDEERS는 시스템을 다시 설계하기 전에 먼저 팀을 해체했다. 기존 인력 전원이 퇴사한 후, 기술 커트라인을 통과한 새로운 엔지니어들로 조직을 재구성했다. 이후 Drone 기반 CI/CD, Git 워크플로우, 테스트 자동화, AI 협업 체계까지 모든 기술 문화가 새롭게 정의되었다. 1. 리빌드의 시작 — 사람부터 바꿨다 2025년 4월 초, REINDEERS는 중대한 결정을 내렸다. 시스템을 새로 만드는 일보다 먼저, 사람을 바꾸기로 한 것이다. 플랫폼은 기술로 움직이지만, 운영의 일관성을 무너뜨리는 것은 언제나 사람이다. 결국 기존 직원들은 모두 퇴사했다. 이전 팀은 실험적이었지만, 운영 가능한 구조를 만들기엔 역부족이었다. 남은 것은 코드 일부와 배포 스크립트뿐이었다. 우리는 그 위에 새로운 문화를 세우기보다, 완전히 새 팀을 만드는 길을 선택했다. “사람을 남긴 게 아니라, 기준을 남겼다.” 2. 새 팀의 탄생 — 기술 커트라인부터 통과해야 했다 신규 채용의 기준은 단순했다. “ 운영 가능한 기술을 이해하는가 .” 단순히 코드를 작성할 줄 아는 개발자가 아니라, 시스템이 어떻게 동작하고 복제되며, 장애를 어떻게 복구해야 하는지를 아는 엔지니어만이 합류할 수 있었다. 기술 커트라인 (필수 항목) Nuxt 3 / Vue3 + SSR 구조 이해 Python / Node.js 기반 API 서버 설계 경험 Drone CI/CD 파이프라인 구축 및 유지 경험 Tencent Cloud CLI 활용 및...

MCP 아키텍처 선언 — 플랫폼의 새로운 청사진

MCP 아키텍처 선언 — 플랫폼의 새로운 청사진 요약: 기존 구조를 완전히 폐기하고, REINDEERS의 모든 시스템은 MCP(Modular Cloud Platform) 형태로 재설계되었다. 각 모듈은 독립 배포, 자동 복구, 글로벌 라우팅이 가능하며, Tencent Cloud 기반의 멀티 리전 구조로 운용된다. 1. MCP(Modular Cloud Platform) 개요 MCP는 REINDEERS의 핵심 인프라 아키텍처로, 모든 기능을 독립된 모듈로 분리하고, 각 모듈이 자체 CI/CD 파이프라인을 통해 배포되며, 장애 시 자동으로 재배포 및 복구되는 구조를 목표로 설계되었다. 모듈화: 모든 서비스(API, AI, 물류, 결제, WMS 등)는 컨테이너 단위로 격리 복제: 리전 간 데이터 실시간 복제 (DTS + GTID 기반) 자동화: Drone CI/CD, COS 업로드, CDN 캐시 자동 무효화 보안: IAM 최소 권한, HTTPS + mTLS 내부 통신, VPC 내 Private Endpoint 2. 글로벌 인프라 구조 — 홍콩 메인 / 서울 DR REINDEERS MCP는 Tencent Cloud 상에 구축되어 있으며, 홍콩(ap-hongkong)을 메인 리전, 서울(ap-seoul)을 재해복구 리전으로 구성한다. 데이터는 TencentDB for MySQL 의 DTS(Data Transmission Service) 를 통해 실시간으로 비동기 복제된다. 아키텍처 구성 [Global Routing] DNSPod Geo Routing (TTL=60s, Health Monitor Enabled) ↓ [ap-h...

새로운 출발을 위한 점검 — 4년의 코드를 다시 열어보다

새로운 출발을 위한 점검 — 4년의 코드를 다시 열어보다 요약: 기존 AWS 싱가포르 기반의 React + Java 구조를 완전히 해체하고, Tencent Cloud 로 전환했다. 프런트는 Nuxt + Vue3 로 재구성, 배포는 Drone CI/CD 와 COS/CDN 자동화로 처리한다. 백엔드는 내부 전용 서비스로 비공개 운영한다. 1. 초기 상황 — AWS 싱가포르, 복잡하게 얽힌 실험의 흔적 REINDEERS 초기 버전은 AWS ap-southeast-1 (Singapore) 리전 위에서 운영되었다. 하지만 이는 서비스 운영을 위한 구조가 아니라 “학습” 중심의 환경에 가까웠다. EC2, S3, RDS, CloudFront, Lambda 등 AWS 주요 기능이 모두 혼재했지만, 어떤 구성요소도 서로 명확히 연결되어 있지 않았다. 인프라 구성 예시 (기존 AWS) VPC (10.0.0.0/16) ├── Subnet-Public (10.0.1.0/24) │ ├── EC2: react-build-server │ └── EC2: spring-api-server ├── Subnet-Private (10.0.2.0/24) │ ├── RDS: mysql-v1 │ └── ElasticCache: disabled └── SecurityGroup: default (80/443 open to 0.0.0.0/0) IAM은 Root Key로 접근했고, Auto Scaling Group은 설정만 되어 있을 뿐 실제 트리거가 비활성화되어 있었다. CloudFront는 S3 버킷에 연결되어 있었지만, TTL(캐시 수명) 설정이 24시간으로 고정되어 실시간 반영이 어려웠다. API 응답 속도는 태국에서 평균 620ms, 말레이시아에서 710ms...