slash-commands

GitHub Copilot 앱의 슬래시 명령어 가이드 (새 탭에서 열림)

GitHub Copilot 앱의 슬래시 명령어는 채팅 입력창에서 `/`로 시작해 세션 관리, 프로젝트 탐색, 작업 모드 전환을 빠르게 수행하도록 돕는다. CLI가 터미널과 디렉터리·작업 경로 관리에 초점을 둔다면, 앱의 명령어는 시각적 인터페이스와 멀티 세션 워크플로에 맞춰 계획 수립, 비판적 검토, 자동 구현 등을 지원한다. 특히 `/plan`으로 작업을 설계하고 `/spar`로 위험을 검토한 뒤 `/autopilot`으로 구현하는 흐름이 핵심이다. ## 슬래시 명령어의 개념과 앱·CLI의 차이 - 채팅 입력창에 `/`를 입력하면 현재 상황에서 사용할 수 있는 명령어 자동완성 메뉴가 표시된다. - CLI 명령어는 터미널 중심으로 설계되어 디렉터리 추가(`/add-dir`), 작업 디렉터리 변경(`/cwd`) 등을 담당한다. - Copilot 앱은 프로젝트 컨텍스트와 파일 접근을 시각적으로 관리하므로 `/add-dir`, `/cwd` 같은 명령어가 필요하지 않다. - 앱에서는 세션 이동, 프로젝트 관리, 에이전트 작업 방식 제어 등 워크플로 중심의 명령어를 제공한다. - `/clear`, `/model`처럼 CLI와 앱에서 공통으로 사용할 수 있는 명령어도 있다. ## `/plan`으로 코딩 전에 작업 설계 `/plan`은 구현에 앞서 작업을 분석하고 단계별 계획을 세우는 명령어다. 실행하면 세션이 **Plan 모드**로 전환되며, 채팅 입력창의 **Mode** 메뉴에서도 같은 모드를 선택할 수 있다. - 새 기능 개발: - 변경이 필요한 파일, 컴포넌트, 의존성을 파악한다. - 예: `/plan`으로 2단계 인증 도입에 필요한 작업과 구현 순서를 정리한다. - 대규모 리팩터링: - 복잡한 코드 변경의 범위와 위험 요소를 확인한다. - 한 번에 전환하지 않고 점진적으로 마이그레이션할 방법을 수립한다. - 버그 조사: - 원인이 불명확한 장애의 가능한 원인을 탐색한다. - 진단 절차와 수정 작업을 단계별로 계획한다. ## `/spar`로 가정과 설계 검증 `/spar`는 Copilot이 반대 의견을 제시하도록 해 설계의 허점, 위험, 트레이드오프를 검토하는 명령어다. - 아키텍처 선택 검증: - Redis 캐시의 무효화 전략, 확장성, 일관성 문제 등을 점검한다. - 구현 방식 비교: - REST와 GraphQL, 동기 처리와 비동기 처리처럼 여러 접근법의 장단점을 비교한다. - 애플리케이션 요구사항에 맞는 선택을 추천하도록 요청할 수 있다. - 마이그레이션 계획 검토: - 데이터베이스나 인프라 이전 과정의 엣지 케이스와 배포 위험을 찾는다. - 무중단 또는 최소 다운타임 조건에서 발생할 문제를 미리 점검한다. - 성능 최적화 비판: - 지연 로딩 등 최적화가 사용자 경험을 해치거나 불필요한 복잡성을 만들 가능성을 확인한다. - 숨은 병목과 부작용, 더 단순한 대안을 함께 검토한다. ## `/autopilot`으로 구현 자동화 `/autopilot`은 계획한 목표를 바탕으로 여러 구현 단계를 Copilot이 직접 수행하도록 하는 명령어다. 실행하면 세션이 **Autopilot 모드**로 전환되며, Mode 메뉴에서도 선택할 수 있다. - 새 기능 구현: - 필요한 파일을 식별하고 코드를 수정한다. - 관련 테스트를 추가하거나 업데이트하도록 요청할 수 있다. - 예: 사용자 보고서를 CSV로 내보내는 기능을 설계부터 구현까지 진행한다. - 대규모 유지보수: - 의존성 업데이트, 리팩터링, 문서 개선처럼 여러 단계가 필요한 작업에 적합하다. - React 버전 업그레이드 시 호환성 문제를 수정하고 테스트 통과 여부까지 확인하도록 할 수 있다. - 사용자는 세부 단계마다 지시하기보다 최종 목표와 제약 조건을 전달하는 방식으로 작업할 수 있다. ## `/rubber-duck`로 문제를 대화형 검토 `/rubber-duck`는 문제를 설명하고 다른 관점에서 검토받는 디버깅 지원 명령어다. - Copilot이 별도의 모델을 사용해 독립적으로 검토하는 방식으로 소개된다. - 혼자 문제를 설명하며 사고를 정리하는 ‘러버 덕 디버깅’ 과정을 Copilot과 수행할 수 있다. - 제공된 글 내용은 이 명령어 설명 중간에서 끝나므로, 구체적인 사용 예와 전체 동작 방식은 확인할 수 없다. 실무에서는 먼저 `/plan`으로 범위와 순서를 정리하고, `/spar`로 설계의 위험을 검증한 다음, 충분히 구체화된 작업을 `/autopilot`에 넘기는 방식이 효과적이다. 자동 구현을 사용하더라도 테스트와 변경 내용을 직접 검토해 결과를 확인하는 것이 좋다.

