앞으로 FE는 “컴포넌트 설계”만 잘해서는 부족하다.
“에이전트 호출 인터페이스 설계”까지 포함해야 한다.
요즘 프론트엔드 논의에서 자주 생략되는 문장이 있다.
“에이전트가 이 플로우를 호출해도 안전한가?”
WebMCP·DevTools for agents 같은 흐름의 배경은 이미 정리한 글을 참고한다.
이 글은 설계 체크리스트에만 집중한다.
TL;DR
- UI를 액션 인터페이스로 재해석해야 한다.
- 호출 가능한 단위마다 권한/검증/취소/재시도 정책이 필요하다.
- 디버깅 대상은 코드뿐 아니라 “생성-검증-수정 루프”다.
- 팀은 이제 사람 경로와 에이전트 경로를 동시에 운영해야 한다.
왜 FE 설계가 바뀌는가
기존 FE 설계의 기본 단위는 화면과 컴포넌트였다.
- 화면 진입
- 사용자 이벤트
- API 요청
- 렌더링 업데이트
에이전트가 들어오면 기본 단위가 바뀐다.
- 호출 가능한 행동 단위 (검색, 선택, 적용, 확정)
- 행동 단위별 권한과 제약
- 실패 시 되돌림과 재시도 정책
즉, 버튼/폼/모달이 아니라 동작 계약(contract)을 설계해야 한다.
FE 관점 체크리스트 7개
1) Action Boundary
- 어느 동작까지 자동화 허용인가?
- 조회와 변경을 구분했는가?
- 확정 단계 전 사용자 확인 지점을 두었는가?
2) Permission Model
- 동작별 권한 수준이 분리됐는가?
- 동일 사용자라도 호출 맥락에 따라 제한이 다른가?
- 위험 동작은 2단계 확인이 있는가?
3) Input/State Validation
- 입력 검증 책임이 UI/API 어디에 있는가?
- stale state를 감지하는 버전 필드가 있는가?
- 검증 실패 메시지가 복구 가능하게 작성됐는가?
4) Idempotency and Retry
- 같은 요청 재실행 시 결과가 안전한가?
- 재시도 기준(네트워크/서버/검증 실패)이 분리됐는가?
- 중복 실행 방지 키를 갖고 있는가?
5) Observability
- 에이전트 경로 요청을 식별할 수 있게 로깅하는가?
- 에러를 “사용자 오류/시스템 오류/정합성 오류”로 분류하는가?
- 성능 지표를 사람 경로와 비교할 수 있는가?
6) Rollback and Recovery
- 실패 시 이전 상태 복구 경로가 있는가?
- 부분 성공(partial success) 시 사용자 안내가 있는가?
- 운영자가 수동 개입할 수 있는 핫패스가 있는가?
7) Trust UX
- 사용자가 “무엇이 자동으로 실행됐는지” 볼 수 있는가?
- 확정 전 요약을 읽고 취소할 수 있는가?
- 실패를 숨기지 않고 다음 행동을 명확히 제시하는가?
DevTools for agents를 FE 프로세스에 넣는 법
도구를 도입했다고 끝나면 변화가 없다.
실무에서는 CI/리뷰 루프로 내려와야 한다.
- 에이전트 산출물 전용 검증 단계 추가
- 접근성 검사
- 성능 회귀 검사
- 보안 정적 점검
- 실패 시 원인 기록 형식 통일
- 어떤 입력/컨텍스트였는지
- 어떤 검증에서 깨졌는지
- 어떤 수정으로 회복했는지
- 재현 가능한 최소 시나리오 유지
- “다시 돌리면 붙는” 방식 금지
핵심은 자동화 도입이 아니라, 재현성과 학습 가능성 확보다.
적용 우선순위: Now / Next / Later
Now (지금)
- 액션 경계 정의
- 로깅/트레이스 분리
- 검증 실패 포맷 통일
Next (다음 분기)
- 재시도/idempotency 정책 정리
- 에이전트 경로 성능 베이스라인 수립
- 위험 동작 2단계 확인 UX 도입
Later (실험)
- HTML-in-Canvas 같은 실험적 조합
- 복합 서페이스(검색/콘텐츠/커머스) 연동 UX
마치며
에이전트 시대 FE는 더 쉬워지지 않는다.
다만 더 명확해진다.
무엇을 자동화할지보다,
어디까지 자동화해도 안전한지를 설계하는 역할이 FE의 핵심이 된다.
한 줄 결: 다음 세대 FE 경쟁력은 컴포넌트 퀄리티가 아니라 인터페이스 경계 설계에서 갈린다.