Hello! I'm Hong Minhee (洪 民憙), an open source software engineer in my late 30s, living in Seoul, Korea. I'm bisexual and non-binary (they/them), and an enthusiastic advocate of free/open source software and the fediverse.
I work full-time on @fedify, an ActivityPub server framework in TypeScript, funded by @sovtechfund. I'm also the creator of @hollo, a single-user ActivityPub microblog; @botkit, an ActivityPub bot framework; Hackers' Pub, a fediverse platform for software developers; and LogTape, a logging library for JavaScript and TypeScript.
I have a long interest in East Asian languages (CJK) and Unicode. I post mostly in English here, though occasionally in Japanese or in mixed-script Korean (國漢文混用體), a traditional writing style that interleaves Chinese characters with the native Korean alphabet. Wanting to write in that style was actually one of the reasons I joined the fediverse. Feel free to talk to me in English, Korean, Japanese, or even Literary Chinese!
安寧하세요! 저는 서울에 살고 있는 30代 後半의 오픈 소스 소프트웨어 엔지니어 洪民憙입니다. 兩性愛者(bisexual)이자 논바이너리(non-binary)이며, 自由·오픈 소스 소프트웨어(F/OSS)와 聯合宇宙(fediverse)의 熱烈한 支持者이기도 합니다.
STF(@sovtechfund)의 支援을 받아 TypeScript用 ActivityPub 서버 프레임워크 @fedify 開發에 專業으로 任하고 있습니다. 그 外에도 싱글 유저用 ActivityPub 마이크로블로그 @hollo, ActivityPub 봇 프레임워크 @botkit, 소프트웨어 開發者를 위한 聯合宇宙 플랫폼 Hackers' Pub, JavaScript·TypeScript用 로깅 라이브러리 LogTape 等의 製作者이기도 합니다.
東아시아 言語(이른바 CJK)와 Unicode에도 關心이 많습니다. 이 計定에서는 主로 英語로 포스팅하지만, 때때로 日本語나 國漢文混用體 韓國語로도 씁니다. 聯合宇宙에 오게 된 動機 中 하나가 바로 國漢文混用體로 글을 쓰고 싶었기 때문이기도 하고요. 韓國語, 英語, 日本語, 아니면 漢文으로도 말을 걸어주세요!
Coming soon on your Mastodon server… The long awaited quote posts, with user-control (you can chose if you want to be quoted on a per-post basis, change it later, and retract any quote of your post)
Amazing work by the team 🎉
Expect a blog post with all the details in a few weeks, support in the mobile apps, then we will enable the feature on mastodon.social, then release Mastodon 4.5
I've recently been working on Optique, a CLI parser combinator for TypeScript. Optique allows you to describe complex CLIs by combining smaller parts. You can also handle the CLI parsing results in a type-safe manner (see code below). The idea came from Haskell's optparse-applicative, but since TypeScript's API style is so different from Haskell's, I referenced Zod and similar libraries for the API design. For a more detailed introduction, please refer to the article I posted on Hackers' Pub!
최근 Optique라는 다소 실험적인 CLI 파서 라이브러리를 제작하게 되었습니다. 이 글을 쓰는 2025년 8월 21일 시점으로 아직 0.1.0도 릴리스되지 않았지만, 나름대로 재미있는 발상이라고 생각해서 이 글을 통해 소개합니다.
Optique는 크게 두 가지 다른 라이브러리로부터 영향을 받았습니다. 하나는 Haskell의 optparse-applicative라는 라이브러리인데, 이 라이브러리로부터 얻은 교훈은 CLI 파서도 파서 컴비네이터가 될 수 있고, 그렇게 만들었을 때 매우 유용하다는 사실입니다. 다른 하나는 TypeScript 사용자들에게 이미 익숙한 Zod입니다. 비록 optparse-applicative에서 아이디어의 줄기를 얻긴 했지만, Haskell과 TypeScript는 너무나 다른 언어라서 API를 구성하는 방식에 큰 차이가 있습니다. 그래서 API를 구성하는 방식에 있어서는 Zod를 비롯한 여러 유효성 검사 라이브러리를 참고하게 되었습니다.
Optique는 여러 작은 파서들과 파서 컴비네이터들을 레고 부품처럼 조립하여 CLI가 어떠한 모양이어야 하는지를 표현합니다. 예를 들어 가장 작은 부품 중 하나로는 option()이 있습니다:
const parser = option("-a", "--allow", url());
이 파서를 실행하려면 run()이라는 API를 사용하면 됩니다:
(참고로 run() 함수는 암시적으로 process.argv.slice(2)를 읽습니다.)
const allow: URL = run(parser);
위 코드에서 제가 일부러 URL이라는 타입을 명시하긴 했지만, 굳이 그렇게 하지 않아도 저절로 URL 타입으로 추론됩니다. 위 파서는 -a/--allow=URL 옵션만을 받아들입니다. 다른 옵션이나 인자를 줄 경우 오류가 납니다. -a/--allow=URL 옵션이 주어지지 않아도 오류가 납니다.
만약 -a/--allow=URL 옵션을 필수가 아닌 선택으로 두려면 어떻게 해야 할까요? 그럴 때는 optional() 컴비네이터로 option() 파서를 감싸면 됩니다.
prog -a https://example.com/ --allow https://hackers.pub/prog -d https://example.com/ --disallow https://hackers.pub/
하지만 다음과 같이 -a/--allow=URL 옵션과 -d/--disallow=URL 옵션이 섞여있을 때는 오류를 냅니다:
prog -a https://example.com/ --disallow https://hackers.pub/
아무튼, 그럼 이 파서의 결과는 어떤 타입이 될까요?
const result: readonly URL[] = run(parser);
이런, or() 컴비네이터가 감싸는 2개의 파서 모두 readonly URL[] 타입의 값을 만들기 때문에 readonly URL[] | readonly URL[] 타입이 되어, 결과적으로 readonly URL[] 타입이 되어버렸습니다. 제대로 된 변별 공용체(discriminated union) 형식으로 바꾸고 싶군요. 아래와 같은 타입이면 좋을 것 같습니다.
변별자(discriminator)를 부여하기 위해 constant() 파서도 사용했습니다. 이 파서는 조금 특이한 파서인데, 아무 것도 읽지 않고 주어진 값을 만들기만 합니다. 즉, 항상 성공하는 파서입니다. 이렇게 변별 공용체를 구성할 때 주로 쓰이지만, 다른 창의적인 방식으로도 쓰일 수 있을 겁니다.
같은 방식을 응용하면 겹쳐진 서브커맨드(nested subcommands)도 구현할 수 있겠죠?
자, 이렇게 Optique가 CLI를 표현하는 방식을 보여드렸는데요. 어떤 것 같나요? Optique의 방식이 복잡한 CLI를 표현하기에 적합하다는 게 와닿으시나요?
물론, Optique의 방식도 완벽하지는 않습니다. 아주 전형적이고 단순한 CLI를 정의하는 데에는 오히려 더 손이 가는 것도 사실입니다. 또한, Optique는 오로지 CLI 파서의 역할만 하고 있기 때문에 일반적인 CLI 앱 프레임워크가 제공하는 다양한 기능은 제공하지 않기도 합니다. (추후 Optique에 더 많은 기능을 추가할 예정이긴 합니다만…)
그럼에도 Optique의 접근 방식에 흥미를 느끼셨다면, 소개 문서나 튜토리얼도 한 번 살펴보시기 바랍니다.
최근 Optique라는 다소 실험적인 CLI 파서 라이브러리를 제작하게 되었습니다. 이 글을 쓰는 2025년 8월 21일 시점으로 아직 0.1.0도 릴리스되지 않았지만, 나름대로 재미있는 발상이라고 생각해서 이 글을 통해 소개합니다.
Optique는 크게 두 가지 다른 라이브러리로부터 영향을 받았습니다. 하나는 Haskell의 optparse-applicative라는 라이브러리인데, 이 라이브러리로부터 얻은 교훈은 CLI 파서도 파서 컴비네이터가 될 수 있고, 그렇게 만들었을 때 매우 유용하다는 사실입니다. 다른 하나는 TypeScript 사용자들에게 이미 익숙한 Zod입니다. 비록 optparse-applicative에서 아이디어의 줄기를 얻긴 했지만, Haskell과 TypeScript는 너무나 다른 언어라서 API를 구성하는 방식에 큰 차이가 있습니다. 그래서 API를 구성하는 방식에 있어서는 Zod를 비롯한 여러 유효성 검사 라이브러리를 참고하게 되었습니다.
Optique는 여러 작은 파서들과 파서 컴비네이터들을 레고 부품처럼 조립하여 CLI가 어떠한 모양이어야 하는지를 표현합니다. 예를 들어 가장 작은 부품 중 하나로는 option()이 있습니다:
const parser = option("-a", "--allow", url());
이 파서를 실행하려면 run()이라는 API를 사용하면 됩니다:
(참고로 run() 함수는 암시적으로 process.argv.slice(2)를 읽습니다.)
const allow: URL = run(parser);
위 코드에서 제가 일부러 URL이라는 타입을 명시하긴 했지만, 굳이 그렇게 하지 않아도 저절로 URL 타입으로 추론됩니다. 위 파서는 -a/--allow=URL 옵션만을 받아들입니다. 다른 옵션이나 인자를 줄 경우 오류가 납니다. -a/--allow=URL 옵션이 주어지지 않아도 오류가 납니다.
만약 -a/--allow=URL 옵션을 필수가 아닌 선택으로 두려면 어떻게 해야 할까요? 그럴 때는 optional() 컴비네이터로 option() 파서를 감싸면 됩니다.
prog -a https://example.com/ --allow https://hackers.pub/prog -d https://example.com/ --disallow https://hackers.pub/
하지만 다음과 같이 -a/--allow=URL 옵션과 -d/--disallow=URL 옵션이 섞여있을 때는 오류를 냅니다:
prog -a https://example.com/ --disallow https://hackers.pub/
아무튼, 그럼 이 파서의 결과는 어떤 타입이 될까요?
const result: readonly URL[] = run(parser);
이런, or() 컴비네이터가 감싸는 2개의 파서 모두 readonly URL[] 타입의 값을 만들기 때문에 readonly URL[] | readonly URL[] 타입이 되어, 결과적으로 readonly URL[] 타입이 되어버렸습니다. 제대로 된 변별 공용체(discriminated union) 형식으로 바꾸고 싶군요. 아래와 같은 타입이면 좋을 것 같습니다.
변별자(discriminator)를 부여하기 위해 constant() 파서도 사용했습니다. 이 파서는 조금 특이한 파서인데, 아무 것도 읽지 않고 주어진 값을 만들기만 합니다. 즉, 항상 성공하는 파서입니다. 이렇게 변별 공용체를 구성할 때 주로 쓰이지만, 다른 창의적인 방식으로도 쓰일 수 있을 겁니다.
같은 방식을 응용하면 겹쳐진 서브커맨드(nested subcommands)도 구현할 수 있겠죠?
자, 이렇게 Optique가 CLI를 표현하는 방식을 보여드렸는데요. 어떤 것 같나요? Optique의 방식이 복잡한 CLI를 표현하기에 적합하다는 게 와닿으시나요?
물론, Optique의 방식도 완벽하지는 않습니다. 아주 전형적이고 단순한 CLI를 정의하는 데에는 오히려 더 손이 가는 것도 사실입니다. 또한, Optique는 오로지 CLI 파서의 역할만 하고 있기 때문에 일반적인 CLI 앱 프레임워크가 제공하는 다양한 기능은 제공하지 않기도 합니다. (추후 Optique에 더 많은 기능을 추가할 예정이긴 합니다만…)
그럼에도 Optique의 접근 방식에 흥미를 느끼셨다면, 소개 문서나 튜토리얼도 한 번 살펴보시기 바랍니다.
저는 일과는 별개로 두통과 함께하는 사람들라는 두통 환자 단체를 만들고 있는데요. 9월 말에 있는 편두통 인식 주간(Migraine Awareness Week)를 맞아서 여러 가지를 준비하고 있습니다. 이번에 편두통 환자나 가족, 보호자를 대상으로 편두통으로 있었던 에피소드를 공유하는 수기 공모전을 진행하게 되었습니다. 수기 공모전은 9월 7일까지 카페에 글을 쓰고 신청할 수 있는데요. 상품 등도 같이 준비하였습니다. 주변에 널리 공유해주시고 관심 부탁드리겠습니다.
최근 Optique라는 다소 실험적인 CLI 파서 라이브러리를 제작하게 되었습니다. 이 글을 쓰는 2025년 8월 21일 시점으로 아직 0.1.0도 릴리스되지 않았지만, 나름대로 재미있는 발상이라고 생각해서 이 글을 통해 소개합니다.
Optique는 크게 두 가지 다른 라이브러리로부터 영향을 받았습니다. 하나는 Haskell의 optparse-applicative라는 라이브러리인데, 이 라이브러리로부터 얻은 교훈은 CLI 파서도 파서 컴비네이터가 될 수 있고, 그렇게 만들었을 때 매우 유용하다는 사실입니다. 다른 하나는 TypeScript 사용자들에게 이미 익숙한 Zod입니다. 비록 optparse-applicative에서 아이디어의 줄기를 얻긴 했지만, Haskell과 TypeScript는 너무나 다른 언어라서 API를 구성하는 방식에 큰 차이가 있습니다. 그래서 API를 구성하는 방식에 있어서는 Zod를 비롯한 여러 유효성 검사 라이브러리를 참고하게 되었습니다.
Optique는 여러 작은 파서들과 파서 컴비네이터들을 레고 부품처럼 조립하여 CLI가 어떠한 모양이어야 하는지를 표현합니다. 예를 들어 가장 작은 부품 중 하나로는 option()이 있습니다:
const parser = option("-a", "--allow", url());
이 파서를 실행하려면 run()이라는 API를 사용하면 됩니다:
(참고로 run() 함수는 암시적으로 process.argv.slice(2)를 읽습니다.)
const allow: URL = run(parser);
위 코드에서 제가 일부러 URL이라는 타입을 명시하긴 했지만, 굳이 그렇게 하지 않아도 저절로 URL 타입으로 추론됩니다. 위 파서는 -a/--allow=URL 옵션만을 받아들입니다. 다른 옵션이나 인자를 줄 경우 오류가 납니다. -a/--allow=URL 옵션이 주어지지 않아도 오류가 납니다.
만약 -a/--allow=URL 옵션을 필수가 아닌 선택으로 두려면 어떻게 해야 할까요? 그럴 때는 optional() 컴비네이터로 option() 파서를 감싸면 됩니다.
prog -a https://example.com/ --allow https://hackers.pub/prog -d https://example.com/ --disallow https://hackers.pub/
하지만 다음과 같이 -a/--allow=URL 옵션과 -d/--disallow=URL 옵션이 섞여있을 때는 오류를 냅니다:
prog -a https://example.com/ --disallow https://hackers.pub/
아무튼, 그럼 이 파서의 결과는 어떤 타입이 될까요?
const result: readonly URL[] = run(parser);
이런, or() 컴비네이터가 감싸는 2개의 파서 모두 readonly URL[] 타입의 값을 만들기 때문에 readonly URL[] | readonly URL[] 타입이 되어, 결과적으로 readonly URL[] 타입이 되어버렸습니다. 제대로 된 변별 공용체(discriminated union) 형식으로 바꾸고 싶군요. 아래와 같은 타입이면 좋을 것 같습니다.
변별자(discriminator)를 부여하기 위해 constant() 파서도 사용했습니다. 이 파서는 조금 특이한 파서인데, 아무 것도 읽지 않고 주어진 값을 만들기만 합니다. 즉, 항상 성공하는 파서입니다. 이렇게 변별 공용체를 구성할 때 주로 쓰이지만, 다른 창의적인 방식으로도 쓰일 수 있을 겁니다.
같은 방식을 응용하면 겹쳐진 서브커맨드(nested subcommands)도 구현할 수 있겠죠?
자, 이렇게 Optique가 CLI를 표현하는 방식을 보여드렸는데요. 어떤 것 같나요? Optique의 방식이 복잡한 CLI를 표현하기에 적합하다는 게 와닿으시나요?
물론, Optique의 방식도 완벽하지는 않습니다. 아주 전형적이고 단순한 CLI를 정의하는 데에는 오히려 더 손이 가는 것도 사실입니다. 또한, Optique는 오로지 CLI 파서의 역할만 하고 있기 때문에 일반적인 CLI 앱 프레임워크가 제공하는 다양한 기능은 제공하지 않기도 합니다. (추후 Optique에 더 많은 기능을 추가할 예정이긴 합니다만…)
그럼에도 Optique의 접근 방식에 흥미를 느끼셨다면, 소개 문서나 튜토리얼도 한 번 살펴보시기 바랍니다.
I've recently been working on Optique, a CLI parser combinator for TypeScript. Optique allows you to describe complex CLIs by combining smaller parts. You can also handle the CLI parsing results in a type-safe manner (see code below). The idea came from Haskell's optparse-applicative, but since TypeScript's API style is so different from Haskell's, I referenced Zod and similar libraries for the API design. For a more detailed introduction, please refer to the article I posted on Hackers' Pub!
최근 Optique라는 다소 실험적인 CLI 파서 라이브러리를 제작하게 되었습니다. 이 글을 쓰는 2025년 8월 21일 시점으로 아직 0.1.0도 릴리스되지 않았지만, 나름대로 재미있는 발상이라고 생각해서 이 글을 통해 소개합니다.
Optique는 크게 두 가지 다른 라이브러리로부터 영향을 받았습니다. 하나는 Haskell의 optparse-applicative라는 라이브러리인데, 이 라이브러리로부터 얻은 교훈은 CLI 파서도 파서 컴비네이터가 될 수 있고, 그렇게 만들었을 때 매우 유용하다는 사실입니다. 다른 하나는 TypeScript 사용자들에게 이미 익숙한 Zod입니다. 비록 optparse-applicative에서 아이디어의 줄기를 얻긴 했지만, Haskell과 TypeScript는 너무나 다른 언어라서 API를 구성하는 방식에 큰 차이가 있습니다. 그래서 API를 구성하는 방식에 있어서는 Zod를 비롯한 여러 유효성 검사 라이브러리를 참고하게 되었습니다.
Optique는 여러 작은 파서들과 파서 컴비네이터들을 레고 부품처럼 조립하여 CLI가 어떠한 모양이어야 하는지를 표현합니다. 예를 들어 가장 작은 부품 중 하나로는 option()이 있습니다:
const parser = option("-a", "--allow", url());
이 파서를 실행하려면 run()이라는 API를 사용하면 됩니다:
(참고로 run() 함수는 암시적으로 process.argv.slice(2)를 읽습니다.)
const allow: URL = run(parser);
위 코드에서 제가 일부러 URL이라는 타입을 명시하긴 했지만, 굳이 그렇게 하지 않아도 저절로 URL 타입으로 추론됩니다. 위 파서는 -a/--allow=URL 옵션만을 받아들입니다. 다른 옵션이나 인자를 줄 경우 오류가 납니다. -a/--allow=URL 옵션이 주어지지 않아도 오류가 납니다.
만약 -a/--allow=URL 옵션을 필수가 아닌 선택으로 두려면 어떻게 해야 할까요? 그럴 때는 optional() 컴비네이터로 option() 파서를 감싸면 됩니다.
prog -a https://example.com/ --allow https://hackers.pub/prog -d https://example.com/ --disallow https://hackers.pub/
하지만 다음과 같이 -a/--allow=URL 옵션과 -d/--disallow=URL 옵션이 섞여있을 때는 오류를 냅니다:
prog -a https://example.com/ --disallow https://hackers.pub/
아무튼, 그럼 이 파서의 결과는 어떤 타입이 될까요?
const result: readonly URL[] = run(parser);
이런, or() 컴비네이터가 감싸는 2개의 파서 모두 readonly URL[] 타입의 값을 만들기 때문에 readonly URL[] | readonly URL[] 타입이 되어, 결과적으로 readonly URL[] 타입이 되어버렸습니다. 제대로 된 변별 공용체(discriminated union) 형식으로 바꾸고 싶군요. 아래와 같은 타입이면 좋을 것 같습니다.
변별자(discriminator)를 부여하기 위해 constant() 파서도 사용했습니다. 이 파서는 조금 특이한 파서인데, 아무 것도 읽지 않고 주어진 값을 만들기만 합니다. 즉, 항상 성공하는 파서입니다. 이렇게 변별 공용체를 구성할 때 주로 쓰이지만, 다른 창의적인 방식으로도 쓰일 수 있을 겁니다.
같은 방식을 응용하면 겹쳐진 서브커맨드(nested subcommands)도 구현할 수 있겠죠?
자, 이렇게 Optique가 CLI를 표현하는 방식을 보여드렸는데요. 어떤 것 같나요? Optique의 방식이 복잡한 CLI를 표현하기에 적합하다는 게 와닿으시나요?
물론, Optique의 방식도 완벽하지는 않습니다. 아주 전형적이고 단순한 CLI를 정의하는 데에는 오히려 더 손이 가는 것도 사실입니다. 또한, Optique는 오로지 CLI 파서의 역할만 하고 있기 때문에 일반적인 CLI 앱 프레임워크가 제공하는 다양한 기능은 제공하지 않기도 합니다. (추후 Optique에 더 많은 기능을 추가할 예정이긴 합니다만…)
그럼에도 Optique의 접근 방식에 흥미를 느끼셨다면, 소개 문서나 튜토리얼도 한 번 살펴보시기 바랍니다.
최근 Optique라는 다소 실험적인 CLI 파서 라이브러리를 제작하게 되었습니다. 이 글을 쓰는 2025년 8월 21일 시점으로 아직 0.1.0도 릴리스되지 않았지만, 나름대로 재미있는 발상이라고 생각해서 이 글을 통해 소개합니다.
Optique는 크게 두 가지 다른 라이브러리로부터 영향을 받았습니다. 하나는 Haskell의 optparse-applicative라는 라이브러리인데, 이 라이브러리로부터 얻은 교훈은 CLI 파서도 파서 컴비네이터가 될 수 있고, 그렇게 만들었을 때 매우 유용하다는 사실입니다. 다른 하나는 TypeScript 사용자들에게 이미 익숙한 Zod입니다. 비록 optparse-applicative에서 아이디어의 줄기를 얻긴 했지만, Haskell과 TypeScript는 너무나 다른 언어라서 API를 구성하는 방식에 큰 차이가 있습니다. 그래서 API를 구성하는 방식에 있어서는 Zod를 비롯한 여러 유효성 검사 라이브러리를 참고하게 되었습니다.
Optique는 여러 작은 파서들과 파서 컴비네이터들을 레고 부품처럼 조립하여 CLI가 어떠한 모양이어야 하는지를 표현합니다. 예를 들어 가장 작은 부품 중 하나로는 option()이 있습니다:
const parser = option("-a", "--allow", url());
이 파서를 실행하려면 run()이라는 API를 사용하면 됩니다:
(참고로 run() 함수는 암시적으로 process.argv.slice(2)를 읽습니다.)
const allow: URL = run(parser);
위 코드에서 제가 일부러 URL이라는 타입을 명시하긴 했지만, 굳이 그렇게 하지 않아도 저절로 URL 타입으로 추론됩니다. 위 파서는 -a/--allow=URL 옵션만을 받아들입니다. 다른 옵션이나 인자를 줄 경우 오류가 납니다. -a/--allow=URL 옵션이 주어지지 않아도 오류가 납니다.
만약 -a/--allow=URL 옵션을 필수가 아닌 선택으로 두려면 어떻게 해야 할까요? 그럴 때는 optional() 컴비네이터로 option() 파서를 감싸면 됩니다.
prog -a https://example.com/ --allow https://hackers.pub/prog -d https://example.com/ --disallow https://hackers.pub/
하지만 다음과 같이 -a/--allow=URL 옵션과 -d/--disallow=URL 옵션이 섞여있을 때는 오류를 냅니다:
prog -a https://example.com/ --disallow https://hackers.pub/
아무튼, 그럼 이 파서의 결과는 어떤 타입이 될까요?
const result: readonly URL[] = run(parser);
이런, or() 컴비네이터가 감싸는 2개의 파서 모두 readonly URL[] 타입의 값을 만들기 때문에 readonly URL[] | readonly URL[] 타입이 되어, 결과적으로 readonly URL[] 타입이 되어버렸습니다. 제대로 된 변별 공용체(discriminated union) 형식으로 바꾸고 싶군요. 아래와 같은 타입이면 좋을 것 같습니다.
변별자(discriminator)를 부여하기 위해 constant() 파서도 사용했습니다. 이 파서는 조금 특이한 파서인데, 아무 것도 읽지 않고 주어진 값을 만들기만 합니다. 즉, 항상 성공하는 파서입니다. 이렇게 변별 공용체를 구성할 때 주로 쓰이지만, 다른 창의적인 방식으로도 쓰일 수 있을 겁니다.
같은 방식을 응용하면 겹쳐진 서브커맨드(nested subcommands)도 구현할 수 있겠죠?
자, 이렇게 Optique가 CLI를 표현하는 방식을 보여드렸는데요. 어떤 것 같나요? Optique의 방식이 복잡한 CLI를 표현하기에 적합하다는 게 와닿으시나요?
물론, Optique의 방식도 완벽하지는 않습니다. 아주 전형적이고 단순한 CLI를 정의하는 데에는 오히려 더 손이 가는 것도 사실입니다. 또한, Optique는 오로지 CLI 파서의 역할만 하고 있기 때문에 일반적인 CLI 앱 프레임워크가 제공하는 다양한 기능은 제공하지 않기도 합니다. (추후 Optique에 더 많은 기능을 추가할 예정이긴 합니다만…)
그럼에도 Optique의 접근 방식에 흥미를 느끼셨다면, 소개 문서나 튜토리얼도 한 번 살펴보시기 바랍니다.
I mean, people with big egos cause serious problems! Fediverse itself is part of an evidence: Look at what Musk's ego did to our world. I am enraged.
Worse, this insight suggests me to ponder if I'm angry because my ego. That is further infuriating!
Worse, now I consider if I am so outraged because it has truth in it. That leaves me vehement!
This is a remarkable staircase of exponential anger. I am actually amazed. It reminds me of my astonishment when I first read Liu Cixin's _Death's End_, in which Luo Ji returns as the first Swordholder in the most terrifying, hard-boiled depiction of a war system.
Like an assassin, Hong Minhee forged this mental blade within a few words, and landed his strike. Now look at my babble. You can see how effective his attack was.
I still believe big egos are enraging, because they actually cause damage to our world, especially for equality and diversity.
I will also block anyone who asks me if I have a big ego.