깨진 URL을 여기에 붙여넣고 "URL 고치기!!"를 클릭하세요깨진 URL 입력

URL 수정기란?

이메일, Word 문서, Slack 메시지, Confluence 페이지에서 링크를 복사했더니, 둥근 따옴표(" 대신 ")가 붙어 있거나, 하이픈이 있어야 할 자리에 엔 대시(–)가 들어 있거나, 앞에 https://가 없거나, 누군가 잘못된 순간에 Enter를 눌러서 URL이 두 동강 나 있는 상황. 여기에 붙여넣으면 작동하는 URL을 돌려드립니다. URL 수정기는 복사·붙여넣기가 남기는 구문상의 손상을 WHATWG URL 표준과 RFC 3986의 규칙에 맞춰 정리합니다.

정규식이라면 영원히 특수 케이스로 처리해야 할 것들을 이 수정기가 다룹니다. 스마트 따옴표, 스마트 대시, 경로에 끼어든 이중 슬래시, 혼합되거나 이중으로 적용된 퍼센트 인코딩(이중 인코딩이 명백할 때 %2520을 %20으로 되돌림), 인코딩되지 않은 공백, 누군가 잘못된 순간에 Enter를 눌러 URL 안에 들어간 CR/LF/탭 문자 등이죠. 호스트명을 새로 만들지 않고, 쿼리 매개변수를 바꾸지 않으며, 원래 없던 경로 세그먼트를 추가하지도 않습니다. 출력은 브라우저의 URL API 규칙에 따라 검증되므로, 반대편에서 정상적으로 파싱된다는 것을 알 수 있습니다. 국제화된 호스트명(Unicode, IDN)은 RFC 3987에 따라 보존됩니다.

입력한 URL은 수정 처리를 위해 백엔드로 전송된 후 바로 돌아옵니다. 입력 자체는 로깅하지 않습니다. URL에는 세션 토큰, 고객 ID 등 로그 파일에 남기고 싶지 않은 것들이 자주 들어 있기 때문입니다. URL에 실제 비밀 정보(서명된 S3 링크, 일회성 인증 토큰 등)가 포함되어 있다면, 여기를 포함해 어디에든 붙여넣은 뒤에는 회전(재발급)하세요.

URL 수정기 사용법

세 단계입니다. 각 단계는 이 페이지의 버튼 하나에 대응합니다 — 숨겨진 동작은 없습니다.

깨진 URL을 붙여넣거나 예시를 불러오기

왼쪽 에디터에 깨진 URL을 넣습니다. 예시 URL을 클릭하면 둥근 따옴표, 엔 대시, 누락된 스킴, 인코딩되지 않은 공백 등 일부러 망가뜨린 예시가 로드됩니다. 이메일에서 실제로 붙여넣었을 때 마주치는 모습이죠. 깨진 URL의 예:

"shop.example.com/orders/ORD–1001?customer=Ava Chen"

Word에서 묻어온 둥근 따옴표가 URL을 감싸고, 경로 세그먼트 안에 엔 대시가, 스킴은 없고, 쿼리 값에 그대로 공백. 짧은 한 줄에 네 가지 문제가 동시에 들어 있습니다.

URL 고치기!! 클릭

초록색 URL 고치기!! 버튼을 누릅니다. 수정기는 감싸는 따옴표를 떼어내고, 엔 대시를 하이픈으로 바꾸고, 앞에 https://를 붙이고, 공백을 퍼센트 인코딩해 결과가 RFC 3986에 맞게 만듭니다.

고친 URL 복사

오른쪽 패널에 깔끔해진 URL이 나옵니다. 한 번 훑어보고 복사한 뒤 브라우저, fetch() 호출, README, 실패하던 테스트 등에 붙여넣으세요. URL을 구성 요소별로 나눠 보고 싶다면 다음 단계로 URL 파서에 통과시켜 보세요.

실제로 쓰게 되는 상황

이메일이나 Word에서 붙여넣은 링크

Outlook과 Word는 곧은 따옴표를 둥근 따옴표로, 하이픈을 엔 대시로 조용히 바꿔버립니다. 메시지에서는 멀쩡해 보이던 URL이 터미널에 붙이는 순간 깨집니다. 수정기는 이 "똑똑한" 자동 교정을 되돌려 링크가 다시 동작하게 합니다.

로거가 따옴표로 감싼 URL

JSON 형식의 애플리케이션 로그는 URL을 "https://api.example.com/v1/orders?id=ORD-1001"처럼 출력하길 좋아합니다. 빠르게 curl을 던지려고 가져오면 감싸는 따옴표가 함께 따라옵니다. 수정기가 그 따옴표를 떼어주면, 셸이 닫히지 않은 따옴표 때문에 불평하는 이유를 더는 고민할 필요가 없습니다.

