Second-Order Effects

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이 가시권에 들어왔다고 합니다. 매출은 빠르게 커졌지만, 청구 시스템은 훨씬 작은 회사였을 때의 방식에 머물러 있었습니다. ...

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

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

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: 소프트웨어는 기능 팽창 경향을 가진다. 실무 해석: 리라이트/플랫폼 전환 시 “완벽 설계"보다 “작은 성공 루프"를 먼저 만든다. ...

AI 보조 도구가 등장했음에도 불구하고 왜 대부분의 개발 팀이 여전히 생산성 혁신을 경험하지 못하는지, 그 근본적인 원인을 ‘거대한 필터(The Great Filter)’ 라는 개념으로 설명하는 글입니다. 원문: The Great Filter, or Why High Performance Still Eludes Most Dev Teams Even With AI 주요 내용 1. AI 생산성 역설 (The Gorman Paradox) AI 코딩 도구가 보급된 지 3년이 넘었지만, 앱 스토어의 제품 출시가 폭증하거나 기업의 이익, 국가 GDP가 눈에 띄게 상승하는 현상은 나타나지 않고 있습니다. AI는 분명 ‘코드’를 더 많이 만들어내지만, 대다수 팀에게 그것이 ‘순 가치’의 증가로 이어지지 않고 있습니다. 2. 고성과 팀과 저성과 팀의 차이 ...

이 글은 슈퍼마켓에서 최소 임금을 받으며 일하던 시절, 바닥 청소 경로를 최적화하려다 깨달은 “잘못된 지표를 최적화하면 기술적으로는 완벽해 보여도 실제로는 쓸모없거나 해로운 결과를 낳는다” 는 교훈을 담는다. 원문: I Got Paid Minimum Wage to Solve 1. 문제의 시작: 단순한 작업의 복잡화 작성자는 슈퍼마켓 바닥을 쓸면서 “어떻게 하면 가장 적게 걷고도 모든 바닥을 다 쓸 수 있을까?“라는 의문을 갖게 된다. 이를 해결하기 위해 매장 내부를 그리드 그래프(Grid Graph)로 변환하고, 시뮬레이티드 어닐링(Simulated Annealing) 알고리즘을 사용해 최단 경로를 찾는 C++ 프로그램을 작성한다. 2. 알고리즘의 한계: ‘기술적 정답’과 ‘실제 유용성’의 괴리 알고리즘은 수학적으로 완벽한 최단 경로를 찾아낸다. 하지만 그 결과는 사람이 도저히 따라 할 수 없는 ‘미친 듯한 경로’ 다. 단순히 거리(Distance)만 최적화했더니, 알고리즘은 수많은 급회전과 지그재그 경로를 만들어낸다. 사람은 직진할 때 가장 편안함을 느끼는데, 알고리즘은 이를 고려하지 않은 것이다. 결국 회전할 때마다 ‘페널티’를 부여하는 조건을 추가한 뒤에야 비로소 사람이 걸을 만한 효율적인 경로가 나온다. 3. 더 큰 깨달음: 현대 사회의 최적화 오류 작성자는 이 경험을 통해 오늘날 많은 시스템이 ‘잘못된 지표’를 최적화 하고 있다고 비판한다. ...

이 글은 최근 AI 도구(Cursor, Replit 등)를 활용해 코드를 빠르게 짜는 이른바 ‘바이브 코딩(Vibe Coding)’ 열풍 속에 숨겨진 위험성을 경고한다. 원문: Vibe Coding Without System Design is a Trap 1. 바이브 코딩(Vibe Coding)의 함정 정의: 정밀한 설계나 구조에 대한 고민 없이, AI에게 자연어로 지시하며 “느낌대로(vibe)” 결과물을 빠르게 만들어내는 방식이다. 문제점: 초기 데모나 프로토타입을 만드는 속도는 매우 빠르지만, 시스템 설계(System Design)가 결여되어 있어 실제 서비스화(Production) 단계에서 큰 벽에 부딪히게 된다. 2. ‘운영의 벽(The Operational Wall)’ 글쓴이는 프로토타입과 실제 제품 사이에는 거대한 간극이 존재한다고 강조한다. AI는 다음의 요소들을 자동으로 해결해 주지 않는다. ...