FeelTalk - Base URL 설계 리팩토링
✍️ Introduction
이 글은 FeelTalk 프로젝트에서 네트워크 요청의 기준이 되는 Base URL을 static 프로퍼티로 관리하던 초기 설계를 되돌아보고, OCP(Open–Closed Principle) 관점에서 이를 리팩토링한 과정을 정리한 기술 문서입니다.
🧱 Background
프로젝트 초기 FeelTalk의 네트워크 구조는 모든 API 요청을 단일 서버 대상으로 했으며, 실행 환경에 따른 분기나 서버 교체를 고려할 필요가 없었습니다.
이러한 맥락에서 네트워크 통신에 필요한 BASE_URL은 다음과 같이 static 프로퍼티로 정의해 사용했습니다.
// file: "Code01"
final class ClonectAPI {
static var BASE_URL: String { "https://example.com" }
}
당시 이러한 구조는 다음과 같은 이유로 합리적이라 판단했습니다.
- 단일 서버 환경으로 인해 BASE_URL의 변경이 낮음
- 전역으로 접근 가능한
static프로퍼티를 통해 간편하게 참조 - 네트워크 요청 코드 전반에서 중복 없이 동일한 값을 사용할 수 있음
즉, 현재 요구사항을 만족하는 가장 단순한 설계라는 관점에서 해당 구조를 적용했습니다.
그러나 이후 Router 패턴을 도입하고, API 요청 명세를 구조적으로 분리하는 과정에서 BASE_URL 관리 방식이 갖는 설계적 한계를 인지했습니다.
특히 BASE_URL이 static 프로퍼티로 고정되어 있다는 점은 다음과 같은 문제를 초래했습니다.
- 네트워크 실행 환경(Dev/Prod)에 따른 유연한 확장이 불가
- 새로운 요구사항이 추가될 경우 기존 코드를 수정
이러한 한계는 Base URL 관리 방식이 새로운 요구사항에 닫혀 있고, 확장에 열려 있지 않다는 점에서 설계 관점의 문제로 이어졌습니다.
특히 실행 환경에 따라 다른 Base URL이 필요해질 경우, 기존 코드를 수정하지 않고는 대응할 수 없다는 점은 OCP(Open–Closed Principle)가 지향하는 방향과 어긋나는 구조였습니다.
