A blog from a software developer who didn't get any formal training or education at all. :P
Yeah. I'm moving to another blog platform.
Blogger is quite a legacy and it's hard to post stuff(e.g. beautifying codes), and there are seldom readers coming in, so I move my blog to dev.to, where I can expose my posts to more "related" people. I'd like to archive this blog after moving some articles.
Now, see you on https://dev.to/teminian
옙. 블로그를 이전합니다.
Blogger 자체가 꽤 오래된 플랫폼이다보니 포스팅이 좀 불편하기도 하고(이를테면, 코드를 보기 좋게 올린다던가......), 사용자 유입이 거의 없다시피 하기도 해서(......), 좀 더 많은 관계자들에게 노출되는 플랫폼인 dev.to로 이전합니다. 이 블로그의 글 중 일부를 천천히 옮기는 것을 시작으로 이 블로그를 archiving하려 합니다.
https://dev.to/teminian 에서 뵙겠습니다.
One of my acquaintances make schedules for his colleague's daily leave schedule. Well, isn't it decided by the individuals themselves? Yet, there was a reason. The workplace has to be open for 7 days a week and employees are expected to take a leave for two days a week. If the selection is left to the individuals, they will certainly select specific weekdays(e.g. Saturday or Sunday), so he had to distribute the leave schedule himself.
But as you can imagine, the schedule can't be well randomized if it's done by hand. Even simple pseudorandom from your computer will generate far better result. So, he decided to use Microsoft Excel to automate the scheduling and get help from AI. And he tells the conditions:
Well, it seems to be fine until now. Isn't it? AI can generate some Excel spreadsheet. But when he added the following condition, AI goes brutal - its result generate error.
If you're good at dealing with Excel, you'll quickly understand it can't be accomplished by "pure" Excel without support of VBA macros. To satisfy the above conditions I need to know when others are taking a leave, but for the others the same applies. To know me I've got to know you, but to know you I've got to know myself, ....... Yep. A typical "recurring reference" situation. If you add such conditions, AI will just "give it up" and will tell whatever it wants to say. Forget prompt engineering. The best answer shall be "it should be done with VBA macros", or it can't make it happen like a magic.
Did you decide to develop a dedicated application software program? Yet still you've got to consider a lot. Scheduling leave schedule for a month, you need to avoid overlapping as much as possible, consider weekly schedule when building the whole monthly schedule, and decide how to deal with non-full-weeks in front or end of the month. Many points to consider, and many exceptions to handle.
But, this is only valid only when you deal with the problem as it is. Yes. AS IT IS.
Thinking a bit further, you can simplify and reassemble the problem and it can be solved quite easily. If you've got to leave once a week, then you shall have leaves sufficient to leave at least once a week. If you divide the full month to number of leaves(in this case 30/8=3.75 days) and spread the leave schedule, all the employees can take a leave at least once a week. Of course in this case the randomization becomes limited when compared with original condition of "leave at least once a week", but from the employer's perspective, leaving only once a day for 3 weeks and leaving the remaining 5 days in week 4 will give him quite a headache. :P
Large Language Model(LLM) can understand the natural language and understand what he says. But, the core of LLM is statistics and probability, and based on which patterns are shown the most when we divide our language to syntactic word level. In other words, if a human gives a sentence, it has no problem in understanding it as it is, but reading so called "between the lines" or "hidden premise" and restructuring the problem itself-we call it a inference- is beyond the level current technology can achieve.
And yes, this is when human intervention is needed.
AI can generate source code, and some people say that developers won't be needed anymore, well, still it's only human who can "truly understand" the depth of the problem and reassemble in a way that the problem can be easily solved. And human acknowledges many conditions which are usually not given to AI. Though I don't know, I think this is related with prompt engineering.
So, my dear fellow software developers in the world! Now is not the time.
Until AI can "infer properly", your desk is safe!
지인 중 한 분이 직원들 휴가 일정을 짜고 있었습니다. 휴가 일정은 휴가 가는 본인이 알아서 짜야 되는거 아니냐...... 했는데, 알고보니 주 7일 로테이션 근무제였고, 직원들이 돌아가면서 일주일 중 이틀씩 쉬는 형태이고, 이걸 무조건 개인의 선호대로만 하면 특정 날짜에 사람이 몰린다던가 하는 문제가 있어서 부득이하게 선임이 직원들 휴일을 지정해주는 형태가 되었다 합니다.
그런데, 이게 무작위로 한다고 해도 사람이 직접 뿌리면 무작위가 될 리가 없지요. Pseudorandum이라고 해도 컴퓨터가 무작위로 뿌려주는게 사람이 직접 분산시키는 것보단 훨씬 낫다는 거야 자명한 사실입니다. 그래서, 그저 한 직장의 현장직 관리자로서 개발과는 아무런 연이 없던 이 분은 마이크로소프트 엑셀로 이를 자동화하기로 하고, AI 시스템의 도움을 얻기로 합니다. 그리고 조건을 거는데......
뭐, 여기까지는 어떻게든 된 것 같습니다. AI가 시키는데로 Excel에 넣기만 하면 척척 나오니까요. 다만 조건을 하나 더 추가하니까 AI가 슬슬 배째라 모드로 들어갑니다.
엑셀좀 만져보신 분들이라면 이 조건이 추가되는 순간 이 문제는 VBA 없이 순수(?)엑셀만으로는 절대로 해결이 불가능하다는 것이 바로 감이 잡히실 겁니다. 위의 조건을 모두 만족하려면 내가 언제 쉬었는지를 알아야 되는데, 그걸 알려면 다른 사람이 언제 쉬었는지를 알아야 되고, 이게 모든 사람들에게 공통적으로 적용됩니다. 즉, 나에 대해서 알려면 남을 알아야 되는데, 남을 알기 위해서는 나를 알아야 하고...... 예. 이건 전형적인 순환 참조 구문입니다. 당연한 이야기입니다만, 이런 조건을 AI에 추가하기 시작하면 그때부터 AI는 배를 째라는 식으로 나오죠. 프롬프트 엔지니어링을 백날 해봐야 구조적으로 불가능한걸 되게 할 수 있는 마법같은 뭐시기는 못 만들어냅니다. 아무리 잘 말해봐야 가장 좋은 답변은 "엑셀만으로는 안되고 VBA 등을 사용하셔야 합니다"일 겁니다.
엑셀을 사용하지 않고 아예 전용 프로그램을 개발하더라도 위 조건은 구현이 생각보다 그리 쉽지 않습니다. 한 달간의 일정을 짜는데, 가능한한 겹치지 않아야 되고, 월단위 일정을 따면서 주단위 일정의 구성에 신경을 써야 할 뿐 아니라, full week가 되지 않는 월초나 월말의 며칠은 어떻게 처리해야 될지도 신경을 써야 됩니다. 이래저래 신경써야 할 조건도 많을 뿐더러, 예외처리해야 할 부분도 한두개가 아니에요.
다만, 이건 어디까지나 문제를 액면 그대로 받아들였을 때의 이야기입니다.
조금만 생각해보면, 이 문제는 꽤나 간단하게 풀립니다. 이를테면, 휴가가 한 달에 8번이고, 일주일에 최소 한 번은 쉬어야 한다는 조건은, 뒤집어서 생각하면 휴가가 무조건 일주일에 한 번 이상 쉴 수 있도록 주어진다는 것입니다. 요컨데, 한 달을 휴가일수로 나눈 기간(여기서는 30/8=3.75일) 내에서 휴가를 균등하게 분산하면 일주일에 무조건 한 번 이상 쉴 수 있게 됩니다. 이 경우 원래 조건인 <일주일에 무조건 한 번 이상 쉰다>에 대한 무작위성이 제한되긴 하지만, 사업주 입장에서도 3주를 일주일에 한 번씩만 쉬고 네번째 주에 5일을 쉬는 엄한 결과를 내는 것보다는 저렇게 최대한 균등하게 배포하는 쪽이 직원들의 사기 등 관리에도 유리할 겁니다.
대규모 언어 모델(Large Language Model, LLM)은 사람의 자연언어를 분석하고 이해할 수 있을 정도까지 발달했습니다. 다만, LLM의 핵심은 통계고, 문장을 어절단위로 분석했을 때 어떤 패턴이 얼마나 자주 나타나는지를 학습한 결과에 기인합니다. 요컨데, 사람이 문장을 주면 그 문장 자체를 이해하는데는 아무런 문제가 없지만, 속칭 행간이라 불리는 보이지 않는 부분을 읽어 문제를 처음부터 다시 구성하는 등의 추론적 사고는 어렵다 하겠습니다.
그리고 당연한 이야기지만, 이 부분이 바로 사람이 필요한 부분이죠.
아무리 인공지능이 알아서 소스코드까지 짜주는 시대이고, 혹자는 앞으로 개발자는 필요없을 거라면서 회의론을 부르짖고 있지만, 문제를 제대로 이해하고 이를 토대로 문제를 해결할 수 있는 형태로 재구성할 수 있는 능력은 아직 사람만이 할 수 있는 것 같습니다. 그리고 사람은 AI에게 주어지지 않은 수많은 조건들을 알고 있지요(고객사 담당자의 성향이라던가, 말하지는 않았지만 당연히 되어야 한다고 생각하는 부분이라던가......). 잘 모르는 분야입니다만, 프롬프트 엔지니어링과도 통하는 바가 있지 않을까 하는 생각도 듭니다.
전세계의 개발자 여러분! 아직은 때가 아닙니다.
AI가 제대로 된 추론을 하지 않는 이상 여러분의 책상은 안전합니다.
고대 중국에 나를 날마다 새롭게 한다는 뜻인 일신우일신(日新又日新)이라는 고사가 있습니다. 이 말을 가슴에 안고, 저는 종종 개발 환경에 변화를 추구하곤 합니다.
한동안 저는 Vim으로 대표되는 "modal editing" 환경에 좀 회의적이었습니다. 아니 왜 내가 삽입/일반/비주얼로 모드를 바꾸는데 신경을 써야 돼? 모드를 변경할 필요 없이 모든 작업을 수행할 수 있다면 모드 변경에 사용되는 시간과 써야 되는 신경을 절약할 수 있지 않을까?...... 뭐 이런 거죠.
이런 생각 아래, 저는 제 소중한 Vim을 대체할만한 무언가를 찾았고, 그 와중에 Lite-XL을 찾았습니다. 지금은 Vim으로 돌아온 상태입니다만, Lua로 개발된 이 에디터와의 5일동안의 기억은 꽤나 신선해서, 이를 기록으로 남기는게 좋겠다는 생각이 들었습니다.
말 그대로입니다. Vim처럼 footprint가 엄청 작습니다. 사실 메모리 사용량 자체는 Vim보다 살짝 높은 수준이긴 하지만 요즘 나오는 IDE급으로 징하게 무거운 코드 에디터들에 비하면야 애교 수준이고, Vim보다 높다는 것도 이게 Lua 기반이라는걸 고려해보면 뭐 나쁘지 않죠.
하지만 이 이야기인즉슨, 바닐라 상태에서는 Vim처럼 정말 아무것도 없습니다(......). LSP라던가, 들여쓰기 가이드라던가, 선택된 문자열과 동일한 문자열을 하이라이트하는 등의 기능들을 모두 플러그인 형태로 따로 설치해야 됩니다.
Vim에 .vimrc가 있다면, Lite-XL에는 .config/lite-xl/*이 있습니다. 이 디렉토리에 존재하는 Lua 스크립트를 이용하면 환경 설정이나 초기화 등을 쉽게 수행할 수 있습니다. 물론, 여러분이 저처럼 Lua를 모른다고 해도 큰 문제는 없습니다. 써있는 설명만 잘 따라하면 되더군요. 뭐...... 저같은 경우에는 혹시 놓치는게 없을까 싶어서 조심스럽게 읽어야 하긴 했지만, 그건 제 모국어가 영어가 아니라서 그럴 것 같습니다. ;)
Lite-XL은 언제나 지연 없이 반응을 수행했습니다. 스크롤 애니메이션은 덤이고요. 파일간 검색부터 명령 팔레트에 이르기까지 "나 엄청 가볍다니까!"하고 외치는 듯한 느낌을 받았습니다. 쾌적하더군요.
LSP 플러그인은 만족스럽습니다. 플러그인의 공식 github 레포지토리에서는 아직 플러그인이 완성되지 않았다고 하긴 합니다만 대부분의 주요 기능들은 잘 동작하는 상태고, 현 상황을 알려주는 오버레이 또한 친절하고, 뭔가 "끼어드는 듯한 느낌"이 없어서 좋았습니다(Vim LSP 플러그인이 띄우는 수많은 Virtual Text를 보셨다면 "끼어드는 듯한 느낌"이라는게 뭔지 이해가 되실겁니다). 오버로드 표시도 Lite-XL이 훨씬 뛰어나더군요.
하지만 심볼 검색 다이얼로그나 명령은 좀 헷갈리는 감이 있고, 몇몇 유틸리티들, 이를테면 심볼 타입 목록을 포함하는 심볼 검색 등은 빠져 있어서 좀 허했습니다. 물론 전체적으로는 괜찮은 편이라고 생각합니다. 이건 제가 새로운 인터페이스에 익숙해지기 위해 충분한 시간과 노력을 들이지 않아서, 그리고 제 업무방식을 Lite-XL에 맞게 바꾸지 않아서 혼란스럽게 느껴진 것일 수도 있거든요.
이 에디터의 개발자들은 자신들의 오른손이 키보드와 마우스 사이를 왕복하는게 꽤나 거슬렸던 것 같습니다. 웬지 디자인이 마우스 사용을 최소화하기 위해서 노력하는 느낌이에요.
자주 사용하는 기능이라면 거기에는 어김없이 단축키가 설정되어 있습니다. 전 Lite-XL 개발자들이 자신들의 개발환경에서도 적극적으로 Lite-XL을 사용하고 있고, "속도광"일 것이라는 느낌을 받았습니다. 타이핑할때 절대로 시간을 허투루 소비하지 않겠다는 집착이 보인달까요.
다만 딱 한 가지, 윈도 분리에서는 좀 헷갈리긴 했습니다. Lite-XL이 <Alt> + ijkl을 사용하는 반면, Vim은 Ctrl-W에 그 유명한 hjkl 조합을 사용하는 터라 방향을 헷갈리지 않을 수가 없었네요. :P
흔하지는 않지만 전 가끔 몇 GB정도 되는 로그 파일들을 다뤄야 할 경우가 있습니다. Vim 9은 이 측면에서 매우 뛰어납니다. 몇 초 안에 모든 준비를 끝내지요.
동일한 파일을 Lite-XL에서 열려고 해보니 몇 분 정도의 시간을 기다려야 하고, 간혹 에디터가 버벅대기도 하더군요. 스크립트 언어에서 개발되어서 그렇다는 생각은 들지 않습니다. 멀리 갈 것 없이, Javascript로 만들어진 Visual Studio Code도 동일한 파일을 꽤 잘 다룰 수 있었거든요(뭐..... 메모리 사용량만 빼고요).
어쨌든, 전 이게 모든 분들에게 해당되는 사항은 아니라고 생각합니다. 굳이 매우 큰 텍스트 파일을 제어할 필요가 없다면 굳이 신경쓸 필요는 없으실 겁니다.
Lite-XL로 몇몇 파일들을 열어놓은 상태에서 프로젝트에 git checkout을 실행해 몇몇 파일을 변경한 결과 에디터가 죽어버렸습니다(얼라리요). 그냥 운이 없었던 건지 버그인지는 모르겠지만, 하여간 뭐...... 그리 되었습니다.
대한민국에는 여자들은 열과 성을 다해서 식당 별점 및 리뷰를 쓰는 반면, 남자는 딱 두 가지 경우, 그러니까 "희생양은 나 혼자면 충분하다!"라고 할 정도로 개판(......)이거나, "이렇게 좋은 곳은 무조건 널리 알려야 한다!"라고 할 정도로 뛰어난 식당을 알게 된 경우에만 리뷰를 작성한다는 농담 아닌 농담이 있습니다.
Lite-XL의 경우에 대해서는, 이건 명백히 후자입니다. 특히나 Visual Studio Code를 대체할만한 가벼운 에디터를 찾는데, Vim의 미친듯한 낭떠러지급 학습곡선을 피하고 싶다면 강력히 추천합니다(참고: 전 Vim 사용자이긴 합니다만 Vim이 생산성을 최대화하는 유일한 길이라는 생각에는 적극 반대합니다. 목표를 달성하는데는 한가지의 길만 있는게 아니죠. 그런 측면에서 보면 VS Code는 매우 많은 사용자 환경과 경우의 수를 커버할 수 있는 폭넓은 환경을 제공합니다. C++만 봐도 MS의 Intellisense와 clang 중 하나를 선택해서 사용할 수 있는 경우는 흔치 않죠).
저의 경우는 몇몇 기능이 부족해서(특히 대용량 파일 제어부분이 뼈아팠습니다) Vim으로 돌아오긴 했습니다만, 여러분의 경우 만일 큰 파일을 제어할 일이 없으시다면 한 번 시도해보시는 것도 나쁘지 않을 것 같습니다.
There's an ancient Chinese saying(which is also famous in Korea), 日新又日新, meaning that "renew myself day by day." With the saying in mind, occasionally I try new development environments and tools, as other good developers do.
During the time I was a bit skeptical about "modal editing" scheme, represented by Vim, changing modes-Insert, Normal, Visual- to do certain stuff. Why would I be concerned with the mode? If I can do everything without changing modes, wouldn't it save both time and my mental resources(e.g. being concerned with mode)?
With that in mind, I tried to search for a good substitute for my precious Vim and amid the search activity I found Lite-XL. Though I'm back to Vim, the 5-day journey with the Lua-based coding editor was impressive, so I'd like to leave a record to remember the fun during the journey.
Literally. Like Vim, it has small footprint. Though memory consumption was a bit higher than Vim for fresh run, but compared with modern "heavyweight" IDE-like code editors, and considering that it's built in Lua, a versatile scripting language, it was impressive.
However, it also means that it barely has anything, like vanilla Vim. To be more productive, you need to install and configure plugins, e.g. LSP, indent guide, or highlighting same words of current selection in the document.
And where there's .vimrc in Vim, there's .config/lite-xl/* in Lite-XL. There are a handful of Lua scripts there, and you can add your own configurations and initializations as needed. Configuration is fully manual and in Lua, but you no worries even though you're not familiar with the language, like I do. Follow the instructions for each plugin and you'll be fine, though I had to be careful to not lose any details when reading them(maybe that's because I'm not an English speaker? ;) ).
Lite-XL was always responsive with nice scrolling animations. Whether it be searching among files or dealing with command palette, it was always like shouting "I'm lightweight enough so that I can fly!".
LSP plugin is satisfactory. Though the official github repository for Lite-XL LSP plugin says that it is WIP, but still most major features are already ready to serve, and the overlay was quite informative, and, most of all, non-interrupting. I'm sure you know what I mean if you saw messages in virtual texts when running Vim LSP plugins. Even showing overloads was better with Lite-XL.
However, its symbol search dialogs and commands were a bit confusing, and missed some small utilities I enjoyed(e.g. symbol search with full symbol list and their types). But that's fine - maybe I was just not familiar with new interface, and I didn't invest ,much time or efforts on changing my workflow for the unfamiliar interface.
The developers must be concerned with their right hands traveling between keyboard and mouse, and they want to minimize using mouse.
Where there is a frequently used feature, there's a hot key dedicated for it. I'm sure that Lite-XL developers must use Lite-XL themselves on developing stuff and they're also "speed freaks", to NOT allow any time loss regarding your keystrokes.
The only thing I was confused was that window splitting - Lite-XL used `<Alt> + ijkl` while Vim used `Ctrl-W` with its famous `hjkl` combination. :P
It's rare but sometimes I have to deal with log files with a few GBs in size. Vim 9 handled them really well. It opened the file in a few seconds and the file is already ready to serve.
When I tried to open the same file with Lite-XL, it took a few minutes to open, and sometimes the editor lagged. I don't think that's simply a limit for scripting language, as I saw Visual Studio Code, written in Javascript, could handle the same file really well, except for memory consumption(lol).
Anyway, I think that's not the case for everyone, so I think you can safely ignore if you don't have to handle REALLY BIG text files.
While opening some files with Lite-XL, I git checkouted my project, some open files changed, and the editor crashed(oops). I'm not sure whether I was just unfortunate or it was a bug, but anyway it happened.
There's a joke in Korea that while women are enthusiastic about rating and reviewing restaurants, men write the review in only two occasions: it's so bad that you'd announce "don't go there it's enough only for me to be the scapegoat", or it's really great that you think "man it's damn great I want to spread the words so that the restaurant can sustain more."
For Lite-XL, this is the latter. It's damn great, especially if you're in thirsty for lightweight alternative against Visual Studio Code yet don't want to face the deep valley of learning curve for Vim(one thing: though I'm a Vim user, I don't think everyone needs to learn Vim for their maximum productivity. Rather, I'm against it - there are so many ways to accomplish your goals. Having such in mind, I think VS Code can satisfy and cover quite a lot of use cases and ways to do things, like choosing between Intellisense and clangd for assisting C++ development).
I had to return to Vim because I missed a few things(handling GB-size files was critical), but if you don't have to deal with big files, I strongly recommend to give it a try.
오랜만입니다! 오늘도 또다른 '얼라리요' 건을 소개할까 합니다.
뭐, 별거 없죠? 문법도 괜찮고....... 하지만 사실 이 코드는 원래 이런 구조여야 했습니다:
뭐, 다들 이런 경우 한 번 씩은 경험해보지 않으셨으려나요?