질문/조언팁/리소스 공유

지난 번  "처음으로 적는 불만족 제품 사용후기" 에 이어

더이상 좋은 구매 경험기나 후기가 아닌 이런 글을 적게 될 날은 오지 않기를 바랬지만 

 

제가 아래 제품에서 좋은 개발자와 좋은 제품이라는 평을 적었던 적이 있었던 만큼

그 반대의 경험도 존재 하기에 사실 그대로 구매 하시는데 참고가 되시라고 적어 봅니다. 

  

개발자 분만 생각하면 이런 글을 적는게 도리가 아닐지도 모르겠지만

기존 제 글을 통해 장미빛 그림만 그리고 불필요한 지출을 하게 만드는데 기여를 하게 될수 있으니 적어 봅니다.


제가 오늘 구매 경험기로서 적을 제품은 아래와 같습니다. 기존 저의 후기는 아래 링크를 통해 보시면 됩니다. 

https://xetown.com/?act=&vid=&mid=tips&category=&search_keyword=Skyo&search_target=nick_name


1. 시간이 흐른후 기능 활용 문제

(1) 에디터 자동완성 모듈 

해시태그 불러오기 : 미사용. (아래 해시태그 자동생성 퀄러티 문제와 맞물림)

URL 카드 불러오기 : 미사용. (모듈 문제가 아니라 API 형태 라서 초과시 추가 과금.)

 

(2) 인공지능 모듈

이미지를 분석하여 태그 생성 : 이미지를 분석 할 이유도 별로 없고, 분석 퀄러티 역시 좋지 않아 미사용

해시태그 자동 생성 : 해시태그 자동생성 퀄러티가 만족 스럽지 않아 미사용

 

(3) 구독 모듈

구독을 기반으로 알림 기능은 푸쉬서버가 별도로 있지 않는 이상 저희 사이트 기준 7~800명 이상 구독 되는 경우 

푸쉬 알림 덕분에 속도에 큰 영향을 미치게 되며, 사람이 몰리지 않는 특정 시간대에 알림을 보내는 백그라운드 알림도 가능하지만

사실 그건 이미 유저 입장에서 알림이 알림이 아니게 됩니다. 

즉, 유저가 이미 본 글에 대해서 알림이 더 늦게 발송 되어 버리는 경우가 다반사. 

결론 적으로 구독을 해도 구독한 유저에게 줄수 있는 이점이 없으므로 구독을 할 이유가 별로 없습니다.

그러나 구독 숫자를 통해 회원에게 동기 부여는 할수 있습니다.

 

(4) gif convert pro 모듈

라이믹스는 모듈의 핵심 기능은 이미 기본적으로 탑재

 

(5) 뮤직 모듈

제대로 사용 못하고 있습니다.

버그 개선 지연 문제는 아래 따로 적도록 하겠습니다.  아래 참고.

 

(6) textarea plus 모듈

거의 문제 없습니다. 아주 추천 합니다.

 


2. 버그 및 개선 사항에 대한 지연 문제 :  저의 그간 제 후기글에 달린 다른 분들이 적어 주신 아래의 관점에서 해당 문제를 적어 봅니다.

 

[스크린샷 2020-06-28 오후 10.17.44.png]

 

[스크린샷 2020-06-28 오후 10.18.27.png]

 

 

저는 위 6번 제품을 제외한 다른 제품들 전반에 걸친 업데이트 및 개선 약속 들이 

묘하게 계속해서 지연이 되는 느낌을 받아서 지난 주 개발자 분에게 문의를 드렸었습니다.

사실 업데이트는 의무도 아니고 개발자 자의에 의해서 안해도 됩니다. 그러나 약속은 약속이지요.

 

그 약속의 예시에 대해서 적어 봅니다.

 

아래는 단편적인 예시 입니다.

2018년도에 이미 많이 지연이 되었고

이제는 그 시간 마저도 지나 몇몇 다른 fix 예정 사항들은 결국 2020년의 10월을 넘어가는 형국이 되어 버렸습니다. 

7c5dfb8f2bf0b64ef645d592d99906ed.png

스크린샷 2020-06-28 오후 9.50.06.png

 

그리고 2019년도 뮤직 모듈 예시중 하나. 확인의 의미와 그 이후 행방은~

스크린샷 2020-06-28 오후 10.15.21.png

 

 

 

이렇 듯 좋은 제품 포함 사실 고마웠던건 고마운거고

제품 구매 이후 구매 이후 경험은 여전히 별도로 봐야 할 것입니다. 

