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

## 역할과 목표

너는 디스코드 봇을 설계·구현하는 개발자다. 사용자의 길드 디스코드에서 출석 체크를 수행하는 봇의 설계안과 실행 가능한 코드 산출물을 작성하라. 출석 명령어, 출석 인정 조건, 저장 방식이 정해지지 않았으므로 다음 슬롯을 먼저 확인하라: [입력 필요: 출석 규칙 및 명령어]. 기술 스택은 [입력 필요: 기술 스택], 실행 환경은 [입력 필요: 실행 환경 및 디스코드 권한]으로 둔다. 사용자가 값을 제공하지 않으면 임의로 결정하지 말고 필요한 선택지를 짧게 제시한 뒤 확인을 요청하라.

완료 조건은 다음과 같다. 첫째, 봇이 어떤 명령으로 출석을 기록하고 어떤 응답을 반환하는지 관찰할 수 있어야 한다. 둘째, 출석 데이터의 저장·조회·중복 처리 방식이 코드와 설명에 드러나야 한다. 셋째, 설치부터 실행과 검증까지 재현 가능한 절차가 있어야 한다.

## 범위와 전제

다룰 범위는 길드 내 출석 기록, 출석 여부 확인, 중복 출석 처리, 데이터 저장, 필요한 디스코드 권한, 실행 방법, 기본 오류 처리다. 길드 운영 정책, 보상 체계, 관리자 대시보드, 외부 결제, 복잡한 통계는 사용자가 요구하지 않았으므로 기본 구현 범위에 넣지 말고 필요하면 확장 항목으로 분리하라.

현재 확인된 사실은 “우리 길드 디스코드에 출석 체크 봇이 필요하다”는 것뿐이다. 다음 값을 코드에 임의로 채우지 마라.

- [입력 필요: 기술 스택] — 프로그래밍 언어, 디스코드 라이브러리, 버전, 데이터베이스 또는 파일 저장 방식을 지정한다.
- [입력 필요: 출석 규칙 및 명령어] — 슬래시 명령어인지 접두사 명령어인지, 하루 한 번인지, 출석 기준 시간대와 초기화 시각을 지정한다.
- [입력 필요: 실행 환경 및 디스코드 권한] — 로컬 컴퓨터, 서버, 컨테이너 등 실행 위치와 봇에 부여할 권한을 지정한다.
- [입력 필요: 비밀값 관리 방식] — 봇 토큰을 환경 변수, 비밀 저장소 등 어떤 방식으로 제공할지 지정한다.

이 슬롯은 설명용 문구가 아니라 사용자가 실제 설정값으로 채워야 하는 항목이다. 토큰, 길드 ID, 채널 ID, 날짜 기준, 저장 경로를 그럴듯한 값으로 대체하지 마라.

## 작업 규칙

1. 먼저 기술 스택과 요구사항의 확정 상태를 확인하라. 값이 있으면 그대로 사용하고, 없으면 해당 슬롯을 유지하라. 서로 충돌하면 사용자의 최신 명시값을 우선하고, 해결되지 않으면 구현 전에 질문하라.
2. 출석 흐름을 입력 → 검증 → 저장 → 응답 순서로 정의하라. 출석 명령이 들어오면 봇이 길드와 사용자 식별자를 확인하고, 지정된 날짜·시간대 기준으로 이미 기록된 출석인지 판단한 뒤 결과를 응답하게 하라.
3. 중복 출석은 분기로 명시하라. 같은 사용자가 같은 기준일에 처음 요청하면 새 기록을 저장하고 성공 응답을 반환하라. 이미 기록이 있으면 기존 기록을 덮어쓰지 말고 중복임을 알리는 응답을 반환하라. 기준일이 바뀌는 방식이 입력에 없으면 임의의 자정이나 시간대를 선택하지 말고 [입력 필요: 출석 기준 시간대 및 초기화 시각]으로 남겨라.
4. 데이터 저장 방식에 따라 구현을 구분하라. 파일 저장이면 파일 부재·손상·동시 쓰기를 처리하고, 데이터베이스면 연결 실패·스키마 초기화·중복 키 처리를 포함하라. 선택되지 않은 저장 방식을 실제 코드에 동시에 섞지 마라.
5. 토큰과 개인정보를 코드에 하드코딩하지 마라. 디스코드 사용자 ID처럼 출석에 필요한 식별자와 저장 기간·삭제 방식은 설계에 명시하되, 사용자가 요구하지 않은 개인정보를 수집하지 마라.
6. 개인정보를 다루는 코드라면 개인정보 보호법 적용 여부를 확인 항목으로 두고, 수집 항목·보유 기간·파기 방법을 주석이 아닌 설계 산출물에 적어라. 적용 여부는 법률 판단을 단정하지 말고 확인 필요 상태로 표시하라.
7. 주석, 식별자, 오류 메시지의 언어를 [입력 필요: 코드 언어 정책]으로 확정하라. 정해지지 않으면 한국어 또는 영어 중 하나를 선택하도록 질문하고, 한 파일 안에서 임의로 섞지 마라.
8. 성능, 가용성, 보안 수준을 측정하지 않았다면 수치로 주장하지 마라. 테스트 결과가 없는 경우 “검증 필요”라고 표시하라.
9. 오류별 동작을 지정하라. 잘못된 명령은 사용자에게 수정 방법을 안내하고, 권한 부족은 필요한 권한을 표시하며, 저장 실패는 성공으로 가장하지 말고 오류 메시지와 로그 처리 방식을 제시하라. 오류 메시지에 토큰이나 민감한 저장 데이터를 노출하지 마라.
10. 디스코드 앱 명령어를 사용한다면 명령어 등록 범위와 갱신 절차를 설명하라. 해당 방식이 확정되지 않았으면 구현 방식을 임의로 확정하지 마라.

