iOS 개발자의 웹 적응기 - 낯선 코드에서 익숙한 구조를 발견하기까지

안녕하세요. Fromm 프론트엔드 개발자 박지민입니다.

올해 초 iOS 개발에서 웹 프론트엔드 개발로 업무를 전환하게 되면서 새로운 프로젝트를 접하게 되었습니다. 웹 개발을 시작하기 전에는 언어와 프레임워크뿐 아니라 애플리케이션을 구성하는 아키텍처 역시 iOS와는 상당히 다를 것이라고 생각했습니다. Swift에서 TypeScript로, UIKit에서 React로 개발 환경이 바뀌었기 때문에 기존에 익숙했던 설계 방식도 대부분 새롭게 익혀야 할 것이라 예상했습니다.

하지만 실제 프로젝트의 코드베이스를 분석하면서 예상과는 다른 점을 발견했습니다.

// queries/arti/useGetArtiTrial/index.ts
const useGetArtiTrial = () =>
  useSuspendedQuery({
    queryKey: ["getArtiTrial"],
    fn: (signal) => getArtiTrial(signal).then(ArtiTrialVo.from),
  });

처음에는 서버 데이터를 조회하는 React의 Custom Hook 정도로 이해했습니다. 하지만 구현을 따라가다 보니 데이터를 조회하고, 프론트엔드에서 사용할 객체로 변환한 뒤, 컴포넌트에 전달하는 흐름이 iOS에서 익숙했던 구조와 상당히 유사하다는 점을 확인할 수 있었습니다.

이후 프로젝트의 다른 영역들도 함께 살펴보면서 관심사를 분리하고, 레이어를 독립시키며, 의존성을 관리하는 방식 역시 모바일 개발에서 사용했던 설계 원칙과 공통점이 있다는 점을 확인할 수 있었습니다.

이번 글에서는 iOS 개발 경험을 기준으로 웹 프론트엔드 프로젝트를 분석하면서 발견한 구조적 유사성과 두 플랫폼의 차이점을 정리해보려고 합니다.

비교의 기준이 된 iOS 구조

웹 프로젝트를 이해하기 위해 먼저 제가 익숙했던 iOS 프로젝트 구조부터 간단히 살펴보겠습니다.

Fromm iOS 앱은 Clean Architecture를 기반으로 Presentation, Domain, Data 세 개의 레이어로 구성되어 있습니다.

• Presentation: 화면과 상태를 관리
• Domain: UseCase를 통해 비즈니스 로직을 수행
• Data: Repository를 통해 API와 로컬 데이터를 관리

핵심은 계층 간 책임을 분리하고, 의존성을 한 방향으로 유지하는 것입니다. 예를 들어 ViewModel은 UseCase를 호출하고, UseCase는 Repository를 통해 데이터를 조회합니다.

final class FanProfileEditViewModel: BaseViewModel {
    @Inject private var loadFanProfileUseCase: LoadFanProfileUseCase
    @Inject private var updateFanProfileUseCase: UpdateFanProfileUseCase
}

이 구조를 기준으로 웹 프로젝트의 데이터 흐름을 하나씩 살펴보았습니다.

웹 프로젝트를 처음 봤을 때

처음 프로젝트 구조를 봤을 때는 각 디렉터리의 역할을 바로 이해하기 어려웠습니다.

src/
├── app/
├── api/
├── vo/
├── queries/
├── hooks/
└── components/

api/와 components/의 역할은 비교적 직관적이었지만 queries/, vo/, hooks/는 각각 어떤 계층을 담당하는지 바로 이해하기 어려웠습니다.

처음에는 다음과 같이 추측했습니다.

• queries/ → Repository
• vo/ → DTO
• hooks/ → UseCase

하지만 실제 구현은 제 예상과 달랐습니다. 디렉터리 이름만으로 구조를 이해하기보다는 API 요청부터 화면 렌더링까지 데이터가 어떻게 전달되는지를 따라가면서 각 계층의 역할을 확인해 보기로 했습니다.

데이터 흐름을 따라가며 본 구조

아티스트 정보를 조회하는 기능을 기준으로 살펴보았습니다.

1. API Layer

export const getArti = (artiPath: string, signal?: AbortSignal) =>
  nativeFetch<GetArtiResponse>({
    url: `/arti/${artiPath}`,
    signal,
  });

가장 아래에서는 API와 통신하여 서버 응답을 가져옵니다. 이 역할은 iOS의 Network Data Source와 유사했습니다.

2. VO Layer

class ArtiVo {
  readonly id: string;
  readonly name: string;

  static from(response: GetArtiTrial): ArtiVo {
    return new ArtiVo(response);
  }

  private constructor(response: GetArtiTrial) {
    this.id = response.id;
    this.name = response.name;
  }
}

