무감

컨테이너 번호 확인을 해야 하는데 찾아 나오는 C# 소스 코드가 에러가 있어서 수정해보았다. 방식은 다음(링크)을 참조했다.

        private bool Cntrnumb_Chk(string conNumber)
        {
        	//11자리 그대로 들어와야 한다.
            if (conNumber.Equals(""))
                return false;
            int nChk = 0;
            int nBcd = 0;
            int nHap = 0;
            string sChk = "";
            conNumber = conNumber.Trim();
            for (int i = 0; i < conNumber.Length - 1; i++)
            {
                nBcd *= 2;
                if (nBcd == 0)
                    nBcd = 1;
                sChk = conNumber.Substring(i, 1);
                switch (sChk)
                {
                    case "A": nChk = 10; break;
                    case "B": nChk = 12; break;
                    case "C": nChk = 13; break;
                    case "D": nChk = 14; break;
                    case "E": nChk = 15; break;
                    case "F": nChk = 16; break;
                    case "G": nChk = 17; break;
                    case "H": nChk = 18; break;
                    case "I": nChk = 19; break;
                    case "J": nChk = 20; break;
                    case "K": nChk = 21; break;
                    case "L": nChk = 23; break;
                    case "M": nChk = 24; break;
                    case "N": nChk = 25; break;
                    case "O": nChk = 26; break;
                    case "P": nChk = 27; break;
                    case "Q": nChk = 28; break;
                    case "R": nChk = 29; break;
                    case "S": nChk = 30; break;
                    case "T": nChk = 31; break;
                    case "U": nChk = 32; break;
                    case "V": nChk = 34; break;
                    case "W": nChk = 35; break;
                    case "X": nChk = 36; break;
                    case "Y": nChk = 37; break;
                    case "Z": nChk = 38; break;
                    case "1": nChk = 1; break;
                    case "2": nChk = 2; break;
                    case "3": nChk = 3; break;
                    case "4": nChk = 4; break;
                    case "5": nChk = 5; break;
                    case "6": nChk = 6; break;
                    case "7": nChk = 7; break;
                    case "8": nChk = 8; break;
                    case "9": nChk = 9; break;
                    default: nChk = 0; break;
                }
                nChk *= nBcd;
                nHap += nChk;
            }
            nChk = nHap / 11;
            nChk *= 11;
            nChk = nHap - nChk;
            if (nChk == 10)
                nChk = 0;
            if (Convert.ToInt16(conNumber.Substring(conNumber.Length - 1, 1)) == nChk)
                return true;
            else
                return false;
        }

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시 직전까지 새로운 기능을 넣어 매일매일 배포하게 되는 좋은 효과가 있는 반면, 다음날 아침에 봐도 무방한데도 새벽 한 시 두 시까지 잠 못 들고 사람들의 반응을 살피다 다음날 산 좀비로 회사 일을 하게 되는 악 효과도 있다.

1. 1월 26일 ~ 27일

아이디어는 기대치 않은 순간에 태어난다. 온라인 모임 단톡방에서 다양한 언어로 이뤄진 Wordle을 이야기하고 있었는데, 한국어 Wordle 이야기가 나왔고 누군가 "해볼까요?" 한 마디를 던졌다. 수동으로 세 판을 내리 해보며 사실상 "꼬들"의 기본적인 요소는 모두 구성되었다. (자세한 내역은 아래 접힌 카톡 대화에 담겨 있으며, 함께한 단톡방 친구분들께 감사의 말씀을 드린다.)

더보기

첫 번째 판

두 번째 판

3번째 판

수동으로 한국어 Wordle을 해보며 정리된 개념은 이렇게 많다.

