리브의 아침 브리핑

01서버 모니터링 분석 가이드

대시보드 설치 가이드는 많은데, 그래프를 실제로 읽고 진단하는 법을 다룬 글은 드뭅니다. 그래서 수많은 지표를 구글 SRE의 네 가지 황금 신호로 묶었습니다. 그리고 증상(지연·에러)을 먼저 보고 원인(CPU·메모리·풀)으로 범인을 좁히는 순서로 정리했습니다.

• 평균 응답 시간은 분포의 모양을 지웁니다. P50/P95/P99로 읽어야 하고, 장애의 전조는 거의 항상 P99에 먼저 나타납니다. 게다가 꼬리에 걸리는 사람은 무거운 쿼리를 만드는 헤비 유저일 가능성이 높습니다.
• 메모리 누수는 톱니의 봉우리가 아니라 바닥이 계단처럼 오르는 것으로 판별합니다. 커넥션 풀이 말랐을 때 던질 질문은 '풀이 작은가'가 아니라 '왜 반납이 느려졌는가'입니다.
• 대기 시간은 사용률에 비례하지 않습니다. 사용률 50%일 때를 1로 두면 80%에서 4배, 95%에서 19배로 늘어납니다. '아직 10% 남았다'는 계산이 위험한 이유입니다.

kciter.so · 관심사 중 · 추천 상위 4.0%

02문제는 AI 코드가 아니라, 이제 아무도 아무것도 모른다는 것이다

AI가 만든 코드의 품질보다 큰 문제가 있습니다. 팀 안에 시스템의 구조와 설계 이유를 이해하는 사람이 사라지고 있다는 점입니다. 모두가 Claude에게만 물으면, 코드가 나쁘지 않아도 전체 계획 없이 개발이 굴러가는 상태가 됩니다.

• 출시량만 압박하는 조직에서는 명세, 코드, 티켓, 보고서까지 Claude Code가 만듭니다. 사람은 하루 12-13시간 엔터만 누르고, 결과는 아무도 읽지 않는다는 증언이 나옵니다.
• 파이프라인·앱·대시보드를 쉽게 만들수록 유지보수할 대상도 늘어납니다. 마지막까지 남는 난관은 여전히 유지보수입니다.
• AI를 지휘하고 조율할 사람은 계속 필요합니다. 의도·안목·설계 역량이 없는데 기본기까지 사라지는 상황이 위험합니다.

ssp.sh · 관심사 최상 · 추천 상위 7.8%

03글 쓰다가 막혔을 때 대처법

제텔카스텐으로 재료와 구성은 쉬워졌어도, 디테일하게 쓰는 일은 여전히 어렵습니다. 여러 해결법을 실험해 보니 대부분이 하나의 원칙으로 모였습니다. 발산할 때는 제약을 없앤다는 원칙입니다.

• 글이 막히는 건 대개 발산 단계에서 스스로 검열하기 때문입니다. 액셀과 브레이크를 동시에 밟는 셈이라, 둘은 따로 밟아야 합니다.
• 아무 말이나 제한 시간 안에 최대한 많이 쓰고, 순서와 상관없이 강렬하게 떠오른 부분부터 씁니다. 다듬기는 퇴고 때 합니다.
• 앞에 누가 있다고 생각하고 말하듯 쓰면 제약이 줄어듭니다. STT로 받아 적으면 논리가 비약하는 곳도 드러납니다.

thinkingsian.com · 관심사 중 · 추천 상위 17.2%

04코딩은 해결된 문제가 아니다

AI가 코드 생성 비용을 낮춘 건 맞습니다. 하지만 그렇다고 소프트웨어 개발이 해결된 건 아닙니다. 운영 비용의 대부분은 유지보수·신뢰성·보안·확장성에 있고, AI는 코드를 설명해 줄 수는 있어도 대신 이해하거나 책임질 수는 없습니다.

• 코드를 안 읽어도 되는 제품은 개인용 소프트웨어, POC, 위험 자체를 무기로 쓰는 경우 정도입니다. 의료·금융·항공처럼 실수가 인명과 법적 결과로 이어지는 분야에는 책임질 사람이 필요합니다.
• LLM 코딩은 오류를 되먹임하는 하네스에 크게 기댑니다. 그래도 논리적 한계, 긴 입력에서 떨어지는 정확도, 비결정적 출력은 남습니다.
• 생산성은 PR 수나 토큰 사용량이 아니라 서비스 수준과 고객이 받는 가치로 판단해야 합니다.

blog.alexewerlof.com · 관심사 중 · 추천 상위 18.9%

05NobodyWho - 앱과 게임에 로컬 AI를 넣는 온디바이스 추론 엔진

클라우드 API 없이 사용자의 기기에서 모델을 돌려, 앱과 게임에 대화·이미지 이해·음성 기능을 넣는 오픈소스 엔진입니다. 모델만 내려받으면 인터넷도 API 키도 없이 돌아가고, 입력은 외부 서버로 나가지 않습니다.

• Rust와 llama.cpp 기반으로 GGUF 모델을 실행하고, Python·Kotlin·Swift·Flutter·Godot 연동을 제공합니다.
• 앱 함수의 인자 이름과 타입을 읽어 도구 호출 형식을 자동으로 만들고, Whisper 음성 인식과 RAG용 임베딩·재정렬도 로컬에서 처리합니다.
• 실험 기능으로 OpenAI Chat Completions 호환 서버를 제공하고, 라이선스는 EUPL-1.2입니다.

