Tell me about your useful loops you actually use
AI 에이전트 루프를 설계하는 사용자들을 위해, 실제로 현업에서 유용하게 쓰이는 작고 단순한 자동화 루프 사례들을 공유합니다.
AI 에이전트 루프를 직접 설계해야 한다는 이야기를 듣고 있습니다. 그게 미래라고 하더군요. 하지만 실제로 그게 무엇인가요? 여러분이 실제로 사용하는 유용한 루프에 대해 알려주세요. 아니면 다른 사람을 위해 만든 루프 중 그들이 잘 사용하고 있는 것이 있나요?
대부분의 사용자는 거창한 자동화보다는 좁은 범위의 작업에 집중하고 인간의 승인 단계를 포함하는 단순하고 지루한 루프가 가장 실용적이라고 입을 모으고 있습니다.
저만의 작업 방식을 만들었고 오픈 소스로 공개했습니다. 소프트웨어 개발을 위한 애자일 스타일의 루프입니다.
[킥오프 단계 — 프로젝트당 1회, 다중 기능 규모 전용] PO → INIT_ANALYST_KICKOFF → 분석가 킥오프 1단계 발견 → 2단계 조정(피치 확정) 3단계: 아키텍트 필요 여부? 예 → init_architect_kickoff → 아키텍트 → init_analyst_kickoff_resume → 분석가 킥오프 재개 아니오 → 계속 4단계 초안 및 검증 — PROJECT_GUIDE 초안 인라인 작성; PO 검증...
실제로 제 몫을 톡톡히 하는 세 가지 루프가 있는데, 전부 의도적으로 지루하게 만들었습니다.
PR 분류: 푸시가 발생할 때마다 저렴한 모델이 diff와 실패한 테스트 결과를 읽고 한 문단으로 요약합니다. 무엇이 바뀌었고, 무엇이 고장 났을 가능성이 높으며, 어떤 파일을 먼저 봐야 하는지 알려주죠. 아무것도 자동으로 고치진 않지만, 30초 더 빨리 올바른 라인을 찾게 해줍니다. 꽤 정확해서 이제는 diff를 보기 전에 이걸 먼저 읽습니다.
받은 편지함에서 초안 작성: 감시 중인 라벨에 새 메일이 오면 답장을 작성해 초안으로 저장만 해둡니다. 절대 보내지는 않고요. 60% 정도는 제가 직접 보냅니다.
ㅇㅇ 아침 9시 세금 관련 루프는 진짜임. 그것만으로도 이 설정값은 충분히 가치 있다고 봄.
유용한 루프는 보통 지루합니다: 같은 입력을 수집하고, 작은 결정을 하나 내리고, 사람이 승인하거나 수정하게 한 다음, 그 수정 사항을 다음 실행에 반영하는 식이죠. 루프가 검토를 통해 개선될 수 없다면, 그건 그냥 단계가 추가된 자동화일 뿐입니다.
유용한 주의사항 하나: 루프가 명시적으로 스스로 학습하지 않더라도 컨텍스트 품질을 개선한다면, 그 품질 개선은 복합적인 차원이 됨. 그러니까 기업 지식 베이스에서 구식 정보를 찾아내는 것 같은 작업도 여기에 해당한다고 봄.
저는 관리자라 사람들을 많이 만나는데, 이 루프가 도움이 됩니다. 캘린더 테트리스 하느라 시간을 낭비하지 않게 해주죠.
매일 아침 제 캘린더를 읽고 몇 가지 일을 합니다: * 3일 이내의 소규모 회의 중 회의실이 예약되지 않은 경우 회의실을 예약합니다. 어떤 회의실을 예약할지에 대한 상세한 선호도가 설정되어 있습니다. * 제가 거절하지 않은 회의들 사이에 충돌이 발생하면, 참가자들의 캘린더를 기반으로 일정 변경 솔루션을 제안합니다(실행은 안 함). * 다가오는 회의에 대해 경고를 줍니다...
솔직히 저한테 효과가 있는 루프는 지루하고 좁은 범위의 것들입니다. '모든 것을 다 하려는' 시도를 하는 루프는 3~4번 반복되면 방향을 잃고 엉뚱한 일을 만들기 시작하거든요.
제가 매일 돌리는 루프는 이렇습니다: 한 소스에서 새 항목을 가져오고, 조건에 맞는 몇 개만 필터링한 뒤, 각각에 대한 답장을 초안으로 작성하고, 멈춰서 제가 승인하기를 기다립니다. 이 '멈춤'이 가장 중요합니다. 확실한 종료 지점이나 인간의 게이트가 없는 루프는 결국 통제 불능이 됩니다.
다른 유용한 루프는 단순한 감시자입니다. 체크를...
제가 의존하는 루프는 에러 로그를 긁어와서 비슷한 스택 트레이스를 그룹화하고, 진짜 문제라면 제가 보낼 수 있도록 Slack 메시지 초안을 남겨둡니다.
제가 가장 좋아하는 것 중 하나는 '캡처-분류-실행' 루프입니다. 머릿속에 뭔가 떠오를 때마다 모든 걸 기억하려고 애쓰지 않죠.
조금 더 자세히 공유해주실 수 있나요?
제 생각에 유용한 루프가 복잡한 작업을 스스로 끝내는 거창한 것일 필요는 없습니다.
제가 사용하는 작은 루프는 몇몇 소스에서 새로운 콘텐츠를 가져와 중복을 제거하고, 회사나 주제별로 그룹화한 뒤, 각 항목이 왜 중요한지에 대한 짧은 메모를 제공합니다.
저에게는 정보 수집과 정리를 더 빠르게 도와준다는 점이 핵심 가치입니다. 딱 이 정도죠.
이건 루프라기보다는 선택적 재귀가 있는 그래프에 가깝습니다. 정말 철저하게 추론이 필요할 때만 사용하죠. 처음에는 1~4번 작업을 수행하는 단일 에이전트를 제어하는 스킬이나, 네 가지 스킬을 연결하는 인지적 오케스트레이션 스킬로 구현했습니다. 지금은 템플릿화된 프롬프트와 조율을 위한 도구(각각 전체 과정의 요약과 특정 역할에 대한 상세 운영 지침이 제공됨)를 갖춘 상태 머신 하네스를 사용하고 있습니다.
여기 허술한 요약이...
제 경험상 유용한 루프는 'N분마다 LLM에게 다시 물어보는 것'이 아닙니다. 오히려 이런 식이죠:
패턴 예시: 캘린더/받은 편지함/작업 소스를 스캔하고, 실제 행동이 필요한 항목만 클러스터링한 뒤, 구체적인 작업을 생성하거나 조용히 있는 것입니다. '조용히 있는 것'이 매우 중요합니다. 그렇지 않으면 모든 루프가 또 다른...
단순한 피드백 루프가 가장 효과적이었습니다. 결과를 기록하고, 매주 검토하고, 한 번에 하나의 변수만 조정하는 방식이죠.
그래, 그 프레임이 더 깔끔하네. 루프 자체가 학습하지 않더라도 컨텍스트 품질은 계속 쌓일 수 있으니까.
AI 에이전트의 데이터베이스 쓰기 사고를 방지하기 위해 브랜치 기반의 변경 사항 검토 및 병합 시스템을 도입하는 방안을 논의합니다.
AI 에이전트의 데이터베이스 쓰기 사고를 방지하기 위해 브랜치 기반의 변경 사항 검토 및 병합 시스템을 도입하는 방안을 논의합니다.
작성자가 저혈당 쇼크로 의식을 잃어갈 때 ChatGPT가 음성으로 계속 말을 걸어 깨워준 경험담입니다.
작성자가 저혈당 쇼크로 의식을 잃어갈 때 ChatGPT가 음성으로 계속 말을 걸어 깨워준 경험담입니다.
사용자가 자신의 타이핑 속도를 측정해 LLM의 토큰 생성 속도(t/s)와 비교하는 웹 도구를 만들어 공유했습니다.
사용자가 자신의 타이핑 속도를 측정해 LLM의 토큰 생성 속도(t/s)와 비교하는 웹 도구를 만들어 공유했습니다.