백엔드 개발자의 AI 비서 만들기 (2편) - 48개의 크론잡으로 살아나다

이전 편 요약

1편에서는 다음을 다루었습니다:

• 당근마켓에서 M2 Mac mini 충동구매
• 인터스텔라 TARS → 아이언맨 JARVIS 이름 변천사
• clawdbot → moltbot → OpenClaw 플랫폼 여정

첫 크론잡은 “자기개선”이었습니다

자비스를 처음 띄웠을 때 가장 답답했던 건 페르소나가 계속 증발한다는 거였어요. 세션이 만료되면 제가 공들여 심어준 말투, 응답 스타일, 맥락이 전부 날아갔습니다. 그래서 다시 대화하면 마치 심심이처럼 밋밋한 답변만 돌아왔죠.

“이거 매번 다시 학습시키는 건 말이 안 되는데.”

그래서 만든 게 첫 번째 크론잡이었습니다. 자비스가 스스로 과거 대화를 읽고, 응답 품질을 평가하고, 개선점을 찾아내는 자기개선 시스템이었어요. 하루에 한 번 돌면서 “어제 내가 너무 딱딱하게 답했네” 같은 걸 스스로 메모해두는 방식이었습니다.

처음엔 신기해했습니다. 크론잡 하나로 페르소나가 유지됐거든요. 그런데 문제는 여기서 시작됐습니다.

크론잡이 불어나는 과정

“아침에 주식 시세 알려주면 좋겠는데?”

06:00에 TQQQ 모니터링 크론이 생겼습니다. 전날 대비 변동폭, 장 시작 전 선물 가격, 환율까지 챙겨주는 브리핑이었어요. 편했습니다.

“출근할 때 날씨랑 교통 상황도 알려주면…”

06:15에 모닝 브리핑 크론이 추가됐습니다. 날씨, 오늘 일정, 출근 경로 교통 체증까지요.

“Google Tasks에 마감 임박한 거 있으면 알려줘.”

06:25에 데일리 넛지 크론이 생겼습니다.

이렇게 하나둘 늘어나더니, 어느새 48개가 됐습니다.

실제로 돌고 있는 크론잡 몇 개만 나열해보면:

• 06:00 일일 주식 브리핑 (TQQQ 모니터링)
• 06:15 모닝 브리핑 (날씨, 일정, 출근 경로)
• 22:00 부부 약 먹기 알림
• 03:15 Nightly Build (자율 개선, 제가 자는 동안 friction point 해결)

이런 식으로 조식 알림, 기술 트렌드 리포트, 퇴근 브리핑, 크론 감시 리포트, 취침 알림 등이 추가되어 총 48개까지 늘었습니다.

처음엔 “이 정도면 괜찮지” 했는데, 문제는 관리였어요. 크론잡이 3개일 땐 귀여웠는데, 10개 넘어가니까 인프라가 됐습니다.

Discord 7개 채널로 나눈 이유

텔레그램에서 시작했다가 디스코드로 갈아탄 건 채널 구조 때문이었습니다. 텔레그램은 단일 채팅방이라 주식 알림, 시스템 로그, 가족 약 알림이 전부 한 화면에 쏟아졌어요. 알림 피로가 장난 아니었습니다.

디스코드는 달랐습니다. 채널을 나눌 수 있었거든요.

실제로 운영 중인 채널 구조입니다. jarvis(메인 대화), jarvis-market(주식/시장), jarvis-system(시스템 알림), jarvis-dev(개발/디버깅), jarvis-family(가족 알림) 등으로 나눠져 있습니다.

관심사별로 분리하니까 알림 피로가 확 줄었습니다. 주식에 관심 없을 땐 jarvis-market을 뮤트하면 그만이었거든요.

그리고 디스코드의 또 다른 장점은 음성이었습니다. OpenAI TTS API를 붙여서 음성 명령에 음성으로 답하게 만들었어요. 와이프가 요리하면서 “자비스, 파스타 레시피 알려줘” 하면 음성으로 답해주는 식이었습니다.

