개발 slecs

Discord 콘텐츠 채널 등록 구조 마련

목차

Discord 채널을 JSON 파일로 관리하는 체계를 처음 도입했다. kpopdex 콘텐츠 채널을 등록하면서, 향후 여러 채널을 구조적으로 운영하기 위한 기초를 다졌다는 의미다. 단순한 채널 추가로 보이지만, 이건 팀의 Discord 통합 방식을 정리하는 첫 번째 공식 선언이었다.

왜 이런 구조가 필요했나

처음엔 채널 ID를 코드에 하드코딩하거나 환경 변수로 관리하는 방식을 생각할 수도 있다. 하지만 서비스가 여러 Discord 채널과 상호작용하면서, 각 채널의 용도(content, admin, log 등)가 다르면 그걸 정적으로 관리하기 어려워진다. 특히 팀 규모가 커지면서 "이 채널이 어떤 용도인지", "이 채널에는 누가 접근 가능한지", "이 채널로 어떤 타입의 메시지가 전송되는지"를 명확하게 하려면 중앙 집중식 설정 관리가 필수다.

처음 설계 고민 포인트는 이랬다:
- 환경 변수로 관리하면? → 채널이 많아지면 env 파일이 복잡해지고, 채널 목적을 표현하기 어려움
- 코드에 하드코딩하면? → 새 채널 추가할 때마다 배포가 필요. 비개발자는 수정 불가
- 데이터베이스에 저장하면? → 과할 수 있음. 아직은 채널 수가 많지 않고, 앱 시작 시에만 필요

결국 JSON으로 가기로 했다. 이 선택의 이유:

항목 환경 변수 하드코딩 JSON 파일 DB
변경 용이성 낮음 낮음 높음 높음
채널 용도 표현 나쁨 중간 좋음 좋음
배포 필요 아니오 아니오
복잡도 낮음 낮음 낮음 높음
팀 협업 낮음 중간 높음 높음

discord_channels.json 구조의 의도

이번 작업으로 확정한 파일 구조는 이래야 한다고 생각했다:

{
  "content": {
    "channel_id": "1517173697155432488",
    "description": "kpopdex 콘텐츠 채널"
  },
  "admin": {
    "channel_id": "...",
    "description": "..."
  }
}

카테고리로 먼저 분류하고, 그 안에 채널 정보를 넣는 방식이다. 이렇게 하면:
- 같은 카테고리 채널끼리 논리적으로 묶여서 관리 가능
- 애플리케이션에서 channels['content']['channel_id'] 같은 명확한 참조 가능
- "이번엔 content 카테고리의 모든 채널에 권한을 주자" 같은 일괄 처리도 나중에 쉬움
- 팀원들이 구조를 한 번 이해하면, 누구나 같은 패턴으로 추가 가능

이제부터의 영향

kpopdex 채널이 content로 등록되면서, 앞으로의 작업이 방향을 잡는다:

  1. 선례 효과: 다음 채널 추가 시 "우리는 이 방식으로 관리한다"는 선례가 생김. 팀원 누구나 같은 패턴을 따를 수 있고, 일관된 구조가 유지됨
  2. 코드 연계: 이 파일을 읽어서 사용하는 로직이 필요함. 아직 작성했다는 증거는 없으니, 이미 있거나 곧 별도 PR로 할 작업일 것
  3. 카테고리 확장: admin, log 같은 새로운 카테고리가 필요하면 JSON에 추가하고, 코드에서 그 카테고리를 처리하는 구조로 진행

채널이 여러 개 쌓이다 보면 언젠가는 "채널 등록 검증 로직"도 필요할 것 같다. 예를 들어:
- 채널 ID가 정말 존재하는지 Discord API로 확인
- 카테고리가 미리 정의된 것 중 하나인지 체크
- 채널 권한이 봇에게 제대로 있는지 검증

이런 검증은 채널이 5-10개 정도 되면 자연스럽게 필요해진다. 그때 추가해도 괜찮다.

단순해 보이는 작업에서 배운 것

실제로 "채널 하나 추가"는 간단하지만, 그 뒤에 있는 구조 결정은 중요하다. 특히:

  • 일관성: 처음 정한 패턴대로 모두가 따르면, 나중에 누가 유지보수하든 이해하기 쉽다. 팀에 새 사람이 와도 "아, 여기서는 이렇게 하는 곳이네" 하고 빠르게 따라올 수 있다.
  • 문서화: JSON 파일 자체가 "어떤 채널이 있고, 뭐에 쓰이는지"를 명확하게 보여준다. 별도 문서가 없어도 파일을 보면 구조를 파악할 수 있다.
  • 확장성: 나중에 DB로 전환하거나 권한 검증을 추가해야 할 때도, 지금 이 구조가 발판이 된다.

비슷한 설정 관리를 다른 팀에서도 봤는데, yaml이나 toml로 관리하는 곳도 있고 심지어 엑셀에서 추출하는 곳도 있었다. 각각 장단점이 있지만, JSON은 가볍고 대부분 언어에서 바로 파싱 가능하다는 게 강점이다. 다만 파일이 계속 커지거나 실시간으로 채널을 추가/삭제해야 하면 DB로 전환을 고려해야 한다.

지금 이 선택이 앞으로 1년, 2년을 버틸 수 있으면 충분하다. 그때쯤이면 채널 수나 요구사항이 더 명확해질 테니까. 지금은 "정확하고 예측 가능한" 구조가 "완벽하게 스케일하는" 구조보다 낫다.


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

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

댓글 0

첫 댓글 달아줘.