AI가 헤매지 않는 프론트엔드 개발 워크플로우를 만드는 방법 - 동일한 설정을 Claude Code로 검증해 보았다【제2회】

제1회에서는 IBM Bob과 MCP를 사용하여 「AI가 헤매지 않는 개발의 토대」를 구축해 본 이야기를 썼다. 규칙(Rule), 커스텀 모드(Custom Mode), Skills, MCP를 정비하여 AI가 헤매지 않고 일할 수 있는 레일을 까는 검증이다.

그 마지막에서 다음과 같이 예고했었다.

제2회는 여기서 정비한 .bob 설정을 그대로 Claude Code의 .claude로 가져가서 검증한 이야기를 쓸 예정이다. 결론부터 말하자면, 설정이 거의 그대로 작동했다.

이 기사는 그 검증의 연장선이다. 동일한 토대를 다른 도구로 옮기면 어떤 일이 일어나는가. 실제로 어떤 Skills와 프롬프트(Prompt)로 구동하고 있는지를 포함하여 솔직하게 작성한다.

본 기사는 필자 개인의 검증과 견해에 기반한 것이며, 소속 조직의 공식 견해를 나타내는 것이 아닙니다. 특정 도구의 우열을 주장하는 것이 아니라, 동일한 설계가 다른 환경에서 어떻게 작동하는지를 확인한 기록입니다.

이것은 시리즈의 제2회입니다. 제1회(IBM Bob과 MCP로 토대를 구축한 이야기)를 먼저 읽으면 이 기사의 전제를 파악하기 쉽습니다.

▼ 제1회는 이쪽

• 동일한 설정을 다른 도구(Claude Code)로 옮기는 검증을 한 이유
• 이행이 허무할 정도로 간단했던 이유
• 검증하며 깨달은 점(모델의 거동과 서브 에이전트(Sub-agent)의 자동 분류)
• 실제로 구동 중인 Skills와 프롬프트의 예

제1회에서 구축한 토대는 특정 도구에 의존하지 않는 형태를 의식했다. 규칙도 Skills도 특수한 기능이 아니라 단순한 Markdown으로 작성했다.

그렇다면, 이 설계는 정말로 도구 비의존적인가, 다른 도구로 옮겨도 똑같이 작동하는가,를 확인하고 싶어졌다. 검증으로서 자연스러운 흐름이다.

더불어 제1회에서 썼던 「이용 한도 소비」나 「지시가 모호할 때의 출력 편차」와 같은 운용상의 깨달음이 다른 환경에서는 어떻게 변하는가에도 흥미가 있었다. 그래서 동일한 .bob 설정을 Claude Code의 .claude로 가져가서 구동해 보았다는 것이 이 기사의 흐름이다.

이 부분이 제1회의 복선 회수가 된다.

제1회에서 정비한 설정은 그 대부분이 단순한 Markdown 파일이다. 규칙도 Skills도 특정 도구에 락인(Lock-in)된 특수 포맷이 아니다.

.bob/
├── rules/ # 코어 원칙·규약(Markdown)
├── skills/ # 작업 절차(Markdown)
...

Claude Code도 생각하는 방식이 놀라울 정도로 비슷하다.

.claude/
├── CLAUDE.md # 프로젝트 공통 지시 사항
├── agents/ # 서브 에이전트(Bob의 커스텀 모드에 해당)
...

한 일은 대략 말하자면 .bob의 내용을 .claude로 가져가서 파일의 위치와 맨 앞의 서식을 맞춘 것뿐이다. 규칙의 본문이나 Skill의 절차는 거의 고치지 않고 그대로 작동했다.

이것은 「이행이 쉬워서 운이 좋았다」라는 이야기에 그치지 않는다. 워크플로우 설계가 특정 도구에 얽매여 있지 않았음을 확인한 것이다. 제1회에서 「레일을 까는 것」에 시간을 투자한 것이 도구를 넘나들어도 살아있었다는 점이 검증에서 가장 기뻤던 부분이다.

「규약이나 절차를 도구 고유의 기능이 아니라 Markdown으로 솔직하게 작성해 둔다」. 이것이 이행 비용을 낮추는 소소한 요령이라고 생각한다. 자산이 플레인 텍스트(Plain Text)라면 목적지가 어디든 가져갈 수 있다.

동일한 의뢰라도 도구나 모델이 바뀌면 돌아오는 결과물의 질감이 달라진다.

제1회에서 「모호한 지시나 어려운 설계 판단으로 인해 예상했던 결과물이 나오지 않는 경우가 있었다」고 썼다. Claude Code에서 비슷한 방식으로 요청하면 설계 의도를 파악한 제안이 돌아오는 장면이 늘어나, 재작업(Re-work)이 줄어드는 느낌을 받았다.

다만, 사양서를 준비하여 전제를 전달하는 등의 궁리는 어느 쪽에서든 유효하다. 토대가 같다면, 즉 토대가 튼튼하다면 그만큼의 안정감은 그대로 작용한다. 엔진이 바뀌면 주행은 달라지지만, 레일이 깔려 있다는 사실 자체의 가치는 변하지 않는다는 것이 솔직한 인상이었다.

검증하면서 가장 「오, 편하다」라고 느낀 것은 이것이다.

제1회의 토대에서는 컴포넌트를 만들 때는 개발 모드, 리뷰를 할 때는 리뷰 모드와 같이 작업할 때마다 스스로 모드를 전환해야 했다. 사소하지만 이것이 사고의 흐름을 끊는다.

Claude Code에서는 .claude/agents/에 둔 서브 에이전트가 각각 「자신이 언제 호출되어야 하는지」를 description

가지고 있다. 그리고 Claude가 그 설명을 읽고, 의뢰 내용에 따라 적절한 서브 에이전트(Sub-agent)로 자동 분배해 준다.

예를 들어, 다음과 같이 정의해 둔다.

---
name: component-dev
description: 신규 컴포넌트 작성 및 리팩터링(Refactoring) 시 사용. React Aria Components 기반의 스토리북 주도 TDD(Storybook-Driven TDD)를 자동 실행한다. 「Button 컴포넌트를 만들어줘」와 같은 의뢰로 기동한다.
...

이렇게 해두면, 「Button 컴포넌트를 만들어줘」라고 그냥 부탁하는 것만으로 개발 담당 서브 에이전트가 기동한다. 리뷰를 부탁하면 리뷰 담당이, 커밋 메시지를 부탁하면 그 담당이 움직인다. 나는 「무엇을 해달라고 할지」만 말하면 되었고, 「어떤 모드로 할지」를 의식할 필요가 없어졌다.

역할별로 권한을 제한한다는 제1회의 생각 방식은 그대로다. 다른 점은 「전환을 사람이 하느냐, 툴 측에서 하느냐」뿐이다. 그리고 그 작은 차이가 경험을 크게 바꾸었다.

토대로 준비하고 있는 스킬(Skills)은 대체로 다음과 같다. 모두 제1회부터 유용(Reuse)한 것이 중심이다.

Skill	역할
page-development	페이지 단위의 일괄 개발(디자인 분석 → 각 컴포넌트 개발 → 통합 → 확인 → 사양서 업데이트)
...

프롬프트(Prompt)는 특별한 주문을 외울 필요가 거의 없다. 솔직하게 일본어(자연어)로 부탁하는 것이 기본이다. 몇 가지 예를 들어보겠다.

・「목록 페이지를 만들어줘」
→ 페이지 개발 스킬(Skill)이 기동하여 각 파트의 개발까지 이끌어준다
・「Button 컴포넌트를 만들어줘」
...

포인트는, 프롬프트를 똑똑하게 만들기보다 Skill과 서브 에이전트의 description을 잘 정돈해 두는 것이다. 입구에서의 부탁이 거칠더라도 분배 대상이 절차를 가지고 있기 때문에 출력의 질이 안정된다.

실제로 페이지 개발을 부탁했을 때의 흐름은 대체로 다음과 같다.

페이지 개발을 1회 부탁했을 때의 흐름(클릭하여 전개)

의뢰: 「목록 페이지를 만들어줘」
1. Figma로부터 디자인 정보 취득
2. 사양서 확인 및 업데이트
...

단 한 번의 의뢰로 여기까지를 레일에 따라 진행해 준다.

좋은 점만 쓰면 거짓말 같으므로, 직접 사용해 보며 느낀 점도 솔직하게 적어둔다.

「Claude Code = 터미널 전용」이라며 경계하는 사람이 있을지도 모르지만, 실제로는 VS Code 확장 기능이 준비되어 있어, IBM Bob과 마찬가지로 에디터 내의 GUI로 조작할 수 있다. 나도 평소에는 이 확장 기능을 사용하고 있으며, 터미널에 매달려 있을 필요는 없다. CLI가 서툴러도 문제없었다.

비용 감각은 어느 쪽이든 의식이 필요하다. 모델이 똑똑한 만큼, 아무 생각 없이 크게 던지면 그만큼 소비된다. 「작게 나누어 작업한다」는 제1회의 교훈은 그대로 살아있다. -
자동 분배가 만능은 아니다. 대부분 적절한 담당에게 배정되지만, 의뢰가 모호하면 의도와 어긋날 때도 있다. 그럴 때는 「리뷰만 하고 코드는 건드리지 마」와 같이 한마디 덧붙이면 안정된다. -
우열의 문제가 아니다. 둘 다 장단점이 있으며, 궁합이나 취향에 따라 선택하면 된다. 이번 검증에서 확인하고 싶었던 것은 「어느 쪽이 위인가」가 아니라, 「동일한 설계가 양쪽 모두에서 통용되는가」였다. 그리고 그것은 통용되었다.

• 제1회에서 구축한 설정(규칙·절차)은 플레인한 Markdown 중심이었기에, 다른 툴로 거의 그대로 옮길 수 있었다
• 이는 「워크플로우 설계가 툴에 의존하지 않았다」는 확인이다. 토대에 대한 투자는 툴을 넘나들며 살아남는다
• 검증을 통해 깨달은 것은 (1) 툴/모델에 따라 응답의 질감이 달라진다는 것, (2) 서브 에이전트의 자동 분배로 모드 전환이 불필요해진다는 것이다
• 프롬프트를 다듬기보다 Skill과 서브 에이전트의 description을 정돈하는 것이 더 효과적이다 - 툴은 둘 다 장단점이 있다. 우열보다는 궁합으로 선택하면 된다

제1회와 통틀어 말하고 싶었던 것은, 「어떤 AI 툴을 사용할 것인가」보다 「AI가 헤매지 않는 토대를 어떻게 설계할 것인가」가 훨씬 더 수명이 길다는 것이다. 툴은 변한다. 설계는 남는다.

여기까지 읽어주셔서 감사합니다. 「우리 회사는 이렇게 설계하고 있다」, 「이 설정은 어떻게 하고 있나?」 등 댓글로 편하게 알려주세요.