🪟 "내 코파일럿 키를 어떻게 한 거냐!"

☘️ "코파일럿 키? 아아, 「이것(한자 키)」 말인가?"

🪟 "키사마아아아아아아----------!!!!!!!!!"

AI FOMO에 휩쓸려 뭐라도 해야겠다는 생각이 드는 입문자(?)라면, 대뜸 강의든 장비든 뭐든 비싼 무엇을 사지 말고 다음 두 가지를 하시길 권해봅니다.

1. 가장 비싼 Plan으로 마음껏 써보기 클로드 코드, 코덱스 등 AI 에이전트 서비스의 가장 비싼 Plan을 한 달 정도는 경험해보세요. 사용량 제한받거나 성능이 떨어지는 AI 모델을 쓰면, AI에 대한 관점도 그 정도에 갇힐 가능성이 커요.

프론티어급 모델을 토큰 화끈하게 사용했을 때 AI 서비스가 제공하는 가치는 꼭 경험해봐야 합니다.

AI 모델 이용료는 더 줄어들 수 있지만, AI 모델을 더 내 손 위에 쥐어주는 AI 에이전트 서비스는 부가가치를 높이는 방향으로 이용료가 낮아지진 않을 겁니다. 게다가 현재는 경쟁하느라 적자 감수하며 퍼주는 것에 가까워서 고객에게 잔치 시기가 끝나면 이용료가 오르거나 제약이 커질 것 같습니다.

제 직업 환경의 상황으로 예로 들지요. 새로운 소프트웨어 개발 도구를 도입할 때, 잘못 도입하면 발생하는 비용이 크기 때문에 많은 시간 분석하고 검증하고, 학습하였습니다. 가치있는 일이지만 시간 비용이 너무 큽니다. 그러나 최근에 AI 코딩 에이전트를 이용해 후보 도구를 동시에 적용해봅니다. 예전엔 여러 사람이 동원되거나 긴 시간을 들여야 했지만, 이제는 혼자서 짧게는 몇 시간, 길어도 며칠 안에 실 경험에 기반한 판단 자료를 도출합니다.

리서칭하는 도구에 대해 직접 조사하거나 AI가 조사한 걸 리뷰하고 재검증하기도 했습니다. 하지만 사용량이 넉넉한 Plan을 사용한 이후로는 사용할 도구가 오픈소스인 경우, 코드 전체를 AI 에게 분석시키곤 합니다. 토큰 사용량으로 보면 1시간도 안 되어 몇 만원을 쓰는 셈인데, 제가 알고싶은 정보를 자세히 학습하기에도 좋고, AI 환각을 줄여주는 데에도 도움이 됩니다.

사용량 제한이 큰 Plan을 사용할 땐 마치 토큰을 아껴쓰느라 예전처럼, 즉 현재처럼 AI를 활용할 엄두를 못냈습니다.

2. 가능성과 한계 인식하기 1번의 연장인데, 화끈하게 AI 에이전트를 여러 방향으로 사용하다보면 자연스레 생각이 복잡해질텐데, 특히 다음 두 가지를 고민해보세요.

• 내가 하는 일, 내 환경에 대해 재정의하기
• 재정의한 내 상황에 비추어 가능성(미래)과 한계(현재)를 정의하기

그동안 많은 일하는 방식, 학습하는 방식, 협업하는 방식은 “사람”을 대상으로, 기준으로 하여 오랜 세월 고도화되어 잡힌 체계입니다. AI는 사람과 다릅니다.

소프트웨어를 만드는 환경을 예로 들겠습니다. 조직의 협업 체계에서 대개는 개발팀, 즉 소프트웨어 개발이 병목 자원입니다. 그래서 병목 자원 관리에 초점을 많추는 소프트웨어 개발 방법이나 협업 체계가 대부분입니다. 과감히 납작하게 본다면, 기획을 조직에 전파하는 용도로 발표 장표를 만드는 이유는, 그 작업 비용이 더 싸기 때문입니다. 전달력이 떨어지지만 전체적으로 봤을 때 저렴한 경우가 많습니다. 만약 발표 장표 만드는 목적이 비용이라면, AI 코딩 에이전트를 사용하여 데모 버전을 만드는 게 더 저렴합니다. 이용료, 시간은 물론이고, 실제 돌아가는 데모 버전의 전달력도 정적인 글, 그림보다 낫습니다.

AI 에이전트를 펑펑 사용하면서 자신이 일하는 체계, 방식에서 사람 간 협업을 기준으로 하는 부분이 무엇인지 고민해보세요.

