일괄등록 시스템 프로젝트(작성 중)

Leo·2022년 10월 11일
0

Project

목록 보기
3/3

(주) 외식인에 근무하며 매장, 사용자 일괄등록 프로젝트 진행 과정에서 겪었던 일들을 정리하고 회고하는 글입니다.

배경


  1. 매장, 사용자 일괄등록을 위한 고객사와의 소통으로 인한 시간 소모
  2. 사용 개시 전 2주간의 시간 동안 기초 정보 세팅 과정으로 인한 대기 기간
  3. 기존 고객사의 일괄등록 시스템 니즈

목표


  1. 어려움 없이 일괄 등록, 수정을 할 수 있는 프로세스와 복잡하지 않은 UI/UX
  2. CRUD 처리 시 속도
  3. 데이터 정확도

사용 기술 및 라이브러리


  • Spring 4.1.7
  • mybatis
  • mysql
  • jQuery
  • JSP
  • jspreadsheet v4(스프레드시트 라이브러리)
  • 등등

여러 기술이 사용되었지만 대부분 기존 환경이라 선택권이 없었지만, 가장 중요한 것은 jspreadsheet 라이브러리를 선택한 이유이다.

처음 일괄등록 시스템을 구축할 때 화면 구성을 어떻게 할 지 고민했었는데 아래 두 가지를 생각했었다.

1. 엑셀 파일을 통으로 받아 읽어들인 뒤 table 형태로 제공
2. 스프레드시트 형태로 제공(예시: 구글 스프레드시트)

이 중 2번을 선택하게 됐는데 이유는 다음과 같다.

1. 일정을 지키기 위한 시간 부족
2. 풍부한 라이브러리 내장 기능
3. 기존 화면이 가지고 있던 한계
4. 자료, 사용률

개발 일정은 모든 개발자라면 공감하지 않을까라고 생각한다. 일정을 맞춰야 하는데 백지에서 시작하기에는 시간이 너무 모자라다고 느꼈다. 그래서 사용할 수 있는 라이브러리를 찾다가 jspreadsheet를 찾게 되었고, 필요한 기능들이 내장되어 있어 선택하였다.

4번의 자료와 사용률은 가끔 라이브러리 중 문서가 부실하거나, 사용률이 낮아 추가 개발이 없는 것들이 있다. 이런 경우 오히려 사용했다가 죽도 밥도 안될 수도 있기 때문에 사전에 많은 검색을 했었다.

마지막으로 기존에 구현된 방식이 엑셀 파일을 업로드 해 읽은 뒤 table 형태로 읽어오는 형태이다.

이 방식의 단점은 업로드 시 에러가 발생하면 몇 번째 줄의 어떤 데이터가 어떻게 잘못되었는지 사용자에게 보여주기가 어렵다는 것 이었다.

실제로 내부 직원분들께서 사용하실 때 가장 사용하기 어렵거나 필요하다고 했던 내용들이 몇 가지 있다.

1. 데이터가 어디가 잘못되었는지 인지하기 어려움
2. 데이터 수정 뒤에도 이게 맞게 수정된 건지 알 수가 없음
3. 등록 시 실패한 데이터만 볼 수 있게

물론 table 형태로 제공하여도 위 부분들을 충족시킬 수 있지만, 라이브러리 내장 기능들이 너무 강력했다.

이 외에 다양한 의견이 있었지만 결론적으로는 기존 화면의 단점들을 보완해야 고객사에서 사용하기에 어려움이 없을 것으로 판단되어 스프레드시트 형태를 선택했다.


화면 설계


스프레드시트 형태로 구성하는 것을 정하고 또 고민이 생겼다.

입력 시트, 등록 실패 리스트 시트, 등록된 리스트 시트 3가지 시트로 표현
1개 시트로 입력


일괄등록 흐름도


작업에 들어가기 전 일괄등록 시스템의 흐름도를 그려보며 설계를 했던 내용이다.

프로젝트가 끝난 지금와서 보니 부족한 부분이 많다. 아래 흐름도를 기본으로 실제 작업이 시작되긴 했지만 프로세스가 추가되거나 없어지고 수정된 내용이 매우 많다(거의 사용할 수 없을 정도).

설계 단계에서 모든 걸 완벽하게 할 수는 없지만, 경험이 부족한 것이 이럴 때 티가 나는 것 같다. 그래도 이런 경험을 통해 다른 시스템 설계 시 고려해야할 점들을 파악할 수 있는 능력이 길러졌다.

흐름도를 Ryan에게 보여주고 피드백을 받았는데 내용은 아래와 같다.

1. 도형 모양의 의미를 명확하게 인지하고 의미에 맞게 사용
2. 매장 일괄삭제의 경우 컨텐츠 유, 무에 대한 기준을 확실하게 정해야 함

1번은 흐름도의 도형 의미를 제대로 파악하지 못한 이유이다.

2번은 내부 처리 방식과 연관이 있다. 대부분의 데이터들을 테이블에서 DELETE 하는 것이 아닌 use_yn 컬럼을 통해 삭제가 된 것처럼 보이게 처리하고 있다.

완전 삭제 시 해당 매장과 연관되어 있는 기능들에 영향이 있을 것을 고려하여 완전 삭제를 할 경우 연관 데이터들도 같이 삭제해야 한다는 내용이었다.

use_yn 컬럼의 데이터만 바꾸게 되면 의미없는 데이터가 쌓여 속도에 영향이 미칠 것으로 생각해 완전 삭제를 고려했지만 속도에 영향을 미칠 정도로 쌓이지는 않을 것으로 판단되고 DB 정리 시 삭제할 수 있다고 피드백을 주셔서 기존 방식을 유지하기로 하였다.

profile
느리지만 확실하게

0개의 댓글