🌈 [Section4] 1. 인증 / 보안

📕 오늘 배운 내용!

• HTTPS
• 해싱 (Hashing)
• 쿠키 (Cookie)
• 세션 (Session)
• 웹 보안 공격

---

✏️ HTTPS ( Hyper Text Transfer Protocol Secure Socket layer )

• HTTP + Secure(보안)
  ( HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해, HTTP 통신을 하는 과정에서 데이터를 암호화하여 전송하는 방법 )

• 대부분의 웹사이트의 경우 HTTPS를 사용

• HTTP over SSL(TLS), HTTP over Secure라고 부르기도 함

💡 기존 HTTP 요청은 누군가가 중간에 중간자 공격(Man-in-the-middle attack)을 통해 요청 내용을 들여다본다면 다 볼 수 있었음
➜ 개인정보 유출 가능성 있음
[중간자 공격 참고] https://en.wikipedia.org/wiki/Man-in-the-middle_attack

✔ HTTPS의 특징

• 기밀성 (privacy)
  ➜ 메세지를 가로챌 수 없음 (읽을 수 없음)

• 무결성 (integrity)
  ➜ 메시지가 조작되지 않음 (수정할 수 없음)

✔ HTTPS의 목적

1. 암호화

• 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환하여,
  해당 방식에 대한 정보를 소유한 사람을 제외하고 이해할 수 없도록 알고리즘을 이용해 정보를 관리하는 과정

• HTTP 프로토콜 내용을 암호화하여 제 3자가 서버와 클라이언트가 주고받는 정보를 탈취할 수 없도록 하는 것

• 중요한 데이터가 유출될 가능성이 HTTP보다 현저히 적어짐
  ( 암호를 복호화하기 전까지는 어떤 내용인지 알 수 없음 )

• 비대칭키 방식과 대칭키 방식을 혼용하여 사용
  ➜ 클라이언트에서 만들 대칭키를 비대칭키로 암호화하여 서버에 전달

  ✔️ 키 유형에 따른 암호화 방식

  • 대칭키 암호화 (키가 하나)
    ➜ 양쪽이 공통의 비밀 키를 공유하여 데이터를 암복호화하는 것
    ( Ex. 가족끼리 집 열쇠 공유하는 것 )
    ➜ 비대칭키 알고리즘보다 훨씬 복잡성이 낮아서, 중간에 정보가 탈취되면 모든 데이터의 복호화가 가능하게 됨
    ➜ 대칭키를 주고받을 때는 비대칭키 방식 사용
    ⠀⠀
  • 비대칭키 암호화 (키가 두개)
    ➜ 각각 공개키와 비밀키를 가지고 상대가 나의 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화하는 것
    ( 아래 두 가지 방식이 있지만 결국은 공개키로 암호화 해야지만 정보 보호 가능 )
    ➜ 대칭키 알고리즘보다 훨씬 복잡
    ⠀
    👉 개인키(private key)로 암호 / 공개키(public key)로 복호 ➜ 전자서명
    ( 정보 보호가 아니라 누가 보냈는지가 궁금한 것 (신원확인))
    ⠀
    👉 공개키(public key)로 암호 / 개인키(private key)로 복호 ➜ 암호화
    ( 말 그대로 정보보호 )

  ---

  ✔️ 방향에 따른 암호화 방식

  • 단방향 암호화
    ➜ 암호화는 되지만 복호화는 되지 않는 암호화 방식
    [참고] https://en.citizendium.org/wiki/One-way_encryption
    ⠀⠀
  • 양방향 암호화
    ➜ 암호화 복호화 모두 되는 암호화 방식

2. 인증서

• 서버의 응답과 함께 클라이언트에게 전송됨

• 해당 인증서의 내용에 서버의 도메인 관련 정보가 있어서 데이터 제공자의 인증을 용이하게 함
  ( 클라이언트는 CA의 공개키로 복호화하여 인증서에 작성된 도메인과 응답데이터의 도메인과 비교하여 확인 )

  💡 여기서 도메인 정보가 같다면 해당 서버가 맞음을 확신하고,
  중간자 공격으로 인해 도메인 정보가 다르다면 서버가 아님을 확신함 !

