사용자 도구

사이트 도구


사이드바

메뉴:

블로그:

기타:


연락처:


안내:

blog:start

최근에 새로 오신 기획자님과 일하다가 문득 이분이 사용하시는 언어가 조금 거슬려서 뭐가 문제일지 생각해보기 시작했습니다. 작성하신 문서를 리뷰하다가 궁금한 점을 질문하면 짧은 이유와 함께 장황한 표현들이 따라붙었습니다. 저는 장황한 설명 중에서 영양가 없는 부분을 잔혹하게 잘라버리는데 이력이 나 있었으므로 몇 초 듣다가 “잠깐만요.” 하고 말을 잘라버리고 말았습니다. 다른 직군 스탭님들과 이야기할 때는 그렇지 않습니다. 하지만 우리들은 생각을 글로 표현하고 문서로 정리하며 이걸 다른 스탭님들께 말로 전달하는 일이 핵심 업무입니다. 그렇다면 글을 잘 써야 하고 문서를 잘 정리해야 하며 말도 잘 해야 합니다.

말을 잘 하기는 원래 어렵습니다. 어떤 일을 연습해서 잘할 수 있다면 한국어로 글쓰기나 한국어로 말하기 역시 수 십 년 동안 해온 사람이라면 누구나 잘할 수 있어야 합니다. 하지만 실제로는 그렇지 않습니다. 글을 잘 쓰는 사람은 적고 문서를 잘 정리하는 사람은 더 적습니다. 심지어 말을 잘 하는 사람은 지금까지 일하며 만나본 모든 사람들을 통틀어도 소수입니다.

문서를 리뷰하거나 회의에서 브리핑할 때 말을 잘 들어보면 누구도 사용하지 않는 머릿속에서만 멤돌던 “게이지빠”같은 이상한 단어가 튀어나오고 주술호응을 맞추지 못할 뿐 아니라 문장을 제대로 끝맺지 못하는 경우도 많습니다. 업무 내용을 브리핑하고 나머지 스탭들에게 협업을 요청해야 하는 상황에서 “뭐뭐 할 것 같습니다.” 같은 표현을 쉴 새 없이 사용하기도 하고 아무도 이해하지 못하는 '게임적인' 같은 표현을 사용하기도 합니다. 그냥 이러면 안됩니다.

실은 원래 한국어는 어렵습니다. 한국어를 모국어로 사용하며 한국에서 일상생활을 하는데 문제가 없다고 해서 한국어를 잘 한다고 가정하는 것은 위험합니다. 나를 포함한 많은 사람들이 한국어를 잘 못한다고 가정하고 한국어를 잘 하려고 노력을 기울여 연습해야 합니다. 종종 드라마를 보면 머리 좋은 사람으로 설정된 캐릭터들이 말을 빨리 하는 것을 볼 수 있는데 그렇게 말을 빨리 할 수 있는 이유는 본인이 존카멕이거나 대본에 적힌 대사를 외워서 말하고 있기 때문입니다. 이 둘 중 하나에 해당하지 않는다면 그렇게 멋지게 말을 잘 할 수 있는 방법은 없습니다.

일단 말을 좀 천천히 하려고 노력해야 합니다. 말을 천천히 하기 시작하면 하고싶은 모든 말을 할 시간이 줄어들어 필요 없는 말을 하기 어려워집니다. 시간이 줄어든 만큼 정말 필요한 말만 해야 하거든요. 하지만 별 문제는 없을 겁니다. 말을 천천히 하려고 노력하다 보면 자연스럽게 주술호응이 안 맞는 표현이나 괴상한 단어를 입 밖으로 내기 전에 머릿속에서 한번 더 거를 기회가 생기거든요.

말 하는 방법을 연습할 방법에는 자기가 한 말을 녹음해서 들어보는 방법도 있습니다. 회의를 녹음해서 들어보면 회의에 참여한 많은 사람들이 횡설수설하며 똑바로 말하는 사람이 별로 없다는 점에 놀라게 됩니다. 그만큼 자기 자신의 말이 얼마나 이상한지를 느낄 수도 있습니다. 하지만 이 방법은 개인적으로 썩 추천하지는 않는데 일단 녹음을 듣고 교훈을 얻는데 시간이 너무 많이 걸리고 자기 자신이 말을 얼마나 못하는지를 삼자 입장에서 들어보면 너무나 충격적이기 때문입니다. 마음이 약한 분들은 상처받을 수도 있습니다.

