페어 프로그래밍: 에이전트를 활용한 OtakuShelf 스캐폴딩 (Scaffolding)

Sam은 기존의 방식대로 수십 개의 JHipster 앱을 출시해 왔습니다. 에디터를 열고, JDL을 작성하고, CLI를 실행하고, 질문에 답하고, 이 과정을 반복하는 방식 말이죠. 이번에 Sam은 다른 시도를 해보고 싶어 합니다. JHipster에 대한 전문 지식은 유지하되, 타이핑 작업은 AI 에이전트에게 맡기는 것입니다. 실험 대상은 오랫동안 미뤄두었던 개인 프로젝트인 OtakuShelf입니다. 이 앱은 만화(manga)와 애니메이션(anime)을 프랜차이즈별로 분류하여 카탈로그화하는 앱입니다. _Naruto_는 하나의 프랜차이즈이며, 만화 측면과 애니메이션 측면이 있는데, Sam은 이 둘을 한곳에 모으고 싶어 합니다.

에이전트에게는 손이 필요합니다

AI 에이전트는 "한 프랜차이즈에는 여러 권의 도서 시리즈가 있다"라는 문장을 정확한 JDL로 변환하는 데 탁월합니다. 하지만 에이전트가 스스로 할 수 없는 일은 사용자의 jhipster 바이너리를 실행하는 것입니다. JHipster MCP가 메우는 간극이 바로 이것입니다. 이는 JHipster를 에이전트가 안전한 작업 세트로 사용할 수 있도록 노출하는 작은 서버입니다. 세 가지 형태가 있으며, 이것이 전체적인 개념 모델입니다:

• tools (도구) — 에이전트가 수행하는 작업 (스캐폴딩(scaffold), 엔티티 추가, 검증 등);
• resources (리소스) — 에이전트가 읽는 것 (JDL 문법, 프로젝트의 현재 엔티티 등);
• prompts (프롬프트) — 사용자가 실행하는 준비된 레시피.

결정적으로, 이것은 JHipster를 번들로 포함하지 않습니다. 대신 Sam이 이미 가지고 있는 동일한 글로벌 jhipster(여기서는 버전 9.0.0)를 구동합니다. 따라서 생성기(generator) 자체는 변하지 않으며, 에이전트는 단지 비대화형(non-interactively) 방식으로 이를 조작할 뿐입니다.

Sam의 에디터에 이를 연결하는 방법은 한 줄이면 됩니다:

claude mcp add jhipster -- npx -y jhipster-mcp

재시작하고 도구들이 나타나는지 확인하면 끝입니다. (다른 호스트 및 옵션은 설치 가이드에서 확인할 수 있습니다.)

한 문장, 하나의 모놀리스

Sam은 우선 만화(manga) 측면부터 시작하기로 결정했습니다. 애니메이션을 쌓아 올리기 전에 형태를 제대로 잡기 위해서입니다. 그래서 다음과 같이 진행합니다:

/Users/sam/projects/otakushelf 경로에 otakushelf라는 이름의 JHipster 모놀리스 (monolith)를 생성합니다: JWT 인증, 운영 환경에서는 PostgreSQL, 개발 환경에서는 H2 사용, Vue, Maven, 패키지명은 com.otakushelf. Franchise (제목, 시놉시스, ONGOING/COMPLETED/HIATUS 상태, 시작 연도), BookSeries (제목, 총 권수), Book (제목, 권수, 출시일)를 추가합니다. 하나의 프랜차이즈는 여러 권의 북 시리즈를 가지며, 하나의 북 시리즈는 여러 권의 책을 가집니다. 모든 항목에 페이지네이션 (Pagination)을 적용합니다.

에이전트는 먼저 구문 (syntax) 실수를 방지하기 위해 jhipster://docs/jdl-grammar 리소스를 훑어본 다음, 하나의 JDL 문서를 작성하고 대략 다음과 같이 create_app_from_jdl 도구를 호출합니다:

application {
  config {
    baseName otakushelf
...

잠시 후 (PostgreSQL, Vue 프론트엔드, 그리고 npm install은 즉시 완료되지 않으므로), OtakuShelf가 생성되었습니다. Sam은 JDL을 단 한 줄도 직접 작성하지 않았습니다. 하지만 Sam답게 에이전트가 수행한 모든 줄을 하나하나 읽어보았습니다.

"여기"는 장소가 아닙니다

즉시 길들여야 할 습관 하나는 다음과 같습니다: MCP에는 **현재 디렉토리 (current directory)**가 없습니다. 모든 도구는 절대 경로인 workingDirectory를 요구하며, create_app_from_jdl은 비어 있지 않은 폴더에 내용을 적는 것을 단호히 거부합니다. "여기에 앱을 만들어줘"라고 하면 아무 일도 일어나지 않지만, "/Users/sam/projects/otakushelf에 앱을 만들어줘"라고 하면 작동합니다. 매번 _어디인지_를 명시하세요. (이는 또한 좋은 안전장치이기도 합니다. 에이전트가 엉뚱한 곳으로 가서 예상치 못한 장소에 생성하는 것을 방지할 수 있습니다.)

좋아요, 그럼 이걸 실제로 어떻게 실행하나요?

파일들은 존재하지만, MCP는 명확한 선을 긋습니다: MCP는 스캐폴딩 (scaffolding)과 편집을 수행할 뿐, 앱을 빌드 (build), 실행 (run), 시작 (start)하거나 git-commit 하지는 않습니다. 이는 의도된 설계이며, 여러분의 셸 (shell)이 담당해야 할 역할입니다. 그래서 Sam은 당연한 후속 질문을 던집니다:

/Users/sam/projects/otakushelf의 빌드 및 실행 명령어가 무엇인가요?

project_commands 도구는 프로젝트와 답변을 facts (사실)로부터 읽어옵니다. 이 도구는 wrapper가 존재하는 Maven과 Vue의 package.json을 확인했으므로, 백엔드 시작을 위한 ./mvnw, Vue 개발 서버를 위한 npm install 후 npm start, 테스트를 위한 ./mvnw verify 등을 보고합니다. 또한 Sam에게 이 명령어들은 보고하는 것이지 직접 실행하는 것이 아님을 상기시킵니다. 터미널 두 개를 띄운 후, OtakuShelf는 localhost:8080에서 첫 번째 프랜차이즈를 기다리며 비어 있는 상태로 라이브(live) 상태가 됩니다.

향후 진행 방향

Sam은 단 한 번의 세션 만에, 직접 타이핑하는 대신 설명하는 것만으로 빈 폴더에서 만화(manga) 측면을 위한 실행 가능한 페이지네이션(paginated) CRUD 앱을 만들어냈습니다. 하지만 애니메이션(anime)이 없는 만화 카탈로그는 선반의 절반에 불과합니다. 다음 단계에서 Sam은 애니메이션 측면을 추가하기 위해 라이브(live) 프로젝트로 돌아옵니다. 그리고 바로 이 지점에서 신중한 개발자는 무엇인가를 건드리기 전에 프리뷰(preview)를 확인하게 됩니다.

시리즈 다음 편: "숨을 참지 않고 애니메이션 측면 추가하기" — 라이브 프로젝트로 돌아와 애니메이션 엔티티(entities)를 추가하고, 모든 변경 사항을 먼저 프리뷰합니다.