실제로 작동하는 루프 오케스트레이터 예시
Example of a real working loop orchestrator
핵심 요약
20년 차 개발자가 자신의 업무를 자동화하고 관리하는 루프 오케스트레이터 'Lloyd'의 작동 방식과 구조를 공유했습니다.
- 오케스트레이터 구조 — SQLite를 활용해 자체 티켓 관리 및 과거 데이터 참조를 수행함
- 하트비트 메커니즘 — 주기적인 신호를 통해 에이전트가 이메일 확인 및 로그 분석을 수행하게 함
- 자동화 워크플로우 — 고객 버그 리포트 확인, 문서 업데이트, 로그 모니터링을 자동으로 처리함
- 운영 방식 — 로컬 환경에서 실행되며 사용자가 직접 제어권을 갖는 구조로 설계됨
다들 안녕,
20년 넘게 굴러먹은 시니어 엔지니어이자 디자이너로서 내가 쓰는 루프 오케스트레이터가 어떻게 생겼는지 살짝 보여주려고 해. 다들 실제 돌아가는 예시를 보면 도움 될 것 같아서.
내 오케스트레이터인 '로이드(Lloyd)'의 주 목적은 자체 내부 티켓 테이블을 관리하는 거야. 예시에서는 그냥 간단한 SQLite 테이블을 썼어. 오케스트레이터는 뭐든 할 수 있으니까, 자체 메모리를 관리할 데이터베이스를 쥐여주면 효율이 기하급수적으로 올라가거든. 로이드는 지금까지 내가 클릭해서 확인할 수 있는 자체 지라(Jira)처럼 600개가 넘는 티켓을 관리해 왔어. 덕분에 새로운 티켓이 들어올 때마다 관련 있는 이전 티켓들을 싹 다 찾아볼 수 있지. 우리도 새로운 업무 맡으면 당연히 그래야 하는 것처럼 말이야.
이게 에이전트한테 어떤 모델에든 넘겨줄 수 있는 '조직의 노하우' 데이터베이스를 만들어주는 셈이지.
여기서 내가 강조하고 싶은 핵심 개념은 '하트비트(heart beat)'랑 '펄스 액션 아이템(pulse action items)'이야.
어디서 가치가 나오는지 딱 보면 알 거야:
- 일단 플레이북(자동화 스크립트)을 돌려서 고객이 보낸 새로운 버그 리포트가 있는지 이메일을 확인해. 티켓을 배정하기 전에 이전 맥락부터 체크하는 거지.
- 웹사이트에 업데이트할 문서가 있는지 확인해.
- 앱 실행 로그를 직접 까서 무슨 일이 벌어지고 있는지 확인해.
-- 이게 진짜 중요한 습관이야. 아무도 신고 안 해서 몰랐던 버그, 에러는 안 떴지만 뭔가 찜찜한 문제 같은 걸 다 잡아내거든.
- 그 과정에서 버그나 개선 사항에 대한 티켓을 스스로 생성하기도 해. 에이전트가 나한테 직접 아이디어나 문제를 던져서 내가 우선순위를 정하게 만드는 거지.
너희 루프는 어떻게 생겼어?
