고성능 시스템과 언어 선택

응답이 느리다는 현상만으로 language를 바꾸면 network 대기, database query, model inference와 serialization 중 실제 병목을 놓칠 수 있습니다. Trace로 end-to-end 시간을 나누고 CPU profile, allocation, queue와 downstream capacity를 측정해야 application code가 차지하는 비율을 알 수 있습니다. 개선 가능한 상한은 병목 비중보다 클 수 없습니다.

대표 workload에는 평균 요청뿐 아니라 큰 payload, 동시 사용자와 오류 조건이 포함되어야 합니다. Microbenchmark에서 parser가 두 배 빨라도 전체 요청의 5%만 차지하면 사용자 latency 변화는 작을 수 있습니다. Rewrite 결정은 처리량과 tail latency뿐 아니라 library 성숙도, 배포 복잡성, 팀의 review 능력과 장애 대응 시간을 포함한 총비용으로 비교해야 합니다.

TypeScript는 browser UI, Node API와 MCP tool schema처럼 JSON 경계가 많은 시스템에서 하나의 type vocabulary를 공유하기 쉽습니다. Discriminated union으로 성공과 오류 상태를 구분하고 exhaustive check를 사용하면 새 상태를 추가했을 때 처리하지 않은 위치를 compile 단계에서 찾을 수 있습니다. IDE refactor가 큰 interface 변경의 영향 범위를 빠르게 보여 주는 것도 중요한 운영 이점입니다.

그러나 Node의 single event loop에서 CPU가 큰 parsing이나 image 변환을 직접 실행하면 다른 요청도 지연됩니다. Worker, queue나 별도 service로 격리할 수 있지만 그만큼 serialization과 운영 비용이 생깁니다. TypeScript를 선택할 때는 팀 생산성과 ecosystem 이점이 workload의 CPU, memory와 latency 조건을 만족하는지 실제 profile로 확인해야 합니다.

Python은 model library, notebook, data processing과 API framework가 풍부해 실험에서 service까지 같은 개념을 빠르게 연결할 수 있습니다. Type hint와 validation library를 사용하면 interface를 문서화하고 일부 오류를 앞당길 수 있지만 runtime에서 type hint 자체가 모든 값을 강제하는 것은 아닙니다. Package와 native extension version을 lock하지 않으면 같은 code도 환경에 따라 다르게 실행될 수 있습니다.

Asyncio는 network와 disk를 기다리는 동안 다른 coroutine을 진행시키는 도구이지 CPU 계산을 여러 core에서 자동 병렬화하지 않습니다. CPU-bound 전처리는 process pool, native library나 별도 worker가 필요할 수 있고, GPU 작업은 framework의 execution model과 queue를 봐야 합니다. GIL이라는 한 단어로 결론 내리지 말고 workload별 concurrency와 memory copy를 측정해야 합니다.

Go의 goroutine과 channel은 많은 network connection과 cancellation을 비교적 단순한 문법으로 구조화해 gateway, controller와 telemetry collector에 잘 맞을 수 있습니다. 단일 binary 배포와 빠른 시작은 운영 단위를 줄여 줍니다. 하지만 goroutine이 가볍다고 무제한 생성하면 downstream보다 빠른 producer가 queue와 memory를 채우고 tail latency를 악화시킵니다.

Context cancellation을 모든 I/O 경계에 전달하고 bounded concurrency, backpressure와 timeout budget을 설계해야 합니다. Race detector와 profile은 공유 state와 allocation 문제를 찾는 증거를 제공하지만 production workload를 대신하지는 않습니다. Go 선택은 “동시성 언어”라는 인상보다 현재 service의 연결 수, CPU 비중과 팀의 운영 경험으로 판단해야 합니다.

Rust의 ownership과 borrowing은 dangling pointer, data race처럼 memory 수명과 공유에서 생기는 일부 오류를 compile 단계에서 거부합니다. Parser, proxy, inference extension처럼 untrusted byte를 고속으로 다루는 경계에서는 이 보장이 장애와 취약점 위험을 줄일 수 있습니다. `unsafe`와 FFI를 사용한 부분은 보장 범위가 달라지므로 작은 module로 격리하고 별도 review가 필요합니다.

전체 service rewrite보다 profile에서 확인한 hot path를 안정적인 API 뒤의 Rust library나 worker로 옮기는 방식이 위험을 줄일 수 있습니다. 이때 serialization, copy와 호출 overhead를 포함한 end-to-end benchmark를 해야 합니다. Compile 성공은 업무 logic, authorization과 resource exhaustion을 증명하지 않으므로 fuzzing, property test와 운영 limit을 함께 유지해야 합니다.

교육용 이미지 분석 요청은 기존 계산 80ms와 나머지 처리 120ms로 총 200ms라고 가정합니다. 새 계산은 20ms지만 전송과 복원에 90ms가 추가되면 총 230ms입니다. 계산 자체는 빨라졌어도 사용자가 기다리는 시간은 늘어납니다. 개선율을 보고할 때 분모를 계산 80ms로 둘지 전체 200ms로 둘지 명시해야 오해를 막습니다.

