iOS 에서 손수 crash reporter 구현하는데에 제약이 많은건 알고 있었지만 애플 엔지니어가 포럼에서 도시락 싸들고 다니면서까지 뜯어 말리는 줄은 몰랐다. ㅎㄷㄷ

이렇게 말리는데에는 몇 가지 이유가 있는데

1. 크래시 시점에 시그널을 외부 프로세스로 전달할 수 없기 때문에 스택이 정리되는 상태에서 덤프까지 써야 한다.
2. macOS 특성상 mach Exception 이 signal handling 보다 유리한데, 1의 이유로 제대로 exception 처리를 하기 곤란하고, 그래서 대부분 3rd party들은 signal handler를 등록해서 덤프를 처리한다. 필연적으로 누락되거나 제대로 처리되지 않는 경우가 발생한다.
3. async signal safe 함수만 써서 구현해야 한다. 안그러면 동작을 보장할 수 없다.

이 외에도 크고 작은 문제들이 생각보다 많고, 암튼 그래서 3rd party iOS 크래시는 수집이 쉽지가 않다.

https://developer.apple.com/forums/thread/113742

파이썬 공부할 겸 만든 토이 프로젝트를 소개합니다.

https://pypi.org/project/rust-minidump-mcp/

Rust Minidump MCP

Empower AI agents to understand crash dumps through MCP server

뭐하는 프로그램인가요?

크래시 덤프를 AI가 읽을 수 있도록 도와주는 MCP Server입니다.

어떻게 쓰나요?

우선 사용하시는 AI Agent 에 다음과 같이 rust-minidump-mcp 서버를 등록합니다.

{
  "mcpServers": {
    "rust-minidump-mcp": {
      "command": "uvx",
      "args": ["rust-minidump-mcp", "server"]
    }
  }
}

AI에게 크래시 덤프(minidump 포맷)와 symbol 이 저장된 위치를 전달합니다.
짜잔! AI 가 덤프를 읽을 수 있습니다. 크래시 원인을 요약하고 코드의 어느 위치에서 크래시가 발생했는지 알려줍니다.

이 정보를 어찌저찌 잘~ 엮으면 AI 에이전트가 크래시 보고 알아서 bug fix & PR 도 올릴 수 있도록 구성할 수 있지 않을까요?

저는 MacBook(또는 리눅스) 써서 minidump를 못남기는데요?

Minidump Writer 나 Crashpad Client, Breakpad Client 를 사용하면 크래시 시점의 ELF , DWARF 포맷을 minidump로 변환할 수 있습니다.

그밖에 궁금한 점은 아래 링크를 참조해 주세요~ https://github.com/bahamoth/rust-minidump-mcp

오픈소스 프로젝트에 여러분의 gemini cli(등등)의 무료 사용량을 기여하세요

오픈소스 소프트웨어라는 소프트웨어 개발 방법은 그동안 대성공을 거두어 오고 있습니다. 여기에는 여러 요인이 있지만, 중요한 요인 중 하나는 이것입니다. 상업 소프트웨어든 오픈소스 소프트웨어든 공평하게 프로그래머의 시간을 들인 만큼 개발된다는 것이지요. 능력 있는 소프트웨어 개발자가 시간을 기여하면 오픈소스 소프트웨어는 상업 소프트웨어만큼이나 빠르게 성장할 수 있었습니다.

하지만 AI 프로그래밍의 시대가 빠르게 다가오고 있습니다. 앞으로 소프트웨어 개발은 프로그래머의 시간만으로 개발되지 않습니다. 상업소프트웨어는 AI 프로그래밍을 적극적으로 사용하여 이전과 다른 생산성으로 개발되기 시작할 것입니다. 상업 소프트웨어와 달리 오픈소스 소프트웨어는 언제나 그럴 수는 없습니다. 프로젝트의 성장과 유지를 위해 훌륭한 프로그래머들의 시간을 들이는 것을 넘어서, 훌륭한 프로그래머들이 시간에 더해 비용까지 들여야 한다면요.

