아키텍처가 부패하는 한 가지 요인은 개발 비용에 타협하는 것
부패한 아키텍처의 특징은 다음과 같다: 다수의 특수 처리, 호환 처리, 심각한 결합, 되돌리기 어려움. 아키텍처는 모두 서서히 부패한다. 부패한 아키텍처는 새로운 기능을 개발하기 어렵고, 버그 수정이 힘들며, 하나를 건드리면 온몸이 반응하여 테스트와 QA도 하기 어렵다. 내가 본 적 있는 비전공 개발 애호가가 글을 올려 말하기를, 모델이 코드를 작성할 때의 추상화 행동을 제한하면 코드를 더 이해하기 쉽다고 했다. 사람이 더 이해하기 쉬운 코드는 LLM도 더 이해하기 쉬우므로, 빠르게 개발하고 오류를 줄일 수 있다. 비전공 개발자들은 아마도 공사 규모가 작아 조립식 흐름 로직에 익숙한 것 같다. 규모 확대를 예상한다면, 사고방식은 조립식 흐름에만 국한되지 말고 건축공처럼 생각해야 한다. 30층짜리 건물을 짓는 것을 예상한다면 10미터 기초를 파야 하고, 급수와 전기를 통하게 할 것을 예상한다면 수직구와 전기 샤프트를 미리 확보해야 한다. 이것은 목표가 명확한 설계이며, 그 밖에 목표가 불명확한 설계도 있는데, 예를 들어 집 안 어딘가에 나중에 가전을 놓을 예정이지만 무엇을 놓을지 불확실하다면 콘센트만 미리 설치해 두면 된다. 소프트웨어 공학에는 이미 설계를 지도하기 위한 SOLID 원칙이 있다. 겉으로 보면 SOLID 원칙을 따를 때 동일한 기능을 구현하려면 더 많은 파일을 거치고 더 많은 코드를 작성하게 되는데, 단기적 결과로 보면 설계를 하든 안 하든 사장/테스터/사용자 입장에서는 거의 차이가 없고, 설계가 가져오는 이점은 장기적으로만 나타난다. 좋은 아키텍처는 기능을 추가하기 쉽고, 기능을 변경하기 쉽고, 버그를 고치기 쉬우며, 더 적은 문제를 유발한다. 설계에 필요한 사고는 직접 손을 대어 기능을 개발하는 것보다 많을 때가 많다. 설계는 입자도를 고려해야 하는데, 콘센트 패널을 타일처럼 온 집에 빼곡히 붙이는 것은 또 다른 황당한做法이다. 예전에 내가 개발할 때 개발 주기를 고려해 타협을 하곤 했는데, 시간이 촉박하면 설계조차 하지 않고 함수 몇 개를 추가해 끝내고, 나중 일은 나중에 생각하곤 했다. 지금은 AI의 도움으로 설계의 입자도를 더 작게 할 수 있고, 생성된 코드는 사람이 보기엔 더 이해하기 힘들지만 공학적으로는 더 유지보수하기 쉽다. 추상화를 늘린 후, 조금 떨어지는 모델은 확실히 제대로 처리하지 못할 수 있으니 가능한 한 현재 가장 좋은 모델을 쓰는 것이 좋다. 그저 스크립트를 작성하는 것이라면 모델 간 능력 차이가 그리 뚜렷하지 않을 수도 있다. AI가 개발자의 진입 장벽을 낮췄는지에 대해서는 의문이 든다. 신입 개발자의 학습 경로가 과거와 이미 완전히 달라졌으니, 장벽의 높고 낮음을 논하는 것은 의미가 없을 수 있다. 어디로 장벽이 옮겨갔는지 우리는 알지 못하기 때문이다.
