2-1. 인터페이스 설계와 구현 설계

해당 포스트는 이규원님의 "Spring Boot TDD" 강의를 기반으로 작성하였습니다.

Spring Boot TDD - 입문부터 실전까지 정확하게| 이규원 - 인프런 강의

---

1. 프로그래머의 설계

￮ 프로그래머는 소프트웨어 개발 과정에서 지속적으로 설계를 합니다.
￮ 특히 인터페이스 설계와 구현 설계는 업무의 큰 부분을 차지하며, 소프트웨어의 품질과 유지보수성에 핵심적입니다.

이 글에서는 시스템의 기본 개념부터 시작해 인터페이스와 구현 설계의 특징, 리팩터링의 정의와 역할, 그리고 리디자인과의 비교를 단계적으로 설명하겠습니다. 이를 통해 프로그래머가 실무에서 어떻게 적용할 수 있는지 이해하기 쉽게 풀어보겠습니다.

---

2. 시스템의 정의: 상호작용하는 단위

￮ 시스템은 특정 목적을 달성하기 위해 내부 구성요소들이 함께 상호작용하는 단위입니다.
￮ 간단히 말해, "함께 작동하는 부분들의 모임"으로, 외부와 구분되는 경계를 가집니다.

• 경계와 인터페이스: 시스템은 경계를 통해 외부와 소통합니다. 이 경계에 배치된 인터페이스가 외부와의 연결점 역할을 합니다. 예를 들어, 응용 프로그램의 API나 클래스의 public 메서드가 이에 해당합니다.
• 하위 시스템 구성: 하나의 시스템은 여러 하위 시스템으로 나뉩니다. 큰 단위로는 모듈이나 애플리케이션, 작은 단위로는 클래스나 함수가 됩니다. 이들은 모두 목적을 위해 협력합니다.

---

3. 클라이언트의 정의: 기능을 사용하는 주체

￮ 시스템이 제공하는 기능을 사용하는 주체입니다.
￮ 인터페이스를 통해 시스템에 접근합니다.
￮ 시스템을 이용하며 대가를 지불하는 고객이나 조직 내부의 동료 등 사용자가 있습니다.
￮ 외부 응용프로그램이나 한 클래스를 사용하는 다른 클래스 등이 있습니다.

￮  클라이언트의 유형
      - 인간 클라이언트: 사용자(고객이나 내부 동료)로, UI(유저 인터페이스)를 통해 상호작용.
      - 시스템 클라이언트: 다른 프로그램이나 클래스(예: 한 클래스를 호출하는 다른 클래스.

 

---

4. 인터페이스 설계의 특징: 클라이언트 중심 소통

￮ 인터페이스는 시스템과 클라이언트 간의 "소통 약속"입니다.
￮ 클라이언트가 시스템을 사용하는 창구로, 설계 시 클라이언트의 요구를 최우선으로 반영합니다.
￮ 인터페이스의 유형:
      - 인간 대상: UI(유저 인터페이스)로, 사용자 경험을 고려한 디자인(예: 버튼, 메뉴).
      - 기계 대상: API(애플리케이션 프로그래밍 인터페이스)로, 클래스 public 메서드나 웹 서비스 엔드포인트.

 

￮ 클라이언트 중심 설계:
  - 인터페이스는 클라이언트의 요구사항(기능, 편의성)을 반영합니다. 자연스러운 결과로, 클라이언트의 필요가 설계를 주도합니다.
￮ 변경의 여파: 인터페이스 변경 시 클라이언트에 직접 영향(예: UI 변경 시 사용자 혼란, API 변경 시 호출 코드 수정).
￮ 제약 요인: 클라이언트의 의사결정권이 강하거나 변경 수용 의사가 없을 때, 인터페이스 수정이 불가능할 수 있음. 이 경우 대안을 모색해야 합니다.
￮ 왜 중요한가?: 인터페이스는 시스템의 "얼굴"입니다. 클라이언트 만족을 위해 안정적이고 직관적으로 설계하면, 시스템 전체 신뢰성이 높아집니다.

---

5. 구현 설계의 특징: 내부 기능 충족과 유연성

￮ 구현 설계는 인터페이스를 통해 제공되는 기능을 실현하는 내부 구조입니다.
￮ 클라이언트에게 보이지 않지만, 시스템의 핵심 동작을 담당합니다.
￮ 구현 설계는 인터페이스를 통해 제공되는 기능 요구사항을 충족시킵니다.
￮ 구현 설계는 비기능 요구사항도 충족시키며 제작공정의 품질에 영향을 줍니다.
￮ 변경 여파가 미치는 범위가 시스템 내부로 한정됩니다.
￮ 대안의 폭이 넓고 변경이 잦습니다.

---

4. 리팩터링의 정의: 내부 개선을 위한 작업

￮ 리팩터링은 기능과 인터페이스를 유지하면서 구현 설계를 변경하는 활동입니다. 프로그래머가 자주 언급하지만, 과도한 강조는 설계 문제 신호일 수 있습니다.

￮ 요구사항 변경 없이 제작 공정 품질(코드 품질, 성능)을 높이기 위한 작업. 기능과 인터페이스는 그대로 둡니다.
  - 영향 범위: 클라이언트에 영향 없음(인터페이스 변하지 않음).
  - 진행 방식: 일상적 코딩 일부로 수시 수행. 별도 자원 할당이나 계획 불필요.
  - 왜 중요한가?: 코드 품질 향상으로 버그 감소, 유지보수 용이. 하지만 리팩터링 과도 시 설계 자체 재검토 필요.

---

5. 리디자인과의 비교: 변경 범위와 영향

￮ 리디자인(재설계)은 리팩터링과 달리 인터페이스나 기능까지 변경하는 광범위한 작업입니다.
  - 리팩터링: 내부 구현만 변경, 클라이언트 영향 없음. 자원 소비 적음, 수시 진행.
  - 리디자인: 인터페이스 변경 포함, 클라이언트에 여파(코드 수정 필요). 자원 소비 크며, 계획적 할당 필요.
  - 왜 구분하나?: 리디자인은 시스템 전체 영향으로 신중히 접근. 리팩터링은 일상적 개선 도구.
  - 왜 중요한가?: 변경 범위에 따라 접근법 달리하면 자원 낭비 피함. 리디자인은 전략적, 리팩터링은 전술적.