# 운영 데이터 AI 코파일럿: 더미 DB와 대시보드를 공개 서비스로 만드는 포트폴리오

인공지능 분야로 옮겨 가려는 소프트웨어 개발자에게 포트폴리오는 모델을 얼마나 많이 호출했는가를 보여 주는 전시장이 아니다. 사용자가 묻는 문제를 데이터 조회·검증·설명·화면 표시라는 여러 책임으로 분해하고, 그 결과를 웹에서 누구나 재현할 수 있게 만드는 작은 서비스가 더 강한 증거가 될 수 있다. 특히 ERP·구매·생산·물류의 데이터와 센서·설비 운영을 경험한 개발자라면, 익숙한 업무 영역을 버리고 범용 챗봇부터 다시 시작할 필요가 없다.

한 가지 구상은 **운영 데이터 분석 대시보드와 자연어 코파일럿**이다. 가상의 공장·물류 데이터가 담긴 관계형 데이터베이스를 만들고, 기존 대시보드로 지표를 보면서 채팅창에 질문할 수 있게 한다. 중요한 점은 AI가 데이터베이스를 ‘안다’고 주장하는 데 있지 않다. **질문을 제한된 조회로 바꾸고, 데이터에 실제로 존재하는 근거만 해석하며, 그 과정과 한계를 사용자에게 다시 보여 주는 것**이 핵심이다. 구현 전의 설계안이며, 현장 적용이나 정량적 성능을 이미 입증한 프로젝트는 아니다.

## 어떤 AI 엔지니어링을 증명할 것인가

AI 포트폴리오에는 적어도 두 갈래가 있다. 기초모델·학습·추론 최적화를 중심으로 하는 연구·모델 개발형 과제와, 이미 존재하는 모델을 도구·데이터·웹 서비스에 연결하는 응용형 과제다. 후자의 경우 중요한 능력은 모델 이름보다 데이터의 구조를 이해하고, 모델이 결정할 일과 코드가 확정적으로 실행할 일을 분리하며, 결과를 평가하고 서비스로 운영하는 능력이다.

산업용 예시로 세 방향이 제시될 수 있다. 생산·설비·물류 로그를 통합하는 **AI 운영 비서**, 구매·생산·재고·출하의 자연어 질문을 SQL·보고서로 바꾸는 **ERP 질의 시스템**, PLC·센서·매뉴얼·점검 이력을 활용하는 **현장 장애 대응 코파일럿**이다. 이 셋은 서로 다른 제품일 수도 있지만, 운영 데이터를 읽는 공통 핵심을 하나의 포트폴리오에서 먼저 검증할 수 있다.

채용 자료에 맞추려는 욕구와 실제로 만들고 싶은 것을 고르려는 욕구는 대립하지 않는다. 취향만 좇으면 외부 평가자가 기능의 의미를 이해하지 못하고, 채용 키워드만 쫓으면 오래 완성하기 어려운 모방품이 된다. ‘취향 30, 시장성 70’이라는 비율은 설계의 대략적인 비유이지 통계적 법칙이 아니다. 첫 결과물은 **관심 있는 현업 문제 하나를, 채용자가 검증할 수 있는 기술 언어로 번역한 서비스**에 집중하는 편이 낫다. 메인 프로젝트 하나와 보조 실험 하나라는 범위 제한도 같은 목적을 갖는다.

## 최소 제품의 세 화면: 지표, 질문, 근거

단일한 공개 웹 주소에 접속하면 즉시 시연할 수 있어야 한다. 로그인이나 설치 과정 없이 샘플 시나리오가 작동하는 것이 이상적인 데모 경험이다. 첫 화면은 ‘제조·물류 운영 데이터를 자연어로 분석하는 AI 코파일럿’이라는 목적을 명확히 알리고, **3월 2라인 이슈**, **납기 지연 분석**, **설비 위험도 요약** 같은 추천 질문을 제시한다.