대체하거나 효율을 높일 부분 뿐만 아니라 한계도 고민하세요. 그 한계가 AI 모델이나 에이전트에서 기인하는 걸 수도 있고, 사람(자기 자신)에게서 기인하는 걸 수도 있습니다.

2번 단계에 오면 다음에 뭘 해야할지 방향이 잡힙니다. 하다못해 강의나 강좌, 책도 무엇을 봐야할지 관점이 생깁니다. 어떤 사람과 어떻게 협업할지, 어떤 도구에 돈을 더 들일지, 내가 몸으로 떼우는 게 나을지. 그 단계에 돈을 쓰세요.

이 과정을 경험하고, 내 관점을 갖는 데 1~2달이면 충분합니다. 요즘처럼 AI 발전이 빠른 시기에 너무 느린 것 아니냐고요. 불과 1년 전만 해도 AI 코딩 에이전트의 수준은 현재와 비교불가 수준이었다는 걸 보면 그런 마음이 들 수 있습니다. 근데, AI가 도구라는 점은 전혀 달라지지 않았습니다. 문제를 정의하고, 실제 문제를 해결하는(execution) 결정과 방식은 사람이 합니다. 끊임없이 새로운 도구는 나왔고 발전해왔지만, hello world에 머무르는 사람은 그때나 지금이나 hello world에 머무르고, 변화를 일으키거나 변화하는 사람도 그때나 지금이나 있어왔습니다.

보안 위협 등 조심해야 할 건 많은데, 이또한 앞서 거론한 “한계”로 파악하는 게 우선입니다. 문제를 알고, 정의할 수 있으면 해결 방법도 찾을 가능성이 큽니다. 더군다나 AI가 끝내주는 점 중 하나는 자연어로 소프트웨어 “엔지니어링”을 실행하는 겁니다. 그리고 “소프트웨어”여서 실행 비용이 상대적으로 저렴하고요.

고환율 시기라 100 USD, 200 USD가 부담스럽지만, 고성능 AI 도구를 다양한 방법으로 써보며 내 생각과 관점을 넓히는 비용으로는 저렴합니다.

Daum (Kakao) 우편번호 서비스 도메인 & JS API 네임스페이스 변경 안내 (사전 공지)

https://github.com/daumPostcode/QnA/issues/1498

GeekNews에도 올리기는 했는데, 아무래도 국내 서비스에는 영향을 받는 곳이 많다보니, Hackers' Pub에도 공유해 둡니다.

1. 공식 가이드 페이지

• 현재: https://postcode.map.daum.net/guide
• 2026-03-10 이후: postcode.map.kakao.com 으로 이전 예정

2. CDN 도메인 변경 (적용 완료)

• 기존: t1.daumcdn.net
• 변경: t1.kakaocdn.net

3. 서비스 도메인 변경 일정 (예정)

• 공식 가이드 / 서비스 팝업
  • 기존 dmaps.daum.net
  • 변경 postcode.map.kakao.com

4. JavaScript API 네임스페이스 변경 안내

