프로젝트 방식의 한계: 플랫폼이 커지면 무엇이 문제가 되는가
백엔드 플랫폼이 단일 팀의 범위를 넘어 여러 팀이 함께 사용하는 공유 인프라로 성장하면, 기존의 프로젝트 중심(project-thinking) 접근 방식은 빠르게 한계를 드러낸다. 프로젝트 방식은 기본적으로 "요구사항 정의 → 개발 → 납품"의 일회성 사이클로 운영된다. 이 구조에서는 납품 이후 해당 기능이 실제로 잘 사용되는지, 어떤 문제가 발생하는지를 체계적으로 추적하기 어렵다.
실제로 나타나는 문제는 세 가지로 압축된다.
- 일회성 납품(one-off deliveries): 플랫폼 기능이 특정 팀의 요청에 맞춰 개별적으로 개발되고, 이후 유지보수와 발전 방향이 불분명해진다.
- 제품 비전 부재: 누가 이 플랫폼을 어떤 방향으로 이끌어가야 하는지에 대한 오너십이 흐릿해진다.
- 피드백 루프 취약: 사용 팀이 불편함을 느껴도 이를 플랫폼 개선으로 연결하는 채널이 없어, 같은 문제가 반복된다.
제품 사고(Product Thinking)로의 전환: 셀프서비스와 API 중심 설계
이 문제를 해결하기 위한 전환의 핵심은 플랫폼을 **내부 제품(internal product)**으로 취급하는 것이다. 외부 고객을 대상으로 하는 SaaS 제품을 운영하듯, 내부 사용 팀을 "고객"으로 정의하고 그에 맞는 운영 구조를 갖추는 것이다.
기술 구조 측면에서는 API 중심의 멀티테넌트 인프라로의 전환이 핵심이다. 사용 팀이 플랫폼 팀에 매번 요청을 넣지 않아도 되도록, 셀프서비스 방식으로 리소스를 프로비저닝하고 설정할 수 있는 API를 제공한다.
// 예: 셀프서비스 테넌트 등록 API 엔드포인트
@PostMapping("/api/v1/tenants")
public ResponseEntity<TenantResponse> registerTenant(
@RequestBody @Valid TenantRegistrationRequest request) {
TenantResponse response = tenantService.register(request);
return ResponseEntity.status(HttpStatus.CREATED).body(response);
}
이처럼 플랫폼 기능을 API로 명확히 노출하면, 소비 팀은 플랫폼 내부 구현에 의존하지 않고 계약(contract) 기반으로 연동할 수 있다. 이는 팀 간 결합도를 낮추고, 플랫폼 팀이 내부를 자유롭게 개선할 수 있는 여지를 만들어준다.
소유권과 추상화 수준의 재정의
제품 방식으로 전환할 때 기술적 설계만큼 중요한 것이 소유권(ownership)의 명확화다. 플랫폼의 어느 부분을 누가 책임지는지, 어떤 팀이 로드맵을 결정하는지가 분명해야 피드백이 실제 개선으로 연결된다.
추상화 수준도 재검토가 필요하다. 플랫폼이 너무 저수준의 인프라만 노출하면 사용 팀의 인지 부하가 높아진다. 반대로 너무 고수준으로 추상화하면 유연성이 떨어진다. 제품 사고 전환 과정에서는 사용 팀의 실제 워크플로우를 분석하여 적절한 추상화 경계를 찾는 것이 중요하다.
# 셀프서비스 인프라 선언 예시 (IaC 기반)
tenant:
id: team-payments
tier: standard
resources:
database: postgres-small
cache: redis-256mb
이런 선언적 방식은 사용 팀이 플랫폼을 쉽게 소비하면서도, 플랫폼 팀이 내부 구현을 통제할 수 있는 균형점을 제공한다.
정리
- 플랫폼이 다수 팀에서 사용되는 시점부터 프로젝트 방식은 한계에 부딪히며, 내부 제품으로서의 운영 체계가 필요하다.
- API 중심 셀프서비스 구조는 팀 간 결합도를 낮추고 플랫폼 팀의 자율적 개선을 가능하게 한다.
- 명확한 소유권 정의와 적절한 추상화 수준 설정이 플랫폼 성숙도를 결정하는 핵심 요소다.