Posts

Rohan Ganapavarapu의 Technological Involution은 기술 정체론, AI, 스타트업 문화, 하드테크를 한데 묶어 묻는다. 우리는 정말 더 이상 만들 것이 없는 시대에 도착했는가, 아니면 기술을 상상하고 믿는 방식이 먼저 낡아버린 것인가. Tech 핵심 정리 정체의 핵심: 문제는 가능성의 고갈보다 상상력의 수축이다. 우주, 원자력, 시간여행을 꿈꾸던 문화가 이제는 더 많은 AI와 더 많은 소프트웨어만 반복한다. 창업 문화의 함정: 창업자는 자기 확신으로 움직인다고 믿지만, 실제로는 VC, 인플루언서, 액셀러레이터가 유통한 논제를 자기 생각처럼 받아들이기 쉽다. AI의 한계: AI는 소프트웨어 엔지니어링에는 강력하지만, 현실 조직을 바꾸는 일은 여전히 운영 이해, 책임, 도메인 감각을 요구한다. 기회의 위치: 쉬운 SaaS보다 칩, 하드웨어 공급망, 엔터프라이즈 운영, 현장 문제처럼 접촉 비용이 큰 곳에 더 오래가는 가치가 있다. 새 기술의 조건: 좋은 제품은 억지 광고보다 제품 자체의 설득력과 시대적 욕구를 통해 퍼진다. 기술자는 다시 만들고 싶은 것에 대한 순수한 확신을 가져야 한다. 1) 정체는 기술보다 상상력에서 먼저 온다 글의 출발점은 1960년대식 미래 감각입니다. 당시 대중문화는 우주, 원자력, 정보기관의 기묘한 실험, 시간여행 같은 주제를 당연히 다음 세계의 후보로 상상했습니다. 중요한 것은 그 상상 중 일부가 실제 기술 개발의 방향이 되었다는 점입니다. ...

Swizec Teller의 Code is the easy part, or how we refactored half the business to fix a janky script는 낡은 청구 스크립트를 고친 이야기처럼 시작합니다. 하지만 핵심은 코드가 아닙니다. 회사가 커지면서 비즈니스 개념, 데이터 모델, 운영 습관, 고객 셀프서비스, 재무팀 도구까지 함께 바꿔야 했던 리팩터링 이야기입니다. 원문: Code is the easy part, or how we refactored half the business to fix a janky script Refactor 핵심 정리 표면 문제: 낡은 Python 스크립트가 모든 인보이스를 발행했고, 월말 청구는 종종 밤샘 작업이 됐다. 진짜 문제: 사용자, 기관, 랩, 구매 부서, 영업 구역, 데이터 공유 구조가 하나의 데이터 모델에 섞여 있었다. 핵심 해법: 협업 구조와 청구 구조를 분리하고, “이 주문을 어떻게 청구할까?“에 답하는 Billing Entities를 만들었다. 결과: 월말 청구가 일주일에서 2일로 줄었고, 고객은 직접 청구 정보와 구매 주문서를 관리할 수 있게 됐다. 실무 교훈: 복잡한 스크립트는 대개 원인이 아니라 증상이다. 먼저 도메인 모델이 현실을 제대로 담는지 봐야 한다. 1) 회사가 커지면 예외 처리도 제품이 된다 Swizec이 합류한 2024년 8월, 회사는 연간 반복 매출 약 2천만 달러에 가까워지고 있었습니다. 2026년 6월에는 1억 달러 ARR이 가시권에 들어왔다고 합니다. 매출은 빠르게 커졌지만, 청구 시스템은 훨씬 작은 회사였을 때의 방식에 머물러 있었습니다. ...

Tereza Tizkova의 글 Software is becoming marketing은 AI가 코드를 대량 생산할 수 있게 된 뒤 소프트웨어 산업이 어디로 움직이는지 다룹니다. 핵심은 소프트웨어가 더 이상 희소한 산출물이 아니라, 마케팅처럼 누구나 만들고 누구나 평가하는 영역에 가까워진다는 주장입니다. AI 핵심 정리 진입 장벽 하락: 누구나 vibecoding으로 간단한 SaaS를 만들 수 있으면, 소프트웨어는 수학보다 마케팅에 가까운 평가 대상이 된다. 헌신 약화: 프로젝트 관리 도구가 3개일 때는 하나를 고르지만, 300개가 있고 직접 만들 수도 있으면 고객의 정착률은 낮아진다. 중간층 압박: 단순 기능을 월 $50에 파는 중간 규모 SaaS는 개인 제작 도구와 거대 플랫폼 사이에서 설 자리가 좁아진다. 서비스화: 기업은 회계 소프트웨어보다 장부 마감이라는 결과에 더 큰 돈을 쓴다. AI 시대의 큰 기회는 도구가 아니라 결과 판매다. 커리어 전략: 그저 괜찮은 개발자보다 기술에 디자인, 유통, 브랜드, 도메인 전문성을 결합한 사람이 더 강해진다. 1) 소프트웨어는 더 쉽게 평가받는 일이 된다 글의 출발점은 진입 장벽과 외부 평가 가능성입니다. 수학처럼 언어 자체가 어려운 분야에서는 비전문가가 쉽게 끼어들기 어렵습니다. 반대로 마케팅, 디자인, 글쓰기처럼 결과물이 눈앞에 보이는 분야에서는 누구나 의견을 냅니다. ...

