먼저 관련 데이터들을 단계별로 삭제

from sentry.models import Organization, Project, Release, Group, Event, Team

orgs_to_delete = Organization.objects.exclude(id=1)

for org in orgs_to_delete:
    print(f"\n=== {org.name} (ID: {org.id}) 삭제 시작 ===")

    # 프로젝트별로 관련 데이터 삭제
    projects = Project.objects.filter(organization=org)
    for project in projects:
        print(f"  프로젝트 삭제: {project.name}")

        # Groups (이슈들) 삭제
        groups = Group.objects.filter(project=project)
        group_count = groups.count()
        if group_count > 0:
            print(f"    Groups 삭제: {group_count}개")
            groups.delete()

        # Events 삭제
        events = Event.objects.filter(project_id=project.id)
        event_count = events.count()
        if event_count > 0:
            print(f"    Events 삭제: {event_count}개")
            events.delete()

    # Releases 삭제
    releases = Release.objects.filter(organization=org)
    release_count = releases.count()
    if release_count > 0:
        print(f"  Releases 삭제: {release_count}개")
        releases.delete()

    # Teams 삭제
    teams = Team.objects.filter(organization=org)
    team_count = teams.count()
    if team_count > 0:
        print(f"  Teams 삭제: {team_count}개")
        teams.delete()

    # Projects 삭제
    project_count = projects.count()
    if project_count > 0:
        print(f"  Projects 삭제: {project_count}개")
        projects.delete()

    # 마지막으로 Organization 삭제
    print(f"  Organization 삭제: {org.name}")
    org.delete()
    print(f"  완료: {org.name}")  

사용자 삭제

