GeekNews Weekly

좋은 글을 읽고도 “잘 봤다”는 말 한마디를 끝내 보내지 못한 경험은 누구나 있을 겁니다. 위클리 메인 주제로 다룬 글이지만, 거기서 다룬 이메일의 지속성보다 더 흥미로운 부분은 “낯선 사람에게 말을 거는 법” 에 있습니다.

저자는 낯선 사람에게 처음 메일을 보낼 때 전송 버튼 위에서 커서가 5분간 머물렀다고 고백하는데요. 그 망설임의 끝에는 “내가 이 사람의 시간을 빼앗을 자격이 있나”라는 마음이 있었다고 합니다. 저자가 제시하는 원칙은 "친구로 삼고 싶은 사람에게만, 요구가 아니라 호기심으로 말을 걸고, 답장이 없어도 그 침묵을 내 가치와 연결하지 않는 것"입니다. 플랫폼이 연결을 추천해주는 시대에도, 결국 오래 남는 관계는 이런 작은 문장에서 시작된다는 점에서 읽어볼 만합니다.

폴 그레이엄 특유의 단순한 계산과 강한 주장이 잘 드러나는 글입니다. 핵심은 억만장자가 되는 비밀이 특별한 편법에 있는 것이 아니라, 사용자가 사랑하는 제품과 지수 성장의 조합에 있다는 주장입니다. 월 15% 성장이면 5년 만에 4,384배가 되고, 핵심 변수는 성장률과 지속 기간일 뿐 부정행위가 아니라는 것인데요. 그의 결론은 결국 공감(empathy), 사용자가 친구에게 알릴 만큼 사랑하는 제품을 만드는 것이 유일하게 지속 가능한 성장 엔진이라는 이야기입니다. 다만 이 글은 “부를 벌었다”는 말의 도덕적 의미까지 충분히 다루지는 않기 때문에, 댓글에서도 꽤 날카로운 반론이 이어졌습니다. 스타트업의 성장 논리를 이해하는 글로도 읽을 수 있고, 동시에 기술 업계가 부와 창업자를 바라보는 방식이 어떻게 바뀌고 있는지를 보는 글로도 흥미롭습니다.

.gitignore는 다들 쓰지만, Git이 파일을 무시하는 방식이 세 단계로 나뉜다는 사실은 의외로 잘 모르는 경우가 많습니다. 이 글은 Git의 무시 규칙이 사실 공유 범위에 따라 세 단계로 나뉜다는 점을 짚습니다. 팀이 공유할 규칙은 .gitignore, 이 저장소에서만 쓸 개인 파일은 .git/info/exclude, .DS_Store처럼 모든 저장소에서 빼고 싶은 건 머신 전역 ~/.config/git/ignore에 두는 식입니다. 특히 작업용 plan.md나 AI 도구가 만든 파일을 팀 저장소를 더럽히지 않고 무시하려는 요즘 워크플로우에 바로 쓸 수 있고, git check-ignore -v로 어떤 규칙이 파일을 잡는지 추적하는 팁도 실용적입니다.

"SaaS는 죽었다"는 종말론이 레거시 소프트웨어 시총 2,850억 달러를 증발시킨 가운데, 이 글은 "죽음이 아니라 재평가(repricing)" 라는 더 정교한 진단을 내놓습니다. AI로 코드 생성이 싸지면서 "기능을 먼저 만들었다"는 해자는 무너졌지만, 기업이 사는 건 코드가 아니라 신뢰라는 것이 핵심인데요. 주말에 Claude로 CRM을 바이브 코딩하는 것과 SOC2/감사 추적/새벽 4시 장애 책임을 감당하는 미션 크리티컬 서비스는 전혀 다른 일이기 때문입니다. 이제 진짜 해자는 기능을 만드는 속도가 아니라 남과 다른 축적된 데이터 / 고객이 빼낼 수 없게 흡수해버린 워크플로우 / 시스템이 제공하는 정확성인 것 같아요

