Base64 디코딩 & 인코딩: PDF·이미지·파일로 변환

Base64를 PDF·이미지·텍스트·JWT로 디코딩하거나 파일을 놓아 Base64로 인코딩하세요. 모두 이 탭에서 처리합니다.

바이트로 판별하는 파일 형식 33가지 · RFC 4648 · 업로드 없음
인코딩됨

위에 무언가를 붙여넣거나, 카드에 파일을 끌어다 놓거나, 예시 중 하나를 누르세요.

예시

모든 처리는 이 탭 안에서 이루어집니다. 붙여넣거나 끌어다 놓은 내용은 업로드되지 않으며, 디코딩된 HTML이나 스크립트는 실행하지 않고 텍스트로만 보여 줍니다.

3바이트 → 4문자
예시: Man
M77 · 4D1번째 바이트
a97 · 612번째 바이트
n110 · 6E3번째 바이트
1922546

3바이트는 24비트입니다. Base64는 같은 24비트를 6비트씩 네 묶음으로 나누고, 각 묶음은 64개 문자 중 하나를 가리킵니다. 흰 선은 바이트가 끝나는 자리로, 묶음의 경계와 맞지 않습니다. 이것이 이 방식의 전부입니다.

1번째 문자

16 + 2 + 1 = 19 T

표준 알파벳의 인덱스 19입니다.

1바이트가 끝나는 곳채운 비트(입력 아님)URL 안전에서 다름문자를 가리키면 6비트가 더해지는 과정을 볼 수 있습니다.

Base64 디코딩 방법: 디코더와 인코더 사용법

입력란 하나에 무엇이든(텍스트, Base64, data: URI 전체, JWT) 붙여넣거나, 파일 선택을 누르거나, 카드에 파일을 끌어다 놓으세요. 도구가 변환 방향을 알아내 방향 표시에 보여 주고, 반대 방향으로 읽기도 클릭 한 번이면 됩니다.

파일을 디코딩하면 바이트 자체로 판별한 형식, 크기, 이미지의 픽셀 크기, 이미지나 PDF의 미리보기, 올바른 확장자의 다운로드를 얻습니다. 파일을 인코딩하면 Base64, 바로 쓸 수 있는 data: URI, 인코딩으로 늘어난 크기를 볼 수 있습니다. 결과 아래의 알파벳, 패딩, 줄 바꿈 옵션으로 출력을 바꿀 수 있습니다.

Base64 디코딩 도구 화면: 붙여넣은 Base64 문자열을 PDF 문서로 디코딩해 형식, 크기, 3바이트가 4문자가 되는 그림을 표시Base64 디코딩 도구 화면: 붙여넣은 Base64 문자열을 PDF 문서로 디코딩해 형식, 크기, 3바이트가 4문자가 되는 그림을 표시입력란 하나로 양방향텍스트, Base64, data: URI, JWT를 붙여넣으세요. 방향 표시가 어떻게 읽었는지 알려 주고, 메뉴로 바꿀 수 있습니다.파일 선택또는 카드 아무 곳에나 파일을 끌어다 놓으세요. 탭을 벗어나지 않고 Base64와 data: URI로 바뀝니다.바이트의 정체디코딩하면 결과 맨 위에 파일의 형식, 크기, 시그니처가 나오고, 이어서 미리보기와 다운로드가 나옵니다.출력 옵션표준 또는 URL 안전 알파벳, 패딩 사용 여부, MIME이나 PEM용 줄 바꿈을 고릅니다.3바이트 → 4문자내 바이트를 6비트씩 묶음으로 다시 나눠 보여 줍니다. 문자를 가리키면 비트가 더해지는 과정을 볼 수 있습니다.
PDF를 디코딩하는 화면입니다. 번호를 선택하면 각 부분이 하는 일을 볼 수 있습니다.

Base64란 무엇이며 왜 필요한가요?

Base64는 어디서든 깨지지 않는 64개 문자(A–Z, a–z, 0–9, +, /)로 어떤 바이트든 나타냅니다. 이메일, URL, JSON, XML은 텍스트를 위해 만들어졌고, 날것의 바이트는 제어 코드나 따옴표, 널 문자가 되어 이들을 망가뜨릴 수 있기 때문에 Base64가 존재합니다.

