path: root/docs/research/006-problem-landscape.md

# Pure 연구 보고서 006: 먼저 풀 문제를 고르기

작성일·자료 확인일: 2026-09-22
상태: **1차 문헌 조사와 실험 전략. 새 성능 측정이나 독창성 입증은 없음.**

## 이번 판단

언어·플랫폼별 실제 문제를 먼저 조사하고 Pure의 전략을 정하는 방향이 맞다.
좋은 문제는 개선의 실용적 가치를 결정하고, 실제 성능은 알고리즘·구현·작업 조건으로 검증해야 한다.
각 언어의 약점 목록에서 출발하되, 최종 연구 단위는 **작업 → 비용 발생 원인 → 기존 최선의 해결책 → 남은 비용**으로 잡는다.

이 조사에서는 서비스·개발 도구의 운영 보고와 공식 구현 문서에서 10개 후보를 검토했다.
여러 사례에는 이미 좋은 해결책이 있다. 따라서 지금 정한 ABI·버퍼 풀·연산 규칙은
문제에 맞춰 수정할 후보 설계다. 먼저 구현하고 그 구조가 유리한 문제를 뒤에서 고르는 순서를 피한다.

첫 후보는 **여러 처리 단계에 걸친 버퍼 수명과 메모리 예산**이다.
사용 경험으로는 큰 파일이나 연속 데이터를 다룰 때 메모리가 예측 가능하고,
출력이 느려져도 조작·취소가 정상적으로 처리되는 것으로 나타나야 한다.
이번에는 사용자가 조작할 새 구현체가 없다. 기존 제작 화면도 이 가설을 검증하지 않는다.

## 조사 범위와 해석 한계

- Discord·Instagram·VS Code 자료는 실제 시스템을 개선한 당사자의 역사적 보고다. 당시 원인이 지금도 그대로 남았다는 증거는 아니다.
- Sonic·Node.js·.NET·Rust·Java·SwiftUI·Metal·Arrow 자료는 공식 기능·구현 설명이다. 그 자체를 대규모 운영 장애나 Pure의 성능 증거로 취급하지 않는다.
- 전체 언어·플랫폼을 망라한 조사나 체계적 논문 검토가 아니다. 동적 문서의 현재 내용을 확인했지만 재현할 버전·커밋은 아직 고정하지 않았다.
- 아래의 ‘Pure 가설’과 우선순위는 자료를 바탕으로 한 우리의 추론이다. 원문 저자들이 Pure의 필요성을 주장한 것이 아니다.

## 10개 후보와 현재 해법

### P01. Go: 큰 캐시의 메모리와 지연

