현재 실제로 사용 중인 유용한 AI 에이전트 20가지 (이론 말고, 작동하는 것들만)

좋은 목록이네요. 저도 받은 편지함 분류(inbox triage) 에이전트는 계속 쓰고 있어요. 가장 빨리 망가진 건 브라우저 자동화에 의존하는 것들이었죠. browser-use는 잘 작동할 땐 좋지만, 대상 사이트의 UI가 조금만 바뀌어도 전체 흐름이 조용히 깨져버려서, 결국 제가 에이전트가 절약해준 시간보다 더 많은 시간을 뒷수습하는 데 썼습니다. 밤새 배치로 돌리는 작업(인리치먼트, 아침 검토용 초안 작성)이 훨씬 안정적이었는데, 그건 사람이 출력물을 확인하고 내보내기 때문이죠. 사람이 지켜보지 않고 작동하는 에이전트들은 제가 계속...

브라우저 자동화가 조용히 깨지는 게 최악이죠. 적어도 API는 에러라도 던지지, UI 변경은 에이전트에게 쓰레기 데이터를 먹이고 며칠 동안 아무도 눈치채지 못하게 만드니까요.

콜드 이메일 개인화 에이전트도 사람이 지켜보지 않는 상태로 돌리진 않습니다. 당신이 말한 것과 같은 이유죠. 초안을 작성해서 검토 대기열에 넣을 뿐, 바로 보내지는 않습니다. 그리고 실패 모드가 충돌이 아니라, 모델이 기술적으로는 말이 되지만 8개월 전 '최근 게시물'을 참조하는 식으로 엉뚱한 내용을 쓰는 거거든요. 에러가 나는 게 아니라 그냥 살짝 이상하게 읽히는...

저는 소매 머천다이징 분야에 있는데, 에이전트들을 역할별로 배치했습니다. 제가 맡은 머천다이징 카테고리의 모든 재무를 담당하는 플래너 에이전트, 재고를 관리하는 보충 관리자 에이전트, 머천트 에이전트, 매장 운영 에이전트, 그리고 이메일 에이전트가 있죠. 이렇게 업무 영역을 정의하는 게 정말 큰 도움이 됩니다. 단순히 자동화된 작업뿐만 아니라 통찰력이 필요한 하이브리드 작업과 결정론적 워크플로우를 구축할 수 있게 해주거든요. 또한 에이전트 간 협업도 가능하게 합니다. 예를 들어...

탄탄하네요. 이건 에이전트당 하나의 작업만 하는 것과는 다르게 조직 구조를 그대로 반영하는 방식이라 이 스레드의 다른 의견들과는 결이 다르네요. 마크다운 예시가 왜 이 방식이 효과적인지 잘 보여주네요. 이메일 에이전트가 요청을 분류하고, 플래너와 보충 관리자를 불러와 재고를 확인하고, 재무 에이전트가 판매 지표를 얹으면, 검토하기 전까지는 손댈 필요 없이 시나리오 분석이 완료되는 거니까요.

에이전트 간 의견 충돌은 어떻게 처리하는지 궁금합니다. 예를 들어 보충 관리자는 재고가 부족하다고 하는데 머천트가...

저한테 효과적이었던 것들은 모두 좁은 범위와 엄격한 타임아웃을 가지고 있었어요. 범위가 넓은 에이전트들은 금방 뒷수습 프로젝트로 변해버리더군요.

좋은 리스트네. 1주 넘게 살아남는 것들에서 공통적으로 보이는 패턴이 있는데, 그냥 프롬프트만 덜렁 있는 LLM이 아니라 실제 기록 시스템(system of record)에 제대로 연결되어 있다는 거야. 금방 죽어버리는 에이전트들은 근거(grounding)도 없고 권한도 없는 것들이더라고.

우리 팀에서 계속 잘 쓰고 있는 것들:

• 슬랙 스레드 읽고, 관련 CRM 기록 가져와서 후속 조치 초안 작성하기. 복사-붙여넣기 노가다를 줄여줌.

• 회의 요약하고 실행 항목(action items)에서 Jira 티켓 생성하기, 사람이 승인해야 반영됨.

• 리포지토리 인식형 코드 리뷰인데…

슬랙 스레드를 CRM 기록으로 옮기는 것도 좋은 예시지. 이건 사람들이 자동화해서 없애기 전까지는 예산에 넣지도 않는 '복사 붙여넣기 세금' 같은 거잖아. 정작 결정하는 일은 하나도 없으면서 툴 사이에서 맥락 옮기는 데 얼마나 많은 시간을 쏟고 있었는지 깨닫게 되지.

콜드 이메일 개인화 에이전트가 여기서 진짜 물건이네. 잠재 고객별로 실시간 웹 컨텍스트를 가져오는 게 핵심임. 난 직접 구현하는 대신 Parallel 써서 검색 레이어 돌렸음.