Cursor는 변경을 싸게 만들지만, 신뢰는 여전히 비싸다.
Cursor makes change cheap. Confidence is still expensive.
핵심 요약
AI로 코딩 속도는 빨라졌지만, 코드에 대한 신뢰가 무너지는 부작용에 대한 고민.
- 코드 신뢰도 저하 — AI로 변경은 쉬워졌으나 코드의 안정성에 대한 확신은 점점 줄어듦.
- 테스트의 중요성 — 자동화된 회귀 테스트 없이는 AI가 만든 코드의 부작용을 감당하기 어려움.
- 개발 프로세스 변화 — 속도에만 집중하다 보면 코드베이스에 엔트로피가 쌓여 수정이 두려워짐.
- 검증의 병목 현상 — AI가 코드를 생성하는 속도보다 이를 검증하는 과정이 더 큰 병목이 됨.
FE 개발자로서 10년 넘게 일해왔습니다. AI를 반대하는 입장은 아닙니다. 저도 변화를 받아들였고, 1년 넘게 매일 Cursor를 사용하며 그 잠재력을 사랑합니다. 하지만 현업에서 계속 마주치는 한 가지 문제가 있습니다.
제품은 겉으로 계속 좋아지지만, 그 밑바닥에서는 신뢰가 조용히 무너지고 있습니다.
작은 변경을 요청합니다. 잘 작동합니다. 그런데 인접한 무언가가 이상하게 작동하기 시작합니다.
버튼은 제대로 보이지만 클릭이 안 됩니다. 폼은 여전히 렌더링되지만 제출이 안 됩니다. 사소한 UI 수정이 건드리지도 않은 다른 동작을 조용히 망가뜨립니다. 그래서 매번 푸시하기 전에 앱을 다시 클릭하며 확인하고, 반쯤은 확인하고 반쯤은 기도하게 됩니다.
그 전체 워크플로우는 이런 느낌입니다:
prompt
apply
click around
ship
pray
panic when something unrelated is suddenly broken
Opus 4.5 이전까지는 "AI가 그냥 코드를 못 짜는 것"이라고 생각했습니다. 이제는 그런 변명도 통하지 않습니다.
제 생각에 진짜 문제는 AI가 변경을 극도로 싸게 만들었지만, 신뢰는 여전히 비싸다는 점입니다.
이제 더 많은 코드, 더 많은 리팩토링, 더 많은 로컬 수정, 더 많은 "작동하는" 기능을 생성하기는 매우 쉽습니다. 하지만 그 루프 속에서 무엇이 유지되어야 하는지 고민하게 만드는 장치는 없습니다.
그래서 코드베이스에 엔트로피가 스며들기 시작합니다:
- 앱은 여전히 대부분 작동하지만, 매주 신뢰도는 떨어집니다.
- 여전히 배포는 가능하지만, 무언가를 건드리는 것이 점점 더 두려워집니다.
- 테스트 코드가 있을지 모르지만, 실제 보호막처럼 느껴지지 않습니다.
- 한 세션에서 로컬 문제를 해결하면, 다음 세션에서 조용히 그 위에 오류가 쌓입니다.
이것이 AI 보조 개발을 이야기할 때 사람들이 놓치는 부분이라고 생각합니다. 고통은 단순히 버그가 아닙니다. 신뢰가 서서히 사라지는 것입니다.
더 이상 단단한 기반 위에 건물을 짓는다는 느낌이 들지 않습니다. 제품의 중요한 부분을 명시적으로 보호하는 장치가 없기 때문에 모든 변경 사항을 일일이 돌봐야 한다는 느낌을 받기 시작합니다.
그러니 "그냥 더 빨리 하라"는 말로는 부족합니다. 중요한 동작을 고정하는 장치가 없다면, 속도는 불확실성을 더 빨리 퍼뜨릴 뿐입니다.
저에게는 이제 더 많은 코드를 생성하는 것이 아니라, 코드베이스가 제가 건드리기 두려운 무언가로 조용히 변해가는 것을 막는 것이 진짜 병목입니다.
푸념은 여기까지입니다. 여러분도 똑같이 느끼시는지, 아니면 코드베이스가 커질수록 신뢰가 무너지는 것을 막는 더 좋은 방법을 찾으셨는지 궁금합니다.
이 긴장감에 대해 제 블로그에 더 자세한 글을 썼으니 원문을 보고 싶으신 분들은 확인해 보세요:
https://www.abelenekes.com/p/when-change-becomes-cheaper-than-commitment
