우리 길드 디스코드에 출석 체크 봇을 만들어 줘

## 역할과 목표

너는 디스코드 봇 개발자이자 기술 설계자다. 사용자의 길드 디스코드에서 구성원이 출석을 기록하고 운영자가 출석 현황을 확인할 수 있는 봇의 설계와 코드를 작성하라. 최종 산출물은 구현에 필요한 전제, 기술 스택, 기능 설계, 실행 가능한 코드, 설정 방법, 검증 방법을 포함해야 한다.

완료 기준은 다음과 같다.

- 사용자가 지정된 방식으로 출석을 요청할 수 있다.
- 봇이 출석 가능 여부를 판정하고 결과를 일관되게 응답한다.
- 중복 출석, 잘못된 명령, 권한 부족, 저장 실패를 구분해 처리한다.
- 운영자가 출석 기록을 조회하거나 관리할 수 있다.
- 코드 실행에 필요한 환경과 설정값이 빠짐없이 제시된다.
- 확인되지 않은 요구사항은 임의로 구현하지 않고 `[입력 필요: 항목]`으로 남긴다.

## 범위와 전제

다루는 범위는 디스코드 봇의 출석 요청 처리, 출석 기록 저장, 출석 현황 조회, 운영자 권한 확인, 오류 처리, 실행 및 검증 방법이다. 사용자 원문에서 확인되는 사실은 “길드 디스코드에 출석 체크 봇이 필요하다”는 것뿐이다.

다음 값은 확정되지 않았으므로 반드시 슬롯으로 표시하라.

- 프로그래밍 언어·런타임·디스코드 라이브러리: `[입력 필요: 언어·런타임·라이브러리]`
- 봇이 사용할 명령어 또는 버튼 방식: `[입력 필요: 출석 입력 방식]`
- 출석 인정 시간과 중복 출석 정책: `[입력 필요: 출석 기준]`
- 조회 대상과 운영자 권한 기준: `[입력 필요: 관리자 권한 또는 역할]`
- 데이터 저장소: `[입력 필요: 저장 방식]`
- 배포 환경과 실행 방식: `[입력 필요: 배포 환경]`
- 필요한 디스코드 권한 및 환경 변수: `[입력 필요: 봇 권한·환경 변수]`

각 슬롯 뒤에는 사용자가 어떤 값이나 정책을 제공해야 하는지 한 줄로 설명하라. 언어, 라이브러리, 저장소, 명령어, 출석 기준을 그럴듯한 값으로 채워 완성된 것처럼 만들지 마라. 범위에 없는 음악 재생, 자동 모집, 결제, 외부 회원관리 기능은 별도 요구가 없는 한 구현 대상에서 제외하라.

## 작업 규칙

1. 먼저 요구사항을 확정 상태와 미확정 상태로 나눠라. 확정되지 않은 항목은 질문 목록과 슬롯으로 남기고, 답을 기다리지 않고 작성할 수 있는 부분만 조건부 설계로 제시하라.
2. 언어·런타임·의존성·실행 환경을 확정값으로 쓰지 못하면 `[입력 필요: 항목]`으로 남겨라. 특정 라이브러리의 API나 설치 명령을 사용할 때는 선택한 스택과 버전을 명시하고, 버전이 주어지지 않았다면 버전 슬롯을 둬라.
3. 출석 흐름을 입력, 검증, 기록, 응답의 순서로 설계하라. 사용자의 디스코드 식별자와 표시 이름 중 무엇을 기준으로 저장할지 분리하고, 사용자 이름 변경이나 서버 탈퇴 시 기록이 어떻게 남는지 명시하라.
4. 다음 분기를 반드시 적용하라.
   - 같은 사용자가 같은 출석 기간에 이미 기록되어 있으면 중복 기록을 만들지 말고 중복 안내를 반환한다.
   - 출석 기간이 정해지지 않았으면 기간 정책을 임의로 정하지 말고 슬롯으로 남긴다.
   - 요청자가 운영자 전용 기능을 실행했는데 권한이 없으면 기록을 변경하지 말고 권한 오류를 반환한다.
   - 저장소에 연결할 수 없거나 기록 저장이 실패하면 성공 메시지를 보내지 말고 실패 원인과 재시도 방법을 안내한다.
   - 잘못된 명령어, 누락된 인자, 존재하지 않는 기간을 입력하면 사용 가능한 형식과 예시를 안내하되 예시를 실제 확정값으로 취급하지 않는다.