위 다른 분의 댓글에도 적혀 있지만 제품 구매 경험에는 지원도 포함이 되는 것이니까요.
 

위 상황들의 예시에서 제가 받은 구매 경험의 느낌을 조금 더 축약하자면

 

1. 전반적으로 제품 개선의 to-do 관리에 있어서 클리어 하지 않습니다.

아래 처럼 까지는 아닐지라도 말이죠. 물론 아래 개발자 분도 이미 두차례 이상 지연이 있었지만

tracker가 있기에 단순 개발 지연 자체는 반복되지 않는 이상 큰 문제가 되지 않습니다. 

스크린샷 2020-06-28 오후 10.55.57.png

 

 

그러나 위 제품들은 이 정도 수준 입니다. 메모..

스크린샷 2020-06-28 오후 10.52.50.png

 

즉, 계획은 있지만 일정이 없는 경우도 많고, 결국 개인적으로 계속 해서 따라 다녀야 하는 느낌은 지울수가 없었습니다.
 

스크린샷 2020-06-28 오후 10.51.46.png

 

 

2. 물론 제가 기대치가 유별나게 높은 것 일수도 있겠습니다.

판매자도 사람이고 구매자도 사람인데 

상식적으로 서로간에 유지 보수의 기간을 life-time 으로 제공 할수도 없고, 기대해서도 안될 겁니다.

그 말은 즉슨 개발자는 계약에 명시가 되어 있지 않는 이상 유지보수에 대한 계약적으로 책임과 의무는 없습니다.

하지만 그 다음은 신뢰의 문제 일겁니다.

 

"수정중에 있다" "메모하였다" "우선순위에 두고 있다" 상태에서 기약없는 장기간의 지연은 결국 아예 "fix 하지 않겠다" 견줄 만큼 구매 경험에는 나쁜 상황이 되어 버립니다.

 

일단 구매자가 리마인드를 몇번이나 작성을 하는 케이스가 벌어지는 동안에

충분히 지연이 예상 되는 케이스의 경우 미리 미리 소통을 했으면 하면 어땠을까 하는 생각은 특정인의 기대치만의 문제는 아닐 것입니다.

(보통 이런 경우 개발자가 케이스 별 공지로 올리곤 하죠)

 

즉, 마일스톤 트랙커가 별도로 없는 상황 = 즉, 개발자가 무엇을 개선하고 있는지 구매자가 아무것도 알수 없는 상황에서

"개선 예정입니다" "고쳐질 예정입니다" "업데이트 예정입니다" 등의 개발자의 약속은

구매자에게 (1년 이상 지나고 다시 상황을 봐야한다) 라고 애초 부터 읽히는게 아니라는 점을

간과하고 있는 것이 아마도 현재 위 제품들이 가진 가장 큰 문제라고 말하고 싶네요.

 

긴 후기 읽어 주셔서 감사합니다. 기존 제품 기능 활용에 주안점을 둔 후기에 이어서 

해당 제품 구매에 관심이 있으신 분들은 참고가 되었으면 합니다. 감사합니다.

 

p.s 이 후기가 구매후 기능에 대한 활용 및 만족에 이어진 최종 구매 경험에 관한 글이므로

해당 제품들의 관련 내용의 새로운 업데이트가 이루어진다면 그떄 역시 새롭게 이어서 작성하도록 하겠습니다.

 

글쓴이 skyo