상업 소프트웨어와 오픈소스 소프트웨어 사이의 불균등한 생산성의 시대가 코앞까지 다가오고 있습니다.

새로운 기여자 확보의 문제

문제는 여기서 그치지 않습니다. 오픈소스 프로젝트는 새 기여자를 얻기 더 힘들어져가고 있습니다. 왜냐하면 이제 'good first issue'라는 것은 의미가 없기 때문입니다. 그 정도로 쉬운 일은 새로운 기여자 대신 로봇이 해결할 가능성이 높고, 그 로봇은 새로운 기여자의 로봇일 수도 있습니다. 결국 AI 프로그래밍으로 기여하는 새 기여자는 이 프로젝트에 대해 거의 배우지 못하게 됩니다.

전통적인 오픈소스 생태계에서 'good first issue'는 단순히 쉬운 문제를 해결하는 것이 아니었습니다. 새로운 기여자가 프로젝트의 코드베이스를 이해하고, 개발 프로세스를 익히며, 커뮤니티와 소통하는 법을 배우는 학습 과정이었습니다. 하지만 AI가 이런 단순한 작업들을 대신 처리하게 되면, 새로운 기여자들은 진입 기회를 잃게 됩니다.

AI 프로그래밍의 현재 위치

AI 프로그래밍은 완벽하지 않습니다. 숙련된 전문가가 숙련된 도메인에서 작업하는 것만큼 잘하지는 못합니다. 하지만 비숙련된 프로그래머가 처음 보는 프로젝트에서 작업하는 것보다는 잘할 때가 많습니다.

그러나 많은 오픈소스 소프트웨어는 바로 이런 비숙련 기여가 성장의 한 축을 차지합니다. 처음 프로젝트에 참여하는 개발자들의 작은 기여들이 모여 거대한 프로젝트가 됩니다. 그리고 이런 비숙련 기여의 일부는 손쉽게 AI가 대체할 수 있는 기여입니다.

다행히도 지금은 AI 프로그래밍의 초창기입니다. Gemini CLI가 무료 사용량을 제공하듯이, 앞으로 여러 회사들이 비슷한 기회를 제공할 것입니다. Claude, ChatGPT, Copilot 등 다양한 AI 도구들이 개인 사용자에게 무료 크레딧을 제공하고 있습니다.

이것은 오픈소스 프로젝트에 기여할 새로운 기회로 삼을 수 있을까요?

주의: 이 글은 아무 프로젝트에나 방문해서 AI로 적당한 코드를 생성한 다음 패치를 보내라는 뜻이 아닙니다.

AI 프로그래밍은 (아직은) 마법이 아닙니다. "이 프로젝트를 겁나 멋지게 만들 기능을 추가해주세요"라고 한다고 해서 그런 패치가 나오는 식으로는 동작하지 않습니다.

이상적인 경우: AI 친화적 프로젝트

가장 좋은 방법은 프로젝트가 AI 친화적으로 준비되는 것입니다. 바로 작업할 수 있을 만큼 잘 정의된 이슈들이 있는 프로젝트라면, "nnn 번 이슈에 대해 작업해 주세요"라는 요청만으로도 누구나 기여할 수 있을 것입니다.

하지만 (적어도 아직은) 그런 프로젝트가 많지는 않을 것입니다.

현실적인 접근: AI가 잘하는 일들에 집중

대신 AI는 인간과 비대칭적으로 잘하는 기능이 있습니다.

이를테면 이슈에 minimal reproducible case가 보고되어 있지만 아직 구체적으로 발생하는 원인이 밝혀져 있지 않은 경우를 생각해봅시다. 버그를 고치는 사람이 해야하는 지루한 작업 가운데 하나는, 이 문제를 어떻게 수정할지를 생각하기에 앞서 이 문제가 어디서 발생하는지 찾는 것입니다. 디버거를 써야 할 수도 있고, 코드에 많은 trace log를 남겨야 할 수도 있습니다.