별 생각 없이 사용하는 단어를 의심해보는 것도 좋습니다. 별 생각 없이 내뱉은 단어가 무슨 의미인지 설명할 수 있는지 시험해보면 도움이 됩니다. 가령 '게임적', '게임성' 같은 말을 누군가 내뱉으면 머릿속에서 빨간불이 켜집니다. 그리고 이 말을 할 상황이 모두 끝나고 나서 여쭤봅니다. 혹시 아까 말씀하신 저 단어가 무슨 뜻이냐고요. 장담하건데 누구도 만족할만한 답변을 하지 못할 겁니다. 이걸 예상한 고약한 질문방법이기도 하고요. 저 단어들은 의미가 없습니다. 마치 게임이 가진 속성을 단어 몇 개로 요약할 수 있을 것처럼 굴지만 실제로는 온갖 장르가 있고 갖가지 주제와 소재로 구성되며 이들이 표현하고자 하는 바 역시 모두 다릅니다. 저런 단어들에 의해 단순하게 요약되지 않아요.

그런 단어들로 대표되는 스스로 설명할 수 없고 실제로 아무 의미 없는 단어들을 고객이나 평론가들은 사용할 수 있습니다. 그분들이 저 단어를 어떤 의미로 사용하든 의미가 없다는 사실이 달라지지 않을 뿐 아니라 그 글들이 유통된다고 해서 딱히 문제가 생기지도 않습니다. 하지만 저를 포함한 소위 기획자들이 이런 말을 사용하면 안됩니다. 의미가 없고 의미 없는 말을 일 하는 도중에 사용하면 서로 잘못된 이해를 할 수 있습니다.

원래 한국말은 어렵습니다. 한국어가 모국어이고 수 십 년 동안 한국어를 사용하며 일상생활을 하는데 지장이 없다고 하더라도 자신이 한국어를 잘 할 거라는 가정은 위험합니다. 특히 글을 쓰고 말을 하는 일을 하는 우리들은 항상 내가 한국어를 잘 못할 거라고 가정하고 단순하고 명확하며 스스로 설명할 수 있는 단어들을 사용하려고 노력하고 생각을 입으로 내뱉기 전에 정리하는 습관을 들이는 편이 좋습니다.

· 2020-06-28 20:59

시니어

한동안 계속해서 구인하고 있습니다. 프로젝트가 어느 시점에 다다르면 빠르게 확장해야 합니다. 맨바닥부터 개발하기 시작1)해 어느 정도 기반을 갖추면 이제 본격적으로 기반 위에 컨텐츠를 쌓아올리고 한편으로는 아직 조금 이를 수 있는 런칭 준비를 해야 합니다. 런칭은 어처구니없이 높은 완성도를 요구합니다. 테슬라처럼 새로운 장르를 개척하고 차별화된 가치를 제공하지 않는 우리들은 문짝이 잘 안 맞는 상태로는 런칭 근처에도 갈 수가 없습니다. 이를 달성하기 위해 지금까지와 비교할 수 없을 정도로 많은 작업을 해야 하고 당장 사람들을 채용해서 이 거대한 완성도에 맞설 준비를 해야 합니다.

이런 시점에는 많은 주니어님들과 적은 시니어님들을 구인합니다. 주니어님들께 게임 컨텐츠를 크게 확장하고 방대한 게임 구석구석의 완성도를 올릴 임무를 맡깁니다. 시니어님들께는 이 확장과 완성도 업무를 지휘하고 각각의 수준을 끌어올리는 역할을 맡기게 됩니다. 주니어와 시니어를 구분하는 기준이 명확하지 않고 또 이런 연차에 따른 구분이 요즘 세상에 잘 맞지는 않습니다. 편의상 오래된 직급 체계를 기준으로 이야기하면 대강 대리급까지는 주니어로 보고 과장급부터는 시니어의 초입에 들어서기 시작했다고 보곤 합니다. 확장에는 이들 양쪽 모두의 도움이 필요합니다.