여기서는 서버 응답을 프론트엔드에서 사용할 객체로 변환합니다.

TypeScript는 구조적 타입 시스템(Structural Typing)을 사용하기 때문에, 구조가 같으면 같은 타입으로 간주합니다. 이 때문에 서버 응답 타입과 내부 모델이 우연히 같은 구조를 가질 경우 경계가 흐릿해질 수 있습니다.

VO.from()과 private constructor 조합은 이 경계를 코드 레벨에서 명시적으로 강제하는 방식입니다. 반드시 from()을 통해서만 생성할 수 있도록 제한함으로써, Structural Typing 환경에서도 서버 응답과 프론트엔드 내부 모델을 분리할 수 있습니다. iOS에서는 Mapper와 Domain Model을 분리해서 사용하는 경우가 많았는데, 웹 프로젝트에서는 VO가 이러한 역할을 함께 수행하고 있었습니다.

3. Query Layer

const useGetArtiTrial = () =>
  useSuspendedQuery({
    queryKey: ["getArtiTrial"],
    fn: (signal) =>
      getArtiTrial(signal).then(ArtiTrialVo.from),
  });

Query는 API를 호출하고, 응답을 VO로 변환한 뒤, 컴포넌트가 사용할 수 있는 형태로 제공합니다. 이러한 흐름은 하나의 기능 단위를 캡슐화한다는 점에서 iOS의 UseCase와 역할이 일부 유사했습니다.

다만 두 구조를 동일한 개념으로 볼 수는 없습니다. iOS의 UseCase는 일반적으로 상태를 보관하지 않는 비즈니스 로직입니다. 반면 React Query 기반의 Query Layer는 서버 상태를 캐싱하고, 재요청을 관리하며, 데이터의 유효 기간까지 함께 관리합니다.

즉, Query Layer는 UseCase와 유사한 역할을 수행하면서도 서버 상태 관리(Server State Management)라는 웹 환경의 책임을 함께 가지고 있었습니다.

구조 비교 요약

역할	iOS	Web
외부 데이터 조회	Repository / Data Source	api/
데이터 변환	Mapper	VO.from()
내부 데이터 모델	Domain Model	VO
기능 단위	UseCase	Query
화면 상태	ViewModel	Custom Hook
UI	UIViewController / SwiftUI	Component

물론 이 표는 개념적인 대응 관계일 뿐이며, 두 구조가 동일한 아키텍처라는 의미는 아닙니다.

DI도 다른 방식으로 존재하고 있었다

iOS에서는 Protocol과 DI Container를 이용해 의존성을 주입하는 경우가 많습니다.

@Inject private var loadFanProfileUseCase: LoadFanProfileUseCase

반면 웹 프로젝트에서는 대부분 ES Module을 이용해 필요한 모듈을 직접 가져옵니다.

import { getArtiTrial } from "api/arti";
import { ArtiTrialVo } from "vo/arti/ArtiTrial.vo";

ES Module 자체는 DI 메커니즘은 아닙니다. 하지만 의존성을 명확하게 분리하고 결합도를 낮추려는 목적은 iOS와 크게 다르지 않았습니다.

테스트 방식에서도 차이가 있었습니다. iOS에서는 Protocol 기반 Mock 객체를 주입하는 방식이 일반적이라면, 웹에서는 MSW(Mock Service Worker) 등을 이용해 네트워크 자체를 모킹하는 방식을 많이 사용했습니다. 접근 방식은 다르지만 외부 환경과의 결합을 줄여 테스트 가능성을 확보한다는 목적은 공통적이었습니다.

마무리

프로젝트를 이해하기 위해 데이터의 흐름을 따라가다 보니, 처음에는 낯설게 보였던 구조들이 하나씩 익숙한 역할로 읽히기 시작했습니다.

물론 React Query를 UseCase로, VO를 Domain Model로 단순히 대응시킬 수는 없습니다. 각 기술은 자신이 속한 생태계의 특성과 요구사항에 맞게 서로 다른 방식으로 문제를 해결하고 있기 때문입니다.

다만 플랫폼은 달라도 관심사를 분리하고, 데이터의 흐름을 관리하며, 외부 변화로부터 핵심 로직을 보호하려는 설계 원칙은 크게 다르지 않았습니다. 사용하는 기술과 구현 방식은 달라도 복잡성을 관리하기 위한 고민은 비슷한 방향을 향하고 있었습니다.

이번 경험을 통해 새로운 플랫폼을 이해할 때는 사용하는 기술보다 데이터가 어떻게 흐르고, 각 계층이 어떤 역할을 담당하는지를 먼저 살펴보는 것이 구조를 이해하는 데 도움이 된다는 점을 느꼈습니다.