우편 관련하여 문의드립니다.

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

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

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

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

안녕하세요 메타본 엔터테인먼트 클라이언트 개발자입니다. 이번에 우편쪽 유저 cs를 작업하다 우편 리스트를 갱신할때 우편을 10개까지 가져오지만 모두 받기 기능을 처리할때는 그이상의 우편도 한번에 수령처리하는부분을 확인했습니다.

현재 저희로직상 확인된 캐싱 우편에 한해 아이템을 지급하게 되어있어 이부분을 우편 수령하는쪽에서 보내온 아이템 정보로 아이템을 지급하려 했으나 수령내역을 표기하기위해선 우편 내용과 제목역시 필요한데 이부분이 누락되어있어 결국 우편리스트를 갱신할때 전체 우편 내역을 캐싱하는식으로 방향성을 정했습니다.

단 현재 Backend.UPost.GetPostList 를 호출할때 limit 카운트를 10개에서 100개 까지 범위를 지정할수있는데 랭킹 관련 함수랑 달리 다음시작점을 지정할수있는 offset 전달인자가 확인되지 않아서 만약 우편리스트 100개 이상이 누적되었을때 101번째 우편을 요청하기위해선 어떤 프로세스를 타야할지 여쭤보고싶어 문의드립니다.

안녕하세요 개발자님,
뒤끝의 우편시스템은 가장 마지막 조회된 우편부터 조회를 시도하는 형태로 제공중에 있습니다.

만약 유저가 받을 우편이 101개가 있는 상황에서 limit 카운트를 100으로 설정하여 호출을 한다면
100개의 우편이 조회되며, 이후 추가 조회를 할 때 남은 1개의 우편을 추가로 조회하게됩니다.

또한 우편 전체수령의 경우 조회된 우편에 한하여 수령하기에,
101개의 우편이 있는 상황에서 limit 카운트를 100으로 설정하여 1회 조회 후 전체수령 함수를 호출하면 100개의 우편만을 수령하며,
이후 추가 조회를 통해 조회된 우편은 다시금 전체수령 또는 개별수령을 진행하면 수령할 수 있게됩니다.

만약 limit 제한보다 더 많은 우편을 조회만하고 수령하지 않고 있는 상황이었다면
조회시 가장 최근 limit 수만큼의 우편만이 조회되지만, 더 많은 우편을 수령하게될 수 있습니다.

전체수령 함수는 '조회가 완료된 우편’에 한해서만 수령되는 점
그리고 우편조회는 가장 마지막 우편부터 limit 에 맞게 우편을 조회하고,
더이상 새로이 조회할 우편이 없다면 최근 우편부터 limit에 맞게 조회되어 제공되는 점 참고하여 이용해 주시면 감사하겠습니다.

조회가 완료된 우편이라는건 Backend.UPost.GetPostList 를 통해 클라이언트에게 전송된 이력이 있는 메일이라고 이해해도 될까요?

상황 예시를 들어드리겠습니다.
모든 상황은 limit 10 조건으로 조회하며,
우편 제목은 가장 먼저 발송된 우편 제목부터 1~15 로 15개의 우편이 발송되어있다는 조건입니다.

  • A유저가 아직 어떠한 호출도 하지 않은 상황
    • ex1>
      1. 조회 함수 1회 호출 시 / 1~10 우편 조회
      2. 전체수령 함수 1회 호출 시 / 1~10 우편 수령
        이 때 우편 11~15는 미조회 및 미수령 상태로 유지
    • ex2>
      1. 조회 함수 1회 호출 시 / 1~10 우편 조회
      2. 수령하지 않고 대기
      3. 조회 함수 1회 호출 시 / 6~15 우편 조회
      4. 전체수령 함수 1회 호출 시 / 1~15 우편 수령

현재 뒤끝 sdk 5.18.1 을 사용하고 있는데 sdk에 따라 다른 프로세스로 처리되고있을수도 있을까요? 일단 현재 DEV 테스트로 15개 가량의 우편을 전송한후 Backend.UPost.GetPostList 를 호출
이후 var postList = bro.GetReturnValuetoJSON()[“postList”]; 의 postList의 count가 10보다 클경우 재귀를 돌리게끔 처리했을때 postList.Count의 카운트가 지속적으로 10개로 발생을 하고있습니다.
또한 다른 dev 계정으로 우편을 10개 이상을 전송후 Backend.UPost.GetPostList를 호출했을때 우편 10개를 확인후 Backend.UPost.ReceivePostItemAll를 호출후 BackendReturnObject의 returnvalue를 출력했을때 우편 10개보다 첨부 파일처럼 우편 갯수보다 더 많은 아이템이 수령된걸 확인했습니다.

