AI와 만드는 새 프로젝트의 모듈과 계층 단순화

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

오랫동안 사람이 직접 작은 서비스를 만들며 다듬은 프로젝트 템플릿이 AI 코딩 에이전트를 적극 활용하는 작업에도 가장 좋은 템플릿인지는 다시 물어볼 수 있다. 다만 이것은 현재 시험하고 있는 가설이지 검증이 끝난 아키텍처 규칙이 아니다.

실험의 범위는 새 프로젝트다. 기존 코드베이스에는 AI가 다른 구조를 더 쉽게 다룰 수 있다는 이유만으로 지울 수 없는 규칙과 의존관계, 역사가 있다. 그에 비해 그린필드에서는 모듈, 인터페이스, 계층을 줄여 에이전트가 다뤄야 할 컨텍스트를 덜면서도 코드의 명확성을 지킬 수 있는지 확인할 여지가 있다.

오래 다듬은 템플릿도 추가 컨텍스트가 될 수 있다

오래 쓴 템플릿에는 여러 프로젝트에서 얻은 판단이 들어 있다. 클라이언트, 스토리지, 설정, 엔티티, 애플리케이션 코드를 모듈로 나눈 이유도 여러 작은 서비스를 출시할 때 그 구조가 편했기 때문일 수 있다.

같은 구조 안에서 AI 에이전트가 일하면 경계마다 더 많은 설명이 필요해질 수 있다. 모듈별 작업 규칙을 컨텍스트로 제공해야 하고, 인터페이스가 많을수록 에이전트가 맞지 않는 추상화를 고르거나 주변 코드와 어긋난 결과를 만들 여지도 커질 수 있다.

이는 진행 중인 개인 실험에서 나온 관찰이지 생산성이나 결함을 측정한 결과가 아니다. 수작업에 맞춰 다듬은 템플릿이 AI 작업에도 최적이라는 전제를 의심할 근거는 되지만, 기존 구조가 실패했다고 결론 내릴 증거는 아니다.

경계를 줄이는 일은 목적지가 아니라 가설이다

한 가지 방향은 설정은 분리하되 스토리지 엔티티를 별도 모듈로 계속 떼어 놓지 않고 핵심 애플리케이션 가까이에 두는 것이다. 네 영역으로 나누던 계층 대신 컨트롤러, 서비스, 리포지터리처럼 더 단순한 구성을 시험할 수도 있다.

모든 인터페이스를 없애자는 제안은 아니다. 실제 포트와 어댑터가 많이 필요한 시스템이라면 그 분리는 여전히 타당할 수 있고, 소프트웨어가 성장하면 판단이 달라질 수 있다. 일반적인 서비스에 책임보다 많은 모듈과 인터페이스가 쌓여 컨텍스트 비용을 만들 수 있다는 좁은 의심에 가깝다.

코드를 더 직접적으로 만든다면 어느 정도 중복을 허용하는 선택도 가능하지만 이 트레이드오프 역시 확정되지 않았다. 추상화를 줄이면 생산 속도는 올라갈 수 있는 반면 필요한 경계까지 잃을 수 있다. 실험은 양쪽을 함께 봐야 한다.

명확성과 품질은 실험에서도 제약으로 남는다

생성량이 늘었다는 사실만으로 품질을 어떻게 가져갈지 답할 수는 없다. 작은 아키텍처는 결과 코드가 더 명확할 때만 의미가 있다. 에이전트를 빠르게 만들려고 계층을 없앤 뒤 사람이 결과를 이해하거나 판단하기 어려워진다면 좋은 교환이 아니다.

그린필드라는 전제도 같은 이유로 중요하다. 개인이나 회사의 새 프로젝트는 시작부터 다른 기본값을 시험할 수 있다. 레거시 시스템은 실험적인 템플릿을 강제로 적용하기보다 기존 구조를 최대한 따르면서 부분적으로 개선하는 편이 맞다.

현재 결론은 잠정적이다. AI와 만드는 새 프로젝트는 오래된 템플릿보다 적은 경계에서 이점을 얻을 수 있다. 앞으로의 사용을 통해 어떤 단순화가 명확성을 높이고 어디서 필요한 구조를 없앴는지 확인해야 한다. 지금은 템플릿 설계 실험이지 단순한 아키텍처가 이미 이겼다는 증거가 아니다.