Leaky Abstractions

추상화(Abstraction)란

• 복잡하고 광범위한 개념을 단일한 아이디어 뒤에 숨기는 기법
• 불필요한 세부 구현을 제거하고, 사용하기 쉬운 API를 노출
• 복잡한 개념을 쉽게 이해하고 소통할 수 있도록 해주는 강력한 개념
• 이상적인 추상화는 블랙박스: 계약(contract)에 따라 사용하면 기대한 결과를 얻음

누수 추상화(Leaky Abstraction)란

• 용어 최초 제안: Joel Spolsky (2002)
• 정의: 숨겨야 할 세부 구현을 완전히 캡슐화하지 못하는 추상화
• 누수가 발생하면 소비자(consumer)는 숨겨져야 할 불필요한 내부 세부 사항을 인지하게 됨
• 핵심 원칙: 숨기려는 로직이 복잡할수록 누수 가능성이 높아짐
• 모든 추상화는 어느 정도 세부 사항을 누수함 — 완전한 캡슐화는 사실상 불가능

누수 추상화 예시

일상적 예시: 컴퓨터 OS

• 컴퓨터는 운영체제(OS)를 통해 복잡성을 숨기는 추상화
• 사양을 초과하는 게임을 실행하려 할 때 블랙박스 내부(하드웨어 스펙)를 이해해야만 함
• → 추상화가 “누수”되어 내부 구현 지식이 필요해지는 순간

소프트웨어 예시 1: Axios 라이브러리

• axios는 브라우저의 fetch API를 감싸는 JavaScript 라이브러리
• fetch의 동작: 응답이 반환되기만 하면 에러로 간주하지 않음 (404, 500도 정상 응답으로 처리)
• axios의 동작: 성공 상태 코드가 아닌 응답은 에러로 처리
• 이 차이를 모르면 axios를 올바르게 사용하기 어려움
• → 내부 동작 방식(fetch의 특성)을 알아야만 추상화를 제대로 활용 가능

소프트웨어 예시 2: ORM

• ORM의 목적: SQL 작성의 복잡성을 객체와 메서드로 숨기는 것
• 일반적인 쿼리에서는 내부 SQL을 몰라도 됨
• 누수 시점: 복잡한 쿼리가 필요할 때 ORM이 원하는 성능을 제공하지 못함
• → 내부 SQL 생성 방식을 이해하고 대안을 찾아야 하는 상황 발생

누수 추상화에 대한 대응

“모든 복잡한 소프트웨어는 어느 정도 누수 추상화를 가질 수밖에 없다.”

복잡성 줄이기 (Remove Complexity)

• 추상화 품질은 숨기는 복잡성의 양에 비례
• 복잡성을 줄이면 누수 가능성도 줄어듦
• 단, 적용 가능한 경우가 한정됨:
  • 우리가 만든 아키텍처 문제라면 → 리팩토링으로 개선 가능
  • 비즈니스 로직의 본질적 복잡성이라면 → 줄이기 불가능

새로운 레이어 추가 (Create Another Layer)

• 누수되는 추상화 위에 또 다른 추상화 레이어를 추가하는 방법
• 내부 지식 없이 사용 가능한 API를 새로 제공
• 주의사항:
  • 레이어 추가 시 전체 소프트웨어 복잡성이 증가
  • 새 레이어가 모든 누수를 해결하지 못하면 더 복잡하고 관리하기 어려운 상황 초래
  • 신중하게 결정해야 함

결론: 누수 추상화는 괜찮다

• 누수 추상화는 코드 스멜(code smell)이나 안티패턴이 아님
• 복잡한 소프트웨어에서는 피할 수 없는 현상
• 시간이 지나면서 과거 기술의 추상화 위에 쌓아가며 누수를 점점 최소화하는 방향으로 발전

핵심 요약