• 이 인증서로 서버(데이터 제공자)의 신원 보장 가능

• 이를 보장하는 제 3자 = CA

  ✔️ CA (Certificate Authority) (공인 인증서 발급 기관)

  • 서버의 공개키 + 정보를 CA의 비밀키로 암호화하여 인증서를 발급함
    ( 이 인증서는 CA의 공개키로 복호화 가능 )
    ( 해당 기관의 비밀키가 유출되면 파산도 가능함 )
    ⠀
  • 각 브라우저는 각자 신뢰하는 CA의 정보를 가지고 있음
    ( 브라우저마자 인증서가 차이가 남 )
    ( 자격이 계속 유지되는 것이 아니라 박탈당할 수도 있음 )
    ⠀
  • 전혀 다른 키 한쌍으로 암호화 / 복호화 가능
    ( A 키로 암호화를 진행했다면 복화화 할 때는 A키의 한 쌍인 B키가 필요 )
    ⠀➜ HTTPS 이용하는 서버는 키 하나를 비밀로 숨겨두고, 나머지 하나는 클라이언트에게 공개해서 데이터를 안전하게 전송할 수 있게 함
    ( But, 공개키 연산은 매우 복잡한 알고리즘이기 때문에 모든 요청에 공개키 사용하는 것은 아님 - 통신 처음 대칭키 전송에만 사용 )

✔️ TLS or SSL

• 서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜
  ( SSL과 TLS는 사실상 동일한 규약 / SSL이 표준화되며 바뀐 이름이 TLS )

✔ HTTPS 통신 시작을 위한 TSL(SSL) 핸드 쉐이크 과정

1. 클라이언트가 서버에게 헬로 요청

💬 클라이언트 :
서버야 안녕.
나 요청 보낼거야.

2. 서버는 클라이언트에게 인증서를 포함해서 헬로 응답

💬 서버 :
클라이언트야 안녕.
여기 인증서 + 공개키 줄게.

3. 클라이언트가 내장된 CA 리스트를 보고 인증서 확인 후,
CA의 공개키로 복호화를 통해 인증서를 검증

💬 클라이언트 :
받은 공개키로 인증서 열어볼게.
너 내가 아는 서버가 맞구나.

4. 클라이언트가 대칭키 만들어서 서버의 공개키로 암호화해서 서버에 전달

💬 클라이언트 :
그럼 내가 대칭키 만들어서 네가 준 공개키로 암호화해서 너한테 줄게.

5. 서버는 서버의 개인키로 복호화하여 클라이언트의 대칭키를 확인

💬 서버 :
너가 준 대칭키 내가 가진 개인키로 복호화해서 잘 받았어.

6. 서버가 받은 대칭키로 샘플 데이터 암호화한 후, 클라이언트에게 보내서 확인

💬 서버 :
그럼 내가 이 대칭키로 데이터 한번 암호화해서 보내볼게.

7. 클라이언트가 서버에게 받은 데이터를 대칭키로 복호화해서 서로 대칭키를 잘 가지고 있는지 확인
( HTTPS 연결 성공한 상태 )

💬 클라이언트 :
너가 준 데이터 대칭키로 열어봤더니 잘 왔어.
너 내가 준 대칭키 잘 가지고 있구나.

8. 이 후에는 클라이언트와 서버는 서로 대칭키로 암복호화를 진행하여 데이터를 전송

💬 클라이언트 / 서버 :
이제 우리 둘 다 대칭키 잘 가지고 있으니까 이걸로 데이터 주고받자.

---

✏️ Hashing

• 어떠한 문자열에 임의의 연산을 적용하여 다른 문자열로 변환하는 것

• input ➜ output 이 항상 동일함
  ( 원본 암호가 같다면 해시값도 항상 동일 )

• 해싱된 값은 사실상 복호화가 불가능
  ( But, 암호화하는 알고리즘을 알게되면 해독 가능 - 레인보우 테이블 )

• 대표적인 해시 알고리즘
  ➜ SHA1(요즘 사용 X) / 요즘엔 SHA256 많이 사용

  SHA-256 알고리즘을 사용했을 경우 출력값의 길이는 입력값의 길이와 관계없이 언제나 256비트(64 글자)

