보고서 자동화, 사람 승인 대신 발송 직전 검사를 둔 이유

왜 보고서 자동화는 마지막 발송에서 막히는가

보고서 자동화라고 하면 대개 문서를 만드는 일부터 떠올립니다. 자료를 모으고 표를 채우고 문장을 쓰는 일입니다. 그런데 사람 손을 완전히 빼려는 순간 가장 무거운 자리는 작성이 아니라 발송으로 옮겨 갑니다. 작성 단계의 실수는 파일을 다시 만들면 끝나지만, 증권사로 나간 메일은 그렇게 되돌릴 수 없기 때문입니다.

이 프로젝트의 대상은 증권사에 보내는 분기 운용 보고서입니다. 받는 쪽이 금융회사이고 내용이 운용 결과라서, 기준일이 틀린 표나 출처가 없는 수치는 단순한 오탈자로 끝나지 않습니다. 보낸 회사의 숫자 전체를 의심하게 만드는 신호가 될 수 있습니다.

가장 흔한 해법은 마지막에 사람이 한 번 보는 방식입니다. 초안은 기계가 만들고 사람이 승인 버튼을 누릅니다. 이 프로젝트는 그 자리에 사람 대신 검사를 넣었습니다. 사람 승인이 나쁘다는 주장이 아닙니다. 사람 손을 어디에 남겨야 하는지는 일마다 다르고, 비슷한 판단을 다룬 글로 컴플라이언스 자동화 기록이 있습니다. 이 글의 질문은 더 좁습니다. 사람 승인을 뺀다면 무엇이 그 자리를 대신해야 할까요?

답을 먼저 적으면 두 가지입니다. 틀린 보고서가 나갈 조건을 미리 적어 둔 검사, 그리고 그 검사가 실제로 막는지 확인한 시험 기록입니다. 이 글은 이 둘을 중심으로, 기록에 남은 만큼만 적습니다.

사람이 처리하던 단계는 어떻게 하나로 이어졌나

기록에 남은 단계는 4개입니다. 자료 수집, 평가 엑셀 생성, 운용보고서 작성, 메일 발송입니다. 이 넷을 사람이 처리했고, 자동화의 뼈대는 네 단계를 끊김 없는 흐름 하나로 잇는 작업이었습니다.

단계를 하나씩 자동화하는 일과 전체를 잇는 일은 성격이 다릅니다. 엑셀 생성만 자동으로 돌리고 그 파일을 사람이 옮겨 붙이면, 사람은 여전히 흐름 한가운데 서 있어야 합니다. 일정을 챙기는 사람도, 어디까지 끝났는지 기억하는 사람도 그대로 남습니다. 네 단계가 이어져야 비로소 사람이 흐름 밖으로 나올 수 있습니다.

반대로 흐름을 이으면 새로운 위험이 생깁니다. 앞 단계에서 생긴 작은 오류를 중간에서 알아채던 눈이 사라지기 때문입니다. 사람이 중간에 있으면 우연히 잡힐 수도 있는 어긋남이 그대로 다음 단계로 흘러갑니다. 그래서 흐름의 끝, 메일이 나가기 바로 앞에 검사를 둘 이유가 생깁니다.

운용보고서 한 파일에 원천 4종을 어떻게 묶었나

운용보고서는 서로 다른 곳에서 온 재료 4종을 PPTX 파일 하나로 합쳐 만듭니다. 시황 코멘트는 Anthropic Claude API로 한국어 문장을 생성하고, CPI는 FRED, 시장 데이터는 yfinance, NAV는 자사 운용 플랫폼에서 가져옵니다. FRED는 미국 경제 지표를 제공하는 데이터 서비스이고, yfinance는 시장 데이터를 프로그램으로 내려받는 파이썬 라이브러리입니다.

이 구성에서 눈여겨볼 점은 성격이 다른 재료가 섞인다는 사실입니다. 숫자 셋은 외부 데이터와 사내 시스템에서 오고, 문장 하나는 언어 모델이 씁니다. 사내 NAV와 공개 시장 데이터는 소유자도 갱신 방식도 다릅니다. 같은 보고서 안에 있어도 저절로 같은 시점을 가리키지는 않습니다.