Daniel Miessler가 2026년 6월 25일에 쓴 “The Coming Divide: AI-Native or Left Behind” 는 AI에 대한 실망과 회의론이 커지는 시점에 던지는 경고입니다. 그는 AI 산업의 거품, 막대한 투자, 추론 비용의 불확실성을 부정하지 않습니다. 다만 그 우려가 “AI는 또 하나의 Crypto/NFT였으니 무시해도 된다"는 결론으로 굳어지는 순간, 개인의 역량 격차가 빠르게 벌어진다고 봅니다. 원문: The Coming Divide: AI-Native or Left Behind TL;DR 핵심 정리 핵심 주장: AI 거품을 비판하는 것과 AI 활용 능력을 포기하는 것은 다른 문제다. 전자는 건강한 경계지만, 후자는 앞으로의 기회 비용이 커질 수 있다. 격차의 본질: AI-native인 사람은 AI를 업무, 학습, 창작, 의사결정에 계속 엮고, 그렇지 않은 사람은 같은 일을 더 느리고 좁은 도구 세트로 처리한다. 독서 비유: 책을 꾸준히 읽는 사람과 학교 이후 책을 멀리한 사람의 차이처럼, AI 사용 습관은 세계를 보는 방식과 가능한 행동의 범위를 바꾼다. 과신 금지: Miessler는 AI를 완벽하거나 신성한 대상으로 보지 말라고 한다. 도덕적 문제, 과사용 위험, 산업적 거품을 인정하되 도구적 가치는 붙잡아야 한다. 실천 지점: 자신과 가까운 사람을 AI-native camp로 옮기는 것, 즉 매일의 일에 AI를 실제로 연결해보게 하는 것이 중요하다. 1) AI 회의론이 틀렸다는 말이 아니다 이 글의 좋은 점은 AI 비판을 단순히 무지나 반기술 정서로 몰아가지 않는다는 데 있습니다. Miessler는 수천억 달러 규모의 자금이 AI 산업에 흘러들어가고 있고, 추론 비용이 아직 명확하지 않으며, 많은 기업과 투자자가 과장된 약속 위에서 움직이고 있다는 점을 인정합니다. ...

idlemachines의 The annotated PyTorch training loop는 PyTorch 학습 루프를 한 줄씩 해부하는 글입니다. 겉으로는 단순한 for 문처럼 보이지만, 실제로는 모델 상태, gradient buffer, autograd graph, optimizer state, scheduler state가 맞물려 돌아갑니다. 그래서 줄 하나가 조금만 엉뚱한 곳에 있어도 에러 없이 학습이 망가질 수 있습니다. 원문: The annotated PyTorch training loop PyTorch 핵심 정리 핵심 순서: model.train() -> zero_grad() -> forward -> loss -> backward() -> clipping -> optimizer.step() -> scheduler.step() -> model.eval() + no_grad()가 기본 골격이다. 가장 위험한 점: 잘못된 위치의 코드가 항상 예외를 내지는 않는다. 학습이 안 되거나, 너무 느리거나, 메모리가 계속 늘어나는 형태로 드러난다. 역할 분리: loss.backward()는 .grad를 채우고, optimizer.step()은 weight를 바꾼다. 이 둘을 같은 일로 보면 루프를 잘못 고치기 쉽다. 검증 루프: model.eval()은 레이어 동작을 바꾸고, torch.no_grad()는 graph 생성을 막는다. 검증에는 보통 둘 다 필요하다. GPU 효율: 모델과 batch를 같은 device에 두고, mixed precision, pinned memory, prefetch, torch.compile을 상황에 맞게 적용해야 GPU가 놀지 않는다. 1) 학습 루프는 작은 상태 머신이다 PyTorch 학습 코드는 보통 이렇게 생겼습니다. ...