• 극히 드물게 다른 입력값인데 해시된 값이 같은 경우가 발생할 수 있음

✔ Hashing 규칙

1. 모든 값에 대해 해시 값을 계산하는데 오래 걸리지 않아야 함
( 유저가 기다리지 않아야하기 때문에 )

2. 최대한 해시 값을 피해야하며, 모든 값은 고유한 해시값을 가짐

3. 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 함

Ex. 이메일 관련 정보 얻을 경우,
1. 클라이언트는 이메일과 함께 password를 서버에 전달.
2. 서버는 이 정보들을 받고 DB에서 비교한 후, 원본 password 그대로 DB에 저장.
3. 이후 요청에서 DB에 보관된 정보와 일치하면, 해당 요청 데이터를 DB에서 찾아서 응답으로 전달
⠀
❗ DB에는 password가 그대로 저장되어있기 때문에 탈취 당하면 개인정보가 유출됨
➜ password를 해싱하여 DB에 보관해야함

✔️ shiftBy(문자열, 숫자)
➜ 입력받은 문자열을 입력받은 숫자의 값만큼 알파벳 순서를 건너뛴 문자열로 반환하여 새로운 문자열을 반환하는 메서드
⠀
Ex. 인증 과정에서 shiftBy 알고리즘을 사용하여 서버에 적용을 했다고 가정하면,
요청과 함께 전달받은 password를 서버측에서 해시 알고리즘을 이용해 해시값으로 변환하여 암호화시킨 후 DB에 password 저장함
⠀
이후 로그인이나 인증이 필요한 요청이 들어오면,
입력받은 비밀번호를 해시값으로 바꾸고 DB에 저장되어 있는 해시값 비밀번호와 비교
⠀
➜ 암호화한 정보를 저장하는 방식이라 DB의 비밀정보가 탈취 당해도 해커는 이 알고리즘을 모르기 때문에 개인정보 유출 가능성 현저히 적어짐

✔ Salt

• 암호화 해야하는 값에 어떤 별도의 값을 추가하여 결과를 변형 시키는 것
  Ex. (password + salt 값) 자체를 해싱 알고리즘을 통해 암호화하여 이의 해시값을 DB에 저장

• 레인보우 테이블(Rainbow Table)을 이용한 무차별 대입(brute-force)공격 성공 확률을 대폭 낮출 수 있음
  ➜ 해시 알고리즘이 노출되더라도 원본값을 보호할 수 있도록 하는 안전 장치 역할
  [레인보우 테이블 참고]
  https://namu.wiki/w/%EB%A0%88%EC%9D%B8%EB%B3%B4%EC%9A%B0%20%ED%85%8C%EC%9D%B4%EB%B8%94

• 재사용 X
  ➜ 클라이언트의 계정 생성 시 / 비밀번호 변경 시 마다 새로운 임의의 Salt 사용하여 해싱
  ➜ 유저와 패스워드 별로 유일한 값을 가짐

• Salt는 유저 테이블에 같이 저장되어야 함

💡 해시값만으로 암호화하여 저장한다고 할 경우,
이 해시 알고리즘만 안다면 해당 값의 output이 항상 같기 때문에 쉽게 유출될 가능성이 있음
⠀
➜ 원본 문자열에 Salt값을 추가한 후, Hashing한다면 예상이 힘든 해시값 만들어짐
( salt를 뿌린다고 생각해 )

---

✏️ 쿠키 (Cookie)

• 서버에서 클라이언트에 데이터를 저장하는 방법의 하나
  ( HTTP 요청은 무상태성이지만 쿠키가 있기에 데이터가 유지될 수 있음 )

• 서버가 클라이언트에게 일방적으로 전송하는 작은 데이터 조각

• 클라이언트는 해당 도메인에 대한 (서버에게 받은)쿠키들을 저장해놨다가,
  동일한 서버에 재요청시 쿠키(저장된 데이터)를 함께 전송

➜ 응답할 때 Set-Cookie로 클라이언트에게 쿠키가 저장되고
매 요청시마다 해당 쿠키를 서버에 같이 전달
[참고] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie

• 삭제하지 않는다면 사라지지 않음
  ➜ 장기간 저장해야하는 옵션을 클라이언트에 저장하기에 적합

• 자바스크립트로 쿠키에 접근이 가능

• 인증상 한계가 있음 ➜ 세션으로 한계 극복

✔ Cookie Options

( 쿠키의 옵션에 아래 옵션 정보가 존재한다면 ~~경우에 클라이언트가 쿠키 전송 )

1. Domain

• 서버의 도메인과 쿠키의 도메인이 일치하는 경우에만 쿠키 전송

  Ex. http://www.localhost.com:3000/users/login에서 localhost.com가 도메인

2. Path

• 서버와 쿠키의 세부 경로가 일치하는 경우에만 쿠키 전송
  ( 설정된 path를 전부 만족하는 경우, 요청하는 path가 추가로 더 존재해도 쿠키 전송 가능 )

  Ex. http://www.localhost.com:3000/users/login에서 path가 /users로 설정되어 있고, 요청하는 세부 경로는 /users/login 이라면 전송 가능

3. MaxAge 0r Expires

• 쿠키의 유효기간 설정
  ( 이 옵션의 여부에 따라 세션 쿠키 / 영속성 쿠키로 나뉨 )

  Ex. pc방 가서 로그아웃 안하고 가면 누군가가 내 정보 탈취할 가능성 있음
  -> 이 옵션으로 쿠키의 유효 기간을 설정하면 자동으로 없어지게 가능

  • 세션 쿠키 (Session Cookie)
    ➜ MaxAge / Expires 옵션이 없는 쿠키
    ➜ 브라우저가 실행중일 때 사용할 수 있는 임시 쿠키
    ( 브라우저 종료시 쿠키도 삭제 )
    ⠀
  • 영속성 쿠키 (Persistent Cookie)
    ➜ MaxAge / Expires 에 지정된 유효시간만큼 사용이 가능한 쿠키
    ( 브라우저 종료 여부와 상관 X )

4. Secure

• Https 프로토콜에서만 쿠키 전송 여부 결정
  ➜ 이 옵션이 true로 설정된 경우만 쿠키 전송

5. HttpOnly

• 자바스크립트에서 브라우저의 쿠키에 대한 접근 가능 여부 결정
  ➜ 이 옵션이 true로 설정된 경우, 자바스크립트에서 쿠키에 접근 불가
  ( 기본은 false )

  Ex. 쿠키는 <script> 태그로 접근 가능 ( XSS 공격에 취약 )
  ➜ 이 옵션을 주면 저 태그로 접근이 불가능하도록 보안 강화 가능

  [XSS 참고] https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%9A%94%EC%B2%AD_%EC%9C%84%EC%A1%B0

6. SameSite

• CORS 요청에 대해 메서드에 따라 쿠키 전송 여부 결정

• CSRF 공격을 막는데 매우 효과적인 옵션

• 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우를 말함
  ( 이 중 하나라도 다르면 Cross-Origin )

  • Lax
    ➜ Cross-Origin 요청이면 get 요청에서만 쿠키 전송 가능해
    (크롬 기본값)
    ⠀
  • Strict
    ➜ Cross-Origin이 아닌 same-site 인 경우에만 쿠키 전송 가능해
    ⠀
  • None
    ➜ HTTPS면 다 상관 안하고 쿠키 전송 가능하게 해줄게
    ( 모든 요청에 쿠키 전송할게 )
    ➜ 이 옵션은 위험하기 때문에 Secure 쿠키 옵션이 필수로 함께 사용됨
    ⠀
    [참고] https://jjam89.tistory.com/231

💡 SameSite vs SameOrigin

• site
  ➜ 똑같은 도메인
  Ex. http://www.google.com = http://api.google.com
  (도메인은 같고 서브도메인은 다름)
  ⠀
• origin
  ➜ 똑같은 url
  Ex. https:://www.google.com = https:://www.google.com:443( wellknown 포트 )
  ⠀
  [참고]
  https://en.wikipedia.org/wiki/Same-origin_policy
  https://web.dev/same-site-same-origin/#same-site-cross-site

---

✏️ 세션 (Session)

