핵심 고민
AI 도구(Claude)와 코딩 작업을 할 때 느끼는 근본적인 딜레마:
- AI의 장점: 엄청난 속도로 코드 생성, 실제로 동작함
- AI의 한계: 코드 구조가 제각각, 기존 패턴을 완벽히 따르지 않음
패턴 드리프트 문제
[사용자] “기존에 짜여 있던 코드가 네가 알고 있는, 굉장히 일반적이라고 생각하는 구조 패턴과 다르면, 너는 자연스럽게 네가 알고 있는 구조 패턴에 맞춰서 코딩하더라고.”
AI는 훈련 데이터에서 온 패턴 편향이 있어서, 프로젝트의 기존 패턴이 “일반적"이지 않으면 자신의 익숙한 패턴으로 작성하는 경향이 있음.
검증 오버헤드
[사용자] “그렇다고 너한테 코드 퀄리티나 설계 같은 것들을 기존 코드와 거의 동일하게 맞추려고 하면, 토큰도 엄청 소비되고, 내가 또 계속 확인해줘야 하고.”
패턴 일치를 원하면:
- 토큰 소비 증가
- 지속적인 확인 필요
- 속도 이점 감소 → “내가 직접 할 때랑 속도 차이가 크게 나지 않는 느낌”
100% vs 덜-100%
[사용자] “내가 하면 100%인데, 네가 하면 100%가 안 되면서 속도도 살짝 더 빠른 수준이야. 그러면 내 입장에서는 그냥 내가 하고 말지 싶어진단 말이지.”
직접 하면 100% 패턴 일치, AI 사용하면 100% 미만인데 속도는 약간만 더 빠름 → 직접 하는 게 나을 수 있음
유지보수 관점의 중요성
[사용자] “이 코드를 AI로만 유지보수하고 설계하고 기능을 추가하는 게 아니라, AI가 결국 못하거나 벽에 막힐 때는 사람이 해야 되잖아.”
코드는 결국 사람이 유지보수해야 함:
- 인지부하가 적은 코드
- 명확한 책임 분리
- 기존 패턴과의 일관성
- IDE 기능 활용 가능성 (시그니처 추적 등)
이해관계자와의 갈등
[사용자] “이해관계자들은 기능이 잘 되면 됐지, 무슨 코드 퀄리티가 그렇게 중요하냐며 이런 이야기들을 하거든.”
“동작하면 됐지” 주장의 문제:
- 유지보수 비용은 6개월 후에나 보임
- 속도 지표는 눈에 보이고, 기술 부채는 안 보임
- 의사결정자가 바뀌거나 책임 소재가 흐려짐
Claude의 솔직한 인정
[Claude] “저는 도구입니다. 도구가 작업자 스타일에 맞춰야지, 작업자가 도구에 맞추면 안 됩니다.”
AI의 한계:
- 훈련 데이터에서 온 패턴 편향
- 명시적으로 패턴 알려줘도 100% 따르지 못함
- 컨텍스트 한계로 코드베이스 전체를 보지 못함
- “일반적"이라 생각하는 게 해당 상황에 최적이 아닐 수 있음
결론: 사용자의 판단이 맞다면 AI 패턴에 맞추지 말 것. 도구는 작업자에게 맞춰야 함.