개발쪽에 일을 할때 보면 어떤 스타일로 문서나 개발을 하는데

각 case(=네이밍 표기법)에 대해서 비교해 보는 시간이 좋을 것 같아서 정리해봤습니다

1) snake_case

**단어를 소문자로 쓰고, 단어 사이를 언더스코어(_)**로 연결하는 이름 규칙이야. 뱀이 기어가는 모양 같다고 해서 그렇게 불러

모든 글자 소문자 + 단어 사이를 _로 연결

예시
customer_id
order_item
created_at

특징/주로 쓰는 곳
DB 테이블/컬럼, 백엔드 설정값에서 많이 씀
대소문자 문제 적고 SQL에서 보기 편함

2) camelCase
첫 단어는 소문자, 다음 단어부터 첫 글자만 대문자(낙타 혹처럼 대문자가 올라옴)

예시
customerId
orderItem
createdAt

특징/주로 쓰는 곳
JavaScript/TypeScript, Java, C# 변수/함수명에서 흔함
코드에서 자연스럽게 읽힘

3) PascalCase (또는 UpperCamelCase)
모든 단어의 첫 글자를 대문자 (첫 단어도 대문자)

예시
CustomerId
OrderItem
CreatedAt

특징/주로 쓰는 곳
클래스명/타입명(예: class Customer {})에 많이 씀
“이건 객체/타입이다” 느낌을 주는 규칙

4) kebab-case
모든 글자 소문자 + 단어 사이를 - 하이픈으로 연결

예시
customer-id
order-item
created-at

특징/주로 쓰는 곳
URL 경로, 파일명, CSS 클래스명에서 많이 씀
예: /order-item/list, .order-item {}

DB 컬럼명엔 보통 비추(하이픈이 SQL에서 빼기 연산자로 취급돼서 매번 따옴표 처리 필요)

5) SCREAMING_SNAKE_CASE
snake_case인데 전부 대문자

예시
MAX_RETRY_COUNT
API_BASE_URL
DEFAULT_TIMEOUT

특징/주로 쓰는 곳
상수(const), 환경변수(.env)에서 많이 씀
“이건 값이 고정이다”라는 의미 전달

6) dot.case / path/case (가끔 참고)
dot.case: db.connection.timeout (설정키에서 가끔)
path/case: api/v1/orders (URL path)

교과서형/기본형(목적 : ERD가 논리적으로 맞는지)

0단계)준비물(이것부터 있으면 쉬워짐)

화면/기능 목록(없으면 메모라도 OK)

예시 데이터 2~3개(진짜 값 아니어도 됨)
용어 통일 메모(“고객=셀러=회원?” 같은 것)

1단계) 업무 범위(경계) 정하기
이번 ERD에 포함할 도메인(예: 회원~주문까지만) 경계부터 확정

“이번 ERD에 어디까지 포함할 건지” 먼저 정해야 안 커져.
예: “회원/몰계정/신청/심사까지만”
제외: 결제, 정산, 상환, 알림, 로그…

산출물 느낌:
“ERD 범위: 신청(한도조회~심사결과)”

2단계) 엔티티(테이블) 후보 추출(뽑기)
요구사항에서 명사 뽑기: 고객/상품/주문/결제…

중복/동의어 정리(고객=회원 같은 것)

요구사항 문장에서 명사만 뽑아.
예)
고객, 몰, 신청, 심사결과, 금융사, 상품, 한도…
그 다음 비슷한 말 합치기
고객=회원=셀러 → customer 하나로
몰계정=스토어계정 → cust_mall 하나로

초보 팁
“데이터가 여러 건 쌓일 수 있는 것”은 테이블 가능성이 높아.

3단계) 엔티티 확정 + 이름 정하기

엔티티 명칭을 한 스타일로 통일(단수/복수, snake_case 등)

테이블 이름을 통일 규칙으로 정해.
snake_case 권장: fi_application, cust_mall
단수/복수도 하나로 통일(보통 단수)

체크
이 테이블이 “한 줄(1 row)”이 무엇을 의미하는지 말로 설명 가능해야 함
fi_application 1건 = “신청 1건”

4단계) 각 엔티티의 속성(컬럼) 나열(적기)
“무엇을 저장하는가?”를 컬럼으로 적기
타입은 대략만(문자/숫자/날짜) 잡아도 됨

각 테이블에 대해 이렇게 질문해:
(1) “이 row를 설명하는 필수 정보가 뭐지?”
고객: 사업자번호, 상호, 대표자, 연락처…
신청: 신청번호, 요청금액, 신청일시, 상태…

(2) “조회 화면에서 꼭 보여줘야 하는 값은?”
신청상태, 승인금액, 심사일시…