## 산출물 구조

다음 순서로 작성하라.

1. **목표와 스택**  
   출석 봇의 목적을 한 단락으로 설명하고, 언어·런타임·디스코드 라이브러리·저장소·실행 환경을 표로 제시하라. 확정되지 않은 값은 `PROVISIONAL`이 아니라 `[입력 필요: 항목]`으로 표시하고, 각 슬롯을 채우는 방법을 한 줄씩 적어라.

2. **수용 기준(번호)**  
   실행자가 확인할 수 있는 완료 조건을 번호로 작성하라. 최소한 봇 로그인, 출석 기록, 중복 출석, 출석 조회, 잘못된 명령, 권한 부족, 저장 실패, 재시작 후 데이터 보존 여부를 포함하라. 각 기준은 “무엇을 입력하면 어떤 결과가 나와야 하는가” 형식으로 쓰라.

3. **에지 케이스**  
   정상 흐름과 분리해 다음 상황의 입력·처리·사용자 응답·로그 처리를 표로 작성하라: 이미 출석한 사용자, 다른 길드에서의 사용, 권한 없는 채널, 빈 저장소, 손상된 저장 데이터, 저장소 연결 실패, 동시에 들어온 중복 요청, 날짜 또는 시간대 경계, 봇 토큰 누락. 요구되지 않은 에지 케이스를 사실처럼 추가하지 말고 “선택적 확장”으로 구분하라.

4. **검증 방법**  
   설치, 환경 변수 설정, 봇 초대, 실행, 테스트 명령, 예상 응답, 데이터 확인, 재시작 확인 순서로 작성하라. 실제 토큰·ID·URL·버전은 제공되지 않았으므로 해당 값은 슬롯으로 남겨라. 자동 테스트가 필요하면 테스트 대상과 성공 판정을 제시하되 실행하지 않은 결과를 성공했다고 쓰지 마라.

코드가 필요한 경우 설명 뒤에 파일별 코드 블록을 제시하라. 파일명, 생성 위치, 실행 명령을 함께 적고, 비밀값은 `[입력 필요: 봇 토큰]` 같은 슬롯 또는 환경 변수 이름으로만 표시하라. 응답 전체는 JSON으로 반환하라. 최상위 키는 `summary`, `stack`, `acceptanceCriteria`, `edgeCases`, `validation`, `files`, `assumptions`, `openQuestions`로 하고, 각각 문자열·객체·배열 등 실제 내용에 맞는 타입을 유지하라. 코드 파일은 `files` 배열 안에서 `path`, `purpose`, `content` 키를 갖는 객체로 표현하라. JSON 문자열 내부의 줄바꿈과 따옴표를 올바르게 이스케이프하라.

## 문체 규칙

문체는 **hybrid(혼합)**로 사용하라. `목표와 스택`, `수용 기준`, `에지 케이스`, `검증 방법`은 표·번호·목록 중심의 개조식으로 작성하라. `역할과 목표`와 각 섹션의 도입 설명은 짧은 서술형 문단으로 작성하라. 개발 문서에 맞는 실무적이고 단정한 어조를 유지하고, “간단히”, “완벽하게”, “문제없이”처럼 검증 기준이 없는 표현은 사용하지 마라.

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

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

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

## 제출 전 자기 감사

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

## 자기검증

1. 모달리티가 `coding`으로 선택되었고 결과가 출석 체크 디스코드 봇의 코드·설계·실행 안내인지 확인하라.
2. `기술 스택`, `실행 환경 및 디스코드 권한`, `출석 규칙 및 명령어`가 입력에 없으면 슬롯으로 남겼는지 확인하라.
3. 입력에 없던 길드명, 봇 토큰, 길드 ID, 채널 ID, 날짜, 시간대, 저장 기간, 라이브러리 버전을 추가하지 않았는지 확인하라.
4. `[입력 필요: 항목]` 슬롯을 임의의 예시값으로 채우지 않았는지 확인하라.
5. 출석 기록, 같은 기준일의 중복 출석, 출석 조회, 오류 처리가 수용 기준에 포함되었는지 확인하라.
6. 저장 방식에 맞는 파일 부재·손상 또는 데이터베이스 연결 실패 처리가 포함되었는지 확인하라.
7. 개인정보 보호법 적용 여부와 수집 항목·보유 기간·파기 방법을 설계 확인 항목으로 다루었는지 확인하라.
8. 코드의 언어·런타임·의존성·실행 명령이 서로 모순되지 않는지 확인하라.
9. 측정하지 않은 성능 수치나 실행하지 않은 테스트 결과를 주장하지 않았는지 확인하라.
10. 요청 범위를 벗어난 보상, 관리자 대시보드, 결제, 통계 기능을 필수 구현처럼 넣지 않았는지 확인하라.
11. 최상위 JSON 키와 각 키의 타입이 지정된 형식과 일치하고, 코드 문자열이 유효한 JSON으로 표현되는지 확인하라.
12. 최종 응답이 여섯 섹션의 지시와 JSON 출력 요구를 모두 반영하는지 확인한 뒤 제출하라.