한 번에 3바이트씩 가져와 24비트를 한 줄로 늘어놓고, 그 줄을 6비트씩 네 묶음으로 자릅니다. 6비트는 64가지 값을 담으므로 각 묶음은 정확히 한 문자를 가리킵니다. 3바이트가 들어가면 언제나 4문자가 나오므로, Base64는 원래 데이터보다 약 3분의 1 커집니다.

Man → TWFu
M77 · 4D1번째 바이트
a97 · 612번째 바이트
n110 · 6E3번째 바이트
1922546TWFu

3바이트는 24비트입니다. Base64는 이를 6비트씩 네 묶음으로 다시 나누고, 각 묶음은 출력 가능한 64개 문자 중 하나를 가리키므로 3바이트는 언제나 4문자가 됩니다. 33% 증가는 바로 여기서 생깁니다.

Ma → TWE=
M77 · 4D1번째 바이트
a97 · 612번째 바이트
바이트 없음—3번째 바이트
19224—TWE=

2바이트는 16비트입니다. Base64는 0 비트 2개를 더해 세 번째 묶음을 채우고, 네 번째 문자 자리에는 = 하나가 들어갑니다.

M → TQ==
M77 · 4D1번째 바이트
바이트 없음—2번째 바이트
바이트 없음—3번째 바이트
1916——TQ==

1바이트는 8비트입니다. Base64는 0 비트 4개를 더해 두 번째 묶음을 채우고, 세 번째와 네 번째 문자 자리에는 = 두 개가 들어갑니다. = 기호는 비트를 전혀 담지 않습니다.

흰 선은 한 바이트가 끝나고 다음 바이트가 시작되는 곳을 표시합니다. 6비트 묶음과 경계가 맞지 않으며, 이 어긋남이 원리의 전부입니다. 출처: RFC 4648 §4

Base64를 PDF로 디코딩하는 방법은?

문자열을 붙여넣으면 도구가 PDF를 복원합니다. 버전과 크기를 보여 주고, 브라우저에 내장된 PDF 뷰어로 문서를 열며, 다운로드도 제공합니다. PDF라고 알려 줄 필요도, data: 접두사를 먼저 지울 필요도 없습니다.

PDF는 첫 5바이트인 %PDF-로 알아보므로, 파일 이름이나 보낸 사람이 주장한 형식, 담겨 온 필드가 다르게 말해도 파일을 식별합니다. 바이트가 PDF가 아니면, 처음부터 없던 문서를 열다가 실패하는 대신 그 바이트가 무엇인지 알려 줍니다.

파일은 브라우저 안에서 복원됩니다. 아무것도 업로드되지 않으며, 급여 명세서, 계약서, 청구서 같은 PDF라면 이 점이 중요합니다.

API가 보낸 JSON"document": "JVBERi0xLjcKJeLjz9MKMS…"응답 안의 필드입니다. 따옴표는 Base64의 일부가 아닙니다.
이메일 첨부 파일Content-Transfer-Encoding: base64MIME은 본문을 한 줄에 76자씩 줄 바꿈합니다. 줄 바꿈이 있는 그대로 붙여넣으세요. 줄 바꿈은 건너뜁니다.
data: URIdata:application/pdf;base64,JVBERi0x…전체를 그대로 붙여넣으세요. 접두사는 손으로 지우지 않아도 읽어 냅니다.
첫 바이트가 정체를 알려 줍니다
  1. 25%
  2. 50P
  3. 44D
  4. 46F
  5. 2D-
  6. 311
  7. 2E.
  8. 377

첫 5바이트 %PDF- 자체가 시그니처 전체입니다. 6~8번째 바이트가 버전을 나타내며, 값은 1.7입니다. 파일 확장자는 관계가 없으므로, 누군가 .txt라는 이름을 붙인 PDF도 PDF로 되돌아옵니다.

사람들이 Base64 PDF를 복사해 오는 세 곳과, 디코딩한 뒤 PDF임을 알려 주는 바이트. 출처: ISO 32000-1:2008 §7.5.2, RFC 8118 §8

이미지를 Base64로 변환하는 방법은? 언제 써야 하나요?

이미지를 끌어다 놓으면 Base64와, HTML이나 CSS에 바로 붙여넣을 수 있는 data: URI를 얻습니다. 더 어려운 질문은 그래야 하느냐입니다. Base64는 언제나 약 3분의 1 더 크고, 인라인 이미지는 따로 캐시될 수 없습니다.