• 기존 new daum.Postcode({...
• 변경 new kakao.Postcode({...

5. 서비스 종료 예정 도메인 안내 (중요)

• 2026년 4~5월 도메인 최종 전환 시점에 서비스가 종료될 예정
  • dmaps.daum.net
  • ssl.daumcdn.net

6. 도메인 변경 사전 안내 및 네임스페이스 변경에 대한 안내

• 기존 도메인 종료에 대한 상세 일정은 3월 10일 전후 공지에서 다시 안내
• 서비스 중단 방지를 위해 사전 점검 및 점진적 전환을 권장

IMO about concurrent programming

소신발언: C 비슷한 문법을 가진 언어 중에서 C++가 제일 문법이 이질적이다.

템플릿은 말할 것도 없고, 앞뒤에 아무 것도 붙지 않은 {}를 polymorphic한 값으로 취급하는 건 아마도 C++가 유일할 것이다.

Weekend thoughts on Gas Town, Beads, slop AI browsers, and AI-generated PRs flooding overwhelmed maintainers. I don't think we're ready for our new powers we're wielding. https://lucumr.pocoo.org/2026/1/18/agent-psychosis/

@hongminhee洪 民憙 (Hong Minhee) @bglbgl gwyng 하하 Git은 CLI로 쓰는 거죠 하하하!

@hongminhee洪 民憙 (Hong Minhee) 저도 비슷한 이유로 Emacs로 회귀했다가 지금은 Zed를 쓰게 되었습니다 😂

https://rosettalens.com/s/ko/truths-programmers-should-know-about-case

@curry박준규 파이썬의 전통을 이었다고 해 주세요 (?)

크리스마스는 새 프로그래밍 언어를 공개하기에 좋은 날이죠. 아직 미완성이지만 요즘 작업하고 있던 프로젝트를 소개합니다. https://github.com/Kroisse/tribute

순수 함수형이고, 모나드는 없고, 소유권도 없고, 타입클래스나 트레잇도 없습니다. 물론 객체 시스템도 없고요. 대신 제네릭과 대수적 효과를 넣을 예정입니다. ad-hoc polymorphism을 배제하고 어디까지 갈 수 있는지 시험해보려는 게 목적 중 하나인데 생각보다 할만할 것 같아요.

그리고 매우 vibe-coded되어 있습니다. Claude Code와 Codex가 없었으면 엄두도 못 냈을 듯.

문법적으로는 Rust와 Gleam에, 의미론적으로는 Gleam과 Unison에 영감을 많이 받았습니다. 사실 Gleam과 Unison 둘 다 네이티브 바이너리로 컴파일을 아직 못 하고 있어서 시작한 프로젝트이기도 합니다. 하지만 정작 Tribute도 첫 타겟은 네이티브가 아니라 WebAssembly 3.0입니다. GC 구현을 만들기 귀찮았거든요.

Rust 이후로 한동안 새 언어 배우는 데에 뜸하다가 최근 건드려 보는 것만 Gleam Lean Unison 이렇게 세 개가 되게 생겼는데 이게 맞나

수상한 컨셉의 함수형 언어가 1.0을 찍었는데 생각보다 재밌어 보여서 한 번 찍먹해 볼까 싶다.

https://www.unison-lang.org/unison-1-0/ https://rosettalens.com/s/ko/the-big-idea https://rosettalens.com/s/ko/abilities-and-ability-handlers

Gleam의 흥미로운 점 두 가지.

1. 함수 오버로딩도 인터페이스 다형성도 타입클래스도 없다. 심지어 이건 기본 타입과 연산자에서도 동일해서 정수 타입인 Int와 부동소수점 실수 타입인 Float는 사용하는 연산자가 다르다! 실수 두 개를 더하려면 5.0 + 3.0이 아니라 5.0 +. 3.0이라고 써야 한다. https://tour.gleam.run/basics/floats/
2. 위의 링크를 눌러 보았다면 눈치챘을지도 모르겠지만, Gleam에서 0으로 나누기는 에러가 아니다! 이건 정수와 실수 모두 동일하며, 그렇다고 Infinity나 -Infinity, NaN 따위가 나오는 것도 아니다. Gleam에서 a / 0은 0이다.

Gleam 언어는 뭔가 별다른 복잡한 요소가 없어서 오히려 재밌는 구석이 있는 것 같다. 제네릭 말고는 별다른 다형성 기능이 없어서 오히려 설계를 고민하게 만든다던지. 서브타입도 타입클래스도 없으니까 제네릭 인자로 넘긴 타입에 뭔가 연산을 하고 싶으면 반드시 호출하는 쪽에서 연산에 필요한 함수를 그때그때 전달해야 한다. TypeScript의 any 타입처럼 gradual typing이 지원되는 것도 아니라서 정 타입시스템을 우회하고 싶으면 그때그때 Dynamic 타입으로 인코딩과 디코딩을 거쳐야 한다. Erlang 기반이니까 액터를 끌어다 쓸 수 있기는 하지만 아무래도 다른 언어에서 그냥 객체를 정의하고 메서드를 부르는 것보다는 무겁게 느껴진다. 액터라고 해서 타입이 아예 없는 것도 아니고.

언어 명세 전체가 한 페이지에 들어온다는 건 실용적인 건 아니지만 멋진 일이죠.

https://github.com/SelfBatteries/SelfCheatSheet/blob/master/self_cheatsheet.pdf

알고계십니까? 고대의 언어인 줄 알았던 Smalltalk 친척 Self는 놀랍게도 최근까지도 업데이트가 되고 있습니다. https://selflanguage.org/

JavaScript의 .prototype 개념에도 영향을 주었다고 알려진 Self가 어떤 언어인지 궁금하시다면 Series about Self(lobste.rs)를 읽어보세요. 프로그래밍 언어에 대한 여러분의 시야가 넓어지는 데에 도움이 될 겁니다.

한국어 번역:

1. 환경
2. 언어
3. 디버거, 트랜스포터, 그리고 문제점
4. 커뮤니티, 역사, 미래, 형이상학

@hongminhee洪 民憙 (Hong Minhee) What the……

@hongminhee洪 民憙 (Hong Minhee) Ruby를 쓰고 정적 타입 검사를 거부하며 과도한 메타프로그래밍을 지향해서인가요?

여러분 int *p를 (int *)(uintptr_t)p 캐스팅하지 마세요 출처라는 것이 바뀝니다

C++에서 UB는 하드웨어 수준에서는 UB가 아니라고 생각했던 얼마 전에 나어게 경종을 올렸던 글. "Pointers are complicated" 시리즈. 주로 Rust에 관한 글이지만 abstract machine, memory model의 개념은 C++에도 있으며 하드웨어와는 확연히 다르다. 특히 포인터가 얼마나 까다로운 개념인지, 컴파일러가 어떠한 가정하에서 최적화를 수행하는지 다시금 익혔다.

• https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html
• https://www.ralfj.de/blog/2019/07/14/uninit.html
• https://www.ralfj.de/blog/2020/12/14/provenance.html
• https://www.ralfj.de/blog/2022/04/11/provenance-exposed.html

찾아보니까 lambda expression이 처음 도입된 Java 8이 2014년, 그러니까 지금으로부터 딱 11년 전에 나왔다.

https://purplesyringa.moe/blog/if-i-hear-design-pattern-one-more-time-ill-go-mad/ (한국어 번역)

If I wanted to go mad thinking abstractly about trivial things, I’d study category theory.

But even Java itself, the language so terrible at fostering good architecture, it has become a joke, has had all of those feature for at least 10 years. So can we abolish “command” and “strategy” now, pretty please?

오래 전

현대 컴퓨터는 계산기라기보다는 복사 기계에 더 가깝다

는 문장을 읽었고 그것에 대해 종종 생각함. 생각해 보면 정말 하는 일이 대개 그런 것에 속한다고 느낌. 어딘가에 있다는 데이터를 모으고 가공하고 정제해서 또 어딘가에 두고 그걸 누군가 가져갈 수 있게 하는 일 끊임 없이 반복함. 데이터의 형식이나 크기나 여러 속성이 다양하고 그래서 다루는 방법과 기술에도 많은 차이가 있지만 어쨌든. 요즘 종종 인용되는 타입 검사는 해결책이 아니라 증상이다(Type Checking is a Symptom, Not a Solution)에 대한 반응들을 보고 직렬화 글과 거기 인용된 인터넷은 디버깅 모드로 돌아가고 있다는 글까지 떠올랐음.

(이 글은 Hackers' Pub에서 제공하는 Markdown 문법 가이드에 익숙해지기 위한 시도로 작성함.)

이런 비직관적이고 알고리즘 수업 때 배웠던 시간복잡도를 무시하는 듯한 결과 또한 메모리 추상화와 깊이 연관되어 있더라. 학부 때야 메모리 접근 정도는 O(1)이라고 가정하지만, 현실은 그렇지 않으니......

(한국어 번역: https://rosettalens.com/s/ko/hashed-sorting)

LWN.net의 What every programmer should know about memory 시리즈를 훑어 보고 나서 든 생각인데, 현대적인 컴퓨터의 메모리 모델이란 건 사용성 관점에서는 놀라울 정도로 투명하게 추상화되어 있으면서 동시에 성능 관점에서는 무시무시할 정도로 새는 부분이 많은 추상화인 것 같다.

인상깊었던 부분 중 하나는, 코드를 실행해 보기 전에는 완벽한 최적화가 사실상 불가능한 메모리 접근 패턴이 드물지 않게 발생할 수 있다는 건데, 이런 부분 때문에 JIT 컴파일러가 AOT 컴파일보다 잠재적으로 더 우수한 성능을 낼 수 있다는 주장이 있었던 걸까 싶다.

@bglbgl gwyng 단순히 링크 용도로만 남겨두는 게 아니라 실행 흐름을 점프시키는 용도로도 활용하면 더 좋겠군요!

키워드는 jmp 아니면 goto로 하면 좋을 것 같습니다.

Git cherry-pick, git rebase 쓰면 뭔가 문제가 있다는 이상한 소리가 도는데,

음 git rebase 안 하고 지저분한채로 git send-email 하면 당신의 패치가 리젝 되기까지 5... 4... 3... 2...

지금 리눅스 진영에서 컨테이너/네임스페이스의 입지가 어떻게 될까요? 사실 요즘 서비스 배포할때는 죄다 컨테이너 쓰잖아요? 근데 또 컨테이너로 할수 있는 것중 상당수는 그냥 기존 권한 관리로도 가능하단 말이죠? 근데 컨테이너를 쓸땐 기존 권한 관리를 그냥 없는셈 치고 접근하게 되는데 이게 정말로 다들 동의하는 방식인지가 궁금합니다.

커뮤니티에서 정치적인 주제를 금지하면 결국 관리자가 보기에만 정치적이지 않은, 자기 입맛에 맞는 정치적인 글만 남더라구요

의외로 잘 안 알려진 도구인데, mise가 정말 좋습니다. 다들 mise 쓰고 행복한 개발 하세요.

https://proofby.ac/mise-for-all/

젊은 친구가 눈치가 빨라서 좋군 😏

C++ module에 대한 좋은 글을 발견했다. https://lucisqr.substack.com/p/why-nobody-is-using-c-modules

C++ module의 처참한 지원을 놀리기라도 하듯 https://arewemodulesyet.org/ 같은 홈페이지도 있지만, 왜 module이 더디게 발전하는지 알 수 있는 글이었다.

삽을 퍼 보니 CJK 문제가 없는 터미널이 왜 어려운 문제인지 바로 이해가 됨. 쉽지 않겠는데.

visionOS에서 한국어 입출력에 문제가 없는 터미널 에뮬레이터가 없어서 진지하게 하나 만들어야 하나 고민 중……

그래도 텍스트 에디터를 만드는 것보다는 난이도가 낮지 않을까?

이런 게 예정대로 2007년이나 2010년에라도 나왔으면 감지덕지하면서 썼겠지. 그런데 지금은 2025년이다.

C++ Concepts는 마치 mypy나 Pyright 같은 정적 타입 검사기가 없던 시절의 Python 3.x와 같다. 타입 검사를 boolean predicate로 하고 자빠졌다는 점에서. 이런 걸 어쨌든 컴파일 타임에 타입 검사가 되기는 한다는 이유로 정적 타입 언어라고 불러줄 수 있는 건가?

모던 C++도 C++이다.

I made a quiz about the JS Date parser. It's very easy and you will score very high.

https://jsdate.wtf

정말 파파괴의 언어...

I scored 11/28 on https://jsdate.wtf and all I got was this lousy text to share on social media.

https://tc39.es/proposal-temporal/docs/

제발 TC39 Temporal 주세요

제발

I scored 11/28 on https://jsdate.wtf and all I got was this lousy text to share on social media.

@hongminhee洪 民憙 (Hong Minhee) @kodingwarriorJaeyeol Lee 저걸 읽어 보니 진짜 문제는 Claude Code가 아니라 git worktree와 Dev Containers를 섞어서 쓰려던 저에게 있었다는 걸 깨달았습니다 😂

CLAUDE_CONFIG_DIR 환경 변수는 참고할 필요가 있겠네요. 저게 credentials 정보를 담는 폴더인지, 아니면 그냥 settings.json이 들어가는 자리인지 봐야겠습니다.

그래도 Emacs도 버전이 30쯤 되니까 설정하는 방법도 많이 현대화되긴 했네. 대부분의 설정을 use-package로 구분해서 나누고 최대한 선언적인 구성으로 만들 수 있었음.

https://github.com/Kroisse/.conf/blob/master/emacs/init.el

이제 La Terminal과 Emacs vterm과 Claude Code와 한국어 IME가 결부된 버그를 신나게 밟아제끼는 중

Anthropic에는 Dev Containers 쓰는 개발자만 없는 게 아니라 Emacs 쓰는 CJK 개발자도 없는 게 틀림없다

내가 2025년에 비전 프로에서 코딩 좀 해 보겠다고 잘 쓰던 VSCode 놔두고 Emacs로 돌아와야 하나 진짜

한때 이 문제에 대한 해법으로, 텍스트로 된 소스 코드가 아닌 문법 트리를 직접 편집하는 식의 IDE를 구상한 적이 있었다. 그런데 이제 대 LLM 시대가 와서 AI도 텍스트를 주로 다루잖아. 우린 안 될 거야 아마.

여기에 Visual Studio Code까지 참전하면 remote tunnel에 접속은 되고 그게 윈도면 WSL까지도 접속되는데 희안하게 원격지에 있는 dev container에는 못 붙는 기묘함을 보임.