[사업 이야기] UI/UX 리뉴얼, 그리고 버그 수정

요새는 UI/UX 리뉴얼 작업을 진행했다.

졸업 작품이랑 병행하기에는 다소 시간이 모자란 감이 있지만 그래도 이렇게 바쁘게 사는 걸 좋아하다보니 좋은 선택인 것 같다.

 

그리고 베타 기간에는 일부 기능이 미흡하거나 오류가 있었는데 이를 수정하기도 했다.

(예를 들어 회원 탈퇴는 수동으로 해줬어야 했는데 이제 서비스 내에서 자동으로 수행할 수 있도록 로직을 개선)

 

🤔 그래서 어떻게 리뉴얼을?

UI/UX를 어떻게 바꿨을까?

 

이게 이제 원래 UI 였는데, 조금 더 다듬어서 그럴 듯하게 만들었다.

전체 사진을 첨부하진 못했지만 위와 같은 UI였는데 아무래도 조금 밋밋하다거나, 딱딱한 감이 있다고 판단해서 다시 만들었다.

 

 

상당히 이제 깔끔하고 더 다채로워진 UI라서 마음에 든다.

(그 외에 정말 바뀐 UI가 많은데 사진이 너무 많아져서 생략..)

 

❓ 이렇게 완성인가?

베타 기간에 운영을 해보니까 이 시스템을 이해하지 못하는 분들이 많았다.

그래서 아마 더 직관적인 UI가 뭐가있을지 고민을 더 해보지 않을까 싶다.

 

약간의 개선

 

 

그래도 뽑은 사람은 "탭해서 확인" 이라는 문구를 추가해서 어느 정도 개선하기는 했지만 여전히 모르는 사람들은 이해하기 힘들 수도 있기 때문에 더 고민을 필요해보인다.

 

 

 

 

 

 

 

🤔 버그 수정? 어떤 점?

참 난감한 버그였다.

지금은 관련 제보글이 사라진 상황이긴 하지만 좀 특수한 상황에서 나타나는 버그였다.

 

지금 시스템의 구조는 "무료 하루 1장, 유료 하루 10장" 까지 응모가 가능한 구조였다.

근데 예전에는 해당 제한을 별도로 서버단에서 검사하지 않았었다.

테이블 구조

 

지금이야 payment_id와 coupon_code 값을 토대로 유료 응모권 여부를 검사해줬는데,

예전에 버그가 발생할 때에는 is_free 만 존재했었다.

 

따라서 이미 구매한 payment_id 가지고 계속 무한정으로 요청을 보내면 무한대로 응모가 가능한 현상이 있었다.

다행히 다음 날 새벽에 이를 빠르게 수정해서 마무리되긴 했다.

 

하지만 또 버그가 발생했는데, 무료로 응모하는 사람들이 정상적으로 무료 수량으로 집계되지 않는 현상이였다.

즉 다시 말하자면

1.  남성이 무료 응모권을 정상적으로 구매함
2.  여성이 무료 응모권을 구매 시도
3.  서버단에서 구매하려는 여성의 ID로 구매 여부를 검사하였으나, 실제 응모는 매칭 예정자 남성의 ID로 응모
4.  여성이 무료 응모권을 추가 구매 시도
5.  3번 반복

 

이게 테스트 할 때는 나타나지 않았는데, 남성 사용자가 훨씬 많다보니까 이러한 현상이 나타나는 것으로 파악됐다.

이건 처음에는 인지하지 못했다.

(남성 사용자는 여성 사용자가 적다보니 매칭 예정자인 여성이 존재하지 않아 발생하지 않음)

그래서 고치는데 이틀정도 걸렸다.

 

관련 코드

 

saveApplicationRecord(userID, waitingID, mySchool, now, &now, isTrulyFree, paymentId, currentCouponCode)

 

지금은 잘 되있는데 저때는 waitingID랑 userID가 서로 바뀐 위치에 존재해서 그랬던 문제이다.

(보면 waitingID 가 0이면 else 문으로 빠져나가기 때문에 남성 사용자의 경우에는 일어나지 않던 오류)

 

 

 

그리고 또 하나는 버그는 아니고 사용자가 조작 실수를 일으키는 경우인데,

결제가 완료되면 경우에 따라 redirect 되거나 또는 결제 결과값을 return 받아야하는데,

