Systems Thinking

Warp 창업자이자 전 Google Docs 수석 엔지니어인 Zach Lloyd는 글 The guide to software factories에서 소프트웨어 개발의 다음 변화를 설명한다. 개발자가 터미널에서 코딩 에이전트를 직접 조종하는 방식에서, 이슈 분류부터 배포와 모니터링까지를 클라우드에서 자동으로 흘려보내는 클라우드 소프트웨어 팩토리로 이동한다는 주장이다. Factory 핵심 정리 핵심 변화: 대화형 에이전트를 개발자별 도구로 두는 대신, SDLC 전체를 하나의 자동화 루프로 연결한다. 자동화 범위: 원문에서 소개한 Warp 팀의 경험으로는 전체 PR의 약 20~30%를 자동화하고 있으며, 완전 자동화가 어려운 작업도 리뷰·검증·모니터링은 자동화할 수 있다. 세 계층: 클라우드 런타임·샌드박스, 오케스트레이션·통합·사람 개입, 측정·평가·메모리로 구성된다. 경영 관점: 토큰 사용량이 아니라 실제 출시된 제품과 비용의 비율로 에이전트의 사업 가치를 측정해야 한다. 도입 원칙: 사람의 개입 경로를 남기고, 여러 모델·하네스를 지원하며, 데이터·컴퓨트·추론 엔드포인트의 선택권을 보존해야 한다. 대화형 코딩 에이전트만으로는 부족하다 Copilot, Cursor, Claude Code 같은 도구를 개발자에게 배포하는 일은 AI 도입의 좋은 출발점이다. 실제로 많은 조직이 먼저 모든 엔지니어에게 도구를 제공하고, 사용량과 도입률을 추적하며, 토큰을 많이 쓰는 팀을 격려했다. 새로운 기술을 현장에 빠르게 퍼뜨리는 단계에서는 합리적인 접근이다. ...

프린스턴 대학의 Arvind Narayanan이 ICML 2026 키노트에서 던진 질문은 단순하다. AI 능력이 계속 올라갈 때, 우리에게 남은 일은 무엇인가? 그는 이 불안을 정면으로 다루며 AI as Normal Technology 프레임워크를 중심으로 세 가지 주장을 펼친다. 첫째, 재귀적 자기개선 같은 불연속성이 오기 전까지 이 프레임은 유효하다. 둘째, 랩에서 어떤 마일스톤을 달성해도 그것이 곧바로 전면 실업을 만들지 않는다. 셋째, 미래 직업은 지금과 근본적으로 달라지므로 대규모 적응이 필요하다. TL;DR 핵심 정리 AI as Normal Technology: AI는 산업혁명급 변환 기술이지만, 경제적 영향은 능력 → 제품 → 초기 채택 → 조직 적응의 네 단계를 거치며 적응은 수십 년이 걸린다. 능력-신뢰성 격차: 최근 24개월 프론티어 모델에서 accuracy는 크게 올랐으나 reliability는 5~10%p 수준만 개선되어, 완전 자동화보다 협업 에이전트가 당분간 더 성공적이다. Decide-Execute-Deliver: AI는 중간 Execute(코딩 등)만 압축하고, 양 끝의 결정·기획과 검증·책임은 오히려 확장될 수 있다. 역할 이동: 검증 가능한 구축 작업은 AI로 넘어가고, 인간의 핵심 역할은 평가·조향·판단·취향으로 이동한다. 목표: 랩의 마일스톤에 굴복하는 것이 아니라, AI를 정신의 크레인으로 쓰는 공초지능(co-superintelligence)을 향해 통제권을 유지하는 것이다. 원문: What will be left for us to work on? 주석 슬라이드: ICML 2026 annotated slides ...

Lilian Weng의 글 Harness Engineering for Self-Improvement는 AI 자기개선을 모델 가중치의 문제로만 보지 않는다. 모델 주변에서 실행을 조율하는 하네스, 즉 도구 호출, 메모리, 워크플로, 권한, 평가 루프까지 포함한 시스템이 가까운 미래의 핵심 개선 대상이라는 주장이다. Harness 핵심 정리 하네스의 역할: 베이스 모델이 어떻게 생각하고, 어떤 도구를 쓰고, 무엇을 기억하고, 어떤 결과를 통과시킬지 정하는 실행 시스템이다. 가까운 경로: 자기개선은 모델이 곧장 자기 가중치를 수정하는 장면보다, 하네스와 연구 파이프라인을 개선하는 형태로 먼저 올 가능성이 크다. 중요 패턴: 워크플로 자동화, 파일 시스템 기반 장기 기억, 서브에이전트와 백엔드 작업 관리가 반복해서 등장한다. 최적화 대상: 프롬프트에서 구조화 컨텍스트, 워크플로, 하네스 코드, 옵티마이저 코드로 점점 내려간다. 현실적 한계: 평가가 흐릿한 영역에서는 보상 해킹, 실패 은폐, 다양성 붕괴, 장기 유지보수 비용을 피하기 어렵다. 1) 하네스는 프롬프트보다 실행 시스템에 가깝다 초기 에이전트 설명은 보통 LLM + memory + tools + planning + action 같은 공식으로 끝났다. Weng은 여기에 한 층을 더 얹는다. 실제 제품에서 중요한 것은 모델에게 좋은 말을 건네는 것만이 아니라, 모델이 어떤 루프 안에서 관찰하고, 실행하고, 실패를 기록하고, 다시 시도하게 만드는가다. ...

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

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 ...