와이프의 반응

처음엔 신기해했습니다. “어, 진짜 대답하네?” 수준이었는데, family 채널에서 요리 관련 질문을 몇 번 하더니 이제는 능숙하게 쓰고 있어요.

“자비스, 브로콜리 데치는 시간 몇 분?” “자비스, 오늘 약 먹었어?”

특히 약 먹기 알림이 생기고 나서는 의존도가 확 올라갔습니다. 22:00에 알림이 안 가면 “자비스 고장났어?”라고 물어봐요. 이쯤 되니까 SLA가 생긴 거나 마찬가지였습니다.

회사 반응

팀장님이 제일 먼저 눈치챘습니다. “정우님 요즘 일정 관리 잘하시던데, 뭐 쓰세요?”

OpenClaw 얘기를 꺼냈더니 꽤 많이 물어봤어요. 어떻게 설치하는지, 디스코드는 어떻게 연동하는지, 크론잡은 어떻게 만드는지.

나중에 들어보니 팀장님도 맥미니 사서 비슷한 걸 돌리고 있다고 했습니다. 디스코드 다채널 구조도 따라 했다더라고요. 영감을 준 셈이었습니다.

회사에서 또 한 명, 다른 팀 개발자도 비슷한 셋업을 했다는 얘기를 들었습니다. 이쯤 되니 조금 뿌듯했어요.

이쯤 되면 서버 운영입니다

48개 크론잡을 관리하다 보니 어느새 인프라 운영을 하고 있었습니다.

• 크론 상태 모니터링 (22:30 크론 감시 리포트)
• 로그 관리 (메모리 사용량, 실패 로그)
• 장애 대응 (크론이 3번 연속 실패하면 알림)

백엔드 개발자로 일하면서 익힌 감각이 그대로 발동했어요. 프로덕션 서비스와 다를 바가 없었습니다.

특히 Nightly Build (03:15 크론)는 제가 가장 아끼는 크론이에요. 제가 자는 동안 자비스가 스스로 friction point를 찾아내고, 개선 방안을 메모해두는 시스템입니다. 아침에 일어나면 “어제 퇴근 브리핑이 3초 늦게 갔습니다. 교통 API 타임아웃 때문인 것 같습니다”라는 리포트가 와 있어요.

이게 진짜 AI 비서구나 싶었습니다.

교훈 세 가지

첫째, 크론잡은 2-3개일 때 귀엽고, 10개 넘으면 인프라가 됩니다. 관리 도구 없이는 감당이 안 돼요. 저는 크론 감시 리포트 크론을 만들어서 해결했지만, 처음부터 모니터링을 염두에 뒀어야 했습니다.

둘째, 에이전트도 사람처럼 “자기 관리”가 필요합니다. 페르소나가 증발하는 문제, 메모리가 쌓여서 느려지는 문제, 크론 간 충돌… 이런 건 AI가 알아서 안 해결해요. 제가 직접 시스템을 설계해줘야 했습니다.

셋째, 가족이 쓰기 시작하면 SLA가 생깁니다. 약 먹기 알림이 안 가면 와이프가 물어봐요. “고장났어?” 그 순간부터 이건 제 장난감이 아니라 우리 집 인프라가 된 거였습니다.

그리고 모든 게 죽었습니다

48개 크론잡이 행복하게 돌아가던 어느 날, 시스템이 멈췄습니다.

응답 시간이 3초에서 15초로 늘어났고, 크론잡이 타임아웃으로 실패하기 시작했어요. 결국 어느 날 아침, 주식 브리핑이 안 왔습니다.

무슨 일이 벌어진 걸까요?

그 이야기는 Part 3에서 이어집니다.

다음 편 예고

48개 크론잡이 행복하게 돌아가던 어느 날, 전부 멈췄습니다. 원인은 MEMORY.md라는 파일 하나였습니다.

3편에서 계속

읽어주셔서 감사합니다.🖐