코딩짜는 일상

[이걸 그렇게 쓸 줄은 몰랐지] 1-1 나에게만 index 사용자에겐 No. 본문

작업 회고록

[이걸 그렇게 쓸 줄은 몰랐지] 1-1 나에게만 index 사용자에겐 No.

Remily 2024. 4. 7. 23:48
반응형

아무리 상황을 가정하고 대비해도
사용자는 늘 예상밖의 오류를 만듭니다.

 

개인은 집단지성을 이길 수 없으니까요...

 

 
이 글에선 제가 미처 대비하지 못해 발생한 오류를 소개하고자 하며
어떻게 보완하면 좋았을까, 고민하는 글입니다.
 

 

 


# 서론

회사에서 협력 업체를 통해 데이터를 전달받고
업소정보를 업데이트하는 시스템을 만들게 되었습니다.
 

사장님 요청 → CS 접수 → 협력사 전달 → 파일 회신 → 업소정보 업데이트

 

 

위 순서로 업무가 이뤄지기 때문에 프로그램 구성은 다음과 같습니다.

 

  1. 업소검색 기능
    cs를 접수하면 관리자가 곧장 해당 업소를 검색 후
    [등록] 버튼을 눌러 파일 요청목록에 등록.

  2. 엑셀 다운로드 기능
    파일 요청목록중 협력사 회신이 필요한 목록을 엑셀로 다운로드하는 기능.

  3. 파일 서버등록 기능
    업체로부터 회신받은 데이터를 서버에 등록하는 기능

  4. 파일 요청목록 뷰
    파일 요청목록을 확인.
    [업데이트] 버튼을 눌러 서버에 있는 데이터파일을 불러오고 그걸 토대로 업소정보를 업데이트.
    성공여부, 실패 사유에 따라 상태값 자동 변경.

 


# 의도한 것

✨ 누구나 쉽게 사용방법을 배우고 조작오류가 적은 프로그램 ✨


CS팀에는 다양한 연령과 배경을 가진 팀원들이 존재합니다.


그래서 새로운 기능을 만들고 배포한 초반 1~2주 정도는

사용법을 교육해주고 조작 오류를 피드백해주는 기간이 필요했습니다.

 


저는 이러한 소모를 줄이기위해

  1. 한눈에 모든 기능이 보이도록 원 페이지로 구성하고
  2. 업무가 이뤄지는 순서대로 기능을 배치하고
  3. 보자마자 무슨 기능인지 알기 쉽도록 각 기능의 헤더명을 작성하고
  4. 짧게 참고사항을 적거나 붉은글씨로 주의사항을 표기하고
  5. 안내한 방법대로만 쓰도록 조작범위를 제한했습니다.
    EX )
    - 업소 하나당 한 번만 등록 가능
    - 업소정보가 업데이트된 업소는 더 이상 업데이트 불가
    - 같은 파일명으로 파일 중복 업로드 불가.

 

 

사용법을 교육한 첫날엔 제 의도대로 모두가

빠르게 사용법을 숙지하고 곧 업무에 돌입했습니다.

 

 

하지만 바로 다음날 문의가 빗발칩니다...

 

 

 


# 예상치 못한 오류

1. 나에게만 index, 사용자에겐 No.

 

파일과 업소를 매칭할 때 업소 이름으로 매칭하면

비슷한 이름의 업소가 많아 오작동할 수 있습니다.

 

그래서 고유 번호(index)를 엑셀 다운로드 내용에 포함하고

해당 번호를 파일명으로 하여 업체가 파일을 생성하도록 요청했습니다.

 

 

하지만 처음 전달받았던, 이메일로 엑셀 파일을 주고받는 방식이 아닌

구글 스프레드 시트를 생성해 목록을 주고받으면서 문제가 발생합니다.

 

바뀐게 있으면 말 좀 해주세요...!

 

 

 

기능은 이제 막 사용하기 시작한 단계였기 때문에 인덱스가 아직 2자리 숫자였으며

