50분 걸리는 작업 시간을 1분으로 개선.

50분 걸리는 작업 시간을 1분으로 개선.

 

 

긴 글 싫어하면 스크롤 조금 내려주세요.

 

 

그룹사 ERP 시스템 담당자, 개발자

 

시스템을 개발하는 프로젝트에는 여러 사람이 참여한다. 21년 초부터 그룹사를 대상으로 진행하는 ERP 프로젝트에 참여했는데, 그룹사 ERP 시스템이다 보니 여러 사람, 여러 회사와 함께 일할 수 있는 기회가 생겼다. 처음 그룹의 모기업을 대상으로 먼저 시스템을 완성한 후 다음 회사, 다음 회사 하나씩 만들어갔다. 우리 팀은 PM, PL로 이끌어가는 팀에 속했고,  타 회사의 요구사항을 확인하기 위해 미팅을 나가곤 했는데, 나는 거의 미팅에 나가지 않고 타 팀원분들이 미팅에 나갔다.

 

그룹사가 사용하지만 계열사마다 다른 요구사항이 반영되어 있기 때문에 한 사람이 모든 기능을 다 알기는 어렵다. 현재 타회사에 나가서 미팅을 하고 개발한 직원들은 모두 퇴사하여서, 히스토리도 정확하게 알지 못하고 내가 손을 대지 않은 프로그램을 접할 때 조금 난감하다. 하지만 현재 내가 이 시스템의 담당자이기 때문에 과거 히스토리를 몰라도  현 업무 담당자들의 요청사항들을 귀담아듣고, 요구 사항을 도출하여서 분석, 설계, 개발, 테스트를 통해 시스템과 프로그램을 개선하고, 개발하는 것이 나의 일이기 때문에 책임감 있게 일을 수행한다.

 

반응형

 

앞에서도 언급했다시피 나는 거의 미팅에 나가지 않고, 전화로 요구사항 도출해서 설계, 개발을 하고 있다. 일단 이렇게 된 이유는 미팅에 나를 참석시키지 않았기 때문에 그렇다. 이번 연도(2024년)에도 6~8월에 2개 회사를 추가했는데 미팅 없이 메일과 전화로 일을 끝냈다. 요구사항 도출부터 분석, 설계, 개발, 교육까지.

 

실제로는 미팅 요청이 있기도 했지만 회사에서 나를 외부 미팅을 잘 보내주질 않는 거 같다. (그런 생각까지 든다.) 현 회사에서 4년을 근무하고 있으면서도 출장이 없었다. 반나절 근교 외근 정도는 있었음. 그래서 출장비를 한 번도 받아 보진 못해 조금 아쉬움이 있다. "프로니까 어떤 상황에서든 일 다 끝낼 수 있다."는 생각을 갖고 일하는 사람이라 지금까지 일 잘하고 있다. 가장 아쉬운 것은 제주도에 있는 계열사에 출장 가지 못한 것이 아쉬움이 남는다. 남들 출장 여러 번 가는데 왜 난 한 번도 못 감ㅜ

 

서론이 길었다.

 

본론으로 들어가자.

 

 

 

히스토리, 요구사항 분석 후 재 설계, 개발하여 50분 소요되는 작업을 1분으로 개선.

 

ERP 시스템에는 많은 부문이 있다. 나는 인사시스템(인사, 근태, 급여, 연말정산 등)을 담당하고 있다. 최근에 한 계열사에서 작업 시간이 너무 오래 걸린다고 연락이 왔다. 확인을 해봤더니 정말 오래 걸렸다. 작업 시간이 50분 정도 소요되는 작업이었다. 현재는 내가 담당자이기는 하지만 과거에 내가 미팅하거나 개발했던 부분이 아니어서 자세히는 모르는 상황이었다. 미팅을 했거나 개발했던 사람들은 모두 퇴사를 했다. 어쩔 수 없다. 그냥 부딪혀서 분석해야 한다.

 

1차 분석 : 현 업무 담당자가 어떤 경우에 작업하고, 관련 작업 순서, 데이터 확인 및 점검 방식 등 인터뷰를 다시 했다.

2차 분석 : 6하원칙에 의거해서 '언제, 어디서, 누가, 무엇을, 어떻게, 왜' 작업이 오래 걸리는지를 분석했다. 분석하고 추적하고 인터뷰를 해보니까 해당 작업에 다양한 작업들이 구성되어 있었다.

 

 

해당 작업은 일근태를 생성하는 작업이다. 현 시스템의 근태 관련 시스템을 개발했었지만, 이번 프로그램과 기능은 특정 계열사에 맞춰서 커스텀 된 일근태 생성 프로그램인 것이다. 간단한 작업일 수도 있지만 요구사항 또는 상황에 따라서 프로그램의 복잡도가 증가한다. 그리고 이미 많은 요구사항이 적용되어 있었기 때문에 기존의 작업에서 속도 개선 작업에 중점을 두어 작업을 해야 했다.

 

아무튼 분석해 보니 최대 중첩 반복문이 3~4개가 있었다. 불필요한 반복문도 보였다. 반복문 중간에 호출되는 프로시저 내부에 커서가 있다거나 하는 등 비효율적으로 코드가 짜여 있었다. 비효율적으로 코드가 구성되면 시간이 오래 걸릴 수밖에 없다. 우선 나는 반복문을 아예 제거하기로 했다. 여기서 기존 기능을 수정하는 방향은 옳지 않다고 판단했다. 해당 작업의 흐름이 길었고, 단순히 조금씩 수정해 가며 접근한다면 개선, 개발하는 시간이 더 오래 걸리거나 속도가 조금씩만 개선되었을 것으로 예상했다. 또 잘 되던 게 안 될 수 있다는 리스크를 짊어져야 한다.

 

그냥 새로 만들기로 했다. (기능 추가)

 

 

 

 

분석을 했으니 그렇게 해도 된다고 판단했다.

 

1차로 반복문을 다 벗겨냈더니 50분에서 10분으로 줄었다. 실제 데이터가 몇 천 건이 되는데 그것을 처리하는 것이다 보니 바로 몇 초대로 작업되는 것을 기대하진 않았다. 그리고 어차피 현 업무 담당자가 작업할 때 몇 천 건의 데이터를 두고 작업하는 게 주 작업이다 보니 그것에 맞게 테스트를 진행했다.

 

다음으로는 어떤 부분에서 오래 걸리는지 계속 분석해 나갔다. 일단 요구조건, 기능 등으로 보이는 것들을 내가 생각하는 기준에서 최소 기능으로 다 쪼갰다. 불필요한 코드는 모두 제거하고, 합치고, 정리했다. 그렇게 적용했더니 약 1분 정도 작업 시간이 소요됐다. 숲을 보고, 나무를 보는 것처럼 큰 작업흐름부터 보고, 작은 작업에 접근하여 해결했다. 결과적으로 50분 정도 걸리던 작업이 1분 정도 걸리는 작업이 되면서 기능 속도가 대폭 향상되었다.

 

 

 

 글 마무리

작업을 개선할 수 있는지를 파악하려면 분석을 해야 한다. 히스토리, 요구사항, 작업 흐름, 코드 등 다양한 관점에서 분석하여 어떻게 개선할 것인지 고민해야 한다. 그다음 분석한 것을 바탕으로 문제점을 제거하고 개선하는 방향으로 재 설계 및 개발을 해야 한다.