DnDn은 건설 현장에서 발생하는 인력, 근태, 안전, 공정, 문서, 환경 데이터를 실시간으로 수집하고 관리하는 플랫폼입니다.
현장 소장과 관리자는 근로자 현황, 게이트 혼잡도, 공정 진행률, 일일 보고, ESG 지표를 한 화면에서 확인하고 데이터 기반으로 의사결정할 수 있습니다.
| 구분 |
기술 |
| 언어 |
 |
| 프레임워크 |
   |
| 데이터 |
    |
| 메시징 |
 |
| AI·파일 |
     |
| API |
  |
| 구분 |
기술 |
| CI/CD |
   |
| 실행 환경 |
  |
| 게이트웨이 |
 |
| 모니터링 |
   |
| Storage Class |
 |
|
| 분류 |
기술 |
| Version Control |
  |
| API Test |
 |
| Design / Docs |
  |
| Communication |
 |
|
프로젝트 기획서, WBS, 요구사항 명세서, 화면 설계서, API 영상, ERD 등 상세 문서는 Wiki에서 확인할 수 있습니다.
| 모듈 |
역할 |
dndn-core |
인증, 근로자, 게이트, 인력 배치, 공정표, 작업 계획, 일보, ESG, 날씨 등 핵심 도메인 API |
dndn-document-management |
문서 업로드, 문서 검색, Elasticsearch 연동, 문서 이벤트 처리 |
dndn-gateway |
Spring Cloud Gateway 기반 라우팅, Eureka 연동, JWT 처리 |
dndn-discovery |
Eureka Server 기반 서비스 디스커버리 |
| 항목 |
적용 기술 |
도입 이유 |
| 인증 |
JWT, Spring Security |
서버 세션을 사용하지 않는 Stateless 인증 구조를 구성했습니다. Access Token에는 사용자 식별자와 역할 정보를 담고, 요청마다 JWT를 검증해 인증 상태를 복원합니다. |
| 인가 |
RBAC + 도메인 권한 검증 |
ADMIN, HEADQUARTOR, SITE_MANAGER, SITE_DIRECTOR, SECTION_LEADER, SECTION_SUPERVISOR 역할 기반 접근 제어를 적용했습니다. 일부 기능은 역할뿐 아니라 현장 코드와 공종 범위까지 확인해 실제 업무 권한에 맞게 접근을 제한합니다. |
| API Gateway |
Spring Cloud Gateway GlobalFilter |
/api/msa/** 요청은 Gateway에서 JWT를 먼저 검증하고, 검증된 사용자 정보를 X-User-Idx, X-User-Role, X-User-LoginId 헤더로 하위 서비스에 전달합니다. |
| Kafka |
서비스 간 비동기 이벤트 연동 |
Core에서 문서 업로드, 작업 지시 변경, 공사 일보 변경 이벤트를 발행하고 Document Management가 이를 소비해 문서 검색 인덱스를 갱신합니다. Core 트랜잭션과 검색 인덱싱을 분리해 장애 전파를 줄였습니다. |
| Elasticsearch |
문서 통합 검색 |
공정표, 작업 지시, 공사 일보 등 문서성 데이터를 여러 필드 기준으로 검색해야 했기 때문에 Elasticsearch를 도입했습니다. 키워드 검색은 ES를 사용하고, ES 장애 시 RDB 검색으로 fallback하도록 구성했습니다. |
| Redis |
캐시, 분산락 |
ESG 대시보드처럼 반복 조회되는 데이터를 캐싱하고, 다중 Pod 환경에서 스케줄러가 중복 실행되지 않도록 Redisson 기반 분산락을 사용했습니다. |
| Batch |
Kubernetes CronJob / Job Trigger |
인력 동기화처럼 오래 걸리거나 주기적으로 실행되는 작업은 API 서버 내부 요청 흐름과 분리했습니다. Core API에서 Kubernetes CronJob 기반 Job을 수동 트리거할 수 있도록 구성했습니다. |
DnDn 백엔드는 Kubernetes 환경에서 Nginx Ingress를 통해 외부 트래픽을 받고, Jenkins와 Kaniko를 이용해 Blue-Green 방식으로 배포됩니다.
Jenkins 빌드 시작
↓
Kaniko로 이미지 빌드 → Docker Hub Push
↓
현재 Active 색 감지 (Ingress service name 기준)
↓
비활성 Deployment에 새 이미지 set + replicas 확장
↓
rollout status 대기 (파드 준비 완료 확인)
↓
Ingress 전환 (backend-service-blue ↔ backend-service-green)
↓
이전 Deployment replicas=0 으로 축소
| 대상 |
선택 이유 |
| Core |
로그인, 인증, 프로젝트 등 사용자 흐름의 중심 API입니다. 새 버전이 정상 기동되기 전에 기존 버전이 내려가면 서비스 전체가 영향받기 때문에, inactive 환경에서 먼저 검증한 뒤 트래픽을 전환하는 Blue-Green 구조가 필요했습니다. |
| Document Management |
MariaDB, Kafka, Elasticsearch, S3, Eureka 등 외부 의존성이 많아 배포 시 환경변수 누락, 인증서 Secret 누락, DB 접속 지연, Kafka 설정 문제 등이 발생할 수 있습니다. 새 버전을 기존 Pod에 바로 덮어쓰지 않고 inactive 버전에 먼저 올려 정상 여부를 확인한 뒤 트래픽을 넘기기 위해 Blue-Green을 선택했습니다. |
Ingress와 Gateway는 blue/green Deployment를 직접 바라보지 않습니다.
항상 고정된 Kubernetes Service를 바라보며, 실제 버전 전환은 Service의 selector만 변경해 처리합니다.
Copyright © 2026 Intelli_J Team. All rights reserved.
