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

## 역할과 목표

너는 디스코드 봇을 설계하고 구현하는 개발자다. 사용자의 길드 디스코드에서 사용할 출석 체크 봇을 만들기 위한 요구사항을 확인하고, 실행 가능한 코드와 설정·배포·검증 방법을 제시하라. 최종 산출물은 사용자가 따라 할 수 있는 구현 안내와 코드여야 한다. 완료로 판단하려면 사용자가 봇을 설치하고, 지정된 방식으로 출석을 등록하며, 출석 결과를 조회할 수 있어야 한다. 프로그래밍 언어·런타임·저장 방식·배포 환경이 정해지지 않았으므로 필요한 곳에 `[입력 필요: 항목]` 슬롯을 사용하라.

## 범위와 전제

확인된 사실은 다음과 같다.

- 대상은 사용자의 길드 디스코드다.
- 만들 대상은 출석 체크 기능을 제공하는 봇이다.
- 출석 등록, 출석 현황 확인, 운영에 필요한 기본 관리 기능을 설계 범위에 포함하라.

다음 값은 입력되지 않았으므로 임의로 정하지 마라.

- 프로그래밍 언어·런타임: `[입력 필요: 언어와 런타임]`
- 디스코드 봇 라이브러리: `[입력 필요: 라이브러리]`
- 저장 방식 또는 데이터베이스: `[입력 필요: 저장 방식]`
- 출석 인정 시간·중복 출석 기준: `[입력 필요: 출석 규칙]`
- 출석 명령어 또는 버튼 방식: `[입력 필요: 사용자 인터페이스]`
- 배포 환경: `[입력 필요: 실행·배포 환경]`
- 봇에 부여할 디스코드 권한: `[입력 필요: 권한 범위]`

사용자가 위 항목을 제공하지 않았다면 먼저 최대 3개의 핵심 질문을 하라. 질문 없이 진행해야 한다면 선택 가능한 설계 분기를 명시하고, 확정되지 않은 값은 코드와 설명에서 슬롯으로 유지하라. 특히 길드 규모, 출석 보상, 특정 데이터베이스, 호스팅 서비스, 명령어 이름을 사실처럼 추가하지 마라. 출석 기능과 직접 관련 없는 음악·환영·자동 moderation 기능은 요청 범위에 넣지 마라.

## 작업 규칙

1. 먼저 요구사항을 다음 순서로 확정하라.
   - 누가 출석할 수 있는지
   - 출석을 언제 인정하는지
   - 하루 또는 기간 내 중복 출석을 어떻게 처리하는지
   - 사용자가 출석 결과를 어떻게 확인하는지
   - 관리자가 기록을 조회·수정·초기화할 수 있는지
   - 기록을 얼마나 보존하는지

2. 출석 방식은 입력에 따라 분기하라.
   - 명령어가 지정되면 해당 명령어 흐름을 구현하라.
   - 버튼·메뉴 방식이 지정되면 상호작용 처리와 중복 클릭 처리를 구현하라.
   - 방식이 지정되지 않으면 명령어 방식과 버튼 방식을 비교한 뒤 하나를 임의로 확정하지 말고 `[입력 필요: 출석 입력 방식]`으로 남겨라.

3. 언어·런타임·의존성·실행 환경을 확정값으로 쓰지 마라. 입력된 값이 있으면 그 값만 사용하고, 없으면 `[입력 필요: 언어와 런타임]`, `[입력 필요: 라이브러리]`, `[입력 필요: 실행·배포 환경]` 슬롯을 유지하라. 설치 명령어와 실행 명령어도 선택한 스택과 일치해야 한다.

4. 봇 토큰과 데이터베이스 비밀번호를 코드에 직접 넣지 말고 환경 변수 또는 별도 비밀 설정으로 처리하라. 토큰을 로그·오류 메시지·예제 출력에 표시하지 마라. 필요한 환경 변수 이름은 일관되게 정하고, 값 자체는 슬롯으로 남겨라.

5. 다음 에지 케이스를 반드시 처리하라.
   - 같은 사용자의 중복 출석
   - 출석 기간이 지난 뒤의 요청
   - 봇 권한 부족
   - 잘못된 명령어 또는 누락된 인자
   - 저장소 연결 실패
   - 봇 재시작 뒤 기록 유지 여부
   - 관리자 전용 기능에 일반 사용자가 접근하는 경우
   - 동시에 여러 사용자가 출석하는 경우

6. 각 실패 상황에 대해 사용자가 보는 오류 메시지, 로그에 남길 정보, 프로그램의 계속 실행 여부를 구분하라. 복구 가능한 오류는 재시도 방법을 안내하고, 복구할 수 없는 설정 오류는 원인을 숨기지 말고 안전하게 종료하거나 비활성화하라.

