구현 속도는 플랜을 검토하는 방식에서 시작됩니다
AEKO 팀이 기능을 빠르고 안정적으로 만들기 위해 가장 많이 신경 쓰는 단계는 코드를 쓰기 전입니다. 하나의 에이전트에게 기획부터 구현까지 맡기기보다, 여러 관점으로 플랜을 만들고 통합한 뒤 사람이 실제 사용자 흐름을 확인합니다.
에이전트가 만든 긴 문서를 읽는 것만으로는 화면의 관계, 빠진 상태, 모호한 전환을 한눈에 찾기 어렵습니다. 그래서 AEKO는 통합된 플랜을 시각적인 artifact로 바꾸고, 구현 전에 사람이 검토할 수 있는 형태로 만듭니다.
AEKO의 플랜 오케스트레이션
Orchestrator는 먼저 Claude와 Codex에 서로 다른 관점의 플랜을 요청합니다. 두 결과에서 공통된 방향과 충돌하는 가정을 찾고, 구현 순서와 검증 기준을 하나의 플랜으로 통합합니다. 그다음 AEKO 팀이 구성한 Claude Code의 커스텀 /artifact-design 워크플로우로 플랜의 화면과 흐름을 시각화합니다.
/artifact-design의 역할은 플랜을 ‘보이게’ 만드는 것
/artifact-design이 사람의 검토를 대신하는 것은 아닙니다. 통합된 플랜을 화면, 다이어그램, 인터랙션처럼 검토 가능한 artifact로 만드는 역할을 합니다. Human Review는 그 결과를 보고 사람이 판단하는 별도의 마지막 단계입니다.
이 구분이 중요한 이유는 구현 가능성과 사용 경험이 같은 질문이 아니기 때문입니다. 에이전트는 논리적으로 완결된 플랜을 만들 수 있지만, 실제 사용자가 무엇을 먼저 보고 어디에서 망설일지는 사람이 시각적으로 확인할 때 더 잘 드러납니다.
Human Review에서 확인하는 것
- 사용자 흐름: 처음부터 완료까지 다음 행동이 자연스럽게 보이는가?
- 상태와 예외: 로딩, 빈 화면, 오류, 권한 차이처럼 빠진 상태는 없는가?
- 가정: 두 Planner가 서로 다르게 해석한 요구사항은 무엇인가?
- 검증 기준: 구현 후 무엇을 확인하면 완료라고 판단할 수 있는가?
에이전트와 사람은 서로 다른 부분을 잘 봅니다
AEKO의 개발 과정에는 이 외에도 목적에 맞춘 여러 커스텀 스킬이 접목됩니다. 하지만 플랜 단계에서 실제 기능의 모습을 사람의 눈으로 확인하는 과정은 가장 기본적인 품질 관리 중 하나입니다.
핵심은 도구 하나가 아니라 역할의 분리입니다. 에이전트는 대안을 빠르게 넓히고 플랜을 구체화합니다. Orchestrator는 결과를 통합하고, artifact는 플랜을 검토 가능한 형태로 바꿉니다. 사람은 최종적으로 제품의 방향과 사용자 경험을 판단합니다.