SLASH 22 - 지속 성장 가능한 코드를 만들어가는 방법

첫 번째 주제 패키지 구조를 햄버거 가게 비유로 풀어낸다. 햄버거 세트를 포장할 때 버거는 포장지로 감싸고 감자튀김은 따로 담고 콜라는 컵에 담아 봉투에 넣듯 패키지에도 적절한 전략이 필요하고, 정책이 바뀌어 최소 주문 수량이 100개가 되면 박스 단위로 포장을 바꾸듯 패키지 전략도 고정된 게 아니라 현재 상황을 계속 점검하며 응집을 지켜내야 하는 가치다. 결제 관련 코드에서 임포트 문을 펼치면 '카드' 개념의 응집이 잘 이뤄지지 않은 점이 아쉽다. CardService가 개념적으로 카드에 속하는데도 Card, CardPaymentRequest, CustomerCard처럼 같은 개념의 클래스들을 임포트로 끌어다 써야 하고, 임포트 문이 여러 결로 분산돼 빵·패티·치즈가 따로 포장된 것처럼 느껴진다.

응집을 고민해 같은 개념의 클래스들을 한곳에 모으자 임포트 양이 줄고, 카드 개념에 속한 클래스들의 임포트 문이 사라졌다. CardReader, CardPaymentProcessor, CardValidator는 생성자에는 존재하되 임포트는 필요 없게 됐는데, 이는 CardService가 존재하려면 이들이 꼭 필요하면서 가까운 곳에 응집돼 있다는 의미다. 역할 기준으로 나뉘어 있던 패키지가 개념 기준으로 더 잘 모여 비로소 완전한 햄버거 모양이 된 셈이다. 한 개념의 클래스가 너무 많아지면 응집이 깨지므로 적절한 시기에 개념을 세분화해야 하는데, 예제에서는 카드 개념이 커지자 '카드 소유'라는 하위 개념을 만들어 별도 패키지로 구성했다. 이때 생기는 임포트 문은 결이 다른 패키지로 나뉘는 게 아니라 카드 하위의 사회적 개념이 생기는 것으로 인식된다. 결국 임포트 문이 보내는 신호를 느끼며 개념을 구체화하고 응집을 다듬어 가는 것이 중요하다.

두 번째 주제 레이어 구조로 넘어가, 토스페이먼츠의 표준 규칙을 짚는다. 레이어는 위에서 아래로 순방향으로만 참조되어야 하고, 참조 방향이 역류되지 않아야 하며, 레이어를 건너뛰지 않는다. 프레젠테이션 레이어에서 비즈니스 레이어로 객체를 그대로 전달하는 코드는 그 자체와 임포트 문이 깔끔해 보이지만, 비즈니스 레이어 쪽 임포트 문을 보면 레이어가 역류하면 안 된다는 규칙이 깨져 비즈니스 레이어가 프레젠테이션 레이어로 접근하고 있다는 신호를 임포트가 보낸다. 개선책으로 전달 시 개념화된 클래스로 변환해 넘기도록 바꾸면 프레젠테이션은 여전히 순방향으로 흐르고, 비즈니스 레이어의 임포트 문에서 더는 역류가 일어나지 않으며 오히려 어떤 개념에 의존하는지를 더 쉽게 유추할 수 있게 된다. 레이어 간 잘못된 참조는 장기적으로 복잡도를 높이고 확장의 발목을 잡는데, 이런 잠재적 문제를 임포트 문으로 신호처럼 느낄 수 있다는 점이 핵심이다.

세 번째 주제 모듈로 넘어가 표준 모듈 구조를 보여준다. 화살표 방향은 그래들에서 의존하는 방향이며 런타임에는 러너 모듈을 중심으로 의존성이 주입되는데, 모듈을 나누면 기술을 격리하고 모듈별로 테스트하며 역할과 경계를 뚜렷이 정할 수 있다. 단일 모듈로 작업하면 비즈니스 로직 안에 특정 라이브러리 의존이 의도치 않게 들어가 그 라이브러리가 바뀌면 비즈니스 로직까지 수정해야 한다. 이런 의존도 임포트 문으로 확인할 수 있으며, 라이브러리 부분을 격리하면 비즈니스 로직에서 특정 라이브러리를 임포트할 수 없게 되어 로직이 뚜렷해지고 라이브러리 교체 시에도 영향이 없다. 나아가 도메인 모델을 페이먼츠 API에서 분리하고 스프링과의 의존성을 격리하며, 스토리지 모듈도 분리해 페이먼츠 API가 스토리지를 런타임으로만 의존하고 스토리지는 도메인 모델 명세를 따르는 구현체 역할만 하도록 바꾼다. 이 구조에서는 HTTP 응답으로 JPA 엔티티를 쓰거나 도메인이 HTTP 스펙을 아는 문제를 피할 수 있다. 임포트를 포함한 코드 한 줄 한 줄을 소중히 여기고, 코드에 대한 통제와 제어를 기반으로 지속 성장하는 소프트웨어를 추구하며, 수명이 긴 결제 시스템일수록 지속적인 관리와 성장이 필요하다는 메시지로 마친다.