일일 뉴스 브리핑 — 매일 아침 누가 업계를 읽어 줄 것인가

경영자에게 가장 비싼 자원은 시간입니다. 2차전지 업계, 관계사, 거래처, 경쟁사의 동향을 매일 직접 챙기는 건 불가능에 가깝습니다. 그래서 매일 아침 그것을 대신 읽고, 요약하고, **“오늘 신경 쓸 핵심 한 줄”**까지 뽑아 주는 AI 비서를 만들었습니다. 이 글은 작아 보이는 이 기능이 왜 우리가 지향하는 ERP의 축소판인지, 그리고 LLM을 쓸 때 가장 먼저 통제해야 할 것이 무엇인지에 대한 기록입니다.

실제 매일 아침 도착하는 'SL Power 뉴스 인텔리전스' 메일. 배터리·ESS·로봇·경쟁사 뉴스를 AI가 모아, 단순 요약이 아니라 “SL파워에 왜 중요한가”와 체크포인트(다음 행동)까지 붙여 줍니다 — 정보를 읽는 게 아니라 판단을 받는 브리핑입니다.

1. 아침마다 반복되는 “정보 노동”

제조 회사를 운영하면 매일 비슷한 질문을 하게 됩니다. 우리 업계(2차전지)에 무슨 일이 있었나? 거래처나 관계사 소식은? 경쟁사가 새로 뭘 내놨나? 이 정보는 여기저기 흩어져 있고, 모으는 데만 한참 걸립니다. 그리고 정작 가장 중요한 한 줄 — “그래서 오늘 내가 뭘 신경 써야 하나” — 는 스스로 뽑아야 합니다.

용어: 정보 노동

흩어진 자료를 모으고, 읽고, 추려서 “판단 가능한 형태”로 만드는 일입니다. 가치는 낮지 않지만 반복적이고 시간을 크게 잡아먹어, 자동화 1순위 후보가 되는 일입니다.

이 노동은 매일, 비슷한 모양으로 반복됩니다. 반복되는 노동이 보이면 그게 첫 자동화 후보입니다. 그래서 이걸 사람 대신 처리할 AI 비서를 만들기로 했습니다.

여기서 짚을 점이 있습니다. 이 노동의 진짜 비용은 “시간”만이 아니라 “놓침”입니다. 바쁜 날엔 업계 뉴스 읽기를 건너뛰고, 그러다 거래처의 중요한 변화나 경쟁사의 신제품을 며칠 늦게 압니다. 정보를 매일 빠짐없이 챙기는 것은 사람의 의지로는 잘 안 됩니다 — 의지는 바쁜 날 가장 먼저 무너집니다. 반면 시스템은 바쁘든 한가하든 매일 같은 시각에 같은 일을 합니다. 자동화의 가치는 “빠르다”보다 “빠뜨리지 않는다”에 있다는 걸, 이 작은 기능이 다시 일깨워 줬습니다.

2. RSS 리더와 무엇이 다른가 — “요약”이 아니라 “인사이트”

단순히 기사를 모아 보여주는 건 흔한 뉴스 모음(RSS 리더)과 다를 게 없습니다. 우리가 원한 건 한 단계 위였습니다.

단계	하는 일	필요한 기술
① 수집	업계·관계사·거래처·경쟁사 뉴스를 모은다	크롤링/연동(규칙)
② 요약	기사를 짧게 줄인다	언어 모델(LLM)
③ 인사이트	”오늘 경영진이 주목할 핵심”을 한 줄로 뽑는다	맥락 이해(LLM)

핵심은 ③입니다. 흩어진 동향을 읽고 **“오늘 경영진이 주목해야 할 핵심 인사이트”**를 한 줄로 뽑는 것 — 이건 단순 분류(규칙)로는 안 되고, 맥락을 이해하는 언어 모델의 일입니다.

용어: LLM

Large Language Model, 사람의 글을 이해하고 생성하는 대형 언어 모델입니다. 단순히 “어떤 단어가 있나”가 아니라 “이 소식이 무슨 의미인가”를 읽어냅니다. 그래서 요약·인사이트 추출처럼 맥락이 필요한 일에 씁니다.

3. AI 계층에서 어디에 두었나 (L4)

우리는 AI 기능을 무작정 붙이지 않고, 다섯 단계로 나눠 관리합니다. 이렇게 줄을 세워 두면, 어떤 기능이 어느 단계의 위험과 비용을 갖는지가 분명해집니다.

AI 5계층(규칙 → 통계 → ML → LLM → 에이전트). 뉴스 브리핑은 L4(LLM)에 위치합니다. 스스로 행동하는 L5와 달리, L4는 "읽고 요약·제안"까지만 합니다.

뉴스 브리핑은 “읽고 요약·제안”이므로 L4입니다. 스스로 무언가를 실행하는 자율 에이전트(L5)와는 다릅니다. 그래서 위험도 더 낮고, 사람의 결재 없이도 매일 돌릴 수 있었습니다.

4. 가장 중요한 한 가지 — LLM 호출을 한 곳으로 모았다

여기서 우리가 의식적으로 한 결정이 있습니다. 이 LLM 호출을 코드 곳곳에 흩뿌리지 않고, 단일 게이트웨이 한 곳을 통해서만 부르게 했습니다.

용어: 게이트웨이(gateway)

