이 농담이 먹히는 이유는 그냥 농담이 아니기 때문이다
Meteor development라고 부르자. 종착지는 먼저 발표되고, 정거장은 중간에 바뀌고, 예산은 알아서 맞추라는 전제가 깔리고, 엔지니어링 조직은 열차가 이미 “곧 출발”한다고 여겨지는 상태에서 선로를 깔아야 하는 진행 방식이다.
이 밈이 웃긴 이유는 실제 팀에서 너무 자주 벌어지는 일이라서다.
창업자는 edge case도 안 나온 feature를 먼저 약속하고, 프로덕트 팀은 design이 이미 지나간 뒤 onboarding flow를 다시 그리고, 경영진은 AI가 지난 screen을 그렇게 빨리 만들었으니 integration 하나쯤 더 붙이는 건 쉽다고 생각한다. route는 계속 움직이는데 마감만 그대로다.
나쁜 소식은 어떤 architecture pattern도 사람들의 비현실적인 기대 자체를 막아주지는 못한다는 점이다.
좋은 소식은 그 비현실적인 기대가 더 이상 엔지니어링 마비로 바로 이어질 필요는 없다는 점이다.
진짜 고통은 기대치 문제만이 아니다
엉성한 계획은 분명 짜증 난다. 시간을 태우고, 압박을 키우고, 계속 협상을 만들기 때문이다. 하지만 그것만으로 진행이 무너지지는 않는다.
진행을 진짜 망가뜨리는 건 늦게 들어온 product change 하나하나가 전체 시스템 리스크가 되는 순간이다.
이게 바로 빠른 AI-generated codebase에서 반복되는 failure mode다. version one이 너무 빨리 ship되면, 모두가 다음 change도 그만큼 빨라야 한다고 믿기 시작한다. 그리고 현실이 온다.
- auth provider를 바꿔야 한다
- analytics를 optional로 내려야 한다
- deep link path 하나가 틀려 있다
- styling 결정 하나가 40개 screen으로 퍼져 있다
- “작은” feature 하나가 서로 상관없는 세 module을 가로지른다
그 순간 팀이 상대하는 것은 비현실적인 기대만이 아니다. 변화를 국소적으로 흡수하지 못하는 codebase까지 동시에 상대해야 한다.
이게 이중 과세다. 조직 문제만으로도 충분히 어려운데, 기술 문제가 그것을 더 증폭시킨다.
Meteor development가 먼저 부수는 것은 brittle한 코드베이스다
그래서 이 밈이 엔지니어에게 정확히 꽂힌다.
우리는 모두 같은 pattern을 봤다.
- map이 완성되기 전에 route가 발표된다.
- implementation이 시작된 뒤에도 범위가 계속 불어난다.
- 발표 자료 위 마감은 그대로다.
- engineering은 “그냥 적응하라”는 말을 듣는다.
system boundaries가 약하면, 여기서 말하는 “적응”은 실제로 이런 뜻이 된다.
- 아무도 설계하지 않은 AI-generated abstraction을 reverse-engineer한다
- 서로의 내부 implementation을 건드리는 module을 풀어낸다
- 건드릴 생각도 없던 곳에서 터진 regression을 고친다
- 원래 보존하면 안 되는 implementation을 살리느라 일주일을 쓴다
그 시점의 팀은 product를 build하는 게 아니라 마감 아래에서 archaeology를 하는 중이다.
이건 더 이상 받아들일 필요가 없다.
Autotomy는 failure mode를 바꾼다
Autotomy는 환상적인 추정을 현실로 만들지 않는다. 대신 더 유용한 일을 한다. system을 replaceable하게 유지한다.
아이디어는 단순하다. 어떤 module이 틀렸거나 늦었거나 더 이상 현재 route에 맞지 않으면, 잘라내고, 교체하고, 계속 전진할 수 있어야 한다.
그러려면 몇 가지 양보할 수 없는 전제가 필요하다.
- auth, analytics, storage, notifications 같은 변하기 쉬운 service 앞에 interface를 둔다
- app이 실제로 어떤 implementation을 쓸지 하나의 composition root에서 결정한다
- screen이 vendor details를 직접 import하지 못하게 dependency boundaries를 둔다
- module을 교체해도 동작을 지키도록 contract tests와 deterministic checks를 둔다
- optional tools가 launch-critical infrastructure처럼 행동하지 않도록 dependency tiers를 나눈다
이것들이 갖춰지면 계속 움직이는 목표는 여전히 귀찮지만 더는 존재론적 위기가 아니다.
provider change는 interface 뒤의 replacement가 된다. product detour는 system-wide refactor가 아니라 local rewrite가 된다. 나쁜 AI-generated module은 조심스럽게 보존할 대상이 아니라 삭제하고 갈아끼울 대상이 된다.
route가 바뀌어도 development는 계속 갈 수 있다
이게 가장 실질적인 변화다.
Autotomy가 없는 Meteor development는 보통 이렇게 들린다.
“onboarding plan이 또 바뀌어서 auth, profile state, analytics, styling, navigation을 다 건드려야 합니다. 뭐가 깨질지 파악하는 데 일주일 주세요.”
Autotomy가 있으면 이렇게 바뀐다.
“기대는 여전히 비현실적이지만 change는 국소화되어 있습니다. app을 다시 짓는 대신 범위나 날짜를 다시 협상하면 됩니다.”
이건 훨씬 나은 실패 모드다.
물론 여전히 납기 약속에 반박해야 할 수도 있다. launch를 쪼개야 할 수도 있고, route에서 stop 하나를 빼야 할 수도 있고, last-minute branch line에 no라고 말해야 할 수도 있다. 하지만 개발 조직이 두 번 고통받을 필요는 없다. 사람 문제는 사람 문제로 남고, software 문제는 manageable하게 유지된다.
AI speed는 이 문제를 더 중요하게 만든다
요즘 Meteor development가 더 자주 보이는 이유 중 하나가 AI coding이다.
Cursor나 Claude Code가 몇 시간 만에 feature의 first version을 만들 수 있게 되면, 경영진은 이후 iteration도 전부 첫 드래프트만큼 빨라야 한다고 생각하기 시작한다. 그들이 보는 것은 표면적인 speed이지, change cost의 구조가 아니다.
현실은 다르다.
AI는 implementation을 채우는 데는 뛰어나다. 하지만 product reality가 바뀔 때 system을 구조적으로 안전하게 유지하는 책임까지 지지 않는다. codebase에 boundaries가 없으면 AI speed는 fragility에 도달하는 속도만 높여줄 뿐이다.
그래서 나는 같은 지점으로 돌아온다. AI-native development에 대한 올바른 반응은 더 낙관적이 되는 것이 아니라, 더 replaceable해지는 것이다.
빠르게 generate한다. boundaries를 enforce한다. deterministic하게 validate한다. route가 바뀌면 나쁜 module을 delete한다. 영향 범위를 local하게 가둔다.
환상인 부분은 여전히 우리가 처리해야 한다
어떤 framework도 계획 회의에 대신 들어가서 “그 출시일은 상상 속의 날짜입니다”라고 말해주지 않는다.
Autotomy는 우선순위 결정도, 희망사항이 섞인 로드맵도, 개발이 시작된 뒤 이해관계자가 map에 새 역을 그려 넣는 일도 막아주지 않는다.
그 부분은 여전히 엔지니어이자 어른으로서 우리가 처리해야 한다.
하지만 어려움은 그 정도로 끝나야 한다.
plan이 바뀔 때마다 같이 무너지는 codebase를 되살리는 일까지 맡을 필요는 없다.
Meteor development가 조직의 날씨처럼 계속 남는다면 그래도 괜찮다. 기대 관리에 대한 밈으로 남겨두면 된다.
Autotomy가 있다면, 그것이 엔지니어링 고통에 대한 밈까지 될 필요는 없다.