참고가 될수있게 해당 GetPostList 출력함수도 첨부드립니다.

public int count = 3;
/// <summary>
/// 특정 타입 우편 리스트 가져오기 (비동기 버전)
/// </summary>
public async UniTask GetPostListAsync(PostType postType, bool immidiately, CancellationToken cancellationToken = default)
{
    UniTask<BackendReturnObject> processAsync()
    {
        if (immidiately)
        {
            return UniTask.FromResult<BackendReturnObject>(Backend.UPost.GetPostList(postType, mailPostRequestCount));
        }
        else
        {
            var tcs = new UniTaskCompletionSource<BackendReturnObject>();

            SendQueue.Enqueue(Backend.UPost.GetPostList, postType, mailPostRequestCount, (bro) => tcs.TrySetResult(bro));
            return tcs.Task;
        }
    }

    var bro = await processAsync().AttachExternalCancellation(cancellationToken);

    if (false == BackendErrorHandler.ErrorCheck(bro))
    {
        return;
    }

    var userMail = UserGameData.GetUserData<UserMail>();

    var postList = bro.GetReturnValuetoJSON()["postList"];
    foreach (JsonData jsonData in postList)
    {
        try
        {
            var (title, content, inDate, expire) = ParsePostData(jsonData, postType);
            var attached = parsingItemsFromJsonData(jsonData);

            userMail.AddNetMail(postType, title, content, inDate, expire, attached);
        }
        catch (Exception ex)
        {
            Debugger.Error($"Failed to parse post data: {ex.Message}");
            continue; // 하나 실패해도 다른 우편들은 계속 처리
        }
    }


    if (mailPostRequestCount <= postList.Count)
    {
        count--;

        if (count <= 0)
        {
            count = 3;
            return;
        }

        await GetPostListAsync(postType, immidiately, cancellationToken);
    }
}

우편보상.txt (4.8 KB)

우편이 수령되지 않은 상태에서는 최근 우편을 limit에 맞게 계속 불러오게되므로 지속적으로 10개로 발생하게되는것이 맞습니다.

  • ex2의 6~15 우편 조회 사례 (4번의 수령작업이 없다면 조회시 계속 6~15가 조회)

dev 계정에서 우편 10개를 확인 후 수령하였을 때 10개보다 더 많은 우편을 수령하셨다고 말씀해주신 케이스는,
우편을 그만큼 더 추가로 조회했을 것으로 예상됩니다.
해당 계정의 uuid를 공유해주시면 정확히 호출내역 확인하여 안내드리겠습니다.

a1124ad0-9d15-11f0-a6c5-43850069ba7a 해당 계정의 uuid입니다 서버는 dev서버입니다.

말씀해주신걸 정리했을때 Backend.UPost.GetPostList 로는 limit 개수만큼 응답되고 이후 다음 메일리스트를 조회하기 위해선 현재 받은 리스트를 수령처리를 해야한다는거 맞을까요? 마지막 조회된 우편부터 조회를 시도한다고 하셨었는데 조회처리를 위해서는 결국 수령처리를 해야하는걸로 들립니다.

말씀하신것과 같이 조회된 아이템만 UI를 통해 보여주도록 하고있다면,
조회한 순간에 수령을 하지 않으면 조회범위를 벗어나는 아이템이 발생할수밖에 없습니다.
가장 좋은 방법은 limit을 언제나 최대치인 100으로 설정하고,
유저에게 발송되는 우편이 가능한 100개 미만의 우편이 존재하도록 하는 방법 뿐입니다.
(혹은 개별수령만 가능하도록 구성)

테스트 계정의 호출정보는 확인하여 안내드리겠습니다.

확인 시 a1124ad0-9d15-11f0-a6c5-43850069ba7a 유저의 수령 내역 리스트의 경우

2026-01-27 10:14 에 수령한 내역을 보내주신것으로 확인됩니다.
해당 수령 함수 호출 이전 이미 다수의 우편조회가 이루어졌고, 이로인해 조회되었던 우편이 일괄 수령된것입니다.

이후 테스트 과정에서
10시 31~34분 사이 12개의 우편을 발송하셨고, 35분에 1회의 호출과함께 전체수령을 1회 호출하여 10개의 우편을 수령, 2개의 우편은 미조회 상태로 수령되지 않은 채 남아있게되었습니다.

