11 의식적으로 지름길 사용하기
이 책의 서문에서는 절대 갚을 길 없는 기술 부채를 쌓아가면서 항상 지름길의 유혹을 느낀다는 사실을 저주했다.
지름길을 방지하기 위해서는 먼저 지름길 자체를 파악해야 한다. 그래서 이번 장의 목표는 잠재적인 지름길에 대한 인식을 높이고 그 영향에 대해 이야기하는 것이다.
이 정보만 있어도 우발적으로 사용되는 지름길을 인식하고 수정할 수 있다. 또는 정당한 지름길이라면 지름길의 효과를 의식적으로 택할 수도 있다.
소프트웨어는 소프트하고 하드웨어에 비해 쉽게 변경할 수 있기 떄문에, 어떤 때는 지름길을 먼저 취하고 나중에 고치는 것이 실제로 더 경제적일 수도 있다.
왜 지름길은 깨진 창문 같을까?
1969년에 심리학자 필립 짐바르도는 나중에 '깨진 창문 이론'이라고 알려진 실험을 했다.
번호판 없는 차 한대를 브롱크스 인근에 주차해놓고 주고 환경이 '조금 더 낫다'고 알려진 팔로 알토 근처에도 한 대 주차해 뒀다. 그리고 기다렸다.
브롱크스에 주차해둔 차는 24시간도 채 지나지 않아 중요 부품들이 감쪽같이 도난당했고, 행인들이 차를 망가뜨렸다.
팔로 알토의 차는 일주일 동안 전혀 손을 타지 않않기에 일부러 창문을 깨뜨렸다. 그러나 그 차는 브롱크스에 있는 차와 비슷한 운명을 맞아서 짧은 시간동안 행인들에 의해 망가졌다.
도둑질과 차량 회손에 가담한 사람들은 모든 사회적 계급에 존재했고, 준법정신이 투철하고 예의바르게 행동했을 법한 시민들도 포함돼 있었다.
인간의 이 같은 행동은 '깨진 창문 이론'으로 알려지게 되었다. 나만의 표현으로 바꿔보면 다음과 같다.
어떤 것이 멈춘 것처럼 보이고, 망가져 보이고, 혹은 관리되지 않는다고 여겨지면 인간의 뇌는 이를 더 멈추고, 망가뜨리고 해도 된다고 생각하게 된다.
이 이론은 삶의 많은 부분에 적용할 수 있다.
- 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기 쉽다.
- 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기도 쉽다.
- 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기도 쉽다.
이 모든 것을 고려하면 이른바 '레거시'라고 불리는 많은 코드의 품질이 시간이 가면서 심하게 낮아졌다는 게 놀라운 일은 아니다.
깨끗한 상태로 시작할 책임
코드를 짜는 것은 차를 도둑질하는 것과 다르지만, 우리는 모두 깨진 창문 심리에 무의식적으로 영향을 받는다. 그래서 가능한 한 지름길을 거의 쓰지 않고 기술 부채를 지지않은 채로 프로젝트를 깨끗하게 시작하는 것이 중요하다.
소프트웨어 프로젝트는 대개 큰 비용이 들고 장기적인 노력을 필요로 하기 때문에 깨진 창문을 막는 것이 소프트웨어 개발자들의 아주 막대한 책임이다.
그러나 때로는 지름길을 취하는 것이 더 실용적일 때도 있다. 작업 중인 부분이 프로젝트 전체로 봤을 때 그리 중요하지 않은 부분이거나, 프로토타이핑 작업 중이거나, 경제적인 이유가 있을 수도 있다.
이러한 의도적인 지름길에 대해서는 세심하게 잘 기록해둬야 한다. 우리는 미래의 우리 혹은 프로젝트를 인계받는 이들에게 빚을 지고 있는 것이다. 만약 팀원 모 두가 이 문서에 대해 인지하고 있다면 지름길이 합리적인 이유에 의해 의도적으로 추가됐다는 사실을 알기 때문에 깨진 창문 이론의 영향을 더 줄일 수 있을 것이다.
유스케이스 간 모델 공유하기
4장에서는 유스케이스마다 다른 입출력 모델을 가져야 한다고 이야기한 바 있다. 즉, 입력 파라미터의 타입과 반환값의 타입이 달라야 한다는 뜻이다.
유스케이스 간 입출력 모델을 공유하는 것은 유스케이스들이 기능적으로 묶여 있을 때 유효하다. 즉, 특정 요구사항을 공유할 때 괜찮다는 의미다. 이 경우 특정 세부사항을 변경할 경우 실제로 두 유스케이스 모두에 영향을 주고 싶은 것이다
두 유스케이스가 서로 간에 미치는 영향 없이 독립적으로 진화해야 한다면 입출력 모델을 공유하는 방식은 지름길이 된다. 만약 독립적으로 진화해야 한다면 처음에는 똑같은 입출력 클래스를 복사해야 하더라도 일단 분리해서 시작해야 한다.
도메인 엔티티를 입출력 모델로 사용하기
도메인 엔티티인 Account와 인커밍 포트인 SendMoneyUseCase가 있으면 엔티티를 인커밍 포트의 입출력 모델 로 사용하고 싶다는 생각이 들지도 모른다.
인커밍 포트는 도메인 엔티티에 의존성을 가지고 있다. 그 결과, Account 엔티티는 변경할 또 다른 이유가 생겼다.
이 지름길이 위험한 이유는 많은 유스케이스가 간단한 생성 또는 업데이트 유스케이스로 시작해서 시간이 지나면서 복잡한 도메인 로직 괴물이 되어간다는 사실 때문이다. 그러므로 처음에는 도메인 엔티티를 입력 모델로 사용했더라도 도메인 모델로부터 독립적인 전용 입력 모델로 교체해야 하는 시점을 잘 파악해야 한다.
인커밍 포트 건너뛰기
아웃고잉 포트는 애플리케이션 계층과 아웃고잉 어댑터 사이의 의존성을 역전시키기 위한 (의존성이 안쪽으로 향하게 하는) 필수 요소인 반면 인커밍 포트는 의존성 역전에 필수적인 요소는 아니다. 인커밍 어댑터가 인커밍 포트 없이 애플리케이션 서비스에 직접 접근하도록 할 수 있다.
인커밍 포트를 제거함으로써 인커밍 어댑터와 애플리케이션 계층 사이의 추상화 계층을 줄였다. 보통 추상화 계층을 줄이는 것은 괜찮게 느껴진다.
하지만 인커밍 포트는 애플리케이션 중심에 접근하는 진입점을 정의한다. 이를 제거하면 특정 유스케이스를 구현하기 위해 어떤 서비스 메서드를 호출해야 할지 알아내기 위해 애플리케이션의 동작에 대해 더 잘 알아야 한다. 전용 인커밍 포트를 유지하면 한눈에 진입점을 식별할 수 있다.
인커밍 포트를 유지해야 하는 또 다른 이유는 아키텍처를 쉽게 강제 할 수 있기 때문이다.
애플리케이션 서비스 건너뛰기
어떤 유스케이스에서는 애플리케이션 계층을 통째로 건너뛰고 싶을 수도 있다.
간단한 CRUD 유스케이스에서는 보통 애플리케이션 서비스가 도메인 로직 없이 생성, 업데이트, 삭제 요청을 그대로 영속성 어댑터에 전달하기 때문에 정말 구미가 당기는 방법이다. 그대로 전달하는 대신 영속성 어댑터가 직접 유스케이스를 구현하게 할 수 있다.
하지만 이 방법인 인커밍 어댑터와 아웃고잉 어댑터 사이에 모델을 공유해야 한다. 이 경우엔 공유해야 하는 모델이 Account 도메인 엔티티이므로 앞서 도메인 모델을 입력 모델로 사용하는 케이스가 되는 것이다.
나아가 애플리케이션 코어에 유스케이스라고 할 만한 것이 없어진다. 시간이 지남에 따라 CRUD 유스케이스가 점점 복잡해지면 도메인 로직을 그대로 아웃고잉 어댑터에 추가하고 싶은 생각이 들 것이다. 이미 유스케이스가 어댑터에 있으니 말이다. 이러면 도메인 로직이 흩어져서 도메인 로직을 찾거나 유지보수하기가 어려워진다.
유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?
경제적인 관점에서 지름길이 합리적일 때도 있다. 이번 장에서는 지름길을 사용할지 여부를 결정하는 데 도움이 되도록 지름길을 사용한 결과에 대한 식견을 제공했다.
간단한 CRUD 유스케이스에 대해서는 전체 아키텍처를 구현하는 것이 지나치게 느껴지기 때문에 지름길의 유혹을 느낄 수 있다. 하지만 모든 어플리케이션은 처음에 작게 시작하기 때문에, 유스케이스가 단순한 CRUD 상태에서 벗어나는 시점이 언제인지에 대해 팀이 합의하는 것이 매우 중요하다. 합의를 이루고 난 후에야 팀은 지름길을 장기적으로 더 유지보수하기 좋은 아키텍처로 대체할 수 있다.
단순 CRUD 상태에서 더이상 벗어나지 않는 유스케이스도 있다. 이러한 유스케이스는 유지보수 비용을 증가시키지 않기 때문에 지름길을 그대로 유지하는 게 더 경제적이다.
어떤 경우든 아키텍처에 대해, 그리고 왜 특정 지름길을 선택했는가에 대한 기록을 남겨서 나중에 우리 자신 또는 프로젝트를 인계받는 이들이 이 결정에 대해 다시 평가할 수 있게 하자.