AI가 소프트웨어 아키텍처를 주도해서는 안 되는 이유
- •조직이 상황 맥락을 고려하지 않은 채 AI 에이전트에게 소프트웨어 아키텍처와 프로젝트 계획 수립을 전적으로 의존하고 있다.
- •AI 에이전트는 팀별 제약 사항을 무시하고 범용적인 '모범 사례'만 제시해, 결과적으로 시스템 구조를 지나치게 복잡하게 만든다.
- •아키텍처 결정을 AI에 위임하면 필수적인 기술적 토론이 사라지고, 설계에 참여하지 않은 엔지니어가 시스템 유지보수 책임을 떠안게 된다.
최근 조직들이 소프트웨어 아키텍처와 기술적 프로젝트 계획을 초안부터 AI 에이전트에 의존하는 사례가 늘고 있다. 기술 작가 찰리 홀랜드(Charlie Holland)는 AI 모델이 본래 도움을 주려는 성향 때문에 사용자의 의견에 동조하는 경향이 있다고 지적한다. 이로 인해 모델은 기술적으로는 타당해 보이지만, 특정 팀의 제약이나 레거시 시스템의 한계, 실무 환경을 전혀 고려하지 않은 설계를 제안하는 경우가 많다.
이러한 방식은 겉보기에는 정교해 보이나 팀 특유의 전략적 선택이 배제된 이른바 '젠가 타워'식 아키텍처를 양산한다. 예를 들어 개발 속도를 위해 마이크로서비스 대신 모노리스를 선택해야 하는 경우처럼, 숙련된 엔지니어가 수행하는 현실적인 타협점이 사라지는 것이다. 특히 엔지니어가 문제를 해결하는 주체가 아닌 AI가 생성한 Jira 티켓을 수행하는 단순 구현자로 전락하면서, 복잡성을 낮추기 위한 필수적인 기술적 토론 과정이 실종되고 있다.
더 큰 문제는 책임 소재가 불분명해진다는 점이다. AI는 시스템을 운영하거나 새벽 3시에 발생한 운영 이슈를 해결할 수 없기 때문이다. 찰리 홀랜드는 Claude Code와 같은 도구가 구현 작업의 생산성을 높일 수는 있지만, 아키텍처 설계만큼은 반드시 사람이 주도해야 한다고 강조한다. 결국 공학이란 조직의 정치적 역학을 이해하고, 부적절한 대안에 맞서 단순한 솔루션을 방어하며 최선의 타협점을 찾는 과정이다. 팀은 AI의 제안을 주니어 엔지니어의 의견처럼 비판적으로 검토해야 하며, 모든 건축적 결정에 사람의 이름을 남겨 장기적인 프로젝트 생존 가능성을 확보해야 한다.