[NHN FORWARD 22] 클린 아키텍처 애매한 부분 정해 드립니다.

기능을 방 안의 물건과 가구에 비유해, 빈 공간이 없고 엉망진창인 방에는 물건을 더 넣기 어렵듯 구조가 엉망이면 기능 추가가 힘들다고 설명한다. 반대로 나름의 질서가 있어 언뜻 복잡해 보여도 물건을 더 넣을 공간과 콘센트 위치까지 갖춘 방처럼, 기능이 계속 더해져도 감당할 수 있는 구조를 목표로 삼아야 한다.

개발의 대부분은 코딩이지만 코딩의 상당 부분은 유지보수이며, 유지보수는 '더 빠르고 정확하게 많이 하는 일'이라고 정의한다. 이를 위해 구조가 잘 잡혀 있어야 하고, 좋은 구조란 낮은 비용으로 계속 변경 가능한 상태다. 기능이 완성돼도 구조가 엉망이면 새로 만드는 게 낫다는 말이 나올 만큼 구조가 중요하다.

화살표가 의존성을 뜻하는 계층형 아키텍처는 간단하고 보편적이지만, 규모가 커지면 도메인·서비스·영속성에 많은 것이 몰려 구조화가 어렵고 데이터베이스 주도 설계를 유도한다. 영속성부터 개발하며 JPA 엔티티를 먼저 만들게 되는 흐름이 그 예다.

로버트 마틴(엉클 밥)이 수십 년의 원칙을 하나로 합친 클린 아키텍처는 관심사를 분리하고 의존성 방향을 안쪽·고수준으로 향하게 한다. 얇고 실천적인 '만들면서 배우는 클린 아키텍처'는 헥사고날 아키텍처를 따라할 수 있는 구조·코드·다이어그램으로 제시하는데, 클린 아키텍처의 공통점을 뽑아낸 것이라 가장 유사하다.

클린 아키텍처에는 애매한 부분이 많지만 핵심 규칙은 두 가지다. 첫째, 의존성은 항상 안쪽(고수준)을 향한다 — 이를 어기면 클린 아키텍처라 할 수 없다. 둘째, 중요한 것을 테스트하기 좋아야 한다. 나머지 수많은 원칙은 이 목표에 부합하는지를 기준으로 판단하면 된다.

JPA 엔티티를 도메인 엔티티로 그대로 써서 어댑터에서 가져오면 구조는 단순해지지만 영속성 관심사가 도메인에 스며드는 부작용이 있다. 출력 포트를 두고 리포지터리 구현 어댑터를 만들면 DB 세부사항으로부터 도메인을 보호할 수 있다. '지름길(건너뛰기)'을 인정하되, 나중에 정석대로 되돌릴 수 있게 관리하는 균형을 강조한다.

아키텍처는 특정 개발자가 아니라 팀 모두를 위한 것이라 정말 중요하며, 좋은 아키텍처를 구성하는 방법으로 클린 아키텍처 패턴과 그 핵심 규칙을 다뤘다. 원칙을 일일이 따지기보다 애매한 것들을 팀이 함께 정해가며 결정해 나가면 좋겠다는 제안으로 마무리한다.