수업노트로 요청한 tdd-red 스킬의 초안은 다음과 같습니다.아래 내용으로 진행하면 import error, 파일 없음 에러도 정상적인 red 로 인식하고 다음 단계로 진행됩니다.--- name: tdd-red description: 승인된 테스트 시나리오를 실패하는 테스트 코드로 작성한다. TDD Red 단계 시작 시 사용한다. argument-hint: <feature> <이슈 번호> allowed-tools: Read Write Bash --- `$ARGUMENTS`에서 feature 이름과 이슈 번호를 파싱해 해당 이슈의 승인된 시나리오를 실패하는 테스트 코드로 작성한다. ## 시작 전 ### 인자 파싱 `$ARGUMENTS`를 공백으로 분리해 첫 번째 토큰을 `{feature}`, 두 번째 토큰을 `{issue}` 로 사용한다. | 입력 예시 | feature | issue | | ------------------ | -------- | ----- | | `/tdd-red tag 2` | `tag` | `2` | | `/tdd-red search 1`| `search` | `1` | 누락된 값이 있으면 실행 전에 사용자에게 질문한다. - `{feature}`가 없으면: "어떤 기능의 이슈인가요? (예: tag, search, ...)" - `{issue}`가 없으면: "이슈 번호를 알려주세요." 두 값이 확정된 뒤 `docs/features/{feature}/issue-{issue}.md` 를 읽어 시그니처와 테스트 시나리오 목록을 파악한다. - 시그니처 섹션: 테스트 대상 파일 경로 및 함수·컴포넌트명 확인 - 테스트 시나리오 섹션: 작성할 시나리오 목록 전체 수집 파일이 없으면 즉시 멈추고 사용자에게 알린다 (`/test-scenarios {feature} {issue}` 를 먼저 실행해야 한다는 안내 포함). --- ## 단계 1: 테스트 파일 준비 시그니처에서 테스트 대상 파일 경로를 추출하고 테스트 파일 경로를 결정한다. ### 파일 위치 규칙 | 구현 파일 | 테스트 파일 | | ---------------------------------- | ---------------------------------------- | | `src/api/tags.ts` | `src/api/tags.test.ts` | | `src/components/TagInput.tsx` | `src/components/TagInput.test.tsx` | | `src/context/NotesContext.tsx` | `src/context/NotesContext.test.tsx` | - 테스트 파일이 이미 존재하면 기존 내용을 읽어 중복 `describe` 블록을 피한다. - 테스트 파일이 없으면 새로 생성한다. ### 파일 헤더 (신규 생성 시) ```ts import { describe, it, expect, vi, beforeEach } from 'vitest'; // 컴포넌트 파일인 경우에만 추가: // import { render, screen } from '@testing-library/react'; // import userEvent from '@testing-library/user-event'; ``` --- ## 단계 2: 시나리오를 테스트 코드로 작성 시나리오를 하나씩 `it()` 블록으로 변환한다. 한 번에 모두 작성하지 않고 **시나리오 하나 작성 → 실행 → 실패 확인 → 다음 시나리오** 순서를 반복한다. ### 테스트 이름 형식 ``` should [기대 동작] when [조건] ``` ### describe 블록 구조 함수·컴포넌트 단위로 묶는다. ```ts describe('함수명 또는 컴포넌트명', () => { it('should [기대 동작] when [조건]', () => { // Red 단계: 구현이 없으므로 실패하는 코드만 작성 }); }); ``` ### Red 테스트 작성 원칙 - 구현이 존재하지 않으므로 import가 실패하거나 호출이 오류를 던져야 한다. - 억지로 통과시키려 하지 않는다. 실패 자체가 목표다. - `expect`는 실제 기대 동작을 명확하게 표현한다. `expect(true).toBe(false)` 같은 더미 assertion은 사용하지 않는다. **API 함수 예시** ```ts import { addTag } from './tags'; describe('addTag', () => { it('should return updated note when valid tag is added', async () => { const result = await addTag('note-1', 'work'); expect(result.tags).toContain('work'); }); it('should throw when tag is empty string', async () => { await expect(addTag('note-1', '')).rejects.toThrow(); }); }); ``` **컴포넌트 예시** ```ts import { render, screen } from '@testing-library/react'; import { TagInput } from './TagInput'; describe('TagInput', () => { it('should render input when component is mounted', () => { render(<TagInput tags={[]} onAdd={vi.fn()} onRemove={vi.fn()} />); expect(screen.getByRole('textbox')).toBeInTheDocument(); }); }); ``` --- ## 단계 3: 시나리오별 실행 루프 각 시나리오를 작성한 직후 아래 명령으로 해당 테스트 파일만 실행한다. ```bash npx vitest run <테스트-파일-경로> --reporter=verbose ``` - **실패 확인**: `FAIL` 또는 import 오류가 나오면 정상. 다음 시나리오로 이동한다. - **통과**: 테스트가 의도치 않게 통과하면 즉시 멈추고 사용자에게 알린다. 구현 파일이 이미 존재하는지 확인한다. --- ## 단계 4: 전체 확인 모든 시나리오 작성이 끝나면 전체 테스트를 실행한다. ```bash npm test ``` - 작성한 테스트 파일의 모든 케이스가 실패하는지 확인한다. - 기존에 통과하던 테스트가 새로 실패하면 즉시 사용자에게 보고한다. --- ## 제약 - 테스트 파일(`*.test.ts`, `*.test.tsx`)만 생성하거나 수정한다. - `src/` 안의 구현 코드(`*.ts`, `*.tsx`, `*.css` 등 테스트 파일 제외)는 절대 수정하지 않는다. - 테스트가 통과하도록 mock이나 stub으로 우회하지 않는다. --- ## 산출물 - 작성된 테스트 파일 목록 및 경로 - 시나리오별 실패 메시지 요약 - `npm test` 결과: 실패한 테스트 수 / 전체 테스트 수   관련해서, import 에러 및 파일 에러는 없어야한다.(stub 이 있어야 함. Collect 는 모두 성공하고 Test 단계에서 실패해야한다.) 는 점을 고려해서 아래와 같이 스킬을 수정했는데, 피드백 부탁드립니다. --- name: tdd-red description: 승인된 테스트 시나리오를 실패하는 테스트 코드로 작성한다. TDD Red 단계 시작 시 사용한다. argument-hint: <feature> <이슈 번호> allowed-tools: Read Write Bash --- `$ARGUMENTS`에서 feature 이름과 이슈 번호를 파싱해 해당 이슈의 승인된 시나리오를 실패하는 테스트 코드로 작성한다. ## 시작 전 ### 인자 파싱 `$ARGUMENTS`를 공백으로 분리해 첫 번째 토큰을 `{feature}`, 두 번째 토큰을 `{issue}` 로 사용한다. | 입력 예시 | feature | issue | | ------------------- | -------- | ----- | | `/tdd-red tag 2` | `tag` | `2` | | `/tdd-red search 1` | `search` | `1` | 누락된 값이 있으면 실행 전에 사용자에게 질문한다. - `{feature}`가 없으면: "어떤 기능의 이슈인가요? (예: tag, search, ...)" - `{issue}`가 없으면: "이슈 번호를 알려주세요." 두 값이 확정된 뒤 `docs/features/{feature}/issue-{issue}.md` 를 읽어 시그니처와 테스트 시나리오 목록을 파악한다. - 시그니처 섹션: 테스트 대상 파일 경로 및 함수·컴포넌트명 확인 - 테스트 시나리오 섹션: 작성할 시나리오 목록 전체 수집 파일이 없으면 즉시 멈추고 사용자에게 알린다 (`/test-scenarios {feature} {issue}` 를 먼저 실행해야 한다는 안내 포함). --- ## 단계 0: 스텁 생성 테스트 파일을 작성하기 전에, 이슈의 시그니처를 읽어 **아직 존재하지 않는 구현 파일**에 대해서만 최소 스텁을 생성한다. ### 목적 Import Error 때문에 테스트가 실행조차 되지 않으면, 테스트가 무엇을 거부하는지 알 수 없다. 스텁은 빌드를 통과시켜 테스트가 **Assertion Failure로 실패**하도록 만드는 것이 전부다. ### 스텁 작성 규칙 - **기존 파일이 있으면 건드리지 않는다.** 신규 파일만 생성한다. - 시그니처의 파라미터·반환 타입을 그대로 선언한다. 구현 로직은 쓰지 않는다. - 반환값은 타입을 만족하는 최솟값으로 고정한다. | 반환 타입 | 스텁 반환값 | | ------------------ | ------------- | | `string[]` | `[]` | | `string` | `''` | | `boolean` | `false` | | `Promise<T>` | `Promise.resolve(/* 최솟값 */)` | | React 컴포넌트 | `return <div />;` | | `void` | _(반환 없음)_ | ### 스텁 예시 **훅 (`src/hooks/useTagInput.ts`)** ```ts import { useState } from 'react'; export function useTagInput(_initialTags: string[]) { const [tags] = useState<string[]>([]); const [inputValue, setInputValue] = useState(''); return { tags, inputValue, setInputValue, addTag: (_value: string) => {}, removeTag: (_tag: string) => {}, handleKeyDown: (_e: React.KeyboardEvent<HTMLInputElement>) => {}, }; } ``` **컴포넌트 (`src/components/TagInput.tsx`)** ```tsx import { TagInputProps } from '../types'; // 필요 시 인라인 정의 export function TagInput(_props: TagInputProps) { return <div />; } ``` **API 함수 (`src/api/tags.ts`)** ```ts import { Note } from '../types/note'; export async function addTag(_noteId: string, _tag: string): Promise<Note> { return Promise.resolve({} as Note); } ``` --- ## 단계 1: 테스트 파일 준비 시그니처에서 테스트 파일 경로를 결정한다. | 구현 파일 | 테스트 파일 | | -------------------------------- | ----------------------------------- | | `src/api/tags.ts` | `src/api/tags.test.ts` | | `src/components/TagInput.tsx` | `src/components/TagInput.test.tsx` | | `src/context/NotesContext.tsx` | `src/context/NotesContext.test.tsx` | - 테스트 파일이 이미 존재하면 기존 내용을 읽어 중복 `describe` 블록을 피한다. - 테스트 파일이 없으면 새로 생성한다. ### 파일 헤더 (신규 생성 시) ```ts import { describe, it, expect, vi, beforeEach } from 'vitest'; // 컴포넌트 파일인 경우에만 추가: // import { render, screen } from '@testing-library/react'; // import userEvent from '@testing-library/user-event'; ``` --- ## 단계 2: 시나리오를 테스트 코드로 작성 이슈의 시나리오 전체를 한 번에 `it()` 블록으로 변환한다. ### 테스트 이름 형식 ``` should [기대 동작] when [조건] ``` ### describe 블록 구조 함수·컴포넌트 단위로 묶는다. ```ts describe('함수명 또는 컴포넌트명', () => { it('should [기대 동작] when [조건]', () => { // 스텁이 있으므로 import는 통과하고, assertion이 실패한다 }); }); ``` ### Red 테스트 작성 원칙 - `expect`는 실제 기대 동작을 명확하게 표현한다. `expect(true).toBe(false)` 같은 더미 assertion은 사용하지 않는다. - 스텁의 반환값(빈 배열, `<div />` 등)을 기준으로 assertion이 자연스럽게 실패하도록 작성한다. - 테스트가 통과하도록 mock이나 stub으로 우회하지 않는다. **API 함수 예시** ```ts import { addTag } from './tags'; describe('addTag', () => { it('should return updated note when valid tag is added', async () => { const result = await addTag('note-1', 'work'); expect(result.tags).toContain('work'); // 스텁은 {} 반환 → tags 없음 → Assertion Failure }); it('should throw when tag is empty string', async () => { await expect(addTag('note-1', '')).rejects.toThrow(); // 스텁은 throw 안 함 → Assertion Failure }); }); ``` **컴포넌트 예시** ```ts import { render, screen } from '@testing-library/react'; import { TagInput } from './TagInput'; describe('TagInput', () => { it('should render input when component is mounted', () => { render(<TagInput tags={[]} onAdd={vi.fn()} onRemove={vi.fn()} />); expect(screen.getByRole('textbox')).toBeInTheDocument(); // 스텁은 <div /> → textbox 없음 → Assertion Failure }); }); ``` --- ## 단계 3: 실행 및 Red 품질 확인 모든 테스트 파일을 작성한 뒤 파일별로 실행한다. ```bash npx vitest run <테스트-파일-경로> --reporter=verbose ``` ### Red 품질 기준 | 실패 유형 | 판정 | 조치 | | ------------------ | ------------- | ---------------------------------------- | | Assertion Failure | ✅ 올바른 Red | 다음으로 진행 | | Runtime Error | ✅ 허용 | 다음으로 진행 | | Import Error | ❌ 스텁 누락 | 단계 0으로 돌아가 해당 파일 스텁 보완 | | Syntax Error | ❌ 테스트 오류 | 테스트 코드 수정 | - **Import Error가 발생하면 올바른 Red로 인정하지 않는다.** 스텁을 보완한 뒤 다시 실행한다. - 테스트가 의도치 않게 통과하면 즉시 멈추고 사용자에게 알린다. --- ## 단계 4: 전체 확인 모든 파일의 Red 품질이 확인된 뒤 전체 테스트를 실행한다. ```bash npm test ``` - 이슈에서 작성한 테스트 파일의 케이스가 모두 Assertion Failure로 실패하는지 확인한다. - 기존에 통과하던 테스트가 새로 실패하면 즉시 사용자에게 보고한다. --- ## 제약 - 테스트 파일(`*.test.ts`, `*.test.tsx`)은 자유롭게 생성·수정한다. - 단계 0의 스텁은 **존재하지 않는 파일**에 한해서만 신규 생성한다. - **기존 구현 파일은 수정하지 않는다.** --- ## 산출물 - 생성된 스텁 파일 목록 및 최솟값 반환 내용 - 작성된 테스트 파일 목록 및 경로 - 파일별 실패 유형 요약 (Assertion Failure / Runtime Error) - `npm test` 결과: 실패한 테스트 수 / 전체 테스트 수

