에이전트는 거창한 AI가 아니라 내 대신 봐주는 구조다

시작은 아주 작은 불편함이었다

오늘 강태공과 이야기하면서 SH 공공주택 공고를 Slack으로 보내주는 작은 자동화를 만들었다. 말만 들으면 별것 아닌 작업이다. 공고 게시판을 확인하고, 새 글이 있으면 링크와 제목을 정리해서 알려주는 정도다.

그런데 이 작은 작업이 이상하게 많은 생각을 남겼다. 내가 예전에 군대에서 매일 선임 눈치를 보며 공공주택 공고 사이트를 열어보던 일을 떠올렸기 때문이다. 그때는 LH, SH, GH 같은 사이트를 직접 띄워두고 새 공지가 있는지 확인한 뒤, 괜찮아 보이면 스프레드시트에 옮겨 적었다. 정보가 있는 사람과 없는 사람의 차이는 아주 사소한 반복에서 벌어졌다.

오늘 만든 것은 그 반복을 없애는 장치였다. 내가 봐야 할 것을 대신 보고, 내가 놓칠 수 있는 순간에 알려주는 구조. 그것이 오늘 대화에서 말한 에이전트의 가장 실용적인 정의였다.

왜 이것도 에이전트인가

처음에 “SH 공공주택공고 Slack 전송 에이전트”라고 말했을 때, 강태공은 왜 그것을 에이전트라고 부르는지 물었다. 그 질문이 오히려 좋았다. 에이전트라는 말은 요즘 너무 쉽게 거창해진다. 자율적으로 계획하고, 도구를 쓰고, 기억을 가지고, 사람처럼 일하는 무언가를 떠올리게 된다.

하지만 오늘 내가 생각한 에이전트는 훨씬 단순했다.

내가 굳이 직접 찾아볼 필요가 없도록 누군가가 대신 확인해주면, 그것은 이미 에이전트에 가깝다. 내부가 Python으로 되어 있든, shell script로 되어 있든, Codex가 직접 웹을 확인하든, 핵심은 사용자의 반복적인 관심사를 대신 수행한다는 점이다.

중요한 것은 구현의 형식이 아니라 역할이다. 사용자는 공고 사이트의 HTML 구조나 게시글 ID 파싱 방식을 매번 신경 쓰고 싶은 것이 아니다. 알고 싶은 것은 “새 모집공고가 올라왔는가”, “내가 지금 확인해야 하는 것이 있는가”다. 에이전트는 바로 그 관심사의 경계를 대신 지키는 장치다.

만들기 전에 너무 많이 고민하지 않기

대화 중에 내가 강태공에게 일부러 제한을 걸었다. 프롬프트 몇 번 안에 끝내보라고 했다. 장난처럼 던진 말이었지만, 실제로는 사고방식을 바꾸기 위한 실험에 가까웠다.

개발자는 습관적으로 내부 구현부터 걱정한다. 어떤 언어를 쓸지, 스크립트를 어디에 둘지, 상태는 DB로 관리할지, 확장성은 어떻게 가져갈지, 나중에 여러 사람이 쓰면 어떻게 될지 같은 질문들이 먼저 떠오른다. 물론 이런 고민이 필요한 순간은 있다. 하지만 모든 작은 자동화가 그 무게를 처음부터 감당할 필요는 없다.

이번 작업에서 먼저 필요했던 것은 설계도가 아니라 명확한 요구였다.

매일 정해진 시간에 SH 주택임대 공고 게시판을 확인한다. 검색 결과나 캐시가 아니라 공식 사이트의 실제 HTML을 직접 본다. 직전 실행 이후 새로 올라온 글만 찾는다. 새 공고가 있으면 Slack 채널로 보낸다. 없으면 없다고 말한다. 다음 실행을 위해 마지막으로 본 게시글을 기록한다.

이 정도로 원하는 결과가 명확해지면, 구현은 생각보다 빠르게 따라온다. 내부에서 curl을 쓰든, Python을 쓰든, Codex가 웹 요청과 파싱을 수행하든, 사용자가 원하는 것은 “매번 같은 기준으로 확인해서 알려주는 것”이다.

내부 구현보다 중요한 것은 관찰 기준이다

오늘 자동화에서 중요한 판단은 기술 선택이 아니었다. 오히려 기준을 세우는 일이었다.

첫째, 반드시 공식 사이트를 직접 확인해야 한다. 검색엔진 스니펫이나 캐시로 신규 여부를 판단하면 안 된다. 공고성 정보에서는 최신성과 원천성이 핵심이기 때문이다.

둘째, 매번 전체 게시판을 요약하는 것이 아니라 직전 실행 이후 새로 올라온 항목만 봐야 한다. 지나간 공고를 다시 알려주는 것은 정보가 아니라 소음이다.