반대 방향인 Base64 이미지 변환에서는 화면 속 그림이 아니라 파일 자체의 헤더에서 읽은 형식, 크기, 실제 픽셀 크기를 얻고, 올바른 확장자로 다운로드할 수 있습니다.

  • 디스크의 파일12.9kB 100%
  • Base64로 바꾼 것17.3kB +33.4%
  • MIME용 76자 줄 바꿈17.5kB +35.1%
  • 파일을 gzip 압축11.7kB -9.5%
  • Base64를 gzip 압축12.5kB -3.2%
별도 파일
  • 한 번만 다운로드
  • 브라우저와 CDN이 캐시
  • 페이지 안이 아니라 페이지 옆에서 가져옴
같은 이미지를 인라인으로
  • 압축 전 3분의 1 더 큼
  • 이미지를 담은 파일의 일부로만 캐시
  • 스타일시트나 HTML의 일부로 파싱

압축으로 대부분 되찾습니다: gzip으로 압축하면 Base64는 gzip 압축한 파일보다 7%만 더 큽니다. 되찾을 수 없는 것은 이미지 자체의 캐시 항목입니다. HTML 페이지에 인라인으로 넣으면, 그 이미지를 담은 페이지마다 다시 다운로드됩니다.

경험칙: 수백 바이트(아이콘, 스페이서, 이메일 속 로고)는 인라인으로 넣고, 그보다 큰 것은 링크하세요. 이 12.9kB PNG 이미지는 이미 그 선을 넘었습니다.

도구의 예시가 디코딩하는 이미지로 측정했습니다. 같은 바이트를 다섯 가지 방식으로 담았고, gzip은 최고 수준으로 압축했습니다. 출처: RFC 2045 §6.8

Base64와 URL 안전 Base64의 차이는?

URL 안전 Base64(RFC 4648 §5)는 두 문자만 바꾼 같은 인코딩입니다. + 대신 -, / 대신 _를 씁니다. 패딩도 흔히 생략합니다.

결과가 URL, 파일 이름, 쿠키에 들어간다면 어디서든 이 방식을 쓰세요. JSON Web Token은 전체에 이 방식을 쓰므로 토큰의 각 부분은 절대 = 기호로 끝나지 않습니다. 이 도구는 두 알파벳을 모두 읽고, 한 문자열에 둘이 섞여 있으면 알려 줍니다.

표준(RFC 4648 §4)+/8=
URL 안전(RFC 4648 §5)-_8=
JWT의 base64url(RFC 7515 §2)-_8
  • + → -인덱스 62. 쿼리 문자열에서는 폼 디코더가 + 기호를 공백으로 읽으므로 데이터가 잘못 복원됩니다.
  • / → _인덱스 63. 경로에서는 / 기호가 새 세그먼트를 시작하므로 값이 둘로 나뉩니다.
  • = 생략URL에서 = 기호는 보통 %3D로 퍼센트 인코딩됩니다(RFC 4648 §5). JWT는 아예 빼 버립니다(RFC 7515 §2). 길이만으로 바이트가 끝나는 곳을 알 수 있기 때문입니다.

두 알파벳의 처음 문자 62개는 똑같습니다. 그래서 두 알파벳을 모두 읽는 도구는 어느 쪽이든 디코딩할 수 있고, 이 페이지는 한 문자열에 둘이 섞여 있으면 알려 줍니다.

두 알파벳에서 다른 문자는 2개뿐입니다. 나머지는 모두 같습니다. 출처: RFC 4648 §5, RFC 7515 §2

Base64는 암호화인가요? 아닙니다

Base64는 아무것도 숨기지 않습니다. 키도 비밀도 없어서 흔히 말하는 ‘Base64 복호화’에는 아무런 노력도 들지 않습니다. 이 페이지 같은 디코더는 입력하는 즉시 되돌립니다.

이 점이 가장 중요한 곳은 HTTP Basic 인증입니다. 헤더에 사용자 이름과 비밀번호가 하나의 Base64 문자열로 담겨, 보는 사람 누구나 읽을 수 있습니다. 그래서 RFC 7617은 TLS 같은 암호화된 연결에서만 안전하다고 봅니다. 읽을 수 없게 지켜야 하는 것이라면 암호화가 필요합니다. Base64는 텍스트용으로 만들어진 통로에 바이트를 안전하게 통과시킬 뿐입니다.