이런 과정에서 시니어님들이 제출해 주신 이력서를 살펴보며 몇 가지 느낀 점이 있습니다. 저 역시 이제부터 적는 아쉬움을 피할 수 있는 입장이 아닙니다. 아직까지는 감사하게도 회사에 고용되어 프로젝트에 기여하고 있어 당장 저를 시장에 노출시키지 않아도 되지만 모두들 잘 알고 계신 대로 언제 갑작스럽게 시장에 내던져질지 모릅니다. 그래서 이 아쉬운 점들은 미래에 스스로를 시장에 노출시킬 때2)를 맞이할 저 자신을 위한 글이기도 합니다.

업계에서 긴 시간 동안 일을 계속하고 있다는 것은 어쨌든 업무능력을 어느 정도 인정받았다는 의미로 해석할 수 있습니다. 물론 어떤 사례를 보면 어떻게 이런 수준으로 살아남아 있는지 의심스러울 때가 없는 것은 아니지만 대체로 그렇다는 이야기입니다. 시장에서 업무능력을 검증받는데 실패하면 시장에 살아남아 있을 수가 없습니다. 아니면 아주 가난한 프로젝트에 고용되어 간신히 숨만 쉬며 먹고사는 수준에 머무르든지요. 그래서 위에서도 기간에 따른 주니어와 시니어의 구분이 항상 옳은 것은 아니라고 이야기했습니다. 하지만 한편으로는 어쨌든 일정 수준 이상의 프로젝트에 고용되어 긴 기간 살아남았다면 그게 업무능력이든 정치적인 면이든 뭐든지간에 살아남을만한 이유가 있다는 이야기입니다. 이 말을 뒤집어 생각해보면 어느 정도 연차를 쌓고 나면 업무능력만으로는 충분한 경쟁력을 가지기 어렵다는 의미이기도 합니다.

연차가 쌓임에 따라 업무능력이 올라 프로젝트에 개인이 기여할 수 있는 한계를 맞이하면 그 다음부터는 개인으로써 업무능력을 갈고닦아도 더이상 프로젝트에 기여하는 수준을 끌어올릴 수 없게 됩니다. 여기부터는 나를 포함한 주변의 다른 개인들에게 영향을 끼쳐야 합니다. 이제부터는 업무능력 이외에 업무 맥락을 파악하고 더 넓은 시야로부터 비롯된 인사이트가 필요합니다. 프로젝트 구성원 개인들은 게임 구석구석을 훑으며 완성도를 올릴 온갖 방법을 찾아 실행하고 있습니다. 자연스럽게 이들의 시야는 좁아지고 한 발 물러나서 보면 생각보다 간단한 일에 매몰되어 고통받는 경우가 많습니다. 개인 수준을 넘어 프로젝트에 기여하기 위해서는 구성원 개개인이 하루하루 업무 수행을 위해 가질 수밖에 없는 시야와 맥락 파악을 도와줄 수 있어야 합니다. 이 도움에는 반드시 더 넓은 시야에 의한 인사이트가 필요합니다.

시니어의 서류에 이런 점이 드러나지 않는다면 이 문서는 지독하게 평이해지고 맙니다. 맡은 일을 훌륭하게 수행해낼 수 있음은 물론 그 자체고 훌륭하기는 하지만 이 분을 시니어로써 구인할 수 있을지 의문을 가지게 만듭니다. 또 이분을 채용한다 하더라도 이 분을 시니어로써 대우하지 않을 수 있습니다. 만약 시니어 이상의 연차로써 시장에 자신을 노출시켜야 한다면 업무능력 이외의 뭔가를 이야기할 수 있어야 합니다. 업무 각각의 맥락을 이해하고 업무 자체의 목표 뿐 아니라 업무 자체가 충분히 표현하고 있지 않은 그 바깥의 목적을 달성하는데도 기여해야 합니다. 또 목표를 방해하는 이상한 업무에 의문을 가질 수 있어야 하고 나아가 이를 바로잡아야 합니다. 이를 어필하지 않으면 시장에서 시니어로 인지되지 않을 겁니다.

