스마트팩토리 관제 프로젝트 개발일지 (2026.06.10)
오늘의 목표
오늘은 스마트팩토리 관제 시스템 구현을 위한 데이터 저장 구조와 실시간 데이터 처리 방식에 대해 논의하고, 데이터베이스 구축 및 프론트/백엔드 개발을 진행했다.
오전 작업
데이터 저장 구조 논의
현재 프로젝트는 실제 제조 데이터를 사용하는 것이 아니라 샘플 데이터를 기반으로 공정 흐름과 AGV 이동을 시뮬레이션해야 한다.
이를 위해 샘플 데이터베이스(Sample DB)와 운영 데이터베이스(Main DB)를 분리하여 운영하는 방안을 논의했다.
검토한 방식
1. 특정 기간 데이터를 저장하고 시스템 시간을 조작하는 방식
- Sample DB에 6/1 ~ 6/7 데이터를 저장
- 시스템이 현재 시간을 기준으로 해당 데이터를 조회
장점
- 실제 데이터 흐름처럼 구현 가능
단점
- 시간 계산 로직이 복잡해짐
2. 스케줄러를 통해 Sample DB에 지속적으로 데이터 적재
- 일정 주기로 Sample DB에 데이터를 삽입
- Main DB가 실시간으로 조회
장점
- 실제 운영 환경과 가장 유사
단점
- 데이터 생성 로직 추가 필요
3. Sample DB에 데이터를 미리 적재 후 순차 조회
- 날짜와 무관하게 첫 번째 데이터부터 순서대로 사용
장점
- 구현이 가장 단순
단점
- 실제 운영 데이터와 차이가 존재
4. 예약 작업을 이용한 실시간 데이터 생성
- INSERT 명령을 예약 실행
- 실제 데이터가 들어오는 것처럼 구성
장점
- 실시간 환경 재현 가능
단점
- 관리 포인트 증가
추가 진행 사항
오전 시간에는 다음 작업도 함께 진행했다.
- 데이터베이스 테이블 생성
- 데이터셋 정제 작업
- 공정 흐름도 구조 정리
- 병목 탐지 모델링 구현
- Redis 생성
- 샘플 데이터 정제
오후 작업
Redis 연결 환경 정리
현재 Redis는 AWS ElastiCache 환경에서 운영된다.
개발 초기에는 Bastion 서버를 이용한 SSH 터널링 방식으로 접속할 수 있도록 구성했다.
로컬 개발 환경
REDIS_HOST=127.0.0.1
REDIS_PORT=16379EKS 배포 환경
REDIS_HOST=Redis Primary Endpoint
REDIS_PORT=6379Redis SSH 터널 연결
ssh -i "C:\Users\user\Downloads\*.pem" \
-L 16379:REDIS_PRIMARY_ENDPOINT:6379 \
ubuntu@BASTION_ELASTIC_IP해당 터널이 활성화되어 있는 동안에는 로컬 PC에서 Redis를 다음과 같이 사용할 수 있다.
127.0.0.1:16379DB와 Redis 터널 통합
매번 DB 터널과 Redis 터널을 따로 여는 것이 번거롭기 때문에 SSH Config를 이용하여 하나의 명령으로 사용할 수 있도록 구성했다.
Host aims-db
HostName BASTION_ELASTIC_IP
Port 22
User ubuntu
IdentityFile C:/Users/user/Downloads/*.pem
LocalForward 13306 RDS_ENDPOINT_ADDRESS:3306
LocalForward 16379 REDIS_PRIMARY_ENDPOINT:6379
ServerAliveInterval 60
ExitOnForwardFailure yes이후에는 다음 명령만 실행하면 된다.
ssh aims-db데이터셋 적재
오후에는 Sample DB와 Main DB에 데이터셋을 적재했다.
진행 과정에서 발견한 문제는 다음과 같았다.
- 데이터셋 구조와 설계한 테이블 구조가 일치하지 않음
- 날짜 저장 정책 변경 필요
- 일부 컬럼 정규화 필요
이를 반영하여 데이터셋을 수정한 뒤 최종적으로 데이터를 저장했다.
병목 탐지 모델링
공정별 생산 흐름을 기반으로 병목 현상을 탐지하기 위한 모델링 작업을 추가로 진행했다.
향후에는 다음과 같은 기능으로 확장할 예정이다.
- 공정별 대기시간 계산
- 공정별 처리량 비교
- AGV 이동 지연 분석
- 병목 공정 자동 탐지
백엔드 개발
백엔드에서는 기본 개발 환경을 구축했다.
구현 항목은 다음과 같다.
- Entity
- DTO
- Repository
- Controller
- Service 구조 설계
향후 API 개발을 위한 기본 틀을 구성했다.
인프라 설계
AWS 환경에서 EKS Cluster 구축을 위한 설계를 진행했다.
현재 검토 중인 구성 요소는 다음과 같다.
- EKS
- ALB
- Redis (ElastiCache)
- RDS
- GitHub Actions
- ArgoCD
프론트엔드 수정
샘플 데이터 및 공정 구조 변경 사항을 반영하기 위해 메인 페이지를 수정했다.
주요 변경 사항은 다음과 같다.
- 공정 흐름도 재설계
- AGV 이동 경로 수정
- 공정 간 이동 라인 추가
- AGV 수량 증가에 따른 UI 조정
실제 제조 라인처럼 AGV가 공정 사이를 왕복 이동하는 형태로 변경하는 작업을 진행했다.
강사님 피드백
EC2를 터널 전용으로 사용하는 문제
현재 Bastion 서버를 통해 DB 및 Redis 터널을 연결하고 있으나, 강사님께서는 단순 통로 역할만 수행하는 EC2는 자원 낭비가 발생할 수 있다고 조언해 주셨다.
개선 방향
- Redmine 서버를 활용한 접속 구조 검토
- VPC를 Redmine용과 서비스용으로 분리
- Bastion 서버는 t3.micro 최소 사양 사용
GitHub Actions 운영 방식
GitHub Actions는 브랜치별로 자동 실행되도록 구성하는 것이 좋다는 의견을 받았다.
권장 구조
- 테스트용 Workflow
- 실제 배포용 Workflow
YAML 파일을 분리하여 운영 환경과 테스트 환경을 구분하는 방향으로 설계할 예정이다.
협업 프로세스
추가로 다음과 같은 팀 운영 방안도 제안받았다.
- Daily Meeting 진행
- Git Push 주기 정하기
- 코드 리뷰 문화 정착
- 공통 개발 규칙 수립
프로젝트 규모가 커질수록 개발 생산성보다 협업 프로세스가 더욱 중요해질 수 있기 때문에 팀 차원의 규칙을 정하는 것이 필요하다는 의견이었다.
마무리
오늘은 단순히 기능 개발만 진행한 것이 아니라 앞으로의 실시간 데이터 처리 구조와 운영 방식을 결정하는 중요한 논의를 진행한 하루였다.
특히 Sample DB와 Main DB를 분리하여 운영하는 구조, Redis 연결 방식, 병목 탐지 모델링 등은 향후 스마트팩토리 관제 시스템의 핵심 기반이 될 것으로 보인다.
내일부터는 API 개발과 실시간 AGV 시뮬레이터 구현을 본격적으로 진행할 예정이다.
