염산하

차별금지법은 ‘종교의 자유’ 침해하지 않습니다 www.ildaro.com/10215 "비엘펠트 교수는 “종교의 자유, 신념의 자유가 인권이라면서 특정 집단의 인권을 유린하기 위해 (그러한 개념을) 사용해선 안 된다”고 재차 강조했다. 그런 일이 생기면 “인권이 파편화될 수밖에 없고, 결국 이는 인권을 보호하는 일 자체에 크나큰 위협이 될 수밖에 없다”고 경고했다."

≪일다≫ 차별금지법은 ‘종교의 자유’ 침해하지 않습니다

마틴파울러 블로그에서도 Agentic Coding에 대한 글이 꾸준히 연재되고 있는듯. 정제도 되어있고 한번에 모여있어서 좋다. https://martinfowler.com/articles/exploring-gen-ai.html

@always.lynnpapa_pavy 퍼플렉시티 정도는 포함시켜보면 더 좋을 것 같은데 말이에요. 저는 거의 퍼플렉시티만 쓴지 오래 되어서요.

카네기멜런 조교수가 권장하는 "모든 개발자들이 해보면 좋은 프로젝트"

https://austinhenley.com/blog/challengingprojects.html?&aid=rec3mWbHrTxWMN36P&_bhlid=818f4f9928e77979b19e926866a9fe3e537f5ee2

텍스트 에디터

• 구현에 사용되는 자료구조 (gap buffer, piece table 등)
• undo, redo 를 사용하는 메멘토 패턴

2d game

• 상태머신 관리
• 컴퓨터 주변기기를 제어하는 방법

컴파일러

• lexical parsing
• syntatic parsing
• code generation

작은 운영체제

• 스케쥴링
• 부트로딩
• 메모리관리 및 페이징
• 파일시스템

스프레드시트

• directed graph (주로 topological sort)
• reactive programming paradigm

비디오게임 콘솔 에뮬레이터

• 컴파일러, 운영체제, 게임엔진 등등의 챌린지를 한번에 짬뽕

그 외에도 데이터베이스 직접 만들기, 그림판 직접 만들기, 터미널 유틸리티 직접 만들기

https://www.sisain.co.kr/news/articleView.html?idxno=55977

시사인 대선직후 설문 조사를 통한 분석. 이준석과 김문수 지지의 차이, 2030에 대한 분석.

김창환 미국 캔자스 대학 교수(사회학)는 이번 <시사IN>·한국리서치 설문문항으로 '극우'를 새로 정의했다. ①자유민주주의 위기 해결·상대 진영 법안 저지·페미니즘 저지·불평등 완화를 위해 폭력이나 무력을 사용할 수 있다는 데 하나라도 동의했거나, '강력한 정치 지도자는 업무를 완수하기 위해 때때로 규칙을 어겨야 할 때도 있다'는 데 동의하고, ②정부보다는 개인이 자신의 생계(복지)에 더 많은 책임을 져야 한다고 응답하며, ③ 이민자 유입이나 난민 수용 확대 중 하나라도 반대하고, ④ 대북 제재를 중심으로 한 압박 정책을 우선하며, ⑤중국의 보복으로 한국이 경제적 타격을 입더라도 한미 동맹을 강화해야 한다고 응답한 사람이다. 이 다섯 가지 항목에 모두 해당하면 '극우'라고 정의해 비율을 추출한 결과, 전체 평균으로 보면 6.3%가 극우인 데 비해, 20대 남성의 15.7%, 30대 남성의 16%가 극우로 추정되었다.

청년층 가운데 극우로 추정되는 집단의 월평균가구소득, 교육 수준, 주관적 계층 인식을 살펴보고 흥미로운 결과를 발견했다. '극우'청년층이 '비극우' 청년층에 비해 사회경제적 계층(인식)이 상대적으로 더 높게 나타난 것이다. 청년층에서 월평균 가구소득이 500만원 이상이면서 스스로를 중간층 이상으로 인식하는 비율이 비극우 추정 집단에서는 25.1%였으나 극우추정 집단 내에서는 57%였다. 이 같은 결과를 두고 김창환 교수는 "현재 한국의 청년층 극우화는 불평등이 심해져서 그에 대한 불만으로 하위 계층이 극우화된게 아니라, 청년층 내에서 상대적으로 기득권층에 해당하는 남성들이 자신의 기득권을 빼앗긴 것에 저항하는 극우화일 가능성이 있다"라고 주장했다(14~16쪽 인터뷰 기사 참조).

엇 오늘부터 지하철 운임 올랐네. 1400원이었는데 갑자기 1550원 찍혀서 깜짝