흔히 경력자 구인은 자기소개서보다는 경력기술서가 더 의미있다고 알려져 있습니다. 어느 정도는 맞는 말입니다. 하지만 현대에 모국어가 한국어이면서도 한국어를 충분히 잘 구사하지 못하는 사람들이 많아 어려움을 겪다 보면 자기소개서가 자기소개 이상의 역할을 하기도 합니다. 자기소개서는 좀 딱딱하게 느껴지기는 하지만 자신이 평균 이상의 한국어 구사능력을 갖추고 생각한 바를 조리있게 글로 표현할 수 있으며 자기소개서라는 좁은 시야를 벗어난 이야기를 자연스럽게 이어갈 수 있다는 사실을 어필할 훌륭한 기회입니다. 만약 주니어님들의 자기소개서라면 '일남일녀의 장남으로 태어나…'로 시작하는 자기소개서를 웃으며 넘어갈 수 있지만 시니어의 자기소개서에 전통적인 의미의 진짜 자기소개를 하면 안됩니다. 시니어의 자기소개서는 자유 주제 에세이라고 보는 편이 더 적당합니다.

솔직히 시니어를 지인찬스 없이 구인하려는 시도는 투입한 시간과 노력에 비해 처참하게 실패하는 중입니다. 구인을 꿈꾸는 시니어들은 이미 어딘가에 단단히 고용되어 있어 시장에 나타나지 않고 지인찬스를 통과하는 시니어들은 아주 잠깐 동안만 시장에 나타날 뿐입니다. 우물쭈물하다가는 순식간에 다른 프로젝트로 사라져버립니다. 이 과정을 거치지 않은 시니어들을 구인해 보려고 하지만 위에 이야기한 여러 가지 아쉬움으로 채용을 결정하기 쉽지 않습니다. 우리는 런칭을 위해 확장을 해야만 하는 상황이고 여기서 구인의 실패는 프로젝트의 실패로 이어질 수 있는 중대한 문제입니다. 그러니 시니어로써 구직하실 때 이런 점들을 조금 고려해주시면 좋겠습니다. 물론 저 자신도 다음번 시장에 나타날 때 이 점들을 신경쓸 겁니다.

· 2020-06-28 22:38

Dokuwiki Loadbalaning

Load balancing was primarily understood by the services of a certain size to serve more requests. This wiki I have been using for a long time has become much larger than initially expected, and as I have become increasingly dependent on it, I have started adding some requirements. For example, it was necessary to reduce the chance of losing data, and service should always be maintained. The chance of data loss is reduced by using a disk that can be detached from the instance and taking daily snapshots of the entire instance, including this disk. However, the requirement that the service should always be maintained was not easy to achieve. My previous experience with failure has led me to realize that Lightsail instances can fail more often than I thought, and I used to experiment with this on wikis and web servers on my own to break services. I used to do something on my own, and after breaking the wiki, I was frustrated that I could not find a way to use my wiki.

Then I came to the conclusion that to meet the second requirement that this service should always be maintained, I had to add servers and configure them to load balance. I have written about adding servers and setting up load balancing3) after the last failure. However, I have never talked about the Dokuwiki load balancing itself. So I decided to write an article that covers this topic precisely because it was difficult to find an article that tried the same with me no matter how much Google ringing this setting. This article is about 'Dokuwiki through load balancing'.

Background

Dokuwiki works on a file system basis. This is both an advantage and a disadvantage of Dokuwiki. Although both simples to install and use, it is platform-dependent and makes it difficult to choose a reliable scaling method like a database when trying to scale through load balancing. Although there is a document on the official Dokuwiki website that addresses the scalability caused by Dokuwiki's operation on a file system basis4), this document itself does not actually explain the use of Dokuwiki by cultivating it for a larger service. This document just talks about how big Dokuwiki exists in the world, and that this wiki is capable of operating at such a large number of documents, and does not explain the situation in which users must continue to operate in the event of an increase or failure.

Scale

This wiki is divided into public and private parts. Dokuwiki provides a feature called a farm that runs multiple wikis by installing one set of scripts and setting up different data directories based on it, but I am not using it. Based on the namespace, some parts are public and private, and they are separated by ACLs supported by Dokuwiki itself. To increase the level of security, Cloudflare Access is used to access additional private parts, requiring additional authentication and enabling a specific VPN to log in5). None of these are required in the public part. Wiki is about 20 gigabytes of text and images, except for cache files, and It using 32-gigabyte disks. The number of registered users is 10 or less, and the average number of edits per day is about 50.

Subjects

Load balancing