언어 모델이 쓴 시황 코멘트에는 다른 종류의 위험이 있습니다. 언어 모델은 자연스러운 문장을 잘 쓰지만, 문장 속 숫자가 어디서 왔는지를 스스로 보증하지는 않습니다. 읽는 사람 눈에는 입력 데이터에서 온 숫자와 문장을 쓰다 생긴 숫자가 똑같이 보입니다. 아래에서 다룰 근거 없는 수치 검사가 필요한 이유입니다.

결국 보고서를 자동으로 만드는 일 자체는 재료를 끌어와 틀에 넣는 작업입니다. 어려운 부분은 합쳐진 결과가 서로 맞는지 확인하는 쪽에 있습니다. 재료가 4종이면 어긋날 수 있는 조합도 그만큼 늘어납니다.

사람 승인 대신 왜 발송 직전 검사를 두었나

먼저 밝혀 둘 점이 있습니다. 당시 어떤 대안을 어떤 순서로 비교했는지는 기록에 없습니다. 기록에 있는 사실은 사람 승인 대신 발송 직전 검사를 두었다는 결정과 그 뒤의 시험 결과입니다. 그래서 아래 비교는 당시 회의록이 아니라, 두 방식의 구조적 차이를 지금 정리한 내용입니다. 처음부터 답을 알았던 것처럼 쓰지 않으려는 선택입니다.

표에서 가장 중요한 줄은 재현입니다. 사람 승인은 좋은 안전장치가 될 수 있지만, 승인이 얼마나 잘 작동하는지를 숫자로 재기는 어렵습니다. 반면 검사는 일부러 틀린 입력을 넣고 멈추는지 볼 수 있습니다. 이 프로젝트가 잘못된 발송 0건이라는 결과를 말할 수 있는 근거도 검사를 시험할 수 있었기 때문입니다.

검사의 약점도 표에 그대로 있습니다. 조건으로 적지 않은 오류는 통과합니다. 사람은 기준이 없어도 이상한 내용을 보고 멈출 수 있지만, 검사는 적어 둔 내용만 봅니다. 그래서 사람 승인을 뺀다는 결정은 사람의 판단 일부를 내려놓는 교환입니다. 공짜 개선이 아닙니다.

발송 직전 검사는 무엇을 막는가

검사가 발송을 멈추는 조건은 3가지입니다. 기준일이 맞지 않을 때, 지표 분기가 맞지 않을 때, 근거 없는 수치가 있을 때입니다. 하나라도 걸리면 보고서를 보내지 않고 담당자에게 알립니다.

앞의 두 조건은 시점을 묻습니다. 보고서가 말하는 날짜와 표 안의 숫자가 같은 시점을 가리키는가, 지표가 이번 분기 값이 맞는가를 확인합니다. 보고서를 분기마다 다시 만드는 일에서는 지난 분기 값이 그대로 남는 사고를 쉽게 상상할 수 있습니다. 형식은 멀쩡해서 눈으로 훑으면 지나치기 쉬운 오류입니다.

세 번째 조건은 출처를 묻습니다. 보고서에 있는 수치가 입력 재료에서 왔는지를 따집니다. 원천 4종 가운데 하나가 언어 모델이 쓴 문장이라는 점을 떠올리면 왜 이 조건이 들어갔는지 이해할 수 있습니다. 다만 이 조건을 어떤 방식으로 판정하는지는 기록에 없어 여기서 적지 않습니다.

눈여겨볼 부분은 실패했을 때의 행동입니다. 검사는 문제를 고치려 들지 않습니다. 보내지 않고 사람에게 알립니다. 사람 승인을 없앴다고 사람이 사라지지는 않습니다. 매번 보던 역할이 이상할 때만 불려 오는 역할로 바뀝니다. 담당자의 일이 전 건 확인에서 예외 처리로 옮겨 가는 구조입니다.