현재는 남아있던 2개의 우편도 조회가 완료된 상태로 추가적인 조회함수 호출없이 수령함수를 호출하면 수령이 이루어지는 상태입니다.

다수의 우편조회가 이루어졌을때 결국 우편을 수령하지는 않은 상태면 해당 우편은 Backend.UPost.GetPostList 를 통해 클라이언트에 전달될수 있는건가요? 조회라는 개념이 조금 생소한거같습니다. 아까전에 말씀하신걸로 이해했을땐 우편 조회를 통해 조회된 우편은 수령을 해야만 다음 우편을 조회할수있는걸로 알고있었는데 그러면 결국 아무리 우편을 다수 조회해도 수령하지 않았으니 다음우편을 조회할수 없어야하는게 아닌가요?

실제로 아까 테스트할 당시에는 Backend.UPost.GetPostList를 다수 요청하긴 했지만 해당 내역은 계속 limit 단위인 10개의 우편만이 표기되고있었습니다만 수령을 했을때는 조회되지 않은 우편을 수령한거같은데 우편 조회를 다수 요청할경우 클라이언트에 전송되는 패킷과 별도로 서버 내부적으로 조회처리가 이루어지는건가요?

아니면 조회가 최신내역기준으로 처리된다하면 만약 10개의 메일을 조회한이후 추가로 11번부터 20번까지 메일을 전송하면 클라이언트에는 11부터 20까지 list가 전송되지만 서버에선 기존 10개 메일 + 11번~20번 메일까지 조회되어 모두받기시 1번부터 20번까지 전부 수령 이런 프로세스로 동작하는건가요?

뒤끝의 구버전 우편의 조회 기능은 전체 우편 중 제일 최근에 발송된 우편 100개를 읽어오는 로직이었습니다.
하지만 이러한 로직으로 인해 100개 이상의 우편이 발송된 경우 조회를 하지못하는 문제상황들이 있었고 이러한 상황을 개선하고자 우편 기능이 새롭게 개선되었습니다.

현재 제공중인 우편 기능(UPost)의 조회 기능은 다음과 같이 동작합니다

조회(GetPostList) 함수의 동작:

  • 조회 함수는 서버에서 수령 가능한 우편을 '수령 가능 상태’로 전환하는 역할을 합니다
  • 첫 호출 시: 가장 오래된 우편부터 limit 개수만큼 수령 가능 상태로 전환하고, 해당 우편 정보를 클라이언트에 반환합니다
  • 수령하지 않은 상태에서 재호출 시: 이미 조회된 가장 최근 우편부터 limit 개수만큼 다시 조회하여 클라이언트에 반환합니다 (서버 내부적으로는 이전에 조회된 우편들이 여전히 '수령 가능 상태’로 유지됨)
  • 수령 후 재호출 시: 마지막으로 조회(수령)된 우편 다음부터 limit 개수만큼 새롭게 조회합니다

예시로 설명드리면

  • 우편 1~15번이 발송된 상태에서 limit 10으로 조회
  • 1차 조회: 1~10번 우편이 '수령 가능 상태’로 전환되고, 클라이언트에 1~10번 반환
  • 수령하지 않고 2차 조회: 서버는 내부적으로 6~15번을 추가로 '수령 가능 상태’로 전환하지만, 클라이언트에는 6~15번 반환 (오버랩)
  • 이 시점에서 전체수령 호출 시: 서버에서 '수령 가능 상태’인 1~15번 우편이 모두 수령됨

정리하면 다음과 같습니다.

  • '조회’는 클라이언트에 우편 정보를 반환하는 것과 서버에서 '수령 가능 상태’로 전환하는 것, 두 가지 의미를 모두 포함합니다
  • GetPostList의 반환값(클라이언트가 받는 리스트)과 서버 내부의 ‘수령 가능 상태’ 우편 목록은 다를 수 있습니다. (수령 가능 상태의 우편이 조회 호출의 limit 값보다 더 많은 경우)
  • 전체수령은 '서버에서 수령 가능 상태로 전환된 모든 우편’을 대상으로 하므로, GetPostList의 마지막 반환값보다 더 많은 우편이 수령될 수 있습니다.

만약 조회된 우편보다 더 많은 우편이 수령되는 것을 막고자 한다면,
limit 값을 최대로 하여 범위를 벗어나는 우편이 발송되지 않도록 하거나, 모든 우편을 개별수령 함수를 통해서 수령하도록 구성해주셔야 합니다.

네 이해됬습니다. 감사합니다. 해당부분 참고해서 코드조정해보겠습니다.