여전히 코드를 읽으시나요? — AI 시대의 '가속자'와 '바이브코더'

본문

이 글은 '코드를 읽느냐'가 아니라 '아직도(still) 읽느냐'라는 질문에 이미 진보의 이론이 숨어 있다는 점에서 출발합니다. 전화번호 암기나 종이 지도처럼 코드 읽기도 사라져가는 기술이라는 전제가 담겨 있지만, 작동하는 애플리케이션을 만드는 것은 쉬워졌어도 요구사항·개발자·도구 변경을 거치며 유지보수하는 비용은 훨씬 뒤에야 드러나므로 어느 쪽의 승리 선언도 성급하다고 봅니다.

가속자와 바이브코더

저자는 AI 활용 방식을 두 부류로 나눕니다. '가속자(accelerator)'는 AI를 자신의 이해를 코드로 번역하는 도구로 쓰며, 의도에서 코드로의 번역 근거를 설명하고 변경의 결과를 예측할 수 있도록 생성된 코드를 읽습니다. 이들에게 언어 모델은 텍스트 에디터와 같은 부류의 도구이며, 팀의 읽기 속도가 생성 속도를 따라가지 못하면 Margaret-Anne Storey가 말한 '인지 부채(cognitive debt)'가 쌓입니다. 반면 '바이브코더(vibecoder)'는 구현과 그 지속적 수정을 AI에 위임하고, 원하는 동작의 명세·컨텍스트 공급·결과 검증 방법에 주의를 집중합니다. 이들에게 모델은 컴파일러나 프레임워크 같은 추상화 계층이며, 대신 요구사항 재작성이나 세션 간 컨텍스트 표류로 '인텐트 부채(intent debt)'가 쌓이고, 컨텍스트가 오염된 에이전트는 Drew Horthy가 말한 '덤 존(dumb zone)'에 빠집니다. 구분의 기준은 모델이 코드를 얼마나 쓰느냐가 아니라 산출물과 개발자의 관계입니다. 가속자는 기능의 거의 모든 줄을 생성해도 이해를 유지할 수 있고, master 브랜치에 올라가기 전에 이해를 습득할 의도만 있다면 생성 코드로 문제를 탐색하는 것도 허용됩니다.

Naur의 이론 구축과 구현의 역할

저자의 입장은 Peter Naur가 1985년에 쓴 'Programming as Theory Building'에 뿌리를 둡니다. 코드는 프로그래밍의 진짜 산출물이 아니며, 오히려 자산보다 부채에 가까운 경우가 많다는 것입니다. 진짜 자산은 뒤에 있는 '이론(theory)', 즉 무언가를 할 수 있을 뿐 아니라 설명하고 질문에 답하고 미래를 예측하고 변화에 적응하게 하는 지식입니다. 소스 코드는 눈에 보인다는 이유만으로 과대평가되는데, 이는 석탄 발전소에서 전기가 아니라 냉각탑의 수증기를 주요 산출물로 취급하는 것과 같습니다. 또한 구현은 명세를 코드로 번역하는 단계일 뿐 아니라 명세가 수정되는 장소이기도 합니다. 모든 경우를 다루다 보면 문제에 대한 이해 자체가 바뀌어 처음으로 돌아가는 일이 생기며, 바이브코더는 구현을 다루지 않고 명세와 실행만으로 이론을 세울 수 있다는 데 베팅하는 셈인데 저자는 회의적입니다. 녹색 테스트 스위트는 프로그램이 당신이 말한 대로 동작함을 증명할 뿐, 그 말이 현실과 부합하는지는 증명하지 못합니다.

표류의 위험과 팀의 합의

저자는 일회성·탐색적 프로젝트에서는 바이브코딩에 기울 수 있지만, 두 접근은 스펙트럼이 아니라고 봅니다. 이해 유지를 포기하면 의식적 위임 설계 없이 기본값으로 바이브코더가 될 뿐이며, diff를 훑기 시작하고 특정 구현 선택의 근거를 떠올리지 못하다가 결국 무엇을 만들었는지 모델에게 물어야 하는 상태가 됩니다. 가장 유해한 관행은 서로 다른 접근을 선호하는 사람들을 사전 합의 없이 같은 팀에 두는 것입니다. 가속자는 작성자가 애초에 유지할 의도가 없던 이해를 재구성하는 일을 떠안고, 바이브코더는 일회용으로 만든 구현 선택의 설명을 요구받습니다. 머지 전에 그 변경이 개발자의 이해로 유지될 것인지, 명세와 생성·검증 프로세스로 유지될 것인지 동료가 알아야 한다는 것입니다.

인텐트 부채와 검토 도구

AI 시대가 드러낸 것은 우리가 코드 품질 자체보다 구현 품질로 표현된 제품 이해를 중시해왔다는 사실이며, 언어 모델은 이제 그 이해를 그럴듯하게 흉내 낼 수 있습니다. 저자는 expiryTime = 6h 같은 값이 명시적 요구사항인지, 관례인지, 고려된 트레이드오프인지, 아무도 이의를 제기하지 않은 추측인지 코드만으로는 알 수 없다는 예를 들어 인텐트 부채를 설명합니다. 대응책으로는 에이전트의 요약 능력을 활용해 근거 없는 선택을 추적하는 방식, Crit 같은 의도-구현 일치 검증 도구, CodeRabbit의 Change Stack, 저자 자신의 intent-stack 스킬 등을 소개합니다. StrongDM의 '소프트웨어 팩토리'처럼 사람이 코드를 쓰지도 리뷰하지도 않고 코드베이스 밖의 시나리오로 검증하는 실험도 위임을 의도적으로 만드려는 시도로 언급됩니다. 끝으로 저자는 Bainbridge의 'Ironies of Automation'(1983)을 인용해, 생성 코드를 검토만 하는 것이 수동 코딩 역량을 유지하기에 충분한지는 미지수이며, '매우 지루하지만 매우 책임이 크고 그 책임을 감당할 자질을 기를 기회가 없는' 최악의 작업이 될 수 있다고 경고합니다.