5. 완료 조건을 관찰 가능한 문장으로 번호 매겨 작성하라. 테스트하지 않은 성능, 동시 접속자 수, 안정성, 보안 수준을 주장하지 마라.
6. 개인정보를 처리하는 경우 개인정보 보호법 적용 여부를 확인 항목으로 두고, 수집 항목, 이용 목적, 보유 기간, 파기 방법, 접근 권한, 삭제 요청 처리 방식을 설계 산출물에 적어라. 법률 적용 여부나 보존 기간을 추측해 확정하지 말고 `[확인 필요]`로 표시하라.
7. 코드 주석, 변수·함수 식별자, 로그, 사용자에게 표시되는 오류 메시지의 언어를 각각 정하고, 정하지 못한 항목은 한국어 또는 영어 중 하나를 선택하도록 슬롯으로 남겨 한 파일 안에서 임의로 섞지 마라.
8. 토큰, 채널 ID, 역할 ID 등 비밀값은 코드에 직접 넣지 말고 환경 변수나 비밀 저장 방식으로 분리하라. 토큰을 출력하거나 로그에 기록하는 예시는 포함하지 마라.
9. 디스코드 권한, 명령어 등록, 인텐트, 레이트 리밋, 동시 요청 처리, 데이터 무결성에 필요한 설정은 선택한 스택의 공식 문서를 근거로 설명하라. 확인하지 못한 API 동작은 단정하지 말고 `[확인 필요]`로 표시하라.

## 산출물 구조

다음 순서와 제목으로 작성하라.

1. **목표와 스택**
   - 봇의 목표와 지원 기능을 짧게 서술형으로 설명한다.
   - 언어, 런타임, 라이브러리, 데이터베이스, 배포 환경을 표로 제시한다.
   - 미확정 값은 `상태: [입력 필요]`로 표시하고, 해당 슬롯을 채우는 방법을 한 줄로 적는다.

2. **수용 기준**
   - 번호가 있는 목록으로 최소 8개를 작성한다.
   - 출석 성공, 중복 출석, 권한 부족, 잘못된 입력, 저장 실패, 조회, 재시작 후 데이터 유지 여부를 실제 관찰 가능한 결과로 표현한다.
   - 성능 기준은 측정 방법과 목표값이 사용자에게서 제공된 경우에만 포함한다.

3. **에지 케이스**
   - 상황 / 판정 조건 / 봇의 응답 / 데이터 변경 여부의 네 열을 가진 표로 작성한다.
   - 중복 요청, 동일 시각의 동시 요청, 저장소 장애, 봇 재시작, 사용자의 이름 변경, 서버 탈퇴, 권한 변경, 잘못된 기간, 디스코드 API 오류를 포함한다.
   - 정책이 미정인 행에는 임의 처리 대신 `[입력 필요: 처리 정책]`을 표시한다.

4. **개인정보 및 권한 설계**
   - 수집 데이터, 목적, 보유 기간, 파기 방법, 조회 권한, 삭제·정정 처리 항목을 표로 제시한다.
   - 개인정보 보호법 적용 여부는 `[확인 필요]`로 두고 확인할 사실을 적는다.
   - 봇 토큰과 식별자 보안, 관리자 명령어 제한, 감사 로그 필요 여부를 별도 목록으로 제시한다.

5. **코드와 실행 방법**
   - 선택한 스택에 맞는 파일 구조와 전체 코드를 제시한다.
   - 코드 앞에 필요한 의존성, 환경 변수, 디스코드 권한, 명령어 등록 절차를 적는다.
   - 코드 뒤에는 설치, 설정, 실행, 종료, 재실행 순서를 번호로 적는다.
   - 코드가 여러 파일이면 각 파일명을 명시하고, 일부만 생략하지 않는다. 미확정 요구사항 때문에 완성할 수 없는 부분은 코드에 임의값을 넣지 말고 조건부 구현 또는 슬롯으로 표시한다.

6. **검증 방법**
   - 각 수용 기준에 대응하는 테스트 절차, 입력, 기대 결과를 표로 작성한다.
   - 정상 흐름과 실패 흐름을 모두 포함하고, 저장소 장애와 봇 재시작 뒤 기록 보존을 확인한다.
   - 실제 실행하지 않은 테스트는 실행 완료로 표현하지 말고 `실행 필요`로 표시한다.

## 문체 규칙

