Abstraction

결제 기능을 쓰는 쪽에서 매번 HTTP 호출 순서, 인증 토큰 처리, 재시도 정책, 저장 포맷까지 알아야 한다면 그 코드는 결제라는 개념을 사용하는 것이 아니라 구현 디테일에 종속된 것입니다. 이런 구조에서는 내부 구현을 조금만 바꿔도 상위 계층이 연쇄적으로 흔들립니다.

소프트웨어가 커질수록 모듈끼리 서로의 구현 세부를 너무 많이 아는 문제가 반복됐습니다. 데이터와 행동을 한 객체 안에 묶는 것만으로는 충분하지 않았고, 어떤 세부는 숨기고 어떤 책임만 드러낼지를 더 의식적으로 설계해야 했습니다. 추상화는 이 지점에서 객체지향 설계의 핵심 기준이 됐습니다.

추상화는 먼저 객체가 맡아야 할 책임을 정하고 그 책임을 수행하는 데 필요한 연산만 바깥으로 노출합니다. 저장 구조, 내부 알고리즘, 외부 시스템 호출 순서 같은 세부는 객체 안이나 하위 계층에 남깁니다. 잘 된 추상화는 호출자가 내부 구현을 몰라도 어떤 식으로 써야 할지 예측하게 만들어 줍니다.

추상화는 보여 줄 개념적 표면을 고르는 일이고, 캡슐화는 그 표면 뒤의 상태와 규칙을 보호하는 일입니다. 따라서 내부를 숨겼다고 해서 좋은 추상화가 되는 것은 아니며, 호출자가 여전히 구현 디테일을 알아야 한다면 표면이 잘못 잡힌 것입니다.

리포지토리, 결제 서비스, 파일 저장기, 메시지 발행기처럼 내부 구현은 자주 바뀔 수 있지만 상위 계층에는 안정된 역할로 보여야 하는 곳에서 추상화가 특히 중요합니다. 다만 차이도 충분히 드러나지 않았는데 공통 표면부터 만들면 오히려 미래의 가정을 코드에 고정하는 이른 추상화가 되기 쉽습니다.