Borrowed Confidence

Addy Osmani의 2026년 6월 15일 글 **“Agentic Code Review”**는 AI 코딩 에이전트가 보편화된 뒤 코드 리뷰의 의미가 어떻게 바뀌었는지 다룹니다. 글의 핵심은 단순합니다. 코드 작성은 기계 속도로 빨라졌지만, 사람이 변경을 이해하고 신뢰하는 속도는 거의 그대로이기 때문에 병목은 리뷰와 검증으로 이동했다는 것입니다. 원문: Agentic Code Review — Addy Osmani TL;DR 핵심 정리 병목 이동: AI는 수천 줄의 코드를 빠르게 만들지만, 사람이 “이 변경을 믿어도 되는가"를 판단하는 속도는 그대로다. 데이터의 경고: Faros는 AI 채택이 높은 팀에서 code churn 861%, incidents-to-PR ratio 242.7%, median review duration 441.5%, zero-review merge 31.3% 증가를 보고했다. 상황별 리뷰: 솔로 프로토타입과 결제·인증·개인정보를 다루는 장기 운영 시스템은 같은 리뷰 규칙을 적용하면 안 된다. 의도 복원 비용: 에이전트가 만든 diff에는 구현 의도와 대안 검토가 사라지기 쉬우므로, PR에 decision log와 테스트 증거를 붙여야 한다. 사람의 역할 변화: 사람은 모든 줄을 읽는 reviewer에서 risk tiering, sampling, audit, high-blast-radius gate를 책임지는 owner로 이동한다. 1) 코드 작성은 싸졌고, 이해는 그대로 비싸다 과거 코드 리뷰는 속도의 균형 위에 있었습니다. 주니어가 코드를 작성하는 속도보다 시니어가 읽는 속도가 빨랐기 때문에, 리뷰는 자연스럽게 병목이 되지 않았습니다. 하지만 에이전트는 이 균형을 깨뜨립니다. ...

이 글은 Tuhin Nair의 아티클 **「Why senior developers fail to communicate their expertise」(2026-05-12)**를 바탕으로, 시니어 개발자의 설명이 왜 조직에서 잘 받아들여지지 않는지 구조적으로 정리한 글이다. TL;DR 핵심 정리 시니어 개발자는 “덜 만들기, 재사용, 지연"을 통해 **복잡성(complexity)**을 관리하려고 한다. 반면 비즈니스 조직은 시장 학습 속도를 높여 **불확실성(uncertainty)**을 줄이는 데 집중한다. 그래서 시니어가 “유지보수성·안정성"만 강조하면, 상대의 핵심 문제를 해결하지 못해 설득이 실패한다. 저자가 제안한 실전 문장: “Can we try something quicker?” AI 시대에는 Speed(실험용)와 Scale(안정화용) 시스템을 분리해, 속도와 안정성을 동시에 달성하자는 제안이 나온다. 원문: https://www.nair.sh/guides-and-opinions/communicating-your-expertise/why-senior-developers-fail-to-communicate-their-expertise ...

Palantir가 공개한 “The Palantir Ontology"는 단순한 데이터 통합 전략이 아니라, 기업 운영을 의사결정 단위로 모델링해야 한다는 주장을 담고 있습니다. 이 글은 긴 원문을 실무 관점에서 빠르게 파악할 수 있도록 핵심만 압축한 정리입니다. TL;DR 핵심 정리 핵심 프레임: Ontology는 Data + Logic + Action + Security를 하나로 연결해, 분석 시스템이 아닌 운영 의사결정 시스템을 만든다. 중요한 포인트: 기업 데이터 자체보다, 누가/언제/어떤 맥락에서 어떤 결정을 내렸는지에 대한 의사결정 데이터와 계보 축적을 더 중시한다. 에이전트 활용 방식: LLM이 단순 조회(RAG)에 머무르지 않고, 기존 최적화 모델·시뮬레이터·업무 로직을 툴로 호출해 대안을 만들고 시나리오로 안전하게 검토한다. 실행과 통제: 액션(writeback)은 ERP/WMS/엣지 시스템까지 반영되지만, 권한·검증·감사 로그를 동일한 보안 체계로 강제해 자동화 리스크를 줄인다. 최종 메시지: 생성형 AI 도입 성패는 “모델 성능"보다 “의사결정 루프를 얼마나 안전하게 닫고 학습시키는 아키텍처를 갖췄는가"에 달려 있다는 주장이다. 원문: https://x.com/PalantirTech/status/2049136883528011954 ...