github.com/nobodywho-ooo · 관심사 상 · 추천 상위 35.2%

06Jeff - 집에서 학습한 Jev 호환 0.8B 의사결정 모델

Jeff는 상황과 선택지를 자연어로 주면 문장 대신 선택지별 확률을 돌려주는 소형 의사결정 모델입니다. Qwen3.5와 Gemma 4를 미세조정했습니다. 학습·합성 데이터 생성·테스트를 모두 집 장비에서 했고, 클라우드 GPU나 폐쇄형 모델의 출력은 쓰지 않았습니다.

• 0.8B 모델은 GPU 한 장으로 약 2시간 만에 학습했고, M4 Max에서 28ms, RTX PRO 6000에서 22ms에 판단합니다. 요청 형식은 Jev와 같습니다.
• 분류와 근거 확인 과제에서는 Jev와 비슷하거나 더 높지만, BBH·WinoGrande 같은 추론 과제에서는 격차가 큽니다. 종합 점수만 보고 대형 모델급 추론을 기대하면 안 됩니다.
• Doom과 Frogger에서는 0.8B가 규칙 봇 수준을 냈습니다. 그런데 벤치마크 점수가 더 높은 2B는 게임에서 오히려 부진했습니다.

github.com/firelex · 관심사 상 · 추천 상위 45.0%

07제대로 된 AI 제품은 어떤 모습이어야 할까?

'AI는 실수할 수 있으니 확인하세요'라고 할 거라면 확인할 도구도 줘야 합니다. 오류 검증은 회색 면책 문구가 아니라 제품의 핵심 기능이어야 합니다. 답변보다 원문 인용과 출처를 앞세워야 합니다.

• 모든 주장 옆에 검증 체크박스를 두고, LLM 출력과 사람이 한 확인 작업을 두 열로 나란히 기록하는 작업지를 제안합니다.
• 연구·개발 도구는 1인칭으로 말하거나 사과할 이유가 없습니다. 끝없는 채팅 대신 작업별 UI, 실행 재현, 컨텍스트 가시성을 줘야 합니다.
• 코딩 에이전트의 안전은 사용자의 주의력이나 프롬프트가 아니라, 모델과 독립된 하네스 통제에 기반해야 합니다. 파일 작업 제한, 스냅샷, 실행 계획 검토가 기본입니다.

blog.glyph.im · 관심사 상 · 추천 상위 59.9%

08LLM Wiki의 불량 페이지를 Jev로 선별하는 것이 가능할까?

AI가 쓴 위키가 커지면 모든 페이지를 다 읽을 수 없습니다. 그래서 Jev에게 결함 확률을 물어 의심스러운 페이지부터 읽으려 했습니다. 결과부터 말하면 기대한 역할을 못 했는데, 그 이유가 오히려 쓸 만한 교훈이었습니다.

• 비공개 위키는 결함 비율이 44%라 어차피 다 읽어야 했습니다. 공개 위키는 자잘한 흠이 거의 모든 페이지에 있고 큰 흠은 드물어서, 점수로 갈라낼 신호가 없었습니다.
• 사전 등록과 블라인드 라벨링으로 쟀습니다. 처음 보인 신호는 파이프라인 개선 전의 옛 페이지가 낮게 나온 코호트 효과였습니다.
• 선별 도구를 붙이기 전에 결함이 얼마나 흔한지, 즉 기저율부터 재야 합니다.

alfadur7.github.io · 관심사 상 · 추천 상위 81.5%

09GPT-6.1 Sol 공개: Astra에 가까운 성능을 1/5 가격에

GPT 6.1 Sol: Near-Astra intelligence for a fifth of the price

GPT-6 Sol을 업그레이드한 GPT-6.1 Sol을 공개합니다. 코딩, 에이전트, 컴퓨터 사용, 전문 업무 전반을 개선했고, GPT-6 Astra에 근접한 성능을 훨씬 낮은 비용으로 제공합니다.

• 같은 사건을 다룬 GN 요약에 따르면, DeepSWE v1.1에서 Astra와 대등한 성능을 약 1/5 비용으로 냅니다.
• HN 반응에서는 '바로 어제 안전 문제로 공개하지 않는다는 헤드라인이 있지 않았나'는 의문이 먼저 나왔습니다. 사용량 집계 방식 변경 발표 이후 가격 인하는 예상된 수순이고 엔터프라이즈 시장을 겨냥한 것이라는 해석도 있었습니다.
• Opus 5.5의 절반 가격이라며 가격 경쟁으로 읽는 댓글도 있었습니다.

openai.com · 관심사 최상 · 프런트 상위 2.8%

10OpenAI Dots: 상시 동작하는 에이전트

Dots: Always-on agents

Dots를 소개합니다. 상시로 돌아가는 에이전트입니다. 발표 본문은 재료로 들어오지 않아서, 여기서는 제목과 HN 반응만으로 정리합니다.

• HN 반응은 제품보다 이름과 표기에 먼저 갔습니다. Claw나 Muse에 비해 Dots는 억지스럽고 비인격적이라 홍보 영상의 분위기와 맞지 않는다는 지적이 있었습니다.
• 이름을 귀엽게 꾸미는 제품일수록 침투적이라는 불신 섞인 반응도 나왔습니다.
• 마케팅 페이지를 여러 번 읽어도 무엇인지 모르겠다는 댓글이 있어, 기능 설명 자체가 부족했던 것으로 보입니다.

openai.com · 관심사 최상 · 프런트 상위 7.5%