리브의 아침 브리핑

01시니어 엔지니어의 파멸적 악순환

새 직장이나 승진, 큰 프로젝트를 맡은 시점에 자신을 증명하려고 실력보다 야심 찬 설계를 떠안는 경우가 많습니다. 보여줄 것이 없는데 스탠드업에서는 잘 되고 있다고만 말하고, 다음 주에 한 달 치를 해내면 된다며 혼자 과로하다 번아웃이나 퇴사로 끝나곤 합니다. 벗어나는 길은 더 높은 수준의 엔지니어를 연기하는 게 아니라 좋은 팀원으로 돌아가는 것입니다.

• COVID와 원격근무, 코딩 에이전트를 거치며 개인의 업무 소유권과 고립이 함께 커졌기 때문에, 동료가 내 작업을 모르는 상태를 스스로 막아야 합니다.
• 회사는 6개월 뒤의 상상 속 내가 아니라 지금의 나를 보고 뽑았습니다. 버그 수정, 동료에게 쌓인 궂은일, 문서 작성으로 다시 움직이기 시작하면 됩니다.
• 큰 프로젝트는 한 번의 폭발적 노력이 아니라 하루, 한 시간 단위의 꾸준한 작업으로 끝납니다. 평판이 먼저이고 소프트웨어는 그 뒤를 따릅니다.

sunilpai.dev · 관심사 상 · 추천 상위 5.7%

02PostgreSQL 캐싱: 기본 동작과 추가 캐시의 선택 기준

PostgreSQL은 데이터 페이지와 실행 계획은 캐싱하지만 쿼리 결과는 저장하지 않습니다. 그래서 캐시 적중률이 99%여도 같은 쿼리를 너무 자주 돌리면 CPU가 포화될 수 있습니다. 캐시를 더 붙이기 전에 디스크 때문에 느린지, 반복 실행 때문에 느린지부터 가려야 합니다.

• shared_buffers는 직접 운영하는 전용 서버에서 RAM의 25%가 시작점이고, OS 캐시와 중복되므로 40%를 넘겨 봐야 얻는 게 적습니다. effective_cache_size는 메모리 할당이 아니라 플래너용 힌트입니다.
• 반복 집계는 구체화 뷰, 자주 읽는 결과는 Redis나 프록시 캐시, 변경 스트림 기반으로는 Readyset·PgCache가 있지만 각각 갱신 비용과 최신성 지연이 다릅니다.
• 쓰기가 많거나 반복 조회가 적으면 캐시는 관리 부담만 늘립니다. pg_stat_statements와 EXPLAIN (ANALYZE, BUFFERS)로 인덱스와 쿼리부터 보는 편이 쌉니다.

pgcache.com · 관심사 중 · 추천 상위 21.2%

03AI가 무너뜨리는 공유의 문화

저는 잡지의 BASIC 코드를 Commodore 64에 옮겨 치며 프로그래밍을 배웠고, 지난 35년의 인터넷은 그런 공개와 카피레프트 위에서 자랐습니다. 그런데 LLM은 라이선스를 가리지 않고 긁어 가고, 그 결과물에는 원래의 의무가 이어지지 않습니다. 공유가 세상에 주는 선물이 아니라 창작자가 떠안는 부담으로 바뀌고 있습니다.

• 남이 공개한 코드를 가져다 쓰려 해도 저품질 AI 코드, 악성 라이브러리, 무단 사용된 저작물이 섞였을 수 있어 믿기 어려워졌습니다.
• 내 코드를 공개하면 AI로 취약점을 찾기 쉬워지고, 쓸모없는 AI 생성 PR을 분류하느라 여가 시간을 뺏깁니다. 공개하지 않을 이유만 늘어납니다.
• 개방성이 기여자에 대한 존중 없이 부와 권력을 모으는 수단으로 바뀌기 전에, 글쓴이·개발자·예술가가 공유의 기반을 함께 지켜야 합니다.

chesterwisniewski.com · 관심사 상 · 추천 상위 29.1%

04Claude Code 개발자 보리스 처니: "나는 자주 틀린다"

저는 거의 모든 문제에 여섯 단계를 씁니다. 가진 정보를 이해하고, 부족한 정보를 모으고, 문제를 정의하고, 단순한 접근법과 목표를 정한 뒤 빠르게 움직입니다. 새 정보가 들어오면 문제 정의로 돌아가는데, 갈팡질팡처럼 보여도 그건 건강한 반복입니다.

• 가장 흔한 실패는 무엇을 풀려는지 불명확하거나 해결법이 복잡한 것이고, 그러면 계획만 커지고 성공 기준이 흐려집니다.
• 계획을 세운 당사자는 이런 불명확함을 알아차리기 어려우니 피드백은 가능한 한 실시간으로 주고받아야 합니다.
• 틀렸다는 걸 발견하면 문제를 더 정확히 이해하게 됩니다. 이 여섯 단계 절차 자체도 고칠 수 있어야 합니다.

borischerny.com · 관심사 상 · 추천 상위 32.2%

05프롬프트는 실재하지 않는다

잘 작동하던 프롬프트도 다른 지시와 섞이거나 모델이 바뀌면 효과가 달라집니다. 그래서 문구를 다듬는 것으로는 에이전트의 신뢰성을 지킬 수 없고, 같은 작업을 반복 실행해 실패를 찾고 변경 전후를 테스트로 비교해야 합니다. 프롬프트는 그 과정에서 언제든 갈아 끼울 수 있는 결과물일 뿐입니다.