• 사용자가 인증에 성공한 상태
  Ex. 은행 어플에서 사용 안하면 '60초 후에 세션이 닫힙니다.' 이런 거 나오는 거

• 서버의 저장소에 세션 저장
  Ex. in-memory / 세션 스토어 등

• 세션이 만들어지면, 각 세션을 구분할 수 있는 세션 ID도 만들어짐

  ✔️ 세션 ID

  • 서버가 클라이언트에 부여하는 유일하고 암호화된 ID
  • 클라이언트에서 세션 성공(인증 성공)을 증명할 수단으로 사용됨
    ⠀
    Ex. 로그인을 유지하기 위한 수단으로 사용
    로그아웃이라고 하면,
    서버는 이 세션 정보를 삭제해야하고 / 클라이언트는 (세션 정보가 삭제된)쿠키를 갱신해야 함

• 서버는 클라이언트의 쿠키 임의로 삭제 불가능
  But, Set-Cookie로 클라이언트에게 쿠키 전송할 때 세션 아이디의 키 값을 무효한 값으로 갱신 가능

• 보통 하나의 서버에서만 접속 상태를 저장

💡 jwt 보다 session이 안전할까?
➜ 상황에 따라 다름 !!
➜ session 베이스는 response content type이 html일 때 자연스럽고,
response type이 application/json일때는 JWT을 더 선호한다
라고 이해하면 편할 듯함
[참고] https://github.com/boojongmin/memo/issues/7

---

✏️ HTTPS 통신 시작을 위한 TSL(SSL) 핸드 쉐이크 과정 예시

1. 클라이언트(김코딩) ➜ 서버
   👉 유저 아이디 / 패스워드 쓰고 이 청바지 장바구니에 넣어줘

2. 서버 ➜ DB
   👉 해싱하여 DB에 정보 저장

3. DB ➜ 서버
   👉 session_id 반환

4. 서버 ➜ 클라이언트
   👉 Set-Cookie로 암호화된 session_id 쿠키에 넣어서 보냄

이후 요청 한번 더 보냄

5. 클라이언트 ➜ 서버
   👉 셔츠도 장바구니에 넣어줘
   ( 저장된 session_id로 필요한 작업 수행 )

6. 서버 ➜ DB
   👉 session_id 확인하고 장바구니 업데이트

7. DB
   👉 session_id가 유효하기에 장바구니 업데이트 완료

8. 서버 ➜ 클라이언트
   👉 장바구니 저장 완료함

➜ 인증에 따라 리소스의 접근 권한이 달라짐

💡 쿠키 vs 세션

• 접속 상태 저장 경로
  • 쿠키 ➜ 클라이언트
  • 세션 ➜ 서버
    ⠀
• 장점
  • 쿠키 ➜ 서버에 부담을 덜어줌
  • 세션 ➜ 신뢰할 수 있는 유저인지 서버에서 추가로 확인 가능
    ⠀
• 단점
  • 쿠키 ➜ 쿠키 그 자체는 인증이 아님
  • 세션 ➜ 하나의 서버에서만 접속 상태를 가지므로 분산에 불리
    ⠀
    ❗ But, 쿠키와 세션은 비교할만한 대상이 아님 !
    아직 학습 초반이라 쉬운 이해를 위하여 각각의 특징들을 알아본 것이라고 생각하기
    ⠀
    [참고] https://codinglevelup.tistory.com/86

---

✏️ 웹 보안 공격

✔ SQL Injection

• 데이터베이스에서 임의의 SQL문을 실행할 수 있도록 명령어를 삽입하는 공격

• 응용 프로그램의 보안상의 허점을 이용해 데이터베이스를 비정상적으로 조작

✔️ SQL Injection 공격 과정

1. 공격자가 악의적인 SQL문을 넣어 서버에 전송

2. 서버가 해당 SQL문을 기존 SQL문에 삽입해 데이터베이스에 쿼리 보냄
   Ex. OR ‘1’ = ‘1'과 같은 당연한 조건을 SQL 문에 삽입해 무조건 응답이 오도록
   Ex. DROP TABLES users;--; 작성하면 모두 삭제되도록

