탈동조화의 함정: AI 슬롭이 신호를 덮어버릴 때
저자는 서로 맞지 않거나 중복되는 모델이 쌓여 변경 비용을 키우는 상태를 ‘탈동조화(decoherence)’라고 부릅니다. AI 에이전트가 코드 변경을 빠르게 늘리면서 이 복잡성을 함께 키우면 기능 개발이 막힐 수 있으며, 실제 세계의 검증 없이 AI가 스스로 개선되는 시나리오도 이 문제에 부딪힌다고 주장합니다.
개발 · 최신기사
언어와 프레임워크, SDK와 개발 방식·도구의 변화를 다룹니다.
변화를 전제로 설계하기
AI 도구로 코드 작성 비용이 낮아지면서 코드의 장기 보존보다 쉽게 교체할 수 있는 구조가 중요해진다고 주장합니다. 자주 바뀌어도 되는 코드와 핵심 영역을 구분하고, 경계의 계약과 테스트를 갖춰 핵심부의 계획되지 않은 변경을 줄이는 설계 원칙을 제안합니다.
내가 쉬는 동안 AI는 나아졌지만, 소프트웨어는 그대로입니다
AI 모델과 코딩 에이전트는 더 많은 코드를 빠르게 만들지만, 과잉 설계와 불필요한 기능 같은 소프트웨어의 문제까지 해결하지는 않습니다. 글쓴이는 코드 작성보다 문제를 제대로 정의하고, 생성된 결과를 검토하며, 필요 없는 복잡성을 덜어내는 판단력이 더 중요해진다고 말합니다.
오래 쓰이는 소프트웨어는 천천히 만들어집니다
Zotero는 연구자들이 필요한 기능을 함께 고민한 끝에 탄생했습니다. 구상부터 초기 프로토타입까지 수년이 걸린 과정을 돌아보며, AI가 코딩을 빠르게 해도 무엇을 만들지 정하는 일에는 탐색과 협업이 필요하다고 설명합니다.
타입클래스와 모듈은 서로 다른 문제를 풉니다
타입클래스는 여러 타입에 같은 연산 이름을 쓰는 임의 다형성을, 모듈 시스템은 프로그램을 인터페이스와 구현 단위로 나누는 모듈 추상화를 목표로 합니다. 글은 두 기능의 차이를 예시와 언어별 구현으로 설명하며, 작성자는 대규모 프로그램을 구성할 때 모듈 추상화를 더 중시합니다.
구현은 판단이 보이지 않게 바뀌는 곳입니다
댓글 응답 추적 도구의 세 가지 버전은 18명, 34명, 2명이라는 서로 다른 수를 냈지만 각자 다른 기준에 따라 정확히 셌습니다. 테스트와 측정값이 맞더라도 범위, 비교 대상, 데이터 수집 위치 같은 판단이 구현에 묻히면 독자는 다른 질문의 답을 받습니다.
사용자가 직접 바꾸는 소프트웨어: 잠긴 앱에서 주도권 되찾기
Ink & Switch는 사용자가 필요에 맞게 소프트웨어를 고쳐 쓰는 생태계를 ‘malleable software’라고 부릅니다. 앱 중심 구조를 공유 데이터와 조합 가능한 도구로 바꾸고, 사용에서 제작까지의 학습 장벽을 낮추는 설계 원칙과 연구 프로토타입을 소개합니다.
좋은 소프트웨어 조언은 왜 따르기 어려울까요
작은 함수나 의미 있는 변수명처럼 실행 여부를 쉽게 확인할 수 있는 규칙과, 상황에 따라 판단해야 하는 원칙을 구분합니다. 경험은 규칙 사이의 충돌과 추상화의 비용을 가늠하는 판단력을 키우며, 좋은 엔지니어는 규칙을 외우는 데서 원칙을 적용하는 단계로 나아간다고 설명합니다.
결합도와 응집도로 돌아가기 — 소프트웨어 설계 원칙을 수치로 읽는 방법
SOLID, DRY, KISS 같은 설계 원칙을 따로 암기하기보다 결합도와 응집도를 관리하는 문제로 바라보자고 제안합니다. 실제 작업에서 변경에 관여한 컴포넌트와 관심사의 노력 분포를 기록해 결합도와 응집도를 계산하고, 같은 프로젝트의 변화 추적과 기술 부채 작업의 근거로 활용하는 방법을 설명합니다.
결정론적 코어, 비결정론적 셸
Functional Core/Imperative Shell 구조를 결정론적 코어와 비결정론적 셸로 확장해 설명합니다. 외부 세계와 맞닿은 코드를 셸에 모으고 비즈니스 로직을 결정론적으로 분리하면, 순수 함수형 프로그래밍을 쓰지 않아도 테스트 범위와 신뢰도를 높일 수 있다고 제안합니다.