``` from django.contrib.auth import get_user_model

User = get_user_model()

삭제할 사용자 확인

user_to_delete = User.objects.get(id=3) print(f"삭제할 사용자: {user_to_delete.email} (ID: {user_to_delete.id})")

사용자 삭제

user_to_delete.delete() print(f"삭제 완료: {user_to_delete.email}")

삭제 후 확인

remaining_users = User.objects.all() print("\n=== 남은 사용자들 ===") for user in remaining_users: print(f"User: {user.email} (ID: {user.id})")

1. df - 디스크 사용량 확인

   df -h # 사람이 읽기 쉬운 형태로 표시 df -T # 파일시스템 타입도 함께 표시 df -i # inode 사용량 확인

2. lsblk - 블록 디바이스 트리 구조로 확인

   lsblk # 기본 트리 구조 lsblk -f # 파일시스템 정보 포함 lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE

3. fdisk - 파티션 테이블 확인

   sudo fdisk -l # 모든 디스크 파티션 목록 sudo fdisk -l /dev/sda # 특정 디스크만 확인

   🔧 상세 하드웨어 정보

4. lshw - 하드웨어 상세 정보

   sudo lshw -class disk # 디스크 하드웨어만 sudo lshw -class storage # 스토리지 컨트롤러 포함

5. hwinfo - 하드웨어 검색 도구

   sudo hwinfo --disk # 디스크 정보만 sudo hwinfo --short # 간략한 전체 하드웨어 정보

6. smartctl - 디스크 건강 상태 (SMART)

   sudo smartctl -i /dev/sda # 디스크 기본 정보 sudo smartctl -A /dev/sda # SMART 속성값들 sudo smartctl -t short /dev/sda # 짧은 자가진단 테스트

   💾 실시간 성능 모니터링

7. iostat - I/O 통계

   iostat -x 1 # 1초마다 상세 I/O 통계 iostat -h # 사람이 읽기 쉬운 형태

8. iotop - 실시간 I/O 모니터링

   sudo iotop # 프로세스별 I/O 사용량 sudo iotop -o # 실제 I/O 발생하는 것만

9. dstat - 종합 시스템 통계

   dstat -d # 디스크 통계만 dstat -D sda # 특정 디스크만

   🔍 파일시스템 분석

10. du - 디렉터리 사용량

    du -sh /home/* # 홈 디렉터리별 사용량 du -sh * | sort -hr # 크기순 정렬

11. ncdu - 인터랙티브 디스크 사용량 분석

    ncdu / # 루트부터 탐색 ncdu /home # 특정 디렉터리만

sudo mkfs.ext4 /dev/xvdb

sudo mkdir -p /mnt/data sudo mount /dev/xvdb /ssd echo '/dev/xvdb /ssd ext4 defaults 0 0' | sudo tee -a /etc/fstab

lsblk -f sudo fdisk -l /dev/xvdb

sudo mount /dev/xvdb1 /ssd

sudo cp -av /ssd/* /llama/ -a: 아카이브 모드 (권한, 소유권, 타임스탬프 등 모든 속성 유지) -v: 상세 출력 (어떤 파일이 복사되고 있는지 확인 가능)

watch -n 1 du -sh /llama

df -h . du -sh ./*

1. 모델 다운로드

mkdir -p /data/Llama4/Q4_K_M cd /data/Llama4/Q4_K_M

wget https://huggingface.co/unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF/resolve/main/Q4_K_M/Llama-4-Scout-17B-16E-Instruct-Q4_K_M-0000{1..2}-of-00002.gguf

2. Llama.cpp

apt -y install cmake libopenblas-dev g++ libcurl4-openssl-dev git clone https://github.com/ggerganov/llama.cpp.git

cd llama.cpp mkdir build cd build cmake ..

cmake --build . --config Release

3. 분할된 파일 합치기

cd bin

./llama-gguf-split --merge
/data/Llama4/Q4_K_M/Llama-4-Scout-17B-16E-Instruct-Q4_K_M-00001-of-00002.gguf
/data/Llama4/Q4_K_M/Llama-4-Scout-17B-16E-Instruct-Q4_K_M.gguf

4. LLM 실행

./llama-cli -m /data/Llama4/Q4_K_M/Llama-4-Scout-17B-16E-Instruct-Q4_K_M.gguf -p "오늘은 며칠이야?"

./llama-server -m /data/Llama4/Q4_K_M/Llama-4-Scout-17B-16E-Instruct-Q4_K_M.gguf --host 0.0.0.0 --port 8080

curl http://{서버IP}:8080/completion -H "Content-Type: application/json" -d '{ "prompt": "오늘은 며칠이야?", "n_predict": 100 }' | jq

도커 gpu

distribution=$(. /etc/os-release;echo $ID$VERSION_ID) # ubuntu20.04 → ubuntu20.04

curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/libnvidia-container/ubuntu22.04/libnvidia-container.list |
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update sudo apt install -y nvidia-container-toolkit

sudo nvidia-ctk runtime configure --runtime=docker

sudo systemctl restart docker

docker run --rm --gpus all nvidia/cuda:12.3.2-base-ubuntu22.04 nvidia-smi

gpu

sudo lshw -C system sudo lshw -C display

cat /proc/cpuinfo

lspci | grep -i VGA lspci | grep -E "VGA|3D|Display" lspci -v

apt search nvidia-driver

nvidia-smi --query | fgrep 'Product Name watch nvidia-smi

sudo ubuntu-drivers autoinstall

sudo apt-get update sudo apt-get install -y curl ca-certificates gnupg

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list |
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' |
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update sudo apt-get install -y nvidia-container-toolkit

sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker

docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu20.04 nvidia-smi

회사의 비즈니스 모델은 간단함. 맛있는 빵을 만들어 고객에게 전하는 것.

크리스마스 기획전에서 2단짜리 케이스를 한정 수량으로 판매. 프로젝트는 성공했지만 예상치 못한 문제 발생. 2단 케이크라 서울 지역 외 배송이 불가한데 대전에 사는 한 어머니의 주문이 옴. CS 담당자가 “서울 지역 외에는 배송이 불가하다" 안내. 이를 보던 다른 담당자가 “맛있는 빵을 만들어 고객에게 전한다”라는 원칙에 근거해 다시 응대.

문의 내용은 밀가루 알레르기가 있어 케이크를 못 먹는 아이를 키우고 있는데 우리 회사 케이크는 먹을 수 있다는 것. 이번 크리스마스만큼은 꼭 케이크를 선물해 주고 싶다는 요청. 퀵 서비스 업체의 원칙이 아니라 우리 회사 원칙에 따라 고객에게 전할 방법 모색. 퀵 배송으로 가능한 지역까지 배달하고 중간지점에서 어머니가 픽업하는 방법으로 2단 케이크 전달. 이 고객은 충성 고객이 되어 서울에 올 때마다 수십만 원어치 빵을 구매.

모든 구성원이 “맛있는 빵을 만들어 고객에게 전한다” 원칙으로 응대하니 이와 같은 충성 고객 다수 확보. 지방에서 베이커리 카페를 운영하는 사업가들과 협업으로 회사 크게 성장. 단순히 지침만 따르는 수동적인 직원은 고객의 니즈를 제대로 이해하지 못함. 이에 관리자는 자연히 잔소리가 많아짐.

반면 회사의 비즈니스 모델을 이해해 주도적으로 일하는 직원은 스스로 판단해 고객에게 최상의 서비스 제공 가능. 기획, 개발, 디자인, 마케팅, CS 포함 모든 구성원이 회사의 비즈니스 모델에 대한 근본적인 이해를 갖고 있으면 주도적인 업무 수행으로 효율을 높일 수 있음. 예를 들어 “맛있는 빵을 만들어 고객에게 전하는 것”라는 원칙을 갖고 있으면 마케팅 메세지를 뽑는 것도 간단. 이 경우 할인이나 1+1 프로모션은 원칙에 어긋남. 우리가 어떻게 맛있는 빵을 만들기 위해 노력하고 고객에게 전하려고 애쓰는지를 보여주는 데만 집중하면 됨.

https://eopla.net/magazines/21234

피터의 법칙

IT 업계가 빠르게 성장하는 만큼, 역량 부재 상태로 승진된 관리자가 조직 성과를 저해하는 현실을 적나라하게 보여준다. 그러나 구글이나 인텔, 일부 스타트업 사례가 증명하듯이, 인사제도 개선(역량 기반 승진·듀얼 트랙)과 체계적인 매니저 교육을 병행한다면 이러한 부작용을 상당히 줄일 수 있다. 신임 매니저라면 “승진이 곧 끝이 아니라, 본격적인 리더십 학습의 시작”이라는 사실을 명심하고, 꾸준히 성장 마인드셋을 유지하기 바란다. 결국, 피터의 법칙에 휘말릴 것인지 넘어서 성장할 것인지는 조직과 개인이 얼마나 적극적으로 학습하고 개선하려 하는가에 달려 있다.

https://brunch.co.kr/@unicornjungle/146

핵심인재

1. 핵심인재가 하고 있는 일에 대해서 책임과 소명을 가지고 일할만큼의 전권을 가지고 있는가?
2. 성과를 냈을 때 해당 핵심인재가 원하는 만큼의 보상을 타 업체보다 줄 수 있는가?
3. 회사의 성장 그리고 개인도 끊임없이 성장을 추구할 수 있는가?
4. 몰입할 수 있는 조직문화와 환경을 제공하고 있는가?

https://eopla.net/magazines/12481

게이미피케이션

1. 도전목표 : 사용자에게 미션이나 도전 과제를 제시하고 도전 의식을 자극해 재미와 동시에 성취감을 제공
2. 경쟁관계 : 사용자들 간의 사회적인 경쟁 관계를 형성하고, 사용자가 자신과 타 사용자와의 상태를 직관적으로 비교
3. 보상 : 여러 도전 과제들을 달성하면 사용자에게 보상을 제공, 그저 겉치레에 불과하다는 불쾌한 경험을 제공하지 않는 것
4. 성취 : 사용자의 장기적인 도전과 경쟁을 이어나갈 핵심 동력

https://ditoday.com/lets-get-it-right-gamification-ux/

랜딩페이지

1. CTA가 직관적이고 명확한가?
2. 이 서비스가 도대체 뭐지? (Hero) 5초 안에 이 서비스가 어떤 서비스인지 스캔 가능
3. 이게 나에게 맞는 서비스인가? (Problem & Solution)
4. 이 사이트가 신뢰할만한가?
5. 누가 실제로 사용 중인가? (Testimonials)
6. 그래서 내가 얻는게 무엇인가? (Benefit)
7. 어디서 도움을 받을 수 있는가?

No MVP , MVT / MLP

sudo sh -c "echo 1 > /proc/sys/vm/drop_caches"

iostat
uptime htop

sudo powertop cat /sys/class/power_supply/BAT1/status upower -i /org/freedesktop/UPower/devices/battery_BAT1

sudo apt install sysbench sysbench cpu --cpu-max-prime=20000 run sysbench memory run sysbench fileio --file-total-size=1G prepare sysbench fileio --file-total-size=1G --file-test-mode=seqrd run

#!/bin/bash

echo "CPU TEST"
sysbench cpu --threads=4 --time=10 run

echo "MEMORY TEST"
sysbench memory --memory-block-size=1M --memory-total-size=10G run

echo "DISK I/O TEST"
sysbench fileio --file-test-mode=seqrd --file-total-size=2G prepare
sysbench fileio --file-test-mode=seqrd --file-total-size=2G --time=10 run
sysbench fileio --file-test-mode=seqrd --file-total-size=2G cleanup

echo "NETWORK TEST"
iperf3 -c <target IP>

sysbench cpu, stress-ng, Geekbench, 7zip benchmark sysbench memory, mbw, stream, stress-ng sysbench fileio, fio, dd, ioping ioping, fio bonnie++, fio iperf3, ping, netperf

sysbench --threads=N, stress-ng, ab, wrk stress-ng, sysbench, locust, wrk wrk, ab, bombardier lmbench, sysbench phoronix-test-suite, unixbench

• 시스템 리소스 사용량: CPU 사용률 (top, htop, mpstat) 메모리 사용량 (free, vmstat) 디스크 사용량 (df -h, du) I/O 활동 (iostat, iotop)

• 네트워크 상태: 네트워크 트래픽 (iftop, nethogs) 연결 상태 (netstat, ss) 패킷 손실 (ping, mtr)

• 시스템 로그: 시스템 로그 (/var/log/syslog 또는 /var/log/messages) 커널 로그 (dmesg) 서비스별 로그 파일

• 프로세스 모니터링: 좀비 프로세스 확인 비정상적인 CPU/메모리 사용 프로세스 식별

• 스토리지 상태: SMART 상태 확인 (smartctl) 파일시스템 무결성 (fsck - 정기적인 확인)

• 보안 관련: 실패한 로그인 시도 (auth.log) 열린 포트 확인 (netstat -tulpn) 예상치 못한 사용자 활동

• 백업 상태: 백업 작업 성공/실패 로그 백업 공간 사용량

sudo mkdir -p /usr/local/lib/docker/cli-plugins sudo mv ~/.docker/cli-plugins/docker-compose /usr/local/lib/docker/cli-plugins/

curl -SL https://github.com/docker/compose/releases/download/v2.27.1/docker-compose-linux-x86_64 -o ~/.docker/cli-plugins/docker-compose

chmod +x ~/.docker/cli-plugins/docker-compose

1. 기존 docker-compose 제거 sudo apt remove docker-compose -y

2. 디렉토리 생성 mkdir -p ~/.docker/cli-plugins

3. 최신 버전 다운로드 (v2.27.1 기준) curl -SL https://github.com/docker/compose/releases/download/v2.27.1/docker-compose-linux-x86_64 -o ~/.docker/cli-plugins/docker-compose

4. 실행 권한 부여 chmod +x ~/.docker/cli-plugins/docker-compose

5. docker-compose v2 버전 확인 docker compose version

docker compose version

mkdir -p auth

htpasswd -Bbn username password > auth/htpasswd docker run --entrypoint htpasswd httpd:2 -Bbn username password > auth/htpasswd

sudo sh -c "htpasswd -Bbn username 'password!' > auth/htpasswd"

프로젝트 정의서

개요

프로젝트명

목표

사용자 정의

요구사항

요구사항 정의서 참고

시스템 아키텍처

아키텍처 개요

• 프론트엔드:
• 백엔드:
• 데이터베이스:

모듈 구성

• 프론트엔드:
• 백엔드:
• 데이터베이스:

인터페이스 설계

• 프론트엔드-백엔드 인터페이스:
• 백엔드-데이터베이스 인터페이스:

설계 상세

사용자 스토리

구현 계획

개발 환경

• 프론트엔드: React, TypeScript,
• 백엔드:
• 데이터베이스:
• 도구: Visual Studio Code, Git

개발 일정

• 요구사항 분석 및 설계
• UI/UX 디자인
• 백엔드 개발
• 프론트엔드 개발
• 통합 및 테스트
• 배포 및 유지보수

자원 계획

• 프론트엔드 개발자: 3명

테스트 계획

품질 보증

코드 리뷰, 자동화 테스트(E2E)

배포 계획

배포 전략

스테이징 환경에서 충분한 테스트 후 프로덕션 환경에 배포

유지보수 계획

버그 수정 및 기능 개선을 위한 정기 업데이트

문서화

사용자 매뉴얼

시스템 사용법을 상세히 설명하는 매뉴얼 작성

개발자 문서

시스템 아키텍처, API 명세서, 코드 설명서 작성

용어 정의

주요 용어와 약어 정의

API 및 인프라 협업 가이드라인

프론트엔드

• API 호출 및 상태 관리

  • api 호출하기 전에 무조건 useEffect 폭주하는 거 없는지 확인하고 호출해주세요. (서버가 아파해요)
  • 불필요한 API 호출을 피하기 위해 useEffect 등 훅 사용 시 의존성 배열을 신중하게 관리해주세요
  • 빠른 연속 호출(예: 버튼 클릭 시)에는 디바운스(또는 스로틀)를 적용하여 서버 과부하를 방지해주세요
  • 응답 데이터 캐싱

    - 코드 내 직접 캐싱보다는 react-query와 같은 라이브러리의 응답 캐싱 기능을 활용하여 최신 데이터를 하지 말아주세요. ( 에디터 부분 한정 )
    - 에디터 같은 동시 편집도구에서 캐시하면 동기화 문제가 발생할 수 있어요.

• 파일 업로드 구현

    - presigned URL 사용하니 백엔드 문서 참고해서 업로드 기능 구현해주세요.

• 배포 및 CDN 활용

    - 배포 시 CloudFront + S3 또는 Cloudflare와 같은 CDN 솔루션을 활용해주세요.
    - 기존의 EC2 + Nginx 방식에 의존하지 않는 것이 좋을 것 같습니다. (자신있으면 해도 상관없어요! ex) 모니터링, 로그 분석 등등등 )

백엔드

• 입력 데이터 검증

  • 프론트엔드에서 전달받은 데이터에 대해 반드시 철저한 검증을 실시하여 보안을 강화.

• REST API 규칙

  • HATEOAS 등 과도한 규칙 적용보다는 기본 REST 규칙을 준수.
  • 응답 상태코드는 상황에 맞게 200, 201, 204, 400, 401, 403, 404, 429(필요시 415 등)로 명확히 구분.
  • GET 요청은 Body 없이 처리할 것.
  • PUT 요청은 멱등성 원칙을 고려하되, 과도한 오버엔지니어링은 피할 것.

• API 응답 구조 (flat vs. nested)

  • 프론트엔드와의 협의 하에 필요한 데이터만 전달하여 불필요한 네트워크 부하를 줄이고 캐시 관리에 용이하도록 설계.
  • 혼합 방식 사용 시 프론트엔드에서 과도한 API 호출 없이 단일 응답으로 필요한 정보를 받을 수 있도록 고려.

• API 응답 포맷 (Response 배열, 페이지 처리)

  • 응답 형식은 프론트엔드와 협의하여 단일 API 호출로 필요한 데이터를 제공할 수 있도록 설계할 것.
  • 예: 단일 객체 내에 blogs: [] 배열 및 페이지 정보를 포함.

• 읽기 전용 API 설계

  • 모듈 분리 후 읽기 전용 엔티티를 별도로 설계하여 성능 및 확장성을 고려할 것.

  • Jooq, CQRS, 또는 replica DB 활용 등 읽기 전용 환경 구축 방안을 적극 검토.

    200, { [ {}, {} ] }
    vs
    200, { "result": [ {}, {} ] }

• ResponseEntity 사용

  • 기본적으로 ResponseEntity를 사용할 필요가 없으나, 특별한 케이스(예외 처리 등)에서 유용하게 활용할 수 있음.

• Service Entity 반환

  • OSIV 사용 여부와 관계없이, 직접 Service의 Entity를 반환하는 것은 문제가 될 수 있지만 적용함.
  • OSIV를 비활성화한 경우라 하더라도 반환 객체의 범위를 명확히 관리할 것.

• 보안 및 인증 (JWT)

  • JWT 기반 인증을 기본으로 하고, Access/Refresh Token 관리 정책(예: RefreshToken은 Cookie, AccessToken은 Response Body)에 따라 구현.
  • 필요 시 Redis 등 캐시 솔루션을 활용하여 세션 및 토큰 관리를 최적화.

• 파일 업로드 처리

  • 서버 리소스 절감을 위해 멀티파트 파일 업로드 대신 presigned URL 방식을 적극 활용.
  • 파일 업로드의 단계(초기화, 중간 발송, 확인, 중단, 삭제)를 구현하며 관련 기술 블로그 참고.

• S3 및 이미지 관리

  • S3 관리 주체(백엔드/프론트엔드)와 역할 분담을 명확히 하고, 이미지 압축 작업의 책임 범위를 결정.
  • 이미지 업로드는 presigned URL을 통한 직접 업로드를 적용하며, 서버에서 최종 검증 및 ID 연동 처리.

• 캐싱 및 트래픽 관리

  • 캐시 전략(캐시 쇄도, 지터 등) 관련 이슈를 사전에 논의하여 전체 시스템에 영향을 주지 않는 방향으로 설정.
  • 캐시 트래픽 관련 참고 자료를 기반으로 최적 방안을 마련.

API 명세서

/api/v1/projects/{id}

• GET

  • 설명: 지정된 ID를 가진 프로젝트의 세부 정보를 조회합니다. 프로젝트 이름, 활성 상태, 데이터, 버전 등의 정보를 반환합니다.

  • 파라미터: id (path, 필수, int64) - 조회할 프로젝트의 고유 ID

  • 응답: 200 OK - ProjectDetailResponse

      {
        "id": 1,
        "name": "Sample Project",
        "active": true,
        "data": "{\\"key\\": \\"value\\"}", // 미정
        "version": 2,
        "lastAccessedAt": "2025-03-19T10:00:00Z",
        "createdAt": "2025-01-01T09:00:00Z",
        "updatedAt": "2025-03-18T15:30:00Z"
      }
    

• PUT

  • 설명: 지정된 ID를 가진 프로젝트의 정보를 업데이트합니다. 이름이나 데이터 등의 필드를 수정할 수 있습니다.

  • 파라미터: id (path, 필수, int64) - 업데이트할 프로젝트의 고유 ID

  • 요청 본문: ProjectUpdateRequest

      {
        "name": "Updated Project",
        "data": "{\\"newKey\\": \\"newValue\\"}"
      }
    

  • 응답: 200 OK - ProjectDetailResponse

      {
        "id": 1,
        "name": "Updated Project",
        "version": 3,
        "createdAt": "2025-01-01T09:00:00Z",
        "updatedAt": "2025-03-19T12:00:00Z"
    

  • 응답: 409 Conflict - 버전 충돌이 발생한 경우 (버전 3→2 또는 2→4 등)

      {
          "message": "meeor message",
          "exceptionCode": "error code"
      }

• DELETE

  • 설명: 지정된 ID를 가진 프로젝트를 삭제합니다.
  • 파라미터: id (path, 필수, int64) - 삭제할 프로젝트의 고유 ID
  • 응답: 200 OK - 응답 본문 없음

/api/v1/templates/suggest

• POST

  • 설명: 주어진 텍스트(예: 기사)를 기반으로 적합한 템플릿을 추천합니다. 템플릿 추천 시스템을 활용한 기능입니다.

  • 요청 본문: TemplateSuggestRequest

      {
        "article": "This is a sample article about technology."
      }
    

  • 응답: 200 OK - TemplateSuggestResponse

      {
        "items": [
          {
            "id": 101,
            "priority": 1,
            "data": {
              "name": "Tech Template",
              "category": "Social",
              "size": {
                "width": 1920,
                "height": 1080
              },
              "background": {
                "id": 10,
                "name": "Tech BG",
                "priority": 1,
                "type": "Image",
                "fileUrl": "<http://example.com/tech-bg.jpg>",
                "size": {
                  "width": 1920,
                  "height": 1080
                },
                "createdAt": "2025-01-01T00:00:00Z",
                "updatedAt": "2025-01-01T00:00:00Z"
              },
              "avatar": {
                "id": 20,
                "name": "Tech Avatar",
                "priority": 2,
                "fileUrl": "<http://example.com/tech-avatar.png>",
                "createdAt": "2025-01-01T00:00:00Z",
                "updatedAt": "2025-01-01T00:00:00Z"
              }
            },
            "createdAt": "2025-01-01T00:00:00Z",
            "updatedAt": "2025-01-01T00:00:00Z"
          }
        ],
        "_info": {
          "category": {
            "id": 1,
            "name": "Social"
          }
        }
      }
    

/api/v1/tasks/{taskId}/retry

• POST

  • 설명: 지정된 작업(task)을 재시도합니다. 실패한 작업을 다시 실행하거나 재처리할 때 사용됩니다.

  • 파라미터: taskId (path, 필수, int64) - 재시도할 작업의 고유 ID

  • 응답: 200 OK - TaskResponse

      {
        "id": 50,
        "projectId": 1,
        "jobId": "job-12345",
        "type": "VIDEO",
        "status": "PENDING",
        "output": {},
        "retryCount": 2,
        "createdAt": "2025-03-18T10:00:00Z",
        "updatedAt": "2025-03-19T12:00:00Z"
      }
    

/api/v1/projects

• GET

  • 설명: 모든 프로젝트 목록을 조회합니다. 프로젝트의 기본 정보(이름, 활성 상태 등)를 반환합니다.

  • 응답: 200 OK - ListResponseProjectResponse

      {
        "data": [
          {
            "id": 1,
            "name": "Project A",
            "active": true,
            "version": 1,
            "lastAccessedAt": "2025-03-19T10:00:00Z",
            "createdAt": "2025-01-01T09:00:00Z",
            "updatedAt": "2025-03-18T15:00:00Z"
          },
          {
            "id": 2,
            "name": "Project B",
            "active": false,
            "version": 2,
            "lastAccessedAt": "2025-03-15T14:00:00Z",
            "createdAt": "2025-02-01T09:00:00Z",
            "updatedAt": "2025-03-16T10:00:00Z"
          }
        ]
      }
    

• POST

  • 설명: 새로운 프로젝트를 생성합니다. 생성된 프로젝트의 세부 정보를 반환합니다.

  • 응답: 200 OK - ProjectDetailResponse

      {
        "id": 3,
        "name": "New Project",
        "active": true,
        "data": "{\\"key\\": \\"value\\"}",
        "version": 1,
        "lastAccessedAt": "2025-03-19T12:00:00Z",
        "createdAt": "2025-03-19T12:00:00Z",
        "updatedAt": "2025-03-19T12:00:00Z"
      }
    

/api/v1/auth/refresh

• POST

  • 설명: 리프레시 토큰을 사용하여 새로운 액세스 토큰을 발급받습니다. 인증 연장을 위해 사용됩니다.

  • 응답: 200 OK - LoginResponse

      {
        "accessToken": "new-access-token-123",
        "refreshToken": "new-refresh-token-456"
      }
    

/api/v1/auth/logout

• POST
  • 설명: 현재 사용자의 세션을 종료하고 로그아웃합니다.
  • 응답: 204 No Content - 응답 본문 없음

/api/v1/auth/login

• POST

  • 설명: 사용자 이름과 비밀번호를 사용하여 로그인하고 인증 토큰을 발급받습니다.

  • access token과 refesh token을 응답으로 반환하며 쿠키에 refresh token을 설정합니다.

  • 요청 본문: LoginRequest

      {
        "username": "user@example.com",
        "password": "securepassword123"
      }
    

  • 응답: 200 OK - LoginResponse

      {
        "accessToken": "access-token-789",
        "refreshToken": "refresh-token-101"
      }
    

/api/v1/account/register

• POST

  • 설명: 새로운 사용자 계정을 등록합니다. 이메일, 비밀번호, 이름 등의 정보를 받아 계정을 생성합니다.

  • 요청 본문: RegisterRequest

      {
        "email": "newuser@example.com",
        "code": "ABC123",
        "password": "newpassword456",
        "name": "John Doe",
        "nickname": "johndoe",
        "phone": "123-456-7890"
      }
    

  • 응답: 200 OK - RegisterResponse

      {
        "memberId": 1001
      }
    

/api/v1/account/register/verify-email

• POST

  • 설명: 계정 등록 시 이메일 인증을 수행합니다. 이메일과 인증 코드를 확인합니다.

  • 요청 본문: VerifyEmailRequest

      {
        "email": "newuser@example.com",
        "code": "ABC123"
      }
    

  • 응답: 204 No Content - 응답 본문 없음

/api/v1/account/register/check-email

• POST

  • 설명: 이메일 인증을 시도합니다. 요청한 이메일로 인증 메일을 보냅니다.

  • 요청 본문: CheckEmailRequest

      {
        "email": "newuser@example.com"
      }
    

  • 응답: 204 No Content - 응답 본문 없음

/api/v1/templates

• GET

  • 설명: 모든 템플릿 목록을 조회합니다. 카테고리 ID를 선택적으로 지정하여 필터링할 수 있습니다.

  • 파라미터: categoryId (query, 선택, int32) - 필터링할 카테고리 ID

  • 응답: 200 OK - ListResponseTemplateResponse

      {
        "data": [
          {
            "id": 101,
            "priority": 1,
            "data": {
              "name": "Social Media Template",
              "category": "Social",
              "size": {
                "width": 1080,
                "height": 1080
              },
              "background": {
                "id": 10,
                "name": "Social BG",
                "priority": 1,
                "type": "Image",
                "fileUrl": "<http://example.com/social-bg.jpg>",
                "size": {
                  "width": 1080,
                  "height": 1080
                },
                "createdAt": "2025-01-01T00:00:00Z",
                "updatedAt": "2025-01-01T00:00:00Z"
              },
              "avatar": {
                "id": 20,
                "name": "Social Avatar",
                "priority": 2,
                "fileUrl": "<http://example.com/social-avatar.png>",
                "createdAt": "2025-01-01T00:00:00Z",
                "updatedAt": "2025-01-01T00:00:00Z"
              }
            },
            "createdAt": "2025-01-01T00:00:00Z",
            "updatedAt": "2025-01-01T00:00:00Z"
          }
        ]
      }
    

/api/v1/templates/{id}

• GET

  • 설명: 지정된 ID를 가진 템플릿의 세부 정보를 조회합니다.

  • 파라미터: id (path, 필수, int64) - 조회할 템플릿의 고유 ID

  • 응답: 200 OK - TemplateResponse

      {
        "id": 101,
        "priority": 1,
        "data": {
          "name": "Social Media Template",
          "category": "Social",
          "size": {
            "width": 1080,
            "height": 1080
          },
          "background": {
            "id": 10,
            "name": "Social BG",
            "priority": 1,
            "type": "Image",
            "fileUrl": "<http://example.com/social-bg.jpg>",
            "size": {
              "width": 1080,
              "height": 1080
            },
            "createdAt": "2025-01-01T00:00:00Z",
            "updatedAt": "2025-01-01T00:00:00Z"
          },
          "avatar": {
            "id": 20,
            "name": "Social Avatar",
            "priority": 2,
            "fileUrl": "<http://example.com/social-avatar.png>",
            "createdAt": "2025-01-01T00:00:00Z",
            "updatedAt": "2025-01-01T00:00:00Z"
          }
        },
        "createdAt": "2025-01-01T00:00:00Z",
        "updatedAt": "2025-01-01T00:00:00Z"
      }
    

/api/v1/templates/categories

• GET

  • 설명: 템플릿 카테고리 목록을 조회합니다. 카테고리 ID와 이름을 반환합니다.

  • 응답: 200 OK - ListResponseTemplateCategoryDto

      {
        "data": [
          {
            "id": 1,
            "name": "Social"
          },
          {
            "id": 2,
            "name": "Politic"
          },
          {
            "id": 3,
            "name": "Economy"
          }
        ]
      }
    

/api/v1/tasks

• GET

  • 설명: 모든 작업(task) 목록을 조회합니다. 작업 상태, 출력물 등의 정보를 포함합니다.

  • 응답: 200 OK - ListResponseTaskResponse

      {
        "data": [
          {
            "id": 50,
            "projectId": 1,
            "jobId": "job-12345",
            "type": "VIDEO",
            "status": "SUCCESS",
            "output": {},
            "retryCount": 0,
            "createdAt": "2025-03-18T10:00:00Z",
            "updatedAt": "2025-03-18T12:00:00Z"
          },
          {
            "id": 51,
            "projectId": 2,
            "jobId": "job-67890",
            "type": "VIDEO",
            "status": "FAILED",
            "output": {},
            "retryCount": 1,
            "createdAt": "2025-03-18T14:00:00Z",
            "updatedAt": "2025-03-19T10:00:00Z"
          }
        ]
      }
    

/api/v1/tasks/{taskId}

• GET

  • 설명: 지정된 ID를 가진 작업의 세부 정보를 조회합니다.

  • 파라미터: taskId (path, 필수, int64) - 조회할 작업의 고유 ID

  • 응답: 200 OK - TaskResponse

      {
        "id": 50,
        "projectId": 1,
        "jobId": "job-12345",
        "type": "VIDEO",
        "status": "SUCCESS",
        "output": {},
        "retryCount": 0,
        "createdAt": "2025-03-18T10:00:00Z",
        "updatedAt": "2025-03-18T12:00:00Z"
      }
    

/api/v1/members/my

• GET

  • 설명: 현재 로그인한 사용자의 프로필 정보를 조회합니다. 회원 ID와 이메일을 반환합니다.

  • 응답: 200 OK - MyProfileResponse

      {
        "memberId": 1001,
        "email": "user@example.com"
      }
    

위 내용은 각 엔드포인트에 대한 설명과 응답의 JSON 포맷 예시를 포함합니다. 요청 본문이 필요한 경우에는 그에 맞는 예시도 추가했습니다. 추가적인 수정이나 더 구체적인 예시가 필요하면 말씀해주세요!

1. 요구사항 세분화
2. 세분화된 모듈 단위 개발
3. 유닛테스트를 통한 구현 검증
4. 모듈간 의존성 파악
5. 의존성 파악을 통한 수정범위 최소화
6. 수정 시, 유닛테스트를 통한 사이드 이펙트 검출

요구사항 분석 : 5Ws 1H / 5Ws / 6Ws

• 무엇을 만들어야 하는지 (What?)
• 왜 하는 것인지 (Why?)
• 언제까지 해야 하는 것인지 (When?)
• 개발 과정에 참여자는 누구인지 (Who?)
• 개발 프로덕트는 어디에 사용되나 (Where?)
• 어떻게 만들 것인가? (How?)

요구사항 세부 분석

• 자료 흐름도 Data Flow Diagram
• 유즈케이스 Use Case Diagram
• 상태 전이도 State Transition Diagram
• 자료 사전 Data Dictionary
• 소단위 명세서 Mini Specification
• 개체 관계도 Entity Relation Diagram

유닛테스트 (Pass)

• Test Driven Development (TDD)
• Jest

• 리액트 테스팅 패턴 : UI 인터렉션 단위 검증
  • Arrange
  • Act
  • Assert

조직간 동기맞추기 - 배포/형상관리

형상관리 - Git

함정

• 이커머스의 함정
  • 사용자가 궁극적으로 원하는 것은 구매뿐 아니라 상품을 사용하면서 느끼는 지속적인 만족감.
  • 이커머스에서 흔히 쓰이는 속임수가 있어도 다크패턴 에 가깝다면 지양한다.
  • 사용자를 쇼핑에 중독되게 하는 기능은 처음부터 고려하지 않는다. Attention economy 에 현혹되지 않는다.

• 데이터 드리븐의 함정
  • 성공지표 재점검. ex) 고객센터콜, 긍정적인 앱 리뷰

      - 매출, 구매 전환율 외에 사용자의 만족도를 측정할 수 있는 CX 성공지표도 함께 생각한다. 

  • A/B 테스트에 성공하는 것만 생각하지 않는다.

      - 큰 버튼 , 무한 스크롤 , 광고 문구를 터무니없이 작게 표기, 광고로 화면상단 도배, 명확한 동의 및 예시 없이 사용자가 정보를 공유

  • 스프린트 이상의 장기적 비전을 생각한다.
    • 고객이 서비스를 사용하여 더 나은 하루를 보낼 수 있게 하기 O
      • 소비자가 더 구매하게 만들기 X
        
• 디자인 패턴의 함정
  • 유명한 패턴도 시간이 지나면 모를 일이다. 반드시 따라야 할 필요는 없다. 구글 머티리얼 가이드 라인도, 타기업 A/B 테스트 결과도 고객을 위한 최선의 UI일지는 테스트해봐야 안다.
  • 패턴을 사용하기 전에 작동하는 원리를 이해하고 비슷하게 사용될 수 있을지 알아보기 위해 적용 전 반드시 테스트한다.
  • PC 중심 UI에 제한받지 않는다. 메뉴버튼, 체크박스, 라디오 버튼 등 기존 UI 어포던스에서 벗어나 최적의 인터랙션 디자인을 스스로 탐색해본다. 모바일용 제스쳐와 애니메이션을 사용해 더 직관적이고 미니멀한 UX를 생각해본다.
  • Frictionless design만 지향하지 않는다. 사용자가 필요로 할 때; 주의사항이나 사용에 대한 만족감, 기억에 남는 UX를 만들기 위해 때로는 단계를 늘리거나 자동화하지 않거나, 아날로그로 남겨두는 것이 좋을 때도 있다. 무엇이 최선일지 때에 따라 늘 생각해보자.

• 사용자 중심 디자인의 함정
  • 사용자 여정을 파악할 때 조직 담당 포트폴리오 외, 혹은 서비스 외 영역까지 다 살펴본다.
  • 많은 경우 사용자는 스스로 자신이 무엇을 원하는지 모른다. 새로운 가치를 창출한다는 뜻은 그것이 현재 존재하지 않는다는 뜻이기도 하다.
  • 사용자가 아이디어를 제안해도 그대로 받아들이지 않고 숨겨진 이유 생각해본다
  • 사용자가 당면한 문제뿐 아니라 그 너머 목표와 가치에 집중하여 해결책을 생각한다
  • 사용자 중심 디자인이 빠질 수 있는 흔한 함정 2가지, 과도한 커스텀 옵션과 초기 부정적인 반응에 속단하여 기능 롤백하기.

• 레퍼런스의 함정
  • 회사의 규모와 비즈니스 모델을 먼저 이해하고 사례를 참고한다.
  • 경쟁사가 왜 그렇게 했는지에 집중한다.
  • 무엇을 적용하든 반드시 테스트해본다.
  • 경쟁사의 사용자가 다르다는 것을 숙지한다. 특히 타 국가의 서비스를 참고할 때 늘 주의한다.
    • 동북아시아: 트렌드 위주, 이미지 중심, 조금 더 인지부하에 익숙하다.
      • 북미/유럽: 정보 위주, 번역과 웹 접근성이 가능한 텍스트 위주 페이지 구성, 인지 부하에 민감
        • 데이터 사용 가격, 선호하는 디바이스, 선호하는 배송 방법, 프로모션 적용 방식, 결제 방식이 모두 다르고 그에 따라 기능의 우선순위도 제각각이다.

비즈니스 규모에 따라 설계

• MVP & Scale
  • Low hanging fruitsY
  • 사용자를 위해 어떤 해결책에 투자하는 것이 가장 좋을까?
  • 지속 가능한 개발이 이루어질 수 있는 MVP인가?
• Impact & Outcome
  • 필터를 개발하는 바람에 사용자의 탐색 기회를 좁혀 매출에 악영향을 주지는 않을까?
  • 필터를 제공하기 위해 DB 수작업을 진행하는 것이 더 나은 투자일까?
• End-State & Vision
  • 비즈니스 골에 부합하는가
  • 궁극적으로 사용자에게 줄 가치는 무엇인가
  • 추천과 필터 중에 어떤 것에 투자하는 것이 더 합당한가?
• One way door (번복X) vs Two way door (롤백가능)
  • 개발한 UI가 잘못되었을 때 되돌릴 수 있는 종류인가?
  • 테스트했을 때 우리가 배울 수 있는 것이 명확한가?

랜딩페이지와 위젯

패턴, 위젯 , 컴포넌트 : 카테고리가 달라도 컨텐츠가 어느 정도 통일된 디자인

• 고려사항
  • Content Strategy , Design Audit , Consistency

그리드와 리스트 유닛

• 정보 그룹화 . 규칙 만들기 . 디자인 시스템
• Grouping 그룹 & 우선순위 > variation : 유닛화 & 규칙 > component > Pattern : 컴포넌트를 패턴 별로 적용 > Application : 그리드 적용

상세페이지

• 모듈화하기
• 정보구조

• ATF : Above the fold - 스크롤 하기 전 보여지는 화면
• BTF : Below the fold

• 고려사항
  • Content Strategy , Design Principle , Cognitive Load 인지부하

리뷰

• 고려사항
  • 최소한의 장벽 , 동기부여 , 데이터 퀄리티

• gamification
• 모더레이션 : 컨텐츠의 퀄리티 평가, 윤리기준에 위반하지 않는지 필터링

• flywheel : 좋은 리뷰 <> 다른 사람에게 도움 <> 동기부여
  좋은 고객경험 , 더 많은 트래픽 , 더 많은 판매자 , 더 다양한 제품 . 지속적인 성장 , 성장하며 낮춘 비용 구조 , 낮아진 가격 , 더 나은 고객경험 , 더 빨라진 성장

결제

• 카드소팅 : 사용자의 멘탈모델에 부합하는 정보구조를 만들기 위해 참여자가 주제별 카드를 그룹으로 구성하고 연결하여 패튼을 발견하는 리서치 기법

• 고려사항
  • Company Leadership principle , Team Tenets , Design principle

새 비즈니스

• 고려사항
  • Branding , CX , Marketing
  • Data Analysis , End-to-end Journey , Priority , Context-Design(Page-drivne)

Soft Skill

UX Advocate

• (책) Inspired : User > Person > Revenue/Impact > Value > Output > Outcome > Feature Team > Product Team
  • 사용자 테스트 적극 공유 : 요약 보고서 작성, 공유
  • 로드맵에 영향주기 : 비즈니스가 아닌 사용자 중심관점에서 우선순위 보기
  • 매커니즘 만들기 : 반복적 발생문제를 프로세스화
  • 프로덕트 비전 세우기 : PRFAQ (아이디어를 새로 제안 할 때)
  • 디자인 팀의 과업 : 채용, 브랜딩, 커뮤니티 & 사회 활동

도메인 핀테크

• 좋은 지표 vs 나쁜 지표
  • 상대적 : (지난달보다) 리텐션이 2% 증가했다
  • 비율로 표현
  • 행동방식을 바꾼다 : 허상지표, 실행 지표 ㅡ 코호트 분석
• 가설과 우선순위
• 5 whys 기법 계속 왜? 라며 원인을 dipping

• RACI 모델 (R&R)
  • Responsible 실무수행자
  • Accountable 의사결정자
  • Consulted 업무 수행 조언자
  • Informed 결과통보 대상자

체크포인트 프로세스

1. 문제정의 : 프로덕트 매니저 명확한 문제정의, 성공 지표, 프로젝트 목표, 이해관계자 식별, 열린 질문 문서화, 잠재 솔루션

2. 컨셉리뷰 : 디자이너 & 리서처 디자인 리뷰 완료, 디자인 피드백 적용, 선택 솔루션 의견 합일

3. 제품 솔루션 : 디자이너 디자인 리뷰 완료, 디자인과 개발팀 의견 합일, 디자인 세부사항 문서화, 최종 디자인 승인

4. 사전 실험 : 엔지니어, 마케팅 매니저 마켓 플래닝 구축, 개발 완료, 디자인 QA 완료, 출시결정

5. 정식 출시와 회고 : 모두 성공 지표, 다음 스텝

도메인 콘텐츠

도메인 SaaS

UX 라이팅

UX 라이팅

• 역할

  • 단계별로 필요한 정보를 인지/이해 시킨다. Awareness, Understanding
  • 기능/서비스를 수행할 수 있도록 행동을 끌어낸다. Guidance, Nudge

• 특징

  1. 기본 원칙과 제약 존재 프로덕트의 UX 플로우에서 각 여정마다의 맥락을 살피며 UI컴포넌트, 그래픽에 적합해야 함 = 간결하고 직관적인 글
  2. 프로덕트 = 서비스 고객의 목표 달성을 도와 신뢰와 충성도 구축 / 서비스 효율과 이용 가치를 높여 비즈니스 성과에 기여

• Copywriting vs UX Writing

보이스앤톤

• 브랜드만의 라이팅 기준, 원칙

• Voice 목소리

  • 브랜드의 핵심 가치를 전하는 수단(기조)
  • 핵심 가치와 동일하게 변함 없는 목소리

• Tone 말투

  • 고객을 응대하는 브랜드의 태도
  • 고객이 놓인 상황에 맞춰 다르게 적용

• Vision System > Brand Definition > Core Value > Voice & Tone

• A list of 37 words describing tone of voice by Nielsen Norman Group 권위 있는 배려하는, 보살피는 발랄한, 쾌활한 거친 보수적인 구어체의 격식을 차리지 않는 건조한, 딱딱한 예민한, 신랄한 열광하는 ...

UX Writing 기본 원칙

• 고객 관점에서 쓰기 서비스 제공자의 입장이 아닌 고객 중심의 용어 극도로 부정적인 표현은 지양 능동형을 기본으로 (행위의 주체 고려)

• 쉽고 명료하게 쓰기 모두가 이해할 수 있도록 복잡한 표현, 전문 용어, 유행어 지양 문제가 발생한 상황: 원인과 해결방법을 쉽게 파악할 수 있도록! 새로운 기능을 설명할 땐 목적과 쓰임을 예상할 수 있게 버튼은 고객이 해야 할 행동이나 결과 = 고객의 대답 다음 화면을 예상할 수 있도록! 핵심부터 빠르게 파악하도록 결론부터 언급

• 간결하게 쓰기 의미 없거나 중복된 표현, 과도한 수식어, 불필요한 행정 용어는 최소화 전달하고자 하는 내용이 많을 땐 한 문장에 한 내용만 여러 내용을 안내해야 할 땐 bullet point 혹은 컴포넌트 분리 제 위치의 역할을 못하는 문장 가지치기

• 일관성 있게 쓰기 기능명, 서비스명, 용어, 가리키는 말 모두 통일!

• UX user experience (사용자 경험) : 전체
• UI interface (사용자 인터페이스) : 접점
• Usability(사용성) : 측정

  - 효과(Effectiveness), 효율성(Efficiency), 만족도(Satisfaction)를 가지고 특정 목표를 달성할 수 있는 정도나 범위
  - 사용 편의성(Ease of use) 및 학습성(Learnability)

• UCD (User Centered Design) : 철학

  - 철학적 접근 방법이자 디자인 사상
  - 시스템, 기능중신, 직관적, 연구중심

• UX user < CX customer < BX brand
• Design Thinking : 비즈니스 전략에 대한 요구를 충족시키기 위해 디자이너의 감수성과 작업방식을 이용하는 사고방식 ( 협업 + 공감 )
  
  
• 비즈니스 모델 캔버스
  
• 린 캔버스
• 제품, 고객, 시장 리스크

유저 리서치

페르소나

• 사용자 세분화 : 목적, 불만사항, 니즈 등을 X, Y축으로 구분

  - 사진, 이름, 직업 
  - 나는 누구? (평소 생활 : 전기) ,  관심사, 사고방식 
  - 제품 사용 이유, 사용을 꺼려하는 이유
  - 숙련도 , 목표 , 사회활동

조사

유의점

• 인터뷰 : 집단사고 (Ground think)

  - 흔히 집단 구성원들간에 강한 응집력을 보일 때 발생
  - 의사결정시에 만장일치에 도달하려는 분위기로 인해
  - 현실적인 다른 대안들을 외면하게 되는 왜곡되고 비합리적인 사고방식

• 포트 저널 : 호손효과 (Hawthorne effect)

  - 다른 사람의 시선을 인식할 때, 본래 의도나 천성과 다르게 행동하는 현상
  - 사전동의하에 카메라 설치 후, 하루 이틀후면 조사대상도 무신경해짐
  - 이때부터 무의식적인 사용자의 실제 행동관찰 가능 

• 온라인 설문조사 : 리커트 척도 (Likert Scale)

  - 설문조사에 사용되는 심리검사 응답척도의 하나 : 반대되는 질문(R)을 숨겨놓음 
  - 응답자가 제시된 문장에 대해 얼마나 동의하는지를 답변하도록 함 : 그냥 무조건 5점, R도 5점 X 

UX 데이터 모델링

친화도 분석

이해관계자 관계 표시

공감지도 (생각)

여정지도 Jouney Map

• 퍼소나 > 단계와 개요 > 스토리보드 > 터치포인트 및 채널 > 백스테이지 > 스토리보드 > 만족도 > 문제 및 원하는 것 > 해결 방안 및 아이디어

서비스 디자인 (참고용)

• 서비스의 품질과 서비스 제공자와 그 고객 사이의 상호작용을 개선하기 위해 서비스의 인력, 인프라, 통신 및 구성요소를 계획하고 구성하는 활동

  - 인간중심 : 서비스에 영향 받는 모든 사람들의 경험을 고려
  - 협업 : 다양한 배경과 역할을 담당하는 이해관계자들이 디자인 프로세스에 활발히 참여
  - 반복 : 반복적인 실험과 검증을 통해 접근
  - 순서 : 관련 행동들이 순차적으로 시작
  - 실제 : 요구사항은 실제리서치에서 발견,프로토타입 역시 실제 현실에서 구현
  - 전체 : 전체 서비스와 비즈니스의 관점에서 이해관계자의 요구사항을 만족

디자인 노하우

기능 구조화

• 정보구조 IA : 분류와 계층 , 네비게이션 , 검색 , 레이블링
• 사이트 맵
• 플로우 차트
• 유저 플로우
• 레이블 : 카드 소팅
  • 오픈 / 클로즈드 카드 소팅 : 네이밍 가능여부
  • 멘탈모델

사용성 분석

• 사용성 테스트 (Usability Test)
  • 대면 / 비대면

• 평가 (Evaluation)

  • 휴리스틱 평가 (Heuristic) : 체험적이고, 경험적인. 최소 3명, 평균 5명 평가자

    1. 제품 상태의 가시성 : 제품은 현재의 상태에 대해 사용자에게 적절한 반응을 적시에 제공해야 한다.
    2. 제품과 사용자 현실 세계의 조화 : 제품은 사용자에게 친숙한 언어로 사용자와 소통해야 한다.
    3. 사용자에게 자유와 주도권 제공 : 제품은 사용자가 실수를 해도 언제든지 취소 또는 재실행 할 수 있는 방법을 제공해야 한다.
    4. 일관성과 표준성 : 사용자가 혼란스럽지 않도록 제품이 사용하는 정보 표현방법, 인터페이스등이 일관성이 있어야 한다.
    5. 오류방지 : 사용자가 실수할 수 있는 상황을 제거하여 미연에 사용자 실수를 방지해야 한다.
    6. 보는 것만으로도 이해할 수 있는 디자인 : 사용자가 제품을 이용하는데 기억에 의존하지 않도록 직관적으로 디자인되어야 한다.
    7. 유연성과 효율성 : 제품은 초보자나 숙련자 모두 유연하게 사용할 수 있아야 한다.
    8. 심미적이고 단순한 디자인 : 제품은 불필요한 정보를 배제하여 가능한 단순하고 미학적으로 아름다운 디자인을 제공해야 한다.
    9. 사용자가 오류를 인식하고 진단하고 복구할 수 있도록 지원 : 제품을 사용하는 사용자들이 스스로 상황을 인식하고 대처할 수 있는 방법을 제공해야 한다.
    10. 도움말과 설명서 : 제품은 도움말, 매뉴얼 등을 제공하여 사용자가 쉽게 사용할 수 있도록 해야 한다.

  

벤치마킹

• 비즈니스
• 정보구조
• 사용성
• SEQ (single ease question) 을 통한 벤치마킹 : 동일한 테스크를 완료한 후 전반적으로 얼마나 어렵거나 쉬웠는지를 측정하여 여러 회사를 비교 분석

모바일 UX

픽셀 밀도

• 옛날 일반 디스플레이 72ppi 기준
• PT ( Point ) = DP ( Density-Independent Pixel ) PPI ( Pixel per Inch ) = DPI ( Dot per Inch )
• 4배수 xxxxhdpi

앱 아이콘

• ios 20 x 20 x @3x
• and 48 x 48 (3x)

UX/UI 디자인 심리학

00의 심리학 법칙

게슈탈트 심리학

디자인 시스템

구성 요소

• 레이아웃 : 간격 , 그리드시스템
• 스타일 : 컬러 , 아이코노그라피 , 타이포그라피
• 컴포넌트 : 버튼, 폼 등의 UI요소
• 패턴 : 내비게이션, 검색 등의 패턴
• 컨텐츠 : 용어 , 보이스톤
• 사용성 : 접근성 , 글로벌 서비스 원칙

vs

• 스타일 가이드 브랜드 요소가 UI에 적용되는 방법을 제공 ( 컬러, 아이코노그라피, 타이포그라피 제공)
• 컴포넌트 라이브러리 팀내에서 사용되는 공통 스타일과 컴포넌트 제공 (디자인 툴을 통해 자동 동기화되며 추가적으로 코드 제공)
• 디자인 시스템 엘러먼트, 컴포넌트, 영역 등을 문서와 코드로 제공 (디자인 원칙과 규칙 등을 추가적으로 제공) https://adele.uxpin.com/

디자인 데이터 전달

디자인 핸드오프 hand-0ff

• 좌표, 크기, 컬러 / 플로우 / 레이아웃 / 에셋 / 인터랙션 / 코멘트

제플린

오버플로우

페인포인트

• Journey Map
• 데이터 분석
  • 분류 분석 : 제품 및 속성에 대한 분류 체계 마련하여 분석하는 방법
  • 감성 분석 : 긍정어, 부정어에 대한 사전 구축을 통해 뉘앙스 파악
  • 키워드 분석 : 언급이 많은 키워드를 파악하고, 감성 분석과 결합하여 분석

SPT

• 시장세분화 Segmentation : 인구통계학적 지리적 심리적 행동적
• 표적시장 Targeting : 우리 서비스를 선택할 가능성이 높은 핵심 소비자층
• 포지셔닝 Positionin : 잠재고객 마음속에 제품을 인지시키는 Identity, Image를 설정

SWOT 분석

• 강점Strengths , 약점Weaknesses , 기회 Opportunities , 위협 Threats

차별화 전략

• 제품(서비스) , 가격 , 이미지
  
  
  

  2. 마켓리서치

  UX리서치

• 정성적 리서치 : why?
  • 사용자 인터뷰, 포커스 그룹 인터뷰, 필드 스터디
• 정량적 리서치 : How many? How much?
  • A/B test, 사용자 설문, 웹로그 분석
    
    
    

3. 사용자 & 서비스 분석

페르소나

• 실제 사용자들의 행동 패턴과 특징을 수집하여 = 근거있게 만들어진 주요 고객을 대표하는 특정 인물
• 기본정보 : 프로필, 이름, 나이, 성별, 직업, 거주지
• 니즈파악 : 동기, 불만사항, 목적

  저니맵

• https://www.slidesalad.com customer journey map
• 고객 또는 잠재고객이 회사에서 목표를 달성하기 위해서 거치는 프로세스를 시각적으로 표현한 것
  • 고객의 동기 motivation , 즉 고객의 니즈 needs, 고충 pain point 파악
  • 고객 중심의 사고방식, 서비스 개선의 우선순위, 새로운 타겟 고객층 발굴

① Phase ② User Action ③ User Feeling ④ Touch Point ⑤ Strength ⑥ Weakness ⑦ Opportunities

AB Test

• 서비스분석 > 가설수립 > AB 디자인 > 테스트 진행 > 분석 및 의사결정 > 고객경험 개선
• 사용자 그룹분리
  • 노출 분산 방식 : 페이지가 보여질 때 일정 확률로 A와 B를 나눠 노출함
  • 사용자 분산 방식 : 사용자를 A그룹과 B그룹으로 분리하여 고정적으로 A안과 B안을 노출함
  • 시간 분할 방식 : 시간대를 분할하여 A안과 B안을 노출
• 결과 데이터분석 https://abtestguide.com/calc/
• AB테스트 사례 https://goodui.ogr/leaks

4. UXUI

5. 기획부터 런칭, 운영, 회고

목표설정

• OKR (Objective & Key Results 목표 & 핵심결과지표) 회사, 팀 등의 조직 및 구성원 개인들의 목표를 설정하고 성과를 측정할 수 있는 방법
• 이상적+공격적으로 목표 설정하고, 핵심 결과는 측정 가능
• CFR : Conversation 대화 ㅡ Feedback 피드백 ㅡ Recognition 인정 (단기적, 갱신)
• vs KPI (Key Performance Indicator)

제품로드맵

• 시간 경과에 따라서 제품/서비스 또는 팀의 비전, 방향, 우선순위에 따라 제품/서비스가 앞으로 어떻게 진행될 것인지 나타내는 문서
• 제품의 전략, 방향성과 명확하게 연결되어야 함
• 고객 피드백 및 경쟁 환경의 변화에 대응해
• https://www.productplan.com , https://www.aha.io/roadmaps https://miro.com , https://marimba.team ,

요구사항 정의서 PRD (Product Requirements Document)

• 기획단계 : 왜 이 제품/서비스를 만들어야 하는가?
• 각 이해관계자들의 관점 차이를 해소, 기획한 의도 및 주요기능을 유관부서 등에게 명확하게 전달
• 구성요소
  • 개요 : 문제정의, 목적 및 배경, 유저, 유저 스토리/저니맵, 사용자 가치, 개발 원칙
  • 기회 및 임팩트 : 기회, 가설 및 가설 검증지표, 임팩트 예측(사용자가 얻게 될 가치)
  • 제품 정의 및 요구사항 , 마일스톤 또는 WBS , FAQ

WBS (Work Breakdown Structure)

정보구조도 IA (Information Architecture)

• 패턴 계층 Hierarchy , 탭 Taps , 허브 앤 스포크 Hub Spoke , 라이너 Linear , 네스트 돌 Nested Doll , 벤토 박스 Bento Box

와이어프레임

• 포함할 내용

  - 화면에 어떤 정보가 나타나야 하는지?
  - 어떤 레이아웃, 모습을 보여줘야 하는지? 
  - 세부 컨텐츠가 있다면 어떻게 표현해야하는지?
  - 다음 화면으로는 어떻게 이어지는지? 
  - 공통영역 (내비게이션, 푸터 등)은 적절히 기능을 하는가?

• 프로토타입

스토리보드

• 스토리보드 = 상세기획서 = 화면설계서
• 구성요소

  - 서비스 개요 : 목표, 주요기능 
  - 서비스 구성 : IA, 서비스 정책 • 주요 서비스 프로세스 
  - 상세 기획 : UI 시나리오 • 화면별 와이어프레임 + 기능 상세설

  테스트

• QA (Quality Assuran) 순서 : 기획서 분석 > 테스트 범위 설정 (단말 등) > 테스트 케이스 (Test Case, T/C) 검토 및 작성 > 테스트 진행 > 버그 리포트 > 최종 테스트 진행 > 결과 리포트 작성
• 기능단위 테스트, 세니티 테스트

회고

• KPT (Keep, Problem, TRY)
• 타임라인
• 5F : 사실 Fact , 느낌 Feeling , 교훈 Finding , 향후 행동 Future action , 피드백 Feedback
  
  
  

  6. 데이터 흐름

  MVP Minimum Viable Product

• Build > Measure > Learn > Build ...
• Product-Market Fit (Product , Price , Market)

그로스해킹

• 리텐션 (Retention) , 전환율 (Conversion) , 순수 추천 지수 (Net Promotor Score , NPS)

AARRR

OMTM

• One Metric That Matters
  • 지금 가장 중요한 한가지 지표의 약자
  • 제품/서비스 성공의 핵심 중 하나는 정확한 목표/방향을 정하고 그것을 유지하는 것
  • OMTM은 고정되지 않고, 시간이 흐르면서 변함
• 좋은 지표 : 상대적, 이해하기 쉽다, 비율로 표현, 행동을 바꾼다
• 올바른 지표 : 정성적/정량적 , 허상/실질 , 탐색/보고 , 선행/후행 , 상관/인과 지표
• vs KPI

7. ETC

OKR Objective - Key - Results

• 목표를 정하고, 달성했는지 측정할 수 있는 결과지표 설정
• 목표는 가슴 뛰게, 결과지표는 너무 쉽지도 어렵지도 않게
• 현실적으로 C레벨 x 불가능 = 결과지표를 통해서 방향성을 제시, 이끌어 가는 것이 최중요
• 달성하기 위한 규칙을 반드시 설정
• 끊임 없이 결과지표를 구성원들에게 리마인드
• 우선순위를 정할 때 반드시 핵시결과를 중심으로 논의 : 달성 = 성과보상 , 실패 = 원인분석

프로세스

• 상위기획

  - 사업결과, 데이터, 트렌드, 리서치 등을 바탕으로 서비스 제안배경과 근거 제시
  - 보고 및 의사결정 또는 제품 조직 구성원에게 배경 설명
  - 컨셉이해를 돕기 위한 목업과 대략적인 로드맵 포함

• PRD

  - 사업결과, 데이터, 트렌드, 리서치 등을 바탕으로 서비스 제안배경과 근거 제시
  - 무엇을 왜 어떻게 만들어야 하는지에 대한 구체적인 형상을 정의
  - 핵심 기능 명세와 피쳐를 명시, 구체적으로 협의 가능한 수준의 프로젝트 마일스톤 제시

프로토타입

• Low/High Fidelity : 사용자의 실제 인터랙션을 시뮬레이션하고 실험하기 위한 UI/UX 프로토타입
• Proof of concept : 기술적인 관점에서 제품을 실제로 구현해낼 수 있는지 실험 (feat. 코드 with 엔지니어)
• Minimum viable product : 최소한의 실제 기능과 데이터로 사용자의 특성을 수집하는 프로토타입
• Wizard of OZ : 완성된 제품 같지만 뒤에서 모든 것을 사람이 수행하며 사용자의 실제 니즈를 검증하는 프로토타입
• Fake door demand : 진짜 같은 링크를 제공하고, 사용자가 클릭하면 테스트임을 알려 수요를 측정하는 프로토타입

• 워터폴 방식은 순차적, 애자일은 반복적이고 유연한 접근법
• 스크럼은 가장 널리 사용되는 애자일 프레임워크 중 하나
• 변화에 빠르게 대응하고 지속적인 개선을 강조

사용자 중심 설계 (UX)

• UX는 단순히 사용자가 말하는 것이 아닌 실제 원하는 것을 파악하는 것
• 컨텍스트, 행동, 니즈, 태도, 동기를 종합적으로 이해해야 함
• 관찰을 통해 핵심 인사이트를 도출하는 과정이 중요

MVP (Minimum Viable Product) 개념

• 최소한의 기능으로 사용자 가치를 검증하는 제품
• 빠른 출시와 피드백 수집을 통한 제품 개선에 초점
• 린 스타트업 방법론과 밀접하게 연관됨

문제 정의

• 5 Whys: 문제의 근본 원인을 찾기 위해 연속적으로 "왜?"를 질문하는 기법
• AS-IS와 TO-BE 분석: 현재 상태와 목표 상태를 명확히 정의하여 문제 해결 방향 설정

페르소나

• 타겟 사용자 그룹을 대표하는 가상의 인물 프로필 작성
• 이름, 나이, 직업, 행동 패턴, 니즈, 페인 포인트 등을 상세히 기술
• Coupang, Volla 등의 실제 예시를 통해 페르소나 작성 방법 학습

사용자 스토리 작성법

• "As a [role], I want to [action], so that [benefit]"
• 사용자의 관점에서 기능과 가치를 정의
• Trello를 활용해 사용자 스토리를 관리하고 우선순위 설정

제품 기획 도구

• WBS: 프로젝트 작업을 구조화하고 세분화하는 도구
• Product Board: 제품 로드맵과 우선순위를 시각화하는 도구
• PRD: 제품 요구사항을 상세히 문서화하는 도구

제품 팀 구성 및 역할

• PM/PO: 제품 비전 수립 및 백로그 관리
• UX/UI 디자이너: 사용자 경험 및 인터페이스 설계
• 개발자: 프론트엔드, 백엔드, DevOps 등 기술 구현
• QA: 품질 보증 및 테스트 수행

회고 (Retrospective) 방법

• KPT: Keep (유지할 점), Problem (문제점), Try (시도할 점)
• 4Ls: Liked, Lacked, Learned, Longed for
• Mad/Sad/Glad: 감정을 기반으로 한 회고
• 기타: Start/Stop/Continue, Sail boat, Starfish, Speed Car 등

CI/CD는 원래 관심있던 DevOps 부분이라 쉬웠던 느낌.

테스트의 종류 : E2E Test < Integration Test < Unit Test

Unit Test (단위 테스트): Cypress , Playwright

• 가장 작은 단위의 테스트
• 개별 함수, 메소드, 클래스 등 코드의 최소 단위를 테스트
• 다른 컴포넌트와의 의존성 없이 독립적으로 수행
• 빠르고 간단하며, 버그를 조기에 발견하는 데 도움

Integration Test (통합 테스트):

• 여러 단위를 결합하여 테스트
• 컴포넌트 간의 상호작용과 인터페이스를 검증
• 데이터베이스, 파일 시스템 등 외부 의존성을 포함할 수 있음
• Unit Test보다 더 넓은 범위의 기능을 테스트

E2E Test (End-to-End 테스트):

• 가장 큰 규모의 테스트
• 실제 사용자 시나리오를 시뮬레이션하여 전체 시스템을 테스트
• 사용자 인터페이스부터 백엔드 시스템까지 모든 계층을 포함
• 실제 환경과 유사한 조건에서 수행되어 전체 시스템의 동작을 검증

CI/CD

CI (Continuous Integration, 지속적 통합):

• 코드 변경사항을 주기적으로 중앙 저장소에 통합하는 프로세스
• 자동화된 빌드와 테스트를 통해 통합 과정에서 발생할 수 있는 문제를 조기에 발견
• 코드 품질 향상 및 버그 조기 발견에 도움

CD (Continuous Delivery, 지속적 전달):

• 코드 변경사항을 자동으로 테스트하고 프로덕션 환경으로 릴리스할 준비를 하는 과정
• 수동 승인 후 배포가 이루어짐
• 언제든 안정적으로 배포할 수 있는 상태를 유지

CD (Continuous Deployment, 지속적 배포):

• Continuous Delivery의 한 단계 더 나아간 형태
• 코드 변경사항이 자동으로 프로덕션 환경에 배포됨
• 수동 개입 없이 전체 프로세스가 자동화됨
  
  
  

Mock-up

• 실제 객체나 프로세스를 시뮬레이션하는 가짜 객체
• 복잡한 의존성을 단순화하고, 특정 동작을 시뮬레이션
• 테스트 속도 향상, 의존성 제거, 특정 시나리오 테스트 용이성

MSW (Mock Service Worker) https://mswjs.io/

• Industry standard API mocking for JavaScript. 자바스크립트를 위한 산업 표준 API 모킹.
• Mock Service Worker is an API mocking library that allows you to write client-agnostic mocks and reuse them across any frameworks, tools, and environments. MSW는 클라이언트에 구애받지 않는 목(mock)을 작성하고 이를 모든 프레임워크, 도구, 환경에서 재사용할 수 있게 해주는 API 모킹 라이브러리입니다.

1. fail2ban 설치:

   sudo apt update
   sudo apt install fail2ban

2. fail2ban 설정 파일 복사:

   sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

3. jail.local 파일 편집:

   sudo nano /etc/fail2ban/jail.local

4. [sshd] 섹션을 찾아 다음과 같이 수정:

   [sshd]
   enabled = true
   port = ssh
   filter = sshd
   logpath = /var/log/auth.log
   maxretry = 10
   bantime = 600

   여기서:

   • maxretry: 차단 전 허용되는 최대 실패 횟수
   • bantime: 차단 지속 시간(초 단위, 600은 10분)

5. fail2ban 서비스 재시작:

   sudo systemctl restart fail2ban

이렇게 설정하면 10번의 실패한 접속 시도 후에 해당 IP가 10분 동안 차단됩니다.

추가 팁:

• bantime을 -1로 설정하면 영구 차단할 수 있습니다.
• findtime 옵션을 사용하여 실패 시도를 카운트할 시간 범위를 설정할 수 있습니다.
• ignoreip 옵션을 사용하여 특정 IP를 차단 대상에서 제외할 수 있습니다.

fail2ban은 SSH뿐만 아니라 다양한 서비스에 대해 유사한 보호를 제공할 수 있으므로, 서버 보안을 강화하는 데 매우 유용한 도구입니다.

sudo fail2ban-client get sshd banip sudo fail2ban-client status sshd

네, 이 세 가지 보안 관련 도구들에 대해 자세히 설명해드리겠습니다.

1. 정기적인 로그 분석 (Logwatch):

Logwatch는 시스템 로그를 분석하고 요약하는 도구입니다.

설치:

sudo apt install logwatch

사용:

• 기본 설정으로 실행: sudo logwatch
• 특정 기간 분석: sudo logwatch --range All
• 특정 서비스 분석: sudo logwatch --service sshd

특징:

• 다양한 로그 파일을 자동으로 분석
• 일일 이메일 보고서 생성 가능
• 사용자 정의 필터 및 보고서 옵션

설정:

• 주요 설정 파일: /etc/logwatch/conf/logwatch.conf
• 사용자 정의: /etc/logwatch/conf/override.conf

2. 취약점 스캐닝 (Lynis):

Lynis는 UNIX 기반 시스템의 보안 및 시스템 강화를 위한 오픈 소스 도구입니다.

설치:

sudo apt install lynis

사용:

• 전체 시스템 스캔: sudo lynis audit system
• 특정 테스트 실행: sudo lynis audit system --tests SSH-7408
• 보고서 생성: sudo lynis audit system --auditor "Your Name" --report-file /tmp/report.dat

특징:

• 시스템 구성, 소프트웨어 패치, 악성 소프트웨어 등을 검사
• 상세한 로그 및 보고서 제공
• 보안 강화를 위한 제안 사항 제공

3. 시스템 모니터링 (Zabbix):

Zabbix는 네트워크와 애플리케이션을 모니터링하는 엔터프라이즈급 오픈 소스 솔루션입니다.

설치 (Ubuntu 20.04 기준):

wget https://repo.zabbix.com/zabbix/5.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.0-1+focal_all.deb
sudo dpkg -i zabbix-release_5.0-1+focal_all.deb
sudo apt update
sudo apt install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-agent

데이터베이스 설정, 웹 인터페이스 설정 등 추가 단계가 필요합니다.

사용:

• 웹 인터페이스를 통해 대시보드에서 모니터링
• 명령줄에서 상태 확인: zabbix_get -s 127.0.0.1 -k system.cpu.load[all,avg1]

특징:

• 실시간 모니터링 및 알림
• 성능 및 가용성 모니터링
• 사용자 정의 대시보드 및 보고서
• 분산 모니터링 지원

이 도구들을 효과적으로 사용하려면 초기 설정과 주기적인 관리가 필요합니다. Logwatch는 일일 로그 분석에, Lynis는 주간 또는 월간 보안 검사에, Zabbix는 지속적인 시스템 모니터링에 적합합니다. 각 도구의 문서를 참조하여 서버 환경에 맞게 구성하는 것이 중요합니다.

1. BASIC 인증

• ① 클라이언트 : 리퀘스트 ② 서버 : 401 응답, 인증 요청 ③ 클라이언트 : ID / PW (Base64 : 암호화 X, 쉽게 복호화) ④ 서버 : 성공 200, 실패 401 응답

2. DIGEST 인증

• 챌린지 코드를 사용해서 리스폰스 코드를 계산, 이 값을 송신하여 인증
• ① 클라이언트 : 리퀘스트 ② 서버 : 401 응답 인증 요청 + 패스워드 & 챌린지코드 (nonce) 송신 , realm/nonce 필수 ③ 클라이언트 : 패스워드, 챌린지코드에서 리스폰스 코드를 계산해서 송신 ④ 서버 : 성공 200, 실패 401 응답

3. SSL 클라이언트 인증

• 클라이언트 인증서, 배포 설치 필요 → 비용발생
• 2-factor 인증

4. 폼 베이스 인증

• 사전 등록한 유저 정보로 웹 애플리케이션 측에 송신, 검증
• 유저에게 세션ID 발행하고 인증 상태를 기록 → 쿠키로 세션 ID 검증

HTTP + 기능추가 프로토콜

1. SPDY

• 병목현상 해소 목적
• HTTP 클라이언트가 늘 서버로 정보 확인요청, 갱신X => 불필요한 통신 발생
• 클라이언스만 리퀘스트 가능, 리스폰스만은 X
  • Ajax , Comet 로 사용성 개선
  • HTTP 포르토콜의 근본적 제약 개선필요

2. WebSocket

• 웹 서버와 클라이언트가 한번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식
  • 서버 푸쉬 가능 , 통신량 삭감

3. HTTP/2.0

• SPDY
• HTTP Speed+Mobility
• Hetwork-Friendly HTTP Upgrade

4. WebDAV

• Web-based Distributed Authoring and Versioning
• 직접 파일 복사나 편집 작업등을 할 수 있는 분산 파일 시스템
  • 추가 개념 : 컬렉션, 자원, 프로퍼티, 잠금
  • 추가 메소드 : PROPFIND. PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK
  • 추가 상태코드 : 102 Processing, 207 Multi-Status, 422 Unprocessable Entity, 424, 507