이 숫자는 실제 제품 측정값이 아니라 경계 비용을 읽는 가상 예입니다. 작은 요청을 묶거나 기존 프로세스 안에서 계산하는 후보를 별도로 비교할 수 있습니다. 다만 묶기 때문에 대기 시간이 늘면 처리량 개선과 응답 지연을 분리해 판단합니다. 실험마다 요청 묶음 크기를 기록해야 대기 시간이 늘어난 원인을 언어 성능 문제와 구분합니다.

반례는 계산이 대부분을 차지하고 입력이 작은 작업입니다. 같은 전송 비용이라도 계산 절감이 충분하면 별도 서비스가 유리할 수 있습니다. 따라서 한 번의 결론을 모든 작업에 적용하지 않고 입력 크기별로 경계 비용이 달라지는 지점을 찾습니다. 입력 분포가 바뀌면 유리한 후보가 달라질 수 있으므로 운영 분포와 시험 분포를 대조합니다.

검증 표에는 입력 크기, 호출 횟수, 복사량, 계산 시간과 요청 전체 시간을 남깁니다. 같은 부하에서 오류율과 최대 메모리도 비교합니다. 계산 구간만 개선됐다는 결과는 전체 서비스 이전의 승인 근거로 사용하지 않습니다. 실패 응답을 제외하고 성공한 요청만 시간을 재면 느리거나 큰 입력을 버린 후보가 유리해집니다.

교육용 조회 API에 연결 10개가 있고 동시에 요청 100개가 온다고 가정합니다. 모든 요청이 같은 길이의 조회를 한다면 나머지는 연결을 기다립니다. 작업자 수를 100개로 늘린 결과와 연결 10개에 맞춘 수신 제한을 같은 부하로 비교합니다. 이 수치는 실측 성능이 아니라 포화 원리를 설명하는 가정이며 실제 연결 한도는 환경에서 확인합니다.

관찰할 값은 성공 건수뿐 아니라 대기 시간과 취소 후 남은 연결 수입니다. 사용자가 떠난 요청까지 계속 실행되면 새 사용자는 필요 없는 작업 뒤에서 기다립니다. 취소된 작업이 재사용 가능한 연결을 반환하는 시점을 확인합니다. 연결 반환 여부를 보지 않고 취소 응답만 확인하면 뒤에서 계속 도는 작업을 성공적으로 종료했다고 오해합니다.

반례로 하위 시스템이 충분한 여유를 갖고 I/O 대기가 대부분이라면 동시성 증가는 처리량을 높일 수 있습니다. 이 경우에도 어느 지점부터 지연과 오류가 증가하는지 측정합니다. 적은 동시성이 항상 안전하거나 큰 동시성이 항상 빠르다고 단정하지 않습니다. 작업 종류가 섞여 있다면 짧은 요청이 긴 요청 뒤에서 기다리는 경우를 따로 관찰해야 합니다.

검증에서는 연결 지연과 사용자 취소를 함께 주입하고 작업 수가 다시 기준선으로 돌아오는지 봅니다. 돌아오지 않으면 누수나 끝나지 않는 작업을 조사합니다. 언어 전환보다 수신 제한과 정리 경로 수정이 먼저 필요한지 이 기록으로 판단합니다. 새 요청을 중단한 뒤에도 기준선으로 돌아오지 않는 현상은 순간적인 과부하와 다른 복구 문제입니다.

교육용 문서 파서는 UTF-8 입력을 받아 단어 위치를 반환한다고 가정합니다. 한국어 한 글자가 여러 바이트라는 사실 때문에 문자 인덱스와 바이트 위치를 바꾸어 쓰면 강조 표시가 어긋납니다. 호출 계약은 반환 위치의 단위를 먼저 정해야 합니다. 반환 위치의 단위를 문서에 적지 않으면 두 구현이 서로 다른 답을 내도 각각 맞다고 주장할 수 있습니다.

같은 문장을 한국어, 영문과 이모지가 섞인 입력으로 만들어 두 구현에 보냅니다. 반환 위치로 원문을 다시 잘랐을 때 같은 단어가 나오는지 확인합니다. 값의 타입이 정수라는 사실만으로 이 의미 차이를 잡을 수는 없습니다. 눈에 보이는 강조뿐 아니라 반환된 시작과 끝 위치도 남겨 경계에서 발생한 차이를 재현합니다.

반례는 작은 영문 파일만으로 속도와 정확성을 비교하는 시험입니다. 그 입력에서는 바이트와 문자 위치가 우연히 맞아 결함이 보이지 않을 수 있습니다. 잘린 UTF-8과 입력 한도 초과도 넣어 호출부가 오류를 정상 결과처럼 처리하지 않는지 봅니다. 잘못된 입력에 대한 오류가 호출 언어의 예외나 상태 코드로 보존되는지 끝까지 확인합니다.

검증을 통과한 경계에는 단위, 최대 크기, 오류 종류와 소유권 이전 여부를 문서로 남깁니다. 호출부 수정 때 같은 자료를 회귀 입력으로 사용합니다. 전체 서비스를 다시 쓰지 않고도 좁은 계산 경계의 이익과 남은 위험을 설명할 수 있어야 합니다. 모듈 교체 시에는 동일한 입력 자료로 이전 호출부와 새 호출부를 모두 실행해 호환성을 점검합니다.