원글은 https://moreal.hashnode.dev/vitepress-localsearch-debugging 에 있습니다. 내용은 같지만 이미지 호스팅용으로 Hashnode를 사용한 꼴이 되었으므로 예의상(?) 남깁니다 🙏

어제는 Zenn이라는 일본 기술 블로그 서비스의 트렌드 글을 알려주는 봇을 계획하고 구현하려고 보고 있었습니다. ActivityPub 프로토콜을 대상으로 하는 봇이었기 때문에 BotKit을 살펴보았고 BotKit에서 제공하는 메소드가 무엇을 하는지 알기 위해 Fedify문서까지 찾아보게 되었습니다. 그러다 Fedify 문서에서 검색하는 데 검색 기능이 깨진 것이 보여서 이슈로 남겼고, VitePress에도 이슈로 남겨달라는 부탁(?)을 받아 이슈의 내용을 적기 위해 조사를 하다가 PR을 올리기 까지, 야크 쉐이빙을 했다는 것이 이 글의 내용입니다 🤣

버그 재현하기 (원인 변수 확인하기)

VitePress 저장소에 이슈를 적을 때 본문에 어떻게 재현하는지와 재현되는 상황 특정, 왜 발생하는지 적어야 하므로 여러가지 시도를 하면서 해당 문제가 발생하는 시도를 해봤습니다.

처음에는 Fedify 이슈에 올렸던 것처럼 코드 블록이 있는 지점부터 검색 결과에 나오지 않았으므로 코드 블록이 포함되어 있으면 검색 결과에 포함되지 않는 것 같다는 추정을 하였습니다.

Fedify 문서는 사용하는 플러그인이 많아 피드백을 얻는데 시간이 걸렸습니다. 임시 디렉터리(/tmp)에 프로젝트를 초기화 하고 Fedify에서 사용하는 [email protected] 패키지를 설치하였습니다. 그리고 yarn vitepress init 명령어를 실행하여 기본 템플릿으로 문서들을 생성하고 .vitepress/config.mts 에서 search.provider 값을 "local"로 설정하였습니다. 그리고 Fedify 문서에 있는 헤딩을 가져와 추가했지만 검색이 잘 되었습니다.

추가적으로 환경을 가져와 보기로 했습니다. 마크다운 관련 설정을 가져가면서 @shikijs/vitepress-twoslash 부터 적용해봤는데 버그가 발생하지 않았습니다. 이어 마크다운 문법 관련 플러그인들도 추가했습니다. 그랬더니 버그가 재현되었습니다. 그 다음에는 마크다운 플러그인을 하나하나 빼면서 어떤 플러그인이 영향을 주는지 확인했고 markdown-it-jsr-ref 플러그인을 사용할 때 버그가 재현됨을 확인했습니다.

markdown-it-jsr-ref 플러그인은 `Type` 같이 특정 타입이나 함수를 지칭하는 마크다운을 작성했을 때 JSR에 있는 문서로 연결해주는 플러그인 입니다. HTML 출력이 어떻게 변하는 지 생각해보면 <code> 태그로만 감싸져 있던 부분을 <a> 로 추가로 감싸게 되는 것인데 이에 맞춰 ## With <a>a tag</a> heading 와 ## With <code>code tag</code> heading 간단한 두 테스트 케이스를 만들었고 전자만 “With “ 까지만 검색 결과에 나오는 것을 확인했습니다.

버그가 재현되는 테스트 케이스를 정의하고 나니 VitePress의 버그임이 명확하다고 느껴졌습니다. CommonMark 스펙에 헤딩에 <a> 태그가 들어가면 안 된다 같은 부분은 찾지 못 했기 때문입니다.

버그 수정하기

VitePress의 코드 베이스를 이해하고 있는 상황이 아니므로 어떤 코드가 영향을 주는지부터 찾아야 했습니다. search.provider 설정의 값으로 ”local” 을 사용하고 있으므로 local이라는 키워드로 검색해봤습니다. 그랬을 때 localSearchPlugin.ts 이라는 파일이 눈에 들어왔습니다. 내용을 봤을 때 MiniSearch 라는 검색 라이브러리를 활용하고 있는 것을 보니 찾던 것이 맞아 보였습니다.

우선 clearHtmlTags 함수가 검색 결과로 보여줄 텍스트를 위해 HTML 태그들을 모두 지워주는 것 같아 여기에 breakpoint를 걸고 디버거를 타고 가면서 상위 splitPageIntoSections 함수를 이해했습니다.

