역할 기반에서 기능 기반으로 — AI 에이전트 아키텍처 전환기

이 글은 SEMO 구축기 시리즈의 네 번째 글입니다.

11개 역할 기반 패키지의 한계

'풀스택인데 sax-next랑 sax-backend 둘 다 써야 하나요?' 이 한마디가 아키텍처 전환의 시작이었습니다. SAX는 프론트엔드, 백엔드, QA, PO 등 11개의 역할 기반 패키지로 구성되어 있었지만, 현대 개발 환경에서 역할 경계는 점점 흐려지고 있었습니다.

세 가지 핵심 문제가 있었습니다. 역할 경계의 모호함(풀스택 개발자에게 두 패키지를 강제), 중복되는 스킬(sax-next, sax-backend, sax-mvp 모두 'implement' 스킬 보유), 복잡한 사용자 경험('로그인 만들어줘'에 어떤 패키지를 쓸지 물어봐야 하는 상황).

새로운 설계: 기능 기반 3-Layer Architecture

역할이 아닌 기능으로 분류하는 것이 핵심 아이디어였습니다. '프론트엔드 개발자용 AI'가 아니라 '코드 작성 AI'. 'QA용 AI'가 아니라 '테스트 AI'.

Layer 0: semo-core (통합 Orchestrator)

11개로 분산되었던 Orchestrator를 단일 통합 Orchestrator로 합쳤습니다. 모든 요청이 하나의 경로를 통과하면서 라우팅 충돌과 우선순위 혼란이 사라졌습니다.

Layer 1: semo-skills (기능별 스킬)

152개의 분산된 스킬을 5개 기능으로 재분류했습니다. coder(코드 작성), tester(테스트), planner(기획), writer(문서), deployer(배포). 역할이 아니라 기능 중심이므로 어떤 개발자든 모든 스킬을 자연스럽게 사용할 수 있습니다.

Layer 2: Extensions (플랫폼 자동 감지)

가장 큰 UX 개선은 플랫폼 자동 감지였습니다. next.config.js가 있으면 Next.js, pom.xml이 있으면 Spring으로 자동 판별합니다. '[next] 버튼 만들어줘' 대신 '버튼 만들어줘'만으로 충분해졌습니다.

Before/After: 숫자로 보는 전환

• 패키지: 11개 → 7개

• Orchestrator: 11개 → 1개

• 스킬: 152개(분산) → 14개(통합)

• 설치: Git Submodule 여러 개 → CLI 원클릭

• 플랫폼 지정: 수동 태그 필수 → 자동 감지

가장 큰 변화는 사용자 경험이었습니다. '어떤 패키지를 써야 하지?'라는 고민이 사라지고, 자연어로 요청하면 SEMO가 알아서 판단합니다. 명시성을 약간 잃었지만, 사용성을 크게 얻었습니다. 명시적 제어가 필요한 경우에는 [platform: vue] 태그로 오버라이드할 수 있습니다.

아키텍처를 바꾼 뒤 다음 과제는 AI에게 대화를 넘어서는 기억력을 부여하는 것이었습니다. AI 에이전트에게 기억을 주다에서 그 이야기를 이어갑니다.