머신러닝 쪽 면접을 준비하는 사람에게는 거의 체크리스트처럼 사용할 수 있는 글인데요. 단순한 면접 후기라기보다, 인터뷰 따내는 법, 기술 준비, 감정 관리, 연봉 협상, RSU와 스톡옵션 차이까지 실제 구직 과정을 전부 정리해뒀습니다. "인터뷰는 본질적으로 확률적이며 결과가 연구자로서의 가치를 결정하지 않는다"는 메시지가 좋네요.

클라우드 AI 코딩 도구의 가격이 올라가면서, 로컬 LLM을 개발 워크플로우에 다시 넣어보려는 움직임이 커지고 있습니다. 이 글은 로컬 모델이 최상위 모델만큼 강하지는 않지만, 좋은 하니스와 작업 분해, 툴링을 붙이면 충분히 실용적인 코딩 파트너가 될 수 있다고 설명합니다. 흥미로운 관점은 약한 모델이 오히려 사용자를 더 개입하게 만들어 "느린 것이 빠른 것"이라는 부분입니다. 계속 로컬 LLM을 강조드리긴 합니다만, 댓글의 온도는 좋지 않네요 ^^;

이 영상은 디자이너가 Claude Code로 코딩하는 데모처럼 보이지만, 실제로는 AI 시대의 제품 개발 워크플로우를 보여주는 사례에 가깝습니다. 여러 worktree에서 Claude 세션을 병렬로 돌리고, 프로토타입을 비교하고, 브라우저에서 검증한 뒤 PR까지 이어가는 과정이 매우 구체적입니다. 중요한 점은 AI가 코드를 대신 써준다는 사실보다, 더 많은 실험안을 빠르게 만들 수 있게 되었을 때 검증, 리뷰, 디자인 판단을 어떻게 확장할 것인가입니다. “모두가 만들 수 있다고 해서 모두 배포되어야 하는 것은 아니다”라는 관점이 특히 요즘 AI 개발 흐름과 잘 맞습니다.

AI 에이전트를 제대로 쓰려면 결국 모델보다 컨텍스트를 어떻게 전달하느냐가 더 중요해집니다. 구글의 Open Knowledge Format은 조직 안에 흩어진 위키, 코드 주석, 런북, 데이터 정의 같은 지식을 에이전트가 읽을 수 있는 Markdown 기반 형식으로 정리하려는 시도입니다. 새로운 거대한 지식 관리 시스템을 만들기보다, 코드처럼 버전 관리할 수 있는 단순한 포맷을 제안한다는 점이 좋습니다. 앞으로 에이전트가 많아질수록 각 회사의 경쟁력은 모델 선택보다 “우리 조직의 지식이 얼마나 잘 정리되어 있는가”에서 갈릴 가능성이 큽니다.

코딩 에이전트가 코드를 많이 만들수록, 병목은 작성이 아니라 리뷰와 신뢰로 이동합니다. 이 글은 AI가 산출량을 늘리는 동시에 코드 churn, 결함률, 리뷰 부담을 함께 키운다는 데이터를 바탕으로, 앞으로 코드 리뷰가 더 중요한 엔지니어링 역량이 될 것이라고 말합니다. 특히 에이전트가 어떤 의도로 코드를 썼는지 PR에 남기지 않으면, 리뷰어는 사라진 맥락을 처음부터 다시 추론해야 합니다. AI로 작성이 싸진 시대일수록, 좋은 팀의 차이는 더 빨리 쓰는 능력이 아니라 더 잘 검증하는 시스템에서 나올 것 같습니다.

SQLite는 “작고 단순한 도구”처럼 보이지만, 실제로는 26년 넘게 유지된 가장 성공적인 소프트웨어 프로젝트 중 하나입니다. 이 인터뷰에서 흥미로운 부분은 기능보다 운영 철학입니다. 외부 기여를 무조건 많이 받기보다 장기 유지보수 책임을 고려해 신중하게 받고, 필요한 도구는 직접 만들며, 제품 코드보다 많은 테스트로 품질을 지켜왔다는 점이 인상적입니다. AI가 코드를 빠르게 만들어내는 시대일수록, 오래 살아남는 소프트웨어는 결국 집요한 테스트와 장기적 책임감 위에 세워진다는 사실을 보여주는 글입니다. SQLite의 지원 종료 목표가 2050년이라는 대목에서, 진짜 린디 효과란 무엇인가를 다시 생각하게 됩니다.

