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