(3) “나중에 찾기 위한 검색키는?”
사업자번호, 신청번호, 몰아이디 등

초보 팁
처음부터 완벽하려고 하지 말고 “필수 + 자주 쓰는 것”만 먼저 적고 확장해도 됨.

5단계) 기본키(PK) 선정(정하기)
각 엔티티를 구분할 키 결정(보통 id)
자연키(이메일 등)는 PK로 할지/UNIQUE로 할지 결정

각 테이블에 PK를 1개 잡아.
보통 customer_id, app_id 같은 숫자 ID

그리고 “업무적으로 유일한 값”은 보통 UNIQUE로 둬.
사업자번호(biz_no) UNIQUE
신청번호(app_no) UNIQUE

초보에게 추천하는 패턴
PK는 단순한 id(자동증가/uuid)
자연키는 UNIQUE

6단계) 관계(Relationship) 찾기 + 카디널리티 정하기
엔티티 간 연결을 찾고
카디널리티(1:1, 1:N, N:M) 표시

이 단계가 ERD 핵심이야. 질문은 딱 2개:
A 한 건이 B 몇 건을 가질 수 있나?
B 한 건은 A에 몇 건에 속하나?
예)
고객 1명은 신청을 여러 번 할 수 있다 → customer 1 : N fi_application
신청 1건은 고객 1명에 속한다 → fi_application N : 1 customer

카디널리티는 보통:
1:1
1:N
N:M

초보 팁

대부분은 1:N이다.
N:M은 나중에 “중간테이블”로 풀어야 한다.

7단계) N:M이면 교차(연결) 엔티티 추가(N:M 관계면 “중간 테이블” 만들기)
예: 주문-상품 N:M → 주문항목(order_item) 만들기

예: 상품과 태그
상품 1개에 태그 여러 개
태그 1개가 상품 여러 개에 붙음
→ N:M

이걸 ERD에서 그대로 두면 DB로 구현이 어려움.
그래서 교차(연결) 테이블을 만든다:

product_tag(product_id FK, tag_id FK)

초보 팁
“둘 다 여러 개”면 중간 테이블을 떠올려.

8단계) 외래키(FK) 배치(관계 구현)
보통 N 쪽에 FK
선택 관계인지(Nullable)도 결정

원칙:
1:N이면 N쪽 테이블에 FK가 들어간다
예)
customer 1 : N application
→ application 테이블에 customer_id FK

그리고 선택 관계인지 결정:
“반드시 있어야 하면” NOT NULL
“없어도 되면” NULL 허용

예)
decision은 신청 후에 생길 수 있으니
decision 테이블의 app_id는 NOT NULL
신청이 decision을 “반드시” 갖는 건 아니므로(0..1) 관계 표현만 그렇게

9단계) 정규화 점검체크(중복/반복 제거)
컬럼에 여러 값 들어가는지(리스트/콤마) 체크
반복 그룹, 파생값(계산값) 저장 여부 검토

초보가 쉽게 보는 체크리스트:
(1) 한 컬럼에 여러 값 들어가나?
“tag = A,B,C” 같은 형태 → 잘못 (테이블 분리)

(2) 같은 정보가 여러 테이블에 반복 저장되나?
고객 전화번호가 신청에도 있고 고객에도 있음
보통은 customer에만 두고 참조
단, “신청 당시 전화번호”를 기록해야 하면 예외적으로 스냅샷 가능

(3) 의미가 섞여 있나?
주소 한 칸에 “서울…상세…” 다 넣음 → address table or 컬럼 분리 고려

10단계) 제약조건/규칙 반영
NOT NULL, UNIQUE, CHECK(상태값)
참조 무결성(삭제/수정 규칙)까지 표시하면 좋음

ERD에 표시하거나 문서로라도 남겨.
NOT NULL: 필수값
UNIQUE: 사업자번호, 신청번호
CHECK/코드: 상태값은 정해진 값만
FK 제약: 참조 무결성

초보 팁
“상태”는 꼭 통제해라.
예: RECEIVED / UNDER_REVIEW / APPROVED / REJECTED

11단계) 검증(가상 데이터로 시뮬레이션)
대표 시나리오 2~3개를 가상 데이터로 넣어본다고 생각하고
“이 구조로 저장/조회가 되는가?”로 검토

이게 초보에게 가장 중요해.

시나리오 2~3개를 손으로 넣어보기
고객 1명 생성
몰계정 2개 연결
신청 1건 생성
심사결정 1건 생성(승인)
또 다른 신청은 결정이 아직 없음(0..1 확인)

이때 확인할 것:
“저장 못하는 상황이 생기나?” (FK 때문에)
“중복이 생기나?”
“조회하려면 조인이 너무 복잡한가?”