소셜 미디어의 둠스크롤에 지친 사람들 사이에서 인디 블로그가 조용히 부활하고 있습니다. 하지만 문제는 여전히 발견 가능성인데요. Bubbles는 5천 개가 넘는 독립 블로그 글을 Hacker News식 프런트 페이지로 모아, 투표와 최신성을 기준으로 보여주는 서비스입니다. 알고리즘 피드와 대형 플랫폼에 묶이지 않은 글들을 다시 발견하게 만든다는 점에서, 이번 주 메인 글의 이메일·개인 웹 흐름과도 잘 맞습니다. 좋은 글이 사라지는 것이 아니라, 발견되는 경로가 약해진 것이라면 이런 실험은 더 많이 나와도 좋을 것 같아요. 물론 지속 운영이 중요하겠지만요.

Claude Code를 만든 Boris Cherny의 이야기라서 “AI가 엔지니어를 대체할까”라는 자극적인 제목으로 읽히지만, 실제 핵심은 조금 다릅니다. 그는 엔지니어의 역할이 코드를 직접 타이핑하는 사람에서 판단하고, 계획하고, 사용자 문제를 이해하는 빌더로 이동한다고 봅니다. 특히 조직이 AI 사용량 자체를 목표로 삼으면 토큰 사용량만 늘어나는 부작용이 생긴다는 지적이 중요합니다. AI 도입의 성패는 “얼마나 많이 썼나”가 아니라, 실제 업무 흐름과 가치 창출 방식을 얼마나 바꾸었는가에 달려 있다는 점에서 읽어볼 만합니다.

이 글은 기술 업계의 문화가 어떻게 제품을 사랑하는 너드 문화에서 관심을 추구하는 창업자 브랜드로 이동했는지를 비판적으로 봅니다. 예전의 기술자 이미지는 세부 구현과 제품 완성도에 집착하는 사람이었지만, 최근에는 돈, 권력, 자기서사를 앞세우는 인물이 전면에 나서는 경우가 많아졌다는 문제의식인데요. 저자는 업계가 40년간 쌓은 신뢰를 지난 10년간 관심(attention) 이라는 자산으로 청산해 왔다고 표현합니다. 그래서 저자는 부와 권력의 과시 대신 틈새에 대한 집착, 배움에 대한 애정, 스포트라이트 앞의 겸손 같은 핵심 너드 가치로 돌아가야 한다고 주장합니다.

웹페이지를 저장해두었는데 나중에 열어보면 빈 화면이나 멈춘 스피너만 남아 있는 경험이 종종 있습니다. Kage는 헤드리스 크롬으로 페이지를 실제 렌더링한 뒤 최종 DOM을 저장하고, JavaScript를 제거한 정적 사본으로 만들어 오프라인 보관을 쉽게 해주는 도구입니다. 단순한 “웹페이지 저장”을 넘어, CSS·이미지·폰트까지 로컬화하고 ZIM 아카이브나 단독 실행 파일로 패키징할 수 있다는 점이 좋습니다. 웹이 점점 동적이고 일시적인 매체가 되는 상황에서, 좋은 자료를 오래 보존하려는 사람들에게 유용한 도구입니다.

Anthropic이 공개한 창업자용 플레이북으로, AI-native 스타트업을 아이디어, MVP, 출시, 확장 단계별로 어떻게 만들지 정리합니다. 흥미로운 점은 “AI로 더 빨리 만들자”가 아니라, AI가 만든 MVP가 기술 부채를 쌓지 않게 관리하고, 초기 반응과 진짜 제품-시장 적합성을 구분하는 방법까지 다룬다는 점입니다. 요즘은 창업자가 직접 코드와 운영 자동화까지 다루는 일이 현실이 되고 있지만, 그만큼 판단 기준도 더 중요해졌습니다. AI로 실행 비용이 낮아진 시대에, 무엇을 만들지보다 무엇을 검증할지가 더 중요하다는 점을 잘 보여줍니다. 다만 "삽 파는 사람의 마케팅", "창업은 상품화될 수 없다"는 회의적 반응도 만만치 않으니, 가치 있는 프레임으로 볼지 영업 자료로 볼지는 직접 읽어보시고 판단하세요.