Discord는 2020년 Read States 서비스에서 큰 캐시의 GC 비용과 주기적인 지연을 보고했다.
캐시를 줄이면 데이터베이스 접근이 증가하는 상충 관계가 있었다. Rust 전환에는 자료구조와
복사 경로 등의 변경도 포함되어 언어만 바꾼 통제 실험으로 읽을 수 없다.
[Discord 운영 보고](https://discord.com/blog/why-discord-is-switching-from-go-to-rust).

**기존 해법:** 캐시 정책·자료 배치·할당 감소·GC 설정과 메모리 제한을 먼저 검토한다.
Go의 공식 GC 안내도 CPU와 메모리 사이의 비용 관계를 설명한다. 이 안내는 Go 1.19를 기준으로
설명한다고 명시하므로 재현 시 선택한 버전에서 다시 확인한다.
[Go GC guide](https://go.dev/doc/gc-guide).

**Pure 가설:** 수명이 다른 데이터를 구분하면 회수 비용과 메모리 유지량을 줄일 수 있는가?
동등하게 최적화한 Go 및 C/Rust 구현이 비교 대상이다. GC가 없는 구현의 이득만 확인되면
Pure 고유의 기여는 아직 없다. 캐시 적중률·DB 작업량도 같아야 한다. **우선순위: 보조 후보.**

### P02. Python: 읽기 위주 데이터도 프로세스마다 복제되는 비용

Instagram의 pre-fork 환경에서는 참조 횟수 등 객체 관리 정보의 쓰기가 공유 페이지의
copy-on-write를 유발했다. Meta는 immortal objects로 이 문제를 줄이는 작업을 보고했고,
PEP 683은 Python 3.12를 대상으로 채택되었다. 모든 사용자 객체가 자동으로 이 혜택을
받는다는 의미는 아니다.
[Meta, 2023](https://engineering.fb.com/2023/08/15/developer-tools/immortal-objects-for-python-instagram-meta/),
[PEP 683](https://peps.python.org/pep-0683/).

**Pure 가설:** 읽기 전용 본문과 변경되는 관리 정보를 분리할 가치가 남아 있는가?
기존 Python 개선과 명시적 공유 메모리가 비교 대상이다. 프로세스별 RSS를 단순 합산하지 않고
공유·전용 페이지를 구분한다. 이 문제의 pre-fork 전제를 모바일·브라우저에 일반화하지 않는다.
**우선순위: 해당 실행 환경을 선택할 때 재검토.**

### P03. Node.js / .NET: 느린 소비자와 버퍼 누적

Node.js는 streams의 역압력으로 생산 속도를 제어한다. .NET Pipelines도 풀링된 버퍼와
writer 중단·재개 임계값을 제공하며, 소비·검사 위치를 잘못 전달하면 메모리 문제나 정체가
생길 수 있음을 문서화한다. 역압력과 버퍼 재사용은 이미 제공되는 기능이다.
[Node.js streams](https://nodejs.org/learn/modules/backpressuring-in-streams),
[System.IO.Pipelines](https://learn.microsoft.com/en-us/dotnet/standard/io/pipelines).

**Pure 가설:** 변환·분기·캐시·완료 대기를 합친 예산을 공유하면, 각 단계가 개별적으로
제한을 두는 구현보다 같은 처리량·지연 조건에서 메모리를 덜 유지하는가?
올바른 역압력과 전역 예산을 추가한 기존 구현까지 비교해야 한다.
느린 소비자에서 입력을 무조건 버려 얻은 수치는 동일 기능의 성능 개선이 아니다.
**우선순위: 첫 연구, P04와 함께 검토.**

### P04. ByteDance Sonic: 복사를 생략한 결과 원본 전체가 살아남는 비용

Sonic은 디코딩한 문자열이 원본 JSON을 참조하면서, 작은 결과를 보관해도 원본 버퍼가
유지될 수 있음을 설명한다. `CopyString` 및 검색 결과의 `CopyReturn` 같은 선택지도 제공한다.
복사량과 장기 메모리 유지량 사이에 상충 관계가 있다는 구체적인 사례다.
[Sonic 공식 저장소](https://github.com/bytedance/sonic#tips).

**Pure 가설:** 원본 크기·남기는 범위·메모리 압력을 이용해 공유와 복사를 선택하면
일괄 정책보다 유리한가? 항상 복사, 항상 공유, 단순 크기 임계값, 기존 라이브러리 설정이
비교 대상이다. 미래의 실제 보관 시간을 미리 아는 정책을 실용 구현처럼 비교하지 않는다.
**우선순위: 첫 연구. 기존 옵션보다 남는 이득이 있는지부터 확인.**

### P05. Rust: 특수화의 실행 성능과 빌드 비용

rustc는 제네릭의 구체 타입별 코드를 생성하는 monomorphization을 사용한다.
공식 가이드는 실행 성능의 이점과 컴파일 시간·바이너리 크기 비용을 함께 설명한다.
이것만으로 Rust 컴파일러 전체의 크기나 어떤 앱의 메모리 사용 원인을 설명할 수는 없다.
[Rust Compiler Development Guide](https://rustc-dev-guide.rust-lang.org/backend/monomorph.html).

**Pure 가설:** 공통 실행과 제한적 특수화를 조합해 원하는 실행 성능에서 빌드 비용을
통제할 수 있는가? 컴파일러 배포 크기, 빌드 시간·최대 RAM, 산출물 크기, 실행 RAM을
별도로 기록한다. 동등한 기능을 가진 비교가 필요하며 현재 작은 DSL의 크기를 범용 언어와
직접 비교하지 않는다. **우선순위: 모든 단계의 관리 지표. 첫 대표 문제로는 보류.**

### P06. JVM: 이미 해결된 제약을 연구 대상으로 고르는 위험

JDK 24는 `synchronized` 안에서 대기하는 virtual thread가 carrier thread를 붙잡는
제약을 완화하는 JEP 491을 반영했다. 이전 버전의 대표 문제를 최신 Java 전체의
한계로 삼으면 출발점부터 비교가 틀어진다. 모든 native/FFI 상황의 제약이 없어졌다는 뜻은 아니다.
[Oracle JDK 24 변경 사항](https://docs.oracle.com/en/java/javase/24/migrate/significant-changes-jdk-24.html).

**Pure 판단:** 이 과거 제약은 첫 연구 후보에서 제외한다. 실제 작업의 남은 대기 비용이
확인되면 지원 중인 대상 JDK와 비교한다. 작은 스케줄러를 만드는 것만으로 우월성을 주장하지 않는다.

### P07. TypeScript / VS Code: 작은 변경에 큰 문서를 다시 처리하는 비용

VS Code의 2021년 괄호 색상 개선은 확장 API의 제약을 넘어서 토큰 정보와 증분 자료구조를
활용했다. 보고된 큰 개선은 특정 괄호 갱신 작업에 대한 것으로, 앱 전체나 언어 간 속도 비율이 아니다.
기존 확장 호스트의 격리는 무거운 작업 중 UI 반응성을 지키는 역할도 했다.
[VS Code 개발팀 보고](https://code.visualstudio.com/blogs/2021/09/29/bracket-pair-colorization).

**Pure 가설:** 작은 수정이 유발하는 재계산·데이터 이동 범위를 예산 안에서 제한할 수 있는가?
비교 대상도 증분 알고리즘을 사용해야 한다. 의존성 추적 메모리와 초기 구축·대규모 수정 비용을
포함한다. **우선순위: 두 번째 연구 후보, 실제 문서·데이터 편집 기능과 연결.**

### P08. SwiftUI: 상태 의존성과 갱신 범위

Apple은 SwiftUI 성능 분석에서 의존성, 뷰의 identity, 비용이 큰 갱신 작업을 다룬다.
SwiftUI 자체가 의존성을 추적하므로 변경된 부분만 처리한다는 발상만으로 차별화되지는 않는다.
[Apple WWDC23: Demystify SwiftUI performance](https://developer.apple.com/videos/play/wwdc2023/10160/).

**Pure 가설:** 상태·입력·출력의 연결 정보로 불필요한 갱신을 줄이면서 추적 메모리도
제한할 수 있는가? 적절히 상태를 분리한 기존 구현과 비교한다. 렌더러 차이와 상태 처리 차이를
분리하고 동일한 화면·상호작용을 유지한다. **우선순위: P07과 묶어 후속 검토.**

### P09. Apple Metal: 통합 메모리에서도 남는 자원 수명과 동기화

Apple GPU는 시스템 메모리를 공유하지만 자원 접근 방식에 따라 shared/private/memoryless를
선택한다. shared 자원도 CPU·GPU 접근 순서를 동기화해야 한다.
[Apple 저장 모드 안내](https://developer.apple.com/documentation/metal/choosing-a-resource-storage-mode-for-apple-gpus),
[shared 접근 계약](https://developer.apple.com/documentation/metal/mtlstoragemode/shared).

**Pure 가설:** 입력에서 GPU 완료까지 자원 수명을 연결해 임시 자원과 대기를 줄일 수 있는가?
잘 구성한 Metal 직접 구현이 비교 대상이다. 동시에 진행하는 프레임 수와 출력 품질을 맞추고
CPU·GPU 대기 및 메모리를 함께 측정한다. 현재 Linux 측정은 사용자의 Apple Silicon에서
실행한 증거가 아니다. **우선순위: 실제 Mac 프로파일을 확보한 뒤.**

### P10. C/C++ 및 다중 언어 경계: 이미 있는 무복사 ABI

Apache Arrow C Data Interface는 같은 프로세스 안에서 언어·런타임 간 columnar 데이터를
공유할 수 있는 작은 C 인터페이스와 해제 계약을 제공한다. 프로세스 간 전송이나 영속 저장 형식은
그 인터페이스의 범위가 아니다.
[Arrow C Data Interface](https://arrow.apache.org/docs/format/CDataInterface.html).

**Pure 가설:** 기존 인터페이스로 표현되지 않는 비동기 수명·예산 관리가 필요한가?
Arrow에 맞는 데이터는 이를 활용하는 방안을 먼저 비교한다. 자체 ABI의 필요성은 함수 호출,
버전 처리, 소유권, 호환 비용까지 보여야 한다. **우선순위: 재사용·연동 기준.**

## 첫 연구 질문

> 여러 단계가 입력을 나눠 읽고 일부 결과를 오래 보관하는 작업에서,
> 전체 예산과 원본 버퍼 수명을 함께 관리하면 기존의 잘 구성한 구현보다
> 같은 처리량·지연 조건에서 메모리 유지량을 줄일 수 있는가?

**귀무가설 H0:** 기존의 제한된 큐, 메모리 풀, 단순 복사 정책을 조합하면 Pure 후보와
동등하거나 더 좋은 비용을 얻는다. 이 경우 공통 라이브러리나 어댑터 수준으로 해결하고
그 문제를 이유로 새 언어·ABI·스케줄러를 확대하지 않는다.

**대안 가설 H1:** 단계 간 예산과 수명 정보를 공유하는 정책이, 입력 분포가 달라져도
단순 정책 대비 유리한 메모리·처리량·지연 조합을 만든다. 그 이득이 관리 정보·계측·호스트
비용을 포함해 남고 다른 작업에도 적용되는지 확인한다. 이 가설은 아직 검증되지 않았다.

현재 초안의 버퍼 전체 단위 대여와 완료 회수 시점도 수정 대상이다.
큰 원본의 작은 구간 때문에 전체 할당이 유지되거나 완료 회수가 밀리면 오히려 비용이 커질 수 있다.
복사를 줄이는 지표 하나만 목표로 삼지 않는다.

## 재현할 작업과 비교 순서

첫 작업 후보는 **큰 로그·구조화 데이터에서 필드를 추출하고, 일부 결과를 보관하면서
느린 출력으로 내보내는 CLI**다. 이는 연구용 작업 제안이며 제품 범위를 확정한 것은 아니다.
후속으로 압축 입력과 문서 탐색 화면을 연결할 수 있지만 첫 비교에 모두 넣지 않는다.

1. **기존 구현에서 비용 재현.** 단일 프로세스의 제한된 처리 흐름으로 시작한다.
   입력 크기, 레코드 크기 분포, 보관 비율, 소비자 속도, 분기 수를 독립적으로 바꾼다.
   합성 데이터는 생성 규칙·seed를 공개하고 실제 운영 추적이라고 부르지 않는다.
2. **비교 구현 개선.** 항상 복사·공유·단순 임계값 정책을 비교하고,
   올바른 역압력·전역 예산·버퍼 풀까지 적용한다. 튜닝에 쓴 입력과 평가 입력을 분리한다.
3. **남은 비용 분석.** 원본 유지·대기열·파싱·할당·I/O 중 비용이 어디에 있는지 확인한다.
   Pure가 건드릴 수 있는 경로의 비중이 작으면 우선순위를 낮춘다.
4. **최소한의 Pure 정책 비교.** 같은 언어·파서·I/O 경로에서 정책만 바꿔 원인을 분리한다.
   외부 언어·플랫폼 비교는 별도 실험으로 보고한다. 파서 교체로 얻은 이득을 수명 정책의 이득으로 돌리지 않는다.
5. **실제 제작 경험.** 가치가 확인된 작업을 사용자가 빈 작업물에서 작성·수정하게 한다.
   새 필터·출력·보관 정책을 추가할 때마다 실행기 코드를 고쳐야 하는지 기록한다.

큰 파일 하나만으로 대규모 서비스의 특성을 대체할 수 없다. 데이터/메모리 비율,
동시 작업 수, 보관 시간 분포, 부하 급증, 느린 소비자의 분포를 드러내야 한다.
네트워크를 붙일 때는 도착 부하와 큐 대기 시간을 기록하고, 느려진 만큼 요청 발생도 늦어져
지연이 작아 보이는 측정 오류를 피한다. 분산 저장소·핫키·질의 설계의 비용은 별도로 분석한다.

## 측정과 탈락 기준

| 축 | 반드시 포함할 것 |
|---|---|
| 정확성 | 출력 내용·순서, 잘린 입력, 실패·취소, 완료 후 자원 반환 |
| 메모리 | 예약·사용·유지 바이트, 큐·풀·관리 정보, 라이브러리 내부 할당, 프로세스 메모리 |
| 수명 | 원본 할당별 마지막 참조 시점, 유지 바이트의 시간 적분(byte·seconds), 최고 유지량 |
| 복사 | 경로별 복사 바이트, 공유로 연장된 수명, 계측 밖 경로 |
| 처리 | 완료한 유효 작업량, 처리량, 큐 대기를 포함한 지연 분포, 거절·손실·취소 수 |
| 구축 비용 | 도구 버전, 빌드 시간·최대 RAM, 실행 파일·모듈·의존성 크기 |
| 측정 조건 | OS·CPU·RAM, 빌드 옵션·커밋, 입력·설정, 워밍업, 반복 분산, 계측 자체 비용 |

공유 원본은 할당별로 한 번만 센다. 풀 예약량·RSS·GPU 통계를 무조건 더하지 않는다.
관리하는 버퍼 예산과 전체 프로세스 메모리 상한을 구분한다. 취소가 접수됐다는 이유로
아직 접근 중인 메모리를 반납해 성능을 높이는 구현은 실패다.

실험 전에 작업의 메모리 한도와 필요한 지연·처리량을 정한다. 숫자는 실제 사용 조건에서 정하고
유리한 결과를 본 뒤 고르지 않는다. 같은 조건에서 반복 측정의 변동보다 확실한 차이가 있는지,
다른 입력에서는 어떤 손해가 생기는지 함께 보고한다.

다음 중 하나면 가설을 기각하거나 범위를 줄인다.

- 단순한 기존 정책을 튜닝하면 차이가 사라진다.
- 관리 정보·라이브러리·호스트 비용을 포함하면 이득이 사라진다.
- 메모리를 줄인 대가로 필요한 처리량·지연·정확성을 만족하지 못한다.
- 특정 입력에만 유리하며 평가에 쓰지 않은 입력에서 재현되지 않는다.
- 새 런타임 없이 작은 라이브러리 변경으로 같은 결과를 얻는다. 이 경우 그 변경 자체의 가치를 평가한다.

## 연구 기여를 판단하기 위한 다음 문헌 단계

운영 사례는 문제의 존재를 보여주지만 새로운 해법의 독창성을 증명하지 않는다.
첫 문제의 잔여 비용이 확인되면 다음 주제의 원 논문·공개 구현과 비교표를 만든다.

- 영역 기반 메모리 관리와 소유권/대여: 회수 단위와 수명 표현의 기존 해법.
- 스트리밍 실행기의 admission control·역압력·메모리 예약: 전역 예산의 기존 해법.
- 공유 버퍼의 보관·복사 정책: 미래 수명을 모르는 온라인 결정과 관리 비용.
- 증분 계산·질의 처리: 입력 변화에 비례한 작업량과 추적 상태 비용.

각 연구의 전제, 보장, 비용, 실패 조건, 재현 가능 구현을 기록한다.
현재는 이 논문 검토를 완료하지 않았으므로 새로운 원리나 세계 최초라는 표현을 사용하지 않는다.

## 기존 계획에 대한 결정

[005의 계약 초안](005-foundation-contract.md)은 유지하되, 구현 우선순위 앞에
**기존 해법의 재현과 남은 비용 확인**을 둔다. 버퍼 풀·자체 ABI·커널 우회 중 무엇이 필요한지는
그 결과에서 결정한다. 컴파일러 크기 관리는 병행하는 측정 항목이다.

다음 산출물은 새 문법 데모가 아니라 첫 후보의 **재현 가능한 비교 구현과 비용 보고서**다.
첫 후보에서 차별화가 확인되지 않으면 그 결과를 남기고 P07/P08 또는 실제 Mac 작업을 검토한다.
압축·암호화·문서·미디어·OS의 장기 목표는 유지하지만, 한 실험의 결과를 모든 분야의 성능으로 확대하지 않는다.

2026-09-22 진행 기록: [007의 첫 비교 실험](007-buffer-retention-results.md)에서 단일 FIFO의
원본 유지 비용을 재현했다. 기존 복사·선별 읽기 정책으로 개선됐으며 Pure 고유의 이점은 확인하지 못했다.
007의 범위에는 여러 소비자와 실제 파서의 잔여 비용 검증이 포함되지 않았다.

추가 진행: [008](008-json-fanout-results.md)에서 실제 JSON 파서와 다중 소비자의 제한된 작업을
검증했다. 기존 정책 대비 고유한 이점을 확인하지 못해 P03/P04는 기반 품질 과제로 유지하고,
다음 대표 연구 후보는 P07/P08의 증분 편집·갱신 비용으로 옮긴다. 실제 운영 작업 전체에 대한 결론은 아니다.

작업 범위 보완: 공유·복사 정책 비교는 여기서 종료하고 원자료를 보존한다.
P07/P08는 아직 구현 대상으로 확정하지 않는다. 먼저 기존 문헌·공개 구현에서
구체적인 편집 작업의 비용과 기존 해법의 한계를 확인한다. **기존 해법 채택으로
충분한지, Pure의 실행 방식 변경이 필요한지**를 가르는 근거만 조사한다.
작은 변경을 전체 재계산과 비교해 빠르다는 사실을 재현하는 데 그치면 탈락이다.
남은 비용과 최소 확인 방법을 특정할 수 있을 때만 비교 구현으로 넘어간다.
세부 작업 기준은 [협업 방식](000-working-method.md)을 따른다.

자체 구현 진행: P07/P08의 일반적인 증분 처리 벤치마크 대신, 초기 연구 질문 중
추적 기록의 제거를 [작은 실행 코어](../../prototypes/forgetful-core/README.md)로
구체화했다. 변경 기록이 부족할 때의 재계산, 조건부 의존성의 보존, 작업 한도 내
거절을 확인했다. 이는 자체 실행 계약 구현이며 신규성·성능 우위의 결론은 아니다.