headingContentRegex 라는 정규식을 활용하는 라인에서 두 테스트케이스의 처리 결과가 달랐습니다. headingContentRegex 정규식을 이해해보면 헤딩을 입력으로 받고 두 부분을 캡쳐하려고 하는데, 첫번째는 <a> 태그 앞의 내용이고 변수 명으로는 title, 검색 결과로 보이는 부분입니다. 두 번째는 <a> 태그의 속성 중 href 의 내용을 캡쳐하는데 그 값이 # 으로 시작해야 했습니다.

const headingContentRegex = /(.*?)<a.*? href="#(.*?)".*?>.*?<\/a>/i

# 으로 시작하는 것을 가져오는 것은 앵커를 추출하려는 것이고 VitePress는 헤딩의 끝에 임의로 앵커를 넣어주고 있었습니다. Fedify 문서 중 헤딩의 HTML 값을 인용하면 아래와 같습니다.

Implement the <a href="https://jsr.io/@fedify/[email protected]/doc/federation/~/KvStore"><code>KvStore</code></a> interface <a class="header-anchor" href="#implement-the-kvstore-interface" aria-label="Permalink to &quot;Implement the `KvStore` interface&quot;">​</a>

위 정규식에 테스트 케이스를 대입하면 아래와 같이 결과를 반환합니다. 반환된 배열의 두 번째 값을 보면 With 까지만 반환 되었고 세 번째 값을 보면 앵커는 제대로 가져온 것을 확인할 수 있었습니다.

>>> /(.*?)<a.*? href="#(.*?)".*?>.*?<\/a>/i.exec('With <a href="https://example.com">a tag</a> heading <a href="#anchor"></a>')
Array(3) [ 'With <a href="https://example.com/">a tag</a> heading <a href="#anchor"></a>', "With ", "anchor" ]

상황을 정리하면 헤딩의 끝에 붙는 <a> 태그의 href 값과 그 <a> 태그의 앞부분을 가져오는 것이 본래 의도이나 제대로 동작하지 않는 것으로 이해할 수 있었습니다.

문제는 첫 번째 캡쳐 그룹인 (.*?) 중 ? 기호가 문제였습니다. MDN의 정규표현식 문서에 따르면 ? 기호는 *, +, ? 와 같은 기호 뒤에 사용되었을 때 해당 기호를 non-greedy 하게 만든다고 합니다.

If used immediately after any of the quantifiers *, +, ?, or {}, makes the quantifier non-greedy (matching the minimum number of times), as opposed to the default, which is greedy (matching the maximum number of times).

정규 표현식을 완전히 이해하고 있지 않았던지라 확실한 판단은 아니지만, 위 인용문과 함께 이해했을 때 non-greedy 하기 때문에 첫 번째 캡쳐 그룹이 가져갈 수 있는 최대치인 ”With <a href=”https://example.com”>a tag</a> heading “ 을 가져가지 않고 최소치인 ”With “ 만을 가져가서 이 문제가 발생했다고 이해했습니다. 나머지 부분은 뒷부분은 <a.*? 부분이 가져가게 됩니다. 소괄호로 감싸 캡쳐 그룹으로 만들어주어 테스트 해보면 아래처럼 나오니 맞는 것 같습니다.

>>> /(.*?)<a(.*?) href="#(.*?)".*?>.*?<\/a>/i.exec('With <a href="https://example.com">a tag</a> heading <a href="#anchor"></a>')
Array(4) [ 'With <a href="https://example.com">a tag</a> heading <a href="#anchor"></a>', "With ", ' href="https://example.com">a tag</a> heading <a', "anchor" ]

그래서 첫번째 캡쳐 그룹을 다시 greedy하게 만들어 줄 필요가 있었고 단순히 ? 기호를 하나를 지웠고 테스트 해보니 잘 동작하는 것으로 보였습니다. 와, 버그 수정 완료!

>>> /(.*)<a.*? href="#(.*?)".*?>.*?<\/a>/i.exec('With <a href="https://example.com">a tag</a> heading <a href="#anchor"></a>')
Array(3) [ 'With <a href="https://example.com">a tag</a> heading <a href="#anchor"></a>', 'With <a href="https://example.com">a tag</a> heading ', "anchor" ]

PR 만들기

PR을 올릴 시간입니다. PR을 열 때 메인테이너에게 무슨 버그인지 충분히 설명할 필요가 있습니다. 이를 위해 별도의 두 저장소를 만들어 GitHub Pages에 배포하는 방식으로 문서를 두 개 만들었습니다. 하나는 기존 1.6.3 버전에서 버그를 확인할 수 있도록 하였고, 나머지 하나는 ? 기호를 없애는 변경을 더해 이 PR의 변경사항으로 버그를 고칠 수 있음을 확인할 수 있도록 하였습니다.

