아침마다 훑던 뉴스 스무 개, 브리핑 메일로 도착합니다

"아침에 출근하면 40분은 뉴스 봅니다. 그런데 정작 중요한 건 놓칠 때가 있어요."

사업개발팀 차장님이 사전 조사에서 하신 말씀입니다. 담당 품목의 원자재 시세, 거래 상대국 정책 변화, 경쟁사 동향. 매일 봐야 하는데 사람이 보면 빠뜨립니다.

사전 조사에서 확인한 것

팀원 다섯 분의 아침 루틴을 따라가 봤습니다.

① 보는 곳이 사람마다 달랐다 — 같은 품목을 담당해도 A는 국내 뉴스를, B는 해외 매체를 봤습니다. 겹치는 것도 있고 아무도 안 보는 영역도 있었습니다.

② 봤다는 기록이 없었다 — 중요한 기사를 봐도 개인 메신저나 메모에 남습니다. 한 달 뒤에 "그때 그 기사"를 찾으면 아무도 못 찾습니다.

③ 공유가 선택적이었다 — 본인이 중요하다고 판단한 것만 팀에 공유했습니다. 판단 기준이 사람마다 달라 누락이 생겼습니다.

담당자분들이 원한 건 뉴스 요약 서비스가 아니라 "우리 품목에 맞춰진 것" 이었습니다. 시중 서비스는 범위가 너무 넓거나 좁았습니다.

왜 직접 만들었나

시중 모니터링 서비스를 검토하다가 접었습니다. 이유가 둘이었습니다.

첫째, 키워드 조합이 우리 것이어야 했습니다. 담당 품목의 업계 용어와 거래처 이름을 조합한 검색은 범용 서비스가 못 합니다.

둘째, 결과를 어디로 보낼지가 중요했습니다. 별도 앱에 들어가서 보는 방식이면 안 봅니다. 아침에 메일함을 여니까 메일로 와야 봅니다.

이 두 가지를 맞추려면 만드는 편이 빨랐습니다. 그리고 만드는 데 개발자가 필요 없다는 것이 이 교육의 전제였습니다.

진행 — 이틀에 걸쳐 하나를 끝까지

사전 준비 — 키워드부터 맞췄다

교육 2주 전에 팀별로 모니터링할 키워드 목록을 받았습니다. 이걸 안 받고 들어가면 첫날 오전을 키워드 정하는 데 씁니다.

받아 보니 예상대로 사람마다 달랐습니다. 같은 품목인데 어떤 분은 영문 업계 용어를, 어떤 분은 국문 일반 명칭을 쓰고 계셨습니다. 이 차이를 사전에 정리해 팀 공통 키워드 12개 + 개인 추가분으로 구조를 잡아 갔습니다.

1일차 오전 — 도구를 만들어 AI에 준다

에이전트가 챗봇과 다른 지점을 먼저 다뤘습니다. AI는 학습한 것만 압니다. 오늘 뉴스를 가져오려면 "가져오는 기능"을 만들어 붙여야 합니다.

오픈 API 키를 발급받고 키워드로 뉴스를 수집하는 도구를 만들었습니다. 여기까지 오전에 끝났습니다.

1일차 오후 — 본문까지 가져오기

검색 결과는 제목과 요약만 줍니다. 그것만으로는 판단이 안 됩니다.

기사 URL을 열어 본문을 가져오는 기능을 추가했습니다. 여기서 처음 막혔습니다 — 매체마다 페이지 구조가 달라 어떤 곳은 본문을 못 가져왔습니다.

이 지점이 교육적으로 중요했습니다. 참가자분들이 "실패하면 어떻게 하죠"라고 물으셨는데, 답은 "실패한 걸 실패했다고 남기고 계속 진행" 이었습니다. 전체가 멈추는 것보다 낫습니다. 못 가져온 기사는 "본문 수집 실패"로 표기하고 제목·링크만 남기게 했습니다.

2일차 오전 — 판단 기준을 프롬프트로

수집한 것을 전부 보내면 아침에 스무 개를 훑던 것과 같습니다. 걸러야 의미가 있습니다.

여기서 팀 논의가 붙었습니다. 무엇을 중요하다고 볼 것인가. 결국 세 가지로 정리됐습니다 — 담당 품목 시세에 영향을 주는 것, 거래 상대국 정책·규제 변화, 주요 거래처·경쟁사 언급.

[시세 영향]
· 인니 수출 쿼터 축소 검토 (로이터)
  → 담당 품목 원료 수급에 직접 영향, 기준 1

[정책·규제]
· EU 탄소국경세 적용 품목 확대안 공개
  → 거래 상대국 규제, 기준 2

[거래처·경쟁사]
· A사 현지 법인 설립 발표
  → 주요 경쟁사 동향, 기준 3
⋯
── 제외 38건 (제목만) ──

중요도 판단을 프롬프트에 명시하고, 왜 그렇게 판단했는지도 함께 쓰게 했습니다. 이유가 있어야 기준을 고칠 수 있습니다.

2일차 오후 — 발송과 정기 실행

브리핑 메일 형식을 정하고 매일 아침 자동으로 도는 구조를 만들었습니다.

