악하

유튜브 댓글 보면서 느끼는 건데... 한국에서 애플 들어온 이유를 아주 잘 알겠다...

로그인한김에 적고 가야지
플라티나랩 프로그래머입니다
뺑이칩니다 열심히 했습니다
플레이해주셔서 감사합니다

밤비 귀엽죠 저도 알아요

잘 사용하고 있음
- 위키: outline
- 코드: forgejo

테스트용 설치
- 위키: docmost

사정상 제거함
- nextcloud

설치하고 싶음
- jellyfin

홈서버에 뭘 설치해야 잘 설치했다는 소리를 들을까... 16기가니까 뭐 안올리면 아깝긴 한데... 그냥 미디어 서버로 쓸까?

@maka@stella.place생성형김마카신경망 당연히 클라담당이랑 쇠뇌 구조 담당은 다를거예요...

@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 어르신 몸 조심하세요..

GiteaのフォークプロジェクトであるForgejoも良いですね。CodebergがForgejoで運営されています。

나 쁜 사 람 으로 찍히고 있나요

자바 두명 타요 의 시즌이 다가온다... 살려줘

소프트웨어 엔지니어 가이드북 (게르겔리 오로스 지음, 한빛 미디어) 읽기 시작

40페이지까지 읽은 감상: "이 책 안 읽은 사람 없게 해주세요" 하드웨어적인 감상: "종이 재질이 반짝여서 조명 각도에 따라 읽기가 힘들어요"

한국 IT 직장인의 테크트리는 40대까지 야근 등으로 밤낮없이 일하다 치킨집이란 자조를 하곤 했는데. 그럴 수밖에 없었다. 지역 시장의 작은 기업은 그 이상의 커리어 패스를 제공할 수 없다.

내 직업(커리어)를 어떤 기준으로 관리할 것인가 기준을 제시하는 책이 아닌가 싶다.

아무도 들어보지 못한 GPS 대안 기술, BPS
------------------------------
- BPS 는 GPS를 대체할 수 있는 *방송 기반 위치 결정 시스템* 으로, *ATSC 3.0 신호를 활용* 하여 높은 정확도의 타이밍을 제공함
- GPS와 BPS는 10ns 이내의 정밀한 동기화를 이루며, 방송 인프라를 활용한 새로운 시도임
- 전력망, 통신, 방송 등 다양한 분야에서 *타이밍 정확성이 중요* 하기 때문에, G…
------------------------------
https://news.hada.io/topic?id=20314&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

사실 각자의 개인 연합우주 서버를 여는 것은 분산되는 측면에서는 매우 좋은데

이게 보안적으로 취약한 서버가 되기 마련이라... 저번처럼 스팸사태가 또 터진다거나, 서버가 암호화폐 채굴장이 된다거나 하는 사태가 벌어질 수 있어서요

웬만하면 구축 커미션이나 호스팅 서비스를 이용하시는 것을 추천드립니다

그냥 LLM이 코드베이스 전체를 이해해주면 안 될까: 번들링을 통한 RAG 시도
------------------------------

"이 글에서는 많은 파일을 내포하는 TypeScript 코드베이스를 번들링(bundling)을 통해 1개의 JavaScript 파일로 압축한 후 LLM에게 전달하였을 때, LLM이 코드베이스와 관련된 질문에 얼마나 정확하게 답변할 수 있는지 확인할 것이다."

후후후... T10을 주문했다... 처음부터 서버엔 그누구도 서있지 않았어... 내가 서버 위에 서겠다...

@maka ai 하느라 바쁘지 않나요?

아무래도 앱 개발은 혼자선 하면 안되고 트러블슈팅을 할수 있도록 팀을 갖추고 해야하는거 같다. 추잡한 문제들이 너~무 많다. 하지만 이런 허접한 교훈을 얻고 관둘순 없으니 어떻게든 혼자서 마저 나아가야한다.

개인적으로는 k8s쓰는 가장 큰 이유는 개발자 복지라고 생각한다. 적정기술만 쓰면 대부분의 사람들은 뭔가를 실 서비스에서 경험할 기회를 잃어버린다. 아니 이건 됐고…