이 순서대로 하면 ERD가 “그럴듯하게” 나온다기보다, 논리적으로 안 꼬인 ERD가 나와요

초보용 “한 장 요약 체크리스트”
 테이블 1줄이 뭘 의미하는지 말로 설명 가능?
 모든 테이블에 PK 있음?
 1:N이면 N쪽에 FK 들어갔음?
 N:M은 중간테이블로 풀었음?
 리스트/콤마 컬럼 없음?
 상태값은 통제됨(코드/ENUM/제약)?
 가상 시나리오 2개는 무리 없이 저장/조회 가능?

실무형(목적:나중에 운영/성능/변경에 안 터지는지)

Step 1. 업무 흐름 1장으로 고정(텍스트/박스)

상태가 바뀌는 지점에 동그라미 치기
→ 이 지점들이 보통 테이블(이력/결과) 후보가 됨

Step 2. 명사 뽑기 → 엔티티(테이블) 후보

여기서 핵심 엔티티(변하지 않는 것) vs 이벤트/이력(변하는 것) 구분
핵심: 고객/몰/금융기관
이벤트: 신청/신청결정/변경이력

Step 3. PK를 먼저 찍고 시작
각 엔티티에 *_id 하나씩 PK 박기
ERD에서 PK는 최우선(관계선 그릴 때 기준점)

Step 4. 관계선(카디널리티) 먼저 그리기
1:N, N:M 판단
N:M이면 중간테이블 만들고 다시 1:N 두 개로 풀기
(여기서 ERD가 급정리됨)

Step 5. FK를 확정하고 “필수/선택” 표시
신청은 고객 없이 존재 못함 → customer_id 필수
결정은 신청 뒤에 생김 → app_id 필수 + 신청 기준 optional(0..1)

Step 6. 속성(컬럼)은 “화면/요청/응답” 기준으로 채우기
ERD에 컬럼을 빼곡히 넣기 전에,

신청 화면에 필요한 값, API 요청/응답 필드,조회 화면(상태/금액/일자) 이걸로 최소 컬럼부터 넣기

Step 7. 제약(UNIQUE/코드값/상태) 표시
app_no UNIQUE
fi_code UNIQUE
decision.app_id UNIQUE(1:1 강제)
상태값은 코드 테이블 or ENUM 정책 결정

Step 8. “이력/로그”는 마지막에 별도로 붙이기
초보가 처음부터 로그까지 ERD에 넣으면 복잡도 폭증

제출용 ERD는 보통
Core ERD(핵심), History/Log ERD(부록)로 나눠 제출하면 깔끔함

ERD 제출 산출물 구성(추천)
(1) Core ERD 1장: customer / mall / fi / application / decision
(2) 용어사전(Data Dictionary): 테이블/컬럼 의미, 타입, 제약
(3) 주요 흐름 1장: 상태 전이 다이어그램(신청상태)

초보 개발자 기준으로 DB 설계는 “요구사항 → 데이터(엔티티) → 관계 → 제약/정규화 → 인덱스/성능 → 물리 구현” 순서로 가면 안전해요.

1) 요구사항을 문장으로 정리
“무엇을 저장해야 하지?”를 먼저 확정
화면/기능 목록을 적고, 각 기능에서 입력/조회/수정/삭제되는 데이터를 뽑기
예: 회원가입(이메일, 비번, 이름), 주문(주문번호, 결제금액, 배송지) …

2) 핵심 용어를 ‘명사’로 뽑아서 엔티티 후보 만들기
문장에서 명사 = 테이블 후보
예: 사용자, 상품, 주문, 주문항목, 결제, 배송, 쿠폰 …

3) 각 엔티티의 속성(컬럼) 정의
“이 테이블은 어떤 정보를 가져야 하지?” 체크
컬럼마다
타입(문자/숫자/날짜)
필수 여부(NULL/NOT NULL)
유일성(UNIQUE)
기본값(DEFAULT)
의미/범위(코드값, 길이)
를 적어둠

4) PK(기본키) 결정
보통 초보는 surrogate key(자동 증가 ID) 추천
자연키(이메일, 주민번호 등)는 변경/정책에 취약할 수 있어 보조로 UNIQUE로 두는 편이 안전

5) 테이블 간 관계 정의 (1:1 / 1:N / N:M)
1:N: N쪽 테이블에 FK 둠 (주문 ↔ 주문항목)
N:M: 중간 테이블 만들어야 함 (상품 ↔ 태그 → 상품태그)

6) 정규화(중복 제거) + 현실적 타협 지점 찾기
중복된 값(예: 사용자 주소를 주문에도 또 저장?)은 원칙상 분리
다만 주문처럼 “그 시점의 주소 스냅샷”이 필요하면 의도적으로 중복 저장(정규화보다 비즈니스가 우선)

