회사 사이트를 세우면서 제일 오래 걸린 문제들에는 공통점이 있었습니다. 에러가 없었습니다. 저장 버튼은 「저장됨」, 배포 화면은 「SUCCESS」, 인증서는 「확인 중」, 사이트는 열렸습니다. 그런데 안 됐습니다.
에러가 있으면 적어도 어디를 볼지는 압니다. 「성공」이 뜨면 거기는 안 봅니다. 그래서 문제가 있는 곳을 제일 늦게 보게 됩니다. 이 글은 그런 다섯 번의 기록이고, 각각 「무엇이 성공이라고 했는지」와 「실제로 어디를 봐야 보였는지」를 나란히 적었습니다.
사무자동화를 만들면서도 같은 종류를 겪은 적이 있습니다. n8n 실패 알림을 만들 때 실패인데 초록 체크가 뜨는 경우가 세 가지 나왔고, 매일 아침 보고 메일은 편집기 시험을 세 번 다 통과하고도 트리거로 처음 돌 때 실패했습니다. 사이트를 세우면서 만난 것은 그 서버판이었습니다.
1. 저장은 됐는데, 세상의 절반에서만 동작했습니다 — 루트 도메인의 CNAME
회사 도메인의 루트 주소(www가 없는 주소)를 서버에 연결하려고 CNAME 레코드를 넣었습니다. 등록처 화면은 이 값을 받아 줬고, 저장도 성공했습니다. 사이트도 열렸습니다.
그런데 그 뒤로 도메인 소유권 확인이 막혔습니다. 검색 엔진에 사이트를 등록하려면 도메인에 TXT 레코드를 넣어 소유권을 확인하는데, 그게 실패했습니다. 소유권 확인이 막히니 그다음 단계인 사이트맵 제출까지 연쇄로 막혔습니다.
원인은 CNAME의 성질이었습니다. CNAME을 넣은 이름에는 다른 레코드가 같이 있을 수 없습니다. DNS의 원 규정인 RFC 1034(3.6.2절)에 「If a CNAME RR is present at a node, no other data should be present」라고 적혀 있고, 운영 규칙 문서 RFC 1912(2.4절)도 「A CNAME record is not allowed to coexist with any other data」라고 적고 있습니다. 루트에 CNAME을 두자, 루트의 TXT·MX·A를 조회하면 전부 CNAME이 돌아왔습니다. 소유권 확인용 TXT를 넣어도, 조회하는 쪽에서는 그 TXT가 보이지 않는 것입니다. 등록처가 입력을 받아 줬다고 해서 그 설정이 규칙에 맞는 것은 아니었습니다.
더 헷갈렸던 것은 같은 도메인을 물었는데 조회하는 DNS 서버에 따라 답이 달랐다는 점입니다. 한쪽은 값을 돌려줬고 한쪽은 주지 않았습니다. 어느 쪽이 맞는지가 아니라, 등록이 됐는데도 보는 곳마다 다르게 보인다는 것이 문제였습니다. 저장은 성공이고 화면도 정상인데, 세상의 절반에서만 동작했습니다.
| 성공이라고 한 것 | 실제로 봐야 했던 것 |
|---|---|
| 등록처 화면의 저장 | 루트에 CNAME이 있는지, 같은 이름에 다른 레코드를 넣었는지 |
| 내 브라우저에서 사이트가 열림 | 다른 공개 DNS 서버 두 곳 이상에 같은 질문을 했을 때 답이 같은지 |
2. 에러 없이 「확인 중」에서 멈췄습니다 — 인증서의 TXT
HTTPS 인증서를 받으려면 이 도메인이 우리 것이라는 확인이 필요합니다. 서버 화면이 알려 준 대로 CNAME 레코드를 넣었습니다. 그리고 1시간이 넘도록 상태가 「확인 중」이었습니다. 에러는 없었습니다.
알고 보니 소유권 확인용 TXT 레코드가 하나 더 필요했습니다. 그런데 그 값은 화면의 DNS 목록에는 나오지 않았고, 서버 API가 돌려주는 별도 필드에만 있었습니다. 그 TXT를 넣자 4분 뒤에 인증서가 발급됐습니다.
함정은 「예전에는 CNAME만으로 됐다」는 기억이었습니다. TXT는 나중에 추가된 요구사항이었고, 화면은 그걸 보여 주지 않았습니다. 넣지 않으면 실패도 아니고 성공도 아닌 「확인 중」이 무한정 이어집니다.
| 성공이라고 한 것 | 실제로 봐야 했던 것 |
|---|---|
| 「확인 중」(실패가 아님) | 화면 목록 말고 API 응답의 모든 필드. 요구하는 레코드가 몇 개인지 |
| CNAME 저장 | 1시간 넘게 그대로면 멈춘 것. 4분이면 되는 일이었습니다 |
3. DNS도 맞고 인증서도 유효한데 502 — 포트
도메인을 서버에 붙이는 작업을 화면이 아니라 명령(API)으로 했습니다. DNS는 맞았고 인증서도 유효했습니다. 그런데 사이트를 열면 502(Bad Gateway)만 나왔습니다.
원인은 포트였습니다. 화면에서 도메인을 만들면 요청을 넘겨줄 포트가 자동으로 잡히는데, API로 만들면 잡히지 않았습니다. 중간 서비스는 요청을 받긴 하는데 서버의 어디로 넘길지를 몰랐던 것입니다. 같은 일을 화면으로 하느냐 명령으로 하느냐에 따라 결과가 달랐습니다.
DNS와 인증서가 맞으니 그쪽은 계속 정상으로 보였습니다. 원인이 보인 곳은 응답 헤더였습니다. 502를 누가 돌려주는지를 보니, 서버가 아니라 그 앞의 중간 서비스였습니다.
| 성공이라고 한 것 | 실제로 봐야 했던 것 |
|---|---|
| DNS 조회 정상, 인증서 유효 | 응답 헤더 — 502를 서버가 준 것인지 그 앞 단계가 준 것인지 |
| API가 도메인을 만들었다고 응답 | 화면으로 만들 때와 같은 설정(포트)이 들어갔는지 |
4. 배포는 SUCCESS인데 502 — 우리 설정이 아니었습니다
워드프레스 공식 이미지로 배포했습니다. 배포 화면은 SUCCESS였습니다. 사이트는 502였습니다.
배포 화면이 성공이라, 우리가 바꾼 설정을 몇 번이나 다시 봤습니다. 원인은 거기가 아니었습니다. 기동하면서 이 줄을 남기고 멈춰 있었습니다.
More than one MPM loaded
웹 서버(아파치)의 처리 방식 모듈이 두 개 동시에 켜져서 기동에 실패한 것이었습니다. 우리 설정이 아니라 이미지 쪽 문제였습니다. 배포가 성공했다는 것은 「이미지를 받아서 올렸다」까지였고, 그 안의 웹 서버가 떴다는 뜻은 아니었습니다.
| 성공이라고 한 것 | 실제로 봐야 했던 것 |
|---|---|
| 배포 SUCCESS | 컨테이너 안 웹 서버의 기동 로그 |
| 우리가 바꾼 설정 (계속 의심함) | 받아 온 이미지 자체의 기본 설정 |
5. 사이트는 열리는데, 글 안의 링크 30개가 한꺼번에 죽었습니다
마지막이 가장 컸습니다.
서버에는 www 주소만 등록하고, 루트 주소는 www로 걸어 두었습니다. 사이트는 www로 잘 열렸습니다. DNS도 정상이었습니다.
그런데 루트 주소로 들어오면 404가 났습니다. 이름은 풀리고, 중간 서비스는 요청을 서버로 넘기는데, 서버가 그 주소를 모르는 것입니다. 서버에는 www만 등록돼 있었으니까요. DNS가 정상이라 DNS 문제로는 보이지 않았습니다.
문제는 본문이었습니다. 글 안의 내부 링크가 전부 루트 주소를 쓰고 있었습니다. 그래서 링크 30개가 한꺼번에 죽었습니다. 메인 화면도, 글도 열리는데, 글 안에서 다른 글로 가는 링크만 전부 404인 상태입니다. 사이트를 열어서 둘러보는 것으로는 보이지 않습니다. 링크를 하나씩 눌러 봐야 보입니다.
하나 더 있었습니다. 루트와 www는 연결 대상 값이 서로 달랐습니다. www에 넣은 값을 루트에 그대로 복사하면 안 됐고, 실제로 확인해 보니 달랐습니다.
| 성공이라고 한 것 | 실제로 봐야 했던 것 |
|---|---|
www로 사이트가 열림 |
루트 주소로도 열리는지. 서버에 두 주소가 다 등록됐는지 |
| DNS 정상 | 본문 안 링크가 어느 주소를 쓰는지, 그 주소로 실제 응답이 오는지 |
www 값을 루트에도 복사 |
주소마다 서버가 알려 주는 연결 값을 따로 받기 |
다섯 번에서 얻은 확인 순서
다섯 번 모두, 「성공」을 말한 쪽은 그 단계 하나만 책임지고 있었습니다. 등록처는 값을 저장했고, 배포 화면은 이미지를 올렸고, 인증서 화면은 요청을 받았습니다. 그 다음이 되는지는 아무도 말해 주지 않았습니다.
그래서 이런 순서로 확인하게 됐습니다.
- 화면의 성공 대신 끝에서 확인합니다. 사이트가 열리는지가 아니라, 사용자가 실제로 누를 주소(루트,
www, 글 안의 링크)에서 응답이 오는지 - 한 곳에서 묻지 않습니다. DNS는 공개 DNS 서버 두 곳 이상에 물어서 답이 같은지 봅니다
- 화면에 없는 값이 있을 수 있다고 봅니다. 화면 목록과 API 응답이 다를 때는 API 쪽이 전부입니다
- 「확인 중」「진행 중」에 시간 한도를 둡니다. 한도를 넘으면 기다릴 게 아니라 빠진 것을 찾습니다
- 502·404는 누가 돌려줬는지부터 봅니다. 응답 헤더에 답이 있습니다
- 우리가 바꾼 것만 의심하지 않습니다. 받아 온 이미지나 기본값이 원인일 수 있습니다
사무자동화 쪽에서 배운 것도 같았습니다. 실행 기록에 「완료됨」이 찍혔는데 메일이 없던 것, 작업 스케줄러는 「준비」라고 하는데 n8n은 살아 있던 것. 도구가 보여 주는 상태는 그 도구가 아는 범위까지입니다.
이 글이 다루지 않은 것
사용한 서비스와 등록처의 이름은 적지 않았습니다. 같은 증상이 다른 서비스에서도 같은 원인으로 나는지는 확인하지 않았습니다.
각 사례에서 걸린 시간은 기록에 남은 것(인증서 1시간 넘게, TXT 뒤 4분)만 적었습니다.
요약
| 화면이 보여 준 것 | 실제 상태 | 봐야 했던 곳 |
|---|---|---|
| 저장됨 (루트 CNAME) | 같은 이름의 TXT·MX가 안 보임, DNS 서버마다 답이 다름 | 공개 DNS 서버 두 곳 이상 |
| 확인 중 (인증서) | TXT가 빠져 무한 대기. 넣고 4분 뒤 발급 | API 응답의 별도 필드 |
| DNS·인증서 정상 | 502. API로 만든 도메인에 포트가 안 잡힘 | 응답 헤더 |
| 배포 SUCCESS | 502. More than one MPM loaded | 웹 서버 기동 로그 |
www로 사이트 열림 |
루트 주소 404, 글 안 링크 30개가 죽음 | 본문 링크를 실제로 눌러 보기 |
「성공」은 그 단계가 끝났다는 뜻이었지, 사이트가 된다는 뜻이 아니었습니다.
비슷한 데서 막혀 계시다면
저장도 됐고 배포도 성공인데 사이트나 자동화가 안 되는 상태라면, 어느 단계의 「성공」까지 확인하셨는지 적어서 문의로 알려 주십시오. 위 순서대로 어디서부터 봐야 할지 같이 짚어 드릴 수 있습니다.
참고 (2026-09-23 확인)
– RFC 1034 「Domain Concepts and Facilities」 3.6.2 Aliases and canonical names: 「If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.」
– RFC 1912 「Common DNS Operational and Configuration Errors」 2.4 CNAME records: 「A CNAME record is not allowed to coexist with any other data.」