AI가 작성하지 않을 코드
저는 기술 면접 질문으로 폼 검증(form validation)을 사용합니다. 간단해 보이지만, 사람들이 이를 해결하는 방식에서 그들의 사고방식을 알 수 있습니다.
Claude, ChatGPT, Gemini를 대상으로 이 문제를 테스트해 보았습니다. 그들은 모두 동일한 해결책을 제시했습니다.
대부분의 사람들은 다음 세 가지 방식 중 하나를 사용하여 문제를 해결합니다:
- 플래그를 사용하여 다양한 타입을 처리하는 단일 함수 사용.
- 재귀를 사용하여 데이터 구조를 탐색.
- 스키마를 기반으로 검증 수행.
AI 모델들은 모두 스키마 방식을 선택했습니다. 기술적으로 타당합니다. 누락된 키를 처리할 수 있고, 확장성도 좋습니다. 런타임에 데이터가 변경된다면 스키마 방식이 올바른 선택입니다.
하지만 대부분의 소프트웨어에는 더 나은 방법이 있습니다.
모든 것에 적용되는 단일 패턴을 찾으려 하기보다, 합성(composition)을 사용하세요. 각 비즈니스 개념에 고유한 함수를 부여하는 것입니다.
- 기본적인 주소 검증기(address validator)를 만듭니다.
- 기본 검증기를 사용하는 배송 검증기(shipping validator)를 만듭니다.
- 기본 검증기를 사용하는 결제 검증기(billing validator)를 만듭니다.
이 방식은 재귀를 사용하지 않습니다. 스키마를 사용하지도 않습니다. 대신 명확하고 분리된 함수들을 사용합니다.
이점은 간단합니다. 코드가 비즈니스를 반영한다는 것입니다. 결제 주소(billing address)는 별개의 개념입니다. 따라서 그에 맞는 고유한 로직이 필요합니다. 새로운 타입을 추가할 때 기존 함수를 수정할 필요 없이, 새로운 함수를 추가하기만 하면 됩니다. 이를 통해 변경 사항의 영향을 국소화할 수 있습니다.
AI는 이 경로를 선택하는 경우가 드뭅니다. 대신 로직을 중앙 집중화하는 패턴을 선택합니다. 우리의 교육은 중복을 제거하고 일반화하는 법을 가르칩니다. AI는 바로 그 문화로부터 학습합니다.
AI가 실패하고 있는 것이 아닙니다. 단지 우리가 가르친 것과 동일한 엔지니어링 본능을 따르고 있을 뿐입니다.
최선의 해결책은 코드 줄 수가 가장 적은 것이 아닙니다. 비즈니스 도메인을 가장 정직하게 반영하는 것이 최선의 해결책입니다.
다음에 해결책을 설계할 때, 스스로에게 한 가지 질문을 던져보세요:
이 가변성(variability)은 내 코드에 있는 것인가, 아니면 데이터에 있는 것인가?
이 질문에 대한 답이 설계 전체를 바꿉니다.
Source: https://dev.to/iceonfire/the-code-ai-wont-write-1ieb