초보 체크 기준:
한 컬럼에 값 여러 개 넣지 않기(“A,B,C” 금지)
반복되는 그룹은 별도 테이블로 빼기

7) 제약조건/규칙을 DB에 박기
FK(참조 무결성), ON DELETE/UPDATE 정책
CHECK(상태값 범위), UNIQUE
상태머신이 있으면 상태값/전이 규칙을 문서로라도 고정

8) 조회 패턴 기준으로 인덱스 설계
“어떤 화면/쿼리가 제일 자주 돌지?”부터

인덱스는 보통
FK 컬럼
자주 WHERE/GROUP BY/ORDER BY 되는 컬럼
(조합 인덱스) where 조건 순서대로 부터 시작

주의: 인덱스는 쓰기(INSERT/UPDATE) 비용도 올림 → 많이 만들면 느려짐

9) 데이터 양/성장/보관 정책 결정
1년치만? 영구 보관?
로그/이력 테이블 분리
대용량이면 파티셔닝/아카이빙 전략 고려

10) 물리 구현 (DDL 작성) → 샘플 데이터 → 쿼리 검증
CREATE TABLE 먼저 만들고
더미데이터 넣어서
실제 화면 쿼리/리포트 쿼리 돌려보고
느리면 인덱스/구조 재조정

11) 마이그레이션/버전관리 붙이기(초보도 강추)
“나중에 컬럼 추가/변경”이 반드시 생김
Flyway/Liquibase 같은 도구 또는 최소한 DDL 파일 버전관리

초보가 특히 자주 실수하는 포인트 5개
“상태값”을 문자열로 막 넣고 통제 안 함 → 코드/ENUM/테이블로 관리
컬럼 하나에 리스트 저장(콤마로) → 중간 테이블로
FK/제약조건 없이 앱에서만 체크 → 데이터 꼬임
인덱스 없이 대용량 가정 → 나중에 화면 다 느려짐
“주문 당시 가격/주소” 같은 스냅샷 필요성을 놓침

UUID (Universally Unique Identifier) 는 전 세계적으로 중복되지 않는 식별자를 생성하기 위한 표준 규격입니다.
특정 시스템·데이터·객체를 구분하기 위해 사용되며, 

서로 다른 장비/시간/환경에서 생성해도 중복될 확률이 극도로 낮습니다.

특징요약

1.128비트 숫자
총 128bit(16byte) 길이이며, 일반적으로 문자열 형태로 표현됨
예:
550e8400-e29b-41d4-a716-446655440000

2.재현 불가 구조
다른 장비나 시간대에 생성해도 동일한 UUID가 생성될 확률이 거의 없음

3.표준화된 규격 (RFC 4122)
운영체제/언어/시스템에 관계없이 사용 가능

4.중앙 관리 불필요
DB 시퀀스처럼 관리 서버가 필요 없음

UUID 구성
UUID는 다음과 같이 5개의 블록으로 구성됩니다:

8자리 - 4자리 - 4자리 - 4자리 - 12자리

총 32자리의 16진수 + 4개의 하이픈 = 36문자

주요 버전 종류 (UUID Version)
버전 생성 방식 특징
v1 시간 + MAC 주소 기반 재현 가능성 O, 보안 취약
v3 이름 기반 (MD5) 동일 입력 → 동일 UUID
v4 랜덤 기반 가장 대중적, 충돌 확률 극저
v5 이름 기반 (SHA-1) v3의 보안 강화판

대부분 시스템은 UUID v4 를 기본으로 사용합니다.
예:
8e52c74c-c7c6-4f61-be3b-977438f6d09f
(4번째 블록 첫 숫자 = 4 → v4)

장점
전역 유일성 보장
분산 시스템에 적합
시퀀스 관리 불필요
충돌 가능성 무시 가능 수준

단점
숫자보다 길어 인덱스 비효율
DB 저장시 공간 많이 사용
정렬 의미 없음
시각적 가독성 낮음

DB에서 UUID 사용 시 고려사항
1. PRIMARY KEY 로 UUID가 적합한가?

장점: 분산 생성 가능
단점: 성능 하락 가능

추천 형태:

BINARY(16) 로 저장 → 공간 절감, 인덱스 효율 ↑

가능하면 v1 또는 v7 사용 → 순차성 ↑

2. MySQL/MariaDB 예시
SELECT UUID();

3. PostgreSQL 예시
SELECT gen_random_uuid();

충돌 확률
UUID의 총 경우의 수는:
2^128 = 3.4 × 10^38 개

비유:
매초 1조개씩 10억년 생성해도 충돌 확률 거의 0
현실적으로 충돌 걱정할 필요 없음