**대시보드**에서는 공장·라인·기간·품목(SKU)·거래처로 필터링한 지표를 확인한다. KPI 후보는 생산량, 불량률, 가동률 또는 정의가 명시된 OEE 유사지표, 평균 다운타임, 납기 준수율, 재고 부족 건수다. 일별 생산량, 장애 원인별 누적 시간(Pareto), 알람 추이, 거래처별 지연, 품목별 불량률을 차트로 구성하면 채팅 없이도 데이터가 읽힌다. 지표의 계산식·기준 기간·분모를 알 수 없게 만든 장식용 숫자는 지양한다.

**채팅 패널**은 자연어 입력과 추천 질문, 그리고 일관된 응답 형식을 제공한다. 응답은 한 줄 결론, 주요 원인 또는 관찰 2~4개, 근거 데이터, 확인할 다음 조치 순서로 읽히면 좋다. ‘3월 둘째 주 2라인 가동률이 왜 떨어졌는가’, ‘A거래처 납기 지연 증가를 설명해 달라’, ‘이번 주 점검 우선순위가 높은 설비는 무엇인가’ 같은 질문은 지표와 사건 로그를 함께 읽게 만든다.

**근거 패널**이 이 프로젝트의 결정적인 세 번째 축이다. 예를 들어 ‘포장기 모터 과열 두 건과 자재 공급 지연 한 건이 가동률 저하와 함께 관찰된다’는 설명을 내놓았다면, 조회 기간, 참조한 뷰(`line_daily_kpi`, `downtime_events` 등), 사용한 집계 함수 또는 SQL, 반환된 주요 행과 차트도 함께 보여 준다. ‘2026-03-10부터 2026-03-16’, ‘원인 분류별 장애 시간’, ‘근거 이벤트 다섯 건’처럼 검증 가능한 단위가 들어가야 한다. 이 기간과 사건은 **데모를 위한 가상 사례**다.

이로써 결과는 ‘그럴듯한 텍스트’에서 ‘데이터의 어떤 부분이 이 문장을 지탱하는가를 추적할 수 있는 분석’으로 바뀐다. 모든 질문에 원인을 단정할 수 있는 것은 아니다. 장비 고장과 생산량 하락이 함께 발생해도 그 관계가 곧바로 인과관계를 증명하는 것은 아니므로, 관찰·유력한 설명·추가 확인 필요를 문장 안에서 구별해야 한다.

## 대량의 더미 데이터보다 중요한 것은 생성 규칙이다

더미 DB의 목적은 테이블의 행 수를 과시하는 일이 아니다. 사용자가 필터를 바꾸고 질문을 던졌을 때 **일관된 패턴이 여러 테이블을 건너 실제로 재현**되게 하는 데 있다. 한 가지 목표 규모는 6개월치 가상 이력, 공장 2곳, 생산 라인 6개, 설비 30대, SKU 50개, 거래처 20개, 총 10만~50만 행이다. 모두 설계상의 목표치이지 이미 만들어진 데이터의 규모가 아니다.

스키마 후보는 다음과 같다.

| 영역 | 테이블 후보 | 서로 연결되는 핵심 정보 |
| --- | --- | --- |
| 기준정보 | `factories`, `lines`, `machines`, `products` | 공장·라인·설비·SKU와 식별자 |
| 생산·품질 | `work_orders`, `production_hourly`, `quality_results` | 작업지시, 시간별 생산량, 양품·불량 |
| 장애·보전 | `downtime_events`, `alarm_logs`, `maintenance_logs` | 고장 발생·해제, 알람, 점검과 수리 |
| 구매·재고·출하 | `inventory_daily`, `purchase_orders`, `shipments`, `suppliers` | 재고, 발주, 납품·출하, 공급업체 |

합성 데이터에는 명시적인 사건 생성 규칙이 필요하다. 월말 출하 집중, 특정 라인의 야간 불량률 증가, 일정 거래처의 높은 지연 빈도, 설비 한 대의 2주 주기 과열 알람, 재료 부족 다음 날의 생산량 감소, 습한 시기의 센서 노이즈 증가는 모두 **삽입할 수 있는 가상 패턴의 예시**다. 데이터 생성기의 난수 시드와 사건 정의를 고정하면 데모를 반복해도 같은 질문의 근거를 찾을 수 있다. 단, 가상 데이터에 심어 둔 사건 관계를 실제 제조 현장의 보편적 원인으로 발표해서는 안 된다.

