Cursor(애니스피어)가 B2B SaaS 역사상 가장 빠른 성장 기록을 세웠다. 출시 24개월 만에 ARR 10억 달러, 2026년 3월 기준으로는 20억 달러(약 3조 원)를 돌파했다. 마케팅 비용 0원에 전환율 36%. 일반 SaaS 전환율 2~5%와 비교하면 그야말로 이례적인 수치다. 제품이 스스로 마케팅을 한 셈이다. AI 코딩 도구가 개발자들에게 실제로 작동하고 있다는 가장 강력한 시장 증거다.
그런데 나는 이 숫자를 볼 때마다 동시에 다른 질문을 하게 된다. 팀의 코드베이스 이해도는 얼마나 빠져나가고 있나? 속도는 올라가고 있는데, 그 속도를 따라가는 '이해'는 제자리인가, 아니면 오히려 뒤처지고 있는가.
'이해 부채'라는 새로운 위험
dev.to에 올라온 글이 이 문제를 정확하게 짚는다. Addy Osmani가 명명한 개념, Comprehension Debt(이해 부채)다. 기술 부채와는 다르다. 기술 부채는 '나쁜 코드인 줄 알면서 쌓아두는 것'이다. 이해 부채는 더 무섭다. 자신이 모른다는 사실조차 모르는 상태다.
수치가 이미 현실을 보여준다. AI를 사용하는 개발자들은 복잡한 작업에서 실제로는 19% 더 느리지만, 본인은 20% 더 빠르다고 느낀다. GitClear가 2억 1,100만 줄의 코드를 분석한 결과, 리팩토링 비율은 10% 이하로 떨어진 반면 중복 코드는 48% 증가했다. AI가 생성한 PR은 코드 리뷰 대기 시간이 4.6배 길어졌고, 시니어 엔지니어들은 AI가 '절약해준' 시간의 30%를 AI가 만든 버그를 고치는 데 다시 쓰고 있다.
가장 섬뜩한 데이터는 따로 있다. Anthropic 연구에 따르면, AI에게 무조건 위임하는 방식("이 기능 구현해줘")으로 작업한 엔지니어들은 코딩 이해력이 17% 하락했다. 반면 AI를 사고 파트너로 쓴 개발자들("이 로직이 스케일에서 왜 깨지는지 설명해줘")은 오히려 점수가 올라갔다. 문제는 AI 도구가 아니라, 그 도구와 맺는 관계다.
18개월 절벽과 스파게티 포인트
AI 코딩에 과도하게 의존하는 팀에는 두 개의 시한폭탄이 있다. 첫 번째는 3개월 차 '스파게티 포인트', 두 번째는 18개월 차 '절벽'이다. 18개월이 지나면 코드베이스의 80~90%가 안티패턴으로 채워지고, 아무도 시스템 전체를 충분히 이해하지 못해 리팩토링 자체가 불가능해진다. 더 이상 아키텍처를 설계하는 게 아니라, 눈 감고 젠가 블록을 쌓는 것과 같다.
팀 상태를 진단하는 테스트는 간단하다. 내일 아침 Cursor와 Copilot을 끄면, 팀이 오후 전에 P0 장애를 디버깅할 수 있는가? 망설임 없이 "Yes"가 나오지 않는다면, 이미 안개가 깔린 것이다.
인터페이스 설계가 핵심이다
또 다른 각도의 분석도 주목할 만하다. AI 코딩 도구를 쓰는 방식 자체가 '이해 부채'를 만드는지 아닌지를 결정한다는 것이다. 두 가지 패턴이 있다.
처방형(Prescription): "React 로그인 컴포넌트 만들어줘. Tailwind 쓰고, 유효성 검증 붙여줘." 수렴조건형(Convergence Condition): "이 4개의 실패하는 테스트를 통과시켜줘."
같은 모델, 같은 도구인데 인지적 결과는 완전히 다르다. 처방형은 개발자가 이미 답을 결정해놓고 AI에게 타이핑을 시키는 것이다. 시스템에 대한 이해 없이도 코드가 나온다. 수렴조건형은 반대다. '완료'가 무엇인지 정의하려면 개발자가 시스템을 깊이 이해해야 한다. AI도 코드베이스를 추론해야 하고, 개발자도 함께 추론한다.
arXiv 연구(2603.22312)가 이를 뒷받침한다. 사전에 협업 프로토콜이 처방된 AI 에이전트는 스스로 패턴을 찾아낸 에이전트 대비 50.5% 낮은 성능을 보였다. 코딩도 마찬가지다. 경로를 처방하면, AI도 더 나쁜 결과물을 만들고 개발자의 판단력도 위축된다.
테크 리드가 지금 당장 바꿔야 할 것들
이 세 가지 문제—폭발적 도구 채택, 이해 부채 누적, 잘못된 인터페이스 패턴—는 서로 연결되어 있다. Cursor가 ARR 3조 원을 찍는 속도와 정확히 같은 속도로, 팀의 코드베이스 이해력이 공동화될 수 있다. 생산성 수치는 올라가고, 실제 역량은 내려가는 조용한 역설이다.
테크 리드 입장에서 당장 실행 가능한 방향은 세 가지다.
1. PR 리뷰 기준을 바꿔라. AI가 생성한 코드는 문법적으로 완벽하다. 그러니 리뷰는 로직이 아니라 의도를 검토해야 한다. 5분 안에 이해가 안 되는 PR은 반려한다. AI 생성 코드라면 반드시 인간이 작성한 'why' 주석이 붙어야 LGTM이다.
2. 프롬프트 패턴을 팀 표준으로 만들어라. "~만들어줘" 처방형 프롬프트를 제한하고, 테스트를 먼저 쓴 다음 AI가 구현하게 하는 수렴조건형을 기본 워크플로우로 정착시켜라. 판단은 사람이 하고, 타이핑은 AI가 한다.
3. ADR(아키텍처 결정 기록)을 살아있는 문서로 유지하라. AI가 코드를 생성할 때 ADR을 컨텍스트로 읽게 하면, 시스템 경계 밖의 코드가 생성되는 것을 막을 수 있다. Context Debt와 Integration Debt를 동시에 줄이는 가장 실용적인 방법이다.
Cursor의 성장은 AI 코딩 도구의 잠재력을 증명한다. 하지만 그 도구를 팀에 심는 방식을 설계하지 않으면, 속도는 얻고 역량은 잃는다. 소프트웨어 엔지니어링의 진짜 병목은 타이핑 속도가 아니라 시스템 이해였다. AI는 그 병목을 해결한 게 아니라, 우리가 그것을 우회했다는 착각을 줬을 뿐이다. 코드는 싸졌다. 이해는 여전히 비싸다.