실무 활용 예

사용자 ID
API 키
트랜잭션 ID
세션 ID
분산 서비스 객체 식별자
Kafka 메시지 키
로그 상관관계 추적 (Correlation ID)

3RSYS T100발키리라는 케이스를 쓰고 있는데

팬에서 이잉잉 우웅  소리가나서

케이스살려고 알아보다가

AS는 탑티어라고 해서

AS 우선 받아보기로 했음

QC가 안좋다고하네

특히나 기본팬은 안좋다고도 후기봤음

https://zod.kr/case/1632214

주소 및 연락처
주소 : 서울시 용산구 청파로 109, 나진전자월드 지하1층 특1호
전화번호 : 02-718-3313, 02-718-3314 / FAX : 02-719-3339
이메일 : support@3rsys.com


고객지원 센터 운영시간
평 일 : 10:00 ~ 16:00
점심시간 : 12:00 ~ 13:00
토,일,공휴일 : 휴 무

서비스 신청방법
01 증상확인
A/S 신청 전, 자주 있는 질문 게시판을 통해서 사용하시는 제품의 증상 원인을 파악하실 수 있습니다.
02 A/S신청
자주 있는 질문 게시판을 통해서 문제가 해결되지 않았을 경우, 게시판이나 전화 등을 이용하여 A/S 신청을 해 주세요.
03 접수완료
게시판을 통하여 신청하시면 온라인 상으로 접수 확인을 해 드리고 있으며, 전화 접수 시에는 실시간으로 상담을 받으실 수 있습니다.
04 제품발송,방문
제품의 고장인 경우 택배 및 직접 방문을 통하여 제품을 보내주시면 교환 및 수리 처리를 해 드립니다. 작은 제품의 경우 우편 등기를 이용하실 수도 있습니다.
택배나 등기를 이용하실 경우 성함, 주소, 연락처, 제품의 증상을 메모에 기입하여 보내주시면 빠른 처리가 가능합니다.
05 A/S처리
방문을 하셨을 시 최대한 빠른 시간 내에 처리해 드리며, 택배 및 우편으로 보내신 경우 배송 기간을 포함하여 최장 일주일 이내에 처리됩니다.

아래는 고객센터 홈페이지

https://www.3rsys.com/bbs/page.php?hid=csguide

ㅇㄹㅇㅇㅇ

루틴요약

[준비]
온찜질 5분
↓
[거북목]
턱당기기 + 가슴열기
↓
[오십견 완화]
팬듈럼 + 수건스트레칭
↓
[등·어깨 교정]
등 폼롤러 + 견갑골 + 가슴 롤링
↓
[마무리]
깍지스트레칭

이 루틴을 일 1회만 꾸준히 해도

2주 후부터 어깨가 부드러워지고,

3~4주 차엔 등 라인과 자세가 눈에 띄게 펴집니다.

거북목·오십견 초기·등어깨 교정용 10분 홈루틴

총 소요시간: 약 10분~12분

매일 저녁 or 샤워 후에 하면 효과 배가

통증이 있는 부위는 “강도 약하게, 횟수 적게”

처음엔 5분만 해도 충분 (꾸준함이 핵심)

보조 도구 & 팁

증상별 이해 (쉽게 정리)

집에서 편하게 할 수 있는 3단계 루틴

하루 15분 루틴으로, 폼롤러·수건·찜질팩만 있으면 됩니다.

단계 1: 온찜질 (5~10분)

• 어깨와 목 뒤에 전자찜질팩 or 따뜻한 수건
  → 근육 이완 + 통증 완화
• 물 온도: 40~43℃ 정도 (뜨겁지 않게)
• 타이밍: 운동 전 or 자기 전

💡 다이소 팁:
전자찜질팩 1~2만 원대, 수건+지퍼백+뜨거운물도 가능

단계 2: 거북목 교정 스트레칭 (5분)

매일 1~2세트면 충분해요. 무리하지 말고 천천히!

1. 턱 당기기(Chin Tuck)
   👉 벽에 기대서 턱을 살짝 안쪽으로 당겨 5초 유지 × 10회
   (목뼈의 정렬 회복 효과)
2. 승모근 스트레칭
   👉 한 손으로 의자 잡고 반대손으로 머리를 천천히 옆으로 당기기
   10초 유지 × 좌우 3회
3. 가슴 열기 스트레칭
   👉 벽에 양손 올리고 가슴을 천천히 앞으로 밀기
   (어깨 앞쪽 굳은 근육 풀기)

단계 3: 오십견 초기 완화 스트레칭 (5분)

통증 없는 범위 내에서 “움직임” 유지가 핵심입니다.

