dev.to

I Vibe-Coded My Way Out of Angular Upgrades

AI 에이전트로 Angular 업그레이드 세 건을 마쳤습니다

Angular 업그레이드 작업을 Codex Skill로 자동화하고, 실제 오픈소스 프로젝트 세 곳에 적용한 경험을 공유합니다. 작성자는 CI의 깨끗한 설치와 Node.js·npm 버전 검증을 추가해 실패를 보완했고, 세 업그레이드를 모두 병합했습니다.

에디터 노트

세 프로젝트에서 병합까지 마친 결과는 이 Skill이 소규모 저장소의 업그레이드 부담을 줄였다는 근거가 됩니다. 다만 프로젝트 세 곳의 성공이 복잡한 Angular 앱이나 배포된 라이브러리까지 검증했다는 뜻은 아닙니다. 댓글에서 제기한 peerDependencies 범위와 보조 진입점 검사는 실제 업그레이드와 패키지 배포의 경계를 구체적으로 짚습니다. 작성자는 데모 앱 테스트와 깨끗한 설치 검증을 포함하고 별도 소비자 프로젝트 테스트는 범위 밖으로 구분했습니다. 일반 업그레이드 절차와 라이브러리 배포 검증을 나눈 판단은 합리적이며, 적용 범위는 아직 소규모 프로젝트로 한정됩니다.

AI 요약

Angular 버전 업그레이드를 미루던 작성자는 Codex용 Angular Update Skill을 만들었습니다. 공식 Angular Update Guide를 따르고 별도 Git 브랜치에서 마이그레이션과 의존성 업데이트를 진행한 뒤 빌드와 동작을 확인하도록 구성했습니다.

실패를 반영한 검증 절차

처음에는 로컬에서 성공했지만 GitHub CI에서 package.json과 package-lock.json이 맞지 않아 npm ci가 실패했습니다. 기존 node_modules에 기대지 않도록 깨끗한 임시 사본에서 npm ci를 실행하는 검증을 추가했습니다.

npm 패키지 배포 과정에서는 npm 레지스트리의 404 오류를 만났습니다. 조사 결과 배포 환경의 Node.js 22와 npm 10이 trusted publishing 요구 버전을 충족하지 않았습니다. 문서에 따르면 Node.js는 22.14.0 이상, npm은 11.5.1 이상이어야 합니다. Skill은 대상 Angular 버전과 프로젝트 요구사항에 맞는 최신 Node.js LTS를 고르고, 배포에 필요한 npm 버전도 확인하도록 바뀌었습니다.

세 프로젝트에서 적용

지침은 1,252단어에서 701단어로 줄였고 전체 번들도 약 40% 짧아졌습니다. 작성자는 Angular 21에서 22로 올린 angular-mydatepicker와 AuthApi, Angular 19에서 22로 올린 FileApi에 Skill을 적용했습니다. FileApi는 세 개의 주요 버전을 넘는 마이그레이션이 필요했습니다. AuthApi에서는 PrimeNG 라이선스 변경에 따라 Optimus UI로 교체했습니다. 세 변경은 모두 병합됐으며, 작업에는 일주일이 걸렸습니다. 작성자는 현재 버전이 소규모 프로젝트에서 잘 작동하지만 복잡한 프로젝트에는 조정이 필요하다고 덧붙였습니다.

dev.to 반응

  • @sylwia-lask — Angular 자체를 업그레이드하는 일도 고역인데, 우리가 어쩔 수 없이 쓰는 Angular 컴포넌트 라이브러리의 업그레이드는 악몽입니다. 버전이 바뀔 때마다 close를 closeDialog로 바꿨다가 다음 버전에서 다시 close로 돌려놓기도 합니다. 그 라이브러리 업그레이드용 Skill도 따로 필요하겠네요.
    • @gramli — close를 closeDialog로 바꿨다가 다시 close로요? 정말 악랄하네요. 그 라이브러리 전용 Skill이 필요하겠어요?
    • @sylwia-lask — 맞아요. 업그레이드할 때마다 평생 일자리를 보장하려고 일부러 그러는 거라고 농담합니다.
  • @sinarezaei — npm ci 실패가 이 글에서 흥미로운 부분입니다. AI 에이전트가 Angular API를 제대로 마이그레이션해도 lockfile, peer dependency, 배포 환경 사이의 계약을 놓칠 수 있습니다. Angular 17에서 18로 올릴 때도 @angular/core와 @angular/compiler-cli만 바꾸면 충분하지 않습니다. 빌드 도구와 TypeScript 버전, peerDependencies 범위도 맞아야 합니다. 깨끗한 체크아웃에서 npm ci를 실행하고 라이브러리를 프로덕션 빌드한 다음 별도 Angular 프로젝트에서 패키징된 tarball을 시험하면 좋겠습니다.
    • @gramli — 맞는 지적입니다. 첫 npm ci 실패 때문에 node_modules에 기대지 않는 깨끗한 임시 사본 검증을 넣었습니다. 데모 앱이 있는 Angular 라이브러리에서도 시험해 업그레이드 후 데모를 확인하고 패키지를 배포했습니다. 별도 소비자 프로젝트에서 패키지를 확인하는 검증은 라이브러리 배포에는 타당하지만 일반적인 Angular 업그레이드 Skill의 범위를 벗어난다고 봅니다.
    • @sinarezaei — 그렇다면 데모 앱 테스트는 라이브러리 빌드만 확인하는 것보다 좋은 신호입니다. 다만 라이브러리 자체 데모에서는 잘 작동해도 peerDependencies 범위가 지원해야 할 Angular 버전을 제외하거나 보조 진입점이 패키징에서 빠질 수 있습니다. 그런 배포 계약 검사는 업그레이드 실패와는 다른 문제이므로 핵심 Skill과 선택 검증을 분리하는 편이 맞겠습니다.
    • @gramli — 동의합니다. 자세한 피드백과 제안 감사합니다.
  • @glenallen — 실제 실패를 겪을 때마다 Skill을 개선한 점이 이 작업에서 가장 가치 있습니다. Node.js와 npm 버전을 고정하고 깨끗한 체크아웃에서 로컬과 CI가 같은 검사를 실행하도록 하면 검증 환경을 재현하기 쉬워집니다. 어떤 검사를 통과했고 무엇을 확인하지 못했는지도 기록하면 업그레이드 완료의 의미가 분명해집니다.
    • @gramli — 제안 감사합니다. 프로젝트마다 버전을 하나로 고정하는 대신 대상 Angular와 프로젝트 요구사항에 맞는 최신 Node.js LTS를 선택합니다. CI 설정의 npm 버전도 확인하고 node_modules 없는 깨끗한 임시 디렉터리에서 npm ci를 실행합니다. 각 검증 단계의 통과 여부와 확인할 수 없었던 항목도 보고합니다.

원문: dev.to / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