출처: https://cacm.acm.org/blogcacm/model-collapse-is-already-happening-we-just-pretend-it-isnt/ 핵심 주장 AI 모델이 이전 모델의 출력(합성 데이터) 으로 훈련될 때 발생하는 모델 붕괴(model collapse) 가 이미 진행 중이며, AI 업계가 이를 인정하지 않고 “더 큰 모델, 더 많은 데이터, 더 많은 컴퓨트"라는 규모 확대 전략으로만 문제를 해결하려 한다고 비판합니다. 모델 붕괴(Model Collapse)란? AI 모델이 자신의 이전 버전(또는 다른 AI)이 생성한 합성 텍스트/데이터로 반복 학습할 때 발생하는 현상입니다. 원본 데이터에 있던 희귀하고 독특하며 놀라운 패턴 (분포의 꼬리 부분, long tail)이 점차 사라짐 모델 출력이 점점 평평하고 제네릭(generic) 해지며, 다양성이 급격히 줄어듦 결국 통계적 평균 으로 수렴하면서 현실성과 정보 밀도가 낮아짐 모델은 덜 유용한 내용을 더 자신 있게 출력하게 되는 위험한 상황 발생 저자는 이를 “포토카피를 반복 복사하는 것"에 비유합니다. 처음에는 괜찮아 보이지만, 몇 세대가 지나면 세부사항이 모두 사라져버립니다. ...

출처: https://ngrok.com/blog/quantization 주요 주제 이 글은 대형 언어 모델(LLM)의 양자화(Quantization) 를 기초부터 자세히 설명합니다. LLM이 너무 커서 일반 PC나 노트북에서 돌리기 어려운 문제를 해결하기 위해, 모델 크기를 줄이면서도 성능을 최대한 유지하는 방법을 다룹니다. 독자가 로컬 환경에서 강력한 LLM을 실제로 실행할 수 있도록 돕는 것이 목적입니다. 왜 양자화가 중요한가? 최신 LLM은 수십억~수조 개의 매개변수(Weights) 를 가짐 → 예: 80B 모델 = 약 159GB (float32 기준) 1T(조) 매개변수 모델은 2TB RAM 이 필요해 단일 머신에서 거의 불가능 양자화로 모델을 4배 작게 , 최대 2배 빠르게 만들 수 있음 (정확도 손실은 5~10% 수준) 핵심 개념 양자화(Quantization) : 고정밀 부동소수점(float32 등)을 낮은 비트(8비트, 4비트 등)로 변환하는 손실 압축 기법 부동소수점 비교: float32: 32비트 (높은 정확도, 큰 메모리) bfloat16 / float16: 16비트 (메모리 절반) 8비트, 4비트: 더 극단적 압축 LLM 매개변수는 대부분 0 근처 에 몰려 있지만, 소수의 아웃라이어(Outliers) 가 존재해 양자화 시 주의가 필요합니다. ...

출처: https://alexop.dev/posts/the-software-factory/ 핵심 메시지 AI 코딩 에이전트(Claude Code 등)를 활용해 “software 팩토리” 를 구축하면, 개발 팀의 작업 방식이 완전히 바뀐다. 개발자는 더 이상 코드를 직접 많이 작성하지 않고, 설계·아키텍처·검토·의사결정 에 집중한다. 결과적으로 팀 규모는 크게 줄고, 출시 속도는 몇 시간 단위로 빨라진다. 기존 방식 vs. software 팩토리 기존 방식 (Beer Commerce 예시) 12명 체크아웃 팀 한 기능(할인 코드 추가) 추가에 10~14일 소요 대부분 시간이 핸드오프(BA → PO → Dev → QA)와 커뮤니케이션에서 사라짐 실제 코딩 시간은 고작 2~3일 software 팩토리 방식 ...

이 글은 2026년 3월 18일경 BLOG@CACM에 게시된 것으로, 저자는 Mallik Tatipamula , David Attermann , 그리고 인터넷의 아버지로 불리는 Vinton G. Cerf (Vint Cerf)입니다. 핵심 논지 AI와 지능이 빠르게 분산화(distributed)되고 있는 현재 상황에서, 신뢰(trust) 와 책임(responsibility) 는 여전히 중앙화된 전통적 모델(특정 조직·인간 감독)에 의존하고 있어 심각한 불일치가 발생하고 있다. → 지능 분산 속도 » 신뢰/책임 메커니즘 발전 속도 따라서 “검증 가능한 책임(verifiable responsibility)” 또는 “검증 가능한 분산 신뢰(verifiable distributed trust)” 를 인터넷 아키텍처 수준에서 근본적으로 설계해야 한다는 주장을 펼칩니다. ...