1. 팬듈럼 운동 (팔 흔들기)
   👉 상체를 약간 숙이고 아픈 팔을 아래로 늘어뜨린 뒤
   천천히 원을 그리듯 10~20회 흔듭니다.
   → 관절 유착 방지 효과.
2. 수건 스트레칭
   👉 수건을 양손으로 잡고,
   건강한 쪽 팔로 아픈 쪽 팔을 천천히 위로 끌어올립니다.
   → 통증이 심하면 30~50%만 움직이기.

폼롤러·도구 활용 팁

• 폼롤러: 등·승모근 아래쪽까지만 사용 (목 직접 금지)
  → 등 위쪽을 30초~1분 천천히 롤링
• 마사지 볼(테니스공): 벽에 기대서 견갑골 안쪽 눌러주기
  → 통증 있는 부위는 10초 눌렀다가 쉬기
• 저가형 어깨마사지기: 오십견엔 강한 진동 금지
  → “약~중” 단계로 승모근 부위까지만.

생활습관 교정

1. 스마트폰 눈높이 유지
   • 아래로 보는 자세가 거북목 악화의 주원인
2. 어깨 펴는 습관 (1시간에 1번 스트레칭)
   • 알람 맞춰서 “턱 당기기 + 가슴 펴기” 10초
3. 수면자세
   • 베개는 목 높이보다 약간 낮게 (수건 베개 추천)
4. 단백질+수분 섭취
   • 근육 회복에 필요 (특히 40대 이후엔 효과 큼)

추천 루틴 조합 (10~15분 버전)

저렴하게 도와주는 도구

등·어깨가 튀어나오는 주요 원인

폼롤러로 교정 가능한 부분

폼롤러는 “말린 등을 펴주고, 뭉친 근육을 풀어주는” 데 효과적입니다.

폼롤러 3단계 루틴 (하루 10분)

필요한 도구: 폼롤러 1개, 요가매트 or 카펫

① 등 상부(흉추) 펴주기 — 굽은등 교정

• 자세:
  무릎을 세우고 폼롤러를 어깨 밑 등 중앙에 두고 눕기
  양손을 머리 뒤에 대고 상체를 천천히 뒤로 젖힘
• 효과:
  말린 흉추가 펴지고, 등 튀어나온 라인 완화
• ⏱ 10회 반복 × 2세트
• ⚠️ 허리까지 굴리면 허리 통증 생길 수 있으니 등 위쪽까지만

② 견갑골(날개뼈 주변) 풀기

• 자세:
  한쪽 팔을 머리 위로 올리고, 폼롤러를 겨드랑이 뒤쪽~등 중간쯤에 두고 천천히 굴리기
• 효과:
  날개뼈 주변 근육(능형근·광배근) 이완 → 등 라인 균형 회복
• ⏱ 30초~1분씩 좌우 교대

③ 가슴 앞쪽(대흉근) 풀기 — 라운드숄더 교정

• 자세:
  옆으로 누워 겨드랑이 앞쪽~가슴 옆 부분을 폼롤러로 천천히 굴림
• 효과:
  말린 어깨 원인인 가슴근육을 이완 → 어깨가 뒤로 펴짐
• ⏱ 30초씩 좌우 교대
• ⚠️ 세게 하면 멍 들 수 있으니 가볍게 압박만!

마무리 스트레칭

폼롤러로 근막을 푼 뒤에는 가벼운 스트레칭을 해줘야 라인이 잡혀요.

1. 벽 밀기 가슴 스트레칭
   벽에 손을 대고 상체를 천천히 밀어 가슴 열기 (20초 × 3회)
2. 어깨 뒤로 젖히기 + 턱 당기기
   거북목 교정 효과
3. 양팔을 뒤로 깍지 → 가슴 펴기 (10초 유지 × 3세트)

꾸준히 하면 이렇게 바뀜

• 1주일: 뻐근함, 뭉침 완화
• 2~3주: 어깨 라인이 내려가고, 등이 펴지는 느낌
• 4주 이후: 거북등이 줄어들고 자세가 자연스러워짐

📌 단, 통증이 “날카롭게” 오거나 팔 들기 힘들 정도면
오십견 진행 중일 수 있으니 강한 자극은 금지입니다.

추가 꿀팁

• 샤워 후 따뜻할 때 폼롤러 쓰면 더 잘 풀림
• 마사지건이 있다면 등 중간~승모근만 가볍게
• 온찜질 + 폼롤러 + 스트레칭 3단 루틴이 최고 효율

예시구문

$rmlist = json_decode($_POST['rmlist'], true);

$ids = array_map('intval', $rmlist);

$placeholders = implode(',', array_fill(0, count($ids), '?'));
$sql = "DELETE FROM your_table WHERE id IN ($placeholders)";

