지식 뇌와 연결한 첫 번째 비서 알림 기능

AI 에이전트 생태계 구축기· 3 / 10
- 1 — 멋진 비서를 만들기 위한 뜬구름 시도 끝에, LLM Wiki부터 세웠다
- 2 — LLM Wiki를 지식 뇌로 쓰게 해주는 두 가지 자동화
- 3 — 지식 뇌와 연결한 첫 번째 비서 알림 기능
- 4 — 지식 뇌에 손발을 붙였다: LLM Wiki와 헤르메스 연결하기
- 5 — AI 대화 기록으로 블로그 작성하기
- 6 — AI 자동화와 사람의 판단을 잇는 우편함 만들기
- 7 — 텔레그램에서 슬랙으로 헤르메스 사무실 옮기기
- 8 — AI가 쓴 블로그에 필요한 이미지를 더한 방법
- 9 — 헤르메스로 자동화를 운영하며 접한 사소한 문제들
- 10 — AI 코딩 에이전트의 테스트 PASS를 그대로 믿을 수 있을까
second는 내가 대화하고 작업하며 남긴 정보를 위키로 정리해, 다음 작업에서 다시 꺼내 쓰기 위해 만든 지식 뇌다. 만들고 나니 다음 질문이 생겼다. 이 지식 뇌를 단순히 기록을 모아 두는 곳으로 두지 않고, 내가 실제로 필요한 기능에 어떻게 연결할까.
그때 내게 가장 필요했던 기능은 정부지원 공고를 놓치지 않게 알려 주는 것이었다. 공고는 여러 포털에 흩어져 있고, 내게 해당하는 지원을 따로 추천해 주는 곳은 없었다. 이미 아는 공고를 검색하는 일보다, 내가 모르고 지나칠 공고를 먼저 찾아 주는 쪽이 필요했다.
그래서 gov-radar를 만들었다. 새 공고를 모으고, 내 조건과 명백히 맞지 않는 공고를 먼저 빼고, 남은 공고를 읽기 쉽게 알려 주는 도구다. 이 글은 그 기능을 만들면서, 왜 하나의 AI 비서에게 전부 맡기지 않고 코드·헤르메스·second로 나눴는지에 대한 기록이다.
필요한 것은 검색이 아니라 알림이었다
정부지원 제도는 필요할 때 검색하면 어느 정도 찾을 수 있다. 문제는 내가 지금 모르는 제도는 검색할 이유도 없어서, 공고가 올라왔는지조차 알기 어렵다는 데 있었다.
내가 원한 흐름은 단순했다.
| 순서 | 실제로 필요한 일 |
|---|---|
| ① | 여러 포털에서 새 정부지원 공고를 모은다. |
| ② | 내 조건에 명백히 맞지 않는 공고는 먼저 제외한다. |
| ③ | 남은 공고는 왜 볼 만한지와 함께 알려 준다. |
| ④ | 공고를 보며 알게 된 제도와 판단 기준은 다음에도 쓸 수 있게 남긴다. |
즉, gov-radar는 공고 검색기가 아니라 내가 놓칠 수 있는 정보를 먼저 챙겨 주는 기능이어야 했다. 이 기능을 지식 뇌에 처음 연결해 보고 싶었다.
하나의 AI에게 전부 맡기기에는 일이 달랐다
처음에는 AI 비서 하나가 공고를 모으고, 적격 여부를 판단하고, 요약해서 알리고, 기억까지 하면 될 것 같았다. 하지만 각 일을 자세히 보면 필요한 능력이 달랐다.
- 마감일·지역·연령 확인은 계산이다. 같은 공고를 다시 확인해도 같은 결과가 나와야 한다.
- 공고문 읽기와 설명은 판단이다. 조건이 애매하거나 예외가 있으면 문장을 읽고, 확신이 없다고 말할 수 있어야 한다.
- 판단의 이유와 제도 정보 축적은 기억이다. 다음 공고나 다른 작업에서도 다시 찾아 쓸 수 있어야 한다.
이 셋을 하나의 AI에게 모두 맡기면, 결과가 이상할 때 어디가 문제인지 알기 어려워진다. 계산이 틀린 것인지, 공고문을 잘못 읽은 것인지, 이전 정보를 잊은 것인지가 섞이기 때문이다.
그래서 각 일을 잘하는 곳에 나눠 맡기기로 했다.
확실히 걸러 낼 수 있는 것은 코드가 맡았다
공고의 마감일, 지역, 연령, 취업 상태처럼 값으로 비교할 수 있는 조건은 gov-radar의 코드가 처리한다. 이런 조건은 AI가 문맥을 읽으며 추측할 일이 아니라, 정해 둔 기준을 매번 똑같이 적용해야 하는 일이기 때문이다.
다만 코드가 “이 공고는 적격이다”라고 확정하지는 않는다. 코드의 역할은 명백히 맞지 않는 공고를 먼저 빼는 것까지다. 예를 들어 지역 제한이 분명하고 내 지역이 그 목록에 없다면 제외한다. 반대로 공고에 정보가 빠져 있거나 조건이 애매하면, 코드가 섣불리 제외하지 않고 다음 단계로 넘긴다.
코드가 통과시킨 공고는 적격으로 확정된 공고가 아니다. 코드만으로는 제외할 이유를 찾지 못한 공고다.
이렇게 해야 애매한 공고를 놓치지 않는다. 동시에 지역이나 마감일처럼 분명한 조건을 매번 AI에게 다시 묻지 않아도 된다.
공고를 읽고 알려 주는 일은 헤르메스가 맡았다
코드를 통과한 공고도 바로 내게 보내지는 않는다. 공고문에는 표에 없는 예외가 있고, 실제로 신청을 생각하면 무엇을 더 확인해야 하는지도 남는다.
이 부분은 헤르메스가 맡는다. 헤르메스는 내가 요청을 주고받는 운영 비서다. 남은 공고를 읽어 왜 볼 만한지 요약하고, 내가 더 알아보고 싶다고 하면 필요한 내용을 이어서 확인한다. 확신할 수 없는 공고는 적격인 것처럼 말하지 않고 [확인 필요] 라고 표시한다.
헤르메스가 맡는 것은 공고를 이해하고 설명하는 일이다. 반복 실행할수록 알아서 판단 기준을 배우는 것은 아니므로, 알림 형식과 확인 필요 원칙은 작업 지침으로 따로 남겨 두었다.
판단의 이유는 second에 남겼다
공고를 이미 보냈는지 기록하는 것과, 왜 이런 기준으로 걸렀는지 남기는 것은 다른 일이다. 이미 확인한 공고 목록은 다음 실행에서 중복 알림을 막기 위한 현재 상태다. 반면 특정 제도를 어떻게 이해했는지, 어떤 공고가 애매했는지, 왜 이런 방식으로 나눴는지는 다음에도 다시 참고할 지식이다.
그래서 그 지식은 second에 모았다. second는 이 글에서 말하는 지식 뇌로, 대화와 작업에서 남은 맥락을 위키로 정리해 다음 작업에 다시 건네는 공간이다.
| 맡는 곳 | 하는 일 | 남기는 것 |
|---|---|---|
gov-radar | 공고를 모으고, 명백한 조건과 중복을 확인한다. | 이미 확인한 공고와 신청 추적 정보 |
| 헤르메스 | 공고문을 읽고 요약하며, 후속 질문을 받는다. | 알림 형식과 확인 절차를 위한 작업 지침 |
| second | 다음에도 필요한 맥락을 정리한다. | 제도 정보, 판단의 이유, 작업에서 쌓인 지식 |
이렇게 나누면 gov-radar는 오늘의 공고를 처리하고, 헤르메스는 공고를 이해해 전달하며, second는 그 과정에서 쌓인 지식을 다음 작업으로 가져간다.
이번에는 실제로 필요한 일을 먼저 찾았다
gov-radar 자체는 거대한 비서 기능이 아니다. 공고를 모아 보고, 명백히 맞지 않는 것을 빼고, 남은 공고를 알려 주는 작은 기능이다. 그래도 이 글에 남긴 이유는, 이 기능이 앞선 두 번의 비서 에이전트 시도와는 다른 출발점이었기 때문이다.
앞선 두 번에는 만들고 싶은 비서의 모습은 있었지만, 막상 만들어 놓고 나서 그 비서에게 무엇을 시킬지는 정하지 못했다. 이번에는 반대였다. 먼저 second라는 기반을 만들고, 그 위에 내가 지금 정말 필요했던 정부지원 공고 알림을 하나 올렸다.
second의 원칙은 “뇌는 하나” 다. 이 말은 모든 일을 한 비서가 처리해야 한다는 뜻이 아니라, 오래 남겨야 할 지식을 한곳에 모으자는 뜻이다. 그 지식을 쓰는 기능까지 하나의 도구가 전부 맡아야 한다는 뜻은 아니다.
그래서 이 알림은 코드는 확실한 조건을 처리하고, 헤르메스는 공고를 읽어 알려 주고, second는 그 과정에서 생긴 지식을 남기는 구조가 됐다. 앞으로 생길 내 필요와 행동을 받쳐 줄 기반을 먼저 만들고, 그 위에 실제로 필요한 일을 처음 연결했다는 점이 이 작은 기능의 의미였다.