The Founder’s Playbook: Building an AI-Native Startup은 Anthropic 팀이 2026년 5월에 발간한 문서로, AI를 기술과 조직 개발의 중심에 두는 스타트업의 새로운 생애주기를 정의한다. 기존 스타트업 성장 곡선이 validate → raise → hire → build의 반복이었다면, 이제 AI는 각 단계에서 요구되는 팀 규모와 자금 조달의 기대를 크게 낮춘다. 좋은 아이디어가 실행으로 이어지는 거리가 극적으로 짧아졌다. 원문: The Founder’s Playbook PDF TL;DR 핵심 정리 42%의 실패 원인: “아무도 원하지 않는 것을 만든다” — agentic coding으로 프로토타입 제작이 쉬워지면서 검증 없이 빌드하는 위험이 오히려 증가한다. Idea 단계 종료 기준: 문제-해결 적합성(PSF). 실제 인간 대화에서 얻은 정성적 증거로 “누가, 얼마나 자주, 얼마나 심각하게 이 문제를 겪는가"를 구체적으로 답할 수 있어야 한다. MVP 단계의 진짜 목표: 제품-시장 적합성(PMF) 증거 수집. 완성도가 아니라 “사용자가 이 제품 없이는 안 될 정도로 가치 있게 느끼는가"가 관건이며, Sean Ellis 테스트에서 40% 이상이 “very disappointed"라고 답해야 의미 있는 신호다. CLAUDE.md의 역할: MVP부터 작성하는 아키텍처·스코프 컨텍스트 파일. 매 Claude Code 세션 시작 시 읽히며, AI 기술 부채와 구조적 일관성 붕괴를 막는 영속적 메모리 역할을 한다. Scale 단계 모트 구축: 창업자 도메인 지식을 제품에 주입하고, 사용자 행동 데이터 플라이휠과 워크플로우 락인을 통해 경쟁사가 2년 안에 복제할 수 없는 깊이를 만든다. 창업자 역할의 근본적 변화 과거 창업자는 실행자(technical founder는 코드 작성, non-technical은 영업·운영)였다. 2026년 AI-native 환경에서는 창업자가 에이전트 오케스트레이터로 이동한다. AI가 코드 작성, 시장 조사, 문서 초안, 워크플로 자동화를 담당하면서 창업자의 시간은 “무엇을 왜 만들 것인가"를 결정하고 시스템(에이전트 + 도구 + 소규모 팀)을 지휘하는 데 쓰인다. ...

The Signalist의 에세이 “The Dialogue Dividend"는 깊은 사고가 문을 닫고 노이즈 캔슬링 헤드폰을 끼는 고립된 상태에서만 가능하다는 지배적인 모델에 도전합니다. 저자는 특정 동료와의 우연한 대화가 오랫동안 고민하던 문제를 순식간에 풀어주는 경험을 반복하면서, 답을 알려주지 않는 상대와의 교환 자체에서 혼자서는 만들어낼 수 없는 사고가 발생한다는 사실을 관찰했습니다. 원문: The Dialogue Dividend Dialogue Dividend 핵심 정리 정밀성 강제: 생각을 소리 내어 말하면 모호한 인상이 주어와 술어를 갖춘 평가 가능한 문장으로 변환되어 내부 독백보다 높은 정밀성을 요구한다 (Self-Explanation Effect). 실시간 교정 루프: 청자의 미간 찌푸림, 질문, “나도 본 적 있다"는 반응이 사고의 드리프트를 즉시 바로잡는다. 기계적 주의 신호만으로는 이 효과가 충분하지 않다 (Robot Duck Debugging 연구). 추론의 사회적 기원: Hugo Mercier와 Dan Sperber의 주장 이론에 따르면 인간의 추론 능력은 고립된 진실 발견이 아니라 집단 내에서 논증을 만들고 평가하기 위해 진화했다. 확장된 인지 시스템: Vygotsky의 근접 발달 영역(ZPD)과 Clark & Chalmers의 Extended Mind 이론은 타인이 단순한 청중이 아니라 사고를 함께 생산하는 인지 인프라임을 보여준다. 보이지 않는 배당: 부엌에서의 짧은 대화가 6개월 뒤 중요한 협업에서 이미 쌓인 관계와 맥락을 제공한다. 대부분의 배당은 투자하지 않으면 존재하지 않는 것처럼 느껴진다. 현대 환경의 침식: 원격 근무, 비동기 우선 통신, 헤드폰 기본 착용, 생성형 AI는 비계획적 교환의 조건을 체계적으로 제거하고 있다. 성과 지표는 당분간 유지되지만 이해와 신뢰는 조용히 약화된다. AI의 동조 문제: LLM은 사용자가 제시한 프레임에 빠르게 동조한다. 3인칭 관점이나 반대 의견을 명시적으로 요구하는 프롬프트로 지연시킬 수는 있지만, 동료처럼 자발적 pushback을 지속적으로 제공하지는 않는다 (SYCON 벤치마크). 1. 지배적인 사고 모델과 그 한계 진지한 사고의 표준 모델은 고독입니다. Deep work는 문을 닫고, 상태를 busy로 바꾸고, 헤드폰을 쓰는 순간에 일어난다고 여겨집니다. 미팅은 조율 비용으로, 대화는 이미 생각을 마친 후에 하는 것으로 취급됩니다. ...