모든 LLM 호출이 반드시 지나가는 단 하나의 관문입니다. “어떤 작업에 어떤 모델을 쓸지”를 여기서 한꺼번에 정합니다. 호출이 흩어져 있으면 모델·비용·정책을 손볼 때 코드 전체를 뒤져야 합니다.

왼쪽(빨강)은 LLM 호출이 코드 곳곳에 흩어진 상태 — 모델 하나 바꾸려도 전부 뒤져야 합니다. 오른쪽(초록)은 게이트웨이로 모아 한 손에 쥔 상태. 뉴스·결재 요약·SLA 진단이 같은 관문을 통과합니다.

통제 대상	흩어진 호출이면	게이트웨이면
모델 교체	호출하는 모든 코드를 찾아 수정	한 곳의 라우팅 표만 변경
비용 관리	어디서 얼마 쓰는지 추적 난망	한 관문에서 작업별로 집계
정책(외부 전송 허용 여부)	제각각 — 누락 위험	관문에서 작업별로 허용/차단

팁

LLM은 모델이 자주 바뀌고, 비용이 호출마다 들고, “이 작업에 외부 모델을 써도 되나”라는 정책 판단이 필요합니다. 호출이 흩어져 있으면 이 셋을 손볼 때마다 코드 전체를 헤집어야 합니다. 한 곳(게이트웨이)으로 모으면 모델·비용·정책을 한 손에 쥡니다. 예컨대 어떤 작업은 외부 모델로, 어떤 민감한 작업은 막거나 다른 모델로 — 이런 라우팅을 코드를 안 건드리고 표 하나로 바꿀 수 있습니다.

5. 업무포탈 안의 한 화면으로

이 브리핑은 별도 앱이 아니라 업무포탈의 한 모듈로 들어갔습니다. 경영자가 아침에 포탈을 열면 뉴스·사내 소식과 함께 AI 비서의 브리핑이 한자리에 놓입니다. 정보를 찾아 헤매는 게 아니라, 정보가 한 화면에서 기다리고 있는 구조입니다. 이 기능은 현재 완성 단계로 본다는 것이 CEO의 판단입니다(1인 개발·미배포 단계).

별도 앱으로 만들지 않은 것도 의도였습니다. 정보를 보려고 새 앱을 열고 로그인하는 마찰이 한 번이라도 끼면, 아무리 좋은 브리핑도 안 보게 됩니다. 이미 매일 여는 포탈 안에 끼워 넣어야, 브리핑이 “찾아가는 정보”가 아니라 “마주치는 정보”가 됩니다. 게다가 게이트웨이를 통해 결재 요약·SLA 진단 같은 다른 LLM 기능과 같은 관문을 공유하므로, 브리핑은 외딴 기능이 아니라 포탈의 AI 기능 묶음 중 하나로 자연스럽게 자리 잡았습니다. 한 곳에 모인 LLM 인프라가, 새 AI 기능을 추가할 때마다 처음부터 다시 깔 필요를 없애 준 것입니다.

6. 작지만, 우리가 가려는 방향의 축소판

뉴스 브리핑은 작아 보이지만 우리가 지향하는 ERP의 축소판입니다. 사람이 정보를 입력하고 가공하는 게 아니라, 시스템이 먼저 읽고 판단해서 사람에게 “결론”을 가져다줍니다.

1. 구시대 방식 — 사람이 여러 사이트를 돌며 읽고, 추리고, 요약하고, 판단합니다(정보 노동).
2. 지금 — 시스템이 읽고 요약하고 핵심을 한 줄로 뽑아 둡니다. 사람은 그 결론을 확인합니다.
3. 지향점 — 입력 없는 ERP. 사람이 데이터를 떠먹이는 게 아니라, 에이전트가 알아서 일하고 사람은 승인·확인만 합니다.

그 첫 경험을 이 작은 화면이 제공했습니다. “보여주는 도구”에서 “판단해서 결론을 주는 도구”로 넘어가는 감각 말입니다.

물론 정직하게 적자면, 뉴스 브리핑은 아직 L4(읽고 요약·제안)에 머뭅니다. 스스로 무언가를 실행하지는 않습니다. 경쟁사 동향을 읽고 “대응 회의를 잡을까요?”까지 제안하고 실행하는 건 한 단계 위인 자율 에이전트(L5)의 영역이고, 그 단계는 사람의 승인(HITL)이라는 안전장치를 반드시 끼워야 합니다. 그래서 우리는 욕심내지 않고 L4에서 단단히 시작했습니다. 작은 기능 하나라도 “AI가 어느 계층의 위험을 갖는지”를 명확히 한 채로 올리는 것 — 그것이 나중에 L5로 확장할 때 흔들리지 않는 토대가 됩니다. 브리핑은 그 토대 위에 놓인 첫 벽돌입니다.

교훈

AI 제품의 가치는 “정보를 보여주는 것”이 아니라 **“판단을 대신 내려 한 줄로 요약해 주는 것”**에서 나옵니다. 요약과 인사이트는 LLM의 일이지만, 그 호출은 반드시 한 곳(게이트웨이)으로 모아 통제하세요 — 그래야 모델·비용·정책을 한 손에 쥡니다. 그리고 매일 반복되는 정보 노동이 보이면, 그게 당신의 첫 자동화 후보입니다.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.