대부분의 사람들은 에이전트가 아니라 더 깔끔한 워크플로우가 필요하다.
Most people don’t need agents. They need cleaner workflows.
핵심 요약
AI 에이전트 도입 전, 복잡한 프로세스를 먼저 정리하는 것이 우선이라는 주장.
- 에이전트 도입 시기 — 프로세스가 명확하지 않은 상태에서 에이전트를 쓰면 혼란만 가중됨.
- 워크플로우 최적화 — 에이전트 없이 스크립트나 간단한 LLM 호출만으로 해결 가능한 경우가 많음.
- 입력 데이터 안정성 — 에이전트의 지능보다 입력 데이터의 일관성을 확보하는 것이 훨씬 중요함.
- 디버깅 효율성 — 프로세스를 단순화하면 에이전트가 실패했을 때 원인 파악이 훨씬 쉬워짐.
이런 시스템들을 여럿 구축하면서 계속 눈에 띄는 점이 있음:
사람들이 너무 일찍 에이전트 단계로 점프한다는 거임.
엉망인 프로세스를 보고는
오케이, 에이전트를 추가해서 처리하자
라고 생각함.
하지만 애초에 프로세스 자체가 명확하게 정의된 적이 없음.
그래서 무슨 일이 벌어지냐?
- 에이전트가 그 모든 엉망진창을 그대로 물려받음
- 일관성 없는 결정을 내림
- 계속 확인해줘야 함
- 결국 신뢰할 수 없다고 에이전트 탓을 함
진짜 문제는 워크플로우였는데 말이지.
많은 "에이전트 사용 사례"는 그냥: 입력 → 처리 → 출력 임.
이걸 제대로 매핑하면 다음과 같은 것들로 해결 가능함:
- 간단한 스크립트
- 워크플로우 도구
- 중간에 LLM 호출 한 번
플래닝 루프도 필요 없고
멀티 에이전트 설정도 필요 없고
메모리 레이어도 필요 없음
나한테 진짜 힘들었던 건 입력값이 엉망일 때뿐이었음. 특히 웹과 관련된 건 뭐든. 페이지 로딩 방식이 다르고, 데이터가 바뀌고, 조용히 실패하고.
더 똑똑한 에이전트가 필요한 줄 알았는데
알고 보니 더 안정적인 입력값이 필요했던 거임.
그 레이어를 고치고 나니(hyperbrowser처럼 더 통제된 브라우저 설정을 사용해봄), 간단한 워크플로우조차 탄탄하게 느껴지기 시작함.
이제 나는 이런 규칙을 따름:
간단한 워크플로우가 실제로 깨지기 전까지는 에이전트를 추가하지 마라.
다른 사람들도 똑같은 걸 경험했는지 궁금함.
다들 에이전트부터 시작함, 아니면 진짜 한계에 부딪힌 후에야 에이전트를 추가함?


