OtakuShelf를 JHipster 9.1.0으로 업그레이드하기

JHipster 9.1.0이 막 출시되었습니다. 수년 동안 이 문장은 Sam의 속을 뒤틀리게 만들었습니다. 버전 업데이트 (version bumps)는 곧 git-merge 모험, 예상치 못한 충돌, 그리고 커스텀한 파일이 조용히 덮어씌워질지도 모른다는 끊임없는 두려움을 의미했기 때문입니다. OtakuShelf는 현재 9.0.0 버전을 사용 중이며, Sam은 현재 상태에 실제로 만족하고 있습니다. 따라서 진짜 질문은 "어떻게 업그레이드하는가"가 아니라, "업그레이드를 해야 하는가, 그리고 그 대가는 무엇인가?"입니다. 에이전트는 단 하나의 파일도 변경하기 전에 이 두 가지 질문에 모두 답할 수 있습니다.

먼저, 이것이 실제로 얼마나 큰 작업인가?

Sam은 범위를 정하는 것부터 시작합니다:

/Users/sam/projects/otakushelf를 JHipster 9.1.0으로 업그레이드하는 것이 얼마나 위험한가?

upgrade_advisor 도구는 OtakuShelf의 .yo-rc.json과 엔티티 (entity) 설정들을 읽고 업데이트의 규모를 보고합니다:

• 현재 9.0.0 → 9.1.0, 마이너 (minor) 업데이트;
• 위험도: 낮음 (low) — 블루프린트 (blueprints) 없음, 일반적인 모놀리스 (monolith) 구조, 소수의 엔티티;
• 몇 가지 프로젝트 특정 노트 (경고할 만한 내용은 없음) 및 짧은 체크리스트;
• 9.1.0 릴리스 노트 (release notes) 링크.

Sam이 높게 평가하는 점 하나는, 어드바이저가 변경 사항 (breaking changes) 목록을 임의로 만들어내지 않는다는 것입니다. 마이너 릴리스에는 변경 사항이 많지 않아야 하지만, 어드바이저는 아는 척을 하는 대신 권위 있는 정보를 위해 Sam을 릴리스 노트로 안내합니다. 어드바이저는 사실과 범위만을 제공하며, 세부 사항은 실제 정보가 있는 곳에 존재합니다. 마이너하고 위험도가 낮은 업데이트에 대해 결론은 "진행하십시오"였지만, Sam은 여전히 피해를 먼저 확인하고 싶어 합니다.

아무것도 건드리지 않는 미리보기

OtakuShelf를 9.1.0으로 업그레이드하면 무엇이 바뀌는지 보여줘.

이것은 Sam이 몇 년 전에 존재했기를 바랐던 기능입니다. preview_upgrade는 generator 9.1.0을 사용하여 격리된 임시 복사본에 OtakuShelf의 자체 모델을 재생성합니다. 이때 npx generator-jhipster@9.1.0을 통해 즉석에서 가져오므로 Sam은 이를 먼저 전역(globally)으로 설치할 필요조차 없습니다. 그런 다음 결과물을 현재 프로젝트와 비교(diff)합니다:

Upgrade preview → generator-jhipster@9.1.0:
  +1 added  -0 removed  ~14 modified
Added (1): ...
...

OtakuShelf 자체는 전혀 건드리지 않습니다 — 이는 일회성 재생성(regeneration)에 대한 차이점(diff)일 뿐입니다. 그리고 이 도구가 명확하게 밝히는 정직한 주의 사항이 있습니다: modified 목록은 두 가지를 혼합한다는 점입니다 — 즉, 새로운 생성기(generator)가 만드는 변경 사항과 Sam이 커스텀한 파일들입니다. 이 둘을 구분하는 것이 모든 JHipster 업그레이드의 실제 작업입니다. 이제 차이점은 Sam이 밤 11시에 머지(merge) 도중에 이를 발견하는 대신, 평온한 오후에 미리 전체 목록을 확인한다는 것입니다.

14개의 수정된 파일은 대부분 의존성 업데이트(dependency bumps)와 재생성된 보일러플레이트(boilerplate)이며, Sam이 직접 편집한 Franchise 뷰를 건드리는 것은 아무것도 없습니다. 이것은 화요일의 일상이지, 모험이 아닙니다.

Sam의 방식대로 적용하기

MCP가 하지 않은 것에 주목하십시오: MCP는 업그레이드를 실행하지 않았습니다. 공식 jhipster upgrade는 Git 기반의 머지(merge)이며, 이 서버는 의도적으로 사용자의 Git 외부에서 작동합니다 — 따라서 머지하는 대신 미리 보기(preview)를 제공합니다. 차이점(diff)을 손에 쥔 상태에서, Sam은 일반적인 워크플로우를 통해 실제 변경을 주도합니다: 현재 상태를 커밋(commit)하고, 업그레이드를 실행하며(에이전트는 탈출구(escape hatch)를 통해 jhipster upgrade를 시작할 수 있고, 또는 Sam이 직접 실행할 수도 있습니다), 미리 보기가 이미 표시해 둔 몇 안 되는 지점들을 해결합니다. Sam이 먼저 커밋을 했고 영향 범위(blast radius)를 사전에 알고 있었기 때문에, 머지는 막연한 믿음에 의존하는 도약이 아니라 빠르고 자신감 있는 검토 과정이 됩니다.

./mvnw verify와 npm test를 실행하고 나면 (MCP가 파트 1에서 Sam에게 이 명령들을 알려주었던 것을 기억하세요), OtakuShelf는 9.1.0 버전에서 즐겁게 실행됩니다.

Sam이 실험을 통해 얻은 것

네 번의 세션 전만 해도 OtakuShelf는 빈 폴더와 막연한 아이디어에 불과했으며, Sam은 AI를 생성기(generator) 근처에 두는 것에 대해 회의적이었습니다. 이제 페이지가 나뉘고 DTO 기반으로 작동하는 만화 및 애니메이션 카탈로그가 존재합니다 — 스캐폴딩(scaffolded)되고, 성장하고, 다듬어지며, 버전이 업데이트되었습니다 — 그리고 에이전트의 개입이 제어권(control)의 감소를 의미한 적은 단 한 번도 없었습니다. 여기서 나타난 패턴은 단순하고 확고했습니다:

• 변경 사항을 평이한 언어로 **설명(describe)**하고;
• 프로젝트를 건드리기 전에 **검증 및 드라이 런(validate and dry-run)**을 수행합니다. MCP는 플래그를 믿는 방식이 아니라 격리(isolation)를 통해 미리보기(preview)를 제공하므로, 이 과정은 무료입니다;
• 가끔 **백업(backup)**을 병행하며 **적용(apply)**하고;
• 에이전트가 실제 프로젝트를 읽도록(read the real project) 하여 편집이 정교하게(surgical) 유지되도록 합니다.

MCP는 Sam의 JHipster에 대한 판단력을 대체하지 않았습니다. 대신 그 주변의 마찰—JDL 타이핑, CLI 프롬프트, 업그레이드에 대한 두려움—을 제거하고, 결정권은 원래 있어야 할 곳에 남겨두었습니다.

이제 선반이 완성되었습니다. 실제로 만화를 채워 넣을 시간입니다. 📚

이 모든 과정의 뒤에 숨겨진 정확한 인자(arguments)와 예외 케이스(edge cases)가 궁금하신가요? 이야기는 동기를 부여하고, 문서(docs)는 명세(specify)를 제공합니다. 도구 참조(tools reference)부터 시작해 보세요. 그리고 서버 자체는 npm의 jhipster-mcp에서 확인할 수 있습니다.