아키텍처 규칙 자동화보다 팀의 판단이 먼저다

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

커스텀 어노테이션, 컴파일 단계 검사, 아키텍처 테스트로 레이어를 건너뛴 의존성을 막을 수 있다. 자기 구조를 검토할 수 있는 팀이라면 이 강제를 기본값으로 두지 않는 편을 택하겠다. 의존성 실수도 중요하지만 규칙 때문에 사라지는 대화도 중요하다.

피자 두 판 규모의 팀인지 먼저 본다

작은 팀에서는 레이어와 컴포넌트 경계를 계속 토론할 수 있어야 한다. 구현 레이어가 왜 있는지 묻고, 이 프로젝트에는 이름이나 역할이 맞지 않는다며 없애자고 제안할 수 있다. 이런 논쟁도 함께 소프트웨어를 만드는 과정이다. 모든 답을 게이트로 인코딩하면 논리적 모델이 아직 맞는지 판단하기 전에 물리적 규칙으로 굳는다.

포맷 규칙과는 다르다. 세미콜론 같은 단순 관례를 리뷰하는 데 시간을 쓰지 않도록 자동화하는 것은 좋다. 레이어는 의존성과 시스템을 이해하는 방식까지 바꾼다. 규칙을 느슨하게 두면 경험이 적은 동료도 도구를 통과하는 데서 멈추지 않고 이유를 묻고 의견을 내며 답에서 배울 수 있다.

피자 두 판을 먹을 정도의 팀이 느슨한 아키텍처 규칙까지 모두 강제로 막아야 한다면 리뷰와 소통이 더 근본적인 문제일 수 있다. 회사의 기본값과 다른 팀 구조가 나왔다고 자동으로 결함이 되는 것도 아니다.

대화가 모든 변경에 닿지 못할 때 자동화가 필요해진다

가끔 참여하는 사람이 많은 저장소, 공개 프로젝트, 기본 의존성 실수까지 검토할 시간이 없는 조직에서는 답이 달라진다. 코드를 바꾸는 사람들이 자주 함께 일하지 않는다면 기계적인 검사가 최소 품질선을 지킬 수 있다. 리뷰를 충분히 받지 못하는 경험 적은 개발자의 예상 가능한 실수도 막아 준다.

보호에는 대가가 있다. 레이어가 왜 있는지, 이 프로젝트에 필요한지 배우지 않고 어떤 규칙을 통과해야 하는지만 익힐 수 있다. 아키텍처 생각을 테스트로 표현할 수 있다는 이유보다 저장소 규모와 리뷰 한계 때문에 그 비용을 감수해야 할 때 강한 검사가 더 타당하다.

모든 강제 도구를 써 본 것은 아니므로 아키텍처 테스트가 나쁘다는 판정은 아니다. 팀이 아직 경계를 토론할 수 있는지, 변경 면적이 너무 커 대화만으로 감당할 수 없는지를 묻는 문제다. 그 제약에서 정적 강제의 시작점을 정하고 모든 설계 생각을 컴파일 오류로 만드는 데까지 가지 않으면 된다.