여기 자료 다운로드 했는데 전체 워크 플로우가 안보입니다 ㅠㅠ 저만 그런가요

github에 가면 src 원본만 있고, 실습내용대로 진행하려니 사용된 skill.md 및 다른.md 를 타이핑하기에 내용이 많습니다. 혹시 사용하신 md 파일 공유하여 주실수 있나요?

codex로 적용해도 큰 문제 없을까요?

강의 자료는 어디서 다운 받나요?

교재 실습 파일과 강의에서 직접 작성하는 코드의 내용이 달라 너무 불편합니다. 아직 강의 초반이지만 너무 훅훅 지나가시고, 혼자말처럼 말씀하시는데 정말 따라가기 힘듭니다 강사님. 바이브코딩 시작 전, 강사님이 직접 작성하시는 테스트 코드 와 제공된 실습 자료 코드가 일치하는지 확인해 주시기 바랍니다.

UserService 가 회원 생성이라는 유즈케이스를 담당하는데, 인증 url 생성이나 메일 발송 정책까지 함께 가지고 있기 때문에 책임이 섞여있다고 판단하여 CertificationService 를 분리하신걸까요? 단순히 외부 의존성 분리하려는 목적보다는 인증메일 정책 이라는 별도의 변경 이유를 분리하려는 의도가 맞는지 궁금합니다

 안녕하세요 강의 정말 잘 듣고 있습니다현재 코틀린으로 직접 타이핑해보며 따라하고 있는데, 자바 공부에 대한 필요성을 느끼고 있습니다다름이 아니라 섹션 2의 POJO에서 스프링 테스트로 전환하며, 기존 테스트 디렉토리의 ProductServiceTest에 대부분 코드가 몰려 있던 구조에서 main 디렉토리에 파일이 많이 늘어서 구조를 맞추는 데 좀 어려웠습니다 중간에 누락된 부분이 있을까요? 만약 같은 분이 계시다면, 클래스명 선택한 다름(드래그로 하이라이트) f5가 이동, f6이 복사로 해당 클래스를 메인에 옮길 수 있습니다(윈도우/리눅스 인텔리제이 기준)확인했습니다! POJO에서 이미 제가 말씀드린 방법으로 리팩토링 수행하셨네요혹시나 헷갈리시는 분들 계실까봐 남겨두겠습니다

