숨을 죽이지 않고 애니메이션 측면 추가하기

일주일 후, OtakuShelf에는 몇몇 프랜차이즈 (Franchise)와 그 만화 (Manga)들이 담겨 있습니다. 이제 Sam은 나머지 절반인 애니메이션 (Anime)을 원합니다. 이는 기존의 Franchise에 연결된 새로운 엔티티 (Entity)들인 Anime, Season, Episode가 필요함을 의미합니다. 지난번과의 차이점은 매우 중요합니다. 이것은 Sam이 아끼는 데이터와 모델이 있는 **라이브 프로젝트 (live project)**라는 점입니다. 생성기 (Generator)를 아무 대책 없이 실행했다가는 엔티티가 엉망이 되고 최악의 오후를 보내게 될 수도 있습니다. 그래서 Sam은 딱 한 가지 습관을 통해 속도를 늦춥니다. 바로 '먼저 미리보기 (preview first)'를 하는 것입니다.

무엇보다 먼저 수행하는 빠른 직관적 확인

적용하기 전, Sam은 새로운 구조를 스케치하고 에이전트 (Agent)에게 이를 검증해 달라고 요청합니다:

아무것도 변경하지 말고 이것을 검증해 줘: Franchise와 다대일 (many-to-one)로 연결된 Anime (title, studio), 애니메이션 하위의 Season (number, title, episode count), 그리고 시즌 하위의 Episode (number, title, air date, duration in minutes).

validate_jdl 도구는 먼저 빠른 로컬 린트 (lint)를 실행하여 (JDL이 제대로 형성되었는지 확인), 그 다음 임시 디렉토리에 전체를 생성한 뒤 모든 오류를 보고합니다. 이 모든 과정은 OtakuShelf를 건드리지 않고 이루어집니다. 결과는 깨끗하게 돌아왔습니다. 좋습니다. 아이디어가 타당하다는 뜻입니다. 그렇다면, 이것이 실제로 프로젝트에 무엇을 할까요?

실제로 '드라이(dry)'한 드라이 런 (dry run)

이 부분은 모든 JHipster 베테랑들이 들어야 할 내용입니다. 우리에게도 같은 문제가 발생했기 때문입니다. JHipster 9에서 --dry-run은 여전히 파일을 작성합니다. 오직 충돌 (conflict) 사항만 출력할 뿐입니다. 따라서 해당 플래그가 프로젝트를 깨끗하게 유지해 줄 것이라고 믿어서는 안 됩니다.

MCP는 이 문제 전체를 우회합니다. Sam이 미리보기를 요청할 때:

/Users/sam/projects/otakushelf에서, 애니메이션 엔티티와 그 관계들을 추가했을 때 무엇이 변경될지 보여줘 — 아직 아무것도 작성하지 마.

…에이전트(agent)가 dryRun: true 옵션과 함께 apply 도구를 호출하면, 서버는 단순히 플래그를 확인하는 것보다 훨씬 더 정직한 작업을 수행합니다. 서버는 임시 디렉터리를 생성하고, 충실도를 위해 OtakuShelf의 .yo-rc.json과 기존 엔티티(entities)들을 그곳으로 복사한 뒤, 그 안에서 변경 사항을 생성하고 목록을 나열한 다음 임시 디렉터리를 폐기합니다. 실제 프로젝트에는 단 한 건의 쓰기 작업도 발생하지 않습니다. Sam은 파일 목록 — 새로운 Anime, Season, Episode 소스, 업데이트된 Liquibase 변경 로그(changelogs), 몇 개의 Vue 컴포넌트 — 을 읽고 고개를 끄덕인 뒤, 그제서야 dryRun 옵션을 제거합니다. 이제 동일한 호출이 실제로 실행됩니다.

이것이 Sam이 프로젝트 남은 기간 동안 정착하게 된 리듬입니다: 검증(validate) → 드라이 런(dry-run) → 적용(apply). 몇 초의 시간이 더 걸리지만, 모든 긴장감을 제거해 줍니다.

에이전트는 이미 셸프(shelf)를 알고 있습니다

이 과정을 안전하게 만드는 더 조용한 과정이 진행되고 있습니다. Sam이 "Anime를 Franchise에 연결해줘"라고 말할 때, 에이전트는 Franchise가 어떻게 생겼는지 추측하지 않습니다. 대신 리소스(jhipster://project/entities)를 통해 프로젝트의 현재 엔티티들을 읽어옵니다. 따라서 Franchise가 이미 title/synopsis/status/startYear를 가진 채 존재한다는 것을 알고 있으며, 해당 필드들을 재정의하거나 실수로 잘라내지 않고 관계를 추가합니다. 에이전트는 지난주 대화의 모호한 기억이 아니라, 실제 모델을 바탕으로 작업하고 있는 것입니다.

이번 배치(batch) 작업에서 Sam은 에이전트가 한 번에 모든 것을 처리하도록 합니다. 세 개의 새로운 엔티티와 그 관계들은 서로 연관되어 있으므로, 에이전트는 세 번의 개별 호출 대신 단 한 번의 import_jdl 호출을 구성합니다:

entity Anime { title String required, studio String }
entity Season { number Integer required min(1), title String, episodeCount Integer min(0) }
entity Episode { number Integer required min(1), title String, airDate LocalDate, durationMinutes Integer min(0) }
...

한 번의 제너레이터(generator) 실행, 한 번의 차이점(diff) 검토. (만약 Sam이 단 하나의 엔티티만 원했다면, 일반적인 설명으로부터 JDL을 빌드하는 add_entity 도구가 있습니다. 일회성 작업에는 유용합니다. 하지만 이번처럼 조율된 배치 작업에는 하나의 import_jdl이 더 깔끔하고 빠릅니다.)

왜 여기서 미리보기 습관이 특히 효과적인가

애니메이션 측면이 만화 측면을 ’건드립’니다 — 즉, Franchise가 animes 컬렉션을 얻게 됩니다. 이것이 바로 맹목적인 재생성(regeneration)을 수행할 때 불안함을 느끼게 만드는 전형적인 횡단 관심사(cross-cutting) 변경 사항입니다. 드라이 런(dry run)을 통해 Sam은 Franchise.java와 그에 따른 Vue 뷰들이 재생성될 것임을 미리 확인했고, 목록에 놀랄 만한 내용이 없음을 확인한 뒤 홀가분한 마음으로 진행할 수 있었습니다. MCP는 영리하게 행동함으로써 변경을 안전하게 만든 것이 아니라, Sam이 원하는 만큼 언제든 ’먼저 살펴볼’ 수 있게 함으로써 안전하게 만들었습니다.

향후 방향

이제 OtakuShelf는 Franchise부터 개별 Episode에 이르기까지 프랜차이즈의 양쪽 측면인 만화와 애니메이션을 모두 모델링합니다. 작동은 하지만 다소 거친 상태입니다. DTO가 없고, Sam은 이미 필드 하나가 누락되었다는 것을 깨달았습니다. 다음 단계는 다듬기 작업(polish pass)과 에이전트가 실제로 코드에 무엇을 수행했는지 읽는 방법에 대한 살펴보기입니다.

시리즈 다음 편: "카탈로그 다듬기 (그리고 에이전트의 영수증 읽기)" — 옵션, 백업이 포함된 잊혀진 필드, 그리고 에이전트가 수행한 작업 신뢰하기.