Kubernetes는 한때 대규모 서비스나 복잡한 마이크로서비스 조직을 위한 도구처럼 여겨졌지만, 이제는 훨씬 작은 회사에서도 기본 선택지가 되고 있습니다. 이 글이 흥미로운 이유는 Kubernetes 채택 이유를 기술적 확장성보다 배포 방식의 통일, 운영 지식의 문서화, GitOps 기반 변경 이력에서 찾기 때문입니다. 즉, Kubernetes는 클러스터 기술이라기보다 조직이 서비스를 운영하는 방식을 표준화하는 언어가 되고 있습니다. 다만 초기 회사라면 여전히 제품에 집중하는 것이 우선이고, 사람과 서비스가 늘어나 운영 지식이 흩어지기 시작할 때 도입을 고민하는 편이 현실적입니다.

홈랩을 운영하는 사람이라면 컨테이너 업데이트, 릴리스 노트 확인, 브레이킹 체인지 점검 같은 일이 생각보다 많은 시간을 잡아먹는다는 것을 압니다. 이 글은 OpenCode Web UI와 GitOps를 엮어, AI가 변경을 제안하고 사람은 PR을 검토한 뒤 배포하는 홈랩 AI 개발 플랫폼을 구성한 사례입니다. 중요한 점은 AI가 실제 서비스에 직접 접근하지 못하고, Git 브랜치까지만 푸시할 수 있게 제한했다는 구조입니다. 개인 홈랩 이야기처럼 보이지만, 앞으로 회사 내부 운영 자동화에서도 그대로 참고할 만한 AI 권한 설계 사례입니다.

Fabrice Bellard는 FFmpeg, QEMU, TinyCC, QuickJS처럼 개발자들이 알게 모르게 의존해 온 굵직한 프로젝트를 만든 인물입니다. John Carmack이 그를 두고 “그가 나보다 전반적인 프로그래밍 실력이 훨씬 뛰어날 것” 이라고 말한 대목이 인상적인 이유는, 두 사람 모두 과시보다 실제 구현물로 평가받는 개발자이기 때문입니다. 요즘은 창업자 브랜드와 AI 도구 활용 능력이 크게 부각되지만, 이 글은 여전히 깊은 기술적 호기심과 장기적인 결과물이 개발자의 가장 강한 평판이 될 수 있음을 보여줍니다. 댓글에서 더 인상적인 평이 나오는데요. "그의 진짜 천재성은 코딩 실력이 아니라, 수많은 사람에게 유용해질 문제를 골라내는 감각"

AI 코딩 에이전트가 코드를 많이 만들수록, 이제는 “누가 이 줄을 썼는가”보다 “어떤 프롬프트와 맥락이 이 줄을 만들었는가”가 중요해지고 있습니다. 이 도구는 에이전트의 작업을 git처럼 추적·감사해서, rgt blame으로 특정 코드 줄을 어떤 프롬프트가 작성했는지 역추적하고, rgt log로 세션 단위 작업 내역을 보는 식인데요. git을 대체하는 게 아니라 보완하는 "에이전트 감사 추적" 계층이라는 점이 핵심입니다. AI 코드 리뷰에서 가장 큰 문제는 결과물만 남고 의도와 과정이 사라진다는 점인데, 이 도구는 그 빈틈을 버전 관리의 방식으로 메우려는 시도입니다. 앞으로 코딩 에이전트를 팀 단위로 쓰려면 코드뿐 아니라 에이전트의 작업 이력도 관리 대상이 될 가능성이 큽니다.