스크린샷을 첨부하였으나 전체를 찍기 애매해서 전문은 이슈에서 확인 부탁드립니다 🙏

한 1시간 정도 준비해서 올렸는데 머지는 순식간에 되어서 빠른 확인에 감사하면서도 그냥 뭔가 머쓱했습니다 😅

회고

잘 된 점

• 야크 쉐이빙이긴 하지만 즐거웠습니다.
• 근래에 나온 Zed Debugger를 사용하여 디버깅 했는데 좋은 경험이었습니다.

잘 안 된 점 (아쉬운 점)

• 이와 관련된 버그를 해결 중인 이슈나 PR이 이미 존재하는 지 알기 어려웠습니다.
• PR 설명을 준비하는데 꽤나 많은 시간을 소모했습니다.
  • 재현 환경을 구성하는데 꽤나 많은 시간을 소모했습니다.
• 이 회고글을 작성하는데도 2시간 정도가 걸렸습니다.
• 정규표현식을 온전히 이해하지 못 하여 <a> 태그에서 정확히 파악하지 정확한 판단하지 못 했습니다.

개선할 점

• 글로 적어보니 꽤나 절차적인데 Agent로 이 과정을 자동화 할 수 있을까?
• 재현 환경의 구성과 배포, 수정된 환경의 배포를 쉽게 할 수 있을까?
• 이미 누가 작업하고 있는 작업인지 여부를 쉽게 확인할 수 있을까?
• 정규표현식을 온전히 이해하면 좋을 것 같습니다.

윤석열 전 대통령 대선 출마 당시부터 3년 넘게 이어진 김건희 여사의 석·박사 학위 논란이 일단락됐습니다. 문제 제기에 나섰던 학교 구성원들은 ‘뒤늦은 결정’에 대한 사과가 필요하다는 입장을 전했습니다.

김건희 석사 논문 취소-박사 입학 취소…3년여 만에 학...

#독서 천개의 파랑. 너무 오랜만에 소설을 읽은 느낌이다. 너무 좋았다.

@ysh 아주 예전 글이라 “컴퓨터의 등장으로 앞으로는 사람이...” 라는 이야기가 종종 나온다. 근데 그게 의외로 요즘의 AI와 묘하게 연결되어서 요즘은 맥락으로 생각하게 되는 측면이 재미있게 느껴졌다.

#독서 생각의 도약 https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=356276093

#독서 생각의 도약 https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=356276093

그리고, 얘가 일처리하는거보면 내가 일 잘하는 사람으로서 인식되려면 일은 하고 있다라는걸 어떻게 전시할지 많이 배우게 됨....

내가 그닥 좋아하는 사람은 아니지만 Ruby On Rails의 메인테이너이자 37signal의 대표는 DHH는 이런 얘기 를 했었다.

요약하자면,

1. LLM한테 일을 지시하는 방식으로는 배워갈 수 있는게 없다
2. 다만, LLM이 문서를 요약해서 알려주거나 자료를 찾아보는 식으로 역할을 위임하고, 내가 직접 프로그래밍 하는 방법이라면 배워갈 수 있는 여지가 있다.

인용한 글에서도 비슷한 내용이 언급이 되어 있는데, 결국에는 사람이 수제로 작업하는것이 개인의 성장에 도움이 되고 대 LLM의 시대에 리터러시를 키울 수 있게 된다는 것

LLM의 편의성은 자명하지만, 적당히 비용효율적으로 트레이드오프 맞춰서 업무를 하더라도 내가 키우고 싶은 코어스킬을 키우는데 있어서는 정신을 곤두세울 필요가 있지 않나 싶은 생각이 들었다.

tmux와는 다르다! tmux와는...!!

@hollo 아 로그인만 다시 하면 되는 정도라면야 ^^ 시크릿이라서 뭔가 데이터를 못쓰게 되는게 있을까봐 걱정했어요

elevenlabs reader 앱에서 기본 남자 목소리 쓰고 있는데 요즘 쇼츠 영상에서도 같은 목소리가 자주 들리네

@hollo railway 에서 redeploy 했다가 안떠서 0.5.6 으로 이미지 태그 고정해서 살렸어요 ㅠㅠ 시크릿키가 너무 짧다는 오류가 나서인것 같기도 한데 어쩌죠?

이 회사는 뭐하나 똑바로 하는게 없다는 느낌을 주는데 어떻게 이렇게 커졌지

검색해보니 그렇네. 당연한 일이긴 하다.