문체는 **hybrid(혼합)**로 쓴다. 목표와 설계 배경, 개인정보 처리 범위, 실행 흐름 설명은 짧은 서술형 문단으로 작성한다. 스택, 수용 기준, 에지 케이스, 환경 변수, 권한, 테스트 절차, 코드 주변의 실행 단계는 표와 번호 목록 중심의 개조식으로 작성한다. “간단히”, “완벽하게”, “문제없이”처럼 검증 기준이 없는 표현은 출석 성공 조건이나 오류 처리 결과로 바꿔 쓴다. 특정 봇이나 개발자 사례를 지어내지 말고, 디스코드에서 실제로 표시될 메시지는 명확하고 짧게 작성한다.

## 문체 규칙 (휴머나이저 v1)

산출물의 산문 전체에 적용한다. 코드, 명령어, 인용문, 고유명사는 손대지 않는다.

- 종결어미를 하나로 고정하지 마라. ~다/~는데/명사형 종결을 섞고 장문과 단문을 교차시킨다.
- 서두 인사("물론입니다!", "~에 대해 알아보겠습니다")와 마무리 상투구("결론적으로", "도움이 되셨기를 바랍니다")를 쓰지 않는다. 마지막 구체 사실로 끝낸다.
- "첫째, 둘째" 기계 나열, 이모지, 문단마다 붙는 볼드 소제목 금지.
- 근거 없는 추상어("다양한", "효과적인", "전략적 접근")를 구체 서술로 바꿔라. 단 그 구체 정보는 사용자 입력과 검증 가능한 출처에 있는 사실만 쓴다. 인간답게 보이려고 세부를 지어내지 마라. 받지 못한 값은 [입력 필요] 슬롯으로 남긴다.
- 번역투를 피한다. "~에 있어서", "~을 통해" 남발과 "~되어지다" 같은 이중 피동 금지.
- 문두 접속사("또한", "하지만", "따라서")를 연속해서 쓰지 않는다. 문맥상 명확한 주어는 생략한다.
- 같은 핵심어를 한 문단에서 반복하지 마라. 억지 동의어로 돌려 말하는 과교정도 피한다.
- 오탐 가드: 오류 없는 문법, 한 번의 접속어, 격식 어휘는 그 자체로 AI 문체가 아니다. 신호가 여럿 겹칠 때만 고치고, 일부러 거칠게 쓰지 마라.

## 제출 전 자기 감사

초안을 완성한 뒤 스스로 두 가지를 점검하라. 어느 부분이 명백히 AI 문체로 읽히는가. 사용자 입력이나 검증 가능한 출처에 없는 사실을 단정한 곳이 있는가. 걸린 부분을 고쳐 쓴 다음 최종본만 출력한다. 점검 과정 자체는 출력하지 마라.

## 자기검증

1. 최종 산출물이 단순한 봇 설명이 아니라 디스코드 출석 체크 봇의 설계, 코드, 실행 방법, 검증 방법을 모두 포함하는지 확인하라.
2. 사용자 입력에 없는 언어·런타임·라이브러리·저장소·출석 기간·명령어를 임의로 확정하지 않았는지 확인하라.
3. `[입력 필요: 항목]` 슬롯마다 사용자가 무엇을 제공해야 하는지 한 줄 설명했는지 확인하라.
4. 출석 성공과 중복 출석을 별도 결과로 구분했는지 확인하라.
5. 권한 부족, 잘못된 명령, 저장 실패, 디스코드 API 오류에서 데이터 변경 여부와 응답을 명시했는지 확인하라.
6. 동일 시각의 동시 출석 요청으로 중복 기록이 생기지 않도록 처리 조건 또는 검증 방법을 제시했는지 확인하라.
7. 개인정보를 처리하는 출석 기록의 수집 항목, 보유 기간, 파기 방법, 접근 권한을 설계 산출물에 넣었는지 확인하라.
8. 봇 토큰과 식별자를 코드에 하드코딩하거나 출력하는 부분이 없는지 확인하라.
9. 코드의 언어·런타임·의존성·실행 환경과 필요한 권한이 서로 모순되지 않는지 확인하라.
10. 테스트하지 않은 성능이나 안정성을 사실처럼 주장하지 않고 `실행 필요` 또는 `[확인 필요]`로 표시했는지 확인하라.
11. 입력에 없던 길드명, 관리자 역할명, 채널명, 출석 시간, 데이터베이스명, 배포 서비스명을 추가하지 않았는지 확인하라.
12. 슬롯을 실제 값처럼 임의로 채우지 않았는지 확인하라.
13. 출석 봇의 범위를 벗어나 결제, 음악 재생, 자동 모집 같은 기능을 추가하지 않았는지 확인하라.
14. 본문이 지정된 6개 섹션 순서를 지키고, 수용 기준이 번호 목록이며, 에지 케이스와 검증 방법이 표로 제시되었는지 확인하라.