Apple의 Vehicle Motion Cues는 차량 움직임을 가속도계·자이로로 감지해, 화면 가장자리에 점을 띄우고 그 점을 차의 회전·제동에 맞춰 움직이는 기능인데요. 눈은 정지한 화면을, 내이(속귀)는 차의 움직임을 느끼는 감각 불일치가 멀미의 원인이라, 그 틈을 점으로 메워주는 원리입니다. 말로 설명드리면 잘 이해가 안되는데, 기능을 키면 점이 막 움직이는게 신기합니다. 특히 버스나 총알택시에서 한번 켜보시면 정말 세상이 좋아졌구나 라는 생각이 드실겁니다.

플래그십 모델의 가격이 잇따라 오르면서, 로컬 LLM을 진지하게 쓸 수 있나라는 질문이 몇주간 긱뉴스에 계속 올라오네요. 이 글은 M2 Mac 같은 일반 개발자 장비에서도 로컬 모델이 개발 질문, 코드 작업, 문서 확인에 꽤 실용적인 수준까지 올라왔다는 경험을 공유합니다. 물론 최상위 클라우드 모델을 완전히 대체하긴 어렵지만, 로컬 모델은 비용, 프라이버시, 관찰 가능성 측면에서 분명한 장점이 있습니다.

앞 글이 "로컬이 좋아졌다"는 한 사람의 경험이라면, 이 Ask HN은 같은 질문을 수십 명에게 던진 집단 지성입니다. 결론을 요약하면 Qwen 3.6 27B(덴스)와 35B-A3B(MoE)가 현재 30B급 sweet spot이고, Pi 하니스 + llama.cpp 조합이 표준처럼 자리 잡았는데요. 가장 자주 나온 비유는 로컬 모델이 "가이드가 필요한 주니어", 클라우드 Opus가 "함께 설계하는 시니어" 라는 것입니다. 즉 정밀한 프롬프트와 작업 분해가 필수죠. 현재 로컬은 대략 프런티어 대비 8~18개월 뒤쳐진 것으로 평가되지만, 무료/프라이버시/할당량 걱정 없음이라는 실질 이점 때문에 계층형(설계는 클라우드, 구현은 로컬) 워크플로가 현실적 대안으로 떠오르고 있습니다.

여러 모델을 한 번에 호출하고, 별도의 judge 모델이 답변을 합성하는 방식은 최근 LLM 활용에서 점점 자주 보이는 패턴입니다. OpenRouter Fusion은 이 과정을 API 형태로 제공해, 단일 모델이 놓칠 수 있는 blind spot과 모순을 줄이려는 시도입니다. 다만 비용은 각 모델 호출의 합으로 계산되고, 속도도 느려질 수 있기 때문에 모든 작업에 맞는 방식은 아닙니다. 리서치, 비평, 고비용 의사결정처럼 오답 비용이 모델 비용보다 큰 작업에서는 이런 다중 모델 숙의 방식이 실용적인 선택지가 될 수 있습니다.

Microsoft가 관리하는 Windows용 Coreutils는 겉보기에는 작은 도구 묶음이지만, 개발 환경의 경계를 줄인다는 점에서 의미가 있습니다. grep, find, coreutils 계열 명령을 Windows에서 네이티브로 실행할 수 있으면, Linux, macOS, WSL, 컨테이너, Windows 사이를 오가는 스크립트와 파이프라인의 마찰이 줄어듭니다. 요즘 개발 환경은 로컬, 컨테이너, 클라우드, CI가 뒤섞여 있기 때문에 “어느 OS에서나 비슷하게 동작하는 기본 도구”의 가치는 더 커지고 있습니다. 좀 늦은감은 있지만, 윈도우 개발자에게는 WSL 없이도 유닉스식 작업 습관을 가져올 수 있는 반가운 변화입니다.

