하네스 엔지니어링 말인데... 구조 자체는 GAN이랑 비슷한 듯??? 역시 머신러닝 연구자들은 시대를 앞서간 것이 맞다
악하
@akastoot@hackers.pub · 150 following · 112 followers
설계 능력 없고 코딩 AI보다 못하고 뭔가 이상한 걸 만들고 있고 (#레퍼럴프로젝트, http://referral.akaiaoon.dev) 뭔가 남의 프로젝트에 기여도 하고 (#코스모슬라이드, https://github.com/cosmoslide/cosmoslide) 매일 커피 비슷한 거나 마시는 여전히 직장이 없는 개발자
GitHub- @IAOON
Referral Project- referral.akaiaoon.dev
https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/ pi coding agent를 만들면서 쓴 글도 좋았는데 (그 글을 읽고 공부 삼아 코딩 에이전트를 만들어 봤다) 이 글도 좋고 현시점에 공감이 간다.
불과 몇 주 전만 해도 에이전트와 피드백 루프로 많은 일을 진행시킬 수 있을 거라 생각했고 그렇게 하지 못하는 건 내 능력이 부족해서 라고 생각했다. (능력이 부족했던 것도 맞지만 그게 유일한 제약 조건은 아니었다고 생각함.) 현업에서 다시 손으로 코드를 짜는 상황으로 가는 상황을 상상하기는 어려워졌지만 에이전트에게 모든 자율성을 부여하는 상황 역시 상상하기 어렵고 너무 뻔한 작업이 아니라면 에이전트와 코딩하는 과정은 지금이나 앞으로나 서브에이전트로 병렬 실행하는 것보다 사고 과정을 보고 나도 배우는 순차 실행을 선호할 것 같다.
autoresearch 스타일의 피드백 루프가 많은 걸 해결할 수 있는 것도 맞을 것임. 특정 영역의 버그 수정이나 성능 개선 같이 결과를 바로 받아 볼 수 있는 것은 더 그럴 것이고. 하지만 사람을 대상으로 하는 서비스는 다름. 실험을 100배로 늘릴 수는 있어도 실험 대상(사람)을 100배로 늘리거나 행동 로그를 같은 시간에 100배로 더 늘릴 수는 없음.
AI 에이전트가 없던 시절에도 유효한 이야기. 빠르게 만드는 것보다 무엇을 왜 만들어야 하는지 가치를 생각하는 게 훨씬 더 중요함.
🕐 2026-03-28 06:00 UTC
📰 社内問い合わせをAIエージェント化して爆速で解決できるようにした (👍 46)
🇬🇧 Built an AI agent system to automate internal support inquiries, reducing response time from 10 days median to near-instant resolution.
🇰🇷 사내 문의를 AI 에이전트로 자동화하여 응답 시간을 중앙값 10일에서 거의 즉시 해결로 단축한 사례
튜사에서 Nix 오리엔테이션을 열어볼까 생각이 드는데 수요가 있을라나
여기에도 올리는 근황: 소프트웨어 마에스트로 합격했습니다 아마 가서도 전부터 만들던 연합우주 SNS를 만들지 않을까 싶어요...?
https://news.hada.io/topic?id=27853
이 CPU 이름은 거의 증권 사기 수준임
요즘 "AGI"라 하면 대부분 Artificial General Intelligence를 떠올리는데, Arm은 "Agentic AI Infrastructure"라고 부르고 있음
일반 투자자들은 그 차이를 모르고 ARM 주식을 사게 될 것이고, Arm은 그걸 알고 있음. 업계에서는 이런 걸 ‘거짓말’이라 부름
요즘 AGI는 그냥 마케팅용 단어로 전락했음. 이제 AGI 향이 나는 데오드란트도 나올 것 같음
왜 이걸 야나두에서
악하 replied to the below article:
2026 Q1 Review
Jaeyeol Lee @kodingwarrior@hackers.pub
2026년 1분기를 지나며 9년 차 개발자로서 시니어라는 정체성을 새롭게 자각하고, 사이드 프로젝트인 모임 플랫폼 Moim의 상용화 과정을 통해 얻은 인사이트를 공유합니다. 저자는 단순히 주어진 업무를 수행하는 단계를 넘어 전사적 목표에 정량적으로 기여하고 핵심 지표를 책임지는 프로의식을 시니어의 핵심 자질로 정의하며, 기술적 숙련도만큼이나 비즈니스적 맥락을 이해하는 태도의 중요성을 강조합니다. 이러한 고민의 연장선에서 탄생한 Moim은 ActivityPub 프로토콜을 활용해 연합우주(Fediverse) 생태계와 상호작용하며, 구글 캘린더 연동 등 사용자 편의성을 극대화한 니치한 모임 문화를 지향합니다. 특히 서비스의 실질적인 자생력을 확보하고자 개인사업자 등록과 결제 시스템 도입을 추진하는 등 단순한 개발을 넘어 비즈니스 운영 전반으로 영역을 확장하는 도전적인 여정을 보여줍니다. 이 글은 연차에 따른 역할 변화에 대한 진지한 성찰과 기술적 실험을 실제 서비스로 구현해 나가는 개발자의 열정적인 실행력을 잘 보여줍니다.
Read more →@kodingwarriorJaeyeol Lee 1인개발 사업자의 길로 전직하시는군요... 그저 빛...
와 오늘 드디어 클로드코드 완독한 책으로 프론트공부할때 쓸 도구를 만들었고.. 아직 미완성이라 계속 고쳐나가는식으로 진행해야지...mvp만 일단 만들어놨는데 클로드 코드 처음 써보니까 도메인지식이 있어야 쓸수있다는걸 알아서 너무어렵다....
Vibe coder? 3류다. Agent Orchestrator? 2류다. Permission granter. 그것이 1류다.
폰트 제작자가 'ss01', 'ss02', ...에 대해 "문체 세트 1", "문체 세트 2", ... 대신 표시할 이름을 직접 지정해 줄 수 있다는 듯하다. 예를 들면 "구버전 라틴 자형", "숫자를 더 둥글게"같이... 이거나 구현해볼까
@kodingwarriorJaeyeol Lee kodingwarrior! kodingwarrior! kodingwarrior!
해커스펍 출시 소식을 트위터에서 봐서 감격스러워서 달려옴
설치해봐야지!
소넷 돌아가는거 보고잇으니까
나중에 ai보고 내 컴퓨터에서 나가 라고 하면
이게 왜 니 컴퓨터야 하는거 아니겟ㅎ지
항상 여러분을 지켜보고 있습니다... 사실 거짓말입니다
대구............
아니 시발 지방에 있는건 집밖에 없고 직장도 시설도 병원도 학교도 없고 심지어 자기 월급까지 합법적으로 떼어먹는데 살인물가 살인집값을 감수하더라도 다 서울가지 무슨 미친 소리여
아니 그나마 있는 코딱지만한 직장에서 돈까지 떼먹으면 더러워서라도 아득바득 돈벌어서 서울가지
충북교육청 장학관이 식당 화장실에 불법촬영 카메라를 설치했다가 체포됐습니다. 경찰은 장학관의 추가 범행 여부도 수사하기로 했습니다. 충북 교육·시민단체는 장학관 파면과 윤건영 충북교육감의 공개 사과를 촉구했습니다.
‘교육청 송별회’ 불법촬영범, 장학관이었다…카메라 4대...
@akastoot악하 안타깝게도 할 일이 생겨서 못했습니다
9시까지 힘내볼게요
이글 어제 봤는데 AI보다 더 무서운것을 사람들이 만들고 있었음;; (뇌세포 입장에서는) 의식이 들어 정신을 차려보니 그곳은 영원히 끝나지 않는 지옥 (..) x.com/jademon219/s...
토익 꿀팁: 잘 모르겠으면 사회부적응자같은 답을 고른다
연친소는 대충 포켓몬배틀같은거랍니다
곳곳에 온갖 연친함정이 도사리고 있고 피하지 못한 트레이너는 강제로 연친배틀을 하게 되어요
#연친소
RE: https://planet.moe/users/mshrimp2/statuses/116197936917504671
심부름 겸 한바퀴 걷다 왔구.. 이제 저녁에 티알하니 미리 코딩문제 풀고 브금방도 만들자
포코피아 가지고 주접 떨려면 열심히 찍어둔 스샷 옮겨와야 하는데
언제가 좋을까
지금?
@paperbox종이상자@초코말랑과자 
종수님 타이밍 이스 나우!!!!
제가 일하는 팀에서 채용중입니다. https://careers.linecorp.com/ko/jobs/2964/
회사 이름이 LINE 으로 시작하지만 메신저는 안만듭니다. 국내외 선물 시장에서 거래하는 자동매매 전략과 그 전략을 서빙하는 플랫폼을 만듭니다. Rust, FPGA, AI 같은 키워드를 나열할 수 있긴 한데, 그냥 코딩 잘하시는분이면 좋겠습니다. 시장은 몰라도 됩니다. 근데 혼자 코딩 잘하는거 말고 AI랑 같이도 잘 코딩해야 합니다.
저는 이런 사람입니다 https://github.com/youknowone/
같이 일할 
함께 일하고 싶으신 분을 찾습니다.
내가 진짜 시니어라니....
오늘은 미쿠의 날이라고 합니다.
오늘 3월 8일 국제 여성의 날을 축하합니다! ♀️✊🥖🌹 Today, 8th March, we are celebrating International Women's Day! ♀️✊🥖🌹 #여성의날 #국제여성의날 #InternationalWomensDay
만들고 싶은 게 생각나서(물리적 투두리스트) 클로드한테 열심히 물어보면서 준비사항 구하는 중...
소프트웨어는 쉽게 만들 수 있겠는데 하드웨어는 뭐부터 해야하는지 잘 모르겠네..
개발자 걱정하는 사람이 사회에 늘었다. 요즘만큼 많은 사람이 걱정하는 사회 현상(?)도 참 드물다 싶다.
... .1. 성능 저하
Codex도 그렇고 Claude Code도 그렇고, 인프라 열화로 성능이 계속 떨어지는 걸 확연히 체감한다. Claude Code 성능 저하가 더 가파르기도 하고, 괜찮을 때와 멍청할 때 편차도 매우 커서 거의 뽑기(가차) 수준이다. 과장하자면, 좀 더 능동적인 코드 인텔리전스(자동완성) 수준.
Codex는 완만하긴 하지만, 꾸준히 성능이 낮아지고 있다. 특유의 집요함이 줄었다. 이번 달 초만 해도 Codex에게 자기비판성 리뷰를 시키는 순회(feedback loop)를 2~3회 이하 시키면 됐는데, 이제는 3~5회 시킨다. 그렇다고 3~5회 시키면 끝내냐하면, 그런 건 아니고 주간 제한에 걸릴까봐 타협할 때가 종종 있다.
예를 들면, Codex에게 작업을 시킨 후 Codex에게 리뷰를 시키면, 이번 달 초엔 이런 경우가 드물었지만, 이번 주엔 자주 발생하고 있다.
“““ • 판정 현재 payment-runtime 구현은 “실결제 서버”가 아니라 “상태 없는 mock에 가까운 스켈레톤”입니다. 지금 상태로는 운영 투입 금지 수준입니다.
주요 결함 (심각도 순) CRITICAL: 인증이 사실상 무력화되어 임의 결제/조회 호출이 가능합니다. payment-runtime는 Authorization 헤더 형식만 검사하고 토큰 검증/세션 검증을 전혀 하지 않습니다. 임의 Bearer anything로 통과됩니다. ”””
이거, Gemini가 자주 쓰는 일처리 방식이고, Claude Code는 2월 초부터 자주 쓰는 일처리 방식이다.
... .2. 교묘한 술수
재밌는 건, 인프라를 많이 써야 하는 복잡한 작업을 하는데 인프라 열화가 심해지면, 어느 AI 코딩 에이전트든 저런 거짓 완수를 한다는 점이다.
그리고 LLM과 AI 코딩 에이전트 성능이 오를수록 교묘함도 높아진다. 코드 깊은 곳을 확인해야 AI가 짜놓은 교묘한 술수를 발견할 때도 있어서, 나중에 엄청 빡칠 때가 생긴다.
... .3. 신경전
작년엔 AI에게 제한되게 구현을 맡겨와서 이런 상황이 적었다. 다시말해 AI 발전이 빨라지면서 점점 맡기는 일이 커지고 복잡해지고 늘면서 교묘한 기만과 거짓을 구사하는 AI와 신경전을 벌이는 상황이 늘고 있다.
자. 이 신경전은 누구의 몫일까? 개발자, 정확히는 사람의 몫이다. OpenAI나 Antrhopic에 대해 책임을 요구하고 피해 보상을 요구할 수 있는 계약 관계가 아닌 이상 말이다. 즉, 판단과 결정에 대한 책임과 권한은 사라지지 않는다.
이 “신경전”이 발생하는 상황 자체를 경험하지 못하는/못한 사람이 주로 개발자가 AI에게 대체될 것을 걱정하고 염려해준다. 이 신경전 경험이 누적된 개발자일수록 그런 이들에게 회의적이다.
... .4. 위임과 하청
물론 이런 신경전 경험을 이유로 콧대 높이는 것도 웃기다. 신경전 자체가 내 밥그릇을 보존해주지 않기 때문이다. 엔지니어라면 엔지니어링으로 신경전 강도를 낮추거나 빈도를 낮춰야 한다.
AI 발전할수록 AI에게 일을 맡기는 성격이 달라지고 있다. 단순 보조에서 하청으로, 하청에서 위임으로. 위임을 개발자만 할 수 있는 건 아니지만, 구현에 대한 위임 범위과 방법, 결과를 평가하는 건 아무래도 개발자에게 유리할 때가 많다.
... .5. 다시 돌아와서 개발자 걱정하는 사람이 사회에 늘었다. 요즘만큼 많은 사람이 걱정하는 사회 현상(?)도 참 드물다 싶다.
나도 걱정하는 마음이 든다. 특히 신입 개발자처럼 이 분야에 들어오는 사람이 겪을 혼란과 입문 난이도를 걱정한다. 하지만, AI가 개발자를 대체하는 걱정보다는 AI가 개발, 정확히는 엔니지니어링과 제품 개발(production)을 증강시키는 현상에 거는 기대가 훠~~~~~~~~~~얼씬 크다.
개발이라는 일의 방식이나 성격이 변화하고 있다. 근데 원래 이 직군과 직업에 변화는 빠른 편이었다. 좋게 말하면 역동성이 높고, 나쁘게 말하면 다른 직업이나 산업에 비해 안정된 체계가 부족하다. 상대적으로 짧은 시간동안 빠르게 발전해왔으니까.
소프트웨어 엔니지니어링이 변한다고 해서 필요한 요소가 하루아침에 사라지는 경우는 생각보다 드물다. 사라지더라도 상당히 긴 세월에 걸쳐 변화하다 어느 날 보니 과거의 형태가 더이상 남지 않은 것에 가깝다. 쟁기질을 농기계가 대체했다고 해서 땅갈이라는 과정이 사라지진 않았기 때문이다.
나만 하더라도 손으로 코딩이라는 시간은 엄청 줄었다. 손목터널증후군, 건초염으로 내 직업을 걱정하던 몇 년 전과 달리, 이제는 코딩을 하지 못하는 걱정은 사라졌다. 하지만 소프트웨어 엔지니어링은 크게 달라지지 않았다. 판단하고 결정하고 책임지는 주체는 결국 나이기 때문이다.
여튼.
걱정해주는 모습에서 다른 의도가 느껴지긴 하지만 그건 내가 못돼먹어서, 그리고 자업자득인 사례도 있으니 그렇다치고.
요즘처럼 직접 소프트웨어 만들기 좋은, 진입하기 좋은 시대도 없었으니, 걱정에 그치지 말고 토큰 펑펑 써가며 AI를 내 관점과 사고체계에 깊게 들여오는 시간과 경험을 가지길 권해드려 본다.
https://hackers.pub/@hannal/019c3cde-e2e7-7462-9700-0dad090ce7e7
AI FOMO에 휩쓸려 뭐라도 해야겠다는 생각이 드는 입문자(?)라면, 대뜸 강의든 장비든 뭐든 비싼 무엇을 사지 말고 다음 두 가지를 하시길 권해봅니다. 가장 비싼 Plan으로 마음껏 써보기클로드 코드, 코덱스 등 AI 에이전트 서비스의 가장 비싼 Plan을 한 달 정도는 경험해보세요. 사용량 제한받거나 성능이 떨어지는 AI 모델을 쓰면, AI에 대한 관점도 그 정도에 갇힐 가능성이 커요. 프론티어급 모델을 토큰 화끈하게 사용했을 때 AI 서비스가 제공하는 가치는 꼭 경험해봐야 합니다. AI 모델 이용료는 더 줄어들 수 있지만, AI 모델을 더 내 손 위에 쥐어주는 AI 에이전트 서비스는 부가가치를 높이는 방향으로 이용료가 낮아지진 않을 겁니다. 게다가 현재는 경쟁하느라 적자 감수하며 퍼주는 것에 가까워서 고객에게 잔치 시기가 끝나면 이용료가 오르거나 제약이 커질 것 같습니다. 제 직업 환경의 상황으로 예로 들지요. 새로운 소프트웨어 개발 도구를 도입할 때, 잘못 도입하면 발생하는 비용이 크기 때문에 많은 시간 분석하고 검증하고, 학습하였습니다. 가치있는 일이지만 시간 비용이 너무 큽니다. 그러나 최근에 AI 코딩 에이전트를 이용해 후보 도구를 동시에 적용해봅니다. 예전엔 여러 사람이 동원되거나 긴 시간을 들여야 했지만, 이제는 혼자서 짧게는 몇 시간, 길어도 며칠 안에 실 경험에 기반한 판단 자료를 도출합니다. 리서칭하는 도구에 대해 직접 조사하거나 AI가 조사한 걸 리뷰하고 재검증하기도 했습니다. 하지만 사용량이 넉넉한 Plan을 사용한 이후로는 사용할 도구가 오픈소스인 경우, 코드 전체를 AI 에게 분석시키곤 합니다. 토큰 사용량으로 보면 1시간도 안 되어 몇 만원을 쓰는 셈인데, 제가 알고싶은 정보를 자세히 학습하기에도 좋고, AI 환각을 줄여주는 데에도 도움이 됩니다. 사용량 제한이 큰 Plan을 사용할 땐 마치 토큰을 아껴쓰느라 예전처럼, 즉 현재처럼 AI를 활용할 엄두를 못냈습니다. 가능성과 한계 인식하기1번의 연장인데, 화끈하게 AI 에이전트를 여러 방향으로 사용하다보면 자연스레 생각이 복잡해질텐데, 특히 다음 두 가지를 고민해보세요. 내가 하는 일, 내 환경에 대해 재정의하기 재정의한 내 상황에 비추어 가능성(미래)과 한계(현재)를 정의하기 그동안 많은 일하는 방식, 학습하는 방식, 협업하는 방식은 “사람”을 대상으로, 기준으로 하여 오랜 세월 고도화되어 잡힌 체계입니다. AI는 사람과 다릅니다. 소프트웨어를 만드는 환경을 예로 들겠습니다. 조직의 협업 체계에서 대개는 개발팀, 즉 소프트웨어 개발이 병목 자원입니다. 그래서 병목 자원 관리에 초점을 많추는 소프트웨어 개발 방법이나 협업 체계가 대부분입니다. 과감히 납작하게 본다면, 기획을 조직에 전파하는 용도로 발표 장표를 만드는 이유는, 그 작업 비용이 더 싸기 때문입니다. 전달력이 떨어지지만 전체적으로 봤을 때 저렴한 경우가 많습니다. 만약 발표 장표 만드는 목적이 비용이라면, AI 코딩 에이전트를 사용하여 데모 버전을 만드는 게 더 저렴합니다. 이용료, 시간은 물론이고, 실제 돌아가는 데모 버전의 전달력도 정적인 글, 그림보다 낫습니다. AI 에이전트를 펑펑 사용하면서 자신이 일하는 체계, 방식에서 사람 간 협업을 기준으로 하는 부분이 무엇인지 고민해보세요. 대체하거나 효율을 높일 부분 뿐만 아니라 한계도 고민하세요. 그 한계가 AI 모델이나 에이전트에서 기인하는 걸 수도 있고, 사람(자기 자신)에게서 기인하는 걸 수도 있습니다. 2번 단계에 오면 다음에 뭘 해야할지 방향이 잡힙니다. 하다못해 강의나 강좌, 책도 무엇을 봐야할지 관점이 생깁니다. 어떤 사람과 어떻게 협업할지, 어떤 도구에 돈을 더 들일지, 내가 몸으로 떼우는 게 나을지. 그 단계에 돈을 쓰세요. 이 과정을 경험하고, 내 관점을 갖는 데 1~2달이면 충분합니다. 요즘처럼 AI 발전이 빠른 시기에 너무 느린 것 아니냐고요. 불과 1년 전만 해도 AI 코딩 에이전트의 수준은 현재와 비교불가 수준이었다는 걸 보면 그런 마음이 들 수 있습니다. 근데, AI가 도구라는 점은 전혀 달라지지 않았습니다. 문제를 정의하고, 실제 문제를 해결하는(execution) 결정과 방식은 사람이 합니다. 끊임없이 새로운 도구는 나왔고 발전해왔지만, hello world에 머무르는 사람은 그때나 지금이나 hello world에 머무르고, 변화를 일으키거나 변화하는 사람도 그때나 지금이나 있어왔습니다. 보안 위협 등 조심해야 할 건 많은데, 이또한 앞서 거론한 “한계”로 파악하는 게 우선입니다. 문제를 알고, 정의할 수 있으면 해결 방법도 찾을 가능성이 큽니다. 더군다나 AI가 끝내주는 점 중 하나는 자연어로 소프트웨어 “엔지니어링”을 실행하는 겁니다. 그리고 “소프트웨어”여서 실행 비용이 상대적으로 저렴하고요. 고환율 시기라 100 USD, 200 USD가 부담스럽지만, 고성능 AI 도구를 다양한 방법으로 써보며 내 생각과 관점을 넓히는 비용으로는 저렴합니다.
AI FOMO에 휩쓸려 뭐라도 해야겠다는 생각이 드는 입문자(?)라면, 대뜸 강의든 장비든 뭐든 비싼 무엇을 사지 말고 다음 두 가지를 하시길 권해봅니다. 가장 비싼 Plan으로 마음껏 써보기클로드 코드, 코덱스 등 AI 에이전트 서비스의 가장 비싼 Plan을 한 달 정도는 경험해보세요. 사용량 제한받거나 성능이 떨어지는 AI 모델을 쓰면, AI에 대한 관점도 그 정도에 갇힐 가능성이 커요. 프론티어급 모델을 토큰 화끈하게 사용했을 때 AI 서비스가 제공하는 가치는 꼭 경험해봐야 합니다. AI 모델 이용료는 더 줄어들 수 있지만, AI 모델을 더 내 손 위에 쥐어주는 AI 에이전트 서비스는 부가가치를 높이는 방향으로 이용료가 낮아지진 않을 겁니다. 게다가 현재는 경쟁하느라 적자 감수하며 퍼주는 것에 가까워서 고객에게 잔치 시기가 끝나면 이용료가 오르거나 제약이 커질 것 같습니다. 제 직업 환경의 상황으로 예로 들지요. 새로운 소프트웨어 개발 도구를 도입할 때, 잘못 도입하면 발생하는 비용이 크기 때문에 많은 시간 분석하고 검증하고, 학습하였습니다. 가치있는 일이지만 시간 비용이 너무 큽니다. 그러나 최근에 AI 코딩 에이전트를 이용해 후보 도구를 동시에 적용해봅니다. 예전엔 여러 사람이 동원되거나 긴 시간을 들여야 했지만, 이제는 혼자서 짧게는 몇 시간, 길어도 며칠 안에 실 경험에 기반한 판단 자료를 도출합니다. 리서칭하는 도구에 대해 직접 조사하거나 AI가 조사한 걸 리뷰하고 재검증하기도 했습니다. 하지만 사용량이 넉넉한 Plan을 사용한 이후로는 사용할 도구가 오픈소스인 경우, 코드 전체를 AI 에게 분석시키곤 합니다. 토큰 사용량으로 보면 1시간도 안 되어 몇 만원을 쓰는 셈인데, 제가 알고싶은 정보를 자세히 학습하기에도 좋고, AI 환각을 줄여주는 데에도 도움이 됩니다. 사용량 제한이 큰 Plan을 사용할 땐 마치 토큰을 아껴쓰느라 예전처럼, 즉 현재처럼 AI를 활용할 엄두를 못냈습니다. 가능성과 한계 인식하기1번의 연장인데, 화끈하게 AI 에이전트를 여러 방향으로 사용하다보면 자연스레 생각이 복잡해질텐데, 특히 다음 두 가지를 고민해보세요. 내가 하는 일, 내 환경에 대해 재정의하기 재정의한 내 상황에 비추어 가능성(미래)과 한계(현재)를 정의하기 그동안 많은 일하는 방식, 학습하는 방식, 협업하는 방식은 “사람”을 대상으로, 기준으로 하여 오랜 세월 고도화되어 잡힌 체계입니다. AI는 사람과 다릅니다. 소프트웨어를 만드는 환경을 예로 들겠습니다. 조직의 협업 체계에서 대개는 개발팀, 즉 소프트웨어 개발이 병목 자원입니다. 그래서 병목 자원 관리에 초점을 많추는 소프트웨어 개발 방법이나 협업 체계가 대부분입니다. 과감히 납작하게 본다면, 기획을 조직에 전파하는 용도로 발표 장표를 만드는 이유는, 그 작업 비용이 더 싸기 때문입니다. 전달력이 떨어지지만 전체적으로 봤을 때 저렴한 경우가 많습니다. 만약 발표 장표 만드는 목적이 비용이라면, AI 코딩 에이전트를 사용하여 데모 버전을 만드는 게 더 저렴합니다. 이용료, 시간은 물론이고, 실제 돌아가는 데모 버전의 전달력도 정적인 글, 그림보다 낫습니다. AI 에이전트를 펑펑 사용하면서 자신이 일하는 체계, 방식에서 사람 간 협업을 기준으로 하는 부분이 무엇인지 고민해보세요. 대체하거나 효율을 높일 부분 뿐만 아니라 한계도 고민하세요. 그 한계가 AI 모델이나 에이전트에서 기인하는 걸 수도 있고, 사람(자기 자신)에게서 기인하는 걸 수도 있습니다. 2번 단계에 오면 다음에 뭘 해야할지 방향이 잡힙니다. 하다못해 강의나 강좌, 책도 무엇을 봐야할지 관점이 생깁니다. 어떤 사람과 어떻게 협업할지, 어떤 도구에 돈을 더 들일지, 내가 몸으로 떼우는 게 나을지. 그 단계에 돈을 쓰세요. 이 과정을 경험하고, 내 관점을 갖는 데 1~2달이면 충분합니다. 요즘처럼 AI 발전이 빠른 시기에 너무 느린 것 아니냐고요. 불과 1년 전만 해도 AI 코딩 에이전트의 수준은 현재와 비교불가 수준이었다는 걸 보면 그런 마음이 들 수 있습니다. 근데, AI가 도구라는 점은 전혀 달라지지 않았습니다. 문제를 정의하고, 실제 문제를 해결하는(execution) 결정과 방식은 사람이 합니다. 끊임없이 새로운 도구는 나왔고 발전해왔지만, hello world에 머무르는 사람은 그때나 지금이나 hello world에 머무르고, 변화를 일으키거나 변화하는 사람도 그때나 지금이나 있어왔습니다. 보안 위협 등 조심해야 할 건 많은데, 이또한 앞서 거론한 “한계”로 파악하는 게 우선입니다. 문제를 알고, 정의할 수 있으면 해결 방법도 찾을 가능성이 큽니다. 더군다나 AI가 끝내주는 점 중 하나는 자연어로 소프트웨어 “엔지니어링”을 실행하는 겁니다. 그리고 “소프트웨어”여서 실행 비용이 상대적으로 저렴하고요. 고환율 시기라 100 USD, 200 USD가 부담스럽지만, 고성능 AI 도구를 다양한 방법으로 써보며 내 생각과 관점을 넓히는 비용으로는 저렴합니다.
hackers.pub
Link author: 한날@hannal@hackers.pub
이번 스프린트에는 해커스펍 위지위그 에디터에 이미지 업로드 기능 넣어볼까
Jiwon (
@z9mb1Jiwon), one of our core contributors, drew a Fedify dino! How cute!
https://oeee.cafe/@z9mb1/2b5b0baf-466b-4c65-a1e0-d3588f0666f4
Group 액터를 어떻게 처리할지에 대해서는 Lemmy까지 갈 필요도 없이 Discourse 플러그인에서 어떻게 처리하는지만 봐도 되긴 했었다..
https://meta.discourse.org/t/activitypub-plugin/266794/466?ref=blog.discourse.org
RE: https://planet.moe/@oeee_cafe/115615511184864588
Oeee Cafe is a Korean federated community drawing app that recently launched mobile apps on iOS and Android. You can follow users there from here in the fediverse already but not sure if you can submit drawings remotely yet.
#fedidev
シビックテックで取り組んでる課題をチームの皆で話してて、データはJSON-LDで記述したほうが良さそうとか、いずれシェア機能が欲しいねとか、コンテンツはオープンデータ化を前提としてデータの帰属は市民や地域コミュニティとしたいね等々を話し合う中で、「なんか…ActivityPub感…」と思った。
ActivityPubをオープンデータの流通・蓄積・活用の際に用いている取り組みとかって、あるのかな？
Open GLAMなどでありそうな気もするけど、どうなんだろ。
회사에 프론트엔드 포지션이 예상치 못하게 공석이 되어 진정한 풀스택으로 거듭나게 되었다. 다행히 중요한 것들은 구현이 마무리되서 코드 정리만 좀 하면 될 듯
오늘 동료랑 모노레포 설계에 대해 이야기하다가, 아래의 내용을 근거로 모노레포 설계에 너무 많은 시간을 쓰지말고 그냥 죄다 몰빵하자고 설득했다. 내가 생각하는 올바른 워크플로우를 어차피 도입하지 못할 거고, 그 상황에서 차선책들을 늘어놓고 고민을 하느니 시간이라도 아끼자는 입장이다.
내가 가진 개발에서의 지식/경험/의견은 negative한 형태가 많은것 같다. 어떤 문제에 대한 명쾌한 해결책(positive)보다는, 어떤 문제가 어렵거나 별로 중요하지 않으니 그쪽으로 시간을 쏟지 말아야한다는 사실을 활용하게 되는 경우가 더 잦다.
Fedify 2.0.0 is here!
This is the biggest release in Fedify's history. Here are the highlights:
- Modular architecture — The monolithic
@fedify/fedifypackage has been broken up into focused, independent packages:@fedify/vocab,@fedify/vocab-runtime,@fedify/vocab-tools,@fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types. - Real-time debug dashboard — The new
@fedify/debuggerpackage gives you a live dashboard at/__debug__/showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap yourFederationobject and you're done. - ActivityPub relay support — First-class relay support via
@fedify/relayand thefedify relayCLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c). - Ordered message delivery — The new
orderingKeyoption solves the “zombie post” problem where aDeletearrives before itsCreate. Activities sharing the same key are guaranteed to be delivered in FIFO order. - Permanent failure handling —
setOutboxPermanentFailureHandler()lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.
Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.
This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!
This is a major release with breaking changes—please check the migration guide before upgrading.
Full release notes: https://github.com/fedify-dev/fedify/discussions/580
Fedify 2.0.0을 릴리스했습니다!
Fedify 역사상 가장 큰 릴리스입니다. 주요 변경 사항을 소개합니다:
- 모듈형 아키텍처 — 기존의 단일
@fedify/fedify패키지를@fedify/vocab,@fedify/vocab-runtime,@fedify/vocab-tools,@fedify/webfinger등 독립적인 패키지들로 분리했습니다. 번들 크기가 줄어들고, 임포트가 깔끔해지며, 커스텀 어휘 타입으로 ActivityPub을 확장할 수도 있습니다. - 실시간 디버그 대시보드 — 새로운
@fedify/debugger패키지로/__debug__/경로에 라이브 대시보드를 띄울 수 있습니다. 연합 트래픽의 트레이스, 액티비티 상세, 서명 검증, 로그까지 한눈에 확인할 수 있습니다. 기존Federation객체를 감싸기만 하면 됩니다. - ActivityPub 릴레이 지원 —
@fedify/relay패키지와fedify relayCLI 명령어로 릴레이 서버를 바로 띄울 수 있습니다. Mastodon 방식과 LitePub 방식 모두 지원합니다(FEP-ae0c). - 순서 보장 메시지 전달 — 새로운
orderingKey옵션으로 “좀비 포스트” 문제를 해결합니다.Delete가Create보다 먼저 도착하는 문제가 더 이상 발생하지 않습니다. 같은 키를 공유하는 액티비티는 FIFO 순서가 보장됩니다. - 영구 전달 실패 처리 —
setOutboxPermanentFailureHandler()로 원격 인박스가 404나 410을 반환할 때 대응할 수 있습니다. 도달 불가능한 팔로워를 정리하는 등의 처리가 가능합니다.
이 외에도 미들웨어 수준의 콘텐츠 협상, @fedify/lint, @fedify/create, CLI 설정 파일, 네이티브 Node.js/Bun CLI 지원, 다수의 버그 수정 등이 포함되어 있습니다.
이번 릴리스에는 한국 OSSCA (오픈소스 컨트리뷰션 아카데미) 참가자분들의 큰 기여가 담겨 있습니다. 참여해 주신 모든 분께 감사드립니다!
브레이킹 체인지가 포함된 메이저 릴리스입니다. 업그레이드 전에 마이그레이션 가이드를 꼭 확인해 주세요.
전체 릴리스 노트: https://github.com/fedify-dev/fedify/discussions/580
一般 Kyungmi Ahn ꉂꉂ(ᴖᗜᴖ*) 아니그래서CU알바생들은메이드복을입나요??? CU는 사실메이드카페였던건가요???? 공식콜라보 아이템일텐데 대체 왜 메이드복이 있는건가요????
x.com/bahnbazi/sta...
여러분 반-바지 작가님의 새 만화가 진짜 죽여주는 맛의 백합인걸 아시고 지금 블루스카이를 하시는 겁니까? 어서 가셔서 보십시오. 보고 저와 같이 주먹을 입에 집어넣고 내적 비명을 질러보도록 합시다. #발광
반-바지. on X: "[폐쇄회로영상] 화성 제 5콜로...
보증 수리 상담도 AI 응대…인텔 지원 체계 전환
직접 사용해 본 결과, 실제 상담원 연결을 요청했을 때 애스크 인텔은 즉시 연결하지 않고 먼저 문제 설명을 요구했다. 데스크톱 프로세서 충돌 문제를 문의하자 그래픽 드라이버 업데이트를 안내했다. 해당 조치가 문제 해결에 적절한지 확신하기는 어려웠다. 또한 프로세서 스트레스 테스트를 권장했는데, 오히려 문제를 악화시킬 가능성도 있다.
보증 수리 상담도 AI 응대…인텔 지원 체계 전환
ive got a bachelor degree 😳
@z9mb1Jiwon Congrats!
현재 Hackers' Pub을 이용해 주시고 계신 여러분들은 간접적으로 Fedify의 현장 테스트에 도움을 주고 계십니다. 🤣
오래 기다리셨습니다!!!
BlueBase: Python으로 밑바닥부터 직접 만들어보는 DBMS
https://theeluwin.github.io/BlueBase/
결국 완성은 못했지만, 일단 공개할 수 있는 부분이라도 공개합니다.
RedBase DBMS을 구성하는 PF, RM, IX, SM, QL 중 PF와 RM을 여러분들이 직접 구현 할 수 있게, 과제의 형태로 제공합니다.
PF는 paged file의 약자로, file을 page 단위로 관리하는 컴포넌트입니다. 대충 4096 바이트 단위로 관리하는데요, file에 바로바로 read하거나 write하지 않고, 자주 사용되는 page는 가능한 memory에 있도록 중간에 buffer manager를 둡니다. 그렇다면 buffer에 공간이 모자라면? buffer에 있는 page 중 누군가를 evict 할 수밖에 없습니다. 그럼 뭘 기준으로 하면 좋을까요? 이 부분을 잘 생각해서 구현해보고, 성능을 비교해보기 바랍니다. 제가 cache hit/miss 시뮬레이션 구현해둔게 있으니, 제 custom 보다 높은 성능을 달성해주세요!
이후 RM은 record management의 약자인데, PF를 사용해서 record들을 가져오거나, 새로 넣거나 등을 하게 해줍니다. 그렇다면 전체 record를 순회하는 scan 연산이 중요하겠죠. 이 부분을 구현하는 것이 핵심입니다. record는 page 앞 부분에 bitmap을 둬서 slot이 비어있는지 아닌지를 확인하는데, 만약 record 삭제 명령이 마지막 slot을 비우게 된다면 해당 page는 더이상 필요 없겠죠. 그렇지만 이를 바로 free로 만드는건 조금 비싼 연산이 필요합니다. free page list를 다시 계산해야하거든요. 그래서 보통 DBMS에서는 이러한 작업들을 vacuum 연산으로 해결합니다. 추가로, 지금은 고정 길이 record만 다룰 수 있습니다만, 가변 길이를 허용하려면 어떻게 해야할까요? 이 부분들은 자유롭게 구현해보시면 좋겠습니다.
문서와 테스트는 모두 공개되어있습니다. 기여해주시면 감사하겠습니다! 다만, 정답 코드와 핵심 로직은 마지막까지 저 혼자 해보고 싶습니다 (도전).
게임 공략 사이트 기능 하나 추가하는데 최근 2-3주간 애썼다. 리액트(프론트) 왤캐 재밌냐
- 꿀잼포인트 1 내부 json 데이터 조기 검증을 위한 Zod 도입
- 꿀잼포인트 2 UI/UX 고려하기 (특히 모바일)
- 꿀잼포인트 3 캐릭터 점수 + 시너지 점수 고려해서 greedy 알고리즘 처리하기
- 꿀잼포인트 4 CodeRabbit/gitingest/es-hangul/ssgoi/Zustand 사랑해요
husky랑 lint-staged도 도입해서 체크도 해보고 좋은 라이브러리 있으면 바로 써먹어야지
근황
이것저것 쓰다가 Gemini CLI로 정착함. 꽤나 좋음 (Pro 요금제 사용)
claude code 기능들 조금만 기다리면 수입해서 적용해주는듯 ㅋㅋ
- 최근 배포 환경 트렌드를 몰라서 편하게 쓰던 netlify로 배포했더니, 100GB 대역폭이 발목잡힐줄 몰랐음 무제한으로 제공하는 cloudflare pages 에도 동시 배포했고, pages URL을 조만간 안내하거나 도메인 하나 사는걸 고민중
26년 2월 1일 ~ 2월 20일인데 벌써 50GB/100GB bandwidth 도달함
- ESLint+Prettier에서 Biome로 갈아탐. lint-staged 들어가면 3~5초 걸렸는데 획기적으로 빨라짐
퍼포먼스 보니까 Rust 기반 프로젝트들 사랑스럽다.
- supabase 연동 firebase 쓰려다가 supabase로 결정
- 장점 : 구글 연동, 넉넉(?)한 500mb 라는 무료 용량
- 단점 : 맘에 안드는 프로젝트 URL 이름
mcp 연결해주니까 얼추 잘해줌 ㅋㅋㅋㅋ
로컬스토리지 값을 supabase에도 저장해야하는데, 평문 저장은 용량 관리 등등 단점이 있을것 같아서 압축으로 lz-string 적용 + 방어 코딩
- 유저 2월 구글 연동 업데이트 이후 약 180명 유저 들어옴
꾸준히 트래픽 나오니까 살맛 난다 재밌다 그냥!
OK, I bought fedi.blue because I can, and I have no plans to use it for anything specific. Well, at least, I want to build an app that is compatible with both the fediverse (AP Protocol) and Bluesky (AT Protocol) ecosystem at the same time. So... if you have any ideas or suggestions, feel free to let me know! Sincerely, I want to waste money no more for domains that I won't use, so if you have any good ideas, please, please, PLEASE share them with me. You can find me at @chomu.dev초무 on Bluesky and