return 받는 경우는 PC인 경우라서 솔직히 큰 문제가 없지만, redirect 방식을 통해 돌아오는 모바일의 경우 문제가 발생한다.

redirect가 진행되는 중에 돌아가기 버튼을 통해 페이지를 아예 벗어나면 검증 페이지로 들어가지 못해서 돈은 빠져나가지만 실제 응모가 진행되지 못하는 경우가 있는 것이다.

(관련해서 환불 케이스가 2건 존재)

 

 

 

😎 추가 기능

1. 탈퇴 기능

 

드디어 자체적으로 탈퇴하는 기능을 구현하였다.

이미 대상을 뽑았는데 대상이 탈퇴하면 이름과 연락처를 "탈퇴한 사용자" 로 마킹해서 표시하게 되게 구현하였다.

(서비스 이용 기록은 시스템 상 외래키로 지정되어 강제로 삭제할 수가 없어 즉시 탈퇴가 어렵다.)

 

서버 코드

 

살펴보면 DeletedAt 필드가 비어있지 않으면 탈퇴한 사용자로 판별되기 때문에 정보를 마스킹해서 반환함을 알 수 있다.

(마찬가지로 회원 탈퇴 Handler 함수에서도 DeletedAt 필드를 업데이트 해주는 방식으로 탈퇴를 처리)

 

 

 

 

 2. 성별, 이메일 수정 기능

 

 

각각 기존 회원정보 수정창과 신규 회원정보 수정창이다.

기존에는 이메일과 성별은 수정할 수 없었지만, 이제는 이메일과 성별을 수정할 수 있도록 만들었다.

서버단에는 처음부터 변경할 수 있도록 구현해두었지만 프론트에서만 구현하지 않았던 부분이라 빠르게 바꿀 수 있었다.

 

이후에는 좀 더 고민해보고 나이도 변경할 수 있도록 할지, 그리고 휴대폰 번호를 변경하게 지원할지 (인증 거치고)

고민을 해봐야겠다.

 

 

 

 

😎 그리고 대망의 보안 업데이트

사실 이게 제일 하고싶은 이야기가 길다.

많은 사람들이 커뮤니티에 개인 정보 보호가 안된다. 등 진짜 말이 많았는데, 너무 억울했다.

 

어쨌든 개인 정보긴 해서 모든 필드를 노출할 수는 없지만 보안이 중요한 필드는 모두 암호화가 진행되어 있었다.

원래는 aes 암호화만을 채택했는데, 그래도 불안하신 분들이 계셔서 이번에 추가로 bcrypt, aes, sha521 암호화 등을 수행했다.

 

(보안상 또 다른 필드들과 그 필드에 대한 다른 알고리즘은 공개하기 좀 힘들다.)

(마찬가지로 보안상 코드도 첨부할 수 없다.)

 

핸드폰 필드는 aes 암호화를 수행하고, 패스워드 필드는 bcrypt 암호화를 수행하게끔 해주었는데

aes 암호화는 매번 수행 시 Salt 값이 달라지기 때문에 동일한 핸드폰 번호에 대해서도 다른 암호화 결과값이 나오기 때문에

sha512 암호화를 통해 핸드폰 번호를 암호화하고 이를 phone_hash 에 등록 (동일 번호 중복 회원가입 방지용)

그리고 핸드폰 번호는 phone 필드에 삽입하도록 해주었다.

 

물론 이렇게하면 핸드폰 번호인 0~9,999,999 범위에 대해서 Brute Force를 수행하면 Phone Hash 를 추정할 수 있다는 단점때문에 당연히 sha512 암호화를 진행할 때에도 핸드폰 번호 뒤에 공개되지 않은 암호화키를 덧붙여 이를 방지하였다.

 

이렇게까지 해도 사용자 입장에서는 학생인 내가 서비스를 운영한다는게 불안한 것 같지만 이게 내가 할 수 있는 최선인 것 같다.

 

 

 

👉 결론?

사업을 실제로 해보니까 되게 우여곡절이 많은 것 같다.

사업 전에는 사람들이 아무리 뭐라해도 흔들리지 않을 자신이 있었는데, 솔직히 나도 사람이라서 흔들리는 건 어쩔 수 없는 것 같다.

 

 

👍 참고 자료

bcrypt 암호화

bcrypt - 위키백과, 우리 모두의 백과사전

 

aes 암호화

고급 암호화 표준 - 위키백과, 우리 모두의 백과사전