초보자를 위한 GitHub Copilot CLI: 자주 사용하는 슬래시 명령어 개요 (새 탭에서 열림)

GitHub Copilot CLI의 슬래시 명령은 모델 선택, 컨텍스트 관리, 세션 재개, 변경 사항 확인 등을 터미널에서 직접 수행하게 해주는 핵심 제어 기능이다. `/`를 입력하면 사용 가능한 명령 목록을 확인할 수 있으며, 각 명령을 익히면 작업 흐름과 권한을 더 효율적으로 관리할 수 있다. 특히 모델과 토큰 사용량을 상황에 맞게 조절하면 속도와 결과 품질을 균형 있게 유지할 수 있다. ## 슬래시 명령의 역할 - 슬래시 명령은 Copilot CLI에 내장된 제어 기능이다. - Copilot의 동작을 지시하고, 변경 사항과 컨텍스트를 확인하며, 세션과 프로젝트를 관리한다. - 터미널에서 `/`를 입력하면 현재 지원되는 명령을 스크롤 목록으로 확인할 수 있다. ## 작업에 맞는 모델 선택: `/model` - `/model`을 입력하면 사용 가능한 모델 목록이 표시된다. - 모델마다 적합한 작업이 다르다. - 간단한 리팩터링이나 빠른 작업에는 가벼운 모델이 적합하다. - 기능 설계나 복잡한 추론에는 더 강력한 모델이 유리하다. - 모델 목록은 사용 중인 요금제나 조직 설정에 따라 달라질 수 있다. - 각 모델 옆의 비용 배수는 사용량과 비용 수준을 비교하는 기준이 된다. - 작업의 복잡도와 속도, 비용을 고려해 모델을 선택해야 한다. ## 컨텍스트와 토큰 관리 ### 현재 사용량 확인: `/context` - `/context`는 현재 세션의 컨텍스트 사용량을 보여준다. - 남은 토큰 수, 시스템이 사용하는 공간, 추가로 활용 가능한 버퍼를 확인할 수 있다. - 컨텍스트 창이 가득 차면 Copilot이 이전 대화와 정보를 충분히 참고하기 어려워진다. ### 대화 압축: `/compact` - `/compact`는 현재 대화를 요약해 컨텍스트 공간을 확보한다. - 기존 세션을 유지하면서 새로운 작업으로 넘어갈 때 유용하다. - 컨텍스트 한도에 가까워지면 Copilot CLI가 자동으로 압축할 수 있지만, 사용자가 직접 실행할 수도 있다. ### 세션 초기화: `/clear` - `/clear`는 현재 세션을 완전히 지운다. - 이전 대화의 영향을 받지 않고 새로운 작업을 시작할 때 사용한다. ## 이전 세션 재개: `/resume` - `/resume`은 과거에 진행한 세션 목록을 표시한다. - 로컬 세션과 원격 세션을 모두 확인할 수 있다. - 세션을 선택하면 이전 작업 기록을 검토한 뒤 중단한 지점부터 작업을 이어갈 수 있다. ## 변경 사항 확인: `/diff` - `/diff`는 현재 세션에서 발생한 최근 변경 사항을 보여준다. - Copilot이 수정한 파일을 검토하고, 의도하지 않은 변경이 없는지 확인하는 데 사용한다. - 변경 내용을 검증한 뒤 커밋이나 다음 작업으로 넘어가는 것이 좋다. ## 작업 디렉터리 변경: `/cwd` - `/cwd`를 사용하면 Copilot을 종료하지 않고 다른 저장소나 디렉터리로 이동할 수 있다. - 여러 프로젝트를 오가며 작업할 때 편리하다. - Copilot의 작업 범위를 현재 선택한 프로젝트에 맞게 조정할 수 있다. ## 도구 권한 초기화: `/reset-allowed-tools` - `/reset-allowed-tools`는 이전에 허용한 파일 수정 등의 도구 권한을 초기화한다. - 신뢰 수준이 다른 저장소로 이동했을 때 기존 권한을 재설정하는 데 유용하다. - 민감한 프로젝트를 다룰 때 권한을 다시 확인하는 안전 장치로 활용할 수 있다. ## 실용적인 활용 방법 - 작업을 시작하기 전에 `/`를 입력해 사용 가능한 명령을 확인한다. - 복잡한 기능 설계에는 `/model`로 추론 능력이 높은 모델을 선택한다. - 컨텍스트가 부족해지면 `/context`로 상태를 확인하고 `/compact`를 실행한다. - Copilot이 코드를 수정한 뒤 `/diff`로 변경 내용을 검토한다. - 다른 프로젝트로 이동할 때는 `/cwd`, 권한을 정리해야 할 때는 `/reset-allowed-tools`를 사용한다. - 슬래시 명령을 익히면 Copilot CLI를 단순한 코드 생성 도구가 아니라 세션·컨텍스트·권한을 통제하는 작업 환경으로 활용할 수 있다.