온프레미스 클러스터 오퍼레이션 부담이나 EKS같은 서비스의 사용료 걱정만 없다면 쓰는게 무조건 낫다고 생각한다.

일단 k8s뿐만 아니라 컨테이너/머신 오케스트레이션의 세계에서 앱과 머신은 좀 더 잘 죽어도되는 존재가 된다. (물론 stateful한 호스트와 앱을 최대한 stateless하게 하거나, 상태를 분리하여 격리시켜야 하긴 한다)

그러면 docker-compose로 충분하지 않느냐 말할 사람도 있겠지만 처음에야 docker-compose 쓰는거나 k8s 쓰는거나 그게 그거지만(오히려 k8s가 성가실것이다) 마이그레이션의 때가 오면 난 그걸 감당할 자신이 없다.

물론 자신만의 가볍고 쏙 맘에드는 솔루션을 고집할 사람도 있을텐데… 난 남들이 다 쓰는거 쓰는게 편하다.

#파면_기념_연친소
#파면_기념_툿친소

음악합니다! n년차 간호사이고 프셉일 합니다!
웹소설 좋아하고 지인들과 탐라대화 또는 멘션대화가 잦습니다!
정치 이시국 얘기는 가끔 올라오는편이고 새친구를 구합니다!
부스트나 별/하트 눌러주시면 멘션과 함께 가겠습니다

당신에겐 웹소켓이 필요 없을 수도 있어요
------------------------------
- WebSocket은 실시간 통신에 유용하지만, 항상 필요한 것은 아니며 HTTP 기반 대안이 더 간단하고 안정적일 수 있음
- 트랜잭션 처리, 연결 관리, 서버 복잡성 등에서 WebSocket은 과도한 오버헤드를 유발할 수 있음
- HTTP Streaming과 라이브러리(eventkit)를 활용하면 WebSocket 없이도 실시간 동기화와 이벤트 …
------------------------------
https://news.hada.io/topic?id=20296&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

?

@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) 할아버지 울지마세요...

@kodingwarriorJaeyeol Lee 역시 고수십니다. 저도 가르쳐주세요.

이 트위터 글을 아는 분 계십니까…
이 글의 암호…
제가 초등학생때 만들었던 암호입니다

일단 django 기본 개발환경 세팅. 시작이 반이랬다.

1. poetry 대신 uv로 사용하는 툴을 변경했고,
2. Docker 기반의 배포환경 세팅하고
3. aider 기반으로 바이브코딩을 이어갈 수 있는 환경을 구축했음.

프로덕션 환경은...... 같이 작업하는 분이 준비되시면 작업하는걸로 ㅋㅅㅋ

이제 앞으로 해야하는 작업은 URL shortener를 먼저 구현하는 방향으로 갈지. (가장 빨리 끝남) 혹은 본격적으로 LLM 기반의 아티클 요약을 구현할지 결정하면 된다. (좀 늘어질 수 있음)

langchain 기반으로 짜면 될 것 같은데, 학습시간이 좀 있을 것으로 예상.

https://github.com/dahlia/yoyak 프롬프트는 여기를 참고하고 스슥하고 짜면 될 듯.

@hongminhee洪 民憙 (Hong Minhee) 고맙습니다!

후후후후후후후후 오늘은 내 생일이니 기쁜 마음으로 홈 서버 구매를 해야겠다... 맥 미니 깡통 사고 싶은데... 이번 달에는 현금이 부족하네...

HTTPS로 전송된 내용은 서버가 내용에 서명을 한 셈 아닌가?

란 질문을 Gemini 2.5한테 했는데 내가 어느 부분을 놓쳤는지를 정확하게 집어내서 설명해주었다. 나의 오개념에 일부분 '공감'을 먼저하고 설명한 부분이 좋았다. 비교를 위해 Gemin 2.0한테도 같은 질문을 해봤는데 그냥 아는 내용을 줄줄이 읊기만 한다.

Hackers' Pub도 Deno 버전을 2.2.9로 올렸다.

Hackers' Pub은 검색에서 몇 가지 기본적인 문법들을 지원하고 있습니다. 문서화되지 않았기 때문에 한 번 정리해 봅니다.

구체적인 동작 방식은 Hackers' Pub 소스 코드를 보시면 더 자세히 알 수 있습니다.

