Softwares

Anthony Hobday의 글 Notes on software quality는 소프트웨어 품질을 낭만적인 장인정신이 아니라, 제품과 조직이 실제로 감당해야 하는 운영 문제로 다룬다. 핵심은 간단하다. 좋은 소프트웨어는 더 많은 기능을 가진 소프트웨어가 아니라, 사용자가 마주치는 문제를 더 적게 남기는 소프트웨어다. Quality 핵심 정리 핵심 주장: 품질은 “문제가 거의 없는 상태"에 가깝고, 완벽에 가까워질수록 필요한 노력은 급격히 커진다. 여섯 신호: 신뢰성, 속도, 명확성, 유효성, 효율성, 아름다움이 소프트웨어 품질을 판단하는 주요 축이다. 조직의 역할: 품질은 실무자의 선의만으로 만들어지지 않는다. 리더십이 품질을 원하고 허용해야 한다. 규모의 비용: 제품과 팀이 커질수록 관계와 조율이 폭증해 세계적 수준의 인터페이스 품질은 점점 어려워진다. 실천 방식: 별도 품질 팀, 버그 우선 정책, 정기적인 품질 개선일처럼 시간과 권한을 따로 확보해야 한다. 원문: Notes on software quality ...

출처: https://www.categoryvc.com/writing/where-the-ai-hardware-market-is 이 글은 2026년 현재 AI 인퍼런스 시장을 “누가 더 많은 FLOPS를 내느냐"가 아니라 “누가 메모리 병목을 더 잘 푸느냐"의 관점으로 재정리합니다. 특히 LLM serving의 실제 병목이 prefill과 decode에서 다르게 나타난다는 점을 기준으로, 어떤 레이어에서 기업들이 경쟁하는지 살펴봅니다. TL;DR 핵심 정리 병목의 본질: H100급 GPU에서도 LLM autoregressive decode 구간은 메모리 대역폭 제약이 커서 Tensor Core 사용률이 낮아지기 쉽다. 칩 레벨 전략: Groq·Cerebras·d-Matrix류 접근은 연산 유닛 증설보다 메모리-연산 거리 단축(SRAM, scratchpad, wafer scale)으로 성능을 끌어올린다. 소프트웨어 전략: RadixArk(SGLang), Inferact(vLLM) 같은 엔진 경쟁의 핵심은 prefill(연산 중심)과 decode(메모리 중심)를 분리 최적화하는 스케줄링이다. 인프라 전략: KV cache를 GPU→CPU RAM→NVMe→S3로 계층화하면 긴 컨텍스트 비용을 줄이고 재사용률을 높일 수 있다. 시장 결론: 승자는 “NVIDIA 대체"보다 “특정 병목 해결"에서 먼저 나오며, 이후 클라우드·엔진·플랫폼에 통합될 확률이 높다. 1) 왜 지금도 GPU는 놀고 있는가 많은 팀이 “GPU가 비싸다"는 문제를 이야기하지만, 더 정확히는 “GPU 안의 연산 장치가 놀고 있다"는 문제가 큽니다. 이유는 단순합니다. ...

출처: https://larsfaye.com/articles/agentic-coding-is-a-trap Lars Faye는 “AI가 코드를 쓰고 인간은 오케스트레이션만 하면 된다”는 흐름이 생산성 혁신처럼 보이지만, 실제로는 팀의 핵심 개발 역량과 비용 구조를 동시에 흔들 수 있다고 경고한다. TL;DR 핵심 정리 핵심 문제: 에이전틱 코딩은 초반 산출 속도를 높이지만, 사람이 코드에서 멀어질수록 장기적으로 이해·설계·디버깅 능력 저하가 발생할 수 있다. 감독자 역설: AI 출력을 제대로 검증하려면 숙련 개발자의 판단력이 필수인데, AI 의존이 커질수록 그 판단력 자체가 약화되는 모순이 생긴다. 주니어 성장 리스크: ‘직접 작성→실패→수정’ 경험이 줄면 코드 리뷰만으로는 학습 곡선이 가파르게 떨어질 수 있다. 비용/벤더 리스크: 토큰 사용량과 모델 성능은 고정비가 아니라 변동성이 큰 외생 변수이므로, 전면 도입 시 예산·운영 안정성이 낮아질 수 있다. 실무 결론: 에이전트를 기본값으로 두기보다, 문제 유형별 사용 경계와 수동 코딩 훈련 루프를 함께 유지해야 한다. 1) 글의 핵심 주장: “속도”와 “역량”은 같은 축이 아니다 글은 에이전트 중심 개발이 단기적으로는 빠르게 많은 코드를 만들어내지만, 그 과정에서 사람이 코드의 실제 인과관계와 설계 의도를 놓치기 쉬워진다고 본다. 즉, 산출량이 늘어도 팀의 실질적 문제 해결 능력이 같이 성장한다는 보장은 없다는 지적이다. ...

Django 핵심 기여자인 James Bennett가 LLM 코딩 도구의 효과에 대해 이론적·실증적 근거를 들어 회의적 분석을 제시한 글입니다. 원문: LLMs 핵심 프레임워크: Fred Brooks의 “은탄환은 없다” (1975) 소프트웨어 개발의 어려움을 두 가지로 구분합니다: 우발적(accidental) 어려움 — 도구로 제거 가능 (수동 메모리 관리 등) 본질적(essential) 어려움 — 사양, 설계, 테스트 등 소프트웨어 자체에 내재된 것 Brooks의 핵심 통찰: “어려운 부분은 개념을 구축하는 것이지, 그것을 표현하는 노동이 아니다.” 우발적 어려움이 전체의 90% 이상이 아닌 한 10배 생산성 향상은 불가능하며, 실제 비율은 훨씬 낮다고 저자는 봅니다. ...

출처: 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가 해결하지 못하는 영역이 여전히 존재: ...

이 뉴스레터는 15명의 실전 엔지니어·엔지니어링 리더 들이 실제로 사용 중인 AI 보조 엔지니어링(AI-Assisted Engineering) 경험을 모아 정리한 글이다. 스타트업부터 대기업까지 다양한 규모와 배경의 사람들이 공유한다. 원문: How to Do AI-Assisted Engineering 핵심 메시지 AI는 생산성을 크게 높여 주지만, 단순히 “AI한테 코드 짜라고 시키면 끝"이 아니다. 엄격한 설계 + AI 구현 + 공격적인 리뷰 + 반복 이 핵심 공식이며, 인간의 판단과 감독 을 절대 빼놓을 수 없다는 점을 모든 기고자가 강조한다. 주요 워크플로우 패턴 (공통점) 아이데이션 / 설계 단계 (가장 중요) ...

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