Discord 통계 대시보드의 sites 필드 분할로 1024자 제한 해결

stats-dashboard 스크립트가 통계 정보를 Discord로 전송할 때, 특정 fields가 Discord의 1024자 제한에 걸리는 문제가 있었다. 이번엔 sites 필드를 분할해서 이 이슈를 해결했다.

Discord의 embed 제약과 마주치다

외부 플랫폼과 연동되는 서비스를 운영하다 보면 예상 못 한 제약에 자주 부딪힌다. Discord도 마찬가지인데, embed 필드(field)는 value 최대 1024자라는 제약이 있다. API 문서에 명시되어 있지만, 실제로 데이터 규모가 커지다 보면 이 한계를 넘게 된다.

우리 stats-dashboard는 수집한 통계 정보를 정기적으로 Discord 채널에 전송해서 팀이 한눈에 보게 하는 스크립트다. 초반엔 데이터가 적어서 문제 없었지만, sites 필드에 누적되는 정보가 많아지면서 언젠가부터 메시지 일부가 잘려나갔다. 처음엔 Discord 앱 버그인 줄 알았는데, 디버깅하다 보니 전송 시점에 이미 truncate되고 있었다.

필드 분할로 문제 해결

간단한 해결책은 하나의 큰 필드를 여러 개의 작은 필드로 나누는 것이다.

우리는 필드 분할 방식을 택했다. sites를 페이징(또는 순차 분할)해서 여러 embed 필드로 나누면, 각 필드가 1024자 이내로 유지되면서도 데이터 손실이 없다.

# 패턴: 긴 데이터를 청크 단위로 분할
def split_field(data, chunk_size=1024):
    """긴 필드를 여러 청크로 나눔"""
    chunks = []
    for i in range(0, len(data), chunk_size):
        chunks.append(data[i:i+chunk_size])
    return chunks

# embed에 추가할 때 각 청크를 별도 필드로
for idx, chunk in enumerate(split_field(sites_data)):
    embed.add_field(
        name=f"Sites ({idx+1})",
        value=chunk,
        inline=False
    )

팀 협업과 모니터링 관점의 고민

이런 수정이 단순해 보일 수 있지만, 실제로는 몇 가지 의사결정이 있었다.

• 필드명 관례: "Sites (1)", "Sites (2)" 같은 형식을 쓸지, 아니면 다른 방식을 쓸지. 팀원들이 한눈에 이어지는 구간이라는 걸 알아야 한다.
• 순서 보장: split이 일관되게 같은 순서로 데이터를 나눠야 한다. 순서가 뒤바뀌면 대시보드를 보는 사람 입장에서 혼란스럽다.
• 로깅과 모니터링: 향후 또 다른 필드가 길어질 가능성이 있으니, 이런 truncation 사건을 조기에 감지하는 방법도 함께 생각해야 한다.

비슷한 상황은 생각보다 자주 온다. 외부 API의 제약(Slack의 블록 제약, AWS CloudWatch의 로그 이벤트 크기, 등등)에 마주칠 때마다 같은 패턴으로 대응한다.

이번 작업에서 배운 점

외부 플랫폼과 연동할 땐 그 플랫폼의 제약을 미리 내재화해야 한다는 생각이 더 확실해졌다. "나중에 문제 되면 고치지" 하다가, 프로덕션에서 데이터가 잘려 나가는 상황은 피해야 한다.

또한 이런 방어적 수정을 할 땐, 단순히 기술적 fix 뿐 아니라 팀 커뮤니케이션도 중요하다. 대시보드 format이 바뀌었으니, 정기 회의에서 한두 줄이라도 언급해서 사람들이 자연스럽게 인지하게 하는 게 좋다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 노이즈캔슬링헤드폰 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.