Verification-First Engineering

LinkedIn Engineering이 2026년 6월 18일 공개한 **“Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing”**는 AI 에이전트가 실제 대규모 서비스의 품질 관리를 어떻게 바꿀 수 있는지 보여주는 사례입니다. 원문: Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing AI 핵심 정리 문제 배경: LinkedIn은 iOS, Android, Web, 36개 이상 언어, 사용자 유형, 멤버십, 실험 조합 때문에 전통적인 UI 자동화만으로 모든 변화를 따라가기 어렵다. 해결 방식: QA Agent는 selector에 의존하지 않고 VLM으로 화면을 읽으며, planner, analytical reasoning model, fine-tuned visual grounding model을 나눠 쓴다. 운영 구조: 안정적인 흐름은 deterministic replay로 빠르게 실행하고, 화면이 바뀌면 vision-based planning으로 넘어간다. 검증 장치: view tree, tracking log, action history, error detection pipeline, golden dataset을 통해 phantom bug보다 실제 버그 탐지를 우선한다. 현재 규모: LinkedIn은 350개 이상 테스트를 30분 주기로 실행하며, QA Agent가 200개 이상 유효 버그를 찾았다고 밝혔다. 1) 전통적인 UI 테스트가 막히는 지점 LinkedIn의 품질 문제는 단순히 화면이 많다는 수준이 아닙니다. 같은 기능이라도 사용자 유형, 언어, 멤버십, 실험군, 개인화 상태에 따라 다른 화면이 나옵니다. LinkedIn은 이 조합을 “하나의 앱이 아니라 수천 개의 permutation"에 가깝게 설명합니다. ...

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 팩토리 방식 ...

출처: https://andresmax.com/large-software-teams-ai-age/ 주요 논제 AI 시대에 대규모 software 팀의 역할이 크게 바뀌고 있다. AI가 개발 생산성을 극적으로 높여 5인 팀 이 2016년의 50인 팀 수준의 출력을 낼 수 있게 되었지만, 대규모 팀이 완전히 사라지는 것은 아니다. 대신 최소 팀 규모는 줄어들고 , 팀을 구성하는 이유(제품 사고, 시스템 복잡성, 조직적 필요)가 달라졌다. 1. 대규모 팀의 기존 문제점과 AI의 영향 과거(2016년) MVP 개발 시 보통 5~7명 (백엔드 23명, 프론트 12명, 디자이너 1명, PM 1명)이 필요했다. 2026년 현재 AI 활용 시 2~3명 (풀스택 엔지니어 12명 + 코딩 가능한 디자이너 + PM 01명)으로 압축 가능. AI가 개인 생산성을 40~60% 향상시킨다. 구체적 가속화 예시: 보일러플레이트 코드: 몇 시간 → 몇 분 (5~10배) 디버깅: 3060분 → 1015분 (2~4배) 새로운 프레임워크 학습: 며칠 → 몇 시간 (3~5배) 테스트 작성, 문서화, 코드 리뷰 준비 등도 2~4배 빨라짐. 그러나 AI가 해결하지 못하는 영역이 여전히 존재: ...

새로운 AI 시대의 가장 중요한 인재는 엔지니어가 아니라 연구자 입니다. 누구나 AI로 “무료로 만들 수 있는” 시대가 되면, 진짜 차별점은 “무엇을 만들 가치가 있는가? 과연 만들 수 있는가?” 를 판단하는 능력이다. 연구자는 해결책이 없을 수도 있는 문제를 붙잡고, “이 베팅에 목숨 걸 만한가?” 를 결정하는 사람들입니다. 시장도 이미 이 사실을 반영하고 있다 퀀트 펌들은 포트폴리오 한 번 관리해 본 적 없는 학부생에게 $600k 를 준다. AI 랩(Meta Superintelligence Labs 등)은 연구자 한 명에게 4년간 $3억 까지 제안한다. → 한 번의 학습 비용이 수억 달러인데, 데이터 효율을 1~2%만 올려도 그 연구자가 수십 배로 돈을 벌어줍니다. 왜 연구는 자동화하기 어려운가? ...