DB 스키마를 이해할 때 ERD는 여전히 가장 빠른 시각화 도구 중 하나입니다. 이 도구는 CREATE TABLE 문을 브라우저에 붙여넣으면 PostgreSQL, MySQL, SQLite, SQL Server 스키마를 바로 인터랙티브한 ER 다이어그램으로 바꿔줍니다. 서버 업로드 없이 로컬 브라우저에서 처리된다는 점도, 실제 서비스 스키마를 다룰 때 중요한 장점입니다. AI가 코드와 쿼리를 생성해주는 시대에도, 사람이 구조를 빠르게 파악하고 검토하는 시각적 도구는 계속 필요하다는 걸 보여주는 작은 유틸리티입니다.

구직 과정에서 GitHub 저장소를 검토해 달라는 요청은 꽤 자연스럽게 보이는데요. 이 글이 무서운 이유는 바로 그 자연스러운 상황을 이용해 npm install만으로 실행되는 백도어를 숨겼다는 점입니다. 개발자는 평소라면 피했을 행동도 면접이나 채용 맥락에서는 “느려 보이면 안 된다”는 압박 때문에 쉽게 실행할 수 있습니다. 중요한 교훈은 낯선 저장소를 실행하기 전에 반드시 격리된 환경과 보안 위생을 갖춰야 한다는 것입니다.

많은 CLI가 localhost로 OAuth를 리다이렉트하는데, 이는 CLI와 브라우저가 같은 머신에 있다고 가정하기 때문에 SSH·컨테이너·WSL에서 흐름이 깨지게 됩니다. 대안은 2019년 표준화된 RFC 8628 Device flow로, 포트 바인딩 없이 짧은 코드와 URL만 출력해 어느 환경에서든 동일하게 작동하는데요. gh·aws sso·vercel은 이미 기본 채택했지만 gcloud·wrangler·claude는 아직 loopback을 사용한다는 지적과 함께, 새 CLI를 개발한다면 device flow를 기본값으로 두라고 강조합니다.

로컬 LLM을 프런티어 모델의 저렴한 대체품으로만 보면 실망하기 쉽습니다. 이 글은 Qwen 같은 로컬 모델의 가치를 Claude Opus와의 점수 경쟁이 아니라, 고정 비용, 프라이버시, 벤더 리스크 완화, 내부 데이터 처리 같은 다른 축에서 봐야 한다고 말합니다. 특히 고객 데이터와 내부 텔레메트리처럼 클라우드로 올리기 어려운 작업에서는 로컬 모델이 단순한 비용 절감 이상의 의미를 가집니다. 로컬 AI를 “더 나쁜 클라우드 AI”가 아니라, 제약이 다른 별도의 도구로 봐야 한다는 관점이 좋습니다.

Java의 Project Valhalla는 너무 오래된 프로젝트라 오히려 실감이 잘 나지 않았는데, 이제 JDK 28 preview로 실제 개발자 손에 들어오는 단계까지 왔습니다. 핵심은 객체를 클래스처럼 작성하면서도 int처럼 효율적으로 다룰 수 있는 value class입니다. 객체 헤더, 힙 할당, GC, 포인터 간접 참조 비용을 줄이려는 시도라서, Java의 성능 모델과 API 설계에 장기적으로 큰 영향을 줄 수 있습니다. 다만 첫 버전은 아직 일부만 들어오기 때문에, “드디어 완성”이라기보다는 Java 객체 모델이 천천히 바뀌기 시작하는 순간으로 보는 편이 맞겠습니다.

유저스페이스 에뮬레이터는 일반 개발자에게는 낯설지만, 보안 연구와 멀웨어 분석에서는 매우 강력한 도구입니다. 이 프로젝트는 Windows API를 통째로 재구현하는 대신 syscall 수준에서 실행을 제어하고, 기존 시스템 DLL을 활용하면서 프로세스 실행을 세밀하게 관찰할 수 있게 합니다. 메모리 접근, 특정 명령어, 새로운 코드 경로를 후킹할 수 있다는 점은 분석 대상이 무엇을 하려는지 파악하는 데 큰 도움이 됩니다. AI 보안, 공급망 공격, 악성 패키지 문제가 계속 커지는 상황에서 이런 저수준 분석 도구의 중요성도 다시 커지고 있습니다.