• 모음은 완전히 풀어쓰는 게 좋다.
• 쌍자음과 겹받침도 풀어쓰는 게 좋다.
• 음절 중간에 낀 자음은 앞에 붙을지 뒤에 붙을지 애매한 효과를 발생시킨다.
• 여섯 칸이 적합하다. ( 다섯 칸은 2음절 강제, 풀어쓰기 상 겹모음과 겹자음이 최소화된다. )
• 현 "꼬들"의 자판이 구성되었다.
• 검증 단어의 범위가 중요하다.

그리고 무엇보다... 하나 만들어주세요, 하는 요청이 있었다.

2. 1월 28일

혹시 모를 마음으로 Github에서 Wordle을 검색해보았다. (현재 검색하면 훨씬 더 다양한 내역이 뜬다. ) 그러자 최상단에 당시 300여 개의 별이 찍힌 Wordle Clone이 나타났다. 현재는 뉴욕 타임스가 구매했기 때문인지 Word-Guessing-Game이라고 변경되었다. ( https://github.com/hannahcode/word-guessing-game/issues ) 나와있는 링크로 한 판 해보니 Wordle Clone은 매우 상세하게 구성되어 있었다. 하지만 GitHub에 올려져 있는 프로그램을 어떻게 진행해야 하는지 알 길이 없었다.

3. 1월 31일 오전

설 전날 집에서 S에게 넌지시 Wordle 이야기를 꺼내자 Fork을 살펴보자고 하였다. GitHub 페이지를 살펴보더니 S는 일단 우상단의 Fork를 눌러 그 목록을 살피기 시작했다. 쭉 내려가다 보니 포크의 포크가 아주 활발하게 구성된 "AnyLanguage-Wordle"이 있었고, ReadME에선 간결하고 쉽게 언어 변경을 간추린 내용이 있었다. ( https://github.com/roedoejet/AnyLanguage-Wordle )

이를 Git Clone을 이용하여 로컬의 적당한 장소에 옮겨놓고, (S의 Mac이었으며 이미 NPM이 구성되어 있었다.) NPM을 이용해 현 패키지의 라이브러리를 알아서 다 설치해주었다. 말하자면 안드로이드의 Grandle이 담당하는 영역과 흡사하다 하는데, 이렇게 일괄 관리를 할 수 있다는 것 자체가 충격이었다.

또한 NPM에서 배포판을 빌드하는 것까지는 그렇다 싶은데, run start를 이용해 서버를 바로 구성하여 웹브라우저로 띄우고, 코드를 수정하는 즉시 결과가 반영된다는 건 믿기지 않는 일이었다. 이 홈페이지를 보면 알겠지만, 보통 C#으로 exe 패키지를 배포하는 편이고 어쩌다 안드로이드 서버를 만들어야 할 때는 아파치 서버를 설치하고 일일이 Webapp 폴더에 올려 쿠키를 지워가며 디버그를 해왔던 입장에서는 인생을 잘못 살고 있는 게 아닐까 하는 생각마저 들었다.

이후 코드를 변경하는 일은 어디서나 비슷한 일이기 때문에 쉽사리 진행이 되었다. Wordle Clone은 Typescript라는 보통 프론트엔드에서 자주 사용하는 언어로 구성되어 있었고, AnyLanguage-Wordle은 사용자 편의를 위해 알파벳 형태일 경우 Constants에 몰아넣은 세팅부터 수정해주면 되었다.

어절의 길이도 간단히 config.ts의 wordLength를 수정하면 되었다. 다만 아직도 여섯 칸으로 결정을 내리지 못했는데, 어섯 칸이 될 경우 난도가 너무 상승하는 게 아닌가 고민되었기 때문이다. 그러나..

  B : 6칸이 되면 다양해져서 너무 어려워지지 않을까?
S : 어휘의 다양성에서는 그렇겠지만, 한 칸당 확인할 수 있는 범위도 같이 늘어나기 때문에 적절할 것 같아.
당장 두 칸짜리를 생각해봐. 그렇게 되면 몇 자 확인하지도 못하고 금방 끝나겠지.
B : ( 듣고 보니 논리적이군. 그리고 남을 설득할 때는 극단적인 반례를 드는게 좋겠군. )  

이 프로젝트를 진행하면서 Mac을 처음 써보았는데, 들었던 대로 마우스는 거의 이용하지 않고 단축키와 터치패드의 구성이 잘 되어 있어 훨씬 편하게 사용할 수 있었다. 특히 터치패드의 두 손가락, 세 손가락 제스처는 문화 컬처였다. 단축키도 Windows 기반과 꽤나 달라서 언어 모르는 다른 나라에 가 어린아이가 된 듯한 기분을 느꼈다.

AnyLanguage-Wordle은 두 가지 어휘목록을 가지고 있는데, 하나는 wordlist.ts로 문제 모음집이고, 다른 하나는 validGuesses로 검증 단어집이다. 처음에는 왜 분리되어 있는지 체감하지 못했지만 나중에 보니 당연히도 범용성 높은 단어만을 문제로, 최대한 넓은 범위의 단어를 검증으로 구성하여야 되었다. 온갖 단어가 다 들어가 있는 어휘집에서 문제를 추출할 경우 상상 이상의 난이도가 될 수밖에 없다.

국립국어원의 기본 어휘 중 명사만을 뽑아 ( 형용사, 동사, 수사 등등은 문제로 나올 경우 납득이 어려울 가능성이 높아 보였다 ) 초기 목표대로 자모를 분리하였다. Python의 h2j, j2hcj 라이브러리를 이용해 일단 분리하고, 이후 따로 만든 필터로 겹모음과 겹자음을 추가로 분리하였다. 그 후 6개로만 이루어진 목록을 정리했는데 여기서 S가 잠깐 목록을 보는데 'ㅈㅏㅎㅚㅅㅏ'라는 단어를 발견했다. 내가 만든 추가 분리 코드에서 'ㅚ'를 뺴먹은 것이었다. 이 문제가 나왔다면 어떻게 되었을까..? ( 차후 1,000여 개의 문제 어휘 목록을 전부 읽어보며 확인하였다. 그러나 이제 와서 생각하니 '위집' 같은 단어는 제거해야겠다. )

말뭉치도 같은 단계로 진행하여 15,000 단어 정도로 검증 단어를 구성하였다. ( https://huggingface.co/klue/bert-base ) 이 정도면 충분하리라 생각했으나 이후 문제가 발생한다.

4. 1월 31일 오후

이쯤에 S가 한국어 워들이 이미 존재하고 있다는걸 발견하고 말해주었다. 개발하기 전에 구글 등에서 검색했을 때 나오지 않았지만 트위터에서 검색을 하니 26일에 이미 개발을 완료하여 올려놓으신 분이 있었다.

#한글 #워들 #korean #wordle https://t.co/irldDxgO3B

— nakosung (@17facet) January 27, 2022

여기까지 굳이 진행을 할 필요가 있었나 하고 체념이 상당히 되었지만, 확인해본 바 칸 수도 입력 방식도 달랐고 완성해서 올렸을 때 사람들이 플레이할게 기대가 되어 마무리 지을 수 있었다.

한국어 자판을 구성하고 입력을 조율하는데, 받아오는 변수인 e.code가 잘 변환되지 않는 문제가 발생했었다. 이후에도 IME 문제가 발생하여 e.key를 직접 받아 한글이 일대일 대응되어 입력되도록 수정하였다. (한/영키 등을 누를 필요 없이 외국 자판을 사용하고 있더라도 위치에 맞춰 한글이 입력될 것으로 예상된다.)

NPM에서 빌드된 배포판을 확인해 본 이후, 적절한 정적 홈페이지를 올릴 사이트를 찾아보았고 Github의 개인 홈페이지도 그에 포함된다는 걸 확인하였다. 그러나 S의 PC에서 작성했기에 Git으로 업로드하기 애매한 상황이었다. 대부분 Github와는 풀과 푸시로 데이터를 주고받겠지만 이번에 Github에도 강제 파일 업로드가 있음을 확인할 수 있었다. 자정이 가까워져 가는 시간에 업로드하여 작동을 확인했고, 트위터에 게시하였다.

글 그대로 다들 재미있게 즐겨주었으며 하는 마음에 올렸는데 생각했던 것보다 더 많은 사람들이 참여하였고, 최대한 요건들을 개선하고 싶은 마음이 들었다. 일정도 설 연휴인지라 더 많은 사람들이 함께할 여유가 있었던 것으로 보인다.

5. 2월 1일 오전

트위터에서 트랜드에 올라가는 걸 확인하다 잠들었다. 다음 날 보니 이용자 분들이 단어가 너무 부족하다고 힘들어했다. "Word not found"가 싫다는 이야기 일색이었다. 그래서 DB를 찾아보는데도 그렇다 할 내역이 보이질 않았다. 부모님께도 한 판씩 하도록 해드렸는데 '가자미', '미나리', '다리미'를 입력하시는데 단어가 없어 한탄하셨다.

설 당일 바닷가가 보이는 전망대에서 휴대폰으로 열심히 검색을 해보니, K-ICT 빅데이터센터란 곳에서 NIADic을 Xlsx로 받을 수 있었다. ( https://kbig.kr/portal/kbig/datacube/niadict.page ) 집에 가자마자 열어 확인하는데 단어의 질이 그렇게까지 썩 좋지는 않았다. 품사 태그 표에서 명사 종류는 n으로 시작하는데, 모든 명사 종류를 ncn 하나로 통일시켜놓아서 따로 더 거를 수도 없었다. ( 네이버에서 우리말샘이 국어사전 지분을 늘려가는 것을 지적하는 경우가 많은데, 이 데이터에는 우리말샘의 단어들이 들어가 있는 것으로 보인다. )

더 시간을 허비할 수는 없고, 적당히나마 ㄹ로 시작하는 단어들을 거르고 - 북한어가 상당히 많이 들어있었다 - 이전과 같은 처리를 거쳐 자모를 분리해 검증 어휘 목록에 추가하였다. 이 와중에 CSV로 변환한 데이터를 Python이 약 170만 건 이상이라고 에러를 내뱉어서 시스템 한계를 해제하는 무식한 방식으로 넘겼다. 다들 '솜털', '나루터', '감줄', '긍휼', '힐난', '고라니', '두더지' 등의 단어가 없다고 아우성 중이었기 때문에 최대한 빨리 올리고 싶었다.

그런데 당장 올리려고 보니 정말 말도 안되는 단어들도 있는데 괜찮은가 싶었다. 사실상 사전에도 없는 단어들이 많은데 (사투리, 입말 등). 하지만 어떻게 생각하면 칠 수 있는 단어들이 늘면 역설적으로 단어를 많이 아는 사람들의 난도가 자동으로 상승한다. 그리고 이상한 단어가 통과되는 것이, 단어가 없다고 나오는 것보다 이용자에게 피로도를 덜 준다. 그런 면에서 업로드를 진행했다. ( 이후 검증 단어 목록은 약 55,000 단어가 되었다. )

하는 김에 지문 대부분을 한국어로 수정하였다. 이 업로드 이후 다들 만족하는 분위기라 기분이 좋았다.

6. 2월 1일 오후

구글 애널리틱스의 추적 ID를 추가하는 부분이 Config.ts에 있기에 추가해보았으나 하루를 작동하지 않고 있었다. 알고 보니 ID 번호의 시작이 G-로 시작하면 안 되고 UA-로 만들어야 작동한다. 다음날에 수정하여 올리니 정상적으로 연결이 되었고 이때부터 이용자 정보를 확인해볼 수 있었다. 만드는 와중에 고급 설정에서 선택해주어야 한다. 다음 포스트의 도움을 받았다. ( https://devsungyeon.github.io/github%20blog/Google-analytics/ )

7. 2월 2일

S와 함께 집에 돌아와 내 컴퓨터에 개발 환경을 구성하기 시작했다. Windows에서도 Node.js를 설치하고 intelliJ 커뮤니티 판은 Typescript 개발 지원이 안 된다고 하여 Vs Code를 준비하였다. Node.js가 잘 설치되고 나자, NPM도 잘 작동하였고 크게 다르지 않게 가상 서버가 구성되고 수정된 코드가 바로 웹 테스트에 반영되었다.

그 사이 설명을 꾸준히 바꿔왔는데 겹자음과 겹모음을 자연스럽게 읽고 무의식 속에 어휘 풀어쓰기를 받아들일 수 있도록 배치하려고 노력하였다. 최대한 자모가 겹치지 않도록 했는데 자연스럽게 읽히는지 궁금하다. 하는 김에 소소하게 파비콘도 변경하고, 손톱 밑 가시 같던 키보드 배치도 변경하였다. 혹시나 아직도 단어가 없다는 알림창이 영어로 나온다던가, 키보드 형태가 실제 키보드와 상이하다던가, 파비콘이 원자로 보일 경우 F5를 한 번 눌러주시길 바란다.

8. 차후

새로운 사전 데이터를 추천받았는데 예상되는데 앞으로 어떻게 진행할지 고민이 된다. 다음과 같이 세 가지 방법이 있을 것이다.

1. 유지 - 우리말샘과 입말이 검증 어휘 목록에 포함되어, 어휘 검증이 질적으로 떨어지나 익숙함을 유지할 수 있다.
2. 추가 - 분량이 너무 많아지므로 무거워질 수 있고, 단어 풀이 너무 넓어져 단어 필터링의 질이 낮아진다.
3. 교체 - 갑작스레 사전 단어로만 빡빡하게 변경되어 이용자들이 낯선 상태에 돌입하게 된다.

좀 더 생각해보니, 일단 기초대사전의 단어들을 받아, 현 목록과 얼마나 겹치는지 등을 비교하여 분량을 생각해서 그때 결정하면 되겠다.

꾸준히 지적된 결과 복사 버튼 수정도 우선순위에 있다. 초기 우선순위에서는 잠시 검색해봐도 다양한 환경에서 각기 다른 결과가 펼쳐져 피드백이 매우 복잡해질 수 있어 뒤로 밀어놓았는데, 편안한 공유를 위해 이제 언어도 찬찬히 알아보면서 수정이 필요할 듯싶다. 마지막으로...

>>> 귀엽고 단순한 게 최고다. <<<

P. S
한글의 특성 때문에 다양한 방식의 풀이법이 존재하며, 각각 좋은 디자인으로 구성되어 있다면 놀이 방법은 큰 문제가 아니라고 생각한다. 개인적으로 3자 우리말 워들( https://plan9.kr/wordle/ )을 적정한 난이도 때문에 재미있게 하고 있으며, 심지어는 5자 음절 워들( https://site.thekipa.com/korsylwordle/ )도 몇 개 풀어보았다.

P. S. 2.
개발자 판에는 Shuffle 모드가 존재한다. 원한다면 시간제한 없이 무한으로 즐길 수 있다. ( 그러나 안 쓴다... )

P. S. 3.
현재 "꼬들"의 결과를 공유할 때 앞에 31 ~ 35라고 붙어 있다. 1 ~ 30은 어디로 갔는가 하면, 애초에 이 패키지가 2022년 1월 1일 배포할 것으로 예정되었을 때의 디폴트 값이 들어있었는데, 그걸 수정하지 않고 배포해버려서 문제 어휘 목록 중 앞 30개를 넘기고 시작해 버렸다.

P. S. 4.
현재 "꼬들"의 문제 어휘 목록의 차례는 완전히 임의적이다. 어떠한 의도도 담겨있지 않는데 신기하게도 맥락을 느낀다.