엑셀 A열에 있어서 일반적으로 목록에 붙이는 넘버링으로 혼동되었습니다.

 

그래서 CS팀 일부가 고유번호를 제외한 내용을 구글 스프레드시트에 붙여 넣고

번호를 임의로 붙이면서 파일과 업소의 매칭이 어긋나게 되었습니다.

 

 

 

파일명을 일일이 고치기엔 파일 수가 너무 많았고

DB로 인덱스를 직접 수정해 급한 불을 껐습니다.

아침부터 탈탈 털렸던 슬픈 기억...

 

 

 


# 보완할 점

1. 사용자에게 노출되는 고유번호는 자릿수를 크게 맞추자

사실 회원 고유번호(index)라는 개념을 CS팀도 알고 있었고

이전에도 업무 관련으로 많이 주고받았기에 문제가 안 될 줄 알았습니다.

 

 

하지만 그건 제 착각이었고...

사람들이 테이블헤더를 잘 안 읽는다는 걸 배웠습니다.

 

워낙 담당하는 업무들이 많아서 그런지

문자 자체가 눈에 안 들어오는 것 같았습니다...

사용법을 읽어주세요...

 

 

 

문자를 안 읽는 사람에게 당신이 예상하는 요소와 이것이

확연하게 다르다는 점을 어떻게 인식시킬 수 있을까요?

 

 

저는 일반적인 형태와 확연히 다른 모습을 하면

그것을 다른 요소로 보게 된다는 점을 이용했습니다.

사실 현재 사용중인 회원 고유번호의 형태를 참고한 것도 있습니다...😅

 

 

 

목록의 넘버링은 1부터 시작하기에 보통 2 자릿수이며

많아도 3 자릿수를 넘지 않습니다.

 

하지만 넘버링이라고 생각했던 숫자가

8 자릿수라면 어떨까요?

1, 2, 3, ... => 10000001, 10000002, 10000003, ...

 

 

 

일반적인 넘버링과는 형태가 다르니까 궁금함에 테이블헤더를 읽게 될 것이고

 

추가로 협력사에 8자리 숫자라고 미리 말해둔다면

파일을 만들기 전 이상함을 느끼고 확인을 요청했을 것입니다.

 

 

2. 아이디 부여

물론 그럼에도 불구하고 관성처럼 ctrl + C ~ V를 누르거나

괜한 짓 하기 싫어서 재확인 없이 일을 진행할 수도 있습니다...😂

 

더 확실한 것을 원한다면 인덱스를 활용하지 않고

앞에 알파벳을 붙여 고유 아이디를 생성할 수 있습니다.

1, 2, 3, ... => downlist_00000001, downlist_00000002, downlist_00000003, ...

 

 

그럼에도 불구하고 사용자를 믿을 수 없다면...

 

사용자의 개입을 완전히 차단하면 어떨까요?

 

 

3. 구글 스프레드시트 자동 등록

구글 API를 이용해 파일 요청목록이 등록됨과 동시에

구글 스프레드시트에 자동 추가될 수 있다면 매우 확실할 것입니다.

 

사용자의 개입이 줄어들면

그만큼 오류가 발생할 확률도 줄어들테니까요!

 

 

🎈 참고

 

Google Sheet 연동하기 (feat. Google API)

구글 스프레드시트 연동하다 빡쳐서 쓰는 글

velog.io

 

 

하지만 이 경우 예상 못한 문제가 발생하면

사용자 재량으론 해결할 수 없습니다.

 

개발자가 직접 나서서 데이터를 수정하거나

빠르게 기능을 수정 또는 추가해야겠죠...🤣

 

 

 


# 결론

다음 편에는 사용자 조작오류를 줄이고자 시행했던

 

 

5. 안내한 방법대로만 쓰도록 조작범위를 제한

 

때문에 발생한 [예상치 못한 오류]를 소개해보겠습니다.

 

 

생각보다 복기할 거리가 많아서 흥미로웠던 작업이었습니다.

첫 시리즈 글이라 읽어주셔서 감사합니다😊

 

반응형