아직도 코드를 읽나요?

AI 활용 방식은 구현 이해를 유지하는 가속형 개발자와 구현 및 수정을 위임하는 바이브코더로 나뉨. 차이는 AI가 작성한 코드의 양이 아니라 결과물을 이해하고 유지보수하는 방식에 있음 프로그래밍의 핵심 자산은 코드보다 도메인에 대한 모델과 이해에 있음. 구현 과정 자체가 요구사항과 모델을 수정하는 과정이므로, 명세 작성과 실행만으로 이를 대체할 수 있는지는 아직 불확실함 서로 다른 AI 활용 방식을 쓰는 동료가 함께 일하려면 유지보수 책임과 경계를 먼저 합의해야 함. 그렇지 않으면 보존되지 않은 이해를 복원하거나, 폐기 가능한 구현 선택을 설명해야 하는 부담이 생김 생성된 코드를 모두 읽어도 의도 부채는 해소되지 않음. 요구사항, 의도적인 설계 결정, 기존 관례, 근거 없는 선택을 구분하고 그 맥락을 코드 변화와 함께 보존해야 함 코드를 읽는 것만으로 수동 개발 능력이 유지되는지, 어느 방식이 장기 유지보수에 유리한지는 아직 검증되지 않음. 코드를 읽지 않게 되는 것 자체가 진보는 아님 ‘아직도’에 담긴 성급한 전제 “코드를 읽나요?”에 ‘아직도’를 붙이면, 코드 읽기가 전화번호 암기나 종이 지도처럼 사라질 관행이라는 전제가 들어감 AI를 폭넓게 사용하면서도 생성 결과를 읽는 방식은, 특히 커밋하고 배포하는 코드에 책임을 져야 하는 업무에서 의도적인 선택이 될 수 있음. 구현을 위임하는 방식 역시 신중한 선택일 수 있지만, 같은 코드베이스를 공유하는 동료에게 무엇을 요구하는지까지 합의된 것은 아님 작동하는 애플리케이션을 만드는 일은 쉬워졌지만, 요구사항, 개발자, 도구가 바뀌는 동안의 유지보수 비용을 확인하려면 훨씬 긴 시간이 필요함 팀은 이미 일하는 방식에 관한 결정을 내리고 있지만, 그 결과는 나중에야 드러남 어느 방식이 승리했다고 단정하기에는 아직 이름 가속형 개발자와 바이브코더의 서로 다른 약속 가속형 개발자(Accelerators) 는 자신의 이해를 코드로 옮기는 데 AI를 사용하며, 의도에서 구현으로 이어지는 이유를 설명하고 변경의 결과를 예측하며 모델과 구현을 유지할 만큼의 이해를 보존하려 함 언어 모델과 하네스는 편집기나 플러그인처럼 코딩을 빠르게 하는 도구에 가까움 큰 변경은 검토에 오래 걸리고, 모델을 잘못 구현한 생성 코드는 다시 작성해야 함 팀의 읽기 속도가 생성 속도를 따라가지 못하면 인지 부채(cognitive debt) 가 쌓이며, 이를 막는 규율을 유지하기는 어려움 바이브코더(Vib...