기초적으로는 시간과 코드가 맞는지, 작업지시가 존재하지 않는 설비에 매달리지 않는지, 지연 일수와 출하일의 계산이 일치하는지를 점검해야 한다. 이후 모델의 평가에도 사용할 **정답 사건 목록**을 별도로 관리할 수 있다. 이 정답은 AI가 생성한 설명과 별개의 기준이다.

## AI가 SQL을 함부로 실행하지 않도록 분리한다

초기 버전에서 자연어를 무제한 SQL로 직접 번역하면 인상적인 시연을 얻을 수 있을지 몰라도, 잘못된 집계·무거운 쿼리·권한 없는 테이블 접근·불안정한 답변이 함께 증가할 수 있다. 특히 누구나 들어오는 공개 사이트라면 입력을 신뢰하는 방식으로 설계해서는 안 된다.

권장된 첫 경로는 다음과 같다.

1. 사용자의 질문을 지표 조회·원인 분석·기간 비교·리스크 요약 등 허용한 범주로 분류한다.
2. 모델이 구조화된 출력으로 도구 이름과 공장·라인·기간 같은 인자만 제시한다.
3. 서버가 인자의 형식과 범위를 검사한 뒤 **미리 작성한 읽기 전용 조회 함수**를 실행한다.
4. 서버는 결과 행과 집계 메타데이터를 모델에 전달하고 근거를 벗어나지 않는 설명을 요청한다.
5. 프론트엔드는 설명·계산값·차트·근거 테이블·사용한 도구 이름을 분리해 보여 준다.

조회 도구의 예시는 `get_line_kpis(line_id, from, to)`, `get_top_downtime_causes(factory_id, from, to)`, `get_supplier_delay_summary(from, to)`, `get_machine_risk_score(factory_id)`다. 위험도 점수를 넣을 경우 그 점수가 과거 장애 이력의 간단한 규칙인지 예측 모델의 결과인지 반드시 명시한다. 이름이 ‘AI 위험도’라는 이유만으로 예측 성능이 입증되는 것은 아니다.

두 번째 단계에서 **제한적 Text-to-SQL**을 실험할 수 있다. SELECT만 허용하고, 테이블과 열을 화이트리스트로 제한하며, 실행 전 구문 분석·결과 행 수 제한·읽기 전용 DB 계정을 갖추는 방식이다. 가능하면 생성 쿼리와 실행 쿼리를 나누고, 실패한 질의는 거절 이유를 보여 준다. ‘AI가 모든 DB를 직접 읽는다’는 구조를 자랑하기보다, **모델의 제안과 서버의 실행 권한이 분리되어 있다**는 점을 시연하는 편이 운영 서비스에 가깝다.

문서 매뉴얼과 장애 대응 이력을 뒤에 붙이는 RAG는 가능한 확장 기능이지 첫 구현의 필수 조건은 아니다. 정형 지표 질의는 SQL·집계가 우선이고, 문서의 절차와 설명을 찾아야 할 때 문서 검색·인용 계층을 추가한다. 검색 결과와 데이터베이스 집계가 서로 다른 근거임을 화면에서도 구분한다.

## 평가·관측·실패의 표기

이 프로젝트의 중요한 성과는 ‘답변이 자연스럽다’가 아니라 **재현 가능한 테스트가 존재한다**는 데 있다. 질문과 기대되는 조회 함수·필터·근거 이벤트를 묶은 작은 평가셋을 먼저 마련한다. 질문이 모호한 경우, 조건에 맞는 행이 없는 경우, 기간 경계가 포함되는 경우, 서로 모순된 로그가 있는 경우, 범위 밖의 수정 명령이 들어오는 경우를 따로 시험한다.