안녕하세요.[개발 환경 준비 인증하기] 미션 마감일이 12월 21일까지로 기제되어 있어 미션 제출 자체가 불가한데요. 혹시 어떻게 제출해야 할까요?

안녕하세요,섹션1 미션이 25년 12월 21일까지라고벌써 마감되어 있는데 어떻게 해야 되나요!?아니면 벌써 마감된 건가요?

시각적 회귀 테스트 강의의 Storybook 코드에서 play 함수 안에 matcher를 넣지 않고 userEvent.click(...)만 사용한 이유가 궁금합니다.import { userEvent, within } from '@storybook/testing-library'; import AvailableUsers from '@/pages/login/components/AvailableUsers'; export default { component: AvailableUsers, title: '로그인/사용자 리스트', }; export const Folded = { name: '접힌 상태', }; export const Expanded = { name: '펼친 상태', play: async ({ canvasElement }) => { const canvas = within(canvasElement); await userEvent.click(canvas.getByText('⚠️ 사용 가능한 유저 리스트')); }, };  제가 이해한 바로는, 이 스토리는 storybook에서 아코디언이 펼쳐진 시각적 상태 변화를 보여주기 위한 용도이고, 실제 기능 로직 검증은 Vitest에서 별도의 테스트 코드로 작성하는 방향이라고 생각했습니다. 1. 여기서 play 안에 matcher를 넣지 않은 것은 Storybook을 시각적 상태 확인용으로 사용하려는 의도인가요? 2. 그리고 이 컴포넌트의 동작 검증은 Storybook이 아니라 Vitest에서 담당하도록 역할을 나눈 것으로 이해하면 될까요?3. 실무에서는 보통 storybook을 어디까지 작성하는지 궁금합니다. - 물론 회사마다 다르겠지만, 강의해주시는 강사님 기준으로 의견을 듣고 싶습니다.