Codex Record & Replay는 프롬프트를 더 잘 쓰는 방향이 아니라, 아예 사용자가 작업을 한 번 보여주면 그것을 재사용 가능한 Skill로 만드는 접근입니다. 비용 처리, 리포트 다운로드, 이슈 생성처럼 매번 비슷하지만 설명하기 귀찮은 UI 기반 작업에 특히 잘 맞습니다. 흥미로운 점은 이것이 단순한 매크로나 RPA가 아니라, 사용 조건, 입력값, 검증 방식까지 포함한 작업 컨텍스트로 저장된다는 점입니다. AI 에이전트가 점점 많아질수록, 자연어 설명보다 시연과 반복에서 배우는 인터페이스가 더 중요해질 것 같아요.

이 기사는 AI 모델 접근권이 이제 단순한 API 권한 문제가 아니라 수출 통제, 국적, 동맹, 사이버 역량의 문제로 번지고 있음을 보여줍니다. 특히 우리가 잘아는 SK Telecom이 논란의 중심에 놓였다는 점도 국내 독자 입장에서는 특히 눈길이 가는데요. 다만 SK Telecom은 의혹을 부인했고, 공개된 제한 요구 문서에도 한국 기업이나 중국에 대한 직접 언급은 없다는 점은 함께 봐야 합니다. AI 모델이 강력해질수록 “누가 접근할 수 있는가”가 기술 정책의 핵심 쟁점이 되는 흐름을 보여주는 사례입니다.

데이터 분석 에이전트가 실제 회사 데이터에 붙기 시작하면, 가장 큰 문제는 SQL을 잘 짜느냐보다 정확한 의미를 알고 있느냐입니다. 매출, 환불률, 활성 사용자 같은 지표는 회사마다 정의가 다르고, 조인 하나만 잘못해도 숫자가 크게 왜곡될 수 있습니다. 이 도구는 위키, dbt, Looker, Metabase, 데이터베이스 메타데이터를 모아 에이전트에게 승인된 지표 정의와 조인 그래프를 제공하려는 시도입니다. 앞으로 데이터 에이전트의 품질은 모델 성능보다, 조직의 지식과 지표가 얼마나 실행 가능한 컨텍스트로 정리되어 있는지에 달려 있을 것 같습니다.

AI 안전 논의는 종종 과장된 종말론처럼 보이지만, 이 글이 던지는 질문은 꽤 구체적입니다. 핵심은 재귀적 자기개선, 즉 AI가 인간 개입 없이 스스로 능력을 키우는 단계에 도달했을 때, 지금의 자발적 안전 프로토콜과 느린 정부 대응으로 감당할 수 있느냐는 문제인데요. 특히 AI 투자는 핵폭탄을 만들어낸 맨해튼 프로젝트와 비교될 만큼 커졌지만, 안전과 검증 체계에 쓰는 비용은 훨씬 작다는 불균형이 중요합니다. AI를 낙관하든 비관하든, 이제는 “모델이 얼마나 똑똑한가”만큼 누가, 어떻게, 어디까지 검증할 것인가를 함께 봐야 할 시점입니다.

AI 앱 빌더를 직접 만들려면 모델 호출보다 더 어려운 부분이 있습니다. 사용자별로 격리된 실행 환경을 만들고, AI가 그 안에서 코드를 작성하게 하고, 결과물을 즉시 미리보기 URL로 보여주며, 비용 때문에 유휴 환경을 잠재우는 일입니다. 이 프로젝트는 그 복잡한 백엔드를 Go, Docker, Traefik, SQLite 조합으로 비교적 단순하게 구성해 오픈소스로 공개했습니다. 멀티테넌트 격리와 슬립/웨이크업 기반 비용 제어를 갖춰 일반 서버 한 대로 여러 사용자를 수용하는 구조를 쉽게 시작할수 있어 도움이 될 것 같습니다.

개인정보 유출이라고 하면 보통 이름, 전화번호, 이메일을 떠올리지만, 이번 사례는 조금 특이하네요. 유출된 정보에 창업 아이디어 요약과 심사평이 포함되었는데요. 어디선가 본 제보에 의하면 해당 사이트 프론트엔드 코드에 키가 아예 인코딩 되어 있었다고 하네요. 요즘 유출 사례들이 많아서 한번 더 내 서비스의 보안을 체크해보게 됩니다.

