Back to the Basics Back to the Basics

디지털 전환(Digital Transformation, 이하 DX)은 더 이상 ‘선택’의 문제가 아닙니다. 특히 제조 산업에서는 스마트팩토리라는 구체적 형태로 그 움직임이 빠르게 전개되고 있고, 그 성공 여부는 결국 조직 구조와 운영 체계에 달려 있습니다. 아무리 훌륭한 시스템을 도입하더라도, OT(Operation Technology), IT(Information Technology), DA(Data Analytics)가 각자 고립된 방식으로 움직인다면 실질적인 스마트화를 이뤄내기 어렵습니다. 이번 글에서는 OT·IT·분석팀이 어떻게 통합된 모델로 작동할 수 있는지, 그리고 이를 위해 어떤 조직 설계 전략이 필요한지를 중점적으로 다룹니다. OT와 IT의 역사적 분리와 갈등의 본질 많은 기업에서 디지털..

FastAPI 서비스 운영 시 반드시 점검해야 할 보안 설정과 환경 구성 방법을 정리합니다. 서버 실행 옵션, HTTPS 적용, 미들웨어 보안 설정 등 실전 배포 전 필수 체크리스트를 제공합니다. 왜 운영 환경 최적화가 중요한가? FastAPI는 개발 속도가 빠르고 문서화도 자동으로 되지만,운영 환경에서 기본 설정 그대로 사용하면 다음과 같은 문제가 발생할 수 있습니다: 서버 재시작 없이 코드가 반영되는 --reload 모드 유지Swagger UI로 민감한 API 노출토큰 만료/암호화 처리 미흡파일 업로드 크기 무제한 설정HTTPS 미적용으로 인해 토큰/쿠키 유출 가능 운영 환경에서는 반드시 보안과 안정성 중심으로 구성을 재점검해야 합니다. 1. 서버 실행 설정 점검 (Uvicorn/Gunicorn)..

전자정부 표준프레임워크 기반 프로젝트를 Gradle과 Spring Boot 기반으로 전환하고자 할 때, 기존 구조를 어떻게 유지하면서 모던 빌드 환경을 적용할 수 있는지를 실무 중심으로 설명합니다. 1. 왜 Gradle과 Spring Boot 전환을 고민하게 되는가? 전자정부 표준프레임워크는 수년간 Maven과 XML 설정 중심의 개발 환경을 유지해왔습니다.그러나 최근 들어 실무에서는 다음과 같은 이유로 Gradle과 Spring Boot로의 전환 요구가 급증하고 있습니다.요구 이유설명빌드 속도 개선Gradle의 병렬 빌드, 캐싱 기능 덕분에 빌드 시간 대폭 단축Spring Boot의 설정 단순화XML → Java 기반 Config 전환으로 유지보수성 향상현대적 DevOps 연계Docker, GitHu..

애플리케이션이 점차 복잡해질수록 하나의 행위가 여러 결과를 유발하게 됩니다. 예를 들어, 회원 가입을 처리하면서 이메일 인증을 보내고, 추천인 포인트를 지급하고, 가입 로그를 저장하는 등 다양한 후속 로직이 따라붙습니다. 이 모든 것을 하나의 서비스 메서드 안에 처리한다면, 유지보수와 테스트는 점점 더 어려워집니다. 이럴 때 가장 효과적인 해법은 도메인 이벤트(Domain Event) 기반으로 부수 효과를 분리하는 설계입니다. 도메인 이벤트란 무엇인가? 도메인 이벤트는 말 그대로, 도메인 내에서 발생한 의미 있는 사건을 나타냅니다. 예를 들어 “회원이 가입되었다”는 사실 자체가 하나의 이벤트입니다.이벤트는 명령(Command)이 아닌, 발생한 사실을 기술하는 객체입니다.그에 반응하는 로직은 이벤트 리스..

