#PI

데이터 비전공자에게 분석 결과 보고하기

시스템 사용량과 업무 실적의 관계를 보고해야 했다. 처음엔 상관계수와 2×2 매트릭스로 정리했는데, 보고를 받는 사람도 하는 사람도 데이터 전공자가 아니었다. 산점도와 추세선 하나로 바꿨다.

여러 점검 시스템을 하나로 합치는 데이터 모델

점검 종류마다 따로 만든 시스템과 양식을 하나로 합치려면, 공통 항목과 점검별 특화 항목을 함께 담는 구조가 필요하다. 파일럿에서는 속성 추가와 화면 필터로 버텼고, 통합 설계에서는 공통 컬럼과 JSON 특화 컬럼을 나눈 하이브리드 모델을 택했다.

보기 좋은 대시보드에서 할 일을 알려주는 대시보드로

처음 만든 대시보드는 KPI 카드, 도넛 차트, 월별 추세선이 한 화면에 가득했다. 보고 자료로는 보기 좋았지만, 현업 사용자가 화면을 열었을 때 오늘 무엇을 해야 하는지는 보이지 않았다. 신호와 조치 대상 중심으로 다시 구성했다.

대시보드 숫자가 틀렸을 때 확인하는 순서

대시보드에 조치 완료가 0건, 지연이 수천 건으로 나왔다. 화면 로직을 몇 차례 고쳤지만 그대로였다. 원인은 세 군데에 있었다. 화면이 실제로 호출하는 경로가 생각과 달랐고, 판정에 쓰던 컬럼은 대부분 비어 있었으며, 조치율 공식에도 오류가 있었다. 이후로는 숫자가 이

인사이트 문장은 사람이 쓰고, 노출은 데이터가 정한다

현장 이슈 대시보드의 '한눈에 보기' 화면을 5년 추이, 최근 3개월, 시기별 주의 순서로 설계했다. 인사이트 문장을 미리 써 두고 데이터가 기준을 넘을 때만 보여주는 방식과, 시스템 전환 때문에 생기는 추이 차트 착시를 막은 방법을 정리했다.

이슈 1건에 리포트 1장: AI 이슈 사례분석 화면 설계

재발 여부 판정, 연관 이슈 검색, 관련 정보 제공이라는 세 가지 요청을 탭 세 개가 아니라 한 장의 이슈 분석 리포트로 묶었다. 대화형 채팅과 구조화 리포트 두 방식을 나란히 놓고 비교한 과정도 함께 정리했다.

비전문가에게 AI 성능을 보여주는 법: 점수 대신 '10건 중 약 6건'

현업 사용자가 보는 AI 화면에서 점수 대신 건수로 성능을 표현하고, 자유 입력 대신 선택형 입력을 받도록 바꿨다. 용어 정책과 함께 비전문가용 AI 화면을 설계하며 적용한 원칙 4가지를 정리했다.

고위험 이슈는 ML에 맡기지 않았다: 키워드 룰 안전망 설계

이슈 등급 분류에서 가장 중요한 고위험 이슈를 ML 대상에서 빼고 키워드 룰로 분리했다. 중대 여부가 접수 텍스트가 아니라 결과로 갈린다는 것을 데이터로 확인한 과정과, 오탐 키워드를 걸러 룰을 '검토 요망' 플래그로 만든 방법을 정리했다.

인프라 자원 신청서, 실측값으로 산정근거 쓰기

사내 Kubernetes 자원과 DB를 신청하면서 산정근거표를 쓴 방법을 정리했다. Grafana 실측값으로 CPU·메모리를, 첨부파일 증가 추세로 스토리지를 계산하는 방식과 함께 내야 하는 서류 3종을 다룬다.

Mendix로 1년 만든 시스템을 코드로 다시 만들기로 한 이유

Mendix로 1년 동안 혼자 만들고 운영한 점검 관리 시스템을 새 플랫폼으로 이관하는 대신 Flask/FastAPI로 재개발하기로 결정했다. 이관할 때 생기는 리스크 6가지, 재개발 판단 기준, DB 테이블을 이관·신규 구현·폐기로 나누는 방법을 정리했다.

보고서를 자동화하지 말고 '보고'를 없애기: 현장 이슈 리포팅 업무 재설계

제조 현장의 이슈 리포팅을 통합 포털과 자연어 질의로 다시 설계한 과정이다. 보고서 작성을 빠르게 만드는 대신 보고 행위 자체를 줄이는 쪽으로 과제를 재정의한 이유와 단계 구성을 PI 관점에서 정리했다.

PI 담당자가 로우코드로 사내 시스템을 직접 만들고 운영한 기록

현업 PI 담당자가 Mendix로 점검 이슈 관리 시스템을 기획부터 운영까지 직접 맡았다. 개발 Activity 약 240건을 유형별로 나눠 보면 출시 후 개선이 약 80%였다. 그 과정에서 정리한 원칙과 숫자를 남긴다.