• 제목을 80자 이하로 달라고 해도 일부 입력에서는 JSON에 관한 혼잣말로 필드를 채웁니다. 필드명을 title에서 heading으로 바꿔 고쳤지만 그게 계속 유효하리라는 보장은 없습니다.
• pass^k 테스트로 행동을 재고 나면 GEPA 같은 최적화기에 프롬프트 수정을 맡길 수 있습니다. 대신 최적화에 쓰지 않은 홀드아웃으로 과적합을 확인해야 합니다.
• 브랜드 어조처럼 정답이 흐린 판단은 전문가가 좋은 답과 나쁜 답을 라벨링한 골든 데이터셋이 프롬프트 작성보다 중요합니다.

evaluation.club · 관심사 최상 · 추천 상위 40.9%

06Worktrunk - 여러 코딩 에이전트의 Git 작업 공간을 관리하는 CLI

Claude Code나 Codex에 여러 작업을 동시에 맡길 때 에이전트마다 별도 작업 디렉터리를 주려고 Worktrunk를 만들었습니다. git worktree의 생성·이동·삭제를 브랜치 이름만으로 처리하고, wt switch -c -x claude feature-a 한 줄로 브랜치와 작업 공간, 에이전트 실행까지 끝냅니다.

• wt list와 대화형 선택 화면에서 작업 공간별 변경, 커밋, 원격 상태, diff, PR 댓글까지 미리 볼 수 있습니다.
• 생성과 병합 전후 훅으로 의존성 설치나 테스트를 자동화하고, wt merge가 커밋 정리·리베이스·병합·작업 공간 삭제를 이어서 처리합니다.
• 지원 파일시스템에서는 빌드 캐시와 node_modules를 복제해 작업 공간마다 새로 설치하는 부담을 줄이고, 개발 서버 포트도 자동으로 나눠 줍니다.

github.com/max-sixty · 관심사 상 · 추천 상위 79.2%

07콘웨이의 법칙과 프로그래밍 언어

콘웨이의 법칙을 에이전트에 대 보면 깔끔하게 들어맞지 않습니다. 에이전트는 통신은 빠르지만 컨텍스트가 세션마다 리셋되어 공유 지식이 쌓이지 않습니다. 텍스트 생성 지연이 0에 수렴하는 지금, 최적화할 대상은 사람이 읽고 판단하는 시간뿐입니다.

• 인원을 더해도 병렬 팀만큼 늘지 않는 한계가 에이전트에서는 컨텍스트 오염으로 나타나고, 그래서 멀티 에이전트가 강한 단일 에이전트보다 못한 경우가 많습니다.
• 함수를 잘게 쪼개는 건 사람의 탐색 부담만 늘립니다. Linus의 '좋은 취향' 예처럼 엣지 케이스 자체를 없애는 설계가 판단 시간을 줄입니다.
• 언어는 에이전트가 아니라 코드를 읽는 사람을 위해 골라야 하고, 이 분석이 맞다면 사람을 위한 언어의 르네상스가 올 수 있습니다.

danieltan.weblog.lol · 관심사 상 · 추천 상위 96.7%

08가진 것은 주의력뿐: 무엇에 집중하느냐가 생각을 만든다

Attention is all you have

본문 재료는 들어오지 않았고, 제목과 댓글로 보면 주의력(attention)을 다룬 에세이입니다. 댓글에 인용된 문장으로는 테트리스 효과를 들어 오래 집중한 것이 결국 생각의 모양을 바꾼다고 말합니다.

• 댓글 반응 중에는 머신러닝 글인 줄 알았다며 제목이 낚시라는 불만이 먼저 보입니다.
• 책은 주의를 빼앗으려 하지 않는데 요즘 앱은 눈을 할퀴어 빼 간다는 반응도 있어, 논의는 주의 경제 쪽으로 흘렀습니다.

alicegg.tech · 관심사 중 · 프런트 상위 5.8%

09Bryan Cantrill 이 돌아본 Sun 의 실패

What Sun got wrong

Sun 출신 Bryan Cantrill이 Sun이 무엇을 잘못했는지 돌아보는 글입니다. 본문 재료는 없어 구체 논지는 원문을 봐야 하지만, 댓글 263개가 몰릴 만큼 그 시절을 겪은 사람들의 반응이 컸습니다.

• 댓글에서는 Sun이나 DEC는 영업 미팅과 견적 수정을 거쳐야 했고, 서버 레일과 전원선 값이 다음 날 오는 Dell 서버보다 비쌌다는 구매 경험담이 먼저 나왔습니다.
• 패키지 관리자 부재와 통째로 덮어쓰는 패치 때문에 야근이 많았다는 불만, 하드웨어는 앞섰지만 소프트웨어가 뒤처졌다는 평가도 반응으로 이어졌습니다.

bcantrill.dtrace.org · 관심사 상 · 프런트 상위 7.2%

10Kev: Qwen3.5 위에 만든 Jev 계열 소형 결정 모델

Kev: Tiny Jev-like family of decision models built on top of Qwen3.5

Qwen3.5를 바탕으로 Jev처럼 동작하는 작은 결정 모델 계열 Kev를 공개했습니다. 글을 쓰는 대신 판정만 내리는 Jev 방식을 오픈 모델 위에서 재현한 것으로 보이며, 세부 성능은 저장소를 직접 확인해야 합니다.

• 댓글 반응에는 내부 라우팅 로직을 이런 모델로 단순하게 만들 수 있겠다는 기대가 있습니다.
• 한편 코딩 에이전트에 쓸 수 있는지, 아니면 전혀 다른 용도인지 묻는 질문과, 분류 모델은 원래 있었는데 왜 지금 Jev 붐이냐는 반응도 함께 나왔습니다.

github.com · 관심사 최상 · 프런트 상위 11.2%