Spring Boot + JPA 환경에서 트랜잭션의 범위와 영속성 컨텍스트의 생명주기를 어떻게 설정해야 하는지 설명합니다. flush 타이밍, LazyInitializationException, 성능 최적화 전략까지 실전 중심으로 구성했습니다. 왜 트랜잭션과 영속성 컨텍스트를 구분해야 하는가? Spring Boot에서 JPA를 사용할 때 @Transactional 어노테이션을 쓰는 것이 익숙하실 겁니다. 그러나 이 어노테이션 하나로 JPA가 “정상 동작한다”고 생각하는 것은 착각입니다.실제로 JPA의 핵심 로직은 **영속성 컨텍스트(Persistence Context)**라는 개념 위에서 돌아갑니다. 그리고 이 컨텍스트의 생성과 종료 시점은 트랜잭션 경계와 밀접하게 연결되어 있습니다. 1. 트랜잭션과..

RAG 시스템에서 문서 기반 응답을 구성하려면 다양한 문서 포맷을 파싱하고 의미 있는 단위로 분할하는 청크 전략이 핵심입니다. Spring AI의 문서 처리 컴포넌트 사용법과 실전에서 적용 가능한 Text Chunking 기법을 정리합니다. 문서를 넣으면 “LLM이 알아서 다 한다”? 많은 개발자들이 이렇게 생각합니다. “PDF나 HTML을 넣으면 GPT가 알아서 문서를 읽고 답해주겠지.” 그러나 실제로는 그렇지 않습니다.LLM은 길고 복잡한 문서를 한 번에 잘라내서 던져주면 오히려 문맥을 잃고 무의미한 답을 할 확률이 높습니다. 따라서 문서를 LLM이 이해할 수 있는 단위로 잘게 쪼개는 작업,즉 Text Chunking 전략이 RAG 시스템의 응답 품질을 좌우합니다. Spring AI의 문서 처리 ..

스마트팩토리라는 단어는 모든 제조 산업에 통용되는 것처럼 들리지만, 실제로는 산업군마다 적용 전략과 기술 우선순위가 전혀 다릅니다. 자동차의 스마트 제조와 제약의 스마트 제조는 구조도, 목표도, 기준도 완전히 다릅니다. 이번 글에서는 산업군별로 스마트 제조를 도입할 때의 공통 구조와 차별화된 우선순위를 비교하고, 실제 사례 중심으로 분석합니다. 1. 산업별 스마트 제조의 구조적 공통점 모든 산업군에서 공통적으로 적용되는 구성요소는 다음과 같습니다: 데이터 수집 체계 (IIoT, SCADA)공정 실행 시스템 (MES, DCS, BMS 등)계획/자원 시스템 (ERP, APS, LIMS 등)품질/이력 관리 체계 (eBR, QMS, Batch Record)데이터 분석/AI 플랫폼 (모델링, 예측, 이상 탐지)..

제조 환경이 점점 복잡해지고, 기술 스택도 다양해지는 가운데 가장 큰 도전은 시스템 간 ‘단절’을 해소하는 일입니다. MES, ERP, SCADA, AI 분석 플랫폼, 클라우드 인프라… 각각은 강력한 기능을 갖췄지만 서로 연결되지 않으면 ‘스마트’하지 않습니다. 이번 글에서는 스마트 제조 시스템을 통합적으로 구성하기 위한 아키텍처 전략을 다룹니다. 단순한 시스템 연동이 아닌, 흐름 기반 통합 설계 철학과 실제 적용 모델을 중심으로 정리합니다. 1. 왜 통합이 필요한가: 단절의 비용 많은 제조기업이 이미 MES, ERP, 설비제어 시스템을 갖추고 있지만 아래와 같은 문제가 발생합니다: 계획과 실적 간 괴리 → ERP ↔ MES 연동 미비설비 상태와 작업자 대응 간 시차 → SCADA ↔ MES 단절품질 ..