2026년 신년 연휴 동안, Joomla 커뮤니티 채팅 중 한 동료가 AI 에이전트(AI agent)를 위한 프롬프트(prompt)와 그 결과물을 공유했습니다. 그보다 일주일 전, 그는 Gemini CLI를 처음 사용해 보았습니다. 그때까지 저는 웹 버전으로만 AI를 사용해 왔고, 전반적으로 그것만으로도 충분했습니다. 하지만 그 텍스트의 벽, CLI 요청, 그리고 응답의 벽을 보았을 때 가장 먼저 든 생각은 다음과 같았습니다.

이 모든 것을 배우고 싶지 않아! 또 새로운 것이라니, 이제 지긋지긋해...

그 후 시행착오의 단계가 이어졌고, 다음과 같이 역할 기반의 제안을 담은 GitHub의 기성 커뮤니티 스킬 패키지(skills packages)를 사용하려는 시도도 있었습니다.

"당신은 40년 경력을 가진 초특급 메가 백엔드 Joomla 개발자입니다. 저를 위해 멋지게 만들어 주세요."

이 반년의 과정 중간 어디쯤에서 저는 저의 프로세스(processes)를 공식화하기 시작했습니다. 여기서 프로세스란 개발뿐만 아니라 SEO, 분석(analytics), 비즈니스 분석(business analysis), 프로세스 연구(process study) 및 프로세스 설계(process design) 등을 의미합니다. 결과적으로, 이 모든 것은 대개 Joomla 사이트와 연결되거나 그것으로 이어집니다. 공식화 과정을 통해 저는 모든 프로세스에 공통적으로 적용되는 몇 가지 기초적인 사항을 이해하게 되었습니다. 자세한 내용은 아래에서 다루겠습니다.

이제 AI 에이전트를 위한 공식화된 작업 프로세스(work processes)를 생성하기 위한 프레임워크인 Process Forge (GitHub)에 대한 저의 작업물을 대중에게 소개하고자 합니다.

숙련된 바이브 코더(vibe coders)분들께, 만약 여기에 뻔한 내용이나 이미 잘 알려진 논제들이 등장하더라도 미리 용서를 구합니다. 업무량 때문에 다른 사람들이 무엇을 하고 있는지 검색하고 살펴보는 데 너무 많은 시간을 할애할 수 없었습니다. 저는 새로운 궤도로 전환해야만 했습니다.

시작점 (Starting Points)

"이게 다 무엇을 위한 것인가?" 그리고 "왜 이런 방식인가?"라는 질문에 답하기 위해, 지난 6개월 동안 실무를 통해 체득하고 Process Forge를 만들 때 근거로 삼았던 몇 가지 시작점을 제시하겠습니다. 이러한 결론 중 일부는 나중에 기사나 소셜 미디어 게시물에서 접한 다른 사람들의 연구 결과에서도 확인되었습니다.

1. 기술 스택에 대한 AI 모델의 내부 지식은 현대의 실제 관행보다 심각하게 뒤처져 있는 경우가 가장 많습니다. 이는 스택마다 차이가 매우 큽니다. "현재로서는"이라는 말을 덧붙일 수 있겠지만, 일반적으로 이는 여전히 유효한 전제입니다.
2. AI 에이전트 (AI agent)가 제대로 작동하려면, 인간이 업무를 위해 제공받는 모든 것, 즉 지식과 도구, 재사용 가능한 기성 템플릿 (templates)이 제공되어야 합니다.
3. AI 에이전트에게는 일정 수준의 자유가 필요하지만, 이는 정의된 통로(corridor) 내에서, 지정된 벡터 (vector)를 따라 이루어져야 합니다.
4. 특정 AI 제공업체 (AI provider)의 생태계에 종속되어서는 안 됩니다. "두뇌를 교체할" 수 있는 방법이 있어야 합니다 (에이전트 자체가 당신을 자신들의 생태계에 묶어두려 하더라도, 에이전트의 홈 베이스가 .codex, .claude 등이 되어서는 안 되며, 중립적인 무언가가 있어야 합니다).
5. 모든 프로젝트 메모리와 프로세스는 파일 형태로 구조화되어야 합니다.
6. 당사자 스스로가 무엇(WHAT)이, 어떻게(HOW), 왜(WHY) 일어나고 있는지를 먼저 이해해야 합니다. 그렇지 않으면 AI는 당신의 삶에 더 많은 혼란만을 가져올 것입니다.

우리가 AI 에이전트, 그리고 일반적인 AI와 함께 작업할 때, 우리는 업무가 빠르고 훌륭하게 수행되기를 기대합니다. 왜냐하면 이것은 빌어먹을 인공 지능 (Artificial Intelligence)이기 때문입니다. 하지만 실제로는 그렇지 않은 것으로 드러났습니다. 삽 대신 당신은 다음과 같이 말하는 터보 굴착기를 받게 된 셈입니다: "밭을 갈고 있는데 바퀴가 빠졌어요. 임시 방편으로 빠르게 고치고 한쪽에는 궤도를 달아볼게요." 당신은 여전히 이 물건을 어떻게 다루는지 배워야 하며, 어디에 어떻게 적절히 적용해야 하는지 알아야 합니다. 미리 말씀드리자면, 여기에 쓰인 거의 모든 내용은 저만의 휴리스틱 (heuristics)의 결과이며 따라서 순전히 주관적입니다. 몇 달이 지나서야 AI Factory (link one, link two (Habr))와 GSD Core를 접하게 되었지만, 이미 제 도구로 전속력으로 작업하던 중이라 너무 늦은 상태였습니다. 이와 유사한 다른 도구들이 있을 수도 있습니다.

Process Forge 개념 (Concepts)

저는 이 개념들을 진화 과정에서 "실전(combat)" 조건 하에 나타나고 테스트된 순서대로 설명하겠습니다. 이렇게 하면 결정의 역사와 논리가 더 명확해질 것입니다.

채팅 대신 프로세스 (Process Instead of Chat)

두 달 동안 채팅 모드(chat mode)로 작업하고, GitHub에서 가져온 역할 기반 제안(예: "당신은 40년 경력을 가진 초특급 메가 백엔드 Joomla 개발자입니다. 저를 위해 멋지게 만들어 주세요")이 포함된 기성 커뮤니티 스킬 패키지들을 사용해 본 결과, 빠른 검색과 이 모든 것에 대한 저의 의구심을 AI와 논의한 끝에 저는 개발 프로세스(development process)를 구축해야 한다는 결론에 도달했습니다. 처음에는 개발을 위해서만 말이죠.

채팅 기록(Chat history)은 프로젝트 데이터나 프로젝트 메모리의 신뢰할 수 있는 소스가 될 수 없습니다. 모든 새로운 세션은 에이전트(agent)에게 제로 상태, 즉 백지상태(tabula rasa)에서 시작됩니다. 에이전트에는 이 대상이 무엇인지, 그리고 어떻게 다루어야 하는지에 대한 프로젝트 컨텍스트(project context)가 로드되어야 합니다. 이것이 바로 모든 프로젝트 메모리와 프로세스가 구조화되어 파일로 저장되어야 하는 이유입니다. 지난 봄, 저는 "자율적인 프로세스의 결과로 생성된 파일"이라는 의미에서의 "아티팩트 (artifact)"라는 단어를 접하게 되었습니다. 업계에서 일어나고 있는 일을 제가 판단하기로는, 모든 이들이 폴더나 Obsidian, 혹은 다른 어딘가에 다양한 지침(instructions), 스킬(skills) 등을 담은 자신만의 마크다운 (Markdown) 파일들을 축적하고 있습니다.

저의 요구사항은 즉각적으로 프로세스에 대한 것이었습니다. 그래서 며칠간의 논의 끝에 저는 **아티팩트 기반 개발 흐름 (artifact-based development flow)**에 도달했습니다. 이는 프로젝트 작업 규칙을 설명하는 폴더와 파일들의 집합이었습니다. 이 파일들은 제가 Joomla 라이브러리, 플러그인, 컴포넌트를 만드는 동안 3개월에 걸쳐 사용하고 개선해 온 워크플로 단계(workflow stages)를 설명했습니다. 아래 접힌 부분에서 단계들에 대한 대략적인 감을 잡으실 수 있습니다. 수정된 형태로, 이것은 Process Forge의 "기본 제공 (out-of-the-box)" 프로세스 중 하나로 포함되었습니다.

예시 프로세스 단계:

또한, 전체 흐름은 task-log, agent-log, verification-log, 그리고 tool-telemetry.ndjson을 유지했습니다. 구체적인 로그는 단계 (stage)에 따라 달라졌습니다. 텔레메트리 (Telemetry)는 도구 사용 내역과 해당 도구들을 사용한 이유를 기록합니다. 예를 들어, MCP PhpStorm이 필요한 작업을 수행할 수 없거나 어떤 이유로 인해 막혔을 경우, 대체 수단 (fallback)으로 일반 셸 (plain shell)이 사용되었습니다.

지식을 AI 프로세스에 연결하기

AI 모델 자체에 내장된 지식은 대개 현재의 현실보다 뒤처져 있습니다. 유료 상위 모델들은 최근 사건들에 대해 어느 정도 알고 있지만, 그마저도 항상 그런 것은 아닙니다. 저의 주관적인 평가로는, 웹 검색 (web search) 또한 AI 에이전트 (agent)에게 더 많은 시간과 토큰 (tokens)을 소모하게 하므로, 모든 현재 지식은 손에 닿는 곳에 있어야 하며 에이전트는 이를 통해 컨텍스트 (context)를 구축해야 합니다. 거의 모든 것이 참조 자료로 사용될 수 있습니다:

• 현재 버전의 소스 코드 (source code),
• 공식 문서의 스냅샷 (snapshots, 로컬 복사본),
• 본인 또는 타인의 개발 아티클 (articles),
• 특정 작업을 해결하기 위한 레시피 (recipes)가 담긴 본인의 노트,
• 사이트 링크.

저는 Joomla를 사용하므로, 제 저장소에는 다음과 같은 것들이 있습니다:

• 여러 Joomla 코어 브랜치 (core branches)의 소스 코드,
• 제가 정기적으로 작업하는 주요 Joomla 확장 기능 (extensions)의 소스 코드 (JoomShopping, RadicalMart 등),
• 웹 풀스택 (web full stack)을 위한 공식 문서의 복사본: manual.joomla.org, HTML / CSS / JS / PHP, 그리고 여러 프레임워크 (frameworks)에 대한 문서,
• 저의 아티클과 동료들의 일부 아티클,
• 다양한 API에 대한 문서 (REST인 경우 실제 응답 덤프 (dumps)를 추가하여 보완함),

등등입니다. 네, Context7(기계 문서화를 위한 서비스 및 MCP)이 존재한다는 것은 알고 있습니다. 하지만 제가 기억하기로는 어느 시점부터 요청(requests)을 제한하기 시작했고, 예상대로 요청 패키지가 포함된 요금제(pricing plans)를 도입했습니다.

전반적으로, 이 섹션은 온프레미스 (on-premise) vs SaaS의 관점에서 다뤄집니다. 즉, 우리가 직접 우리를 위해 수동으로 수행하거나, 아니면 다른 누군가가 우리를 대신해 돈을 받고 수행하는 것입니다. 아마 이미 짐작하셨겠지만, 현재 저는 전자를 지지합니다. )) 당연히 이 접근 방식을 취하면, 당신이나 당신의 AI 에이전트가 지식을 최신 상태로 유지해야 할 의무를 지게 됩니다.

도구(Tools), MCP, 그리고 템플릿(Templates) 연결

템플릿 (Templates)

템플릿은 단순하기 때문에 이것부터 시작하겠습니다. 저의 경우, 템플릿은 복사하여 약간만 수정하면 바로 사용할 수 있는 별도의 완성된 코드 조각들입니다. AI 에이전트의 경우, 이들을 폴더에 넣고 각 폴더에 이 템플릿이 무엇인지 그리고 어떻게 사용하는지를 설명하는 README.md를 제공하는 것이 더 좋습니다.

하지만 반드시 코드일 필요는 없습니다. 디자인 조각, 비디오 조각 (footage) 등 에이전트가 다루는 것이라면 무엇이든 가능합니다.

도구 (Tools) 및 MCP

도구란 AI 에이전트가 당신의 장치에서 사용할 수 있는 것을 의미합니다. 개발자에게는 git, GitHub CLI, 파이프라인 실행(pipeline runs), 린터(linters), 수정 도구(fixers), 패키저/빌더(packagers/builders), 로컬 및 원격 테스트 스탠드 등이 포함될 수 있습니다. SEO \ GEO 전문가에게는 다양한 서비스 API에 자동 액세스하기 위한 작은 유틸리티(Wordstat 및 SERP 데이터 수집을 위한 Yandex API), Screaming Frog CLI 등이 해당될 수 있습니다. 일반적인 영상 제작 환경 또한 그 나름의 유사한 도구들을 가지고 있을 것이라 생각합니다.

가장 중요한 점은 도구가 워크스테이션에 전역적으로(globally) 설정되어야 한다는 것입니다. 그래야 서로 다른 프로젝트들이 동일한 방식으로 도구를 사용할 수 있기 때문입니다. 예를 들어, 당신이 작성하는 80개의 플러그인 전체에서 하나의 빌더 인스턴스가 사용되는 것과 같습니다.

이 경우 MCP는 Model Context Protocol을 통해 사용할 수 있는 동일한 종류의 도구로 나타납니다. 브라우저가 필요한 작업의 경우 Playwright / Chrome DevTools / Firefox DevTools가 될 수 있습니다. 저의 경우에는 MCP IDE PhpStorm이 될 수 있고, 기호적 코드 분석 (symbolic code analysis)을 위한 Serena 등이 될 수 있습니다.

MCP IDE를 통해 코드를 작업할 때 파일 인코딩 (file encodings) 및 파일 시스템 권한 (file-system permissions) 문제가 더 적다는 것을 발견했습니다. 또한, MCP를 통해 에이전트는 검사 (inspections)로부터 더 많은 정보를 받고 테스트를 실행할 수 있습니다. 하지만 에이전트는 이미 콘솔에 직접 접근할 수 있음에도 불구하고 PhpStorm 콘솔을 통해 셸 명령 (shell commands)을 실행할 수도 있으므로, 에이전트가 엉뚱한 짓을 시작하기 전에 제때 잡아내야 합니다.

프로세스에 대하여 다시 한 번

Joomla 및 그 확장 기능(extensions)과 함께 작업하는 맥락에서, 저는 전체 엔지니어링 프로세스 (engineering process)를 통해 작업하려고 노력합니다. 즉, 필요한 기능을 논의하고, 구현을 계획한 다음, 코드를 작성하고, 엔드 투 엔드 테스트 (end-to-end tests)를 실행하며, 패키지를 마무리 및 빌드하고, semver에 따라 릴리스를 게시합니다. 그 후에는 릴리스 후 작업들이 이어집니다. 두 가지 언어로 문서를 업데이트하거나 처음부터 새로 작성하고, 두 가지 언어로 스크린샷을 준비하며, 한 가지 언어로 영상을 제작하고, 15개 이상의 플랫폼에 설명을 포함한 새 버전 공지사항을 게시하는 등의 작업들입니다...

AI 에이전트와 작업하는 방법을 이해하게 되면서, 우리의 공동 작업 결과물이 쌓이기 시작했습니다. 그리고 새로운 문제가 나타났습니다. 이 모든 것을 언제 확인하고 게시해야 하는가 하는 점입니다. 에이전트를 사용하면 코드에 소비되는 시간은 줄어들었지만, 계획과 테스트에 소비되는 시간은 늘어났습니다. 그리고 릴리스 후 작업들은 사라지지 않았습니다...

따라서 다음 실험은 문서를 작성하고, 스크린샷을 준비하며, 이 모든 것을 사이트에 게시하도록 에이전트 (Agent)를 적응시키는 것이었습니다. 이미 구축된 파일 기반 프로세스 (File-based process)가 이 작업 또한 처리했습니다. 커다란 불신을 품은 채 수십 번의 반복 (Iteration)을 거치며, 저는 에이전트의 책임 영역을 확장하기 시작했고 마침내 완전한 릴리스 게시 단계에 도달했습니다. 일반적으로는 잘 작동하지만, 물론 기대만큼 인간적인 정서가 담겨 있지는 않습니다.

종종 특정한 생각이나 정보 조각들이 우리 주변을 오랫동안 맴돌며, 우리가 그것을 인지하고 이해하기 전까지 눈앞에 여러 번 나타나곤 합니다. 이 경우, 저는 제 업무가 다양한 복잡성을 가진 프로세스들로 둘러싸여 있다는 이해가 형성되기 시작했습니다. 코딩보다 한 단계 높은 수준으로 올라가, 단계의 수가 다르거나 그 사이의 산출물 (Artifact), 관계 등이 존재할 수 있는 보편적인 프로세스 엔티티 (Process entity)를 식별하는 것이 논리적으로 다가왔습니다. 그렇게 Process Forge가 나타나기 시작했습니다.

이제 이 시스템은 내부 프로세스 (Internal processes), 즉시 사용 가능한 프로세스 (Out-of-the-box processes), 그리고 자신만의 프로세스를 생성하는 기능을 갖추고 있습니다. 프로세스는 분기 (Branch)될 수 있으며, 부모 프로세스 (Parent process)는 자식 프로세스 (Child process)의 결과를 기다린 후 작업을 계속할 수 있습니다.

플랫폼 및 전문화 (Platforms and Specialisations)

플랫폼 (Platforms)