?
XE타운 관리자 입니다.
관리자 아닌것 같지만 제이쿼리 엔지가 없는게 매력인 관리자 입니다.
  • profile
    구독모듈의 알림 기능은
    백그라운드 php cron으로 1분 정도의 주기로 실행하면 너무 늦게 받는 부분은 해소가 되면서 글 등록시 서버에 요청하는 시간이 길어지는 문제는 해결 될 것으로 보입니다.
  • profile ?

    1분 주기로 실행 시킬거면 알림을 백그라운드로 돌릴 이유도 크게 없습니다. 게다가

    구독 회원이 7~800명 되는 회원이 틈나는 대로 글을 쓰기 하는 상황에서는 문제 입니다. 물론 모듈 자체의 문제라기 보다는 

    해당 모듈의 활용성의 문제로 귀결 됩니다.
     

  • ? profile

    네. 글 등록시 등록이 딜레이 되는 현상은 없앨 수 있구요. 백그라운드로 메일,알림 보내는 정도는 다른 사용자들은 불편을 못느낄 정도로 소화가 될 것이라 추천해 드렸습니다.

    글 등록자가 푸시까지 마쳐야 하는(동기 동작 때문에) 경우 등록이 한참 걸리지만 백그라운드로 하는 경우는 이런 점이 없습니다.

     

    저희는 푸시앱을 사용해서 구독알림은 지금은 제공하지 않지만 푸시앱의 경우 푸시발송을 비동기로 처리해 줘서 글 등록 버튼 눌러도 알림 2000개 처리를 해도 일단 글 등록하는 작업은 지연이 되지 않고 사용자는 느끼지 못하게 처리가 되네요.

  • profile
    업데이트 부분은 기대를 할 수 없는 상황이니 이제는 포기?? 상태라 어쩌면 신경을 끄게 되었네요.
  • profile ?
    네. 좋은건 좋은것 대로 기존에 작성했기에.... 아닌건 아닌지라 같은 관점에서 이어서 작성 하게 되었네요.
  • profile
    구독모듈은 확실히 활용도가 떨어집니다.
    구독자 수가 수십명 이상인 경우 글 등록시에 서버요청 딜레이도 상당하고 이런 글을 동시에 여러명이 작성할 경우에는 문제가 다 심각해 질것으로 생각됩니다.

    현재 저는 회원간의 구독보단 관리자의 공지를 위한 용도로 주로 쓰고 있습니다.

    그래도 구름이님이 최근 유지보수가 많이 늦어진 느낌이 있지만 이미 이 만큼 장기간에 유지보수와 기능추가는 환영할 만한 일이기는 합니다.
    하지만 사용도가 떨어지는 기능 추가보단 버그픽스에 조금 더 노력을 기울여주셨으면 합니다.
    거의 스쿄님이 해결책을 포함한 오류 수정을 요청했지만 아직 새 버전에 반영이 안되는 것이(아니.. 새버전이 나오는 기간이 길죠.) 아쉽기는 합니다.

    이렇게 문제점만 적는 것 보다 개발자님 별로 장단점을 적는 리뷰도 좋을 것 같다는 생각이 듭니다.
  • profile ?

    ^^ 시간이 흐른후 기능 활용 문제 입니다. 기존 후기는 이미 링크 걸어 두었습니다

    스크린샷 2020-06-30 오전 11.10.28.png

     

     

  • profile profile

    업데이트가 늦어지는 문제(기약이 없는듯 한)는 프로그램이 안정된 것과 별개로 뒤늦게 발견 보고된 버그 픽스가 안된다는 문제점이 사용자로 하여금 큰 문제로 느껴지더군요. 그래서 적극 추천하기가 곤란해진 상황입니다.

    중요 대부분의 문제는 말씀 하신대로 기간이 오래된 만큼 안정적이거나 성능 향상이 이루어졌어도 개발 초기 이후에 피드백 한 문제가 사용상 굉장히 불편한 버그이거나 문제일 수 있거든요. 그런데 이런 해결해야할 것 들이 보통 6개월 안에 처리가 안되는 문제는 좀 심각합니다. 물론 개발자님 입장에서는 그 문제가 사이트가 중단되거나 전체 기능 중지 되는게 아니라 다음 업데이트 일정에 처리를 하시겠지만요.

    ex) 게시글을 이동 시 중요 기능이 문제가 발생하는 문제가 있는데 이런 버그가 처리가 안된다면 사이트 운영자 입장에서는 게시글 관리에 굉장히 어려움이 생기는데 이런 경우가 현재 진행형입니다. (약 14개월째.....)

    ex는 샘플 중 하나 입니다.

  • ? profile
    네. 이미 그 글 작성하실 때 읽어봤었습니다.
    본문에도 재차 강조하면서 적으셨지만, 그리고 물론 사실을 적으시긴 했지만 단점만 있으니 구름이님이 걱정이 되긴 합니다. ^^;;
  • profile profile
    네. 꽤 중대한 버그픽스가 미뤄지고 있는 부분은 공감합니다.
    솔직히 저도 자동완성 모듈은 기능을 반만..(자잘한 버그들 때문에) 구독 모듈은 거의 사용을 안하고 있는 상태입니다.
    아이디어는 좋았으나 막상 사용해보니 실제 적용시 효율성이 많이 떨어집니다.
  • ?

    구독모듈같은 류의 프로그램이 알람 발송땜에 웹사이트가 느려지는 문제는 동기화된 동작을 하고 있다면 사실 구조상 당연한거라서...
    cron으로 돌리는 것에 대해서 뭔가 거부감을 가지고 계신 것 같은데...
    cron으로 돌리는건 땜빵식 문제해결이 아니라 사실상 [근본적인 문제해결방법]입니다.
    구지 cron이 아니더라도 하여튼 뭔가 웹사이트와는 별개로 따로 백그라운드로 돌게 할 수 밖에 없습니다.
    그리고 웹사이트가 느려지는 문제와는 별도로 알람 발송 자체가 지연되는 문제는..
    백그라운드로 돌리되 1프로세스가 아니라 여러개의 멀티프로세스로 동시 처리를 해서 처리능력 자체를 향상시키는 수 밖에 없겠죠.

  • ? ?

    음.. 뭔가 자의적인 해석이 강하신것 같은데 글 다시 보시길 추천 합니다.

    "구독을 기반으로 알림 기능은 푸쉬서버가 별도로 있지 않는 이상 저희 사이트 기준 7~800명 이상 구독 되는 경우
    푸쉬 알림 덕분에 속도에 큰 영향을 미치게 되며, 사람이 몰리지 않는 특정 시간대에 알림을 보내는 백그라운드 알림도 가능하지만 사실 그건 이미 유저 입장에서 알림이 알림이 아니게 됩니다. "



    구독모듈이 알람 발송땜에 웹사이트가 느려지는 문제는 동기화된 동작을 하고 있다면 사실 구조상 당연한거라서...
    >> 그 당연한걸 미리 고지 받지 못했고, 당시는 지금 보다 더 지식이 미천하기도 하여

    스크린샷 2020-06-30 오후 1.17.57.png

    스크린샷 2020-06-30 오후 1.18.04.png

     

    대략 적으로 구독 회원 숫자 에 따른 알림 숫자 와 동시에 몇개가 발송이 되면

    저의 사이트 동접 유저에게 실제 유의미한 부하가 걸리는지 알기가 힘드네요.

     


    cron으로 돌리는 것에 대해서 뭔가 거부감을 가지고 계신 것 같은데...
    >> 크론에 대해 거부감을 적은 적 없습니다. 위 글 다시 보시길 바랍니다.
    크론을 사용하기 전에 오히려 문제가 있다는 것이고 그 문제를 해결하기 위해 크론을 사용 해야 한다는 겁니다.

    cron으로 돌리는건 땜빵식 문제해결이 아니라 사실상 [근본적인 문제해결방법]입니다.
    >> 그러니 말씀하신대로 크론이 근본적인 해결 방법인데, 이 논리로 접근하면 처음 부터 실시간 알림 기능이 존재하는 이상 

    부하는 미리 고지 되었어야 합니다. 물론 말씀 주셔서 말하는 거지 고지 여부 자체에 거부감은 애초부터 없습니다.

     

    그리고 웹사이트가 느려지는 문제와는 별도로 알람 발송 자체가 지연되는 문제는..
    백그라운드로 돌리되 1프로세스가 아니라 여러개의 멀티프로세스로 동시 처리를 해서 처리능력 자체를 향상시키는 수 밖에 없겠죠

    >> 결국 이 역시 고지 여부와 맞물려 있는데, 웹마스터에게는 따로 작업의뢰를 해야 하는일인건 사실입니다. 

    만약 구독자 수가 늘어 구독 알림 기능 부하가 생겨 부하를 줄이기위해 따로 이런 작업을 해야 하는 걸 알았다면 전 해당 모듈 구매를 보류 했을 겁니다. 대부분 본인 사이트가 영원히 소규모로 정체 되어 있는걸 기준으로 제품을 구매하지는 않을테니까요.

  • ?

    알림 발송수가 엄청 많은 경우 보통 메세지 큐랑 node조합으로 많이 하죠.

    php는 알림 발송을 메세지 큐에다 전송 예약으로 해 놓으면 node가 알아서 꺼내서 처리하는 구조로.

    알림 수가 적을때는 그냥 복잡하기만 한 시스템 구조지만, 알림 량이 많아지면 이 구조를 안 쓰고는 못 버티겠더군요..

     

    예전에 알림 처리하면서 느낀 것 중에 하나가

    푸쉬 알림 처리는 php 하나로 처리하긴 어려운 것이였습니다. ㅠㅠ

    저도 첨엔 cron을 생각해 보았으나, 푸쉬를 보낼 게 없는 상태에서 푸쉬를 보낼 게 생겼으면 바로 보내야 하는데, cron이 다시 실행되기 전까지 CPU는 아무것도 안하고 멍청하게 놀아버리는 문제가 있죠..

  • ? ?
    구지 php를 써야한다면 cron을 안쓰고 php 프로세스를 그냥 무한루프로 돌리는 방법도 있긴 하죠..
    php안에서 무한루프를 돌거나 node를 쓰거나 결국 내부적으로 동작하는건 비슷한 모습일겁니다. 슬립 들어갔다 나왔다 루프돌면서 드문드문 db 살펴보다가 레코드 있으면 처리하고...
  • ? ?
    네. 맞습니다.

    결국적으로 크론을 이용하는 백그라운드 방식은 사실상 알림으로서 의미가 퇘색되어 버립니다. 유저 입장에서는요.

    한 10년전 스마트폰에서 푸쉬 알림 기능이 감지덕지 하던 시절만 해도... 유저들이 이해를 하겠지만

    이제는 유저에게 "알림"이라는 기대치는 이미 높아질대로 높아졌기에

    알림이라는 기능을 하고 실시간 반응을 보여주지 못하면 어쩔수 없이 선택지에서 제외가 됩니다.
  • ? ?
    구조적으로 다른게 있다면 php와 node 사이에 메세지 큐를 사용하는 겁니다.
    sleep를 사용할 일도, 주기적으로 db를 들여다 볼 필요가 없어요.

    sleep구문을 넣어버리면 일이 들어오면 바로 처리해야하는데 금쪽같은 시간을 놀게 냅두면 아깝잖아요.. ㅎㅎ
    db를 계속 들여다 보는 것도 자원 소모가 지속적으로 발생하고..
  • ? ?
    php나 node같은 스크립트 언어들이 OS에서 제공하는 메시지큐를 직접 쓸 수 있나요?
    몰랐네요... 쓸 수 있으면 좋긴 하겠네요.. 일 있을때만 깨면 되니까요...
  • ? ?

    OS의 메세지 큐 보다는 rabbitmq나 activemq같은 프로그램의 도움이 필요합니다. ㅎㅎ

  • profile
    skyo님께서는 xetown 관리자셨군요. 제자료에 대한 후기는 없어서 다행이네요^^;
    xetown 관리하시면서 장단점을 말씀해주시는 것도 좋은 것 같습니다. 그래야 상호발전이 있으니깐요.
    닉네임이 좀 익숙해서 댓글을 남겨봅니다.
  • profile profile
    XETown을 관리한다고 해서 전체적인 모든걸 총괄하지 않습니다.
    운영에 참여만 하여 방향성이나 의견제시등등의 활동을 하죠 ㅎㅎ

    실제로 모듈 설치나 스킨 수정및 등등의 작업은 대부분 여기를 처음만드셧던 코노리님이 하시고 계십니다.
  • profile profile
    아 그렇군요. 제가 관심을 좀 못가진것에 대해 반성합니다.^^ 코노리님께서 만드셨군요.
    코로리님을 포함해서 xetown 관리자 여러분 감사합니다.
  • profile
    오.. 제 경험과는 조금 달라서 댓글남겨봅니다.

    저는 그 개발자님의 구독 모듈, 뮤직 모듈, TextArea plua, 음성 합성 구입하여 사용하고 있는데 모두 다 완성도가 높다고 생각하고 잘 활용하고 있습니다.

    구입당시 버그라고 해야할지 fix 되어야할 부분과 저희 사이트에 맞게 소소한 업데이트해야 할 부분이 있었는데 픽스 되어야할 부분은 빠르고 정확하게 해주셨고, 업데이트가 필요한 부분은 적정한 금액을 내고 진행했으며 마찬가지로 약속한 기간내에 깔끔하게 처리해주셨습니다.

    가장 만족스러운 부분은 업무 시간엔 거의 바로 응대를 해주시는 편이라 (어찌 보면 당연한건데)
    최소 연락이 안되서 답답한 경우는 없다는 점이랄까..
    여튼 제 경험은 제품과 as 모두 전반적으로 만족이었습니다 :)
  • profile ?

    저도 그랬었습니다. 당시에는요~ 그리고 응대 자체가 문제가 아니라 응대 이후의 문제에 방점이 있기도 합니다. 

  • profile

    A/S(뿐만 아니라 전반적인 서비스)가 제대로 되지 않으면
    아무리 제품이 좋아도 구매자 입장에서는 실망스러울 수 밖에 없다는 걸
    다시 한번 깨닫게 해주는 글이었습니다.

    저도 더 노력해야겠네요.

  • ?
    생각해보면.. 아이템모듈이라던지 은행 등등.. 변경도 자유롭고 기간에 촉박하게 불안해 할 필요도 없고 정말 좋은 곳 이였군요. ㅎㅎ