[python/development] project Ti Manager2 개발

Project TI Manager2 — 대용량 업무 데이터 처리를 위한 TI Workflow Management System

Project TI Manager2는 TI 업무의 의뢰, 담당자 배정, 진행 상태 공유, 업체별 통계 등을 관리하기 위해 개발한 Django 기반 업무 Workflow Management System이다.

약 6년간 운영한 기존 TI Manager1에 데이터가 지속적으로 누적되면서 페이지 로딩과 데이터 처리 속도가 크게 저하되었고, 기존 구조를 부분적으로 수정하는 대신 Database와 데이터 조회 구조를 성능 중심으로 다시 설계해 TI Manager2로 재구축했다.

프로젝트 기간 : 2025.06.05 ~ 2025.07.11 / 이후 실제 업무에 맞춰 지속 개선
실제 집중 개발 약 2주 + 사용자 Feedback 반영 약 1주

Project Summary

프로젝트 배경 — 6년간 누적된 데이터

TI Manager1은 Python을 배우기 시작한 초기 시기에 처음 제작했던 Django 업무 시스템이었다.

당시에는 기능을 빠르게 구현하는 것에 집중해 하나의 Application과 하나의 주요 화면에서 많은 데이터를 동시에 처리하도록 구성했고, Table의 각 Cell에서 데이터를 직접 수정하는 방식도 많이 사용했다.

초기 데이터 규모에서는 사용할 수 있었지만 시스템을 약 6년간 운영하면서 업무 데이터가 지속적으로 증가하자 구조적인 문제가 나타나기 시작했다.

TI Manager1

하나의 주요 App / 화면
        ↓
많은 데이터를 한 페이지에서 조회
        ↓
Table Cell 단위 직접 수정
        ↓
업무 데이터 지속 누적
        ↓
약 6년간 Data 증가
        ↓
Page Load 및 처리 속도 저하
        ↓
기존 구조 유지의 한계

단순히 서버 사양이나 일부 Query를 수정하는 것만으로 해결하기보다는, 앞으로 데이터가 계속 증가할 것을 고려해 Database와 데이터 조회 방식 자체를 다시 설계하는 것이 필요하다고 판단했다.

V1에서 V2로 — 성능 중심 재설계

TI Manager2에서 가장 중요한 목표는 새로운 기능을 많이 추가하는 것이 아니라 필요한 데이터만 필요한 시점에 처리할 수 있는 구조로 변경해 페이지 로딩과 데이터 처리 부담을 줄이는 것이었다.

TI Manager1

대량 Data
   ↓
한 화면에 집중
   ↓
Page Load 시 많은 데이터 처리
   ↓
데이터 증가와 함께 성능 저하


TI Manager2

업무 영역 분리
   ↓
Database 구조 재설계
   ↓
기능별 Data 처리
   ↓
필요한 데이터 중심 조회
   ↓
지속적인 Data 증가에 대응

특히 장기간 운영하는 업무 시스템은 개발 당시의 데이터 양만 기준으로 설계할 수 없다는 점을 TI Manager1을 통해 직접 경험했기 때문에, V2에서는 데이터가 계속 누적되는 상황을 전제로 구조를 다시 설계했다.

주요 업무 흐름

TI Manager2는 TI 업무의 등록부터 완료까지 발생하는 주요 데이터를 하나의 시스템에서 연결해 관리하도록 구성했다.

TI 업무 의뢰
      ↓
업무 정보 등록
      ↓
담당자 배정
      ↓
업무 진행
      ↓
진행 상태 공유
      ↓
완료
      ↓
업무 History 축적
      ↓
업체 / 기간 / 담당자 기준 조회 및 통계

업무 처리 과정에서 생성되는 데이터를 별도의 문서나 개인 기록으로 분산시키는 것이 아니라, 동일한 원본 데이터를 진행 관리와 이후 조회 및 통계에 다시 활용할 수 있도록 하는 것이 목적이었다.

Application 구조

기존처럼 하나의 Application에 기능을 집중시키지 않고, 사용자·업무·설정·보고 등 역할에 따라 Django Application을 나누어 구성했다.

python manage.py startapp org
python manage.py startapp web
python manage.py startapp setting
python manage.py startapp utils
python manage.py startapp report

org
 └─ 사용자 / 조직 / 담당자 Data

web
 └─ Main 업무 화면 및 TI Workflow

setting
 └─ 업무 기준 및 공통 설정 Data

report
 └─ 통계 / Export 관련 기능