식품 제조 기계에는 전용 윤활유를 사용하도록 되어 있는건가?

‘SPC 사망 사고’ 압수수색 들어간 경찰·고용노동부 https://newneek.co/@newneek/article/33289?utm_source=article&utm_medium=share&utm_content=33289

주변에 학령기의 아이를 가지신 분들께는 "게임이 아니라 플랫폼입니다. 로블록스라고 하는 거대한 오락실이 있고, 아이들이 그 안에서 자기가 원하는 게임을 하죠. 로벅스는 그 오락실에서 사용하는 동전입니다. 어떤 게임기는 동전 한개면 충분하지만 어떤 게임기는 5분 단위로 동전을 필요로 합니다. 실행 앱이 로블록스라는 것 말고는 모두 다르기 때문에 정확하게 아이들이 로블록스에서 어떤 게임을 하는지 아시는게 좋습니다." 라고 설명드리는 편.

RE: https://bsky.app/profile/did:plc:a6qvfkbrohedqy3dt6k5mdv6/post/3lrro6f4coc2n

韓國語(한국어)에 「念頭(염두)하다」라는 動詞(동사)는 없다. 「마음 속」이라는 뜻의 【念頭(염두)】라는 名詞(명사)는 있다. 따라서 「念頭(염두)해 두다」라는 表現(표현)은 잘못된 것이다. 풀어보면 「마음 속 해 두다」가 되는데 말이 안 된다. 「念頭(염두)에 두다」가 맞는 表現(표현)이다. 풀어보면 「마음 속에 두다」가 되므로 말이 된다.

@hongminhee @nesroch 생각해보니 저는 주석 달때 이거 쓰지 마시오 그런 식으로 달아두는데요 ㅋㅋㅋ

오 티머니애플페이 https://www.instagram.com/p/DK8NdbmvhWf/

삼립 SPC에 여성 노무사가 두 달 동안 잠입, 일하면서 사고를 기록;;; 회사는 그런 일 없었다고 잡아떼는 중.

#독서 What Is Juneteenth? 도서관 영어책 레벨4

https://www.aladin.co.kr/m/mproduct.aspx?ItemId=275516852

@kodingwarrior 와우... 가격이 넘 쎄요 ㅠㅠ

조직이 작아 Vault 처럼 외부 주입되는 Secret 관리 체계가 미비하다면 Sealed Secret을 고려해 볼만하다.

최근 xAI의 API Key 유출 사례에서 보듯, GitOps 배포 파이프라인을 구성할 때 암호나 인증키는 골치거리이다.
Secret 정보들을 git repo나 helm chart에 포함시키자니 보안 리스크가 걱정되고, 배포 시에만 Secret을 외부 주입하자니 자동화 흐름을 깨트리고.. 때문에 GitOps 흐름을 유지하면서 Secret정보를 안전하게 관리하려면 Vault 나 AWS Secret Manager 류의 외부 Secret 주입 서비스를 이용하기 마련이다.(오픈소스로는 Infisical이라는 훌륭한 대체제가 있다.)

하지만 여건상 Vault 류를 쓸 수 없는 애매한 환경도 존재한다. 서비스 규모가 애매하거나, Vault를 도입하지 않은 Private Cloud를 사용하거나.. 이럴 때 도입을 고려해 볼 만한 것이 bitnami 에서 만든 Sealed Secrets 이다.

Sealed Secrets 는 서비스 외부의 Secret 관리 체계를 별도로 갖고 있지 않으며,

• Cluster Side Secret Controller(=Operator)
• Client Side Utility(=kubeseal)

두 도구로 Secret 정보를 관리한다.

큰 흐름은 다음과 같다. 1) Secret 암호화 2) 암호화된 Secret 형상관리하면서 배포 3) cluster 에서 복호화

이렇듯 대칭키로 암호화된 Secret은 여러 설정이나 helm chart 같은 배포 패키지에 포함되더라도 안전하기 때문에 GitOps 흐름이 끊기지 않는다.

하지만 Cluster Side 에 저장된 키를 털리거나 분실하는 경우에는 방법이 없으므로 이에 대한 대책을 또 마련하다보면 결국 Vault 류 같은게 나울 수밖에 없는데.. 그렇더라도 Sealed Secrets는 중소 규모 서비스에서 보안과 자동화의 균형점을 적당히 타협하여 쓸만한 도구라 생각한다.

https://github.com/bitnami-labs/sealed-secrets

o3 모델 가격 할인 직후 커서에도 사용 가능해졌길래 써보니 툴 50회 사용만 채우고 자꾸 멈춰서 못쓰겠네...