서버에서 앱이 데이터에 접근하는 방식에 대한 업데이트된 요구사항 (새 탭에서 열림)

Discord는 서버 멤버 정보, 사용자 현재 상태, 메시지 내용에 접근하는 앱에 대해 더 엄격한 심사 기준을 도입한다. 이제 총 사용자 수가 10,000명 이상인 앱은 심사를 받아야 하며, 접근 권한을 유지하려면 매년 재심사를 신청해야 한다. 기존 데이터 종류 자체가 확대되는 것은 아니며, 목적에 맞지 않거나 심사를 통과하지 못한 앱은 관련 기능이 제한될 수 있다. ## 변경되는 접근 권한 기준 - 대상 데이터는 다음과 같다. - 서버 멤버 목록 - 사용자의 온라인·오프라인 등 현재 상태 - 메시지 내용 - 기존에는 **100개 이상의 서버에 추가된 앱**이 심사 대상이었다. - 앞으로는 서버 수가 아니라 **앱이 도달하는 총 사용자 수**를 기준으로 한다. - 총 사용자 수가 **10,000명 이상**인 앱은 해당 데이터에 계속 접근하려면 심사를 거쳐야 한다. - 10,000명 미만의 앱은 이번 기준 변경으로 즉시 영향을 받지 않는다. ## 매년 재심사 도입 - 앱 개발자는 데이터 접근 권한을 계속 유지하려면 **매년 재신청**해야 한다. - 앱의 기능과 목적이 시간이 지나며 변할 수 있기 때문에, 현재 데이터 접근이 실제 사용 목적에 필요한지 확인한다. - 심사에서는 앱이 해당 데이터를 실제로 사용하는지, 명시한 기능에 데이터가 필요한지 등을 중점적으로 검토한다. - 개발자는 언제든 재신청할 수 있다. ## 변경의 배경과 데이터 보호 - 기존 기준은 2020년 당시 Discord와 앱 생태계 규모를 바탕으로 설계됐다. - 서버 수만 기준으로 삼으면, 하나의 대형 서버에만 추가된 앱도 많은 사용자 데이터에 접근할 수 있었다. - 새로운 사용자 수 기준은 앱이 실제로 도달할 수 있는 이용자 규모를 반영한다. - 매년 심사를 통해 더 이상 필요하지 않거나 정책에 맞지 않는 데이터 접근 권한을 줄일 수 있다. - 이번 변경은 앱이 접근할 수 있는 데이터 종류를 늘리는 것이 아니라, 접근 신청과 유지 조건을 강화하는 조치다. ## 사용자와 앱 기능에 미치는 영향 - 대부분의 사용자는 즉각적인 변화를 느끼지 못한다. - 개발자가 심사를 신청하지 않거나 권한을 유지하지 못하면 메시지 읽기 등 특정 데이터에 의존하는 기능이 중단될 수 있다. - 앱 자체가 삭제되는 것은 아니며, 해당 데이터가 필요 없는 기능은 계속 작동한다. - 예를 들어 메시지 내용을 읽어 특정 단어에 반응하던 봇은 슬래시 명령어(`/command`) 방식으로 재설계될 수 있다. - Discord는 기존 앱이 변경에 대응할 수 있도록 개발자에게 알리고, 필요한 조치나 재심사를 준비할 **90일의 유예 기간**을 제공한다. ## 앱 사용자의 확인 방법 - 서버 구성원은 서버 멤버 목록에서 앱 프로필을 확인할 수 있다. - 앱의 역할과 기능을 살펴본 뒤 서버에 추가할지 판단하는 데 활용할 수 있다. - 앱이 어떤 데이터를 필요로 하는지와 실제 기능이 그 접근을 정당화하는지를 확인하는 것이 중요하다. 실용적으로는 앱 개발자는 데이터 접근 필요성을 문서화하고 매년 재심사 일정을 관리해야 하며, 가능하다면 메시지 내용 접근 대신 슬래시 명령어·명시적 사용자 동작처럼 권한이 적은 구조로 전환하는 것이 바람직하다.