utils
 └─ 공통 처리 기능

기능과 데이터를 역할별로 분리하면서 이후 업무 기능을 수정하거나 새로운 통계·보고 기능을 추가할 때 기존 화면 전체에 영향을 주지 않도록 구조를 정리했다.

개발 환경

Django와 MariaDB를 기반으로 Web Application을 구성하고, 기존 TI Manager1의 데이터를 새로운 Database 구조에 맞게 Custom Migration하는 방식으로 진행했다.

기본 환경 구성

# Virtual Environment
D:\Python\python311\python.exe -m venv vTiManager2

# Django
pip install django

# Database
pip install pymysql

# CORS
pip install django-cors-headers

# IIS
pip install wfastcgi

# HTML Parsing
pip install beautifulsoup4

# Excel
pip install openpyxl

# Image
pip install Pillow

# Outlook / Windows Integration
pip install pywin32

# Project
django-admin startproject back .

Database 생성

Database는 MariaDB를 사용했다. 기존 TI Manager1의 Database를 그대로 복제하는 것이 아니라 V2의 데이터 구조에 맞게 필요한 데이터를 이전하는 방향으로 구성했다.

MariaDB 설치 방법 : [python/setting] Python – Django 설치 + 셋팅

CREATE DATABASE ti2;
USE ti2;
SHOW DATABASES;

Django 초기화

python manage.py makemigrations
python manage.py migrate
python manage.py createsuperuser

일부 기본 프로젝트 파일을 재사용하는 과정에서 각 Application의 migrations/__init__.py가 누락된 경우 Django가 Migration App을 정상적으로 인식하지 못하는 문제도 확인했으며, Migration 구조를 다시 정리해 해결했다.

사용자 및 조직 데이터

TI 업무에서는 실제 업무 담당자뿐 아니라 요청자와 참조 대상 등 여러 사용자 정보를 선택해야 하기 때문에 사내 사용자 정보가 중요한 기준 데이터였다.

Django의 기본 Username 대신 Email 기반 Custom User Model을 사용하고, 사용자와 별도로 업무 선택에 사용하는 Member 데이터를 관리하도록 구성했다.

User
 ├─ Login Account
 ├─ Profile
 ├─ 소속 정보
 └─ Permission

Member
 ├─ 업무 담당자
 ├─ 요청자 / 참조 대상
 ├─ 소속 정보
 └─ 업무 Selection Data

사용자 계정과 업무 선택에 사용하는 전체 구성원 데이터를 분리해, 실제 로그인 계정의 범위와 업무에서 참조해야 하는 사람의 범위가 서로 달라도 처리할 수 있도록 했다.

사내 구성원 데이터 Update

업무에서 선택하는 구성원 정보가 오래된 상태로 남지 않도록 외부에서 추출한 사용자 데이터를 CSV로 받아 Member Database를 갱신할 수 있도록 했다.

사내 사용자 Data
      ↓
CSV Export
      ↓
Name / Email / Team / Position 정규화
      ↓
기존 Member 검색
   ├─ 존재 → Update
   └─ 없음 → Create
      ↓
TI 업무의 담당자 / 참조 선택에 사용

이 과정에서는 이름에 포함된 불필요한 문자 제거, 조직 정보 변환, 날짜 형식 변환 등 원본 데이터를 Application의 Database 구조에 맞게 정규화한 뒤 update_or_create 방식으로 반영했다.

member, created = Member.objects.update_or_create(
    member_email=member_email,
    defaults={
        'member_name': member_name,
        'member_phone': member_phone,
        'member_department': member_department,
        'member_team': member_team,
        'member_position': member_position,
        'member_start': member_start,
    }
)

대량 선택 데이터의 UX 개선

TI 업무에서는 담당자, 참조 대상, Model 등 선택해야 하는 기준 데이터가 많다.

특히 회사 전체 구성원 데이터를 일반 Select Box로 제공하면 사용자가 긴 목록을 계속 Scroll해야 했기 때문에, 입력한 Text를 기준으로 결과를 즉시 줄여주는 검색 및 자동완성 방식을 적용했다.

기존 방식

Select Open
    ↓
수많은 항목 Scroll
    ↓
대상 탐색
    ↓
선택


개선 방식

Text 입력
    ↓
실시간 Filtering
    ↓
관련 후보만 표시
    ↓
선택

데이터가 많아지는 문제를 Backend 성능만의 문제로 보지 않고, 사용자가 많은 데이터를 실제 화면에서 어떻게 탐색하는지도 함께 개선했다.