Jordan Cutler(Pinterest Staff Engineer)가 Senior에서 Staff Engineer로 성장하는 데 필요한 마인드셋 변화 와 실전 사례를 정리한 글입니다. Staff Engineer는 단순히 더 깊은 기술력이나 빠른 실행력이 아니라, 다른 차원의 영향력 을 발휘하는 역할이라는 점을 강조합니다. 원문: How to Grow From Senior to Staff Engineer in the AI Era TL;DR 요약 핵심 전환: Senior → Staff는 “내가 더 많은 코드를 쓰는 것"에서 “다른 사람들이 더 많은 일을 할 수 있게 만드는 것"으로의 전환이다. Surface Area 확장: 주어진 업무 외에 자발적으로 기회를 만들고 가치를 먼저 증명하면 조직적 영향력이 따라온다. 팀 간 영향력: 문제만 지적하지 말고, 데이터 + 구체적 해결책 + 도움 제안을 함께 전달해야 신뢰와 실행을 이끌어낸다. 확장 가능한 시스템: 내가 없어도 돌아가고, 다른 팀까지 자연스럽게 확장되는 시스템을 구축하는 것이 multiplier의 본질이다. AI 시대 함의: Heads-down 코딩에서 벗어나 영향력과 시스템을 만드는 multiplier 사고가 더 중요해졌다. Staff Engineer가 되는 데 방해가 되는 것 기술 깊이, 실행 속도, 복잡한 시스템에만 집중하는 것 “개인 기여” 중심 사고에서 벗어나지 못함 Staff로 성장하지 못하는 엔지니어들의 공통점은 기술 역량 자체가 부족해서가 아니라, 그 기술을 조직 전체로 확장하지 못한다는 점입니다. ...

이 글은 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 ...

Dr. Milan Milanović의 뉴스레터 글 **“The 20 Software Engineering Laws”(2026-04-23)**는 소프트웨어 실패를 “예외"가 아니라 “반복 가능한 패턴"으로 보게 해주는 체크리스트입니다. 아래는 원문의 20개 법칙을 빠르게 의사결정에 쓸 수 있도록 압축한 정리입니다. 원문: The 20 Software Engineering Laws 20 Laws 핵심 정리 이 글의 본질: 법칙은 “무엇을 해야 하는가"보다 “이미 어떤 일이 벌어지고 있는가"를 설명하는 진단 프레임이다. 실무 고빈도 함정: 늦은 프로젝트에 인원 추가(Brooks), KPI를 목표화해 왜곡 유도(Goodhart), 낙관 일정 산정(Hofstadter)이 반복된다. 설계 원칙: 작게 시작해 점진 진화(Gall), 단순성 우선(KISS), 장애를 기본값으로 설계(Murphy·Postel·CAP). 팀 운영 원칙: 팀이 커질수록 개인 생산성 저하(Ringelmann), 소수 핵심 인력 집중(Price), 과잉 자신감 리스크(Dunning-Kruger) 관리가 필요하다. 결론: 20개 법칙은 아키텍처·조직·일정·품질·스케일링 의사결정에서 “미리 실패 비용을 줄이는 안전장치"로 써야 한다. 1) 시스템이 만들어지는 방식 Gall’s Law: 동작하는 복잡계는 항상 먼저 동작한 단순계에서 진화한다. KISS: 단순함을 유지하라. 불필요한 복잡성은 미래 장애 비용이다. Conway’s Law: 조직의 커뮤니케이션 구조가 시스템 구조를 복제한다. Hyrum’s Law: API의 관측 가능한 모든 동작은 결국 누군가의 의존성이 된다. CAP Theorem: 분산 시스템은 일관성·가용성·분할 허용성 중 2개만 강하게 보장 가능하다. Zawinski’s Law: 소프트웨어는 기능 팽창 경향을 가진다. 실무 해석: 리라이트/플랫폼 전환 시 “완벽 설계"보다 “작은 성공 루프"를 먼저 만든다. ...

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

Peter Szász가 “엔지니어링 매니저(EM) 역할에 에이전트를 적용하면 어떻게 될까?“라는 사고 실험을 통해 기회와 리스크를 동시에 드러내는 글입니다. 코드 완성에서 에이전틱 엔지니어링으로 넘어가는 흐름이 매니지먼트 영역까지 확장될 수 있는지 탐색합니다. 원문: Agentic Engineering Management TL;DR 요약 에이전트 정의: 사용자 프롬프트로부터 목표 달성까지 “도구 호출 → LLM 평가” 루프를 자율적으로 반복하는 시스템. EM 분해: Execution(실행), Team Dynamics(팀 다이내믹스), Personal Development(개인 성장) 3축. 위로 갈수록 사람과의 거리는 가깝고 리스크는 높아진다. 두 평가 축: ① Autonomy Fitness — 반복성·데이터 풍부도·모호성·가역성. ② Trust Gradient — 개인적일수록 신뢰 리스크 증가. 하네스 설계: confidence threshold, dry-run, blast radius limit, reversibility, audit trail로 자율성 강도 조절. 결론: 신뢰가 깨지면 매니지먼트는 무너진다. 그러나 하네스 설계가 없으면 EM은 “풀타임 에이전트 베이비시터"가 된다. 핵심 정의 Agent: 초기 프롬프트에서 시작해 목표가 충족될 때까지 도구 호출과 LLM 평가를 반복하는 루프. Engineering Management: 비즈니스 목표에 부합하는 결과(outcome)를 전달하도록 팀을 이끄는 일. EM의 일은 세 가지로 분해된다: ...