// package.json npm list로 확인 결과 react-router@7.13.1 storybook-addon-remix-react-router@6.1.0 react@19.2.4 storybook@10.2.17강의에 있는 내용을 토대로 typescript로 쇼핑몰 storybook 테스트를 진행 중에 React Router pannel에 로깅이 찍히지 않습니다.  github, storybook docs 참고하면서 해봐도 해결이 되지를 않는데... 제 코드는 아래와 같습니다..storybook/main.ts// .storybook/main.ts import type { StorybookConfig } from "@storybook/react-vite"; const config: StorybookConfig = { stories: ["../src/**/*.mdx", "../src/**/*.stories.@(js|jsx|mjs|ts|tsx)"], addons: [ "@chromatic-com/storybook", "@storybook/addon-vitest", "@storybook/addon-a11y", "@storybook/addon-docs", "storybook-addon-remix-react-router", ], framework: "@storybook/react-vite", }; export default config;  .storybook/preview.tsximport type { Preview } from "@storybook/react-vite"; import { withRouter } from "storybook-addon-remix-react-router"; const preview: Preview = { tags: ["autodocs"], parameters: { controls: { matchers: { color: /(background|color)$/i, date: /Date$/i, }, }, a11y: { // 'todo' - show a11y violations in the test UI only // 'error' - fail CI on a11y violations // 'off' - skip a11y checks entirely test: "todo", }, }, decorators: [withRouter], }; export default preview; EmptyNotice.tsximport type { MouseEvent } from "react"; import { useNavigate } from "react-router"; const EmptyNotice = () => { const navigate = useNavigate(); const handleClickBack = (event: MouseEvent<HTMLButtonElement>) => { event.preventDefault(); navigate("/"); }; return ( <div style={{ display: "flex", justifyContent: "center", height: 400, alignItems: "center", flexDirection: "column", }} > <p style={{ fontSize: "50px", fontWeight: 300 }}>텅~</p> <button onClick={handleClickBack} style={{ cursor: "pointer" }}> 홈으로 가기 </button> </div> ); }; export default EmptyNotice;  EmptyNotice.stories.tsximport type { Meta, StoryObj } from "@storybook/react-vite"; import EmptyNotice from "./EmptyNotice"; const meta = { title: "장바구니/EmptyNotice", component: EmptyNotice, } satisfies Meta<typeof EmptyNotice>; export default meta; type Story = StoryObj<typeof meta>; export const Default: Story = { name: "장바구니가 빈 경우", };  AI하고 문답하면서 디버깅 하는데 좀처럼 원인을 못찾겠어서 질문올립니다.