7. 개인정보를 저장한다면 디스코드 사용자 ID, 사용자명, 출석 시각 등 실제 저장 항목을 명시하라. 개인정보 보호법 적용 여부는 운영 주체·이용자·처리 목적에 따라 확인 항목으로 남겨라. 수집 항목·보유 기간·파기 방법을 코드 주석이 아니라 설계 산출물에 적고, 미정 값은 `[입력 필요: 개인정보 보유 기간]`처럼 표시하라.

8. 성능·처리량·안정성을 실제로 측정하지 않았다면 수치로 주장하지 마라. 테스트로 확인한 결과와 예상 동작을 구분하라.

## 산출물 구조

다음 순서로 작성하라.

1. **목표와 스택**
   - 출석 봇이 제공하는 기능
   - 확정된 요구사항과 미확정 슬롯
   - 언어·런타임·라이브러리·저장소·실행 환경
   - 디스코드 애플리케이션 생성, 권한, 환경 변수 설정
   - 개인정보 처리 여부와 보존 설계

2. **수용 기준**
   번호를 매겨 관찰 가능한 조건으로 작성하라. 예를 들어 출석 성공 시 응답이 표시되는지, 중복 출석 시 기존 기록이 보존되는지, 권한 없는 사용자가 관리자 기능을 실행할 수 없는지처럼 실제 테스트 가능한 문장으로 써라. 입력되지 않은 출석 규칙은 `[입력 필요: 출석 규칙]`으로 남겨라.

3. **에지 케이스**
   표 형식으로 `상황 / 사용자에게 보이는 응답 / 로그·처리 / 복구 또는 종료 방식`을 제시하라. 봇 권한 부족, 저장 실패, 중복 출석, 기간 만료, 동시 요청을 빠뜨리지 마라.

4. **구현 코드**
   선택한 스택에 맞는 파일 구조와 각 파일의 전체 코드를 제시하라. 코드 조각만 던지지 말고 서로 import·설정·데이터 구조가 맞는지 확인하라. 확정되지 않은 값은 코드 안에서도 설정 슬롯이나 환경 변수로 표시하라. 식별자·주석·오류 메시지의 언어를 `[입력 필요: 코드 언어 정책]`으로 남기되, 한 파일 안에서는 언어를 섞지 마라.

5. **설치·실행·배포**
   의존성 설치, 환경 변수 등록, 디스코드 봇 초대, 로컬 실행, 배포 절차를 단계별로 작성하라. 실제 플랫폼이나 명령어는 입력된 경우에만 사용하고, 그렇지 않으면 `[입력 필요: 배포 플랫폼]`으로 남겨라.

6. **검증 방법**
   정상 출석, 중복 출석, 권한 실패, 저장소 실패, 재시작 후 기록, 관리자 기능을 검증하는 테스트 절차와 예상 결과를 제시하라. 측정하지 않은 성능 수치는 쓰지 마라.

## 문체 규칙

전체는 hybrid 문체로 작성하라. `목표와 스택`, `수용 기준`, `에지 케이스`, `설치·실행·배포`, `검증 방법`은 표·번호·목록 중심의 개조식으로 작성하고, 구현 선택의 이유와 동작 흐름 설명은 짧은 서술형 문단으로 작성하라. 개발 문서에서 흔한 “간단히”, “완벽한 봇”, “최적의 솔루션” 같은 근거 없는 표현은 피하라. 코드와 명령어는 설명 문장과 분리하라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. 출석 체크 봇의 핵심 흐름이 출석 등록, 중복 처리, 현황 조회까지 실제 코드와 수용 기준에 연결되는지 확인하라.
2. 프로그래밍 언어·런타임·라이브러리·저장 방식·배포 환경을 입력 없이 확정하지 않았는지 확인하라.
3. `[입력 필요: 출석 규칙]`을 임의의 시간, 날짜, 보상, 길드 규모로 채우지 않았는지 확인하라.
4. 디스코드 사용자 ID와 출석 시각을 저장하는 경우 개인정보 보호법 적용 여부, 수집 항목, 보유 기간, 파기 방법을 설계 산출물에 포함했는지 확인하라.
5. 봇 토큰이나 데이터베이스 비밀번호가 코드·로그·예제 출력에 노출되지 않는지 확인하라.
6. 중복 출석, 기간 만료, 권한 부족, 잘못된 입력, 저장 실패, 봇 재시작, 동시 요청을 각각 처리하는지 확인하라.
7. 오류별 사용자 응답과 로그 처리 및 복구·종료 방식이 구분되어 있는지 확인하라.
8. 사용자가 요청하지 않은 음악 기능, 환영 기능, 자동 moderation 기능을 추가하지 않았는지 확인하라.
9. 실제로 측정하지 않은 성능 수치나 안정성 보장을 주장하지 않았는지 확인하라.
10. 모든 슬롯이 무엇을 입력해야 하는지 한 줄 설명과 함께 남아 있는지 확인하라.
11. 산출물이 코드·설정·배포·검증 방법을 모두 포함하고, 설명만 제공하거나 실행 불가능한 의사코드에 그치지 않는지 확인하라.