Profile img

notJoon

@joonnot@hackers.pub · 69 following · 84 followers

Uncertified Quasi-pseudo dev

ImageGitHub
@notJoon
ImageTwitter
@JoonNot
0
0
0
1
0
0
Image
洪 民憙 (Hong Minhee) :nonbinary: @hongminhee@hollo.social
Public
Shared by ImagenotJoon

日本(일본)의 TypeScript 컨퍼런스인 TSKaigi 2026이 5月(월) 22日(일)(金(금))–23日(일)(土(토))에 東京(도쿄)에서 開催(개최)된다고 합니다. 함께 가실 韓國(한국) 분 계실까요?

一旦(일단) 저랑 Image@2chanhaeng초무 님하고 Image@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) :vim: 님이 같이 가실 것 같습니다.

Image

TSKaigi 2026

TSKaigiは日本最大級のTypeScriptをテーマとした技術カンファレンスです。2026/5/22 (金) - 23 (土) の日程で開催します。

2026.tskaigi.org

3
0
0
2
2
0
4
0
0
3
0
0
1
0
0
0
0
0
1
1
0
2
0
0
2
0
0
2
1
1
0
0
0
1
1
0
2
0
0
2
0
0
2
0
0
Image
남정현 @rkttu@hackers.pub
Public
Shared by ImagenotJoon

AI 코딩 도구 업계에서 매주 새로운 "필수 도구"가 등장합니다. 안 쓰면 뒤처진다는 메시지가 넘쳐나죠.

그런데 모든 AI 서비스 업체가 "AI는 실수할 수 있으니 꼭 확인하라"고 말하면서, 동시에 "에이전트 다섯 개를 병렬로 돌려야 진짜 생산성"이라고 합니다. 이 두 메시지, 동시에 성립할 수 있을까요?

이번 아티클에서 hype의 구조, 백그라운드 에이전트의 HITL 제거 위험, 그리고 Visual Studio 2026 디버거 에이전트가 보여주는 전통적 IDE의 가치를 다뤘습니다.

https://devwrite.ai/ko/posts/ai-coding-tools-fomo/

Image

AI 코딩 도구, '뒤처진다'는 불안에 휘둘리지 않는 법

요즘 AI 코딩 도구 업계의 소식을 접하다 보면, 새로운 도구가 등장할 때마다 “이것이 미래다”, “안 쓰면 뒤처진다"는 메시지가 과도하다 싶을 정도로 강조되는 것을 볼 수 있습니다. 백그라운드 에이전트, 병렬 AI 세션, 자율 코딩—매주 새로운 개념이 등장하고, 그것을 도입하지 않으면 마치 시대에 뒤처지는 것처럼 느껴지게 만듭니다. 하지만 이런 메시지를 곧이곧대로 받아들이는 것이 정말 건전한 접근일까요? 저는 그렇지 않다고 생각합니다. Hype는 어떻게 만들어지는가 AI 코딩 도구 업계의 hype에는 구조적인 이유가 있습니다. AI 기술로 수익을 창출해야 하는 기업들의 경영자는 투자자와 주주를 만족시켜야 하는 위치에 있습니다. 그래서 그들의 메시지에는 이중 청중 문제가 존재합니다. 개발자에게는 “생산성 향상"을 약속하면서, 동시에 투자자에게는 “시장 지배력"과 “필수불가결한 도구"라는 서사를 제공해야 합니다.

devwrite.ai · /dev/write

6
0
0
1
0
0
Image
notJoon @joonnot@hackers.pub
Public

종료 시그널이 들어왔을 때 잘 처리되는지, 상위 context가 계속 잘 전파되는지를 확인하는게 관건이긴 하군

1
0
0
1
0
1
Image
notJoon @joonnot@hackers.pub
Public

별거 아닌거 같지만 은근하게 신경 쓸 부분이 많은 것 같음

3
0
0
Image
Hyaline @hyaline@hackers.pub
Public
Shared by ImagenotJoon

