DIP on Kelly Dev

dev-data-server-light. 0. Concept

Wed, 24 Jun 2026 00:00:00 +0000

시작하기

iOS 프로젝트를 진행하다 보면 생각보다 자주 간단한 API 서버가 필요해진다. 회원가입 화면을 만들거나, 목록 조회 기능을 붙이거나, 이미지 업로드를 테스트할 때도 서버가 필요하다. 물론 실제 백엔드를 구축할 수도 있고, Supabase나 Firebase 같은 BaaS를 사용할 수도 있다. 하지만 작은 개인 프로젝트나 프로토타입 단계에서는 좋은 설계는 아니라고 생각한다.

특히 처음부터 특정 서비스에 의존하기 시작하면, 정작 내가 만들고 싶은 앱의 기능보다 인프라 설정과 서비스 사용법을 익히는 데 더 많은 시간을 쓰게 된다. 앱 개발을 위한 도구가 필요했는데, 어느 순간 도구를 사용하기 위한 공부를 하고 있는 상황이 되는 것이다.

dev-data-server-light. 2. Database CRUD

Tue, 30 Jun 2026 00:00:00 +0000

시스템 모듈을 만든 이후에, 아마도 가장 많이 쓰게 될 DB 모듈을 만들었다.

당시에는 구조도 시스템 모듈과 동일하다고 생각했다. Router가 DB 인터페이스에 의존하고, 이를 구현한 구현체를 주입받는 방식으로 DIP와 DI를 동시에 적용했다.

이 과정 중에서

naming bias 해결하기
id 생성 책임 위치
기존 아키텍처의 문제점 -> 서비스 레이어 도입해서 해결하기

에 대한 고민을 했다. 아래는 고민과 해결 과정이다.

CRUD부터 만들기

Mock Server라도 최소한 CRUD는 제공해야 한다. 처음부터 구현체를 만들 필요는 없으므로, 라우터와 인터페이스까지만 만들도록 프롬프트를 작성했다.

dev-data-server-light. 3. Database Implementation

Thu, 02 Jul 2026 00:00:00 +0000

DB 모듈의 인터페이스와 서비스 레이어를 만들었으므로, 실제 구현체를 만들어야 한다. 우선 인 메모리(In-Memory)로 가볍게 구현체를 만들었다.

인 메모리 데이터 저장소

인 메모리 방식을 선택한 이유는 첫째로 처음부터 SQL이나 JSON 파일 기반 저장소를 이용해서 구현체를 만드는 것 보다는, 가장 단순한 구현체를 만들어서 DB 기능을 검증하고 빠르게 다음 기능을 만들기 위해서이다. 외부 의존성도 없고, 설정도 필요 없고, 테스트도 쉽다.

구현하기

RecordStore 인터페이스를 다시 보면 다음과 같다.

export interface RecordStore {
 list(collection: string): Promise<StoredRecord[]>;
 get(collection: string, id: string): Promise<StoredRecord | undefined>;
 create(collection: string, data: RecordData): Promise<StoredRecord>;
 replace(collection: string, id: string, data: RecordData): Promise<void>;
 delete(collection: string, id: string): Promise<boolean>;
}

구현체는 이 계약을 그대로 만족하면 된다. 중요한 것은 구현체는 Express를 몰라야하고 순수하게 TypeScript 코드로 짜여야 한다. HTTP 요청이나 라우팅 같은 것은 Router가 책임져야 한다.

dev-data-server-light. 4. File Storage

Thu, 02 Jul 2026 00:00:00 +0000

DB 모듈을 마무리하고, 다음으로 구현한 것은 File Storage 모듈이다. DB 모듈과 크게 다르지 않을 것이라고 생각했다. 우선 CRUD 비슷한 메소드를 처리하고, 구조는 DB 모듈에서 충분히 다듬었기 때문이다. 하지만 실제로는 DB보다 인터페이스를 어떻게 정의할 것인지에 대한 고민이 더 많았다.

인터페이스 만들기

처음 작성한 프롬프트는 다음과 같다.

Create the initial FileStorage contract in src/storage.

Requirements:

- Define a FileStorage interface.
- The interface is responsible only for storing and retrieving binary file contents.
- It should not manage file metadata, ids, ownership, permissions, or database records.
- Use Buffer for file contents.
- Include only the minimal operations required for file storage:
 - save(path: string, content: Buffer): Promise<void>
 - read(path: string): Promise<Buffer>
 - delete(path: string): Promise<void>
 - exists(path: string): Promise<boolean>
- Add minimal domain errors if necessary.

For this step, create only the contract and related types.
Do not implement any storage implementation yet.

로컬 파일 시스템을 의식하고 있어서 의심 없이 path라는 이름을 사용했는데, 이 때문에 인터페이스가 구현체를 닮아버리게 되었다. path는 과연 인터페이스를 대표할 수 있는 네이밍인가?

