품앗이 위키

도메인 회수와 사이트 직접 관리

20 min read

도메인 회수와 사이트 직접 관리

외주에 묶인 홈페이지를 조직 명의로 다시 세우고, 조직이 직접 고치게 하기까지

의료복지사협·자활 기관·로컬푸드 협동조합·교육원·영농형 태양광 협동조합 연합회 현장에서 도메인과 홈페이지를 조직 손으로 되찾은 과정을 순서대로 정리했습니다. 업종이 달라도 같은 순서로 쓸 수 있게 일반화했습니다.

1. 도메인의 진짜 열쇠는 소유자 연락처 두 칸입니다

등록기관 문서와 현장 실측을 맞춰 보면 도메인 관리에는 층이 둘 있습니다.

하는 일필요한 것
DNS 레코드 추가·수정등록기관 계정 로그인
네임서버 변경, 소유자 정보 변경소유자 본인인증. 등록된 이메일 또는 휴대폰

법인 도메인은 주민등록번호를 받지 않기 때문에, 등록된 소유자 이메일과 휴대폰이 사실상 유일한 소유권 확인 수단이라고 등록기관 문서는 설명합니다. 그 두 칸을 쥔 사람이 도메인을 쥡니다.

한 교육원 현장에서 실제로 이런 일이 있었습니다. 등록인 이름은 조직으로 맞게 들어가 있었는데, 책임자 이메일은 도메인 등록 9일 전에 만들어진 개인 메일 계정이었고 휴대폰도 조직 사람 번호가 아니었습니다. 등록을 대행한 업체 쪽 사람이 자기 연락처로 잡아 둔 것으로 보입니다. 조직 담당자는 3년 동안 DNS 레코드만 편집해 왔기 때문에 이 사실을 몰랐고, 품앗이가 네임서버를 옮기려는 순간 처음 드러났습니다. 공개 조회에 나오는 책임자 전화와 등록기관 화면의 휴대폰 번호가 서로 달랐다는 것도 이때 알았습니다. 그래서 공개 조회와 등록기관 화면 두 곳을 다 봐야 한다고 봅니다.

점검은 두 단으로 합니다.

  1. 소유자 칸이 가리키는 곳이 조직인지 공개 조회와 등록기관 화면을 둘 다 봅니다.
  2. 그곳을 조직이 열 수 있는지 봅니다. 소유자 이메일이 조직 공용 주소여도, 그 메일함의 비밀번호와 2단계 인증 복구 연락처가 한 개인에게만 있으면 실질 통제는 그 개인에게 있습니다.

되찾는 길. 기존 연락처로 인증이 안 되면, 소유자가 법인인 경우 등록기관의 소유자 추가 인증 메뉴에서 사업자등록증명원 같은 서류를 올려 새 연락처로 바꿀 수 있습니다. 이때 새 연락처는 그 조직의 공용 주소와 대표 휴대폰으로 넣습니다. 품앗이 사람의 연락처를 넣으면 나중에 넘길 때 같은 문제가 반복됩니다.

대조군도 있었습니다. 한 로컬푸드 협동조합은 대행업체 없이 법인 계정으로 도메인만 직접 샀고, 등록자·소유자 이메일·계정 세 칸이 처음부터 조직 것이었습니다. 휴대폰 칸만 담당자 개인 번호였는데, 담당자 본인이면 실무상 정상이므로 바꾸라고 요구하지 않고 「담당이 바뀌면 이 칸도 같이 바꾼다」를 기록으로 남겼습니다.

2. 조직 명의의 클라우드 계정을 조직이 만든다

도메인을 옮겨 갈 클라우드플레어 계정은 조직이 직접 가입합니다. 품앗이 계정에 조직 도메인을 넣지 않습니다.

자활 기관 현장에서 쓴 방식은 이렇습니다.

  1. 기관 담당자가 기관 메일 주소로 계정을 만든다
  2. 담당자가 품앗이 계정을 관리자 멤버로 초대한다
  3. 비밀번호와 토큰은 주고받지 않으며, 계정 주인은 기관이고 기관은 언제든 품앗이를 뺄 수 있다

이 과정에서 실측한 함정이 둘 있습니다. 가입 뒤 확인 메일을 열지 않으면 멤버 초대가 막힙니다. 그리고 클라우드플레어의 일반 관리자 역할로는 계정에 도메인을 새로 추가할 수 없고 최고관리자만 할 수 있습니다. 도메인을 계정에 붙이는 한 번은 조직 담당자 손으로 하고, 그 뒤 도메인 안의 설정은 관리자 역할로 다 됩니다.