최소 평가 기록은 질문별 도구 선택의 적절성, 인자 추출의 정확성, 수치·합계 일치 여부, 근거 행의 연결, 근거 없는 인과 단정, 응답 시간과 호출 비용이다. 모델·프롬프트·조회 함수가 바뀌었을 때 같은 질문 묶음을 다시 돌려 비교할 수 있어야 한다. 성공률이나 평균 지연시간은 **측정한 다음에만** 적는다.

운영 화면과 로그에도 역할을 분리한다. 쿼리 오류, 데이터 없음, 모델 응답 실패, 비용 제한 도달, 시간 초과는 각각 다른 상태다. 실패를 정상 결과처럼 감추면 시연은 잠깐 부드럽겠지만 평가자는 원인을 알 수 없다. 특히 사람이 확인하지 않은 추천 조치를 ‘확정된 원인’이나 자동 제어 명령처럼 표시하지 않는다.

## 공개 배포: 무료 웹과 과금되는 추론을 구별한다

구현의 기본 선택지로 **Next.js + Vercel + Supabase 또는 Neon + 외부 LLM API**가 제시된다. React·TypeScript 경험을 살려 대시보드와 Route Handler를 함께 시작하면 초기 서비스 수를 줄일 수 있다. 데이터 계층은 Postgres로 두고, 필요하면 Python·FastAPI를 별도 서비스로 분리한다. 차트 도구는 Recharts 또는 ECharts, 스타일은 Tailwind를 후보로 둘 수 있다. 이후 Python 기반 AI 개발 경험을 드러내고 싶다면 평가·데이터 생성기부터 Python으로 독립시키는 방법도 있다.

배포 후보들의 차이는 다음과 같다.

| 조합 | 초기 장점 | 검토해야 할 한계 |
| --- | --- | --- |
| Vercel Hobby + Supabase Free | Next.js 배포와 Postgres, 인증·스토리지 확장 | Hobby의 개인·비상업적 이용 범위, 무료 DB·요청·함수 제한 |
| Vercel Hobby + Neon Free | 별도 인증이 필요 없을 때 간결한 Postgres 계층 | 컴퓨트 시간·저장 용량·유휴 재시작 제한 |
| Cloudflare Pages/Workers + D1 | 가벼운 서버리스 웹과 SQL, 무료 요청량 활용 | D1의 SQLite 계열 특성, Postgres 쿼리·확장과의 차이 |
| Render Free | 별도 웹 서비스를 배치하는 대안 | 유휴 중단과 무료 DB의 지속성 문제 |

당시 소개된 무료 티어의 **참고 수치**로 Supabase 500MB DB·50,000 MAU, Neon 프로젝트당 0.5GB·월 100 CU-hours, Cloudflare Workers 하루 10만 요청 및 D1 DB당 500MB, Render 무료 Postgres 30일 만료 등이 거론되었다. Vercel Hobby의 함수 실행 한도 역시 기본 10초·설정 최대 60초라는 값이 제시되었다. **이 수치들은 대화 당시 설명에 포함된 값이며 현재 가격표나 서비스 계약 조건으로 검증된 것이 아니다. 실제 배포 직전에 각 공식 문서를 다시 확인해야 한다.** 호스팅 선택과 공개 이용 조건도 구분한다.

웹과 DB를 무료로 올려도 모델 API 호출비까지 무료가 되지는 않는다. 비용 구조를 설명하는 계산 예로 입력 6,000토큰·출력 800토큰, 입력 백만 토큰당 0.75달러·출력 백만 토큰당 4.50달러를 대입하면 **호출당 약 0.0081달러**다. 이는 특정 모델에 대한 당시 안내 가격을 가정한 산술 예시로, 현행 요금이나 실제 평균 호출비를 보증하지 않는다.

