코딩 전 나의 계획

Source: Dev.to

1️⃣ The Strategy (The “Ask”)

Three Critical Questions

• Who is this for? (Target Audience)
  대상은 누구인가? (대상 청중)
• What exact problem am I solving? (Pain Points)
  내가 해결하려는 정확한 문제는 무엇인가? (고충)
• What does success look like? (Definition of Done)
  성공은 어떻게 보이는가? (완료 정의)

Example Case: Digital Marketplace

• Users: Creators selling ebooks, courses, and digital assets.
  사용자: 전자책, 강좌, 디지털 자산을 판매하는 크리에이터.
• Problem: Manual payment verification and insecure file delivery.
  문제: 수동 결제 검증 및 보안이 취약한 파일 전달.
• Success: A creator uploads a file, a user pays via local gateways (e.g., Paystack), the product is delivered instantly, and earnings reflect in a dashboard.
  성공: 크리에이터가 파일을 업로드하고, 사용자가 로컬 결제 게이트웨이(예: Paystack)를 통해 결제하면, 제품이 즉시 전달되고, 수익이 대시보드에 반영된다.

2️⃣ Defining the MVP

• Identity: Authentication with User & Creator roles.
  신원 확인: 사용자와 크리에이터 역할을 가진 인증.
• Management: File upload and storage for creators.
  관리: 크리에이터를 위한 파일 업로드 및 저장.
• Checkout: Integration with local payment gateways.
  결제: 로컬 결제 게이트웨이와 통합.
• Verification: Robust webhook handling for payment status.
  검증: 결제 상태를 위한 견고한 웹훅 처리.
• Delivery: Automated email/secure download links.
  전달: 자동 이메일/보안 다운로드 링크.
• Finances: A wallet system to track creator balances.
  재무: 크리에이터 잔액을 추적하는 지갑 시스템.

3️⃣ System Design (High‑Level Thinking)

시스템 설계 (고수준 사고)

User → API → Backend → Database

4️⃣ Database Design (The “Critical” Step)

데이터베이스 설계 (“핵심” 단계)

-- Users
CREATE TABLE users (
    id          SERIAL PRIMARY KEY,
    email       VARCHAR(255) NOT NULL UNIQUE,
    password    VARCHAR(255) NOT NULL,
    role        VARCHAR(50)  NOT NULL   -- creator or customer
);

-- Products
CREATE TABLE products (
    id          SERIAL PRIMARY KEY,
    creator_id  INTEGER REFERENCES users(id),
    title       VARCHAR(255) NOT NULL,
    price       DECIMAL(10,2) NOT NULL,
    file_url    TEXT NOT NULL
);

-- Orders
CREATE TABLE orders (
    id          SERIAL PRIMARY KEY,
    user_id     INTEGER REFERENCES users(id),
    product_id  INTEGER REFERENCES products(id),
    status      VARCHAR(20) NOT NULL   -- pending, paid, failed
);

-- Transactions
CREATE TABLE transactions (
    id          SERIAL PRIMARY KEY,
    order_id    INTEGER REFERENCES orders(id),
    amount      DECIMAL(10,2) NOT NULL,
    reference   VARCHAR(255) NOT NULL,
    status      VARCHAR(20) NOT NULL
);

-- Wallets
CREATE TABLE wallets (
    creator_id  INTEGER PRIMARY KEY REFERENCES users(id),
    balance     DECIMAL(12,2) DEFAULT 0
);

5️⃣ Offloading Background Tasks

백그라운드 작업 오프로드

• Emails: Sending purchase confirmations.
  이메일: 구매 확인 메일 전송.
• Retries: Handling failed payment verification pings.
  재시도: 실패한 결제 검증 핑 처리.
• Security: Generating expiring, one‑time‑use download links.
  보안: 만료되는 일회용 다운로드 링크 생성.

6️⃣ Security Thinking (Day Zero)

보안 사고 (Day Zero)

• Validation: Strict input sanitization to prevent injection.
  검증: 인젝션 방지를 위한 엄격한 입력 정화.
• Auth: Protecting endpoints with JWT or session‑based security.
  인증: JWT 또는 세션 기반 보안으로 엔드포인트 보호.
• Storage: Using signed URLs to ensure only paid users can access files.
  스토리지: 서명된 URL을 사용해 결제한 사용자만 파일에 접근하도록 보장.
• Rate Limiting: Protecting APIs from brute‑force or DDoS attempts.
  속도 제한: 무차별 대입 또는 DDoS 시도로부터 API 보호.

7️⃣ Infrastructure & Deployment

인프라 및 배포

• Containerization: Docker for local development and production consistency.
  컨테이너화: 로컬 개발 및 프로덕션 일관성을 위한 Docker.
• Hosting: Scalable providers like AWS or DigitalOcean.
  호스팅: AWS 또는 DigitalOcean과 같은 확장 가능한 제공업체.
• Storage: S3 or Cloudinary for reliable asset hosting.
  스토리지: 신뢰할 수 있는 자산 호스팅을 위한 S3 또는 Cloudinary.

---

What do you think? Do you have a different planning process, or do you prefer to “build and break” as you go? Let’s discuss in the comments!
어떻게 생각하시나요? 다른 계획 프로세스가 있나요, 아니면 진행하면서 “구축하고 깨뜨리기”를 선호하시나요? 댓글로 논의해 주세요!