기본 파이썬 명령어의 버전을 바꾸기 위해 심볼링 링크를 업데이트 하려고 하니 permission denied가 뜹니다.  이미 파이참이 설치 되어 있어서 가상환경 외부 의존성을 설치하려고 경로를 맞추려고 하는데 해당 부분을 어디서 진행해야하는지 모르겠습니다.  

안녕하세요, 선생님의 강의 덕에 개인 프로젝트에 테스트를 적용하는 재미를 느끼고있는 수강생입니다. 강의 내용을 참고하여 개인 프로젝트에서 도메인 테스트를 작성하던 중,한 가지 개념적으로 헷갈리는 지점이 있어 질문드립니다. 강의 중“private 메서드는 테스트할 필요도 없고, 해서도 안 된다”라고 말씀 주셨는데,  엔티티 내부에 도메인 정책으로서 private static final 상수와 이를 사용하는 private 검증 로직이 존재하는 경우엔 어떻게 하지...? 라는 궁금증이 생겼습니다.이때 테스트에서는 경계값을 검증해야 하는데,@Entity public class TransactionFile extends BaseEntity { private static final long MAX_FILE_SIZE = 10; // 중략 private static void validateSize(long size) { state(size != 0, "파일 크기는 0보다 커야합니다."); state(size <= MAX_FILE_SIZE*1024*1024, "파일 크기는" + MAX_FILE_SIZE + "MB 이하여야 합니다."); } } 상수가 private 이므로 테스트 코드에서 값을 참조할 수 없습니다.class TransactionFileTest { long fileSize = MAX_FILE_SIZE * 1024 * 1024 - 1; // 테스트에서는 접근 불가 } 결국 궁금한 점은 private 상수를 경계값 테스트 기준으로 사용할 시...□ 단순히 도메인 모델 정책만 지켜지는지 검증하고 경계값 테스트를 안하는게 맞는지 (예 - MIN_VALUE, MAX_VALUE를 써서 그냥 충분히 작은값, 큰값으로 테스트하고 넘기기)□ 아니면 리플렉션을 이용해서 상수 값을 참조해야하는지(강의 중 리플렉션에 대해 부정적으로 말씀해 주셔서, 이런 경우에도 리플렉션을 지양하는 것이 맞는지 아니면 예외적으로 고려할 수 있는 상황인지...) 강의자님의 실무 기준을 듣고싶습니다.

안녕하세요.호기심에 질문 드립니다. CTO로 여러 회사에서 활동하셨던걸로 소개를 받았는데 이중에 성공전인 회사에 입사하셔서성공 궤도에 올리신 회사가 있을까요~?

is_host와 사용자의 캘린더 보유를 모두 사용해야 한다고 생각합니다.개인적으로 호스트가 정해진 서비스라면 모두 고려할 필요는 없지만, 실제 누구나 호스트의 역할을 하게 된다면2가지를 병행해서 사용해야 한다고 판단했습니다. 홍길동이 호스트가 될수도 있고, 게스트도 될수 있습니다.그래서 호스트별로 마스터가 될수 있는 캘린더의 아이디를 저정해서 실제 보유하고 있는 권한이 있는 호스트 인지판단하려고 합니다.

파일삭제에 대한 정책은 있어야 한다고 생각합니다.파일 저장공간에 대한 것은 비용입니다.삭제 주기는 서비스 정책 및 신청약관에 명기해야 합니다.파일 업로드시 YYYY/MM/DD 구성으로 파일 디렉토리를 구성해서 쉽게 일괄 삭제 할수 있게 구성합니다. 부킹데이터를 삭제하면, 파일도 삭제할 것인지 여부해당 서비스가 무료/유료여부에 따라서 달라질것 같습니다.원칙은 삭제해야 하는데, 해당 서비스의 경우 파일은 바로 삭제할것 같습니다.보통 게스트의 개인정보와 관련된 것들이 많을것 같아서 바로 삭제하는 것이 좋습니다.

강의를 수강한 이후 테스트 코드를 짜다가 문득 궁금하여 문의드립니다. 보통 테스트 코드는 입력이 있고, 그것에 대한 출력을 검증하는 것인데 반환 값이 void면 어떻게 테스트 코드를 짜면 되는지 궁금합니다. (예를들어 단순 update문) copilot이나 ai는 verify로 행위 검증을 하던데... 이렇게 하는게 맞는건지, 아니면 void로 반환하는것 자체를 지양하는게 좋은지... 의견을 여쭙고 싶습니다!!!

1) 부킹 파일 삭제 시, 먼저 '삭제 대기'로 해당하는 테이블 행에 표시를 하여 놓고, 일정 기간 후에 정리 작업을 통해 테이블로부터 삭제를 하여주고, 스토리지에서도 해당 파일을 같이 제거해 줍니다.  2) 부킹 삭제 시, 부킹을 먼저 '삭제 대기' 로 테이블 행에 표시를 하여 놓고, 파일들도 마찬 가지로 '삭제 대기'로 유지 시켜줍니다. 일정 기간 후, 부킹 데이터가 삭제 될 때, 같이 해당하는 부킹 파일 레코드 행들을 테이블로 부터 삭제하여주고, 스토리지에서도 물리적으로 제거 해줍니다.  이는 사용자가 실수로 특정 파일 및 부킹을 삭제 할 경우를 대비해 복구 할 시간을 주기 위함입니다. 즉시 물리 삭제를 수행할 경우 DB에는 삭제되었지만 파일이 남거나, 파일은 삭제되었지만 DB 에서는 계속 존재하는 불일치 문제가 발생할 수 있습니다.