형식을 정할 때 한 가지를 짚었습니다. 읽는 사람이 스크롤을 내리지 않아도 판단할 수 있어야 합니다. 그래서 기사 제목 아래에 "왜 중요한지" 한 줄을 붙이고, 본문 요약은 그 아래에 뒀습니다. 제목만 훑고 필요한 것만 펼쳐 보는 방식입니다.

수집 결과가 0건인 날을 어떻게 할지도 정했습니다. 빈 메일을 보내면 안 봅니다. "오늘 해당 없음"을 한 줄로 보내되, 수집 자체가 실패한 경우와 구분되게 표시했습니다.

진행 중에 나온 질문

"이거 개발자 없이 정말 되나요." 첫날 오전 내내 반신반의하는 분위기였습니다.

오후에 첫 수집 결과가 화면에 뜨자 분위기가 바뀌었습니다. 코드를 한 줄도 직접 쓰지 않고 요청문만으로 여기까지 왔다는 것을 눈으로 확인한 뒤였습니다.

"막히면 누구한테 물어보나요." 이게 더 실질적인 질문이었습니다. 교육이 끝난 뒤가 진짜이기 때문입니다.

그래서 2일차에 일부러 망가뜨리고 고치는 연습을 넣었습니다. API 키를 잘못 넣어 보고, 없는 파일을 지정해 보고, 매체 주소를 바꿔 봤습니다. 오류 메시지를 그대로 복사해 붙여 넣으면 대부분 풀린다는 걸 세 번쯤 겪고 나면 두려움이 줄어듭니다.

막히는 지점이 "코드를 모르는 것"이 아니라 "물어보는 방법을 모르는 것" 이라는 게 이 과정에서도 확인됐습니다.

이 방식으로 안 되는 것

• 유료 매체는 본문을 못 가져옵니다. 제목과 링크만 남습니다. 구독 중인 매체가 있으면 별도 처리가 필요합니다
• 중요도 판단이 완벽하지 않습니다. 걸러진 것 중에 중요한 게 있을 수 있어, 전체 수집 목록을 시트에 남겨 나중에 확인 가능하게 했습니다
• 매체 구조가 바뀌면 깨집니다. 본문 수집이 안 되기 시작하면 고쳐야 합니다. 이 경우 실패 알림이 오게 해 뒀습니다
• API 호출 한도가 있습니다. 키워드를 무한정 늘릴 수 없어, 우선순위를 정해 관리하게 했습니다

운영 준비 — 누가 관리할지 정했다

만든 사람만 아는 자동화는 그 사람이 나가면 멈춥니다. 이 팀은 담당자 순환이 잦아 특히 중요했습니다.

운영 문서를 마지막 시간에 썼습니다. 흐름도, 키워드 목록의 위치, API 키 관리 방법, 실패 알림이 오면 무엇을 볼지. 이 문서 없이 넘기면 반년 뒤에 아무도 못 고칩니다.

API 키를 팀 계정으로 발급받아 관리하게 했습니다. 개인 계정으로 각자 만들면 담당자가 바뀔 때 끊깁니다.

월 비용을 계산해 드렸습니다. 키워드 수 × 실행 횟수로 예상 비용이 나옵니다. 숫자를 미리 보여 드리는 편이, 나중에 "이거 계속 써도 되나"를 줄입니다.

교육이 끝났을 때 남은 것

참가자 13명 중 다섯 팀이 각각 담당 품목의 브리핑 에이전트를 완성했습니다. 다음 날 아침부터 메일이 왔습니다.

40분이 5분이 됐습니다. 그런데 차장님이 더 크게 보신 건 다른 지점이었습니다 — 팀 전체가 같은 것을 본다는 것. 사람마다 다른 곳을 보던 문제가 없어졌습니다.

한 가지 더 있었습니다. 브리핑에 "왜 중요한지"가 한 줄씩 붙어 있어, 신입 담당자가 어떤 뉴스를 왜 중요하게 봐야 하는지를 매일 배우게 됐습니다. 판단 기준을 가르치려고 만든 게 아닌데 그런 효과가 났습니다.

여섯 달 뒤 확인했을 때 키워드 목록이 두 배로 늘어 있었습니다. 처음 만든 것을 복사해 다른 품목으로 넓힌 결과입니다. 그리고 예상 못 한 활용이 나왔습니다 — 수집 결과를 쌓은 시트가 분기 시장 보고서의 재료가 됐습니다.

다룬 도구

• Claude Code · Codex — 바이브코딩으로 수집·요약 도구를 만듭니다. 코드는 직접 쓰지 않습니다
• 오픈 API — 뉴스 검색과 본문 수집에 씁니다
• 메일 발송 — 매일 아침 정해진 시각에 브리핑을 보냅니다

비슷한 교육을 검토 중이시라면

이 과정은 14시간(2일)이었습니다. 하나를 끝까지 만들려면 이틀이 필요합니다. 하루로 줄이면 수집까지만 되고 발송·정기 실행을 못 다룹니다.

• 매일 확인하는 외부 정보가 있는가 — 뉴스·시세·공시 무엇이든 됩니다
• 사람마다 보는 곳이 다른가 — 다를수록 효과가 큽니다
• 결과를 어디로 받을 것인가 — 메일·메신저·시트 중 실제로 여는 곳으로

담당 품목과 지금 보고 계신 정보원만 알려주시면 어느 범위까지 자동화가 가능한지 정리해 보내 드립니다.