1. 시작하며
이전 글을 쓴 지 2주 남짓 지났다. 서비스를 운영한다는 건 문제와 해결이 꼬리에 꼬리를 물고 이어진다는 사실을 많이 느꼈다. 해결 하나는 또 다른 문제 하나를 물고 온다. 매일 밤 이용자들의 반응을 보다 보면 추가하고 싶거나 수정하고 싶은 것들이 떠오르기도 했다. 두서없이 개발하다 보니 이번에는 소재별로 글을 정리해 보았다.
2. 몰려오는 트래픽 물결
개인적으로 이용자들의 정보 수집에 부정적인 관점을 가지고 있다. 장기적으로는 이용자들이 만들어낸 정보의 값어치에 적절한 보상이 필요하다고 생각한다. 하지만 서비스를 운영해보자, 정보를 수집하지 않는 한 물리적으로 관측이 어려운 웹 서비스가 어떤 방식으로 사용되고 있는지 파악할 길이 없었다. 노점상에서 붕어빵을 판다고 해도, 지나가는 손님들과 무엇을 사는지, 얼마나 사는지, 어떤 분들이 사는지를 모르려야 모를 수가 없는데, 구글 애널리틱스를 깔기 전까지는 오직 "꼬들"의 답안지가 어디에 얼마나 올라오는지 확인하는 정도뿐이었다.
게다가 트래픽 내역을 확인하자...
생각했던 것보다 엄청나게 많은 분들이 즐겨주셨다. 하지만 이 정도 트래픽량을 보니 Github blog의 트래픽 허용 용량이 얼마 정도 되는가 궁금해졌다. ( https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages ) 찾아보니
- GitHub Pages sites have a soft bandwidth limit of 100GB per month.
라는 게 아닌가? 예전 소소한 설치형 블로그 운영할 때는 1GB/월로도 별 신경 안 써도 되었지만, 현재 이렇게 많은 분들이 하고 계신데 갑자기 트래픽 제한으로 연결이 끊긴다면? 하고 고민이 시작되었다. 그리고 GitHub에서는 현재 트래픽량이 얼마나 남았는지 등을 확인할 수 있는 영역도 없기 때문에, 이후 하루하루 실시간 이용자 수가 12시마다 쭉 올라갈 때마다 보이지 않는 시한폭탄의 심지가 바짝바짝 타들어가고 있는 기분이 들었다.
일단은 마찬가지로 정적 홈페이지 트래픽을 무료로 월간 100GB를 지원하는 Vercel( https://vercel.com/ )과 Netifity( https://www.netlify.com/ )에 바로 가입하여, GitHub 내역을 Deploy 해 복제 정적 웹사이트들을 만들었다. ( 이렇게 간단하게 웹사이트 복제를 할 수 있다니! ) 어디 공지할 곳도 없으니, 트위터에 멘션으로 공지하였는데 아무래도 노출이 잘 될 것 같지 않았다. 또한 이렇게 만들어놨다 하더라도 원 GitHub Blog에 트래픽 제한이 걸리면 리디렉션 할 홈페이지조차 닫히게 된다는 아이러니가 실감 났다.
게다가 상술했듯, GitHub에서는 트래픽 사용량을 보여주지 않으니, 이 당시 달 초순에는 GitHub Blog , 중순에는 Vercel, 말에는 Netifty로 돌려가며 리디렉션을 할까 생각하고 있었다. ( 지금 생각해보면 그럴 때마다 게임 로컬 스토리지의 통계가 날아간다.... ) 소소하게 Vercel과 Netlify의 초기 주소를 다들 익숙하라고 원 주소를 살려 github-belorin-io로 서브도메인 이름을 지었다가 크롬에 차단되어 매우 놀라기도 했다. 주소 이름을 지을 때는 피싱사이트처럼 보이지 말자.
3. 무한한 트래픽과 도메인 구매
당장 서버가 3개가 되자 먼저 생각나는 것은 도메인이었다. 세 개의 서버를 서로 리디렉션하며 갈아치우는 건 말도 안 되는 일이고, 세 개 다 닫혔을 때 어디론가 공지로 리디렉션 할 지점이 필요했다. 도메인을 고르는데도 생각했던 것보다 고민이 되었다. korld.le일지, kkordle일지, .net이나 .com일지. kordle.net도 고민해보았으나 battle.net과 어감이 비슷해서 이상한 기분이 들었다. 그러다 모양으로 보기엔 kordle.kr이 가장 예뻐 보여서 결정을 하고 GoDaddy( https://kr.godaddy.com/ )에서 구매를 하려고 하는데...
역순, 선순, 도로명 주소, 옛 주소 등등을 이것저것 입력해도 저 유효성 검사를 통과하지 못했다. 이걸 통과하려고 시도하느라 이틀이 걸렸으나 결국 다른 지인 분의 추천으로 호스팅케이알( https://www.hosting.kr/ )에서 쉽고 간단하게 구매하게 된다. 아무래도 .kr을 구매하려면 추가적인 검증이 필요한 상태여서 들어가는 정보인가 본데, 다른 분들은 어떻게 입력하고 구매했는지 궁금하다.
이 와중에 상황을 바꿀 트윗 하나가 와 있었는데...
서버가 필요 없는 정적 페이지라면 Cloudflare Pages를 써보시는 게 어떠세요? 정적 사이트 무제한 무료...! 저희도 이걸로 트래픽 감당했었어요https://t.co/JawLJMFQPu
— 산타파이브🌲예차니즘✨ (@yechanism_) February 8, 2022
Cloudfare Pages( https://www.cloudflare.com )를 추천해주는 @yechanism_님의 트윗이었다. 무제한 무료라는 말에 당장 가입하고 위의 두 사이트에서 익숙해진 Deploy를 구현하는데, 여기는 Create React App 등에 대해 자동 빌드 및 배포가 구성되어 있었다. 즉 빌드 이전의 코드를 올려두면 자동으로 알아서 빌드해준다! GitHub 원격 저장소에 Push만 하면 바로! ( 무엇을 선택할지 몰라서 Create React App을 선택했으나 React Static과 어떤 차이가 있는지 모르겠다. )
잘 올라가서 돌아가는지 확인한 후에, Kordle.Kr로 포워딩을 걸어주고는 한동안 지쳐서 쉬었다. ( 정적 포워딩을 걸자 아직 HTTPS가 아닌 주소라 바로 Clipboard API가 작동하지 않아 어쩔 수 없이 동적 포워딩으로 변경했다. 그렇게 해놓고 나니 이게 무슨 의미가 있나 싶고, 이용자들은 Pages의 주소를 복사해가기 시작했다. )
4. 어디에서 와서 어디로 가는가?
이렇게 되자 구글 애널리틱스의 리퍼러 대부분은 Kordle.Kr에서 들어오게 되었다. 그렇다면 Kordle.Kr로 들어오는 사람들은 어디에서 오는 건가? 마치 빌딩 로비에 앉아, 입구에서 들어오는 사람들을 보며 "다들 입구로 들어오는군"하는 꼴이었다. 게다가 문제점은 또 있다. 앞으로 개발하고 싶은 아이템은 주소로 쿼리 스트링을 통해서 정보를 받아야 하는데 이래서는 Cloudfare Pages의 주소로 리디렉션 되면서 쿼리 스트링이 날아가는 문제가 생겼다.
그래서 SSL을 설정하는데 지금까지 개념을 전혀 잘못 알고 있었다는 사실을 알게 된다. 암호 키나 비대칭키 개념은 알고 있었으나 정확히 인증서가 어디에 어떻게 작동하는지는 모르고 있었던 것이다. 지금까지는 특정 도메인 주소에 인증서가 삽입되고, 그 인증서가 삽입된 주소와 연결되는 서버 모두에게 효력이 발생되는지 알고 있었다. (... 웹 브라우저의 도메인 주소 옆에 자물쇠가 있으니까...)
하지만 알고 보니 도메인이라는 가면을 쓴 서버가 그 도메인의 서버가 맞는지 확인하는 용도의 인증서였고, 결국 인증서는 서버에 부착되어 도메인 주소의 DNS로 연결되는 것이었다. (아직도 개념을 명확히 이해한 것 같지 않다.) 어찌 되었든간, 또다시 Cloudflare의 도움을 받아 호스팅케이알의 DNS 주소를 Cloudflare 것으로 변경하고, 중간 인증서를 획득하여 이제 Kordle.Kr 옆에도 자물쇠가 달리게 되었다! ( 네임서버 변경 과정에서 한국 네임서버 변경이 늦어 접속 장애가 발생했다. Dns propagation을 확인할 수 있는 몇 사이트에서 확인해 보았다. )
이렇게 같은 주소로 같은 서비스를 제공하고자 하는 과정에서 주소를 기반으로 구성된 로컬 스토리지가 몇 번이나 리셋되었다. 어떻게 손을 쓸 수 없는 상황에서 반복되다 보니 안타까움과 아쉬움이 남는다. 그리고 결과지에 주소를 남길지 말지도 매 번 고민이 돼서 이렇게도 저렇게도 해보았다. 개인적으로는 주소를 어디엔가 붙어 포스팅할 때 자동으로 섬네일이 구성되는 게 지저분하다 느끼는 편인데, 주소를 빼보았더니 일부러 찾아 붙이는 분들도 있어 그렇게도 받아들일 수 있구나 싶었다. 현재로서는 결과 복사 버튼을 링크 있는 버전과 없는 버전 2개로 늘릴지 고민 중이다.
5. 문제를 누구나 출제하도록 해보자!
주소도 고정되었으니, 맘 놓고 주소로 정보를 받을 수 있게 되어 추가 개발을 해보았다. 일단 정보는 간단하게 Base64로 변환하여 주고받고 기본 컴포넌트와 함수들을 이용하여 구성하였다. 생각했던 것보다 빠르게 만들고 배포할 수 있었다. 어느 정도 React의 구성이나 Typesrcipt의 운용을 이해하게 되었다. ( 역시 그냥 해 보는 게 좋다. )
개발 중간중간과 SSL 수정, DNS 변경 등 여러 부분에서 S의 도움을 많이 받았다. 특히 문제 출제 폼 구성과 도메인 서버 인증서 획득은 S에게 큰 도움을 받았다. 서로 번갈아 코딩 짜는 걸 공유하며 진행해보니 여러모로 재미가 있었다.
6. 나가며
이제는 가만히 놔두어도 2 ~ 3년 정도는 알아서 굴러갈 수 있는 서비스가 되어 마음은 편해졌다. 현재로서는 안정적으로 길게 군더더기 없는 깔끔함을 계속 유지하고 싶다. 앞으로 시간이 흘러 조금씩 찾아오는 사람이 줄어들다, 몇 명 들어오지 않아도 계속 그 자리에 꾸준히 기다리는 공간이 되고 싶다.
P. S.
사람들이 입력하지만 검증 단어에는 없는 단어들을 수집해서 검증 단어 풀을 늘려보려고 수집을 시작해보았는데,
뭐든 생각대로만은 되지 않는다. ( 48번째 정답, ㄱㅜㅇㅜㅓㄹ )
P. S. 2.
매일 밤 12시에 새로운 문제가 나오니, 12시 직전까지 새로운 기능을 넣어 매일매일 배포하게 되는 좋은 효과가 있는 반면, 다음날 아침에 봐도 무방한데도 새벽 한 시 두 시까지 잠 못 들고 사람들의 반응을 살피다 다음날 산 좀비로 회사 일을 하게 되는 악 효과도 있다.
'공개' 카테고리의 다른 글
| "꼬들"을 만들기까지. (12) | 2022.02.05 |
|---|