$stmt = $pdo->prepare($sql);
$stmt->execute($ids); // 순서대로 바인딩: 109, 110, 111

$ids = array_map('intval', $rmlist);에 대해서 자세히 알아보겠습니다

해당 줄의 개념은 정수 변환 (SQL 인젝션 방지)로직입니다

intval(mixed $value, int $base = 10)의 기본 베이스는 10진수입니다.

!!!이런일을 합니다

array_map()이 $rmlist 배열의 각 요소에 intval() 함수를 적용해서,
정수로 변환된 값들로 구성된 새 배열 $ids를 만듭니다.
(원본 $rmlist는 바뀌지 않아요. 단일 배열을 넘겼을 때는 키도 유지됩니다.)

!!!이러기 위해서 씁니다

입력 정규화/안전: 폼/JSON 등 외부 입력을 숫자형으로 딱 고정해 SQL 인젝션 등 위험을 줄입니다.
(그래도 최종 쿼리는 Prepared Statement 권장!)
타입 일관성: 이후 로직에서 정수 연산/비교가 안정적입니다.

!!!!예시(문자열)

문자열 앞쪽의 공백은 무시, 처음부터 숫자로 읽히는 부분만 변환하고 처음 아닌 문자를 만나면 거기서 중단:
'123' → 123
' 123' → 123
'123abc' → 123
'abc123' → 0 (처음이 숫자가 아님)

!!!!예시(부호)

부호는 처리: '-42' → -42, '+7' → 7

!!!!예시(소수문자열)
소수 문자열은 소수점에서 끊김: '12.9' → 12



!!!!예시(지수표기문자열)
지수 표기 문자열은 ‘e’에서 끊김: '1e3' → 1
(단, 실제 float 값 1e3을 intval(1e3) 하면 1000)


!!!!예시(진수문자열)
16진/8진 문자열은 기본(10진)에서는 해석 안 함:
'0xFF' → 0
'075' → 75 (8진수로 안 봄)



!!!!예시(빈 문자열/null)
빈 문자열/null → 0



!!!!예시(불리언)
불리언: true → 1, false → 0



!!!!예시(배열/객체등)
배열/객체 등 비스칼라:
배열: 비어있으면 0, 비어있지 않으면 1
객체: 1 (경고가 날 수 있음 — 이런 값은 애초에 들어오지 않도록 하는 게 좋습니다)

implode(',', array_fill(0, count($ids), '?')) 에 대해서 자세히 알아보겠습니다

1) count($ids)
$ids 배열의 원소 개수를 구합니다.
예: $ids = [109,110,111] → count($ids) === 3

2) array_fill(0, count($ids), '?')
배열을 채워서 생성하는 함수입니다.
형식: array_fill($start_index, $count, $value)
$start_index: 시작 인덱스(대부분 0 사용)
$count: 몇 개를 만들지
$value: 각 원소에 넣을 값
즉, array_fill(0, 3, '?') → ['?', '?', '?']

3) implode(',', ...)
배열을 구분자로 문자열로 합치는 함수입니다.
첫 번째 인자 ','는 구분자.

두 번째 인자는 배열(array)
implode(',', ['?','?','?']) → ?,?,?

implode(',', ['1','2','3']) → 1,2,3

결과적으로
$ids 길이만큼 '?'를 만들고, 이를 ,로 이어 붙여 플레이스홀더 목록을 만듭니다.
예: $ids = [109,110,111] → 결과 문자열: "?,?,?"
이건 Prepared Statement의 IN 절을 만들 때 정석처럼 씁니다.

?가 아니라 직접 값(숫자일경우)을 IN절로 만드는 방법

$idList = implode(',', $ids); //109,110,111

$sql = "DELETE FROM your_table WHERE id IN ($idList)";

직접 값(문자열일경우)을 IN절로 만드는 방법

$rmlist = ["109","110","111"];

// 문자열 각각을 작은따옴표(')로 감싸기
$quoted = array_map(function($v) {
    return "'" . addslashes($v) . "'";
}, $rmlist);

$idList = implode(',', $quoted);

$sql = "DELETE FROM your_table WHERE id IN ($idList)";

공유기 (Router)
여러 기기를 인터넷에 연결하고, **IP 주소를 배분하며 외부 네트워크(인터넷)**와 통신하게 해주는 장치

주요 기능
공인 IP 1개를 사설 IP 여러 개로 나눠줌 (NAT 기능)
DHCP 서버 역할: 자동으로 IP 주소를 할당
방화벽 및 포트포워딩 지원
무선 공유기인 경우 Wi-Fi 기능 포함
인터넷 회선을 받아 LAN 여러 대로 분배