Matt Sayar의 글 Yes, we still need engineers는 Claude Code 같은 AI 코딩 도구가 프로토타입 제작을 얼마나 빠르게 만들었는지 인정하면서도, 그 결과물이 곧바로 프로덕션 품질의 소프트웨어가 되는 것은 아니라고 말합니다. 핵심은 “AI가 코드를 빨리 만든다"와 “소프트웨어가 실제 사용자에게 안전하게 운영된다” 사이에는 여전히 넓은 엔지니어링 간극이 있다는 점입니다. 이 글은 원문의 주장을 바탕으로, AI 프로토타입과 프로덕션 엔지니어링의 차이를 한국어 독자를 위해 정리한 글입니다. 핵심 정리 프로토타입은 커뮤니케이션 도구다: AI로 만든 데모는 아이디어를 빠르게 보여주고 팀의 이해를 맞추는 데 강력하지만, 운영 가능한 제품과는 거리가 있다. 제품화에는 보이지 않는 작업이 많다: 백엔드 지원, 회귀 테스트, 기능 테스트, 보안 테스트, 성능 검증, 접근성, 권한 처리, 유지보수성 같은 요소가 필요하다. 운영 책임은 코드 생성보다 넓다: 로깅, 모니터링, 알림, 배포와 롤백, 장애 대응, 데이터 무결성, 규제 준수, 감사 추적까지 고려해야 한다. 엔지니어의 역할은 사라지지 않고 이동한다: 자동화는 반복적인 코드 작성을 줄이고, 엔지니어가 문제 정의와 시스템 품질, 운영 책임에 더 집중하게 만든다. AI 프로토타입은 왜 매력적인가 AI 코딩 도구를 사용하면 기존 UI 저장소를 복제한 뒤, 버튼 추가나 테스트 데이터 구성, 워크플로 데모 녹화 같은 작업을 매우 빠르게 진행할 수 있습니다. Loom 영상으로 보여주기에 충분한 데모를 만드는 속도는 과거보다 크게 빨라졌습니다. ...

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) 코드 작성은 싸졌고, 이해는 그대로 비싸다 과거 코드 리뷰는 속도의 균형 위에 있었습니다. 주니어가 코드를 작성하는 속도보다 시니어가 읽는 속도가 빨랐기 때문에, 리뷰는 자연스럽게 병목이 되지 않았습니다. 하지만 에이전트는 이 균형을 깨뜨립니다. ...

AI가 소프트웨어 엔지니어를 대체할 것이라는 전망이 끊임없이 제기되지만, 실제 데이터는 정반대의 그림을 보여주고 있습니다. AI 적용이 가장 빠르고 앞선 분야인 소프트웨어 엔지니어링에서조차 대규모 해고나 노동력 감소는 일어나지 않았으며, 그 이유는 단순히 AI의 능력 부족이 아니라 소프트웨어 개발이라는 작업의 근본적인 구조 에 있습니다. TL;DR 요약 AI 해고는 대부분 AI 워싱 : Block, Snap, Intuit 등 유명 기업의 해고 사례 분석 결과 실제 원인은 재정 압박과 구조조정이었으며, 뉴욕주 WARN Act에서 AI 관련 체크박스를 사용한 사례는 0.2%에 불과하다. Decide-Execute-Deliver Sandwich : AI는 중간의 Execute(코딩)만 압축했을 뿐, 양 끝의 Decide(무엇을 만들지 결정)와 Deliver(테스트·검증·배포·책임)는 여전히 인간의 깊은 맥락 이해가 필요하다. 코딩은 전체 업무의 일부에 불과하다 : 개발자들이 실제로 코딩에 사용하는 시간은 9~61% 수준이며, 나머지는 미팅·디버깅·코드베이스 이해 등에 소요된다. 미국 소프트웨어 엔지니어 고용은 여전히 성장 중 : AI 이후 성장률이 다소 둔화되었을 뿐, 절대 고용 수치는 감소하지 않았다. 원문: Why AI hasn’t replaced software engineers, and won’t ...