이 선택을 한 문장으로 줄이면 보내지 않는 쪽으로 실패하게 만든다는 원칙입니다. 늦은 보고서는 사람이 수습할 수 있지만, 틀린 보고서가 나간 뒤에는 수습할 방법이 줄어듭니다.

검사가 정말 막는지는 어떻게 확인했나

검사를 만들었다는 사실만으로는 아무것도 증명하지 못합니다. 평소에 정상 보고서만 흘려보내면 검사가 아무 일도 안 해도 겉보기에는 똑같이 잘 돌아갑니다. 작동하는 검사와 고장 난 검사가 구분되지 않는다는 뜻입니다. 그래서 실패 주입 시험을 했습니다. 일부러 잘못된 상태를 만들어 넣고 검사가 발송을 멈추는지 보는 시험입니다.

결과는 시험 10건에서 잘못된 발송 0건입니다. 사람 승인을 빼는 결정을 뒷받침하는 유일한 수치이자, 이 글에서 가장 무거운 숫자입니다.

이 숫자를 읽을 때 조심할 점도 함께 적습니다. 10건은 큰 표본이 아닙니다. 0건은 시험에 넣은 오류를 모두 막았다는 뜻이지, 세상의 모든 오류를 막는다는 뜻이 아닙니다. 시험 10건이 각각 어떤 오류였는지도 기록에 없습니다. 그래도 시험을 아예 하지 않은 검사와 시험 기록이 있는 검사는 다릅니다. 앞의 것은 믿음이고 뒤의 것은 범위가 정해진 증거입니다.

비슷한 시행착오를 다룬 글로 챗봇 상담 자동 검수 기록이 있습니다. 검사 도구를 어떻게 시험해야 하는지 고민한다면 함께 읽어 볼 만합니다.

평가자료 4종은 왜 요청을 기다리지 않게 바꿨나

두 번째 변화는 검사와 성격이 다릅니다. 평가자료 4종의 발송 시점을 뒤집었습니다. 예전에는 상대의 요청이 와야 움직였고, 그 요청은 분기가 끝나고 수 주 뒤에야 왔습니다. 지금은 요청을 기다리지 않고 새 분기 영업일 2일째부터 먼저 보냅니다.

자동화를 이야기할 때는 보통 사람이 일하는 시간을 줄이는 쪽만 봅니다. 여기서 없앤 대상은 작업 시간이 아니라 대기 시간입니다. 요청이 언제 올지 모르는 상태로 자료를 준비해 두고 기다리는 시간입니다. 같은 일을 자동화해도 요청이 온 뒤에 돌리면 대기는 그대로 남습니다.

먼저 보낼 수 있게 된 바탕에는 앞에서 이은 흐름이 있습니다. 자료 수집과 평가 엑셀 생성이 사람 없이 돌아가면, 분기가 바뀌는 시점 자체를 시작 신호로 삼을 수 있습니다. 사람이 처리하던 때라면 요청이 온 일부터 처리하는 쪽이 자연스럽습니다. 일을 시작시키는 신호를 바꾸는 선택은 자동화가 있어야 현실적인 선택지가 됩니다.

운영 업무를 자동화할 때 이 질문을 따로 던져 볼 만합니다. 지금 이 일은 누가 시작시키는가? 상대의 요청이 시작 신호라면, 달력이 시작 신호가 될 수는 없는가? 답이 된다면 작업 시간을 한 시간도 줄이지 않아도 기다림은 사라질 수 있습니다.

경쟁사 6개사 분석 리포트는 무엇이 달랐나

같은 리포팅 자동화 묶음에는 산출물이 하나 더 있습니다. 로보어드바이저 6개사의 경쟁 환경을 분기마다 분석하는 리포트로, Excel 형식으로 자동 생성합니다. 로보어드바이저는 알고리즘으로 자산 운용을 돕는 서비스를 말합니다.

