[2025.08.15 주간 개발 트렌드] Node.js 24.6 정리 (ML-DSA, 양자내성 서명)

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

# GPT-5가 나왔다. 코딩할때는 뭐가 달라질까

AI에게 코드 작성을 부탁하면 함수 하나는 금방 만들어준다. 그런데 실제 저장소에서 버그를 고치는 일은 함수 하나 만드는것보다 복잡하다.

관련 파일을 찾고 기존 구조를 이해하고 수정한 다음 테스트까지 확인해야한다. 중간에 도구가 실패했을때 다시 원인을 찾는 일도 필요하다.

이번주 8월 7일에 [GPT-5가 API로 공개됐다](https://openai.com/index/introducing-gpt-5-for-developers/). OpenAI는 coding과 agentic task를 주요 강점으로 설명하고있다.

이번주 개발트렌드로 새 모델의 숫자만 보기보다 코딩 작업을 맡길때 무엇을 확인해야할지 정리해보려고 한다.

# 1. 우선 ChatGPT와 API를 구분해서 보자

GPT-5 소개를 보면 빠르게 답하는 모델, 더 오래 추론하는 모델, 요청을 나누는 router가 나온다. 이건 ChatGPT에서 제공하는 통합 시스템에 대한 설명이다. 질문의 복잡도와 도구 필요성 등을 보고 어떤 경로로 처리할지 정하는 구조다. [GPT-5 시스템 소개](https://openai.com/index/introducing-gpt-5/)

반면 API의 gpt-5를 호출한다고 같은 router 구성이 그대로 붙는다고 이해하면 안된다. API에서는 추론 모델을 사용하면서 작업에 맞춰 reasoning effort 등을 조절한다.

```text
ChatGPT의 GPT-5
요청 → Router → 빠른 응답 또는 깊은 추론

API의 gpt-5
개발자가 모델과 추론 설정 선택 → 응답·도구 호출 처리
```

이 차이를 놓치면 API에서 간단한 질문도 알아서 다른 모델로 보내주겠지라고 생각할 수 있다. 실제 앱의 모델 선택과 작업 분리는 개발자가 설계해야하는 부분이다.

이번 API 공개에는 gpt-5-mini와 gpt-5-nano도 포함됐다. 성능뿐 아니라 지연과 비용을 같이 보고 선택할 여지가 있다. [OpenAI API 변경 내역](https://developers.openai.com/api/docs/changelog#august-2025)

# 2. SWE-bench 74.9%는 어떻게 읽어야할까

OpenAI는 SWE-bench Verified에서 74.9%라는 결과를 발표했다. 저장소와 이슈를 주고 문제를 해결하는 패치를 만드는 평가다.

다만 우리 회사의 버그를 74.9% 확률로 해결한다는 의미는 아니다. 발표에는 평가 환경에서 안정적으로 검증되지 않은 23개 문제를 제외한 조건도 설명되어있다.

같은 코드 작업이어도 저장소 크기, 테스트 품질, 의존성, 주어진 도구에 따라 난이도가 달라진다. 그래서 벤치마크는 방향을 보는 자료로 읽고 실제로 맡길 작업은 따로 확인해야한다.

예를 들어 내 프로젝트에서 반복되는 수정 요청 몇개를 골라 같은 조건으로 비교해볼 수 있다.

- 관련 파일을 제대로 찾는가?
- 기존 API나 데이터 형식을 지키는가?
- 필요한 수정만 하는가?
- 테스트를 실행하고 결과를 정확하게 설명하는가?

예쁘게 보이는 코드보다 기존 서비스에 맞는 변경을 만드는지가 더 중요한것 같다.

# 3. Agent에서는 도구를 이어쓰는 능력이 중요하다

코딩 Agent의 흐름을 단순하게 그리면 다음과 같다.

```text
이슈 확인
  → 저장소 탐색
  → 원인 가설
  → 코드 수정
  → 검사·테스트
  → 실패 원인 확인
  → 필요한 부분 재수정
```

여기서 모델은 다음에 어떤 작업이 필요한지 판단하고 도구 호출을 요청한다. 실제 파일 접근이나 명령 실행은 Agent를 구성하는 프로그램이 담당한다.

모델이 좋아졌다고 파일 권한이나 실행 환경까지 자동으로 준비되는것은 아니다. 읽을 수 있는 파일, 호출할 도구, 수정 가능한 범위가 있어야 긴 작업을 이어갈 수 있다.

또한 테스트에 실패했는데 성공했다고 마무리하면 수정이 잘됐는지 알기 어렵다. 실행하지 못한 검사와 실제 통과한 검사를 구분해서 알려주는지도 확인해야한다.

개인적으로는 코드 생성 결과 한장보다 이런 중간 과정을 보는게 모델을 비교하는데 더 도움이 될것 같다. 최종 답변이 그럴듯해도 도구 결과와 다르면 다시 확인해야한다.

# 4. 추론을 많이 시키면 항상 좋을까

GPT-5 API는 minimal, low, medium, high 같은 추론 수준을 지원한다. 응답 길이를 조절하는 verbosity도 별도로 제공한다.

둘은 같은 설정이 아니다. 추론을 얼마나 할지와 최종 설명을 얼마나 길게 할지는 나눠서 생각해야한다.

| 작업 예시 | 먼저 확인할 기준 |
| --- | --- |
| 형식 변환이나 간단한 분류 | 정확도와 응답 지연 |
| 여러 파일에 걸친 버그 수정 | 원인 분석과 변경의 일관성 |
| 수정 내용 설명 | 필요한 근거가 빠지지 않는지 |

이 표는 특정 설정이 무조건 정답이라는 의미는 아니다. 실제 입력을 넣고 결과를 비교할 출발점이다.

간단한 작업까지 오래 추론하게하면 기다리는 시간과 사용량만 늘어날 수 있다. 반대로 여러 조건이 얽힌 수정을 빠른 응답만 기준으로 처리하면 검증할 부분이 빠질 수 있다.

같은 작업에서 설정을 바꿔보고 성공률, 지연, 사용량을 함께 기록해보는게 좋겠다. 답변이 길다는 이유만으로 더 깊게 검토했다고 판단하면 안된다.

# 5. 실제 작업을 맡길때는 이렇게 나눠보자

처음부터 서비스 전체를 알아서 고치라고하기보다는 완료 조건이 분명한 작업으로 시작하면 좋겠다.

```text
특정 요청에서 발생하는 오류를 수정해줘.

기존 응답 형식은 유지해줘.
관련 코드와 테스트를 먼저 확인해줘.
수정 후에는 사용한 검사 명령과 결과를 알려줘.
실행하지 못한 검사는 따로 적어줘.
```

이런 요청은 모델의 능력을 대신해주는 마법의 문장이 아니다. 개발자가 결과를 확인할 기준을 미리 전달하는것이다.

변경 후에는 diff를 보고 예상하지 못한 파일까지 바뀌었는지 확인한다. 기존 테스트가 놓치는 조건이 있다면 실제 재현 입력도 넣어본다.

DB 변경이나 외부 서비스에 영향을 주는 작업은 어디까지 자동으로 실행할지 정해야한다. 모델의 도구 사용 능력과 작업을 허용하는 범위는 별개의 문제다.

# 마무리

이번 GPT-5 공개는 코드 한조각을 잘 만드는지에서 긴 작업을 얼마나 잘 이어가는지로 평가 기준이 넓어지는 흐름으로 보인다.

ChatGPT의 자동 라우팅과 API의 추론 설정은 구분하고, 벤치마크 숫자는 내 프로젝트의 성공률처럼 읽지 않는게 좋겠다.

모델이 좋아지면 맡길 수 있는 일도 많아지겠지만 결과를 확인할 기준은 더 분명해야할것 같다. 결국 코드를 빨리 받는것보다 수정과 검증까지 얼마나 믿고 이어갈 수 있는지가 중요한것 같다..


[2025.08.08 주간 개발 트렌드] GPT-5 정리 (코딩 Agent, 추론 설정, 검증할것)

독자의 메모