Streams API 시리즈

파일이 작고 네트워크가 친절하다면 우리는 굳이 stream을 의식하지 않아도 된다. 응답을 통째로 받고, 문자열을 통째로 만들고, 메모리에 올린 다음 “됐네” 하고 넘어가면 된다. 문제는 현실이 그렇게 예의 바르지 않다는 데 있다. 데이터는 조금씩 오고, UI는 기다리지 않으며, 사용자는 진행률이 멈추면 일단 새로고침 버튼을 누른다. 가끔은 그게 유일하게 인간다운 선택처럼 보이기도 한다.

Streams API는 그 “조금씩”을 다루기 위한 약속이다. 읽는 쪽과 쓰는 쪽이 서로의 속도를 모른 척하지 않게 만들고, 아직 끝나지 않은 데이터를 끝난 것처럼 취급하지 않게 막는다. 처음에는 ReadableStream, WritableStream 같은 이름이 조금 차갑게 느껴지지만, 따라가다 보면 결국 이 API가 다루는 것은 데이터보다 더 자주 우리의 조급함이라는 사실을 알게 된다.

Stream은 데이터를 빠르게 처리하는 기술이라기보다, 끝나지 않은 일을 끝난 척하지 않게 만드는 기술에 가깝다.

시리즈 구성

1. Streams API 1. 읽기와 쓰기의 출발점 ReadableStream, WritableStream, reader, writer의 기본 흐름을 잡고, stream을 열고 닫는 최소한의 손잡이를 익힌다.
2. Streams API 2. 상태와 백프레셔의 의미론 stream이 단순한 이벤트 목록이 아닌 이유를 상태, 큐, backpressure를 통해 살펴본다.
3. Streams API 3. 바이트 스트림과 실전 파이프라인 byte stream, pipe, transform이 실제 입출력 문제에서 어떤 역할을 하는지 연결해서 본다.
4. Streams API 4. 왜 모든 언어에는 Stream API가 존재할까 JavaScript만의 API를 넘어, 거의 모든 런타임이 stream 개념을 다시 발명하는 이유를 정리한다.
5. Streams API 부록 1. HTTP 다운로드 진행률은 어떻게 계산될까 다운로드 진행률이 단순한 퍼센트처럼 보이기 위해 뒤에서 어떤 정보가 필요한지 다룬다.
6. Streams API 부록 2. 왜 이미지는 위에서 아래로 나타날까 이미지가 한꺼번에 나타나지 않고 점진적으로 그려지는 이유를 stream 관점에서 풀어본다.

추천 읽기 순서

처음 읽는다면 1편부터 4편까지 순서대로 읽는 편이 좋다. 앞에서는 API의 손잡이를 잡고, 중간에서는 속도 차이를 다루며, 마지막에는 왜 이 개념이 특정 언어의 유행어로 끝나지 않는지 확인한다.

실전 감각이 먼저 필요하다면 1편을 읽은 뒤 3편과 부록 1편으로 건너가도 된다. 다운로드 진행률이나 파일 처리처럼 눈에 보이는 문제를 먼저 만나면, backpressure 같은 단어도 덜 추상적으로 느껴진다. 물론 덜 무섭다는 뜻이지, 완전히 다정해진다는 뜻은 아니다.

결국 흐름을 인정하는 일

Stream을 배운다는 것은 데이터를 한 번에 통제할 수 있다는 착각을 내려놓는 일에 가깝다. 모든 것을 메모리에 올리고 나서 처리하는 방식은 단순하지만, 단순함이 늘 오래 버티지는 못한다. 데이터가 커지고, 네트워크가 흔들리고, 사용자가 기다리지 않는 순간부터 우리는 흐름을 나눠 받아들이는 법을 배워야 한다.

이 시리즈는 Streams API의 모든 세부를 외우기 위한 목록이 아니다. 대신 읽기와 쓰기, 상태와 압력, byte와 pipe가 왜 함께 등장하는지 이해하는 길잡이에 가깝다. 결국 좋은 stream 코드는 빠른 코드 이전에 정직한 코드다. 아직 오지 않은 데이터를 아직 오지 않았다고 말하는 코드. 생각보다 이 정직함이 많은 버그를 조용히 막아준다.