@kodingwarriorJaeyeol Lee 부럽다... 티키타카하면 코드를 짤 수 있다니... 역시 부장님급 연세라 연륜이 남다르시군요?

최근에 추천사를 썼던 책이 있는데요. 이 교재를 활용해서 LLM AI 에이전트를 개발해볼까합니다. 제가 자원봉사(?)를 하고 있는 곳에서 컨텐츠 팀을 담당하고 있는데, 거기서 하는 일 중 하나가 뉴스레터 발행입니다.

TLDR 뉴스레터처럼 링크들을 오마카세처럼 모아서 양질의 콘텐츠를 제공하는게 목표인데, 그런 데이터를 모으기 위해서 최대한 아티클들을 모아서 요약해주는 봇을 만들어야겠다는 판단이 들었습니다. 언어 LLM 관련된 리소스도 많은 파이썬을 쓰게 될 것 같고, 서버 프레임워크는 컨텐츠 관리(어드민페이지)의 수월함을 위해서 Django를 쓰게 될 것 같습니다.

https://product.kyobobook.co.kr/detail/S000216210672

RE: https://hackerspub-ask-bot.deno.dev/message/01962280-fc29-748e-9ba8-fad032795e0d

트위터(현 X)가 진짜로 타임라인을 구성하는 방식

https://gayuna.github.io/system design/twitter-design-in-real/

@kodingwarriorJaeyeol Lee (a.k.a. kodingwarrior) work in my machine

맥 스튜디오는 귀여운거 맞음
가격이 흉악해서 문제지

@kodingwarriorJaeyeol Lee 로컬 LLM으로 번역 어때요

스트레스가 쌓일 때는 홈 서버 생각을 하자... 주말에 주문해야지

브런치 제목 보고 웃었네

https://brunch.co.kr/@bcca3b25411846b/23

사실 Hackers' Pub 같은 거 운영하면서 최신 DevOps도 배우고 좀 그래야 하는데…

[공지] 현재 타 서버에서 극우단체에 의해
깡계를 이용한 사이버불링 시도가 일어남에 따라
머스타드에서도 깡계 생성 방지를 위해
가입시 가입 사유를 필수로 적도록 하고 있습니다.

가입 사유를 보고 가입여부를 판단하고 있사오니,
ㅁㄴㅇㄹ 등으로 대충 쓰지 마시고
알아볼 수 있도록 작성해주세요.

[당근] 의존성 그래프를 활용한 프로젝트 시각화 — 사이드 이펙트 한눈에 파악하기 (2025-04-10)

k8s를 제대로 공부안하고 있는 이유는 딱 봤을때 k8s의 primitive 위에서 조화롭고 아름다운 뭔가가 만들어질거같은 느낌이 들지 않기 때문이다. 하스켈 튜토리얼 챕터1만 봐도 제대로 공부해봐야겠다 생각이 드는거랑 반대의 이유.

...인데 사실 저 느낌이 완전 틀렸을수 있다. 애초에 ops를 아름답게 하는 방법을 우리가 모르는 걸수도 있고. 또는 ops 자체가 현실의 지저분한 일임을 알기에 그걸 마주하지 않으려고 핑계대는 걸수도 있고. 약간의 상상의 나래를 펼쳐보자면, Pod 2개를 합성하는 연산을 정의하는 방식으로 쌓아올려나가면 어떨까 싶다. 지금은 Pod의 합성이란건 암시적으로 이루어지는데, 한 Pod의 노출된 ip:port를 다른 Pod이 보고 있으면 그게 합성이다;;

메타적인 얘기지만, 저는 오늘 “Kubernetes는 적정 기술인가?”라는 떡밥이 Hackers' Pub 내부적으로 발생했다는 사실이 아주 기쁩니다. 여태까지는 Hackers' Pub 자체에 대한 떡밥이거나, GeekNews나 X에서 넘어온 떡밥이었거든요.

긱뉴스에도 Ask GN: 이번 주말에 뭐하세요?

같이 꾸준히 올라오는 자동 게시글이 있는데, 이걸 botkit으로 붙이면 어떨까 싶은 생각이 들었다

홈서버 사서 공부하려는데 다들 쿠베 이야기 하는 거 보니 무섭다..

