글 목록

블로그
사례와 실험

수정

매일 아침 3시간, 금융 데이터를 수작업으로 모으고 있다면

금융·회계 데이터 취합의 구조적 비효율과 자동화 파이프라인 설계 접근법

이국환SION.LAB 대표예상 읽기 시간 10분


매일 금융 자료를 모으는 순서본문에서 설명한 흐름을 먼저 확인합니다.. 일정 시작: 정해진 시각에 수집을 시작합니다. 원본 수집: API·로그인 포털·파일·DB 수집기로 받습니다. 정규화·저장: 공통 스키마로 맞춰 쌓습니다. 완료 알림: 수집기별 성공·실패를 알림으로 받습니다. 수집기는 소스별로 독립적으로 실패해 문제 소스를 바로 알 수 있습니다.전체 흐름매일 금융 자료를 모으는 순서본문에서 설명한 흐름을 먼저 확인합니다.01일정 시작정해진 시각에 수집을 시작합니다02원본 수집API·로그인 포털·파일·DB 수집기로받습니다03정규화·저장공통 스키마로 맞춰 쌓습니다04완료 알림수집기별 성공·실패를 알림으로 받습니다수집기는 소스별로 독립적으로 실패해 문제소스를 바로 알 수 있습니다.
전체 흐름. 수집기는 소스별로 독립적으로 실패해 문제 소스를 바로 알 수 있습니다.

기획의 시작: "데이터가 없는 게 아니에요"

금융·회계 분야의 데이터 자동화를 기획하면서 여러 현장 담당자들의 아침 루틴을 분석했습니다. 공통 패턴이 있었습니다. 증권사 HTS, 회계 시스템, 운용사 포털, 내부 거래 시스템. 각각 로그인하고, 파일을 내려받고, 엑셀에 붙여넣는 과정이 3시간 동안 반복됩니다. 오전 10시가 지나서야 전날 포지션이 완성됩니다.

"이 작업에서 가장 아까운 게 뭔가요?"라고 물으면 답은 한결같았습니다.

"데이터가 없는 게 아니에요. 모으는 데 시간이 다 가요. 완성되면 이미 시장이 2~3시간 움직인 후예요."

새벽빛이 드는 창가의 모니터 세 대와 커피

전략 판단이 늦어지는 이유는 데이터 부족이 아니라 취합 구조의 부재였습니다. 이 문제를 해결하는 자동화 파이프라인을 직접 기획했습니다.

수작업 취합의 실제 흐름

수작업 취합의 실제 흐름주체별 요청·응답과 순서를 확인합니다.. 참여: 담당자A, 담당자B, 플랫폼, 엑셀. 순서: 1. 담당자A → 플랫폼: 소스1 로그인·다운로드; 2. 담당자A → 엑셀: 수동 붙여넣기; 3. 담당자A → 플랫폼: 소스2 로그인·다운로드; 4. 담당자A → 엑셀: 수동 붙여넣기; 5. 담당자B → 플랫폼: 소스3 로그인·다운로드; 6. 담당자B → 엑셀: 수동 붙여넣기; 7. 담당자A → 담당자B: 취합 완료 확인; 8. 메모(담당자A, 엑셀): 총 소요 시간: 2~3시간. 각 주체 사이에 오가는 요청·응답과 메모를 순서대로 읽습니다.요청과 응답 순서수작업 취합의 실제 흐름주체별 요청·응답과 순서를 확인합니다.담당자A담당자B플랫폼엑셀01담당자A플랫폼소스1 로그인·다운로드02담당자A엑셀수동 붙여넣기03담당자A플랫폼소스2 로그인·다운로드04담당자A엑셀수동 붙여넣기05담당자B플랫폼소스3 로그인·다운로드06담당자B엑셀수동 붙여넣기07담당자A담당자B취합 완료 확인08메모 · 담당자A, 엑셀총 소요 시간: 2~3시간각 주체 사이에 오가는 요청·응답과 메모를순서대로 읽습니다.
도식: 수작업 취합의 실제 흐름

소스마다 포맷이 다르고, 담당자마다 취합 방식이 달라집니다. 한 명이 빠지면 전체 취합이 늦어집니다. 이 구조에서 데이터 신뢰도를 유지하는 것은 담당자 개인의 주의력에 달려 있습니다.