Copilot CLI에서 /fleet으로 여러 에이전트 동시에 실행하기 (새 탭에서 열림)

Copilot CLI의 `/fleet`는 하나의 작업을 여러 독립적인 하위 작업으로 나누고, 여러 에이전트를 병렬 실행하는 기능이다. 오케스트레이터가 작업의 의존성을 분석해 실행 순서를 정하고, 결과를 검증·통합하므로 여러 파일이나 모듈을 동시에 처리할 수 있다. 다만 에이전트들이 동일한 파일을 수정하면 잠금이나 자동 병합 없이 마지막 변경이 덮어쓰므로, 작업 범위와 파일 경계를 명확히 지정해야 한다. ## `/fleet`의 작동 방식 - 사용자가 `/fleet <작업 목표>` 형식으로 목표를 전달한다. - 오케스트레이터가 목표를 독립적인 작업 단위로 분해한다. - 작업 간 의존성을 분석해 병렬 실행 가능한 항목과 순차 실행해야 하는 항목을 구분한다. - 독립적인 작업은 백그라운드 하위 에이전트에 동시에 배정한다. - 작업 완료를 확인한 뒤 다음 의존 작업을 실행한다. - 각 결과를 검증하고 최종 산출물로 통합한다. - 하위 에이전트는 각자의 컨텍스트 창을 사용하지만 동일한 파일 시스템을 공유하며, 서로 직접 대화하지 않고 오케스트레이터를 통해 조정된다. ## 시작 방법 - 대화형 CLI에서는 다음과 같이 실행한다. ```text /fleet Refactor the auth module, update tests, and fix the related docs in the folder docs/auth/ ``` - 터미널에서 비대화형으로 실행할 수도 있다. ```bash copilot -p "/fleet <YOUR TASK>" --no-ask-user ``` - `--no-ask-user`는 사용자가 추가 질문에 응답할 수 없는 비대화형 환경에서 필요하다. ## 병렬화에 적합한 프롬프트 작성 - 작업마다 구체적인 산출물을 지정해야 한다. - 파일 - 테스트 스위트 - 문서 페이지 - 특정 모듈 - “문서를 작성하라”처럼 모호한 요청은 독립 작업을 식별하기 어려워 순차 실행될 가능성이 높다. - 예를 들어 인증, 엔드포인트, 오류 문서를 각각 별도 파일로 지정하면 세 작업은 병렬 처리할 수 있다. - 여러 문서를 연결하는 `docs/index.md`처럼 다른 결과물에 의존하는 작업은 후속 단계로 명시해야 한다. ## 파일 범위와 제약 조건 지정 프롬프트에는 각 에이전트가 담당할 범위를 명확히 적어야 한다. - 담당 디렉터리나 파일을 지정한다. - 수정해서는 안 되는 영역을 명시한다. - 테스트 변경 금지 - 의존성 업그레이드 금지 - 지정 디렉터리 외 수정 금지 - 완료 조건을 제시한다. - 린트 통과 - 타입 검사 통과 - 특정 테스트 통과 - API, UI, 설정처럼 서로 다른 영역을 별도 트랙으로 나누면 병렬 실행 효과가 커진다. ## 작업 의존성 선언 - 한 작업이 다른 작업의 결과를 필요로 하면 프롬프트에 `depends on` 관계를 명시한다. - 예를 들어 다음과 같이 데이터베이스 마이그레이션, ORM 모델, API 핸들러, 통합 테스트의 순서를 지정할 수 있다. - ORM 모델이 완성된 뒤 API 핸들러와 통합 테스트를 동시에 실행하도록 구성할 수 있다. - 의존성을 명시하지 않으면 에이전트가 충돌하거나 불완전한 결과를 바탕으로 작업할 수 있다. ## 사용자 지정 에이전트 활용 - `.github/agents/`에 전문 에이전트 설정 파일을 만들 수 있다. - 에이전트마다 다음을 지정할 수 있다. - 모델 - 사용 가능한 도구 - 역할과 작업 지침 - 문서 작성에는 `technical-writer` 같은 전문 에이전트를 사용하고, 코드 변경에는 기본 에이전트를 사용하는 식으로 역할을 나눌 수 있다. - 모델을 별도로 지정하지 않으면 현재 기본 모델이 사용된다. ## 병렬 실행 여부 확인 - 오케스트레이터가 작업을 여러 트랙으로 분해했는지 계획을 먼저 확인한다. - `/tasks` 명령으로 백그라운드 작업 목록과 진행 상태를 볼 수 있다. - 여러 트랙에서 동시에 진행 상황이 보고되는지 확인한다. - 병렬화되지 않는다면 다음처럼 먼저 분해하도록 요청할 수 있다. ```text Decompose this into independent tracks first, then execute tracks in parallel. Report each track separately with status and blockers. ``` ## 주요 주의점 - 하위 에이전트는 파일 잠금 기능 없이 동일한 파일 시스템을 공유한다. - 두 에이전트가 같은 파일을 수정하면 오류나 자동 병합 없이 마지막 완료 결과가 앞선 변경을 덮어쓸 수 있다. - 따라서 각 에이전트에 서로 다른 파일을 배정해야 한다. - 하나의 파일에 여러 에이전트가 기여해야 한다면: - 각자 임시 파일에 작성한 뒤 오케스트레이터가 병합하게 하거나 - 에이전트 실행 순서를 명시해야 한다. - 하위 에이전트는 오케스트레이터와의 이전 대화 기록을 볼 수 없으므로, 전달되는 프롬프트만으로 작업할 수 있도록 지침과 제약 조건을 self-contained하게 작성해야 한다. 실제로 `/fleet`를 사용할 때는 먼저 작업을 파일·모듈 단위로 분리하고, 의존성과 검증 조건을 프롬프트에 명시하는 것이 좋다. 특히 공유 파일을 여러 에이전트가 수정하지 않도록 범위를 엄격히 나누면 병렬 처리의 속도 이점과 결과 안정성을 함께 얻을 수 있다.

