추상화 범위에 관한 고민

배경

• API 통신 기능을 구현하던 중, 기능의 추상화는 어디까지 하는 것이 좋을까? 라는 의문이 들었다.
• 오버엔지니어링과 언더엔지니어링 사이 적정 수준의 설계점을 어떻게 찾을 수 있을까?

어디까지 추상화를 해야 할까?

• API 통신은 보통 아래와 같이 분리 및 추상화해 사용한다.
  • Endpoint
    • 요청을 보낼 주소 정보를 담는 객체
  • APIClient
    • Endpoint를 사용해 요청을 수행하는 객체
  • Request & Response
    • 요청 / 응답 데이터 정보를 담는 객체
• 그런데 만약 작성하고자 하는 기능명세가 오직 하나의 Endpoint만 필요로 하고, 앞으로 새로운 Endpoint가 추가될 가능성이 희박하다고 가정해보자.
• 단 하나의 구현체만이 존재할 예정임에도 Endpoint의 추상화가 필요할까?
  • 만약 필요하다면 그 이유는 무엇이고, 필요하지 않다면 그 이유는 무엇일까?

추상화로 얻는 것과 잃는 것

• 적절한 추상화는 코드의 재사용을 쉽게 해 주고, 코드의 유연성을 높여준다.
  • 구체 Endpoit 타입 대신 Endpoint 프로토콜에 의존하여, 서로 다른 여러 개의 Endpoint를 추가하는 것 만으로 APIClient의 코드 변경 없이 기능 확장이 가능함
• 그러나 오버엔지니어링된 추상화는 복잡도를 높이고, 잘못 설계될 경우 생산성을 저하시킨다.
  • 간단한 계산기 기능을 만들 때 각 연산을 추상화할 필요가 있을까?

적절한 균형 잡기

• 결국 추상화의 목적은 복잡한 시스템을 이해하기 쉬운 단순한 형태로 제공해 가독성, 재사용성, 유지보수성을 향상하는 것이다.
• 이를 위해서는 최대한 현재 필요한 기능에 대해서만 추상화를 진행하고, 아직 쓰이지 않는 부분에 대해 미리 에측해서 추상화를 진행하지 않는 것이 좋겠다고 생각했다.
• 또한 한 번에 모든 구조를 설계하려고 하기 보단, 작은 구조로 시작해 계속해서 수정하며 점차 큰 구조로 발전시켜나가는 것이 좋겠다고 생각된다.

정리

• 오버엔지니어링을 피하기 위해서는, 현재 필요한, 그리고 예측가능한 추상화에만 집중하고, 작은 구조에서 큰 구조로 점진적으로 발전시켜 나가며 적절한 수준의 추상화를 유지해 나가는 전략이 적절해 보인다...!