If you are just getting bigger wikis or more users, you can simply fix the problem using the larger Lightsail bundle. I am using the 2GB memory bundle, Until now, I don't feel particularly lacking in digesting the features I need for Dokuwiki. In particular, Cloudflare handles requests that the web server does not need to receive directly in front of the webserver6), so I do not feel the need for a bigger web server. As I said above, I wanted to reduce service outages and continue to use the wiki in the event of an outage by me, and I came to the conclusion that to meet this requirement, I had to increase the number of instances instead of the larger instances.

Among the load balancing services that can be easily found right now where services provided by Lightsail and Cloudflare. With Lightsail, you could build load balancing regardless of the number of servers, a number of requests, and traffic at a fixed cost of $18 per month7). Cloudflare can start load balancing with two servers for $5 per month but increases the cost by increasing the number of servers or increasing the number of requests8). In my case, I choose this because Cloudflare's pricing was cheaper because My scale is smaller. If it grows in size someday, there is room for migration to the flat rate load balancing offered by Lightsail.

Cloudflare Load Balancing

Cloudflare's load balancing does not use the API it requires IP addresses as many as the number of servers in order to use it without setting DNS separately on the Lightsail side. Currently, I building load balancing with two Lightsail instances, and the two instances have separate IP addresses and they are accessed through Cloudflare's DNS settings. Each server has to be set as A record and must be accessed separately through sub-domain, and load balancing is set based on this. The load balancing setup first creates a server pool and adds each of the servers to be in that pool. What you can do with $5 per month is one pool and up to two servers in it. Exactly what I am doing right now can be handled with this amount. Here, to increase the number of pools or increase the number of servers, the cost increases by about $5.

Once set up, it will be deployed within seconds, and once you enter the domain name, one of the two servers will start responding. With the session affinity9) setting, even if there are multiple servers, the server that initially responds for a certain period of time continues to respond, making it easy to maintain login and synchronize.

Synchronization

Because Dokuwiki works on a file system basis, it creates a number of concerns when expanding in this way. When I Googled, I want to expand Dokuwiki, but since it is based on a file system, there are articles10) saying that I am not sure what to do. Perhaps experts who know how to fit the situation have already left Dokuwiki or have already solved the problem via a network filesystem, but this article has not appeared on Google. I wasn't expert enough to set this up, and will not go to leave Dokuwiki for a while, so I had to find a way to fix it. To be precise, I had to decide how to synchronize the file system between the two servers and run it.

As I said in the previous article, I put unison11) into crontab and run it in a short cycle. Basically, I think synchronization should be the most secure and the most efficient way to reduce waste when the file system is changed. But for some reason, people with the requirement to sync the filesystems shown on Google were using more methods to perform synchronization in a shorter period by using tricks on the crontab12), which can only be done for up to 1 minute. Once I did it right now, it seemed a lot easier, so I followed the same thing and there haven't been any incidents so far.

However, it can potentially cause problems if one sync operation is longer than the minimum time unit in which synchronization occurs. unison runs on only one of the two servers. The other one just syncs but doesn't run it on its own. If we need to increase the number of instances in the future, I plan to respond by adding synchronization settings to instances that are expanded based on the 'Synchronizing Side' instance and running synchronization.

Certification

To maintain the security of the entire service, certificates are required in three sections. One is between client and Cloudflare. I use a free certificate provided by Cloudflare. In desktop browsers, you can click on the padlock icon next to the address to view the certificate information, but here I see the Cloudflare domain name instead of my domain name. I thought it does not matter. And it fully achieves the original purpose of encrypting traffic in this section.

The other two are between two servers and a Cloudflare server. Initially, Let's Encrypt certificates were issued and used, it was possible to automate the issuance and maintenance of certificates for each sub-domain. But I switched to using the origin certificate provided by Cloudflare. This origin certificate is signed by Cloudflare and the certificate is valid itself, but not valid for all authentication chain from the root certificate. So, if you use this certificate and without going through the Cloudflare, the authentication is marked as broken. However, since all requests are always going through the Cloudflare, the request was never marked as broken to the client, and the validity of the certificate was long, so it was less administrative and could achieve the purpose of encrypting between the Cloudflare and two origin servers.

Code distribution