자동화 파이프라인이 필요한 이유

자동화가 어렵다고 느끼는 이유 중 하나는 "각 소스가 너무 다르다"는 것입니다. 실제로는 소스 유형이 3~4가지로 수렴됩니다. 그 유형에 맞는 수집기를 만들고 연결하면 됩니다.

# 데이터 수집 파이프라인 구조
# 핵심 원칙: 소스 유형별 수집기 분리 → 공통 저장소로 통합
 
class DataPipeline:
    def run(self, date: str):
        sources = [
            ApiCollector("증권사API", credentials),      # REST API 소스
            SeleniumCollector("운용사포털", credentials), # 로그인 필요 소스
            FileWatcher("회계시스템", download_path),     # 파일 다운로드 소스
            DbConnector("내부DB", conn_string),           # 직접 DB 연결 소스
        ]
        for source in sources:
            raw = source.fetch(date)
            normalized = source.normalize(raw)  # 공통 스키마로 변환
            save(normalized)
 
        notify_completion()  # Slack·이메일 알림

각 수집기는 독립적으로 실패합니다. 한 소스가 오류를 내도 나머지는 정상 수집됩니다. 어느 소스에서 문제가 났는지 즉시 파악할 수 있습니다.

자동화된 파이프라인의 흐름

자동화된 파이프라인의 흐름주체별 요청·응답과 순서를 확인합니다.. 참여: 스케줄러, 파이프라인, 소스들, DB, 담당자. 순서: 1. 메모(스케줄러): 오전 7시 자동 실행; 2. 스케줄러 → 파이프라인: 일일 수집 시작; 3. 메모(파이프라인, 소스들): 자동화 핵심 구간; 4. 파이프라인 → 소스들: 병렬 수집 (API·크롤링·파일); 5. 소스들 → 파이프라인: 원본 데이터 반환; 6. 파이프라인 → DB: 정규화 후 저장; 7. 파이프라인 → 담당자: 완료 알림 (Slack); 8. 메모(담당자): 출근 시 데이터 이미 준비. 각 주체 사이에 오가는 요청·응답과 메모를 순서대로 읽습니다.요청과 응답 순서자동화된 파이프라인의 흐름주체별 요청·응답과 순서를 확인합니다.스케줄러파이프라인소스들DB담당자01메모 · 스케줄러오전 7시 자동 실행02스케줄러파이프라인일일 수집 시작03메모 · 파이프라인, 소스들자동화 핵심 구간04파이프라인소스들병렬 수집 (API·크롤링·파일)05소스들파이프라인원본 데이터 반환06파이프라인DB정규화 후 저장07파이프라인담당자완료 알림 (Slack)08메모 · 담당자출근 시 데이터 이미 준비각 주체 사이에 오가는 요청·응답과 메모를순서대로 읽습니다.
도식: 자동화된 파이프라인의 흐름

담당자가 출근하면 전날 데이터가 이미 대시보드에 올라와 있습니다. 3시간이 0분이 됩니다. 그 시간을 분석과 판단에 씁니다.

항목수작업 취합자동화 파이프라인
데이터 준비 시간매일 3~4시간30분 이내 (자동)
오류 발생률수동 입력으로 높음검증 로직으로 최소화
소스 추가 대응담당자 재교육 필요수집기 1개 추가
장애 인지결과물 누락 시 뒤늦게 발견즉시 알림
담당자 부재 시데이터 준비 중단정상 가동

자동화 도입 판단 기준

데이터 취합 자동화가 맞는 상황인지 아래 기준으로 판단하세요.

  • 동일한 소스에서 같은 형식의 데이터를 매일 수집하고 있다
  • 취합 담당자가 특정 인원에 한정되어 있고, 부재 시 지연이 발생한다
  • 수집 후 동일한 정제 작업(형식 통일, 이상값 제거)이 반복된다
  • 데이터 완성 시점이 오전 업무 시간에 걸쳐 있어 의사결정이 지연된다

수집 주기가 규칙적이고 소스 형식이 안정적이라면, 자동화 ROI는 빠르게 나옵니다. 불규칙하거나 소스 구조가 자주 바뀐다면 유지 비용을 먼저 계산해야 합니다.

#금융#회계#데이터자동화#파이프라인
문의하기