성능 개선에서 얻은 가장 큰 경험

TI Manager2에서 가장 중요한 개발 경험은 데이터 규모가 작은 시점에 동작하는 구조가 장기간 운영에서도 좋은 구조인 것은 아니라는 점이었다.

TI Manager1에서는 하나의 화면에서 많은 데이터를 읽고 수정하는 방식이 처음에는 구현하기 쉽고 사용하기도 편했지만, 6년 동안 데이터가 계속 증가하면서 페이지 로딩과 처리 비용이 함께 증가했다.

V2에서는 이 문제를 단순한 화면 최적화가 아니라 Database 설계와 데이터 조회 범위, Application 역할 분리까지 포함한 구조적인 문제로 보고 다시 설계했다.

V1에서 얻은 경험

"현재 Data에서 동작한다"
        ≠
"Data가 계속 증가해도 동작한다"

        ↓

V2 설계 기준

Data Growth
    +
Query / Load 범위
    +
화면당 Data 양
    +
Application 역할 분리
    +
사용자 검색 방식

오랜 기간 실제로 운영한 V1이 있었기 때문에 성능 문제를 추상적인 예상이 아니라 실제 데이터 증가에 따른 문제로 확인할 수 있었고, 그 경험을 V2의 설계 기준으로 다시 반영할 수 있었다.

개발 환경 확인

Project TI Manager2 결과

TI Manager2는 기존 시스템의 디자인이나 Python Version만 변경한 프로젝트가 아니라, 장기간 운영하면서 누적된 데이터로 인해 드러난 V1의 구조적 한계를 분석하고 Database와 업무 처리 구조를 다시 설계한 프로젝트였다.

TI 업무의 의뢰, 담당자 배정, 진행 상태, 업체별 데이터 관리라는 기존 업무 흐름을 유지하면서도 대량 데이터 환경에서 페이지와 사용자가 불필요하게 많은 데이터를 처리하지 않도록 구조를 다시 구성했다.

또한 전체 구성원과 다양한 업무 기준 데이터를 다루는 과정에서 검색 및 자동완성 기능을 적용해 실제 사용자가 데이터를 찾고 선택하는 과정도 개선했다.

후속 개발 항목

연도별 업무 데이터를 Excel 형태로 추출하는 Report 기능도 V2의 확장 기능으로 계획했다.

다만 초기 개발 기간에는 기존 시스템의 성능 문제 해결과 주요 Workflow 이전을 우선했기 때문에 Report 영역은 후속 개발 항목으로 분리했다.

모든 기능을 한 번에 구현하기보다 현재 운영에 가장 큰 영향을 주는 성능과 핵심 업무 기능을 우선 완료한 뒤 부가 기능을 확장하는 방식으로 개발 범위를 조정했다.

프로젝트를 통해 얻은 경험

TI Manager2는 신규 서비스를 처음 만드는 프로젝트와 달리, 내가 과거에 만든 시스템을 여러 해 동안 실제로 운영한 뒤 그 한계를 다시 분석하고 재설계한 프로젝트라는 점에서 의미가 컸다.

처음 TI Manager1을 개발할 당시에는 기능을 구현하는 것 자체가 가장 중요한 목표였다면, V2에서는 데이터가 어떻게 증가하는지, 어떤 Query와 화면이 반복적으로 사용되는지, 사용자에게 실제 필요한 데이터 범위가 어디까지인지까지 고려하게 되었다.

또한 Backend의 Database 구조만 변경해서는 충분하지 않았고, 많은 사용자와 기준 데이터를 검색하는 Frontend Interaction까지 함께 개선해야 실제 체감 성능과 사용성이 좋아진다는 점도 확인할 수 있었다.

TI Manager1
     ↓
6년간 실제 운영
     ↓
Data 지속 증가
     ↓
성능 Bottleneck 발생
     ↓
문제 구조 분석
     ↓
Database / Application 재설계
     ↓
대량 Data UX 개선
     ↓
기존 Data Migration
     ↓
TI Manager2 배포
     ↓
사용자 Feedback 반영

Project TI Manager2는 Legacy System 운영 → Data Growth에 따른 Bottleneck 발견 → 원인 분석 → Database 및 Application 재설계 → 기존 데이터 이전 → UX 개선 → 실제 재배포까지 장기간 운영되는 업무 시스템의 Lifecycle을 경험한 프로젝트라는 점에서 의미가 있다.

다른 프로젝트 보기 : Project 전체 보기

Django : https://www.djangoproject.com/