3. id 검증 여부와 상관 없이 모든 사용자의 정보를 반환

4. 모든 사용자의 정보가 공격자에게 전송됨

✔️ SQL injection 공격 대응 방안

• 입력(요청)값 검증
  ➜ 화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환하여 SQL Injection에 대응

  ✔️ 화이트리스트
  ➜ 기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식 or 그 지정된 대상들

• Prepared Statement 구문 사용
  ➜ 사용자의 입력이 SQL문으로부터 분리되어 SQL Injection 방어

  💡 사용자의 입력값이 전달되기 전에 데이터베이스가 미리 컴파일하여,
  SQL문을 바로 실행하지 않고 대기하며 사용자의 입력값을 단순 텍스트로 인식함
  ➜ 입력값이 SQL문이 아닌 단순 텍스트로 적용되어 공격 실패

• Error Message 노출 금지
  ➜ 공격자는 데이터베이스의 Error Message를 통해 테이블이나 컬럼 등 데이터베이스의 정보를 얻을 수 있는데,
  이 SQL문과 Error 내용이 클라이언트에게 노출되지 않도록 별도의 에러핸들링 필요

✔ CSRF (Cross-Site Request Forgery)

• 다른 Site에서 유저가 보내는 요청을 조작(forgery)하는 것
  ( 주소가 다른 사이트에서 요청을 조작하는 것 ( 응답에는 접근 X ))
  ⠀
  Ex. 김코딩이 은행 로그인하는데 해커가 스팸메일로 링크 클릭하게 함
  해커는 그 정보를 가지고 자기 계좌로 돈 이체 가능

• 해커가 직접 데이터를 접근할 수 없음
  다른 Origin이라서 응답(Response)정보를 직접 받을 수 없기 때문에 데이터에도 접근 불가

[참고] https://ko.wikipedia.org/wiki/%EC%82%AC%EC%9D%B4%ED%8A%B8_%EA%B0%84_%EC%9A%94%EC%B2%AD_%EC%9C%84%EC%A1%B0

✔️ CSRF 공격을 하기 위한 조건

• 쿠키를 사용한 로그인
  ➜ 유저가 로그인 했을 때, 쿠키에 유저 정보가 담겨있어야함

• 예측할 수 있는 요청 / parameter를 가지고 있어야함
  ➜ 요청에 해커가 모르는 정보가 담겨있으면 안됨
  Ex. 은행에서 돈을 뽑으려고 할 때 password를 모르고 이 공격을 하여 조작된 요청을 보낸다면,
  거기서 또 password를 입력해야만 가능하다고 재요청을 한다면 이 공격은 실패할 것

✔️ CSRF 공격 대응 방안

• CSRF 토큰 사용하기
  ➜ 서버 측에서 CSRF 공격에 보호하기 위한 토큰 문자열을 유저의 브라우저와 웹앱에만 제공하여, 이 조합으로 생성된 요청에만 성공적으로 요청을 완료하는 방식
  ⠀
  Ex. 해커가 다른 웹사이트를 클릭하게 하여 돈을 빼가는 것 방지 가능

• Same-site cookie 사용하기
  ➜ 같은 도메인에서만 세션/쿠키를 사용할 수 있도록 만들어서, 도메인이 다르다면 요청을 받아주지 않는 방식
  ⠀
  Ex. 해커가 보낸 하이퍼링크를 클릭해서 요청을 하더라도 도메인이 다르기 때문에 쿠키 전송 안됨

---

😜 실습

• projects - section4-week1

✔️ 실제 웹 애플리케이션에서 보안 관련으로 신경써야할 것들

• HTTPS 필수 적용

• 민감한 정보는 최대한 노출 X

• OWASP같은 보안 가이드 적용
  ( 웹 애플리케이션에 대한 보안 에러 설명 )

• 잘 검증된 보안 프레임워크 사용

---

🌈 느낀점

이번 학습은 이해한 내용을 좀 더 쉽게쉽게 작성하려고 하다보니 좀 늦었다.
그래도 그만큼 이해가 완벽하게 된 것 같아서 다행이다 !
물론 이해와 습득은 다름 ㅠ
이해 잘 했으니까 머리에 넣도록 해야지 ..