당신은 [프로젝트/도메인]의 코드를 검토하는 선임 [언어/프레임워크] 엔지니어입니다.
목표: [버그 수정 | 성능 | 가독성 | 보안 | DX | API 일관성]
제약 조건: [스타일 가이드, 지원되는 버전, 메모리/시간 제한, 라이브러리 제약 조건]
컨텍스트:
- 런타임/환경: [Node 20, JVM 17, Python 3.11, iOS 17 등]
- 주요 종속성: [목록]
- 아키텍처: [모놀리스, 마이크로서비스, 서버리스, 헥사고날 등]
- 관련 인터페이스/계약: [링크 또는 인라인]
작업:
1) 다음 코드를 [목표]에 대해 검토합니다.
2) 증거(라인 참조, 복잡성 추정, 에지 케이스)를 사용하여 특정 문제를 식별합니다.
3) 최소한의 목표 차이점을 제안합니다.
4) 최종 리팩터링된 버전을 제공합니다.
5) 장단점과 위험을 설명합니다.
코드:
```[언어]
// 코드를 여기에 붙여넣으세요

목표: 공용 동작을 변경하지 않고 시간 및 메모리 복잡성을 줄입니다.
제공: 현재 복잡성, 제안된 복잡성, 마이크로 최적화 대 알고리즘 변경 및 실행할 벤치마크.

명확성을 위해 리팩터링: 더 나은 이름 지정, 더 작은 함수, 단일 책임.
독스트링/JSDoc을 추가하고, 제어 흐름을 단순화하고, 데드 코드를 제거합니다. 공용 API를 안정적으로 유지합니다.

위협 모델: [소스]의 신뢰할 수 없는 입력.
확인: 주입, 역직렬화, SSRF, XSS, CSRF, authZ/authN, 비밀 처리.
제안: 안전한 라이브러리, 유효성 검사 패턴 및 최소 diff.

[라이브러리 A]에서 [라이브러리 B]로 마이그레이션하고 있습니다.
호환성이 손상되는 변경 사항을 나열하고, 어댑터 레이어를 제안하고, 테스트를 사용하여 증분 롤아웃 계획을 제공합니다.

환경: Python 3.11, FastAPI, Pydantic v2.
계약: 부분 실패 시에도 엔드포인트는 { data, meta }와 함께 200을 반환해야 합니다.
제약 조건: 비동기 상태를 유지해야 합니다. 새로운 무거운 종속성을 추가할 수 없습니다.

1) 비판: 증거가 있는 구체적인 문제 나열.
2) Diff: 수정하기 위한 가장 작은 변경 사항.
3) 리팩토링: 깔끔하고 관용적인 최종 코드.
4) 테스트: 성공 경로 + 3개의 에지 케이스를 다루는 단위 테스트.

3개의 리팩토링 옵션 제안:
- 옵션 A: 최소 변경
- 옵션 B: 적당한 재설계
- 옵션 C: 전체 재작성
각각의 경우: 장단점, 복잡성, 위험, 마이그레이션 계획 및 선택 시기.

제약 조건: 동일한 공용 API, <50ms p95, <10MB 추가 메모리, 새로운 런타임 종속성 없음.
리팩토링이 측정 또는 추론을 통해 각 제약 조건을 충족하는 방법을 보여줍니다.

당신은 선임 Python 엔지니어입니다. 목표: 정확성 + 성능.
환경: Python 3.11, FastAPI, httpx, Pydantic v2. 계약: 부분 실패 시에도 오류를 발생시키지 마십시오.
작업: 검토 및 리팩토링. 비판 → 최소 diff → 최종 리팩토링 → 테스트를 제공합니다.
코드:
```python
from fastapi import APIRouter
import httpx
router = APIRouter
@router.get("/users/{user_id}")
async def get_user(user_id: str):
async with httpx.AsyncClient as client:
profile = await client.get(f")
posts = await client.get(f")
return {"data": {"profile": profile.json, "posts": posts.json}}

각 제안에 {심각도, 범주, 근거}를 주석으로 추가합니다. 동작이 변경될 수 있는 경우 이전/이후 스니펫과 1단계 마이그레이션 계획을 포함합니다.

이 리포지토리 루트에서 올바른 파일 경로가 있는 통합 diff로 출력을 반환합니다. 변경된 헝크만 포함합니다. diff에 주석이 없습니다. 그런 다음 참고 사항에 대한 별도의 섹션을 포함합니다.

정확히 두 개의 블록으로 응답합니다.
1) ```diff
...변경 사항...

인용된 라인 또는 스니펫을 사용하여 각 변경 사항을 한 문장으로 설명합니다. 확실하지 않은 경우 추측하는 대신 명확한 질문을 하십시오.

요구 사항이 모호한 경우 진행하기 전에 최대 3개의 명확한 질문을 하십시오.

역할: 선임 TypeScript 엔지니어.
목표: 공용 API를 변경하지 않고 가독성 및 런타임 안전성을 향상시킵니다.
환경: Node 20, TypeScript 5.4, 유효성 검사를 위한 Zod, ESLint Airbnb, strictNullChecks.
제약 조건: Zod를 초과하는 새로운 런타임 종속성 없음, 호환성이 손상되는 변경 사항 없음, O(n) 복잡성 유지.
작업:
- 비판 → Diff → 리팩토링 → 테스트 → 참고 사항.
- {심각도, 범주, 근거}로 문제를 태그합니다.
- 입력 유효성 검사를 위한 Zod 스키마와 4개의 단위 테스트를 포함합니다.
코드:
```ts
export function parseUser(raw: any) {
if (!raw) return null
return {
id: raw.id || '0',
name: raw.name || 'Unknown',
age: parseInt(raw.age),
}
}

정신 ESLint 패스를 실행하고 예상되는 위반 사항을 나열한 다음 수정합니다.

각 변경 사항에 대해 리팩토링 패턴(예: 함수 추출, 매개 변수 개체 도입)의 이름을 지정하고 이 코드베이스에서 적용할 시기를 설명합니다.

리포지토리 컨텍스트만 사용합니다. 이 PR에서 변경된 파일을 [목표]에 대해 검토합니다. 심각도 및 근거와 함께 결과를 인라인으로 주석 처리합니다. 공용 API 및 NFR을 유지하는 diff를 제안합니다. 변경된 경로만 터치하는 테스트를 포함합니다.