Data and settings are synchronized in short cycles. But the Dokuwiki script didn't seem to do that. I frequently experimented with web servers and wikis, and if the experiment failed, the service would be temporarily stopped. At this time, if the Dokuwiki script was also synchronized, problems from one server could quickly spread to another server. However, I had to modify the code and I needed a way to deploy it comfortably. Perhaps the experts have another way, but I'm distributing the code by creating a repository on Github13). First, create an instance with a snapshot to modify and test the code there. If it does not seem to have any problems here push it to Github, deploy it to only one of the two servers, and let it go for a while. If it still doesn't seem like much, deploy it to the other one.

This method was used a while ago when applying14) the new RC15) of Dokuwiki. First I created a branch, applied the new code, then reviewed it, and tested it for some time, reflecting only on the newly created instance. I didn't have a big problem, and the third RC decided that all the changes were for code cleanup and deployed them on a daily basis on each server. Of course, this is because the major version update does not migrate the filesystem. If a new version of the future migrates a filesystem, it will not be possible to deploy one by one in this way.

Problems

Synchronization interval

File system synchronization occurs over time. Now it happens once every 10 seconds. In the first, 1-minute interval setting, there was a case where a page was written on one side but was not reflected on the other side, so there was a page that was not available when sharing an address. So for some time, when I shared the address, I opened the subdomains of all the servers to see if the posts appeared on both sides, and then shared the address. I have reduced the synchronization interval no. and It is working reliably to some extent, no longer checking every server before sharing the address.

If the number of users increases and the same page is modified on different servers at intervals shorter than the synchronization interval, the data of the side that was modified earlier will be lost. It was very difficult to merge when corrections occurred on both sides at the same time automatically. I'm simply overwriting the revised side later, but on my scale, there haven't been any problems yet, but it's not without problems. Potentially modified pages may lose their modifications.

External edit

Dokuwiki has a function that detects edits that Dokuwiki does not know through the time stamp of the file system. If someone or some other app opens and edits the Dokuwiki data file directly, there will be a difference between the time stamp recorded inside the file and the timestamp of the file itself. The next time you try to edit this page while in this state, It will first make a new revision of the changes that Dokuwiki doesn't know about, then open this revision to begin editing. However, in the environment of synchronizing files, the side that synchronizes the modifications will always have a wrong timestamp. On one server, the timestamp inside the file will match on the file itself, but on the other server, the timestamp of the file itself will point to a more future perspective, leaving an 'External edit' record at all times. The two servers that are synchronized always show the same revision history, but I didn't want to call the detectExternalEdit function16) because I didn't want to register the revisions that occurred. However, this setting will prevent you from recording this revision when external editing actually occurs.

Another external edit issue is that if the latest revision of a page has been synced from another server, the user who modified this page appears as 'External edit'. This is not recorded in the revision, but when the next modification occurs, it is normally recorded in the revision, but the newest page displays the edited user information normally on one server, while on the other server it is displayed as 'external edit' instead of the modified user information. This seems to be modifiable in the template output code, but I didn't fix it because I didn't understand why there was no user information because it was supposed to be external edit when no user information edited the page.

Session affinity

As I solved this external edit issue, I noticed a situation where the session affinity function was working. Session affinity is a function that continuously routes users accessing either server to the server through load balancing. Without this feature, a user who just logged in to one server may be routed to another server immediately after logging in and may be asked to log in again. When the page is edited and saved in connection with the external editing problem above, the user information is displayed in the page history, but when you access the page again after a while, it is sometimes changed to 'external edit'. This means that I was routed from one server to another while I was refreshing and using the wiki.

Conclusion

If Dokuwiki had used a database, I would have been talking about database replication for most of the load balancing. On the other hand, instead of using another tool like unison, you could just use the functionality of the database itself to build more stable load balancing without the potential problems discussed above. However, on my scale, I built Dokuwiki load balancing that works anyway, including potential issues, and it's been running without problems for a while. I can increase the number of servers to be synchronized and to reduce the possibility of data loss, I can back up the servers to synchronization. If one server is lost in the future, it can be recovered from data from the other server or from data in another Availability Zone. I believe that I have achieved some of the two goals mentioned above.

· 2020-06-28 18:18

<< 새 항목 | 오래된 항목 >>

blog/start.txt · 마지막으로 수정됨: 2020-06-07 14:29 (바깥 편집)