멤버, 중재자, 관리 (새 탭에서 열림)

디스코드 서버의 권한 설정은 무질서한 공간과 안전하고 활발한 커뮤니티를 가르는 핵심 요소다. 글은 권한을 일반 멤버, 운영진(모더레이터), 관리자 세 범주로 나누고, 각 역할에 필요한 권한만 부여하라고 권장한다. 특히 관리자 권한은 서버 전체에 큰 영향을 주므로 신뢰할 수 있는 사람에게만 제한적으로 제공해야 한다. ## 일반 멤버에게 필요한 기본 권한 일반 멤버는 서버에서 대화하고 음성 채널과 앱을 이용하는 데 필요한 권한을 갖는다. - **채널 보기(View Channels)**: 채널을 보고 접근할 수 있게 한다. - **메시지 보내기(Send Messages)**: 텍스트 채널에 글을 작성할 수 있다. - **공개 스레드 만들기(Create Public Threads)**: 주제에서 벗어난 대화를 별도 스레드로 분리할 수 있다. - **스레드에서 메시지 보내기(Send Messages in Threads)**: 스레드를 만든 뒤 그 안에서 대화할 수 있도록 함께 활성화해야 한다. - **초대 만들기(Create Invite)**: 다른 사용자를 서버에 초대할 수 있다. - **닉네임 변경(Change Nickname)**: 해당 서버에서 사용할 개인 닉네임을 설정할 수 있다. ## 음성 채널 및 활동 권한 음성 채널을 운영하는 서버라면 다음 권한을 일반 멤버에게 제공할 수 있다. - **연결(Connect)**: 음성 채널에 입장할 수 있다. - **말하기(Speak)**: 음성 채널에서 마이크를 사용할 수 있다. - **영상(Video)**: 웹캠, 화면 공유, 게임 스트리밍을 사용할 수 있다. - **외부 사운드 사용(Use External Sounds)**: 다른 서버의 사운드보드 음향을 사용할 수 있다. - **음성 감지 사용(Use Voice Activity)**: 음성이 감지되면 자동으로 마이크가 활성화된다. - 비활성화하면 사용자는 푸시 투 토크 방식으로만 말할 수 있다. - **음성 채널 상태 설정(Set Voice Channel Status)**: 현재 음성 채널의 상황이나 주제를 상태로 표시할 수 있다. ## 앱과 디스코드 활동 권한 - **애플리케이션 명령어 사용(Use Application Commands)**: 슬래시 명령어를 비롯한 대화형 앱을 사용할 수 있다. - **활동 사용(Use Activities)**: 체커와 같은 디스코드 내 게임 및 활동을 이용할 수 있다. - **외부 앱 사용(Use External Apps)**: 계정에 저장된 외부 앱으로 메시지를 작성할 수 있다. - 이 권한을 꺼도 앱은 사용할 수 있지만, 앱이 작성한 메시지는 해당 사용자에게만 표시된다. ## 모더레이터에게 필요한 운영 권한 서버 규모가 커지면 일부 멤버에게 커뮤니티 관리 권한을 부여할 수 있다. 대부분의 조치는 되돌릴 수 있지만, 차단이나 대규모 알림처럼 영향이 큰 권한은 신중히 부여해야 한다. - **메시지 관리(Manage Messages)**: 메시지를 고정·고정 해제하거나 삭제할 수 있다. - **스레드 관리(Manage Threads)**: 스레드 이름 변경, 보관, 삭제가 가능하다. - **표현물 만들기(Create Expressions)**: 사용자 지정 이모지, 스티커, 사운드보드 음향을 업로드할 수 있다. - **대규모 멘션 사용**: `@everyone`, `@here`, 전체 역할 멘션을 사용할 수 있다. - **멤버 추방·가입 승인·거절**: - **추방(Kick)**: 사용자를 내보내지만 초대를 받으면 다시 가입할 수 있다. - **승인·거절**: 가입 신청이 필요한 서버에서 사용된다. - **멤버 차단(Ban Members)**: 사용자를 서버에서 제거하고 재가입을 막는다. 이후 서버 설정에서 차단을 해제할 수 있다. - **멤버 타임아웃(Timeout Members)**: 지정된 시간 동안 메시지 작성, 음성 채널 입장 등 커뮤니티 활동을 제한한다. - **닉네임 관리(Manage Nicknames)**: 다른 사용자의 닉네임을 변경할 수 있으며, 사용자가 직접 설정한 닉네임보다 우선 적용된다. - **감사 로그 보기(View Audit Log)**: 메시지 삭제, 스레드 생성, 이모지 이름 변경 등 서버에서 발생한 작업 이력을 확인할 수 있다. ## 모더레이터의 음성 채널 관리 - **우선 발언자(Priority Speaker)**: 푸시 투 토크를 사용하는 동안 다른 사람의 음량을 낮춰 발언을 더 잘 들리게 한다. - **멤버 음소거(Mute Members)**: 특정 사용자의 마이크를 끈다. 해당 사용자는 다른 사람의 음성은 들을 수 있다. - **멤버 청각 차단(Deafen Members)**: 마이크를 끄고 다른 사람의 음성도 듣지 못하게 한다. - **멤버 이동(Move Members)**: 사용자를 다른 음성 채널로 이동시킨다. - 이동 대상자는 이동하려는 채널에 접속할 권한도 가지고 있어야 한다. ## 이벤트 관리 권한 - **이벤트 만들기(Create Events)**: 커뮤니티 이벤트를 예약할 수 있다. - **이벤트 관리(Manage Events)**: 생성된 이벤트를 수정하거나 삭제할 수 있다. - 이벤트 생성 권한만으로는 생성 후 내용을 수정할 수 없다. ## 관리자 권한은 최소한으로 부여 관리자 권한은 메시지, 이모지, 채널 등 서버의 중요한 요소를 수정하거나 삭제할 수 있는 강력한 권한이다. - 커뮤니티에 실제로 필요한 권한만 활성화해야 한다. - 누구에게나 일괄적으로 관리자 권한을 부여하지 말고, 신뢰할 수 있는 사람을 선별해야 한다. - **서버 관리(Manage Server)** 권한은 서버의 주요 설정을 변경할 수 있으며, 예시로 서버 이름 변경 등이 포함된다. - 제공된 글 내용은 서버 관리 권한의 세부 항목을 설명하는 중간에서 끝나므로, 관리자 권한 전체 목록은 확인할 수 없다. 권장 방식은 일반 멤버에게는 대화와 참여에 필요한 권한만 주고, 모더레이터에게는 삭제·제한·음성 관리 권한을 추가하며, 서버 설정을 바꾸는 관리자 권한은 최소 인원에게만 부여하는 것이다.

