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

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

# npm 배포 토큰을 계속 보관해야할까

npm 패키지를 CI에서 배포하려고하면 보통 NPM_TOKEN부터 등록하게 된다. 로컬에서만 쓰던 배포 권한을 GitHub Secret에도 넣고 워크플로우가 가져다 쓰는 방식이다.

처음에는 간단한데 토큰을 언제 만들었는지, 어디에서 사용하는지, 만료되면 누가 바꿀지까지 생각하면 관리할게 생긴다..

이번주 7월 31일에 [npm Trusted Publishing의 OIDC 지원이 GA](https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/)가 됐다. 장기 npm 토큰을 CI에 보관하는 대신 승인한 워크플로우의 신원을 확인해서 배포하는 방식이다.

이번주 개발트렌드로 어떻게 달라지는지 정리해보려고 한다.

# 1. 우선 기존 방식과 비교해보자

기존에는 대략 다음처럼 연결했다.

```text
GitHub Actions
     ↓
Secret에 저장한 NPM_TOKEN
     ↓
npm publish
```

배포할때마다 같은 토큰을 사용하니 토큰 자체를 안전하게 보관하고 교체하는 일이 중요하다. 저장소가 여러개라면 어디까지 배포 권한을 줬는지 확인하는것도 번거로워질 수 있다.

Trusted Publishing은 흐름이 조금 다르다.

```text
GitHub Actions 실행
     ↓
OIDC로 실행 주체 증명
     ↓
npm이 등록한 신뢰 조건 확인
     ↓
짧게 사용하는 배포 자격 증명
     ↓
npm publish
```

아무 워크플로우나 토큰을 요청하면 배포할 수 있다는 의미는 아니다. npm에 어떤 저장소와 워크플로우를 신뢰할지 먼저 등록해야한다.

GitHub Actions의 OIDC 토큰에는 실행 주체를 확인할 정보가 들어간다. 이를 이용해 필요한 시점에 짧은 수명의 자격 증명을 받는 구조다. [GitHub의 OIDC 설명](https://docs.github.com/en/actions/concepts/security/openid-connect)

비밀값을 복사해서 오래 보관하던 부분을 실행 주체의 신뢰 관계로 바꾸는것으로 이해하면 쉬울것 같다.

# 2. 어떤 조건에서 사용할 수 있나

이번 GA에서는 GitHub-hosted runner와 gitlab.com의 shared runner를 지원한다. npm CLI는 11.5.1 이상이 필요하다.

즉 npm publish 명령만 바꾸면 끝나는것은 아니다. 지금 CI가 사용하는 npm 버전과 runner 종류부터 확인해야한다. 직접 관리하는 self-hosted runner도 당연히 될거라고 가정하면 안된다.

npmjs.com의 패키지 설정에서 trusted publisher를 등록하고 GitHub 사용자나 조직, 저장소, 워크플로우 파일명 등을 맞춰줘야한다. environment를 사용한다면 그 조건도 같이 확인한다.

특히 파일명을 바꾸거나 배포용 저장소를 옮긴다면 신뢰 설정도 따라 바뀌어야한다. 기존 Secret이 없어지는 대신 확인할 연결 조건이 생기는 셈이다.

사내 패키지도 배포하는 registry가 어디인지 먼저 봐야한다. npmjs.com의 기능이 모든 사설 registry에도 똑같이 적용되는것은 아니다.

# 3. 워크플로우는 어떻게 달라질까

공개 패키지의 태그 배포를 예로 들면 다음처럼 구성할 수 있다. npm 쪽 trusted publisher 설정을 먼저 해둔 상태라고 가정하자.

```yaml
name: Publish

on:
  push:
    tags:
      - 'v*'

jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm install --global npm@11.5.1
      - run: npm ci
      - run: npm test
      - run: npm run build --if-present
      - run: npm publish --access public
```

여기서 핵심은 id-token: write다. 워크플로우가 OIDC 토큰을 요청할 수 있도록 하는 권한이지, 그 자체로 npm의 모든 패키지를 수정할 수 있게 만드는 권한은 아니다. [npm 설정 설명](https://docs.npmjs.com/trusted-publishers/)

예제에는 프로젝트에 테스트 명령이 있다고 가정했다. 실제로는 배포 전에 필요한 검사와 빌드를 맞춰줘야한다. 태그 이름만 믿고 검사 없이 배포하는 구조로 바꿀 이유는 없다.

기존 .npmrc나 환경 변수에 토큰 설정이 남아있는지도 확인해보면 좋겠다. OIDC로 배포되는걸 검증해야 어떤 인증 경로를 쓰고있는지 분명해진다.

# 4. provenance가 있으면 안전한 패키지일까

Trusted Publishing에서는 조건을 만족하면 provenance attestation도 자동 생성된다. --provenance 플래그를 따로 붙일 필요가 줄어든다.

이 정보는 패키지가 어떤 소스와 빌드 환경에서 만들어졌는지 확인하는데 도움을 준다. 다만 비공개 소스 저장소에서 배포할때는 provenance를 사용할 수 없다는 제한이 있다.

그리고 출처를 확인할 수 있다는것과 코드가 안전하다는것은 다르다. 승인한 저장소의 코드 자체에 문제가 있다면 그 코드의 출처를 증명하는것만으로 해결되지는 않는다.

그래서 워크플로우 변경 검토, 의존성 관리, 배포 승인 같은 과정도 여전히 필요하다. 이번 변화는 공급망 보안에서 토큰 보관이라는 한 부분을 개선하는것으로 보는게 맞을것 같다.

# 5. 기존 배포를 옮길때 확인할것

바로 기존 토큰부터 없애기보다는 새 경로를 먼저 확인하면 좋겠다.

1. 배포 패키지와 registry, npm 버전을 확인한다.
2. npm에 저장소와 워크플로우를 등록한다.
3. OIDC 권한을 추가하고 테스트 배포로 동작을 확인한다.
4. 실제 배포된 버전과 provenance 제공 여부를 확인한다.
5. 기존 토큰을 사용하는 다른 작업이 없는지 확인하고 정리한다.

실패했다면 토큰을 새로 만드는것부터 하기보다는 저장소명, 파일명, environment, runner 조건이 맞는지부터 보는게 좋겠다.

배포 인증이 달라져도 패키지 버전 관리나 빌드 결과물 검증은 그대로 필요하다. 로그인에 성공했다고 올바른 파일이 올라갔다고 단정할 수는 없다.

# 마무리

이번 변화는 npm publish 명령보다 배포 권한을 다루는 방식이 바뀐다는 점에서 의미가 있는것 같다.

개인적으로는 CI마다 장기 토큰을 복사해두고 교체 시점을 기억해야하는 부담을 줄일 수 있다는게 눈에 들어왔다. 대신 어떤 실행을 신뢰할지 설정을 정확히 해줘야한다.

패키지 배포가 잘된다고 토큰은 계속 그대로 두기 쉬운데.. 이번 기회에 배포 권한이 어디에 남아있는지부터 한번 정리해봐도 좋을것 같다.


[2025.08.01 주간 개발 트렌드] npm Trusted Publishing 정리 (OIDC, 배포 토큰, provenance)

독자의 메모