하지만 AI 코딩 에이전트는 테스트가 재현 가능하기만 하다면, 문제를 발생시키는 정확한 줄을 찾아내는 데 탁월합니다. 지치지 않고 정석적인 지루한 방법으로 꾸준히 로그를 추가하고 테스트를 다시 실행하면서 문제를 찾아내거든요.

어쩌면 문제의 원인이 아주 단순해서, 문제를 바로 수정할 수 있을지도 모릅니다! 그렇다면 패치를 제출해도 좋겠지요. 하지만 바로 수정하기까지는 어렵더라도 괜찮습니다. 버그 리포트와 실제 코드의 문제를 매핑하는 것은 그 자체로 지루하고 시간이 걸리는 일입니다. 이것을 대신하는 것으로도 큰 작업을 대신하는 것입니다.

주의: 모든 프로젝트가 AI 기여를 환영할 리는 없습니다. 충분히 유용하게 다듬어지지 못한 유형의 AI 기여는 스팸처럼 느껴질 가능성이 있음을 유의해야 합니다.

미래

사실 누구나 자기 라이브러리를 뚝딱 만들어낼 수 있게 되었다는 점에서 오픈소스 프로젝트에 참여하는 사람들의 동기와 기여 방식 자체가 크게 뒤바뀔 가능성이 높습니다.

AI 프로그래밍을 누구나 거의 무료로 사용할 수 있는 시대가 올까요? 아마 어느 정도의 사용량까지는 그럴 것입니다. 그것이 얼마나 많은 양일지에 따라서 오픈소스 프로젝트의 미래는 크게 바뀌겠지요.

만일 정말로 AI 프로그래밍을 누구나 무제한적으로 사용할 수 있다면, 대규모가 아닌 대부분의 오픈소스 프로젝트에는 더이상 협력이 필요하지 않을 것입니다. 진정으로 '어떻게'보다 '무엇을'이 더 중요한 시대가 온다면, 프로젝트의 목표를 확고하게 가진 사람이 극한의 완성도까지 프로젝트를 밀어붙이는 편이 훨씬 좋은 결과를 만들겠지요.

그런 시대가 올지 오지 않을지 모르겠습니다. 하지만 그 전까지는, AI 프로그래밍이 누구에게나 주어지는 기회이지만 프로젝트를 단숨에 완성할만큼 주어지지는 않는 시대가 유지되는 동안에는, 다음 세대의 오픈소스 기여의 방법은 AI 프로그래밍 사용량을 기여하는 것이 하나의 큰 축이 될 것입니다.

fastmcp 2가 나왔구나.
json-rpc 도 추가되고 바뀐게 많네..

https://gofastmcp.com/updates

https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http

@theeluwin제이미 Jamie 님 쓰시는 방식이 저랑 좀 다른 것 같아 살펴보니 제가 미리알림 사용법을 잘 몰랐었네요..
crontab 처럼 반복이 되는 기능이 있는 줄 모르고 매일/매주 단축어로 새로 미리알림 생성 스케줄을 걸어두었었어요.
할 일을 세세하게 나누고 일/주 단위로 반복을 걸어놓으니 너무 좋네요!!

코딩 에이전트들이 uv를 회피하는 경향이 있어서 짜쳤었는데 이렇게 지시를 해두니 uv를 잘씀. never invoke 가 key term 인듯?

• Python 3.11 + managed exclusively with uv.

  • Never invoke pip, python -m venv, virtualenv, poetry.

• Environment workflow

1) create / refresh the virtual environment

uv venv source .venv/bin/activate

2) add or upgrade a dependency

uv add <package> uv add --dev <package> uv remove <package>

3) install everything exactly as pinned

uv sync