게스트 예약 부킹 일정 변경 정책일자와 타임 슬롯 변경을 허용합니다.과거 일자로의 변경은 허용 되지 않습니다. 예약 날짜는 항상 현재 일자 및 시간 보다 미래 이어야 하기 때문입니다.각 호스트 고유의 등록된 타임 슬롯으로만 변경이 허용 가능 합니다. 호스트 A의 캘린더에 지정된 타임 슬롯 이외에 시간을 선택한다면, 호스트와 게스트의 만남이 불가능합니다.호스트의 캘린더에 해당 타임 슬롯의 자리가 비어있다면, 변경이 가능합니다. 그렇지 않다면, 해당 예약 내역 실패 오류를 반환합니다.성공 시나리오 호스트 타임슬롯: 화,목,금 오후 3시 - 4시, 4시 - 5시, 6시 - 7시 (1월 3일~ 1월 10일 다 비어있음) 게스트는 2026년 1월 1일에, 2026년 1월 2일 (금요일) 오후 3시 부킹을 2026년 1월 6일 (화요일) 오후 6시로 변경하려고 합니다.  a) 새 부킹 날짜는 현재 날짜보다 미래 날짜이며,   b) 새 부킹 날짜는 호스트의 타임 슬롯의 일자와 일치하며,  c) 1월 6일 오후 6시에는 자리가 비어있으므로, 일정 변경이 성공하게 됩니다.실패 시나리오들 a) 1. 게스트는 2026년 1월 1일에, 2025년 1월 2일 (금요일) 오후 3시 부킹을 실수로 2025년 12월 30일 (화) 오후 6시로 변경하려고 합니다.새 부킹 날짜는 현재 날짜보다 과거 날짜 이므로 유효 날짜 오류를 반환해줍니다.  b) 1. 게스트는 2026년 1월 1일에, 2025년 1월 5일 (금요일) 오후 3시 부킹을 2026년 1월 5일 (월) 오후 6시로 변경하려고 합니다.새 부킹 날짜는 현재 날짜보다 미래 날짜이므로 첫번째 조건을 통과합니다. 그러나, 호스트의 타임 슬롯 일자들과 맞지 않으므로, 유효하지 않은 타임슬롯 오류를 반환합니다. c) 1. 게스트는 2026년 1월 1일에, 2025년 1월 5일 (금요일) 오후 3시 부킹을 2026년 1월 6일 (화) 오후 6시로 변경하려고 합니다.새 부킹 날짜는 현재 날짜보다 미래 날짜이므로 첫 번째 조건을 통과합니다. 호스트의 타임슬롯과 일치하므로, 두 번째 조건도 통과합니다. 그러나, 호스트의 캘린더에 이미 요청 시간대에 다른 게스트와의 예약이 존재하므로, 이미 존재하는 일자 오류를 반환합니다.