최근에는 Claude Code와 Figma MCP를 사용하여 Figma 컴프(Comp)를 구현하고 있습니다.

문득 이런 생각이 들었습니다.

"이슈(Issue)에 사양을 정리하고, 브랜치(워크트리(Worktree))를 여러 개 생성해서, 여러 에이전트를 동시에 실행하면 컨플릭트(Conflict) 없이 폭속 개발을 할 수 있지 않을까!?"

하지만 기다리고 있었던 것은, 숨 쉬듯 발생하는 컨플릭트(Conflict)와의 진흙탕 싸움이었습니다 😇

기대와 절망 (엄청나게 귀찮음)

제가 생각했던 "절대로 에러가 발생하지 않을 흐름"은 다음과 같습니다.

• AI 에이전트가 구현을 마치고, 풀 리퀘스트(PR)가 올라온다.
• 그 시점에 로컬에 코드가 있으므로, 체크아웃(Checkout)하여 동작을 확인한다.
• 수정 사항이 있으면 PR에 코멘트를 남겨 에이전트에게 재수정을 요청한다.
• 브랜치에 푸시(Push)가 되어 PR이 업데이트되면, 만반의 준비를 갖추어 메인 브랜치에 머지(Merge)한다!
• 머지(Merge)가 완료되면, 가져온 브랜치를 로컬에서 열어 git pull 한다.

GitHub에 정통하지 않은 사람이 이런 야심 찬 워크플로우(Workflow)를 생각했을 리가 없죠. 두 번째 이후 에이전트의 PR을 머지(Merge)하려고 하면, 가차 없이 "CONFLICT"라는 글자가 화면에 떠오릅니다.

원인: 별도의 워크트리(Worktree)라도 결국 건드리는 것은 "같은 파일"

원인은 지극히 단순했습니다.

워크트리(Worktree)를 나누어 별개의 태스크를 병렬로 진행하더라도, 결국 에이전트들이 같은 SCSS 파일(_common.scss나 style.css 등)을 편집하고 있었기 때문입니다.

브랜치를 생성한 시점의 코드를 바탕으로 각 브랜치가 작업을 수행하므로, 여러 에이전트가 같은 파일을 편집하면 당연히 컨플릭트(Conflict)가 발생합니다.

에이전트의 작업 속도가 인간보다 압도적으로 빠른 만큼, 컨플릭트(Conflict)가 발생하는 빈도도 엄청나서 뇌가 타버릴 것 같은 기분이었습니다. 부하가 엄청납니다.

더 이상 이런 무익한 시간을 보내고 싶지 않기에 대책을 세웁니다.

대책 1: 귀찮더라도 섹션 내에서 컴포넌트화하기

역시, 하나로 이어진 파일에 모두가 써 내려가는 것이 만악의 근원입니다. 첫 번째 대책은 귀찮더라도 페이지 내의 섹션 단위로 파일을 세밀하게 분할하여, 물리적으로 건드리는 위치를 격리하는 것입니다.

여기서 다시 한번, WordPress(PHP) 개발의 답답함과 Vue.js의 훌륭한 개발 경험(DX) 차이를 절감하게 됩니다.

참고로 Vue를 사용하는 것은 참여 중인 프로젝트에서 사용했기 때문입니다. 사상이 강해서 React를 사용하지 않는 것은 아닙니다.

WordPress의 컴포넌트화는 번거롭다

WordPress에서도 컴포넌트화는 가능합니다. 다만, SCSS를 세밀하게 분할하려고 하면 새로운 파트(예를 들어 _mv.scss나 _news.scss)를 만들 때마다, 컴파일 전의 부모 파일(main.scss 등)을 열어서 굳이 수동으로 @use나 @import를 작성해야 합니다.

CSS 파일 수가 불필요하게 늘어나는 것도 깔끔하지 않고, 무엇보다 코드를 오가는 "컨텍스트 스위칭(Context Switching)" 비용이 너무 높아서 어쨌든 손이 많이 가고 귀찮습니다.

그 점에 있어서 Vue.js의 컴포넌트 지향 방식은 정말 훌륭하다고 생각합니다.

하나의 .vue 파일 안에 HTML도 JS도, 그리고 SCSS도 모을 수 있습니다.

"이 파트의 수정은 이 Vue 파일만 건드리면 된다"라고 완전히 캡슐화(Encapsulation)되어 있기 때문에, 에디터를 오갈 필요도 없고 에이전트끼리 같은 파일을 실수로 건드려 사고가 날 리스크도 격감합니다. 하기 편하네요...

【WordPress에서의 현실적인 타협안】

Vue에 대한 미련을 품으면서도 WordPress 프로젝트를 맡고 있는 이상, 에이전트에게 **"이번에는 _mv.scss만 편집해. 다른 파일은 일절 건드리지 마"**라고 파일 편집 경계를 엄격하게 지정하여 분리하는 궁리도 필요할지 모릅니다.

대책 2: 기존 프로젝트가 아니라면 애초에 WordPress를 사용하지 않는다

두 번째 대책은, 기존 프로젝트라면 어쩔 수 없지만 신규 프로젝트라면 **"압도적으로 개발 경험이 좋은 모던 프레임워크(Vue.js 등)로 이행하는 것"**이라는 선택입니다.

WordPress는 백엔드(PHP)와 프론트엔드가 밀접하게 결합되어 있어, "생각지도 못한 곳에서 에러가 발생한다", "원인 파악이 매우 어렵다"라는 함정이 다수 발생합니다.

만약 지금부터 자유롭게 설계할 수 있다면,

• WordPress는 단순한 입력용 백엔드(Headless CMS)로 취급하고, WordPress REST API를 호출한다. - 아예 microCMS와 같은 모던한 CMS를 사용한다.

그리고 프론트엔드는 Vue.js와 같은 모던 프레임워크(Modern Framework)로 구현한다. 이것만으로도 AI 에이전트의 병렬 작업 용이성은 몇 배로 뛰어오르며, 컨플릭트(Conflict)의 스트레스로부터 근본적으로 해방될 것 같은 기분이 듭니다. (아마도)

대책 3: 「병렬 작업을 그만두기」라는 현명한 퇴화

마지막 대책은 가장 투박하지만, 인간의 뇌 리소스를 고려하면 "이것이 최적해(Optimal Solution)가 아닐까?"라고 생각될 만한 선택입니다. 그것은 바로, **일부러 시대에 역행하여 "병렬로 작업하게 하지 않는다 (싱글 태스크화)"**는 것입니다.

"하나의 에이전트가 작업하는 동안에는 절대로 다른 에이전트에게 코드를 쓰게 하지 않는다"라고 철저히 지킵니다. 그렇게 하면 이론상 컨플릭트(Conflict)는 발생하지 않습니다.

언뜻 보면 개발 속도가 떨어지는 "퇴화"처럼 보이지만, 사실 그렇지 않습니다.

에이전트가 코드를 쓰는 동안, 인간(자신)은 다음 일을 하면 됩니다.

인간은 「지시(요건 정의)」 공장이 된다

• 에이전트 A에게 태스크(Task, 예: 헤더 구현)를 던져 실행시킨다.
• 에이전트 A가 코드를 쓰는 동안, 자신은 다른 이슈(Issue)를 생성한다.
• 다음 에이전트 B에게 넘기기 위한 "지시 요건"이나 Figma URL 등을 문서에 깔끔하게 정리한다.
• 에이전트 A의 PR(Pull Request)이 나오면, 빠르게 체크하여 머지(Merge) ＆ 로컬(Local)에 풀(Pull)한다.
• 토대가 최신 상태가 된 상태에서, 에이전트 B에게 다음 지시를 내린다.

컨플릭트(Conflict)가 발생한 후에 "아, 어디가 충돌하고 있는 거지?"라며 코드를 노려보고, 에이전트에게 수정 지시를 다시 내리는 비용은 인간의 뇌 리소스를 격렬하게 소모합니다.

그럴 바에는 작업 자체는 직렬(Single Task)로 돌리고, 인간은 「한 발 앞선 요건 정의」에 리소스를 전부 쏟아붓는다. 이 교통정리가 결과적으로 재작업(Rework)이 없고, 정신 건강 측면에서도 압도적으로 매끄럽게 개발이 진행된다는 경지에 도달했습니다.

이슈를 생성하고 PR을 체크함으로써 컨텍스트 스위칭(Context Switching)은 발생하지만, 컨플릭트(Conflict)와 싸우는 것보다는 훨씬 낫습니다.

요약: AI 시대의 엔지니어는 「초우수한 교통정리 아저씨」가 된다

Claude Code나 Figma MCP 덕분에 인간이 직접 손을 움직이는 시간은 극적으로 줄었습니다. 하지만 그 반면, **「어떻게 에이전트들을 충돌시키지 않고 걷게 할 것인가」**라는, Git의 할당과 교통정리 스킬이 매우 중요해질 것이라고 생각합니다.

WordPress의 연속적인 사양에 맞춰 "엄격한 파일 분할"을 지시할 것인가, 과감하게 "Vue.js 등의 Headless 구성"으로 방향을 틀 것인가, 아니면 "일부러 직렬로 움직이게 하여 다른 요건 정의에 집중할 것인가".

AI에게 휘둘리지 않기 위해서라도, 가장 하기 쉬운 「교통정리」를 찾아 나가려고 합니다!