펑션에서 뒤끝베이스 기능 사용 빈도에 대해

고객님의 문의에 답변하는 직원은 고객 여러분의 가족 중 한 사람일 수 있습니다.
고객의 언어폭력(비하, 조롱, 욕설, 협박, 성희롱 등)으로부터 직원을 보호하기 위해
관련 법에 따라 수사기관에 필요한 조치를 요구할 수 있으며, 형법에 의해 처벌 대상이 될 수 있습니다.

커뮤니티 이용 정책에 위배되는 게시물을 작성할 경우, 별도 안내 없이 게시물 삭제 또는 커뮤니티 이용이 제한될 수 있습니다.

문의 응대 : 평일 오전 10시 ~ 오후 6시
문의를 남기실 경우 다음 항목을 작성해 주세요.
정보가 부족하거나 응대시간 외 문의하는 경우 확인 및 답변이 지연될 수 있습니다.

  • 뒤끝 SDK 버전 :
  • 프로젝트명 :
  • 스테이터스 코드 :
  • 에러 코드 :
  • 에러 메시지 :

펑션에 대해 공부하던 중 커뮤니티를 좀 둘러보던 중에 뒤끝펑션에 사용되는 뒤끝베이스 기능이 많을수록
요청에 대한 반환 속도가 많이 늦어지기에 최소 2~3개 정도로만 사용을 권하는 내용의 글을 봤습니다.
그래서 그 내용을 기반으로 펑션에서 상점 아이템 구매에 대한 로직을 작성하던중에 고민이 생겼는데,

  1. 유저의 재화 상태 읽기
  2. 상점 차트 읽기
  3. 구매성공한 아이템 유저의 인벤토리에 쓰기
    3_1)만약 인벤토리를 먼저 읽어야 한다면 읽기(저장할때 새로 쓰는개념이기에 기존 아이템 손실 방지)
  4. 재화 차감 쓰기
    5_1) 만약 아이템의 기록 데이터가 있을 경우(구매제한횟수 같은것) 읽기 및 쓰기

이렇게 많으면 6번의 호출이 발생 하게 되는데 어느정도 클라이언트 보안의 타협을 보고 호출 수를 줄여야 할까요…
따로 최적화 할만한 방법이 있는지 제 머리로는 생각이 안나서 여쭤봅니다.

안녕하세요 개발자님,
불러오려는 차트 데이터가 펑션 타임아웃(10초)이 발생할 정도의 대용량의 데이터라면 문제가 되겠지만 그렇지 않으면 말씀해주신 구성은 허용 범위 이내로 예상됩니다.
다만 충분한 테스트와 추후에 차트의 용량이 변동 될 것을 고려해 보신 뒤 사용을 권장드립니다.

호출을 줄일 수 있는 방법은 상점 차트를 펑션에서 처리하는 방법이 더 안정적일 수는 있겠으나
CDN차트를 사용하여 로컬에 차트를 저장하고 구매할 아이템 id와 구매 갯수 등을 펑션으로 전달하여 처리하는 방법이 있습니다.
구매 전 차트를 항상 최신화를 유지하면 해킹/변조의 위험 또한 줄일 수 있습니다.

3-1의 펑션을 사용하지 않고 경우 구매 직전에 데이터를 클라이언트에 임시 저장해두셨다가 에러 발생 시에만 사용하시는 방법도 고려해보시면 좋을 것 같습니다.

이해가 잘 가지 않아서 질문드립니다.
결국에는 펑션에 아이템 id, 구매 갯수, 가격정보 등을 전달하게 되는 시점에서
해커가 데이터를 변조해서 보내는 경우가 생기게 되는게 아닌가 싶은데
구매 전 차트를 update한다고 해서 의미가 있는 것인가요?
그래서 결국에는 펑션쪽에서 다 처리하여 데이터 변조 위험을 원천방지 해야겠다는 계획이였습니다.
사실 데이터 변조 관련해서는 지식이 얕아서 제가 잘못생각하고 있는것이라면 죄송합니다.
그리고
3-1의 답변에 대해 이해가 힘든 부분이 있는데
3-1의 질문의도는 구매성공한 아이템을 인벤토리 적용해야할때 구매아이템들을 유저의 보유아이템을 관리하는InventoryData라는 테이블에 추가해야하는데 구매아이템들만을 가지고 해당 테이블에 업데이트 해버리면
기존 보유 아이템은 사라지고 구매아이템만 적용되어버리기 때문에 기존 보유 아이템리스트를 가지고 있는 InventoryData에 있는 한번 불러와서 그 리스트에 구매 아이템을 추가적용해서 그 자체를 다시 update해야 하지
않나라는 의도로 질문했습니다. 근데 클라이언트에서 임시 저장했다가 “에러 발생 시” 라는 의미가 정확히 무슨 의미인지 잘 모르겠습니다. 보충해서 설명해주시면 감사하겠습니다. (_ _

먼저 말씀해주신 것처럼, 서버내에서 모든 로직을 처리하여 데이터 변조 위험을 원천적으로 방지하고자 하시는 목적이라면,
모든 처리를 펑션에서 수행하고, 필요한 데이터는 조회 함 또는 저장 함수를 활용하시는 방법으로 구성하시는 것이 맞습니다. (단, 저장 함수를 통해 차트를 서버 로컬에 저장하는 경우는 다른 문의에서 답변드린것과 같이 메모리가 해제된 후는 조회가 불가하기에 이후 추가 호출이 필요합니다.)

앞서 안내드렸던 내용은 호출 최적화 관점에서 고려할 수 있는 방법을 예시로 드린 것이며,
변조 방지 자체를 가장 우선으로 생각하신다면, 호출 횟수가 다소 많아지더라도 말씀해주신 것들과 같이 로직을 안전하게 구성하는 것이 권장되는 방향입니다.

좋아요 1