방문자가 자유롭게 입력하는 사이트라면 API 키를 클라이언트에 두지 않고 서버에 보관하고, 방문자·IP 단위 속도 제한, 하루 총 호출량 또는 예산 상한, 질문 길이 제한, 타임아웃, 캐시나 미리 계산한 데모 응답을 검토해야 한다. 실사용을 목표로 하는 제품과 달리 **포트폴리오 데모의 목표는 무제한 서비스가 아니라 작은 예산 안에서 평가 가능한 경험을 안정적으로 제공하는 것**이다.

## 범위는 작게, 보여 주는 증거는 충분히

첫 페이지에서 곧바로 화면을 볼 수 있게 하는 데 집중한다. 샘플 질문 3~5개, 공장·기간 필터, 주요 KPI 카드, 차트 두세 개, 조회 함수를 사용하는 채팅, 근거 패널 정도가 최소 기능이다. 시작부터 완전한 ERP, 실시간 PLC 연결, 문서 RAG, 자율형 에이전트와 자유 SQL 생성까지 한꺼번에 넣으면 ‘작동하는 완성물’이 늦어진다.

가능한 3주형 일정은 다음과 같다.

| 단계 | 구현·검증 범위 |
| --- | --- |
| 1주차 | 문제·지표 정의, 스키마, 시드 고정 합성 데이터 생성, 기본 대시보드 |
| 2주차 | 질문 분류, 제한된 조회 도구, AI 설명, 근거 패널, 공개 URL 배포 |
| 3주차 | 평가 질문과 실패 케이스, 비용·속도 측정, 디자인, README, 시연 영상 |

2주 내 배포를 목표로 하고 3주차를 문서·검수 단계로 두는 계획이지, 실제 소요 시간이 보장되거나 제작이 끝났다는 뜻은 아니다. 추가 보조 프로젝트로는 코드·문서 요약 에이전트, 사내 규정 질의, 한국어 검색의 청킹·reranking·인용 품질 비교가 후보로 제시된다. 그러나 메인 서비스의 완성도를 떨어뜨릴 정도로 기능 수를 늘리는 것은 바람직하지 않다.

저장소 README는 제품의 문제 정의, 대상 사용자, 스키마와 데이터 합성 규칙, 아키텍처, 모델·도구 선택 이유, 실행 및 배포 방법, 대표 질문과 평가 기준, 비용·지연 측정값, 실패 사례와 개선 전후의 차이를 담는다. 짧은 데모 영상과 공개 주소는 코드를 직접 읽기 어려운 평가자를 위한 두 번째 입구다. **‘사용 가능한 기술’과 ‘실제로 구현·측정한 기능’을 명확히 분리하는 것**이 포트폴리오의 신뢰도를 만든다.

## 남은 설계 결정과 검증 경계

서비스 이름으로 **OpsLens AI**가 제안될 수 있지만 확정된 제품명은 아니다. 실제 선택해야 할 것은 데이터의 중심축(생산·설비 또는 구매·재고·물류), 처음 제공할 조회 도구의 수, AI 호출 예산, 로그인 없는 공개 정책, 합성 데이터 재생성 방식, 평가셋의 합격 기준이다. 데이터 양과 기능을 늘리기 전에 ‘가상의 2라인 가동률 하락에 대한 설명을 누구나 같은 근거로 재현할 수 있는가’를 먼저 검증해야 한다.

이 설계는 완성된 서비스의 운영 보고가 아니라 **서비스화할 수 있는 AI 포트폴리오의 명세와 판단 근거**다. 실 구현 주소, API 호출 성공, 모델의 정확도, 무료 티어의 현재 조건, 채용 시장의 일반적 우선순위는 여기에서 새로 검증된 사실로 간주하지 않는다.

## 관련 문서

- [엣지 영상 이벤트 감지 포트폴리오](./edge-vision-event-monitor-portfolio.md): 객체 인식·이벤트 판정·엣지 배포라는 다른 AI 포트폴리오 경로와 비교한다.
- [개인 개발자의 제조 최적화 엔진](./manufacturing-optimization-solo-business.md): 운영 데이터를 ‘설명’하는 단계에서 제약을 만족하는 ‘결정’을 만드는 단계로 확장할 때의 차이를 살핀다.