내가 k8s 자체를 딱히 좋아하느건 아닌데(어차피 잘 몰라서 좋고 싫고 할것도 없음), 근데 요즘은 처음부터 k8s 쓰는게 오버엔지니어링은 아니게 되었다. k3s같은 것도 있고(NixOS로 하면 5분이면 띄운다), 어차피 머신 적을때는 별로 설정할것도 없을 것이다. 혹시 뭔가 +알파로 해줘야할게 있을때 helm install로 날먹 할수 있다는 여지도 있다. 그 다음에 서비스 운영은 이제 docker-compose up하냐, kubectl apply -f deployment.yaml 하냐의 차이가 된다.

근데 또 복잡하지 않은 인프라라면, 때가되서 k8s로 옮기는 것도 크게 어렵지 않을 것이다. 나는 '옮기는' 종류의 일을 매우 하기 싫어/두려워하기 때문에(DB 마이그레이션 처럼) 그냥 service.k3s.enabled = true 해버린다.

RE: https://hackers.pub/@ujuc/0196189f-1c95-7120-831b-27d7c51e8f38

@kodingwarriorJaeyeol Lee @hongminhee洪 民憙 (Hong Minhee) 100만원...

@saschanazKAGAMI🏳️‍🌈🏳️‍⚧️ 그게 제일 바람직하다는 것에 저도 동의해요. 다만 현실적으로는 아무래도 DB라든지 MQ라든지 이것저것 같이 띄워야 하다 보니, 서비스 운영을 하려다 보면 그런 전체 형상 관리를 위한 추상화 계층이 있기는 있어야 하는 것 같아요. 물론 도커 컴포즈를 안 쓰고 앤서블로 그런 모든 것을 관리할 수도 있고, 아예 닉스나 닉스오에스를 써서 더 아름답게 할 수도 있겠습니다만... 도커 컴포즈 정도면 타협 가능한 것으로...

개인적으로 쿠버네티스를 편하게 쓰기 위한 공부를 어느 정도 마친 상태에서 보면 "아 이거 쿠버 하나만 떠 있으면 편하게 이것저것 띄우고 할 수 있는데 괜히 귀찮게 세팅해야 하네"라는 생각이 들기도 하지만 😅 쿠버네티스 잘 모르는 상태에서는 참 막막하겠다 싶긴 합니다....

RE: https://hackers.pub/@xt/01961970-a29f-78ff-baaf-1db2056a78e1

@xtjuxtapose 저도 처음부터 지금까지 "쿠버는 구글급으로 서버도 많고 서비스도 많지 않으면 굳이 쓸 필요 없고 도커 스웜 수준의 복잡도면 충분하다"라는 입장입니다

저, 저도 90% 이상의 경우 도커 컴포즈 정도가 적당한 추상화 수준이라고 생각해요...

실제로 쿠버네티스 쓰는 팀에서 일해 본 경험도 그렇고, 주변 이야기 들어 봐도 그렇고, 도입하면 도입한 것으로 인해 증가하는 엔지니어링 코스트가 분명히 있다는 점은 누구도 부인하지 않는 것 같은데요. 쿠버네티스를 제대로 쓰는 것 자체도 배워야 할 것도 많고, 엔지니어가 유능해야 하고, 망치도 들여야 하고... 웬만하면 전담할 팀이 필요하지 않나 싶어요. (전담할 '사람' 한 명으로 때우기에는, 그 사람 휴가 가면 일이 마비되니까.)

엔지니어만 100명이 넘는 곳이라면 확실히 도입의 이득이 더 크겠지만, 반대로 혼자 하는 프로젝트라면 도무지 수지타산이 안 나올 것이라고 생각합니다. 따라서 쟁점은 그 손익분기점이 어디냐일 텐데... "대부분의" 서비스는 대성공하기 전까지는 도입 안 해도 되지 않나, 조심스럽게 말씀드려 봅니다. 즉 쿠버네티스가 푸는 문제는 마세라티 문제인 것이죠...

특히 클라우드 남의 컴퓨터 를 쓰지 않고 베어메탈 쓰는 경우는 더더욱...

RE: https://hackers.pub/@hongminhee/019618b4-4aa4-7a20-8e02-cd9fed50caae