* **Running commands** – always prefix with `uv run --`
  ```bash

  uv run -- ruff check .
  uv run -- mypy .
  uv run -- pytest -q
  

@kodingwarriorJaeyeol Lee 오! 클로드 맥스의 퍼포먼스가 어떨지 궁금하네요.

지난번 read papers with me에 이어서... 이번에도 어차피 논문 읽을겸, 세미나 발표 준비하듯 피피티도 만들고, 영상도 촬영해봤는데요,

결국 촬영 + 편집에 오버헤드가 너무 많이 걸려서 이것도 그다지 좋은 방법이 아니었네요. 혹시라도 비슷한 생각 하신 분들은 참고하시길(...)

https://www.youtube.com/watch?v=X6yWfjBgHsg

DRM 깨고 개인소장하는 걸 합법화 해주세요
대신 그렇게 해서 배포하거나 관리가 부실해서 유출되면 책임은 당연히 지는거고

덴마크 디지털부, Windows와 Microsoft Office를 Linux와 LibreOffice로 교체
------------------------------
- *덴마크 디지털부* 가 전 직원의 *Windows와 Office 365* 를 각각 *Linux와 LibreOffice* 로 단계적으로 전환 중임
- 이번 조치는 덴마크의 *디지털 주권 강화와 특정 공급업체 의존도 감소* 전략의 일환임
- 코펜하겐 및 오르후스 등 주요 지방자치단체에서도 유사한 변화가 확산됨
- 장관은 오픈소스 …
------------------------------
https://news.hada.io/topic?id=21425&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

구글 release-please + python(uv) 프로젝트 시멘틱 버저닝 버그.

release-please 를 이용해 uv 로 관리하는 프로젝트를 Semantic Versioning 하려면 아직 release-please에서 uv 지원을 안하기 때문에 uv.lock toml을 array filter 써서 편집해 줘야 한다. uv.lock 편집을 안하면 봇이 올리는 릴리즈 PR 이 실패한다.

문제는 toml 을 json 변환할 때 오류가 있어서 의도대로 편집이 안된다는거.

일단 요런 식으로 Ad Hoc 한 땜질이 가능함.

혹시라도 누군가 release-please + uv 로 SemVer 설정할 때 나처럼 삽질하지 않길 바람.

"jsonpath": "$.package[?(@.name.value=='package-name')].version"

https://github.com/googleapis/release-please/issues/2455?utm_source=chatgpt.com

6월 3일 부로 kaniko 프로젝트가 archived 되었단다.

Cloud Native CI 환경에서 유용한 rootless 컨테이너 빌드 도구였는데 ㅠㅠ
https://github.com/GoogleContainerTools/kaniko

타협하는 마음으로 매번 민주당을 찍는다. 나는 좌파고 애국심도 없는 반면 민주당은 애국보수이기 때문에 정치적으로 맞지 않는다. 국민의힘을 비롯한 일부 정치 세력과 일부 종교 세력은 “보수”가 아니라 “반인륜적 기회주의 세력”에 불과하기 때문에 애초에 고려 대상이 아니다.

반인륜적 기회주의 세력이 충분히 정리되고, 민주당이 정통보수로 자리잡고, 언론이 제대로 작동하기 시작하면(현재의 언론은 기회주의 세력의 일부이거나 극도로 무능하다), 그러면 드디어 안심하고 내가 실제로 지지하는 진보 계열 정당을 찍을 수 있을 것 같다.

이재명은 성남시장 시절부터 존경하던 정치인이자 행정가다. 기회주의자들의 이재명 악마화는 전혀 믿지 않는다. 그가 공약을 지키기 위해 최선의 노력을 할거라고 믿는다. 다만 그는 보수주의자이고 애국자라서 나랑 맞지 않을 뿐이다. 모든 공약에 반대하는 건 아니다. 예를 들어 보편기본소득 관련 정책은 적극 지지한다.

권영국의 공약은 나랑 잘 맞는 편인데(어떤 정치성향 테스트에 의하면 88% 일치) 이걸 그대로 믿는건 아니다. 원래 지지율이 낮을수록 강하고 선명한 메시지를 낼 수 있는거니까. 게다가 권영국이 지금 당장 당선된다 하더라도 그의 공약이 그대로 실행될 가능성이 매우 낮다. 한국은 아직 그렇게 좋은 나라가 아니다.

부디 이재명 정부가 성공하길 진심으로 바란다. 그 덕에 다음 대선 혹은 다다음 대선에서는 꼭 진보정당을 뽑고 싶다.

이재명이 과반을 넘긴 점, 이준석이 선거비 보전을 한 푼도 받지 못하게 된 점은 아주 기쁘다. 다만 권영국의 지지율이 더 높지 않은 게 아쉽고 미안하다.

Right now, South Korea is counting votes for the presidential election. Amid this, it has been revealed that men in their 20s and 30s overwhelmingly support Lee Jun-seok—an anti-feminist and effectively fascist candidate. I feel not only ashamed of my country's men of my generation but also deeply concerned. I believe there is a very high chance that South Korea could become a fascist country in 10 to 20 years. As a socialist and leftist, I feel powerless…

Apache Pulsar 4에서 ZooKeeper가 대체되는구나.

원래 Pulsar는 장기 플랜으로 ZooKeeper 대체를 계획, Cloud Native 한 운영에 맞도록 etcd를 대체자로 계획하고 있었다.
근데 어쩐 일인지 oxia 라는 Metadata store service 를 자체적으로 개발, etcd와 oxia 중에 선택할 수 있도록 했다.

메세지 브로커 서비스 특성상 운영에 큰 문제거 없다면 잘 건드리지 않기 때문에 당분간 내가 쓸 일은 없겠지만 Cloud Native 한 Pulsar 신규 구성을 염두에 둔다면 oxia를 고려해 보는 것도 나쁘지 않겠다.

https://streamnative.io/blog/announcing-apache-pulsar-tm-4-0-towards-an-open-data-streaming-architecture

https://github.com/streamnative/oxia?tab=readme-ov-file

simonw llm https://llm.datasette.io 을 써봤는데 커맨드라인에서 사용하기 편하다.

데코레이터 대신 직접 함수객체 생성하려고 Callable 타입인 fn을 lambda로 넘기려 한다. arguments 처리를 위해 signature 정보를 넣어줬더니 mypy 가 배를 짼다.

이럴땐

1. cast 한다
2. mypy ignore 한다

어떻게 하는게 바람직한가요?

간만에 필받아서 aider 커꾸(commit 꾸미기) 함.
gum 이라는 훌륭한 쉘꾸 도구 + git pretty format + delta 썼어요

# Define the git log format string with color formatting for better readability
local GIT_FORMAT="%C(bold yellow)Hash:%C(reset) %C(bold cyan)%h%C(reset) %C(dim white)(%cd)%C(reset)%n"
GIT_FORMAT+="%C(bold yellow)Author:%C(reset) %C(bold white)%an%C(reset) %C(dim white)<%ae>%C(reset)%n"
GIT_FORMAT+="%C(bold yellow)Message:%C(reset) %C(bold white)%s%C(reset)"

# Define the date format
local DATE_FORMAT="%Y-%m-%d %H:%M:%S"

# Perform the commit with aider and show a styled commit summary
aider --commit && \
gum style \
  --border rounded \
  --padding "0 2" \
  --border-foreground 39 \
  "$(git log -1 \
      --pretty=format:"$GIT_FORMAT" \
      --date=format:"$DATE_FORMAT" \
      --color=always)" && \

# Show detailed changes using delta for side-by-side diff with line numbers
git show -1 --color=always --stat --patch | delta --side-by-side --line-numbers

가장 선호하는 JetBrains IDE가 AI 시대에 뒤쳐지고 있어서 안타까웠는데 AI assistant 와 Junie 업데이트로 이제 좀 쓸만해진 것 같다.

여전히 부족한 점이 많기는 하다.
Agent는 느리고, 현재 상태에 대한 가시성이 없어 계속 기다려야할지 중단하고 새로운 세션을 열어야 할지에 대한 판단이 안선다.

prompt를 별도 관리할 수 있게 한 점은 훌륭하나 포맷이나 디렉토리를 유저가 선택할 수 있게 했더라면 더욱 유용했을 것이다. 나는 prompt가 다른 에이전트와 공유 가능하길 원한다.

vscode copilot처럼 Claude로부터 mcp 서버 설정을 불러올 수 있다. 하지만 역시 현재 상태 가시성이 없어 제대로 mcp 서버와 인터랙션이 되고 있는지 확인하기 어렵다.

그럼에도 불구하고 Cursor 나 Copilot에 충분히 대항할만한 업데이트라 생각한다. 앞으로를 응원한다!
https://www.jetbrains.com/ko-kr/junie/

Manning 에서 올해 4번째로 구독한 책은 'API Design Patterns'

https://www.manning.com/books/api-design-patterns

API 설계의 원칙에 맞게 고려할 사항들을 패턴화, 일목요연하게 정리한 책. GoF 책처럼 Motivation, Overview, Implementation, Trade-off 로 구분지어 설명하는 구성이 너무 마음에 든다. 뛰어난 개발자/개발사가 작성한 API를 자주 경험하다보면 & 개발 경험이 어느 정도 쌓이면 API 설계에 대한 감이 적당히 생기는데 이 책은 '적당' 하거나 '감' 의 영역에 있던 불분명한 경계를 명확히 해준다는 장점이 있다.

회사의 Private Network 환경에서만 발생하는 간헐적 alpine docker build hang 문제가 있었다. 이 문제의 원인은 MSS(Maximum Segment Size) 경계에 걸친 패킷이 alpine apk 의 DF(Don't Fragment) flag 때문에 적절히 분할되지 못해 생기는데에 있었다. (방화벽 문제도 있지만 이건 원인을 정확히 모르겠다.)

기록해 둘만한 재미있는 현상이어서 글로 정리를 하고 싶었는데 안타깝게도 회사 밖에선 재현이 어렵네.

암튼, Private Network 환경에서 간헐적으로 docker 의 동작이 달라진다면 bridge interface 의 MTU 를 조정해 볼 것을 추천한다.(특히 alpine)

나스닥도 국장이다

@kodingwarriorJaeyeol Lee 하스켈로 HTTP 서버를 바닥부터 구현하는 책입니다. https://leanpub.com/sockets-and-pipes

Vim/Neovim의 시대가 가고, Vibe Coding 내지는 LLM 에이전트의 도움을 얻는 시대가 왔다지만, 난 아직까지는 전적으로 동의하지는 않음(부분적으로는 동의한다는 의미) 아직까지는 수제로 직접 코드를 짜는 것도 의미가 있고, CLI 기반의 에디터도 저마다의 발전을 하고 있다고 자신있게 말할 수 있음.

내가 생각하는 요오즘 시대 개발의 장점도 언급하면서 CLI 기반의 에디터는 어떤 위치에 있는지도 얘기해보고자 한다.

1. 신뢰구간이 넓지 않아도 되는 작업을 할때는 AI를 사용하는 코드가 분명 시간을 확 줄여주고 결과적으로 생산성을 향상시키는 경향은 있지만, "정확함"을 위해서 프롬프트를 넣어야 하는데 그 프롬프트를 넣는 작업이 품이 많이 들때(넣어야 하는 맥락이 너무 많을때) 그렇게 정확하지는 않을뿐더러 맥락을 넣는 시간 때문에 차라리 내가 직접 짜는게 나을때가 많음. 수제로 직접 짜기 vs AI한테 전적으로 맡겨버리기 두 세계를 적절하게 오가면서 작업하는게 베스트이지 않나 싶음.

2. GUI 에디터 특유의 장점도 분명 있긴 있다. GUI 에디터가 올인원 기능을 갖추고 있는 경우도 많고 편의성 면에서 미니멀리즘을 추구하는 CLI 기반의 에디터보다 가진 기능이 많다. 남이 차려준 밥상이 그렇게 달달하지 않을 수 없다. 하지만, 그런 기능들을 제공하는 플러그인이나 자체 기능들의 내부 구현을 막상 까보면 CLI 도구에 의존하는 기능들이 많다. 특히, LSP/린터/포매터가 그렇다. 다만 추상화레이어를 어떻게 감쌌느냐 정도의 차이가 있는데, 그 추상화레이어를 커스터마이징하는데 있어서의 진입장벽은 CLI 기반의 에디터가 상대적으로 낮은 편이다. 왜냐면, 인고의 시간을 거쳐서 해온게 딱 그거라서(.....)

3. 바이브 코딩은 분명 압도적인 속도로 코드가 짜여질 수 있게 하고, 단위시간당 코드가 짜여지는 양 자체도 어마어마하다. 특히, scaffolding을 할때 더더욱 빛을 발휘한다. 그렇기 때문에, 코드를 짜는건 기계/인공지능에 위임하고, 자세한 디테일을 채우는건 유저리서치를 하거나 와이어프레임을 그려서 기획을 더 보강하는 등 중요한 영역에 집중할 수 있게 된다. 코드를 짜는데 드는 시간은 최소한으로, 중요한 영역에 집중하기 위해 생각하는 시간을 더 많이 가지는 것은 분명 좋은 일이다. 관련해서는 이 글도 읽어보면 좋을 것 같다. https://two-wrongs.com/typing-fast-is-about-latency-not-throughput

물론, 코드를 짜는데 있어서 중요한 것은 리터러시이다. LLM이 코드베이스의 이해를 빠르게 할 수 있도록 도와주긴 하지만, 위에서 언급했듯 어느 정도 시점이 되면 결국엔 직접 짜고 직접 수정하는 일도 있어야 한다. 로컬 LLM이 발전한다 하더라도, LLM을 사용할 여력이 되지 않는 환경에서도 동일한 생산성을 유지할 수 있을까? 생산성이 일관적이지 않다면, 그렇지 않은 환경에 노출이 되었을때 어떻게 대응할 수 있을지가 중요한 포인트일 수 있다고 생각한다. 인자강, 즉, 사람 자체가 강해질 필요가 있다고 생각한다.

인공지능에 전적으로 의존하지 않고 수제로 직접 코드를 짜는 사람들이 기계/인공지능에 저항해서 어떻게 살아남을까를 생각해보면 인간공학에 기반해서 편집하는 테크닉이 더 연구될 필요가 있다.

GUI 기반의 에디터가 날이 갈수록 좋아지고 있는 상황 속에서 CLI 기반의 에디터가 살아남으려면 더더욱 CLI 기반의 도구와 궁합이 좋은 것을 내세워서 차별점을 내세울 필요가 있다. Neovim은 그런 관점에서 IDE와 유사한 경험을 제공하는 쪽으로 잘 발전되어 왔다고 보고 있다.

Vim/Neovim 생태계는 아직까지는 미래가 낙관적이라고 본다.

#툿친소

디지털 가드닝에 관심이 많은 개발자입니다.
- 특히 위키 형식의 문서 관리, knowledge graph 구조의 시각화에 관심이 있어요.
- kodingwarrior.github.io/wiki

Neovim 이라는 텍스트 에디터에 굉장히 꽂혀있습니다.
- 과몰입한 나머지 플러그인까지 개발해본 경험이 있어요.
- 한국어권 개발자를 위한 Vim 디스코드를 운영중입니다 (vim.kr)

프로그래밍을 하는 행위 자체를 좋아합니다.
- 프로그래밍으로 퍼즐을 푸는 행위를 좋아했고, 비슷한 흔적을 가진 사람들에게 친밀감을 느낍니다.