What is Upstream and Downstream in Software Development

원문: https://reflectoring.io/upstream-downstream/ (by Tom Hombergs)
(원문을 임의로 번역한 글 입니다)

생산 공정에서의 업스트림과 다운스트림

소프트웨어 개발과 관련이 없는 간단한 생산 공정에서 시작해보자. 이를 기반으로 소프트웨어 개발에서도 업스트림과 다운스트림을 정의할 수 있을 것이다.

위 예시는 3가지 단계를 가지고 있다:

1. 부품 수집하기
2. 부품 조립하기
3. 조립품 도색하기

생산 공정은 강과 비슷하기 때문에 이해하기 쉽다. 공정이 한 단계 다음으로 진행하면 다운스트림으로 나아가게 된다.

이로 부터 다음과 같은 규칙을 도출할 수 있다:

1. 의존성 규칙(Dependency Rule): 다운스트림은 업스트림의 모든 항목에 의존한다.
2. 가치 규칙(Value Rule): 다운스트림으로 내려갈수록 각 단계는 제품은 더 많은 가치가 더해진다.

자, 이제 이 규칙을 여러가지 소프트웨어 개발 컨텍스트에 적용해보자.

소프트웨어 의존관계에서 업스트림과 다운스트림

대부분의 소프트웨어 컴포넌트는 다른 컴포넌트들에 대해 의존관계를 가지고 있다. 업스트림 의존관계와 다운스트림 의존관계는 무엇일까?

다음 그림을 살펴보자:

컴포넌트 C는 컴포넌트 B에 의존하고 있고, 컴포넌트 B는 다시 컴포넌트 A에 의존하고 있다.

의존성 규칙을 적용해보면, 컴포넌트 A는 컴포넌트 B의 업스트림이라 할 수 있고, 컴포넌트 B는 컴포넌트 C의 업스트림이라 할 수 있다.

가치 규칙을 적용해 보면 (다소 추상적이긴 하지만) 컴포넌트 C는 가장 많은 가치를 가지고 있다고 할 수 있는데, 컴포넌트 B와 A의 모든 기능을 "imports(가져오다)"하여 자신의 가치를 추가하기 때문이다. 그래서 컴포넌트 C가 다운스트림 컴포넌트가 된다.

오픈소스 프로젝트에서 업스트림과 다운스트림

오픈소스 개발에서도 "업스트림"과 "다운스트림"이라는 용어가 많이 사용된다. 위에서 살펴본 컴포넌트 의존관계와 매우 비슷하다.

프로젝트 A와 B가 있고, A는 B의 오리지날 프로젝트이고 B는 A의 포크(fork)인 상황을 가정하자:

이는 오픈소스 프로젝트에서 다소 흔한 개발 스타일이다. 어떤 프로젝트의 포크를 만들어서 버그를 수정하거나 기능을 추가한다. 그리고 오리지날 프로젝트에 패치를 제출한다.

이 컨텍스트에서 의존성 규칙을 적용하면 프로젝트 A는 업스트림 프로젝트이다. A 프로젝트는 B 프로젝트가 없어도 생존할 수 있지만 B는 그렇지 않기 때문이다.

가치 규칙을 적용해도 마찬가지이다. 프로젝트 B는 새로운 기능을 추가하거나 버그를 수정해서 오리지날 프로젝트 A에 가치를 더하기 때문이다.

그래서 오픈소스 프로젝트에 패치를 기여(contribute)할 때 마다 우리는 "업스트림에 패치를 보낸다"하고 말할 수 있다.

(마이크로-)서비스에서 업스트림과 다운스트림

마이크로서비스들(혹은 구식의 오래되고 평범한 분산 서비스)로 구성된 시스템에서도 업스트림과 다운스트림 서비스에 대한 얘기할 수 있다.

당연히 의존성 규칙과 가치 규칙도 이 컨텍스트에 적용된다.

서비스 B는 업스트림 서비스이다. 서비스 A가 의존하기 때문이다. 서비스 A는 서비스 B의 가치를 더하기 때문에 다운스트림 서비스이다.

무엇이 업스트림이고 무엇이 다운스트림인지에 대한 "스트림"을 정의하는 것에 주의해야 한다. 이 경우 "스트림"은 서비스 A를 통해 시스템으로 들어오는 데이터 스트림이 아니라 시스템의 핵심으로 부터 사용자 대면 서비스로 내려가는 데이터 스트림이다.

사용자(or 최종 컨슈머)에게 가까운 서비스일수록 다운스트림에 더 가까워진다.

결론

"업스트림"과 "다운스트림"의 개념이 사용되는 어떤 컨텍스트에서도, 우리는 두 가지 간단한 규칙을 적용해서 어떤 것이 업스트림이나 다운스트림인지 알아낼 수 있다.

다른 요소에 가치를 더하거나 의존한다면 다운스트림이 확실하다.