RFC 7617 §2 방식으로 만든 Authorization 헤더

Authorization: Basic dXNlcjpwYXNzd29yZA==

한 단계면 원래대로: 키도 비밀번호도 필요 없음

user:password

RFC 7617은 헤더를 단계별로 만들며, 마지막 단계가 그 ‘보호’의 전부입니다. 거기서 클라이언트는 “이 옥텟 시퀀스를 Base64로 인코딩하여 basic-credentials를 얻는다”고 되어 있습니다. 그것이 무슨 뜻인지는 §1에 나옵니다. TLS 같은 시스템이 연결을 보호하지 않는 한 “사용자 ID와 비밀번호가 평문으로 네트워크를 통해 전달된다”는 것입니다. Base64에는 키가 없으므로 깨뜨릴 것도 없습니다. 문자열을 가진 사람은 곧 비밀번호를 가진 셈입니다.

위의 인증 정보는 지어낸 것입니다. 되돌려 읽는 데는 한 단계면 되고 키는 필요 없습니다. 이것이 ‘암호화가 아니라 인코딩’이라는 말의 뜻입니다. 출처: RFC 7617 §2, §1

디코딩한 텍스트가 깨진 글자로 보이는 이유는?

Base64는 바이트를 담고, 바이트는 무언가가 문자 인코딩을 골라야 비로소 글자가 되기 때문입니다. UTF-8 텍스트를 ISO-8859-1인 것처럼 읽으면 é 문자가 é 같은 글자로 바뀌고, ISO-8859-1을 UTF-8로 읽으면 대체 문자가 됩니다.

data: URI는 charset을 선언할 수 있으며, 이 페이지는 모든 것을 UTF-8로 밀어붙이지 않고 그 charset으로 텍스트를 읽습니다. 선언된 charset의 디코더가 브라우저에 없으면, 틀린 글자를 조용히 보여 주는 대신 그렇다고 알려 줍니다.

UTF-8로 쓴 ‘Café’436166C3A9
ISO-8859-1로 쓴 ‘Café’436166E9

UTF-8에서 é 문자는 2바이트이고, ISO-8859-1에서는 1바이트입니다. Base64는 글자가 아니라 바이트를 담으므로, 어느 쪽을 뜻했는지 디코더가 문자열만 보고 알 수는 없습니다.

올바르게 읽은 결과Café
UTF-8 바이트를 ISO-8859-1로 읽은 결과Café
ISO-8859-1 바이트를 UTF-8로 읽은 결과Caf�
글자 깨짐(모지바케)에는 두 가지 모습이 있습니다. UTF-8을 1바이트 코드 페이지로 읽으면 읽을 수는 있지만 뜻 없는 글자(Café)가 되고, 바이트가 아예 올바른 UTF-8이 아니면 대체 문자(Caf�)가 됩니다. 출처: RFC 4648 §4, RFC 2397 §4

Python, JavaScript, Java, C#, Go, PowerShell, 셸에서 Base64 쓰기

모든 언어에 Base64가 내장되어 있습니다. 함정은 어디서나 같습니다. 문자열이 아니라 바이트를 인코딩하고, 텍스트가 어떤 문자 인코딩인지 밝혀야 합니다.

가장 까다로운 것은 JavaScript의 btoa()입니다. U+00FF까지의 문자만 받으므로, Latin-1을 넘는 문자는 먼저 TextEncoder로 UTF-8 바이트로 바꿔야 합니다. 아래 예제는 모두 ‘Man’을 인코딩하고 디코딩하며, 실제로 실행해 출력을 확인했습니다.

import base64

b64 = base64.b64encode("Man".encode("utf-8")).decode("ascii")
print(b64)                                    # TWFu
print(base64.b64decode(b64).decode("utf-8"))  # Man

Python 3.14.4 환경에서 2026년 10월 26일에 실행했으며, 주석에 적힌 그대로 출력합니다.

모든 코드는 ‘Man’ 입력으로 실행했으며 주석에 적힌 그대로 출력합니다. 셸의 base64 -d는 옛 macOS에서는 -D입니다. 출처: gnu.org, developer.mozilla.org

Base64 알파벳 표: 0부터 63까지

