Back to the Basics Back to the Basics

제조 AI는 이제 선택이 아니라 필수입니다. 품질 예측, 수율 향상, 병목 탐지까지 다양한 제조 AI 모델을 어떤 흐름 위에, 어떤 데이터 기반으로 설계하고 현장에 적용할 수 있는지 현실적인 시선으로 풀어봅니다.제조 현장에 AI를 쓴다는 건 뭘까?요즘 누구나 AI 얘기합니다. 제조도 예외는 아니죠."AI로 불량률 줄이자", "예지보전 하자", "데이터만 모으면 AI가 다 해줄 거야"…그런데 현실은 다릅니다.모델은 만들었는데 현장에서 못 쓰는 경우도 많고,데이터는 많은데 학습이 안 되는 경우도 많고,성과가 안 보여서 프로젝트가 멈추는 경우도 많습니다.그래서 이번 글은 딱 현실적으로,제조 AI를 어떤 흐름에서, 어떤 방식으로 설계해야,진짜 쓸만한 도구가 되는지 이야기해보려 합니다.1. 제조 AI의 대표 활용..

Spring MVC에서 요청이 들어오면 어떤 경로를 따라 응답이 만들어질까요? DispatcherServlet을 중심으로, HandlerMapping, Controller, ViewResolver까지의 흐름을 자연스럽게 정리합니다.Spring MVC의 진짜 시작점은?우리는 보통 컨트롤러부터 코드를 쓰기 시작합니다.@GetMapping("/hello")public String hello() { return "hello";}근데 정말 이게 전부일까요?이렇게 작성된 코드는 어떻게 실행되고, 어떻게 우리가 작성한 뷰 이름을 찾아가는 걸까요?그 중심에는 바로 DispatcherServlet이 있습니다.사실상 Spring MVC의 모든 요청은 DispatcherServlet을 거쳐서 흐릅니다.Dispatche..

Spring AI에서 제공하는 PromptTemplate 기능을 바탕으로, LLM 응답을 더 정밀하게 제어할 수 있는 프롬프트 설계 전략을 살펴봅니다. 다양한 실전 예시와 함께 Prompt Engineering의 핵심 개념을 정리합니다. 우리가 GPT나 Hugging Face 모델을 쓸 때 가장 많이 하는 실수 중 하나는 이겁니다.그냥 질문만 던지고 결과가 별로면 모델 탓을 한다는 거죠.사실 LLM의 성능은 모델의 파라미터 수나 학습 데이터만으로 결정되지 않습니다.**어떻게 질문하느냐(Prompting)**도 그 못지않게 중요합니다.프롬프트 엔지니어링(Prompt Engineering)은 이 “질문 설계”를 통해 원하는 출력을 이끌어내는 기술입니다.Spring AI는 이걸 위한 도구로 PromptTemp..

헥사고날 아키텍처는 ‘깔끔한 구조’를 위한 트렌드가 아닙니다. 외부로부터 자유로운 도메인 설계를 위한 철학입니다. 이 글에서는 헥사고날 아키텍처의 본질과 구조, 도입 배경을 현실적인 시각에서 풀어봅니다. 솔직히 말하면, 헥사고날 아키텍처라는 이름을 처음 들었을 때,“왜 하필 육각형이지? 도형은 왜 중요한데?”이런 생각, 한 번쯤은 해보셨을 겁니다.하지만 핵심은 형태가 아니라 방향입니다. 헥사고날 아키텍처는 결국 “의존성은 안으로만 향해야 한다”는 단순한 원칙에서 시작합니다.헥사고날 아키텍처, 왜 나왔을까?이 구조를 처음 제안한 사람은 Alistair Cockburn입니다.그는 객체지향 설계를 오랫동안 고민하면서 한 가지 문제에 도달합니다:“왜 항상 비즈니스 로직이 외부 기술에 끌려다니지?”DB를 바꾸면 ..

스프링의 의존성 주입 구조를 테스트에 적합하게 리팩토링하는 방법과 함께, 단위 테스트와 통합 테스트에서 @TestConfiguration, @MockBean, ApplicationContext 활용 전략을 소개합니다. 왜 테스트 가능한 구조가 중요한가? 실무에서 스프링 애플리케이션의 성공 여부는 테스트 전략에 크게 좌우됩니다.하지만 많은 개발자가 기능은 되는데 테스트는 어려운 구조를 만들어냅니다. 그 이유는 다음과 같습니다: new 키워드 남용 → DI 불가내부 의존성 연결이 강함 → Mock 불가Bean 설정이 하드코딩 → 프로파일 분기 실패 이제, 우리가 앞서 만든 DI 기반 계산기 시스템을 테스트 가능한 구조로 바꿔보고, 실제 테스트 코드까지 작성해보겠습니다. 1. 설계 리팩토링 – 인터페이스 ..

계층형 아키텍처는 소프트웨어 설계의 기본입니다. 하지만 진짜 중요한 건 '계층이 몇 개냐'가 아니라 '책임이 올바르게 분리되었느냐'입니다. 이 글에서는 구조를 넘은 설계 철학을 깊이 있게 다룹니다.레이어의 수보다 중요한 것: 책임(Responsibility)많은 개발자들이 아키텍처 설계를 시작할 때 흔히 묻는 질문은 "몇 개의 계층이 적당한가요?"입니다.그러나 더 중요한 질문은 **"각 계층이 어떤 책임을 가져야 하며, 그것이 명확하게 분리되어 있는가?"**입니다.1. 전통적인 계층 구조의 재조명우리는 3~4계층의 구조를 자주 사용합니다.UI (사용자와의 인터페이스)Application Logic (유스케이스, 흐름 제어)Domain (핵심 비즈니스 로직)Infrastructure (DB, API, 메시..

FastAPI에서 사용자 역할(Role)을 기반으로 접근 권한을 제어하는 방법을 설명합니다. Depends를 활용해 인증과 권한 검증을 모듈화하고, 실무에서 필요한 보안 구조를 구축합니다.왜 Role 기반 권한 관리가 필요한가?대부분의 서비스는 사용자 유형이 나뉘며 각자의 권한이 다릅니다:사용자 유형 접근 가능한 리소스일반 사용자본인의 정보, 게시글관리자전체 사용자 목록, 설정 변경운영자일부 모니터링 기능이러한 역할(Role) 기반 권한 관리 시스템은 서비스 품질뿐만 아니라 보안을 위해서도 반드시 필요합니다.1. JWT 토큰에 Role 정보 포함def create_access_token(data: dict): payload = data.copy() payload.update({ "..

스마트 제조의 성과는 측정 가능해야 한다. 본 글에서는 OEE, Takt Time, PPM, CTQ 등 핵심 KPI를 어떻게 정의하고 구조화하며, MES 및 분석 시스템과 연동해 실시간 모니터링과 개선 활동으로 연결할 수 있는지 전략적으로 안내한다.서론 – 측정할 수 없으면, 개선할 수 없다스마트팩토리의 핵심은 지능형 판단과 자동화지만,그 출발점은 결국 정확한 측정과 지표(KPI)의 설계다.제조현장은 수많은 설비와 사람이 동시에 움직이는 복잡한 생태계이며,그 흐름을 정량화하지 않으면 아무리 자동화를 하더라도 본질적인 개선은 어렵다.이번 글에서는 스마트 제조에 최적화된 KPI 항목과 측정 방식, 실시간 모니터링 전략을 산업공학과 데이터 분석 관점에서 정리한다.1. 제조 KPI의 분류 체계운영 효율 지표OE..