예시
인터넷 회선을 ‘KT, SK, LGU+’로부터 하나 받았다면,
공유기가 그 하나의 인터넷을 여러 대(PC, 휴대폰, TV 등)에 나누어 줌.

스위칭 허브 (Switch)
같은 네트워크 안에서 기기들끼리 데이터를 빠르게 주고받게 하는 장치

주요 기능
로컬 네트워크(LAN) 확장
IP를 새로 주지 않음 (라우팅 기능 ❌)
단순히 데이터를 목적지 포트로만 전달 (MAC 기반 스위칭)
네트워크 트래픽을 효율적으로 분배

예시
공유기에서 나온 LAN 포트가 부족할 때,
스위칭 허브를 추가로 연결하면 포트를 늘려 여러 PC를 연결 가능.

요약 비교표

정리하면
공유기는 ‘인터넷을 나눠주는 두뇌’
스위칭 허브는 ‘유선 네트워크를 늘려주는 손발’

정리하자면, 테이블의 기본키(Primary Key)로 DATETIME을 쓰는 건 권장되지 않습니다

문제점
1.유일성 보장 어려움
같은 시각(밀리초 단위)으로 여러 건이 동시에 들어올 경우 PK 충돌 가능성이 높습니다.
특히 다중 서버 환경, 트랜잭션 동시처리 시 더 취약합니다.

2.인덱스 효율성 저하
PK는 클러스터형 인덱스(Clustered Index)가 되는 경우가 많은데, DATETIME은 단순히 시간순 정렬은 가능하지만 랜덤 삽입 시 성능 저하가 있을 수 있습니다.

3.가독성/관리성 문제
시간이 곧 식별자 역할을 하면, 사람이 식별하기도 불편하고 조인 시에도 직관성이 떨어집니다.

언제 가능할까?
로그성 데이터(이벤트 로그, 센서 측정값 등)에서 "실행시각 자체가 절대 중복되지 않는 경우" 에는 가능할 수 있습니다.
단, 이 경우에도 보통은 DATETIME + AUTO_INCREMENT 복합키를 쓰는 게 안전합니다.

권장 대안

1. Auto Increment (INT, BIGINT)
가장 일반적인 PK 방식. 단순하고 충돌이 없음.

2UUID / GUID
분산 시스템, 글로벌 유니크 ID 필요할 때 적합.

3.복합키
(일자, 시퀀스) 형태로 만들어서 유일성을 확보. 예: 2025-09-25 10:00:00 + seq=1

결론:
DATETIME만으로 PK를 잡는 건 위험합니다.
→ 대신 DATETIME은 보조 컬럼(이력 추적, 조회 조건)으로 쓰고,
→ PK는 BIGINT AUTO_INCREMENT나 UUID 같은 안정적인 값을 쓰는 게 베스트입니다.

WPS(Wi-Fi Protected Setup)는 무선 네트워크에 장치를 빠르고 간편하게 연결할 수 있도록 도와주는 기능으로, WPS 버튼이나 PIN 코드를 활용해 설정할 수 있습니다. 

WPS 연결 방법
1.WPS 버튼 사용
공유기나 무선랜카드에 WPS 버튼이 있는 경우, 해당 버튼을 약 2~3초간 누르면 WPS 표시등이 깜빡입니다. 

동시에 연결하려는 장치(예: 스마트폰, 프린터 등)의 WPS 버튼도 2분 이내에 눌러야 하며, 두 장치 모두 WPS 표시등이 깜빡이면 연결이 시작됩니다. 
일부 공유기는 웹 관리 페이지에서 WPS 설정을 활성화할 수도 있습니다. 

2.PIN 코드(PBC) 방식
공유기에서 PIN 코드를 확인한 뒤, 연결하려는 장치의 설정에서 해당 PIN을 입력하면 연결이 완료됩니다. 
프린터 등 일부 장치는 WPS 버튼을 반복해 PIN 코드를 인쇄해 제공하므로, 이를 공유기에 입력하면 됩니다. 

3.지원 기기 및 주의사항
WPS는 Open System, WPA-Personal, WPA2-Personal 등 일부 보안 방식만 지원하며, WPA3-Personal은 지원하지 않습니다. 
2.4GHz 대역만 기본적으로 지원하므로, 5GHz로 변경하려면 WPS 기능을 끄고 주파수를 변경한 뒤 다시 켜야 합니다. 
WPS 버튼이 없는 경우, 공유기 관리 페이지에서 WPS 설정을 활성화할 수 있습니다. 
WPS는 복잡한 설정 없이 무선 연결과 보안 설정을 간편하게 할 수 있어, 무선 프린터, 스마트폰 등 다양한 장치에 널리 사용됩니다