6비트 묶음은 각각 0부터 63까지의 수이고, 이 표에서 문자를 찾습니다. Base64는 대소문자를 구분합니다. A는 0, a는 26이므로 글자의 대소문자를 바꾸면 문자열이 깨집니다.

눈으로 익혀 둘 만합니다. A가 이어지면 값이 0인 바이트가 이어진 것이고, JVBER로 시작하는 Base64 문자열은 PDF, iVBOR로 시작하면 PNG, /9j/로 시작하면 JPEG입니다.

  1. A0
  2. B1
  3. C2
  4. D3
  5. E4
  6. F5
  7. G6
  8. H7
  9. I8
  10. J9
  11. K10
  12. L11
  13. M12
  14. N13
  15. O14
  16. P15
  17. Q16
  18. R17
  19. S18
  20. T19
  21. U20
  22. V21
  23. W22
  24. X23
  25. Y24
  26. Z25
  27. a26
  28. b27
  29. c28
  30. d29
  31. e30
  32. f31
  33. g32
  34. h33
  35. i34
  36. j35
  37. k36
  38. l37
  39. m38
  40. n39
  41. o40
  42. p41
  43. q42
  44. r43
  45. s44
  46. t45
  47. u46
  48. v47
  49. w48
  50. x49
  51. y50
  52. z51
  53. 052
  54. 153
  55. 254
  56. 355
  57. 456
  58. 557
  59. 658
  60. 759
  61. 860
  62. 961
  63. +URL 안전: -62
  64. /URL 안전: _63

0–25: A–Z, 26–51: a–z, 52–61: 0–9. 두 알파벳에서 다른 것은 표의 마지막 두 문자뿐이며, 위에 표시했습니다. = 기호는 표에 아예 없습니다. 값이 아니라, 마지막 3바이트 묶음이 모자랐다는 표시입니다.

RFC 4648 §4의 순서대로 나열한 문자 64개. 각 문자 아래의 숫자는 그 문자가 나타내는 6비트 값입니다. 출처: RFC 4648 §4

Base64: 자주 묻는 질문

Base64 디코딩(복호화)이란 무엇인가요?

Base64 디코딩은 네 문자씩의 묶음을 그것이 나타내는 3바이트로 되돌리는 일입니다. 그 바이트는 텍스트일 수도, PDF, PNG 이미지, ZIP 압축 파일 같은 파일 전체일 수도 있습니다. 이 도구는 첫 바이트를 읽어 어느 쪽인지 판별하고, 기호가 가득한 화면 대신 텍스트나 파일 자체를 보여 주며 다운로드하게 해 줍니다.

Base64 파일을 디코딩하는 방법은?

Base64 문자열을 입력란에 붙여넣으세요. 도구가 디코딩한 뒤 첫 바이트를 도구가 아는 파일 시그니처(모두 파일 형식 33가지)와 비교해 형식을 알려 주고, 이미지나 PDF는 미리 보여 주며, 올바른 확장자로 다운로드하게 해 줍니다. 어떤 종류의 파일인지 알려 줄 필요가 없고, 판별을 위해 업로드되는 것도 없습니다.

Base64는 어디에 쓰이나요?

텍스트를 위해 만들어진 곳으로 바이트를 나를 때 씁니다. 이메일 첨부 파일(MIME), HTML과 CSS의 data: URI, JSON과 XML의 바이너리 필드, JSON Web Token, HTTP Basic 인증, PEM 파일 속 인증서와 키가 그 예입니다. 어느 경우든 데이터는 날것의 바이트를 바꾸거나 빠뜨릴 수 있는 통로를 지나야 하므로, 평범한 영문자와 숫자로 이동합니다.

Base64는 암호화인가요?

아닙니다. Base64는 인코딩이지 암호가 아닙니다. 키도 비밀도 없으며, 이 페이지가 입력하는 즉시 되돌리듯 누구나 순식간에 되돌릴 수 있습니다. Base64로 쓴 것은 모두 그대로 드러나 있다고 여기세요. 데이터를 비공개로 지켜야 한다면 먼저 암호화하고, 텍스트로 옮겨야 할 때 암호화된 바이트를 Base64로 인코딩하세요.

Base64를 온라인에서 디코딩해도 안전한가요?

이 페이지에서는 안전하며 직접 확인할 수도 있습니다. 모든 디코딩은 브라우저 탭 안의 JavaScript가 하고, 붙여넣거나 끌어다 놓은 내용은 업로드되지 않습니다. 디코딩된 HTML, SVG, 스크립트는 실행하지 않고 텍스트로 보여 주며, 이미지와 PDF는 브라우저 자체의 뷰어가 보여 줍니다. 사용하는 동안 개발자 도구의 네트워크 탭을 열어 보세요. 데이터를 담은 요청은 없습니다.

Base64는 왜 원본보다 33% 더 큰가요?

3바이트마다 4문자가 되고, 4를 3으로 나누면 1.33이기 때문입니다. 끝에 = 패딩 문자가 최대 2개 붙을 수 있고, 이메일용으로 76자마다 줄을 바꾸면 줄마다 줄 바꿈이 더해지므로, 긴 문자열은 담고 있는 바이트보다 35% 정도 더 큰 경우가 많습니다. gzip 같은 압축으로 그 대부분을 되찾을 수 있습니다.

URL 안전 Base64란 무엇인가요?

RFC 4648 §5의 정의대로 + 대신 -, / 대신 _를 쓰는 Base64로, 결과를 이스케이프하지 않고 URL, 파일 이름, 쿠키에 넣을 수 있습니다. JSON Web Token처럼 패딩도 보통 생략합니다. 이 도구는 한 문자열에 섞여 있어도 두 알파벳을 모두 읽고, 어느 쪽으로든 쓸 수 있습니다.

Base64 디코딩이 실패하는 이유는?

거의 항상 Base64 알파벳에 없는 문자 하나 때문입니다. 채팅 앱이 문자열을 자른 자리의 말줄임표, 워드 프로세서의 둥근 따옴표, PDF에서 온 줄 바꿈 없는 공백 같은 것입니다. 이 도구는 그 문자의 이름과 위치를 보여 주고, 그 앞까지 깔끔하게 디코딩된 양을 알려 주며, 남은 내용을 여전히 디코딩할 수 있다면 ‘삭제하고 디코딩’으로 그 문자를 지울 수 있게 합니다.

Base64를 이미지로 변환할 수 있나요?

네. data:image/png;base64, 같은 접두사가 있든 없든 문자열을 붙여넣으면 이미지가 나타나고, 형식, 크기, 파일 자체의 헤더에서 읽은 실제 픽셀 크기를 보여 줍니다. 그다음 올바른 확장자로 다운로드하세요. PNG, JPEG, GIF, WebP, BMP, ICO, AVIF는 미리 볼 수 있고, SVG는 스크립트를 담을 수 있으므로 처음에는 텍스트로 보여 줍니다.

Base64 끝에 붙는 = 기호는 무슨 뜻인가요?

마지막 3바이트 묶음이 모자랐다는 뜻입니다. 남은 2바이트는 3문자와 = 하나가 되고, 남은 1바이트는 2문자 뒤에 == 기호가 붙습니다. 패딩은 데이터를 전혀 담지 않으며, 바이트가 끝나는 곳을 디코더에 알려 줄 뿐입니다. 이 도구를 포함한 많은 디코더는 패딩이 생략된 Base64도 읽습니다.

크기 제한이 있나요?

선택하거나 끌어다 놓는 파일은 최대 10MB까지입니다. 더 큰 파일은 이름과 크기를 알려 주며 거부하고, 절반만 읽는 일은 없습니다. 붙여넣은 텍스트의 한도는 14,349,002자입니다. 이는 10MB 파일을 줄 바꿈까지 포함해 Base64로 만든 길이에 충분하므로, 이 도구가 인코딩한 것은 무엇이든 다시 디코딩할 수 있습니다. 큰 입력은 백그라운드에서 읽어 입력이 끊기지 않습니다.

여기서 JWT를 디코딩할 수 있나요?

네. 토큰을 붙여넣으면 헤더와 페이로드가 서식 있는 JSON으로 출력되고, iat와 exp 클레임 옆에는 날짜가, 서명은 바이트로 표시됩니다. 이 페이지는 세 개의 base64url 부분을 디코딩할 뿐, 서명을 검증하지 않으며 토큰이 유효하다고 말하지도 않습니다. 그러니 토큰을 믿을지 결정하는 데 쓰지 마세요.

부족한 점이 있습니까?기능 또는 새 도구 제안하기