멀티테넌시의 60년 진화: 테넌트 단위는 왜 계속 작아졌는가
멀티테넌시(Multi-tenancy)의 역사는 곧 "자원을 누가, 얼마나 잘게 나눠 쓰는가"의 역사다. 1960년대 메인프레임 시분할(time-sharing) 시스템은 하나의 거대한 기계를 여러 사용자가 공유하는 구조였다. 이후 가상 머신(VM)이 등장하며 테넌트의 단위는 조직에서 팀으로, 팀에서 서비스 단위로 점점 쪼개졌다. 컨테이너와 쿠버네티스가 보편화된 시대에 이르러서는 마이크로서비스 하나하나가 독립된 테넌트처럼 운영되기 시작했다.
이 흐름에서 백엔드 개발자가 체감한 실질적인 목표는 "개발자 1인당 독립 환경(per-developer environment)" 이었다. 로컬 개발 환경과 프로덕션 환경의 괴리를 줄이기 위해, 각 개발자가 자신만의 격리된 DB, API 서버, 메시지 브로커를 갖는 구조가 이상적인 모델로 여겨졌다. docker-compose, 네임스페이스 기반 쿠버네티스 격리, 혹은 Neon·PlanetScale 같은 브랜치 가능한 DB 서비스가 이 목표를 현실로 당겨왔다.
# 개발자별 네임스페이스 격리 예시 (Kubernetes)
apiVersion: v1
kind: Namespace
metadata:
name: dev-johndoe
labels:
environment: development
owner: johndoe
에이전트의 등장이 바꿔놓은 전제
문제는 최근 AI 에이전트가 개발 파이프라인에 본격적으로 개입하면서 이 "개발자 1인 = 테넌트 1개" 공식이 흔들리기 시작했다는 점이다. 에이전트는 단일 개발자의 맥락 안에서도 병렬로 여러 작업 스트림을 동시에 실행한다. 코드 리뷰, 테스트 생성, 리팩터링 제안이 동시에 진행된다면, 하나의 개발자 환경 안에서도 격리가 필요한 변경(change) 단위가 폭발적으로 늘어난다.
이는 백엔드 설계 관점에서 중요한 시사점을 던진다. 기존에는 "개발자 수 × 서비스 수"로 환경 수를 추산할 수 있었다. 하지만 에이전트 시대에는 동시에 실행 중인 에이전트 워크스트림 수까지 곱해야 한다. 결국 테넌트의 단위는 개발자에서 "변경 단위(unit of change)" 로 다시 한번 이동하게 된다.
// 변경 단위별 격리 컨텍스트 예시 (개념적 표현)
public class ChangeContext {
private final String changeId; // 에이전트 작업 단위 ID
private final String developerId;
private final DataSource isolatedDataSource; // 변경별 독립 DB 연결
// ...
}
백엔드 개발자가 지금 주목해야 할 설계 방향
이 변화는 단순한 인프라 트렌드가 아니라 애플리케이션 아키텍처 설계에도 영향을 미친다. 환경 격리를 코드 레벨에서 어떻게 표현할 것인지, 테넌트 컨텍스트를 어떻게 전파할 것인지가 다시 중요한 설계 결정이 된다.
실무적으로 고려할 수 있는 방향은 다음과 같다:
- 컨텍스트 전파 표준화:
ThreadLocal, MDC, 또는 리액티브 환경에서의Context를 활용해 변경 단위 ID를 전계층에 전파하는 구조 - 데이터 격리 수준 재검토: 스키마 기반 멀티테넌시에서 더 가벼운 row-level 격리 또는 브랜치 DB로의 전환 검토
- 환경 생명주기 자동화: 에이전트 작업이 시작/종료될 때 환경을 동적으로 프로비저닝·해제하는 파이프라인 설계
- 비용 모델 재산정: 환경 수가 기하급수적으로 늘어날 수 있으므로, 경량 격리(컨테이너 < 프로세스 < 스레드)의 트레이드오프를 명확히 파악
정리
- 멀티테넌시의 테넌트 단위는 60년간 지속적으로 작아져 왔으며, 최근까지의 목표는 "개발자 1인당 독립 환경"이었다.
- 에이전트의 병렬 워크스트림 등장으로 테넌트 단위가 개발자에서 변경(change) 단위로 다시 이동하고 있다.
- 백엔드 설계 차원에서 컨텍스트 전파, 데이터 격리 전략, 환경 생명주기 자동화를 선제적으로 재검토해야 할 시점이다.