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

2026.04.15
  • 시리즈 1/16
  • PI
  • Mendix 10

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

상황

외주 없이 PI 담당자 1명이 로우코드로 기획, 개발, 운영을 모두 맡음

결과

모듈 4개 운영, 개발 Activity 약 240건 중 98% 완료, 월 사용자 개발 기간 대비 8.4배

정리

처음부터 완벽하게 설계하기보다 바꾸기 쉬운 구조를 먼저 잡는 편이 운영 부담이 적었음

만든 것

현장 점검에서 나온 이슈를 등록하고, 조치 완료까지 추적하는 시스템이다. 사례 공유와 회의 후속조치를 붙이고, 전체 현황을 대시보드로 모았다.

점검 이슈 관리점검 결과 등록, 조치 담당 지정, 조치 이력
사례 공유단계별 보고서, 메일 발송, 후속 조치 연결
회의 후속조치회의록, 액션 아이템, 조치 완료 확인
대시보드현황 통계, 지연 건 확인, 추세 분석
공통SSO 로그인, 사내 메일 발송, 엑셀 업로드 및 다운로드, 역할별 권한
모듈 구성
구분사용 기술
플랫폼Mendix 10, 사내 PaaS 배포
DBMySQL 계열
화면기본 위젯 + HTMLSnippet 기반 JS 위젯
서버 로직Microflow, Java Action
인증SAML SSO

진행 경과

  1. 착수
    1차 PI업무 흐름 정의, 요구사항 정리
  2. 14개월 차
    시범 오픈점검 이슈 관리, 대시보드
  3. 18개월 차
    모듈 추가사례 공유
  4. 21개월 차
    시험운영 종료, 정식 오픈메인 화면 개편, 대시보드 메뉴 분리
  5. 예정
    운영 시스템 전환, 통합 PI흩어진 점검 시스템 통합 설계

숫자로 본 개발

약 240건개발 Activity
98%완료율
8.4배월 사용자, 개발 기간 대비
34%2개월 이상 재방문

Activity 유형별 비중

  • 신규 구축21%
  • 기능 개선55%
  • 결함 조치12%
  • 성능 개선12%
  • 처음 만든 기능
  • 출시 후 개선 79%
  • 출시 후 고친 횟수가 처음 만든 횟수의 약 4배
  • 개선 요청은 화면을 실제로 써 본 뒤에 구체화됨
  • Activity를 유형별로 나눠 두니 보고 때 "무엇을 얼마나 고쳤는지"를 바로 설명할 수 있었음

운영하며 정리한 원칙

바꾸기 쉬운 구조를 먼저 잡는다

목록과 대시보드 화면을 HTMLSnippet 기반 JS 위젯으로 옮겼다. 엔티티나 Microflow를 건드리지 않고 화면만 고칠 수 있게 되면서 수정 요청 대응이 빨라졌다.

관련 글: 2편 Datagrid2 대신 HTMLSnippet과 JS로 목록 화면 만들기

증상이 여러 개면 구조 하나를 의심한다

한 번에 접수된 버그 10건 중 대부분이 이벤트 리스너 중복 등록 하나에서 나왔다. 증상별로 따로 고치는 대신 이벤트 처리 구조를 다시 짰다.

관련 글: 3편 Mendix SPA에서 HTMLSnippet JS가 꼬이는 이유

데이터가 쌓이면 저장 방식이 드러난다

사진을 base64 문자열로 저장한 구조는 데이터가 적을 때는 문제가 없었다. 1만 건을 넘기면서 목록 조회 중 서버 메모리가 부족해졌다. 첨부 저장 때 커밋이 롤백되는 문제도 있었는데, 처음엔 용량 탓으로 봤지만 원인은 다른 곳에 있었다.

관련 글: 5편 Java heap OOM 추적기, 6편 Mendix 커밋 롤백, 용량 문제가 아니었다

숫자는 추측하지 않고 DB에서 확인한다

대시보드에 조치 완료가 0건으로 나온 적이 있다. 상태 판정에 쓰던 컬럼이 특정 점검 유형에서만 채워지는 값이었다. 화면 로직을 몇 번 고치는 것보다 실제 데이터를 한 번 조회하는 편이 빨랐다.

관련 글: 13편 대시보드 숫자가 틀렸을 때 확인하는 순서

운영 부담을 늘리는 기능은 뺀다

정식 오픈 메인 화면에 "내 조치 현황"을 넣을지 검토했다. 집계용 Microflow를 새로 만들어야 했고, 담당자 데이터도 아직 정리되지 않은 상태였다. 데이터 호출이 없는 정적 화면으로 정리했다.

관련 글: 14편 보기 좋은 대시보드에서 할 일을 알려주는 대시보드로

파일럿 방식과 정식 설계는 나눠서 본다

파일럿에서는 점검 유형이 늘 때마다 속성을 추가하고 화면 필터로 나눴다. 빠르게 대응할 수 있었지만, 정식 개발에서는 공통 컬럼과 특화 컬럼을 분리한 모델로 다시 설계하기로 했다.

관련 글: 15편 여러 점검 시스템을 하나로 합치는 데이터 모델

이 시리즈의 범위실제 운영하며 겪은 문제와 해결 과정을 정리했다. 코드와 화면은 구조 설명을 위해 다시 구성했고, 실제 시스템의 명칭과 데이터는 포함하지 않았다.

다음 단계

  • 파일럿을 운영 시스템으로 전환
  • 여러 곳에 흩어진 점검 시스템을 하나로 합치는 통합 PI
  • 통합 데이터 모델 기준으로 정식 개발
시리즈 목차 16편
  1. PI 담당자가 로우코드로 사내 시스템을 직접 만들고 운영한 기록 (현재 글)
  2. Mendix Datagrid2 대신 HTMLSnippet과 JS로 목록 화면 만들기
  3. Mendix SPA에서 HTMLSnippet JS가 꼬이는 이유: 이벤트 중복과 DOM 공존
  4. Mendix mx.data.commit이 조용히 실패할 때
  5. Mendix Java heap OOM 추적기: base64 이미지 컬럼
  6. Mendix 커밋 롤백, 용량 문제가 아니었다: FileDocument 전환기
  7. Mendix 첫 접속 지연 줄이기: 워밍업과 캐시
  8. Mendix SAML SSO 자동 로그인과 딥링크 유지
  9. Mendix Studio Pro에서 안 바뀌는 스타일 main.scss로 바꾸기
  10. Mendix MPK 파일 열어서 마이크로플로우 구조 보기
  11. SSO 로그 테이블로 MAU와 재방문율 구하는 SQL
  12. Mendix DateTime이 BI 도구에서 하루 빠르게 보이는 이유
  13. 대시보드 숫자가 틀렸을 때 확인하는 순서
  14. 보기 좋은 대시보드에서 할 일을 알려주는 대시보드로
  15. 여러 점검 시스템을 하나로 합치는 데이터 모델
  16. 데이터 비전공자에게 분석 결과 보고하기
  • #Mendix
  • #로우코드
  • #PI
  • #업무시스템
  • #시민개발
  • #회고

댓글