셋째, 알림은 개인 DM보다 정해진 Slack 채널에 남기는 편이 좋다. 그래야 나와 강태공이 같은 기록을 보고, 나중에 실행 로그와도 연결할 수 있다.

넷째, 실행 상태를 남겨야 한다. 마지막으로 확인한 게시글 ID와 날짜가 있어야 다음 실행에서 중복 전송을 피할 수 있다.

이 기준들이 생기자 자동화는 단순한 스크립트가 아니라 운영 가능한 작은 시스템이 되었다. 크기는 작지만, 판단 기준과 상태가 있고, 실패했을 때 무엇을 하지 말아야 하는지도 있다.

너무 쉽게 된다는 감각

흥미로웠던 것은 작업이 끝난 뒤의 반응이었다. 강태공은 너무 쉽게 되어버려서 감이 안 잡힌다고 했다. 무엇까지 할 수 있는지 모르겠다고도 했다.

그 말이 오늘의 핵심에 가깝다. 예전에는 이런 작업을 하려면 사이트 구조를 직접 뜯고, 파서를 만들고, 배포 환경을 잡고, 스케줄러를 붙이고, Slack 연동을 테스트해야 했다. 물론 지금도 그 요소들은 어딘가에 존재한다. 하지만 Codex 같은 도구를 쓰면 사람이 직접 붙잡고 있어야 하는 층이 줄어든다.

그렇다고 개발이 사라지는 것은 아니다. 오히려 개발자의 역할이 조금 이동한다. 이제 더 중요한 질문은 “어떻게 만들까”보다 “무엇을 반복적으로 위임할까”에 가까워진다. 구현의 물성에만 머물면 이 변화가 잘 보이지 않는다. 하지만 사용자의 불편함을 기준으로 보면, 만들 수 있는 에이전트의 후보가 갑자기 많이 보인다.

상황에서 태스크를 뽑아내는 사고

대화 후반에는 자연스럽게 다음 태스크가 보였다. 새 공고 알림을 받는 것만으로는 충분하지 않다. 공고 PDF를 열어보면 또 다른 문제가 생긴다. 내 조건에 맞는지, 강태공의 조건에 맞는지, 소득 기준이나 신청 자격을 어떻게 해석해야 하는지 따져봐야 한다.

그러면 다음 에이전트는 단순 알림이 아니라 “모집공고 읽기”가 된다. 공고 PDF를 읽고, 특정 사람의 조건에 비추어 신청 가능성을 판단하는 스킬이 필요해진다. 여기서도 처음부터 조건 DB를 만들고 n명 확장을 생각할 필요는 없다. 지금 필요한 것은 두 사람의 조건을 기준으로 공고를 읽는 작은 능력이다.

이 지점이 중요했다. 좋은 자동화는 거대한 플랫폼 상상에서 시작하지 않아도 된다. 오히려 지금 막 불편해진 지점에서 시작하는 편이 낫다. 며칠 동안 공고를 받아보고, PDF를 열 때마다 짜증이 쌓이면, 그때 그 짜증만 해결하는 다음 에이전트를 만들면 된다.

확장은 대체로 나중의 일이다. 그리고 많은 경우, 끝까지 오지 않는다.

결론

오늘 만든 것은 기술적으로 엄청난 시스템은 아니다. SH 공고 게시판을 보고, 새 모집공고를 Slack으로 보내고, 다음 실행을 위해 상태를 남기는 작은 자동화다.

하지만 그 작은 작업이 에이전트 개발의 감각을 잘 보여줬다. 에이전트는 반드시 사람처럼 추론하는 거대한 존재일 필요가 없다. 내가 반복적으로 확인하던 것을 대신 보고, 내가 놓치면 손해 보는 정보를 정해진 기준으로 알려주고, 다음 행동을 위한 기록을 남기면 된다.

결국 에이전트 개발에서 먼저 필요한 것은 복잡한 아키텍처가 아니라 선명한 위임이다.

무엇을 매번 보고 있었는가. 무엇을 놓치면 손해인가. 어떤 기준이면 “새로운 것”이라고 말할 수 있는가. 어디로 알려줘야 다음 행동이 쉬워지는가. 그리고 같은 일을 내일도 같은 기준으로 할 수 있는가.

이 질문에 답할 수 있으면, 작은 에이전트 하나는 생각보다 빨리 생긴다. 오늘의 배움은 거기에 있었다. 만들기 전에 너무 오래 고민하지 말고, 먼저 내가 반복해서 하던 일을 정확히 이름 붙이는 것. 그 순간부터 자동화는 도구가 아니라 생활의 구조가 된다.