에이전트 기획을 구현 전에 검토하는 방법: /artifact-design

구현 속도는 플랜을 검토하는 방식에서 시작됩니다

AEKO 팀이 기능을 빠르고 안정적으로 만들기 위해 가장 많이 신경 쓰는 단계는 코드를 쓰기 전입니다. 하나의 에이전트에게 기획부터 구현까지 맡기기보다, 여러 관점으로 플랜을 만들고 통합한 뒤 사람이 실제 사용자 흐름을 확인합니다.

에이전트가 만든 긴 문서를 읽는 것만으로는 화면의 관계, 빠진 상태, 모호한 전환을 한눈에 찾기 어렵습니다. 그래서 AEKO는 통합된 플랜을 시각적인 artifact로 바꾸고, 구현 전에 사람이 검토할 수 있는 형태로 만듭니다.

AEKO의 플랜 오케스트레이션

Orchestrator는 먼저 Claude와 Codex에 서로 다른 관점의 플랜을 요청합니다. 두 결과에서 공통된 방향과 충돌하는 가정을 찾고, 구현 순서와 검증 기준을 하나의 플랜으로 통합합니다. 그다음 Claude Code의 /artifact-design 워크플로우로 플랜의 화면과 흐름을 시각화합니다.

/artifact-design의 역할은 플랜을 ‘보이게’ 만드는 것

/artifact-design이 사람의 검토를 대신하는 것은 아닙니다. 통합된 플랜을 화면, 다이어그램, 인터랙션처럼 검토 가능한 artifact로 만드는 역할을 합니다. Human Review는 그 결과를 보고 사람이 판단하는 별도의 마지막 단계입니다.

이 구분이 중요한 이유는 구현 가능성과 사용 경험이 같은 질문이 아니기 때문입니다. 에이전트는 논리적으로 완결된 플랜을 만들 수 있지만, 실제 사용자가 무엇을 먼저 보고 어디에서 망설일지는 사람이 시각적으로 확인할 때 더 잘 드러납니다.

Human Review에서 확인하는 것

• 사용자 흐름: 처음부터 완료까지 다음 행동이 자연스럽게 보이는가?
• 상태와 예외: 로딩, 빈 화면, 오류, 권한 차이처럼 빠진 상태는 없는가?
• 가정: 두 Planner가 서로 다르게 해석한 요구사항은 무엇인가?
• 검증 기준: 구현 후 무엇을 확인하면 완료라고 판단할 수 있는가?

에이전트와 사람은 서로 다른 부분을 잘 봅니다

AEKO의 개발 과정에는 이 외에도 목적에 맞춘 여러 커스텀 스킬이 접목됩니다. 하지만 플랜 단계에서 실제 기능의 모습을 사람의 눈으로 확인하는 과정은 가장 기본적인 품질 관리 중 하나입니다.

핵심은 도구 하나가 아니라 역할의 분리입니다. 에이전트는 대안을 빠르게 넓히고 플랜을 구체화합니다. Orchestrator는 결과를 통합하고, artifact는 플랜을 검토 가능한 형태로 바꿉니다. 사람은 최종적으로 제품의 방향과 사용자 경험을 판단합니다.