Ask HN: 데이터+임베딩+API 파이프라인을 위한 기능적 DSL은 왜 없는가?

저는 상당히 흔한 문제를 다루고 있습니다:

• JSONL 파일에 구조화된 데이터를 가지고 있습니다 (in.jsonl, out.jsonl)
• 키를 기준으로 라인을 매칭합니다.
• 이를 (텍스트, 임베딩) 쌍으로 변환합니다.
• 선택적으로 필터링/매핑을 수행합니다.
• 배치 처리합니다 (50개 청크 단위).
• 각 배치를 외부 시스템(예: 벡터 DB, Chroma)에 푸시합니다.
  그게 전부입니다. 사소하게 들립니다. 하지만 금세 지저분한 명령형 Python 코드가 됩니다: 중첩된 for 루프, 전역 인덱스, += 연산자, 수동 배치 처리, 라인별 처리, 저수준 JSON 파싱.

실제로는 다음과 같은 형태가 됩니다:

with open("in.json", "r") as fin:
with open("out.json", "r") as fout:
for in_line, out_line in zip(fin, fout):
in_data = json.loads(in_line)
out_data = json.loads(out_line)
if in_data["custom_id"] != out_data["custom_id"]:
    raise Exception...
texts = in_data["body"]["input"]
embeddings = [d["embedding"] for d in out_data["response"]["body"]["data"]]
for i in range(len(texts)):
doc = texts[i]
emb = embeddings[i]
metadata = {
    "source": f"chunk-{global_ids}",

우리는 2025년인데, 데이터가 API로 연결되는 방식이 이렇습니다.

왜 우리는 이것을 용인하는 걸까요?
이것은 선언적(declarative)이며 스트리밍(streaming) 데이터 처리 문제입니다. 왜 더 우아한 것을 사용하지 않는 걸까요? 기능적 파이프라인처럼, 더 조합 가능한(composable) 것이요?
저는 스스로에게 묻습니다: 이런 종류의 작업에 대해 조합 가능하고, 스트리밍하며, 기능적인 DSL은 왜 없는가?

유닉스 파이프처럼 만들 수는 없을까요?
제가 원하는 것은 다음과 같은 느낌입니다:

cat input.jsonl \
| match output.jsonl on custom_id \
| extract (text, embedding) \
| filter not-empty \
| batch 50 \
| send-to-chroma

Lisp / Clojure에서는:

(->> (zip input output)
(filter (= :custom_id))
(mapcat (fn [[in out]] (zip (:input in) (:embedding out))))
(partition-all 50)
(map send-to-chroma)) 

Elixir + Broadway에서는:

Broadway
|> read_stream("in.jsonl", "out.jsonl")
|> match_on(:custom_id)
|> map(&{&1.text, &1.embedding})
|> batch_every(50)
|> send_to_chroma()

그리고 다시 Python으로 돌아와서..
우리는 명령형스러운 찌꺼기를 작성하거나 다음과 같은 방식으로 임시방편적인 DSL을 구축하는 데 빠져 있습니다:
load_json_pairs()
| where(is_valid)
| select(to_embedding_record)
| batch(50)
| foreach(send_to_chroma)
...또는, 더 현실적으로는 with open(...) as f를 수천 줄 작성하는 것입니다.

tf.data.Dataset, dask.bag, pandas, 또는 pipe 같은 라이브러리가 존재함에도 불구하고, 이들은 어떤 것도 응집력 있고 표현력이 풍부한 방식으로 이 사용 사례를 해결하지 못합니다. 그들은