앱과 활동으로 게임 플레이 (새 탭에서 열림)

Discord의 앱과 Activities는 서버와 DM에서 게임, 음악 감상, 협업, 관리 기능 등을 제공해 대화를 확장한다. 사용자는 App Launcher나 App Directory에서 앱을 찾고, 서버에 추가하거나 자신의 계정에 저장해 사용할 수 있다. 다만 서버에서 앱을 실행하려면 서버 정책과 `External Apps`, `Activities` 같은 권한이 허용되어야 한다. ## App Launcher와 App Directory에서 앱 찾기 - **App Launcher**는 텍스트 채팅 입력창이나 음성 통화 하단에 있는 앱 아이콘으로 열 수 있다. - 추천 앱을 둘러보거나 검색창으로 원하는 앱과 Activities를 찾을 수 있다. - Activities에는 친구들과 함께하는 캐주얼·경쟁 게임, 협업 도구, 음악 감상 기능 등이 포함된다. - 더 많은 앱을 찾으려면 서버 이름을 클릭한 뒤 **App Directory**를 선택하면 된다. - App Directory에는 일반적인 대화용 앱뿐 아니라 서버 관리와 커뮤니티 운영에 특화된 앱도 등록되어 있다. ## Discord 서버에 앱 추가하기 - App Directory 또는 앱 프로필에서 **Add App** 버튼을 누르면 서버에 앱을 추가할 수 있다. - 서버용 앱은 다음과 같은 기능을 제공한다. - AutoMod를 보완하는 추가 moderation 기능 - 메시지 반응으로 역할을 부여하는 **Reaction Roles** - 농장·낚시 등 텍스트 기반 게임 - 명령어를 통한 이미지 검색 및 공유 - 앱을 추가하기 전 필요한 권한을 확인해야 하며, Discord의 커뮤니티 서버 기능이 비슷한 관리 기능을 기본 제공할 수도 있다. ## 계정에 앱을 저장해 모든 채팅에서 사용하기 - 과거에는 대부분의 앱이 서버에 봇으로 추가되어야 했지만, 현재는 앱을 개인 계정에 추가할 수 있다. - 앱 프로필의 **Add to My Apps**를 선택하고 계정 권한을 승인하면 된다. - 저장한 앱은 App Launcher에서 실행할 수 있다. - `/`를 입력해 Slash Command를 열면 저장한 앱과 명령어를 한곳에서 확인하고 사용할 수 있다. - 이 방식은 특정 서버에 앱을 설치하지 않고도 개인적으로 앱 기능을 활용할 수 있게 한다. ## 서버에서 앱이나 Activity를 실행할 수 없는 경우 - 서버 운영진이 승인하지 않은 외부 앱의 사용을 제한할 수 있다. - 앱을 실행할 수 없거나 Activity를 시작할 수 없다면 자신의 역할과 권한을 확인해야 한다. - 특히 다음 권한이 활성화되어 있는지 살펴봐야 한다. - **External Apps** - **Activities** - 권한이 꺼져 있다면 서버 관리자에게 허용을 요청해야 하며, 서버 자체 정책상 사용이 제한될 수도 있다. ## 활용을 위한 권장 사항 앱은 서버의 목적에 맞는 moderation, 역할 관리, 게임, 커뮤니티 기능을 보완하는 용도로 선택하는 것이 좋다. 설치 전 요청 권한과 서버 정책을 확인하고, 개인적으로 사용할 앱은 **Add to My Apps**, 서버 전체가 사용할 앱은 **Add App**으로 구분하면 된다.