- 회원들이 추천해주신 좋은 글들을 따로 모아놓는 공간입니다.
- 추천글은 매주 자문단의 투표로 선정됩니다.
Date | 24/04/17 04:17:08 |
Name | 와짱 |
Subject | 개인위키 제작기 |
0. 이번 학기에 듣는 수업 중 하나는 교수님께서 만드신 개인 위키를 통해서 이루어집니다. 컴공 수업이라면 특별한 일이 아닐지도 모르겠지만(컴공에서도 특별한 일일 것 같긴 한데 모르겠습니다) 이 수업은 국문학 전공 수업이라는 점에서 특이하죠. 직접 위키를 만든다거나... 그런 수업을 하는 건 당연히 아니고, 과제 제출이나 공지 등을 위키 시스템을 통해서 하는 정도이긴 하지만 굉장히 재밌는 수업방식이라고 느꼈어요. 교수님께서 인문학을 배우다가 기술에 뒤쳐지지는 않았으면 좋겠다고 말하셨어요. 여기에는 약간의 감명까지도 받았습니다. 사실 저도 개인 위키를 만드는 일에 굉장히 관심이 많았습니다. 오픈나무(https://namu.wiki/w/openNAMU)라는 프로그램을 받아서 사용해보기도 했어요. 다만 이쪽은 웹사이트를 제작해서 운영하는 것이 아니라, 제 개인 컴퓨터에 파일 형태로 넣어놓고 필요할 때마다 파일을 열어서 메모해두는 방식으로만 사용했습니다. 당연히 접근성이라는 측면에서 굉장히 떨어지는 형태였고, 자주 사용하지는 않았어요. 특히 노션을 사용하게 된 이후로는 거의 사용하지 않았습니다. 사실 노션을 사용하면 개인 위키의 장점이 그리 크지 않기는 해요. 그런데... 그래도 한번 만들어 보고 싶어지더라고요 ㅎㅎ 이번 기회에 한번 만들어 보기로 마음먹었습니다. 무엇보다도 어딘가에서 막히면 교수님께 질문을 드릴 수 있을 거라고 생각하니 자신감이 붙었어요. 결과적으로, 교수님께 질문을 드리지 않고도 성공적으로 웹사이트를 제작했습니다. 그러나 그 과정에서 굉장히 갖은 뻘짓과 치열한 구글링이 있었어요. 힘들게 완성하고 나니 어딘가에 자랑하지 않고서는 억울해서 미칠 것 같아집니다. 예. 이 글의 목적은 '나 이렇게 대단한일(아님)했다'고 자랑하기 위함입니다. 칭찬해주세요. 빨리. 1. 호스팅 교수님의 위키는 카페24라는 웹호스팅 업체를 사용하고 있었습니다. 이 업체는 저도 예전에 개인위키 제작을 알아보면서 들어봤던 곳이었어요. 이 업체의 장점이라면 역시 가격입니다. 웹하드 용량 500mb 정도를 월 500원으로 이용할 수 있어요. 미디어위키 설치가 완료된 후 약 470mb 정도를 썼던 걸로 기억하고, 지금 몇가지 옵션들을 건드린 후에는 479mb를 쓰고 있습니다. 훗날 용량이 많아진다면 추가 결제가 필요할 수도 있겠지만, 그걸 감안하더라도 가격에 부담이 덜합니다. 사실 로망이라면 자체적으로 서버를 한 대 돌리는 거긴 한데, 이쪽은 무리였어요. 일단 가장 커다란 이유는 제가 잘 알지 못합니다. 진짜 잘 몰라서 뭘 모르는지도 모르는 수준이고, 건드릴 엄두가 안 났습니다. 교수님은 웹호스팅 서비스를 사용하고 계시니 이것과 관련해서 질문을 드릴 수도 없었고요. 그 외에 다른 이유로는, 서버를 직접 돌린다면 서버를 항상 켜놓고 있어야 할텐데(상술했듯이 저는 이쪽으로 무지하기 때문에 어쩌면 아닐수도 있겠습니다), 저는 꽤 고사양의 글카를 사용하기 때문에 전기료가 부담이었습니다. 미니pc를 사는 것도 고려해볼 수 있겠지만 단기적으로는 비용 부담이 오히려 더 많아질테니까요. 저는 어디까지나 실험적으로 만들어볼 생각이었습니다. 어쩌면 다음달부터 바로 접어버릴지도 모르는 위키입니다. 2. 도메인 카페24 웹호스팅 서비스를 사용하면 자동적으로 도메인을 발급해줍니다. 다만 사용자아이디.cafe24.com 형태의 도메인이기 때문에 간지가 안나요. 간지는 중요한 문제입니다(...) 도메인 하나 멋있는걸 샀습니다. 처음 계획은 닷네임코리아라는 곳에서 구입할 예정이었는데 구글 검색 자동완성으로 닷네임코리아 쓰레기가 뜨는걸 보고 급하게 다른 업체를 알아봤습니다. 후이즈라는 곳이 평가가 괜찮아보였는데, 카페24에서도 도메인 발급 서비스를 해주더라고요. 가격을 비교해보니 카페24가 더 쌌습니다. 도메인을 2년 단위로만 팔더라고요. 저는 실험적으로 만들어볼 생각이었기 때문에 2년까지는 필요가 없었지만, 어쩔 수 없이 2년치를 샀습니다. 이 글을 쓰면서 확인해보니 무료 도메인 발급 서비스도 있네요. 다시는 저와 같은 불행한 유저가 없기를 바랍니다. 아... 3. 위키 설치 호스팅과 도메인을 결제하기 전에 나름대로 알아보기는 했는데, 실제로 진행을 해보니까 생각하지 못한 부분이 굉장히 많았습니다. 우선 오픈나무 프로그램을 사용할 수가 없었습니다. 오픈나무라는 프로그램은 파이썬을 통해 돌아가는 프로그램인데, 카페24를 통한 웹호스팅으로는 파이썬을 사용할 수 없다는 것 같습니다. 파이썬을 지원해주는 웹호스팅 업체를 알아볼까 고민했지만, 이미 결제한 금액이 아까웠습니다. 미디어위키를 설치하는 쪽으로 방향을 바꿨습니다. 좀 부끄러운데, 저는 웹호스팅 서비스를 결제하면 관리페이지에 파일 업로드 버튼 같은게 있을 거라고 생각했어요. 알아보니 그렇지 않고 ftp 프로그램이라는걸 사용해서 제 데스크탑과 웹서버를 연결해줘야 한다고 합니다. 이쪽으로 가장 유명한 프로그램이 filezila라는 프로그램인 것 같았습니다. filezila를 설치했더니 호스트, 사용자명, 비밀번호, 포트를 입력하라는 창이 보입니다. 비밀번호는 웹호스팅 결제를 할때 뭔가 입력하라고 떴던 기억이 나서 그거라고 추측할 수 있었지만, 호스트 사용자명 포트는 대체 뭔지... 다행히 구글링을 하니 설명해주는 블로그가 있었습니다. 호스트에는 도메인 주소, 사용자명에는 카페24 아이디, 포트에는 아무것도 입력하지 않아도 된다고 합니다. 하라는 대로 합니다. 안됩니다. 왜 이러는거지... 알고봤더니 도메인 주소에서 http://를 제거하고 넣어야 했습니다. 다시 했더니 이번에는 연결이 됩니다. 좀 쪽팔리고 살짝 화도 나지만 아무튼 신기하고 기쁩니다. 미디어위키 파일을 업로드해줍니다. 잘 되다가 갑자기 전송 오류가 뜹니다. 오류 메세지를 ctrl cv해서 구글에 검색했더니 저랑 같은 증상을 겪은 사람이 올린 질문글이 있습니다. 너무 많은 파일을 전송하면 그럴 수 있다고 합니다. 그게 ftp 프로그램의 태생적 한계이고 그나마 그 중에서 가장 나은 프로그램이 filezila라고 합니다. 어쩔 수 없이 파일을 여러번에 걸쳐서 나눠 보냅니다. 하다가 살짝 화나서 압축파일 째로 올려봅니다. 당연히 filezila에 압축 해제 기능은 없습니다. 압축파일을 삭제하고 마저 업로드를 합니다... 업로드를 다 했으니 이제 위키가 설치됐을거라 생각하고 들어가봅니다. 안들어가집니다. 다시 구글링을 합니다. 블로그를 발견합니다. 설치페이지로 이동한 후에 설치를 시작할 수 있다고 합니다. 설치페이지로 어떻게 이동하는지는 설명해주지 않습니다. 다시 구글링을 합니다. 다른 블로그를 발견합니다. 특정한 도메인을 입력하면 설치페이지로 이동할 수 있다는 것 같습니다. 어떤 도메인인지는 안알려줍니다. 다시 구글링을 합니다...... 설치페이지 도메인을 알아낸 후에 설치를 완료했습니다. 이 시점에서, 프로그래머들의 주 업무는 코딩이 아니라 구글링이라는 농담을 이해했습니다. 구글은 신이야. 구글펀치. 4. 대문 이미지와 파비콘 고생고생해가며 위키 설치를 완료했더니 뿌듯함이 몰려옵니다. 그런데 그것도 잠시, 위키 좌상단의 임시땜빵용 이미지가 몹시 거슬립니다. 교수님의 위키를 보니 그곳에 웬 거위 이미지가 올라와 있습니다. 솔직히 저대로 놔둬도 상관없는데, 괜히 경쟁심리가 생깁니다. 일단 이미지를 만듭니다. 혹시라도 트러블이 생기고 싶지는 않으니 저작권 문제가 생기지 않는 이미지 제작 사이트를 알아봅니다. canva에서 ai를 통해 자동으로 로고를 생성해준다는 것을 알게됩니다. canva는 팀플 과제용 ppt를 만들면서 한번 써봤는데, 그때도 굉장히 유용하다는 인상을 받았던 적이 있습니다. 그런데 로고도 만들어주면서 저작권 문제도 자유롭다니, 대단하더라고요. 저는 디자인 감각이 좋은 편은 아니라서 로고를 별로 예쁘게 만들지는 못한 것 같지만, 아무튼 적당히 괜찮아보이는 로고를 만들었습니다. 화질이 조금 아쉬웠지만 그럭저럭 괜찮았습니다. 로고를 축소해서 파비콘 이미지도 만들어줍니다. 그리고 여기서부터 본격적으로 위키 시스템을 붙잡고 씨름을 하게 됩니다. 일단 가장 먼저 당황스러웠던 점은 위키에 파일 업로드 기능이 없었다는 점입니다. 위키백과를 자주 사용해보진 않았지만, 거기에 파일 업로드 기능이 없지는 않을텐데? 다시 구글링을 합니다. 파일 업로드 기능이 없는건 당연한 일이었습니다. 위키를 설치한 이후 따로 설정을 만들어줘야 한다고 해요. 그런데 설정을 만드는 방법이 제가 직접 프로그램을 건드려야 하는 방법이었습니다. .htaccess 파일이라는게 필요하다고 해요. ...저는 태어나서 처음 보는 확장자였습니다. 폴더에 .htaccess 파일이 있으면 수정을 하면 되고, 없으면 직접 만들어줘야 한다고 합니다. 저는 없었으니 직접 만들어야 했습니다. 어떻게 만드는지는 모르겠습니다. 다시 구글링을 합니다. visual studio code의 확장 프로그램을 설치하면 생성 및 수정이 가능하다고 합니다. 확장 프로그램을 설치합니다. 블로그에 올라온 코드를 복사해서 붙여넣기합니다. local setting.php라는 파일도 수정해줘야 한다고 합니다. 다시 코드를 복사붙여넣기 합니다. 위키를 새로고침하니 파일 업로드 기능이 생겼습니다. 신나서 로고와 파비콘 이미지를 업로드합니다. 그리고 대문 이미지 수정 버튼을 찾습니다. 버튼이 없습니다. 수정을 어떻게 하는지 모르겠습니다. 다시 구글링을 합니다. 알고보니 파일 업로드 기능과 대문 이미지 수정은 전혀 상관이 없었습니다. 어차피 필요한 일이었으니 오히려 잘된 일이었다고 자신을 위로합니다. 대문 이미지 수정을 위해서는 localsetting.php 파일을 수정한 후, 특정 폴더에 filezila 프로그램을 통해 이미지를 넣어줘야 했습니다. 앞서 localsetting파일을 수정해봤으니 이해가 쉽습니다. 블로그가 시키는 대로 한 후 위키를 새로고침했더니, 접속 자체가 안됩니다. 방금 수정했던 부분을 다시 지웠더니 접속이 정상적으로 됩니다. 구글링을 더 합니다... 다른 블로그는 다른 방법을 알려주고 있습니다. 똑같이 했더니 이번에는 접속은 되는데 화면이 깨집니다. 두 블로그의 설명을 적당히 절충시켰더니 정상적으로 작동이 됩니다. 왜 됐는지는 아직도 잘 모르겠습니다. 이번엔 파비콘을 수정해줄 차례입니다. 잔뜩 쫄아서 블로그가 시키는대로 했더니, 위키 접속이 안 되거나 화면이 깨지거나 하지는 않는데, 그냥 파비콘이 수정이 안 됩니다. 구글링을 한참 했더니 파비콘 이미지는 .ico라는 확장자를 쓰는게 기본이라고 합니다. png를 써도 된다고 하는 블로그도 있었는데 이건 아니지 않을까...? 그래도 이것 말고는 짐작가는 곳이 없습니다. png를 무료로 ico로 변환시켜주는 웹사이트가 있었습니다. 파일을 ico로 교체해줍니다. 여전히 안됩니다. 뭐가 문제지...... 한참 고민하다가 문득 깨달았습니다. 이미지를 변환하는 과정에서 파일 이름의 띄어쓰기에 하이픈(_)이 생겼습니다. 이걸 반영을 안했으니 작동이 안되는게 당연했습니다. 파일 이름을 수정해줬더니 파비콘이 정상적으로 적용됩니다. 대충 여기까지 꼬박 하루가 걸렸던 걸로 기억합니다. 5. 숏url 고생을 하긴 했지만 어쨌든 만들어놓으니 흐뭇합니다. 그런데 도메인 주소가 자꾸 못나보입니다. 그때 도메인 주소는 http://구매한도메인.com/mediawiki-1.41/index.php/대문 이었습니다. 이대로 써도 별 상관없긴 하지만, 제 머리로는 이 도메인 주소를 다 외울 수가 없습니다. 기왕에 쓸거면 좀 간단하고 깔끔한 도메인 주소를 쓰고 싶었습니다. 위키백과에서 쓰는 것과 똑같은 형식으로요. 찾아보니 숏url 기능이라는게 있습니다. 이걸 쓰면 http://구매한도메인.com/w/대문 형식의 도메인을 쓸 수 있다고 합니다. 이 기능은 크게 두 단계로 나뉘어진다고 합니다. mediawiki-1.41을 w(혹은 자신이 원하는 문구)로 변경하는 단계가 하나, index.php를 제거하는 단계가 둘입니다. 여기서부터는 블로그 공략으로는 알 수 없는 부분이 많았고, 미디어위키의 공식 안내 가이드를 같이 살펴볼 필요가 있었습니다. 문제는 그게 영어로 작성되었다는 점이죠. 엣지의 번역 기능이 생각보다 나쁘지 않아서 그렇게까지 힘들지는 않았습니다. 번역을 도저히 못알아보겠다 싶으면 페이지를 두개 띄워놓고 원문과 번역을 대조해가면서 읽었습니다. 두 단계 모두 생각보다 어렵지는 않았습니다. 위키가 저장되어있는 파일의 이름을 mediawiki-1.41에서 w로 바꿔주고, localsetting 파일과 .hataccess파일을 살짝 수정했더니 성공했습니다. 물론 몇번 시행착오는 있긴 했는데, 이쯤부터는 슬슬 적응이 됐다는 느낌입니다. 6. 외부 회원가입 허용 및 권한 분배 이 부분은 프로그램을 수정하는 방법 자체가 어려웠다기 보다는, 외부 이용자에게 권한을 어디까지 허용해줄지 고민하는 부분에서 시간이 많이 걸렸습니다. 문서의 수정을 저만 할 수 있게 한다는 원칙 자체는 위키를 만들 때부터 세운 원칙이었지만, 외부 이용자가 수정 요청을 할 수 있게 해주고 싶었어요. 그런데 미디어위키에서는 수정 요청이라는 기능 자체가 없는 것 같더라고요. 위키백과에서도 그런 기능이 없고요. 이메일 주소를 공개하고 이쪽을 통해서 수정 요청을 받을까도 고민해봤지만, 가급적 위키 자체로 완결성을 갖추고 싶었습니다. 고민끝에 외부 이용자에게 글의 수정 권한을 주고, 대신 각각의 문서들을 관리자만 수정할 수 있게 설정해놓기로 결정했습니다. 대신 건의함 문서를 만들어놓고 이곳을 통해서 편집 요청을 받는다는 안내를 해놓았어요. 이러면 문서를 새로 생성할 때마다 문서의 수정 권한을 바꿔줘야 한다는 불편함이 있지만, 어쩔 수 없었습니다. 사실 이 위키의 사용자들이 많이 생길 가능성이 희박한 상황에서, 이런 걸 굳이 신경쓸 필요는 없겠죠. 그냥 회원가입도 허용하지 않고, 편집 요청을 받을 루트도 없애고, 저 혼자만 수정 권한을 가지고 있어도 아무런 문제가 생기지 않을 거에요. 이건 완전히 쓸데없는 일입니다. 하지만 쓸데없는 일이 가장 재밌으니까요. 7. 각주 및 각주 미리보기 설정 여기까지 완성한 후 본격적으로 위키 문서를 만들었습니다. 위키백과 문법이 나무위키랑은 많이 다르더라고요. 나무위키 문법도 html과 비슷한 부분이 많다고 생각했는데, 위키백과는 html을 그대로 사용하는걸 장려한다는 인상도 받았습니다. 그러다가 각주 기능을 사용하려면 따로 설정을 바꿔줘야 한다는걸 깨달았어요. 다시 구글을 킵니다. 확실히 사람은 짬을 먹으면 실력이 늡니다. localsetting 파일을 살짝만 수정해주는 걸로 각주 기능을 이용할 수 있었습니다. 이제 다시 각주 기능을 사용해서 문서를 편집합니다. 그런데 뭔가 이상하다는걸 느낍니다. 뭔가... 뭔가 위키백과는 이거랑 좀 달랐던 것 같은데. 잘 생각해봤더니, 위키백과에서는 각주에 마우스 커서를 올려놓으면 미리보기 창이 떴다는걸 깨달았습니다. 제 위키는 그런 기능이 없습니다. 이것도 뭔가 설정을 바꿔줘야 하겠구나 하고 감이 옵니다. 다시 구글을 킵니다. 이번에는 설정을 바꿔주기 전에 확장 프로그램을 설치해줘야 한다고 합니다. filezila를 한 두번 써본 것도 아니고, 이제 이 정도는 간단하겠거니 생각합니다. 파일을 다운받습니다. 그런데 확장자가 zip가 아니라 이상한 확장자입니다. tar.gz...? 검색해보니 리눅스 쪽에서 주로 사용하는 압축 프로그램이라고 합니다. 다행히도 윈도우 환경에서도 압축을 해제할 수 있다고 합니다. 무슨 명령 프롬포트를 키라고 하는데, 무섭긴 해도 블로그의 설명이 꽤 친절하게 되어있습니다. 그대로 합니다. 안 됩니다. 다시 합니다. 안 됩니다. 아... 도저히 답이 없다 싶어서 유튜브를 켜서 검색을 해봅니다. 아하! 블로그에서 설명이 빠져있는 부분이 보입니다. cd라는 명령어를 통해 명령 프롬포트를 tar.gz 파일이 있는 폴더로 경로를 바꿔줘야 하는데(쓰면서도 솔직히 무슨 말인지 잘 모르겠습니다) 블로그에서는 경로를 바꿔주라는 설명만 해주고 cd라는 명령어를 안 알려준겁니다. 블로그 주인은 사람들이 당연히 이 정도는 알거라고 생각했겠지만, 그걸 제가 어떻게 압니까?? 아무튼, 요즘 정보를 구하기 위해서는 가장 먼저 유튜브를 찾아봐야 한다는 말이 사실이었다는걸 느끼면서 파일 압축을 풀어줍니다. 또 안 됩니다. 아... 또 한참동안 씨름하던 끝에 문제를 해결합니다. 문제의 원인은, 제 파일은 tar.gz 확장자라서 명령프롬포트에도 tar.gz라고 입력해줘야 하는데, tar이라고만 입력했던게 원인이었습니다. 블로그와 유튜브에서는 tar이라고만 나와있어서 생각을 못했습니다. 이런걸로 오류가 나는게 좀 쪽팔리기도 한데, 화가 나는게 더 컸던 것 같습니다. 화낼 대상이 없어서 조금 더 열받았던 것 같기도. 8. https 인증 여기까지 왔더니 살짝 눈에 뵈는게 없어진 것 같습니다. 갑자기 https 인증을 받고 싶어졌어요. 사실 이거 안해도 아무 상관 없다는건 압니다. 아는데, 여기까지 온 이상 뭔가 완벽하게 하고 싶어집니다. 카페24에 접속해서 알아보니 돈을 내면 인증을 대행해줍니다. 그런데 돈을 내는건 또 이야기가 다르죠. 조금 더 찾아봤더니 무료로 인증을 해주는 곳이 있다고 합니다. 한국어로 설명해주는 블로그들도 많이 있습니다. 블로그에서 소개해주는 zerossl이라는 사이트에 회원가입을 합니다. 이곳에서 인증을 하려면 웹사이트의 소유자가 저라는걸 증명해야 합니다. 증명하는 방식이 여러가지가 있는데 보통은 이메일을 사용하는 것 같더라고요. 그런데 제가 보기에는 오히려 이쪽이 더 복잡해 보였습니다. html 파일을 통해 인증받는 방식을 선택하기로 합니다. 이때 솔직히 좀 쫄았는데, filezola 프로그램을 통해 지정된 폴더에 html 파일을 집어넣기만 하면 되는 방식이라서 그렇게 어렵지는 않았습니다. 인증을 완료한 후에 카페24 관리 페이지를 통해 설정을 마무리해줍니다. 하나 걸리는 점은, 인증 기간이 90일이라는 점입니다. 이게 자동 갱신이 된다고 들은 것 같긴 한데, 확실하게는 잘 모르겠어요. 어쨌거나 이 위키는 장기적으로 운영되지 않을 수도 있는 실험용에 가까운 프로젝트였으니까요. 위키를 계속 사용할 마음이 들고, 90일 뒤에 자동 갱신이 안되면 그때 가서 어떻게 할지 생각해 보면 될 것 같습니다. http로 접속하더라도 자동적으로 https로 접속하는 시스템까지 만들어주고 싶었는데, 이것도 생각만큼 어렵진 않았어요. 아까 숏url을 설정하면서 만들었던 .htaccess 파일을 살짝 수정해주는 걸로 간단하게 완료했습니다. 블로거들에게 축복이 있기를. 9. 모바일 대응 하는 김에 모바일 대응까지 합니다. 솔직히 이건 진짜 할 생각 없었는데, 이 시점부터 '위키를' 만드는 게 아니라 위키를 '만드는' 쪽으로 관심이 옮겨간 것 같습니다. 기본적으로 각주 미리보기 설정을 했던 것과 과정이 크게 다르지 않았습니다. tar.gz 파일 다운받아서 설치해준 후, localsetting 파일 수정. 그런데 localsetting 파일을 수정하는 과정에서 조금 더 복잡했어요. 무엇보다 크게 해맸던 점은, 설치가 완료된 후에도 모바일 화면이 pc 화면과 똑같이 나왔다는 점이었습니다. 하단에 데스크탑 화면으로 보기/모바일 화면으로 보기 버튼이 생성된 것을 통해 설치가 완료되었다는 점은 분명했는데, 정작 화면은 똑같았으니 당황스러웠죠. 알고보니 모바일 화면은 미네르바 스킨을 사용해줘야 했습니다. 저는 그때 벡터 스킨을 사용하고 있었는데, 벡터 스킨을 모바일 화면에 띄우면 자동으로 모바일 최적화가 되는 구조가 아니라, pc에서는 벡터를, 모바일에서는 미네르바를 사용하게끔 설정해줘야 하더라고요. 이 부분을 변경해주면서 pc화면의 기본 스킨을 벡터에서 벡터-2022로 바꿔줬습니다. 이쪽 화면이 훨씬 깔끔하더라고요. 다른 커스텀 스킨을 알아볼까 고민하기도 했지만, 거기까지 가면 그건 정말로 투머치라는 생각이 들었습니다. 벡터-2022도 마음에 들어요. 10. 구글 서치 콘솔 등록 구글에 내 웹사이트를 검색했더니 나오면 좀 멋있을 것 같다...는 생각이 들었습니다. seo라는 개념이 있다는 건 이미 알고 있었어요. 관련해서 찾아보니까 구글 서치 콘솔이라는 곳에 웹사이트를 등록하면 검색엔진에 잡히게 된다는 것 같았습니다. 구글 서치 콘솔에 접속했더니 도메인을 통해 페이지를 등록하는 방법과 url접두어를 통해 페이지를 등록하는 방법이 있었어요. 이 두 개가 뭐가 다른지는 아직도 모릅니다. 다만 도메인을 통해 페이지를 등록하기 위해서는 어떤 권한이 필요한 것 같고, 웹호스팅을 통해 만든 페이지는 그 권한이 제가 아니라 호스팅 업체에게 있는 것 같습니다. url접두어를 통해 페이지를 등록하는 방법을 선택했습니다. ssl 인증을 받을 때와 비슷한 방법으로 웹페이지의 소유권이 제게 있다는 걸 증명한 후 등록했어요. 하루 이틀 정도 지난 후에 제 위키의 도메인 주소를 검색해보니, 구글에 제 위키가 검색되더라고요. 약간 과장하자면, 아이가 태어나면 이런 느낌일까 싶었습니다. 11. 결론 이걸 코딩이라고 부르면 프로그래머들에게 실례겠죠. 그치만 비전문가의 입장에서는 충분히 힘들었습니다. 또 그만큼 뿌듯했고요. 다만 다시 돌아가면 그냥 노션 쓸 것 같습니다. 만든지 며칠 지나지도 않았는데 벌써 사용을 잘 안하게되네요. 그리고 새삼스럽게 토비님의 대단함을 느끼게 되었습니다. 충성충성. * Cascade님에 의해서 티타임 게시판으로부터 게시물 복사되었습니다 (2024-04-29 19:18) * 관리사유 : 추천게시판으로 복사합니다. 13
이 게시판에 등록된 와짱님의 최근 게시물 |