자산운용사 n8n 업무자동화 PoC

동기

자산운용사 PoC 의 목표는 n8n 이 고객 환경에서 실제 업무자동화 플랫폼으로 동작하는지 검증하는 것이었습니다. 범위는 두 축이었습니다. 하나는 외부망과 내부망 설치, 그리고 현장에서 다시 세울 수 있는 인수 패키지였고, 다른 하나는 문서 기반 업무를 보여 줄 PDF 를 PPT 로 바꾸는 워크플로였습니다.

공개 카드에서는 고객명과 내부 접속 정보를 쓰지 않습니다.

내가 담당한 트랙

설치와 인수 패키지가 제 쪽이었고, 문서 변환 워크플로는 동료와 같이 리드했습니다. 그 안에서 산출물을 두 벌로 나눈 것, 업로드와 다운로드를 갖는 사용자 흐름, 그리고 그것을 비동기로 다시 짠 것이 제 몫입니다. 항목별 내역은 오른쪽 「주요 업무」에 있습니다.

산출물을 두 벌로 나누기

처음에는 PDF 한 벌을 PPT 한 벌로 바꾸는 방향이었습니다. 그런데 요구가 둘로 갈렸습니다. 원본이 어떻게 생겼는지 그대로 보고 싶다는 것과, 받아서 고쳐 쓰고 싶다는 것입니다. 이 둘은 한 파일 안에서 서로를 깎습니다. 원본 모양을 지키려면 페이지를 그림처럼 옮겨야 하고, 고칠 수 있게 하려면 글자와 표를 다시 짜야 하는데 그러면 원본과 배치가 달라집니다.

그래서 합치지 않고 나눴습니다. 한 벌은 원본 한 페이지를 한 슬라이드로 그대로 옮긴 참조본이고, 다른 한 벌은 글자와 표를 편집 가능한 요소로 다시 구성한 검토본입니다. 결과 묶음에는 두 파일과 함께 각 단계에서 무엇을 얼마나 처리했는지를 적은 수치가 같이 들어갑니다.

처리에 몇 분이 걸리는 파일

문서가 커지면 처리에 몇 분이 걸립니다. 그동안 요청을 붙잡고 있으면 중간의 게이트웨이나 프록시가 먼저 끊고, 사용자는 무엇이 어디까지 됐는지 알 방법이 없습니다.

그래서 사용자 쪽 흐름을 네 갈래로 갈랐습니다. 업로드는 파일을 받고 작업 번호와 조회·다운로드 주소를 바로 돌려줍니다. 실제 처리는 그 뒤에서 따로 돌고, 조회는 지금 어느 단계인지와 얼마나 진행됐는지를 답하며, 다운로드는 끝난 작업에만 결과 묶음을 내줍니다.

이렇게 하면 요청이 즉시 끝나므로 끊길 자리가 없어지고, 사용자는 기다리는 동안 상태를 물어볼 수 있습니다. 작업이 어디서 실패했는지도 단계 이름으로 남습니다.

인수 패키지

최종 산출물은 워크플로 파일이 아니라 현장에서 다시 설치하고 검증할 수 있는 묶음이었습니다. 외부망과 내부망 각각의 컨테이너 구성, 환경변수 서식과 설치 스크립트, 폐쇄망에 이미지를 들여보내는 가이드, 워크플로 정의와 보조 스크립트, 무결성 확인용 체크섬과 진단 스크립트, 그리고 운영 문서와 시연용 명령 모음을 함께 넣었습니다.

이 패키지는 한 번 폐기했습니다. 처음 만든 것이 현장 조건을 잘못 가정하고 있어서, 전제를 다시 잡고 두 번째로 만들었습니다.

PoC 는 이후 본사업으로 이어졌습니다.

배운 점

• 오래 걸리는 일을 요청 하나에 담으면 그 요청이 언제 끊길지를 내가 정할 수 없습니다. 처리를 뒤로 보내고 사용자에게는 번호와 조회 주소를 먼저 주는 형태로 바꾸고 나서야, 사용자가 기다리는 동안 무슨 일이 일어나는지 물어볼 수 있게 됐습니다. 실패 지점도 단계 이름으로 남습니다.
• 요구 둘이 서로를 깎을 때 한 산출물에 억지로 담으면 양쪽 다 어중간해집니다. 원본 모양과 편집 가능성이 그런 관계였고, 나누고 나서야 각각을 그 목적에 맞게 만들 수 있었습니다.