계정 주인은 공용 주소로 세운다. 한 영농형 태양광 협동조합 연합회 현장에서 품앗이는 담당자 개인 메일로 계정을 만들어 달라고 안내했는데, 담당자는 이미 있던 조합 공용 주소로 만들었습니다. 담당자가 바뀌어도 계정이 조합에 남기 때문에 품앗이는 그 선택을 그대로 따랐습니다. 이 현장은 도메인이 외주가 아니라 품앗이 쪽 개인 계정에 있던 경우였고, 그래서 열쇠를 넘기는 쪽이 품앗이였습니다.

3. 네임서버를 옮길 때

레코드를 그대로 복제하고 옮긴다. 기존 레코드를 새 네임서버에 그대로 복제해 두면 현재 사이트는 원래 서버에서 그대로 돌고, 클라우드플레어 프록시가 https를 바로 붙여 줍니다. 한 의료복지사협 현장에서는 https 주소로 사이트가 열리지 않던 문제가 이것으로 사이트 이전보다 먼저 풀렸습니다.

메일 레코드를 먼저 지킨다. MX와 SPF 레코드가 틀어지면 그날 조직 메일이 멈춘다는 것이 작업 기록의 경고입니다. 연합회 현장에서는 이 순서가 더 무거웠습니다. 새 클라우드 계정 주인의 메일함이 바로 옮기려는 도메인의 메일 레코드에 물려 있었기 때문입니다. 네임서버를 먼저 바꾸고 새 쪽에 메일 레코드가 없으면, 비밀번호나 2단계 인증을 다시 잡아야 할 때 계정 주인이 자기 계정에서 잠깁니다. 그래서 새 쪽에 메일과 소유 확인 레코드를 가장 먼저 넣고 네임서버는 그 뒤에 바꿨습니다. 작업 기록은 전체 이관에서 가장 중요한 검증을 계정 주인 메일의 실물 수신으로 꼽았고, 담당자의 수신 회신으로 확인했습니다.

넘기기 전에 새 네임서버에 직접 묻는다. 새 네임서버에 레코드를 하나하나 질의해 전부 맞는 것을 확인한 다음에 네임서버를 바꿉니다.

네임서버 값은 손으로 옮겨 적게 하지 않는다. 연합회 현장에서 담당자가 등록기관 화면에 새 네임서버 이름을 넣다가 한 글자가 빠졌습니다. 작업 기록에 남은 원인의 사슬은 이렇습니다. 존재하지 않는 이름이 들어가자 클라우드플레어가 위임을 확인하지 못했고, 새 영역이 대기 상태에 머물러 프록시가 돌지 않았으며, 터널로 내보내던 상담 AI 주소부터 내려갔습니다. 오타를 바로잡자 복구됐고, 그 다음 단계 안내부터는 복사·붙여넣기와 생성 버튼으로만 값을 넣게 했습니다.

사이트 주소 연결도 계정을 따라 옮긴다. 같은 현장 기록에 따르면 DNS가 새 계정으로 넘어온 뒤에도, 같은 주소가 옛 계정의 Pages 프로젝트에 연결돼 있으면 새 계정 쪽 연결은 대기로 남습니다. 서비스는 정상으로 보이지만 사이트를 내주는 주체는 아직 옛 계정입니다. 옛 쪽 연결을 풀어야 이관이 끝납니다.

4. 외주 사이트를 넘겨받을 때

요청은 조직이 업체에 한다. 외주 업체에서 자료를 넘겨받아야 할 때 품앗이는 업체와 조직 사이에 끼지 않습니다. 품앗이가 처음에 「넘겨받는 방법은 저희가 업체 담당자와 직접 맞추겠다」고 썼다가 고친 일이 있습니다. 지금은 업체에 그대로 보낼 요청 항목을 정리해 조직에 드리고, 요청과 답은 조직과 업체 사이에서 오갑니다. 한 사이트 이전에서 정리한 요청 항목은 이랬습니다.

  • 회원 표 전체 컬럼 덤프
  • 비밀번호 해시 방식과 솔트
  • 암호를 건 압축 파일, 비밀번호는 별도 문자로
  • 받을 조직 담당자 메일
  • 전환일까지 기존 서버 유지

원본은 건드리지 않고 통째로 보관한다. 자활 기관 현장에서는 22년치 게시글과 첨부를 먼저 통째로 받아 두었습니다. 받는 도중 일부 오래된 사진은 이미 서버에서 파일이 사라진 뒤였습니다. 오늘 받지 않으면 다음에 무엇이 사라질지 모른다는 뜻으로 읽었습니다.

남의 서버에는 속도 상한을 건다. 품앗이는 한 현장에서 자료 수집과 링크 반복 검사를 겹쳐 돌리다가 업체 서버를 멈춰 세운 적이 있습니다. 그 뒤로는 남의 운영 서버를 읽을 때 요청 사이에 1~2초 간격을 두고, 업무 시간을 피하고, 재시도 없이 한 번만 봅니다.

옛 서버로 가는 통로를 남긴다. 로그인 뒤에 있어 안을 못 본 자료가 있으면 원서버를 끄지 않고 별도 주소로 닿을 길을 남깁니다.

되돌리기를 먼저 실증한다. 새 사이트로 바꾸기 전에 원래 사이트로 돌아가는 스크립트를 만들고 실제로 왕복해 봅니다. 자활 기관 현장에서는 원래 사이트로 45초, 새 사이트로 다시 2분이 채 안 걸렸고, 왕복 뒤 DNS 설정 차이가 0줄이었습니다. 이 과정의 기록에는 함정 하나가 적혀 있습니다. 클라우드플레어 Pages에 사이트 주소를 연결해 두면 DNS 레코드를 되돌려도 그 주소는 Pages로 갑니다. 되돌리기에는 Pages의 주소 연결 해제가 함께 들어가야 합니다.

없는 주소에는 404를 준다. Pages는 404 페이지가 없으면 없는 경로에도 첫 화면을 200으로 돌려줍니다. 옛 로그인 주소로 들어온 조합원이 첫 화면만 보고 왜 안 되는지 모르게 됩니다. 그래서 404 페이지를 따로 두는 것이 품앗이의 처방입니다.

5. 조직 AI가 직접 고치고 올린다

현장 기록을 보면 사이트를 옮기는 것으로 일이 끝나지 않습니다. 조직이 품앗이에 부탁하지 않고 고칠 수 있어야 합니다.

퍼블리셔 구조. 로컬푸드 협동조합 두 곳은 각자 자기 도메인·자기 클라우드 계정·자기 서버를 이미 쥐고 있었고, 빠져 있던 것은 홈페이지 소스와 배포 열쇠 둘뿐이었습니다. 그래서 조직마다 스크립트를 따로 만들지 않고 다음처럼 짰습니다.

조각위치
올리는 스크립트공용 한 벌을 조직 서버에 둔다
조직별 설정조직 서버 안 설정 파일 하나. 업무 AI 작업 폴더 밖에 둔다
정본 소스와 사진담당자가 탐색기로 여는 공유 폴더
배포 백업배포할 때마다 소스와 사진을 통째로 보관

인자 없이 실행하면 미리보기로 올라가고, 라이브는 명시해야 올라가도록 기본값을 미리보기로 두었습니다. 담당자는 사진을 공유 폴더에 넣고, 업무 AI에게 고쳐 달라고 말하고, 미리보기를 본 뒤 라이브로 올립니다.

검산은 빌드 표식으로 한다. 작업 기록에 따르면 배포마다 빌드 표식을 심어 라이브 페이지에서 그 표식이 보이는지로 판정합니다. 클라우드 쪽이 페이지 본문에 스크립트를 끼워 넣기 때문에 파일 해시 대조는 판정이 되지 못했습니다.

통째로 올리면 소스에 없는 파일은 사라진다. 매장 진열대 가격표에 인쇄된 QR이 가리키는 경로처럼, 사이트 밖에서 이미 쓰이는 주소는 필수 목록으로 묶어 두고 배포 전에 있는지 확인합니다.

게시판은 함수 한 겹으로 연다. 자활 기관 현장에서는 담당자 AI가 공지와 사진을 올리고 고정 페이지 문구까지 고칠 수 있는 통로를 열었습니다. 그 통로는 사용법을 물으면 한국어 설명을 돌려주게 짜서, 담당자 AI가 따로 문서를 들고 다닐 필요가 없습니다. 열쇠 원문은 담당자에게 건네고 DB에는 해시만 둡니다. 데이터베이스 계정을 통째로 주지 않은 이유는, 그 DB가 여러 조직이 함께 쓰는 프로젝트라 계정을 주면 다른 조직 표까지 손이 닿기 때문이었습니다. 함수 한 겹이 손이 닿는 범위를 그 기관 표 세 개와 저장소 하나로 좁혔습니다.

판정은 「통로가 섰는가」가 아닙니다. 담당자가 품앗이 없이 공지 한 건을 올렸는가로 봅니다.

6. 조직에 넘긴다

마지막 단계는 소스·배포 열쇠·도메인·계정이 모두 조직 쪽에 있는 상태로 넘기는 것입니다. 한 협동조합 보고서는 이 상태를 「품앗이에게 부탁하지 않아도 되는 상태」로 적었습니다. 의료복지사협 현장에서는 이 과정으로 매달 나가던 홈페이지 관리비와 건별 수정료가 없어졌습니다.

넘길 때 조직 쪽 AI의 지시문도 같이 봐야 합니다. 「홈페이지는 품앗이 몫」 같은 문장이 남아 있으면 조직 AI가 스스로 멈춥니다.

관련 노드

작성: 품앗이 · 2026-10-15 · 다섯 현장의 도메인·홈페이지 이전 실측 기준

그래프 뷰

백링크