Slack이나 Jira가 URL 중간에 끼워 넣는 줄바꿈

Slack, Jira, Confluence 페이지의 긴 URL은 종종 줄바꿈되어 복사할 때 \n이 함께 묻어옵니다. 경로는 멀쩡해 보이지만 fetch()는 파싱 오류로 거부합니다. 수정기는 줄바꿈을 평탄화해 URL을 다시 하나의 연속된 문자열로 만듭니다.

이중 인코딩된 쿼리 문자열

URL이 둘 다 퍼센트 인코딩하는 두 시스템을 거치면, %20이 있어야 할 자리에 %2520이 들어가게 됩니다. 수정기는 명백한 이중 인코딩을 한 겹으로 줄여줍니다. 리다이렉트 체인이나 웹훅 페이로드를 디버깅할 때 유용합니다.

자주 묻는 질문

URL이 저장되거나 제가 볼 수 없는 어딘가로 보내지나요?

URL은 수정 처리를 위해 백엔드로 갔다가 바로 돌아옵니다. 입력 자체는 로깅하지 않습니다 — URL에는 세션 토큰이나 경로/쿼리에 PII가 들어 있는 경우가 많기 때문입니다. 수정이 일어났다는 사실은 기록하지만, 무엇을 수정했는지는 기록하지 않습니다. URL에 진짜 비밀 정보(서명된 링크, 인증 토큰)가 들어 있다면, 여기를 포함한 어떤 외부 도구에든 붙여넣은 시점에 노출된 것으로 보고 회전하세요.

어떤 종류의 URL 오류를 실제로 고치나요?

일상적으로 마주치는 것들입니다. 누락된 스킴(기본값 https://), URL을 감싸는 둥근/스마트 따옴표, 하이픈 자리의 엔 대시나 엠 대시, 경로 안의 우발적 //, 이중 퍼센트 인코딩(%2520 → %20이 명백한 경우), 쿼리 값 안의 인코딩되지 않은 공백, 워드 프로세서가 URL 안에 떨어뜨린 탭/CR/LF 문자, Markdown 링크에서 따라온 <https://example.com> 같은 감싸는 꺾쇠괄호 등.

경로, 쿼리, 프래그먼트 값을 바꾸나요?

아니요. 수정기는 의도적으로 보수적입니다. 호스트를 만들어 내지 않고, 빠진 TLD를 추측하지 않으며, 경로 세그먼트를 추가하거나 제거하지 않고, 쿼리 매개변수를 추가/제거하지 않으며, 매개변수 순서를 바꾸지 않고, 프래그먼트를 버리지 않습니다. 구문적으로 잘못된 문자만 손댑니다. customer=Ava Chen이 들어가면 customer=Ava%20Chen이 나옵니다 — 같은 값이지만 RFC 3986에 맞게 올바르게 인코딩될 뿐입니다.

국제화(Unicode) 도메인명도 지원하나요?

네. 호스트나 경로의 Unicode 문자는 국제화 리소스 식별자(IRI 형태)로 보존됩니다. 애플리케이션이 호스트의 puny코드(ASCII) 형식을 필요로 한다면, 정리된 URL을 사용 언어의 URL 라이브러리에 통과시키세요. Node의 url 모듈, Python의 idna 패키지, 브라우저 내장 URL 생성자가 두 형식을 모두 제공합니다.

아주 긴 URL은 어떤가요?

입력 한도는 64KB(약 64,000자)입니다. 실제 URL은 거의 항상 2,000자 미만입니다. 그보다 크다면 보통 무언가가 이중 인코딩되어 거대한 덩어리가 됐거나, POST 본문에 들어가야 할 바이너리 페이로드가 쿼리 문자열에 들어 있는 경우입니다. 수정기는 입력이 너무 크다고 알려줍니다. 먼저 줄이거나 구조를 바꿔 주세요.

수정된 URL 대신 오류가 반환됐어요. 이제 어떻게 하죠?

입력에 따라 도저히 손쓸 수 없는 경우도 있습니다. 예를 들어 호스트가 완전히 빠진 URL, 또는 구조가 너무 망가져서 모델이 무엇을 의도했는지 알 수 없는 경우입니다. 그럴 때는 URL을 직접 살펴보고 분명한 부분(보통 호스트와 스킴이 범인입니다)을 손으로 고친 뒤 다시 시도하세요. 결과를 URL 검증기에 넣어보면 URL 파서가 정확히 무엇에 불만인지 확인할 수도 있습니다.

필요할 수 있는 다른 URL 도구

URL을 고치는 건 한 단계일 뿐입니다. 깔끔하게 파싱되기 시작하면, 다음 도구들이 마무리를 도와줍니다: