매트 포콕(Matt Pocock)의 Skills 프레임워크는 간결한 기술과 반복적인 피드백을 바탕으로 에이전트의 구현을 돕지만, 사양 작성과 테스트에서 형식적인 절차를 따르는 데 그치거나 설정 안내가 오래된 문제도 드러냈다. 이 프레임워크를 직접 써본 스콧 로직(Scott Logic)의 엔지니어는 좋은 출발점이지만 팀의 관례에 맞게 조정해야 하며, 사람의 판단을 맡길 수는 없다고 평가했다.
그는 개인 앱 KartLog를 처음부터 다시 만드는 방식으로 프레임워크를 시험했다. KartLog는 카트 레이싱 세션을 기록하는 프로그레시브 웹 앱(PWA)으로, 실제 사용자가 일부 있다. 시험은 규모가 크지 않은 새 애플리케이션에서 이뤄졌고, Skills를 따로 조정하지 않았다.
/grill-with-docs는 약 5분 동안 질문을 주고받으며 프로젝트 맥락을 정리했고, 약 45줄의 CONTEXT.md와 아키텍처 결정 기록(ADR)을 만들었다. 카트·엔진·타이어를 하나의 ‘카트’ 기록으로 묶지 않고 서로 교체할 수 있는 부품으로 모델링한 결정은, 실제 부품별 사용량을 추적해야 한다는 점을 잘 담았다고 봤다. 해당 Skill이 질문 방식과 도메인 모델링을 조합해 구성됐으며, Skills 자체도 간결한 점은 긍정적으로 평가했다.
반면 /to-spec이 만든 사양은 사용자 스토리 형식으로 CRUD 기능을 길게 나열했다. 엔지니어는 이를 데이터 모델로 표현하는 편이 더 간결하고 사람과 에이전트 모두에게 요구사항을 전달하기 좋았을 것이라고 지적했다. 절차를 충실히 수행하는 것과 절차의 목적을 달성하는 것은 다르며, 사양의 목적은 요구사항을 간결하게 담아 전달하는 것이라는 설명이다. 이후 /to-tickets는 가볍고 타당해 보이는 티켓 8개를 만들었다.
/implement는 실패하는 테스트를 먼저 쓰고 구현한 뒤 검증하는 레드-그린 TDD 방식을 따랐다. 구현 과정에는 코드가 프로젝트 표준과 사양을 따르는지 확인하는 code-review Skill도 포함됐다. 프로젝트 코딩 표준이 제공되지 않아 기본적인 코드 스멜 목록을 적용했고, 두 검토 기준에서 초기 구현의 버그를 찾아 수정했다. 엔지니어는 이런 피드백을 반복하는 구현 루프를 유용하게 봤다. 프로젝트나 조직의 기준을 에이전트가 따르도록 명시하는 데 가치가 있다는 점도 강조했다.
그러나 테스트는 과도하게 반복됐다. 앱은 Supabase를 백엔드로 사용하고, 테스트를 위해 얇은 추상화 계층을 둬 UI가 Supabase에 직접 의존하지 않도록 했다. 에이전트는 각 데이터 항목의 CRUD 동작을 테스트했지만, 실제 저장 로직은 여러 항목이 공유하는 약 15줄의 일반 어댑터 코드였다. 엔지니어는 테스트가 코드 자체보다 만들어 둔 모의 객체를 검증하는 데 더 치우쳤다고 봤다.
설정 안내 도구인 /wizard도 한계를 보였다. 이 도구는 Supabase 설정 과정을 단계별로 안내하는 셸 스크립트를 만들었지만, 사라진 페이지나 실제로 없는 버튼을 안내했다. 설정 과정은 직선적으로 진행되지 않을 수 있는데, 스크립트에는 에이전트와 함께 문제를 해결할 우회로가 없었다. 안내가 막히면 해당 단계에서 진행할 수 없었다.
엔지니어는 시험 범위가 제한적이었다는 점을 전제로, 프레임워크가 가볍고 조정하기 쉬우며 구성 기술도 단순하다는 점을 장점으로 들었다. 구조화된 개발 경험이 적은 엔지니어에게는 체계적인 접근을 익히는 데 도움이 될 수 있고, 경험 많은 엔지니어에게는 자신의 관례를 반영한 에이전트 개발 흐름을 만드는 출발점이 될 수 있다는 평가다. 다만 기본 설정만으로 각 팀의 관례에 맞는 것은 아니므로 조정이 필요하다.
그는 이 프레임워크가 때로는 소프트웨어 개발의 절차를 흉내 내면서 그 절차를 가치 있게 만드는 판단까지 담지는 못했다고 지적했다. Skills는 작업을 안내하고 관례를 담을 수 있지만, 어떤 실천을 언제 왜 적용할지는 사람이 판단해야 한다. 에이전트에 어디까지 통제권을 넘길지는 개인의 선택이며, 경험과 절제가 필요하다는 결론이다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요