Meta는 오랫동안 빠른 실행과 엔지니어 자율성의 상징 같은 회사였지만, 이 글은 그 문화가 AI 경쟁 속에서 어떻게 흔들리고 있는지를 보여줍니다. 엔지니어들이 제품을 만드는 사람에서 데이터 라벨링과 RLHF 작업자에 가까운 역할로 이동하고, 키 입력·토큰 사용량 같은 측정 지표가 평가 압박으로 들어오는 모습은 꽤 상징적입니다. AI를 도입하는 기업이 흔히 빠지는 함정은 “AI로 더 좋은 제품을 만들자”가 아니라 “AI를 많이 쓰는 조직처럼 보이자”로 목표가 바뀌는 것입니다. 빅테크의 내부 변화이지만, 모든 회사가 AI 전환을 설계할 때 조심해야 할 사례로 읽을 만합니다.

근데 진짜 요즘 페이스북은 기능 업데이트가 없던데, 메타 내부에서는 인스타그램이랑 쓰레드만 신경쓰는 듯 합니다. 소셜에서 이 기사에 달린 댓글을 보니 메타 내부에선 페북을 선셋 프로젝트로 보고 있다는 얘기도 있더군요.

업계를 들썩이게 한 빅딜입니다. Elon Musk의 SpaceX가 Cursor 개발사 Anysphere를 600억 달러(약 90조 원) 전액 주식 교환으로 인수했는데요. 우주 회사가 IDE를 사는 기괴한 그림이지만, 핵심은 Cursor가 보유한 개발자 데이터(코딩 요청·설계 결정)가 Grok 같은 모델 개선에 쓰일 수 있다는 점입니다. SpaceX가 IPO에서 제시한 28.5조 달러 시장의 상당 부분이 기업용 AI라는 배경도 깔려 있죠. 다만 댓글의 온도는 회의적입니다. "이미 다들 Claude Code·Codex로 옮겨갔는데 왜 지금 Cursor인가"

Microsoft CEO 사티아 나델라가 AI 시대 기업 전략을 정리한 글로, AI 전환을 모델 경쟁이 아니라 학습 루프 경쟁으로 봅니다. 핵심 개념은 사람의 지식·판단인 휴먼 캐피털과 기업이 소유하는 AI 역량인 토큰 캐피털인데요. 토큰 캐피털이 커질수록 인간의 방향 설정(주도성)이 더 중요해지고, 진짜 경쟁력은 최고 모델을 고르는 게 아니라 두 자본이 복리로 쌓이는 학습 루프를 모델 위에 구축하는 데서 나온다는 주장입니다. 특히 소수 모델이 모든 가치를 흡수하는 미래는 정치·경제적으로 용인되지 않으니, 가치가 모든 기업·산업·국가로 흐르는 '프론티어 생태계'를 만들어야 한다는 메시지가, MS의 플랫폼 사업자로서의 포지셔닝과 맞물려 읽힙니다.

SaaS 주가가 크게 흔들리면서 “AI가 SaaS를 끝냈다”는 말이 다시 나오고 있지만, 이 글은 그 해석이 너무 단순하다고 반박합니다. 수직 SaaS와 수평 SaaS의 성장률은 생각보다 큰 차이가 없고, 시장이 과소평가하는 것은 워크플로 장악력, 독점 데이터, 도메인 지식 같은 눈에 잘 보이지 않는 해자라는 분석이 핵심입니다. AI 네이티브 소프트웨어가 기존 SaaS를 일부 대체하겠지만, 실제 산업 현장의 복잡한 규칙과 데이터를 가진 기업은 오히려 더 강한 위치를 가질 수도 있습니다. “SaaS는 죽었다”보다 “어떤 SaaS가 AI 시대에 더 강해지는가”라는 질문으로 바꿔 읽어야 할 글입니다.