운용 보고서와 나란히 놓으면 차이가 보입니다. 운용 보고서는 증권사로 나가는 문서라 발송 직전 검사가 핵심이었습니다. 경쟁 환경 리포트에 대해 기록이 말하는 내용은 자동 생성까지이고, 외부 발송이나 별도 검사는 기록에 없습니다. 기록의 무게가 다르다는 점만으로 단정할 수는 없지만, 자동화의 안전장치는 산출물이 어디로 나가느냐에 맞춰 달라져야 한다는 점은 분명합니다.

또 한 가지 공통점도 있습니다. 둘 다 분기라는 달력을 따라 반복합니다. 주기가 고정된 일은 시작 신호를 달력에 맡기기 쉽고, 지난 회차의 결과물이 다음 회차의 틀이 됩니다. 처음 자동화를 시도한다면 이런 일이 후보로 좋습니다.

기록에 없는 것과 남은 한계는 무엇인가

이 글이 말하지 못하는 내용을 분명히 적습니다. 숫자가 없는 자리에 숫자를 채우지 않기 위해서입니다.

• 절감 시간: 무인화 전후로 보고서 작성과 발송에 든 시간은 기록에 없습니다.
• 운영 실적: 실제 분기 운영에서 검사가 몇 번 발송을 멈췄는지는 기록에 없습니다. 시험 결과와 운영 결과는 다른 숫자입니다.
• 시험 내용: 실패 주입 10건의 오류 종류와 정상 보고서를 잘못 막은 사례가 있었는지는 기록에 없습니다.
• 상대 반응: 평가자료를 먼저 보낸 뒤 증권사 쪽 업무나 반응이 어떻게 달라졌는지는 기록에 없습니다.
• 검사 범위: 조건 3가지 밖의 오류, 예를 들어 숫자는 맞는데 해석이 어긋난 시황 코멘트를 막는 장치는 기록에 없습니다.

특히 마지막 항목이 실제 위험에 가장 가깝습니다. 기준일과 출처 검사는 틀린 숫자를 겨냥하지만, 맞는 숫자로 쓴 잘못된 설명은 다른 문제입니다. 검사에 잡히지 않는 오류가 무엇인지 계속 찾아 조건을 늘리는 일은 구축이 끝난 뒤에도 남습니다.

정상 보고서를 잘못 막는 문제도 지켜봐야 합니다. 검사가 너무 자주 멈추면 담당자는 알림에 익숙해지고, 사람 승인을 없앤 효과도 함께 사라집니다. 이 균형을 판단할 운영 숫자가 쌓여야 이 구조의 진짜 성적을 말할 수 있습니다.

우리 회사 보고서에 옮긴다면 무엇부터 봐야 할까

금융회사가 아니어도 같은 구조를 쓸 수 있습니다. 정기적으로 밖에 나가는 보고서가 있다면 도구를 고르기 전에 아래 네 가지를 먼저 적어 보길 권합니다.

• 지금 사람이 처리하는 단계를 끝까지 적습니다. 이 프로젝트에서는 4개였습니다.
• 틀리면 곤란한 조건을 문장으로 적습니다. 기준일, 분기, 수치 근거처럼 맞고 틀림을 가를 수 있는 항목이어야 합니다.
• 조건에 걸렸을 때의 행동을 정합니다. 기본값은 보내지 않고 담당자에게 알리는 쪽입니다.
• 일부러 틀린 입력을 넣어 검사가 멈추는지 시험합니다. 시험 기록 없이 사람 확인을 빼지 않습니다.

네 번째를 건너뛰면 나머지 셋의 의미가 크게 줄어듭니다. 검사가 있다는 사실과 검사가 막는다는 증거는 다른 이야기이기 때문입니다. 시험이 어렵다면 사람 승인을 남긴 채 검사부터 붙여도 좋습니다. 사람과 검사가 함께 도는 기간에 검사가 놓친 오류를 모으면 그 자체로 다음 조건 목록이 됩니다.

반복 보고서를 어디부터 자동화할지, 사람 확인을 어디에 남길지 정리가 필요하다면 상담에서 지금 하는 방식을 알려 주세요.