[2025.12.19 주간 개발 트렌드] Kubernetes 1.35 정리 (Pod 리소스, 기능 단계, 업그레이드)

![주간 개발 트렌드](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)

# GPT-5.2에서는 긴 작업을 끝내는 능력이 눈에 들어온다

AI가 코드 한부분을 작성하는것과 저장소를 읽고 수정한 다음 테스트까지 마치는것은 작업의 길이가 다르다. 중간에 오류가 나거나 요구사항이 추가되면 앞에서 한 일을 이어가야한다.

이번주 12월 11일에 [GPT-5.2](https://openai.com/index/introducing-gpt-5-2/)가 공개됐다. 장문 문맥과 도구 사용, 코딩과 복잡한 여러 단계의 작업을 개선했고 장시간 실행하는 Agent 용도도 강조했다.

이번주에는 답변을 잘하는 모델에서 긴 작업을 안정적으로 끝내는 시스템으로 관심이 넓어지는 흐름을 정리해보려고 한다.

# 1. 우선 벤치마크가 무엇을 말하는지 보자

OpenAI는 GPT-5.2 Thinking에 대해 SWE-bench Verified 80.0%, SWE-Bench Pro 공개 평가 55.6%를 발표했다. 두 평가는 문제와 조건이 다르므로 숫자를 같은 시험의 점수처럼 비교하면 안된다.

또한 80%라는 숫자가 우리 저장소의 작업을 80% 확률로 해결한다는 뜻은 아니다. 평가에 제공된 도구와 실행 조건, 문제의 성격이 실제 서비스와 다를 수 있다.

```text
확인할 구분
공개 평가의 성능
    ↓
우리 저장소에서의 수정과 테스트
    ↓
리뷰를 거쳐 실제로 완료된 작업
```

모델을 비교한다면 자주 요청하는 작업을 모아 같은 조건으로 실행해보면 좋겠다. 수정이 쉬운 함수와 여러 모듈에 걸친 변경은 난이도가 다르다.

테스트를 통과했는지와 요청 범위를 지켰는지도 같이 봐야한다. 테스트를 삭제해서 성공으로 보이게 만들거나 관련없는 구조까지 바꿨다면 원하는 완료가 아닐 수 있다.

# 2. 도구 호출은 마지막 결과까지 연결돼야한다

Agent가 도구를 사용할때는 호출을 만드는것 다음에 결과를 해석하고 다음 행동을 정해야한다. 요청이 실패했는데 성공했다고 가정하면 뒤의 작업도 잘못 이어진다.

예를 들어 저장소를 수정하는 Agent라면 다음 흐름을 생각할 수 있다.

```text
코드 탐색 → 변경 위치 결정 → 수정 → 테스트 실행
                                     ↓
                       결과 확인 → 필요하면 다시 수정
```

여기서 테스트 실행 요청을 보냈다는것과 테스트가 통과했다는것은 다르다. 프로세스가 실행중인지, 실패했는지, 결과가 잘렸는지도 확인해야한다.

서비스를 만드는 입장에서는 도구의 반환 형식도 중요하다. 상태와 오류, 결과를 구분해서 전달하면 모델이 다음 단계를 판단할 근거가 분명해진다.

긴 문자열 하나에 모든 정보를 섞어놓으면 중요한 오류를 놓치거나 성공 메시지를 잘못 읽을 수 있다. 모델의 능력이 개선돼도 도구의 계약을 명확히 만드는 작업은 필요하다.

# 3. 긴 문맥과 작업 상태는 구분하자

문맥을 많이 읽을 수 있으면 큰 문서나 저장소를 다루는데 도움이 된다. 그래도 대화 내용이 길다는 이유만으로 작업 상태가 안전하게 보관되는것은 아니다.

서버가 재시작되거나 외부 호출이 끊겼을때는 어디까지 완료됐는지 다시 알아야한다. 중요한 상태를 대화 문자열에만 맡기기보다 별도로 표현하는 방식을 생각할 수 있다.

```json
{
  "jobId": "job-demo",
  "status": "running",
  "completedSteps": ["inspect", "edit"],
  "currentStep": "test",
  "resultRef": null
}
```

위의 JSON은 작업 상태를 생각해보기 위한 예시이며 GPT-5.2 API의 반환 형식은 아니다. 서비스에서 완료한 단계와 현재 단계를 구분해 저장할 수 있다는 의미다.

대화를 요약한다면 사용자의 요구사항과 이미 내린 결정, 검증 결과를 구분해서 남기면 좋겠다. 실패한 시도를 완료한 작업처럼 압축하면 다음 실행이 잘못된 전제에서 시작할 수 있다.

원본 결과물이 어디에 있는지도 중요하다. 요약에 파일을 만들었다고 적혀있어도 실제 파일이나 변경 내역을 찾을 수 없다면 확인하기 어렵다.

# 4. 재시도는 같은 행동을 반복하는 문제가 아니다

오래 실행하는 작업에서는 일시적인 오류가 발생할 수 있다. 이때 무조건 처음부터 다시 실행하면 이미 완료한 외부 작업까지 반복될 수 있다.

조회는 다시 해도 되지만 주문 생성이나 메시지 전송 같은 작업은 중복이 문제가 될 수 있다. 도구별로 재시도해도 되는 조건과 완료 여부를 확인할 방법이 필요하다.

```text
외부 작업 요청
    ↓
응답을 받지 못함
    ↓
실패한건가? 완료됐는데 응답만 사라진건가?
    ↓
상태 조회 또는 중복 방지 기준으로 판단
```

서비스 설계에서는 작업 식별자와 멱등성 키, 체크포인트 같은 방식을 검토할 수 있다. 이것들이 모델을 교체했다고 자동으로 구현되는것은 아니다.

다시 실행하기 전에 사용자의 취소 여부와 권한도 확인해야한다. 긴 작업을 시작한 순간의 조건이 끝까지 그대로라고 가정하면 안되는 경우가 있다.

또한 도구 호출 횟수와 실행 시간에 한도를 두면 반복되는 실패를 발견하기 쉽다. 더 오래 실행할 수 있는 능력과 무한히 실행하도록 두는것은 다른 이야기다.

# 5. 서비스에서는 무엇을 비교할까

새 모델을 도입한다면 최종 답변의 품질과 함께 작업 전체의 결과를 확인해보면 좋겠다.

| 지표 | 확인할 질문 |
| --- | --- |
| 완료율 | 사용자가 요청한 결과물이 만들어졌는가 |
| 수정 정확성 | 관련없는 변경 없이 요구를 만족하는가 |
| 도구 사용 | 실패를 인식하고 올바른 다음 행동을 했는가 |
| 시간과 비용 | 재시도까지 포함해 어느정도 필요한가 |
| 복구 가능성 | 중단 후 이어서 처리할 수 있는가 |

평균 비용이 낮아도 실패한 작업을 사람이 오래 고쳐야한다면 전체 비용은 달라질 수 있다. 반대로 모든 요청에 가장 긴 추론을 사용하면 간단한 작업에서도 기다리는 시간이 늘 수 있다.

작업의 복잡도와 필요한 검증을 기준으로 적용 범위를 나눠보면 좋겠다. 짧은 분류와 저장소 수정, 보고서 작성이 같은 실행 설정을 필요로 하지는 않을것이다.

이번 발표에서는 API의 gpt-5.2 제공도 안내했다. 실제로 비교할때는 모델 이름뿐 아니라 추론 설정과 도구, 평가 사례도 함께 기록해야 같은 조건을 다시 만들 수 있다.

# 마무리

이번 GPT-5.2는 답변 하나의 성능과 함께 여러 단계를 도구로 연결해 긴 작업을 수행하는 방향을 보여준다.

개인적으로는 모델이 더 오래 일할 수 있을수록 상태와 실패, 검증을 관리하는 백엔드의 역할도 커진다고 생각한다. 모델이 좋은 판단을 하더라도 시스템이 결과를 잃어버리면 사용자는 완료된 작업을 받기 어렵기 때문이다.

우선 우리 서비스의 대표 작업으로 비교해보면 좋겠다. 말을 잘 마치는지보다 요청한 작업을 확인 가능한 결과로 끝내는지 살펴봐야겠다..


[2025.12.12 주간 개발 트렌드] GPT-5.2 정리 (긴 작업, 도구 호출, Agent 운영)

독자의 메모