예전에는 CPU 버그가 드물었지만, 최근에는 복잡성의 증가로 많이 흔해졌다는 이야기로 시작하는 CPU 버그에 대한 좋은 마스토돈 포스팅. 버그가 어떤 식으로 발생하고 여기에 어떤 식으로 준비/대처하는지에 대해 자세히 이야기를 해준다. 습관적으로 마스토돈에 들어갔다가 상당히 흥미롭고 깊이있는 이야기를 발견해서 기뻤다. 주소는 여기

예전에 lwn.net 에서 본 What every programmer should know about memory가 생각났다. Static RAM 과 Dynamic RAM 의 속도차이는 왜 어떻게 발생하는 것일까에 대해 아주 오랫동안 궁금해하던 것을, 회로도를 통해서 직관적으로 이해할 수 있게 해줘서 굉장히 (...인생에서 가장 기뻤던 순간 중 손에 꼽을 정도였다.) 기뻤던 기억이 아직도 난다.

로우레벨 컴퓨팅에 대한 이야기는 내 정신 저 밑바닥에 있는 "아니 그러니까 왜냐고?!" 의 욕망을 크게 해결해주는 경향이 있어서 좋아한다.

그리고 마스토돈의 기본 웹 클라이언트는 브라우저들이 번역을 정말 잘 못한다-_-; 웹페이지의 기본 언어가 브라우저 언어로 맞추어져 보여지고, 그래서 번역할 필요가 없다고 브라우저가 판단해서 그런 것 같다고 이해하고 있는데 이 문제 어떻게 해결할 방법이 없을까 흠 ' -' ...

3
1
0
4
0
1
0
0
0
7
1
1
1
0
0
Image
Linear @linear@hackers.pub
Public
Shared by ImagenotJoon

코로나 시기의 단절이 사람들에게서 ‘뉴비를 잘 가르치는 법’을 앗아갔듯이 AI의 유행이 사람들에게서 ‘사람에게 잘 설명하는 법’을 앗아갈 거라는 생각이 가끔 든다.

4
1
0
1
0
1
Image
notJoon @joonnot@hackers.pub
Public

LLM에게 한 번도 반말을 해본 적이 없다 (100%인지는 모르겠음). 같이 일하는 동료로서 존중하기 위한 목적도 있고, 먼 훗날 기계 문명이 도래했을 때 조금이나마 정상참작을 받을 수 있을까 하는 마음에서이기도 하다.

11
0
0

업무 일지 CLI 명세 메모 (v0.0.1)

Image

notJoon @joonnot@hackers.pub

해야 할 작업 목록과 업무 일지를 txt 파일로 관리하고 있다. 그런데 작성하다 보니 날짜를 잘못 입력하거나, 태그를 빠뜨리는 실수가 종종 생겨서 아예 CLI 도구로 만들기로 했다.