devbox-light-server (5). Auth

Sat, 08 Aug 2026 16:27:42 +0900

Auth 설계하기

개발용 목서버에서 실제 서비스 수준의 인증 시스템을 구현하지 않고도, 클라이언트에서 사용하는 로그인과 인증 흐름을 테스트할 수 있도록 Auth 기능을 추가했다.

로그인 요청을 보낸다.
access token을 발급받는다.
Authorization 헤더에 token을 실어 요청한다.
현재 로그인된 유저를 확인한다.
로그아웃으로 token을 무효화한다.

JWT, 비밀번호, OAuth, Refresh Token, 보안 같은 기능은 의도적으로 제외했다. 프로덕션 인증 로직을 구현하려는 글이 아니라, 개발용 Mock 서버에서 클라이언트의 로그인, 인증, 로그아웃 흐름을 확인하는 것이 목적이기 때문이다.

최소한의 Auth 구조

첫 단계에서는 DatabaseService를 그대로 사용했다. users 컬렉션을 만들어서 그 레코드 ID를 유저 ID로 사용해 로그인할 수 있도록 했다.

devbox-light-server (6). Json 영속성

Mon, 10 Aug 2026 14:14:08 +0900

MVP의 마지막 기능으로 서버를 재시작해도 데이터가 사라지지 않도록 영속성을 추가했다.

이번 포스트에서는 devbox-light-server에 DB, Storage, Token Storage에서 영속성을 가진 저장 방식을 구현해서 in-memory 대신 사용할 수 있도록 만든다.

프로토타입이었던 dev-data-server에서는 시작부터 SQL 의존성을 가지고 시작했지만, devbox-light-server는 아주 얇은 in-memory 구현만 가지고 있다.

MVP 마지막에 영속성을 넣는 이유는 서버를 구현할 때, 특정 구현에 휘둘리지 않기 위해서다. dev-data-server에서 SQL을 빠르게 들여와서, 결국 프로젝트가 SQL 래퍼가 된 느낌이 있다.

당연히 Service 레이어는 Repository의 인터페이스에만 의존하므로 어떤 방법을 쓰든 단순히 구현체만 갈아 끼우고, 의존성 생성, 연결 부분을 제외하고는 어떠한 코드에도 변화가 없어야 한다.

devbox-light-server (7). Dockerizing, MVP 마무리

Mon, 10 Aug 2026 17:42:56 +0900

도커라이징

영속성까지 추가했으므로 이제 서버를 하나의 실행 단위로 묶을 차례다.

지금까지는 로컬에서 Node.js를 설치하고, 의존성을 설치하고, TypeScript를 빌드한 다음 서버를 실행했다. 혼자 개발할 때는 큰 문제가 없지만, 이 서버를 다른 환경에서 실행하려면 매번 같은 준비 과정을 반복해야 한다.

도커라이징은 이 과정을 이미지 안에 고정하는 작업이다. 이 프로젝트에서는 Express 서버를 빌드하고, 실행에 필요한 파일만 담은 뒤, .data 디렉터리를 기준으로 데이터를 유지할 수 있도록 구성했다.

Dockerfile 작성하기

Dockerfile은 두 단계로 나눴다.

FROM node:24-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY tsconfig.json tsconfig.build.json ./
COPY src ./src
RUN npm run build

첫 번째 build 단계에서는 개발 의존성을 포함해서 설치하고 TypeScript를 빌드한다. npm run build를 실행하면 dist 디렉터리가 만들어진다.

Software Engineering. DI와 DIP

Thu, 27 Mar 2025 00:00:00 +0000

의존성 주입(Dependency Injection)

의존성 주입은 객체가 필요한 의존성을 내부에서 직접 생성하지 않고 외부에서 전달받는 방식이다. 별도의 DI 프레임워크나 주입 전용 객체가 반드시 필요한 것은 아니다. 생성자를 통해 객체를 전달하는 것만으로도 의존성 주입이 된다.

의존의 의미

A → B: A가 B에 의존한다.

A가 동작하기 위해 B의 타입이나 기능을 사용한다면 A는 B에 의존한다. B의 공개 인터페이스가 바뀌면 A도 영향을 받을 수 있다.

다음 코드에서 Greeter는 구체 타입인 EnglishGreetingProvider를 직접 생성한다.

final class EnglishGreetingProvider {
 func greeting() -> String {
 "Hello, World!"
 }
}

final class Greeter {
 private let provider = EnglishGreetingProvider()

 func greet() {
 print(provider.greeting())
 }
}

이 구조에서는 구현을 교체하거나 테스트 대역을 사용하려면 Greeter를 직접 수정해야 한다.