현재 사용 중인 문서 형식은 다음과 같다. 섹션은 크게 TODO, DONE, 메모(주로 #TIL, #메모로 표기)로 구성된다.

[빈 줄 (선택)]

YYYY-MM-DD
==========

[섹션들...]




YYYY-MM-DD
==========

[섹션들...]

기능 명세

1. 날짜 자동 생성

cron을 이용해 매일 자정(00:00)에 새 날짜 섹션을 자동 생성한다.

2026-01-21
==========

최신 날짜가 파일 상단에 위치하며, 이전 날짜와는 빈 줄로 구분한다.

2. TODO 추가 및 편집

todo 명령으로 오늘의 할 일을 추가하거나 편집한다.

$ tag todo
  • 오늘 날짜 섹션이 없으면 자동 생성
  • TODO 섹션이 없으면 에디터에서 새로 작성
  • TODO 섹션이 이미 있으면 해당 내용을 에디터로 불러와 편집
TODO
 - 첫 번째 할 일
 - 두 번째 할 일
  . 세부 항목 A
   - 더 깊은 항목
  . 세부 항목 B

3. 완료 기록

done 명령으로 완료한 작업을 기록한다. 명령 실행 시점의 시간이 자동으로 추가된다.

$ tag done

시간 형식은 [오전|오후 HH:MM]이며, 24시간제로 표기한다.

[오전 10:40]
 - 완료한 작업 내용

[오후 14:30]
 - 또 다른 완료 항목
  . 관련 세부 사항
  . 추가 메모

4. 메모 및 커스텀 태그

note 명령으로 메모를 추가한다. 태그를 인자로 전달하면 해당 태그로 섹션이 생성된다. [명세 업데이트 필요]

$ tag note           # "노트:" 헤더로 추가
$ tag note TIL       # "#TIL" 헤더로 추가
$ tag note memo      # "#memo" 헤더로 추가

(자주 사용하는 태그는 단축 명령을 지원하는 것도 좋아보임)

note 명령 이후에 오는 태그는 종류에 상관없이 # 접두사를 붙여 커스텀 태그로 활용할 수 있어야 한다.

$ tag note foo      # `#foo`
$ tag note idea     # `#idea`

5. 불렛 포인트 규칙

들여쓰기 깊이에 따라 -와 .가 교차한다. 스페이스 1칸이 1레벨이다.

깊이 들여쓰기 불렛 예시
1 1칸 - - 항목
2 2칸 . . 항목
3 3칸 - - 항목
4 4칸 . . 항목

에디터에서 아무 불렛(-, ., *)으로 작성해도 저장 시 규칙에 맞게 변환된다.

6. 환경 설정

환경 변수로 기본 동작을 변경할 수 있다.

변수 기본값 설명
TAG_FILE ~/todo.txt TODO 파일 경로
EDITOR vim 사용할 에디터 
export TAG_FILE="$HOME/Documents/work.txt"
export EDITOR="nvim"

파일 예시 



2026-01-20
==========

TODO
 - 첫 번째 할 일
 - 두 번째 할 일
  . 세부 항목 A
   - 더 깊은 항목

[오전 10:30]
 - 오전에 완료한 작업

[오후 15:00]
 - 오후에 완료한 작업
  . 관련 메모

#memo
기억해둘 내용 작성

#TIL
 - 오늘 배운 것
  . 세부 내용




2026-01-19
==========

TODO
 - 어제의 할 일 목록

[오전 11:00]
 - 어제 완료한 작업

노트:
자유 형식의 메모 내용
Read more →
2
0
0
0
0
0
5
0
1
0
0
0
2
0
0
3
0
1
Image
FOSS for All @fossforall@mastodon.social
Public
Shared by ImagenotJoon

모두 새해 복 많이 받으시기 바랍니다!

FOSS for All () 에서는 오는 1월 31일에 모두의연구소 강남캠퍼스에서 첫 개최를 준비하고 있습니다. 국내 Fiscal sponsorship 사례 연구, 포용기술 전문가 간담회 후기 등을 주제로 프로그램이 구성 될 예정입니다.

참가 등록이 몇일 안으로 열릴 예정이니, 조금만 기다려 주세요!

Image
1
0
0
Image
notJoon @joonnot@hackers.pub
Public

문서를 업데이트 안 한지 1년이 넘어서 이 참에 문서 생성기를 만들었다. 불필요하게 시간 소모하는거 아닌가 싶었는데 사용해보니까 이게 더 시간 효율적인 접근이였다.

3
0
0
8
0
0
2
0
0
Image
유루메 Yurume @yurume@hackers.pub
Public
Shared by ImagenotJoon

LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(**)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.

문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 **는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다. 여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 **<보통 글자> 꼴이거나 <공백>**<기호> 또는 <기호>**<기호> 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 **마크다운**은 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 이 **"마크다운"** 형식은 같이 기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 **마크다운(Markdown)**은을 해석해 보면 뒷쪽 **의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.

CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 **이런 **식으로** 중첩되어** 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 **이런 ** 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에, 이런 식으로 어느 연속된 구분자가 왼편인지 오른편인지 추론하는 데 한계가 있다는 것이다. 단순히 <보통 문자>**<기호>도 왼편으로 해석하는 식으로 해서 **마크다운(Markdown)**은 같은 걸 허용한다 하더라도, このような**[状況](...)**は 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.

* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [강조 처리된 "비숍(Ba5)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]
14
1
0
Image
std_logic_vector @stdlogicvector@chaos.social
Public
Shared by ImagenotJoon

I finally got the data transfer from the AISC110C high-speed camera sensor working!

It's a 5€ chip that outputs 80x120 video at up to 40k fps.

Data is read with a Xilinx Spartan7 and transmitted via USB3 with a Cypress FX3, each on its own little PCB.

The front PCB is exchangeable, making this a neat modular platform. I already have an analog video frontend with the ADV7182 and am working on a Cameralink interface.

Videos are coming tomorrow, I need more light for the high framerates.

A greyscale image of a hand giving thumbs-up. It's a video capture of the highspeed sensor, albeit only recording at 30fps with 8ms exposure time in this case.A stack of three PCBs sitting on a grey 3D-printed base (the back of the camera housing) lying on top of a hand. The uppermost PCB has the image sensor on top. Between the upper and middle PCB a 80 pin connector is visible. The middle and lower PCB have some components visible on their top sides.The grey 3D-printed casing of the PCB stack is sitting in a bracket on top of a camera mount. On the front a metal CS-mount thread is screwed into the 3D-print. Inside that, a printed adapter is holding a black M12 lens.
0
0
0
Image
어둠사자 @gnh1201@catswords.social
Public
Shared by ImagenotJoon

오픈소스 활동하면서 고민하게 되는 법적 어려움들

1. 오픈소스가 완전 공개에 무료인 것은 맞으나, 무상이라도 저작권 관리, 기업 납품 등 법적 행위가 정상적으로 성립하려면 절차상 결국 사업자등록 사실이 필요한 경우가 많다.

2. 리눅스 재단과 하버드대 공동 연구에 따르면, 오픈소스 메인테이너들은 본업 외에 주당 20시간 이상을 오픈소스에 쏟으며 사실상 '투잡'을 뛰지만 월급은 한 곳에서만 받는 기형적 구조다.

3. 이런 기형적인 구조에서, 그나마 비영리 활동을 한다고 인정을 받는 방법을 고민하게 되지만 실질적으로는 그 어느 나라도 제도적으로 방법이 없다시피한 경우가 많다.

4. 기존의 영리 사업자 제도에 대부분을 의존해야 해서 협력자가 아닌, 겸업으로 인식되거나 아예 경쟁사를 창업한 것으로 인식되는 등 의도치 않은 여러가지 오해를 불러일으키기도 한다.

5. 이 1에서 4까지의 내용을 이해하고 상담해주는 법률가조차 찾아보기 어렵다.

2
0
0
2
0
0
5
0
0
Image
조내일 @tomorrowcho@hackers.pub
Quiet public
Shared by ImagenotJoon

[2일차 -20p.]

데이터 종속을 수작업으로 분석한다면, 결국 실수를 하게 될 것입니다. 구조만 개선하려고 하다가 실수로 동작까지 변경하게 될 수도 있습니다. 그래도 문제는 없습니다. 올바른 버전의 코드로 되돌리면 됩니다. 작은 단계로 작업하세요. 그 방식이 바로 코드 정리 방법입니다. 커다란 설계 변경은 어렵고 무섭죠? 더 작은 단계로 진행하세요. 그래도 무섭다면, 더 작게 하세요. 두려움을 느끼지 않는 수준의 바로 그 단계가 가장 좋은 수준입니다.

Tidy First -2일차
1
0
0
4
0
0