노코드로 업무 시스템 연동 자동화를 만드는 순서

노코드 AI 자동화 파이프라인을 세울 때 일정을 정하는 값은 연결할 시스템의 개수가 아닙니다. 각 시스템의 계정을 누가 발급할 수 있느냐에 따라 표준 API 구간·인증 벽 구간·수작업 잔존 구간으로 나뉘고, 작업량은 그 경계를 넘을 때만 뜁니다.

요금 고지를 받고 대안을 찾기 시작하면 비교표부터 만들게 됩니다. 세로에 후보 도구, 가로에 실행 횟수 한도와 커넥터 수. 그런데 도구를 옮겨 새로 만들어 보면, 첫 번째 흐름을 완성하는 데 걸린 시간이 예전과 비슷합니다.

시간을 잡아먹은 자리가 도구 안이 아니었기 때문입니다. 화면에서 블록을 끌어다 놓는 일은 어느 빌더에서든 오후 한나절이면 익혀지고, 정작 며칠이 지나가는 자리는 연결 대상 쪽에 있습니다.

그 자리는 시스템마다 다르고, 같은 시스템이라도 회사마다 다릅니다.

도구를 바꿔도 왜 같은 자리에서 멈출까?

빌더가 제공하는 것은 연결하는 방법이지 연결할 권한이 아니기 때문입니다. 권한은 대상 시스템 쪽에 있고, 그쪽 사정은 도구를 바꿔도 그대로 남습니다.

실제로 멈춘 지점을 되짚어 보면 세 가지로 좁혀집니다. 사내 시스템에 붙일 계정을 요청했는데 답이 오지 않았거나, 외부 서비스가 심사를 요구했거나, 아예 접속 창구가 없어서 사람이 화면을 열어야 했거나.

셋 다 빌더의 기능 목록에는 나타나지 않는 조건입니다. 커넥터가 몇 개인지, 월 실행 횟수가 얼마인지를 아무리 비교해도 이 셋은 비교표에 자리가 없죠.

비용을 줄이려고 도구를 옮기는 경우에는 이 차이가 더 크게 다가옵니다. n8n이나 Make로 이미 몇 개를 만들어 본 팀이라면 특히 그렇습니다. 요금 자체는 옮긴 첫 달부터 바로 내려가지만, 옮기는 데 드는 사람의 시간은 연결 대상 쪽 조건에 따라 몇 배씩 벌어지기 때문입니다. 두 값을 같이 세어 봐야 옮기는 결정이 실제로 남는 장사인지가 나옵니다. 그리고 뒤쪽 값은 도구 비교표가 아니라 우리 시스템 목록에서만 나옵니다.

그래서 도구를 고르기 전에 연결 대상부터 줄을 세워야 합니다. 대상마다 난이도가 다르고, 그 난이도는 세 덩어리로 끊깁니다.

노코드 AI 자동화 파이프라인에서 막히는 자리는 세 구간으로 나뉜다

구간을 정하는 값은 하나뿐입니다. 그 시스템에 접속할 계정과 키를 우리가 직접 발급할 수 있는가, 누군가에게 받아야 하는가, 발급할 것이 아예 없는가.

구간	이 구간에 들어가는 조건	첫 연결에 드는 일	같은 발급처의 두 번째부터	실제로 기다리는 것
표준 API 구간	우리 계정으로 키나 토큰을 바로 발급한다	인증 정보 입력, 필드 대응, 실패 처리 규칙	거의 같은 일을 반복한다	데이터 형식이 맞는지
인증 벽 구간	발급 권한이 본사 정보전략팀·유지보수 업체·서비스 제공사 심사에 있다	발급 요청, 용도와 범위를 적은 문서, 승인 대기	경로가 이미 뚫려 첫 건보다 짧다	승인 절차가 먹는 달력 시간
수작업 잔존 구간	발급할 키가 없다(외부 접속 창구 미제공, 화면만 존재, 규정이나 계약이 자동 접속을 막음)	사람이 손댈 지점을 한 곳으로 모으는 설계	손댈 지점이 하나 더 늘어난다	매달 사람이 쓰는 시간

세 구간을 가른 기준이 기술 수준이 아니라는 점이 이 표의 핵심입니다. 최신 서비스인지 오래된 사내 시스템인지, REST를 지원하는지 아닌지는 구간을 정하지 못합니다.

정하는 것은 열쇠의 소재입니다. 그리고 열쇠는 시스템의 속성이 아니라 그 시스템과 우리 조직 사이의 관계라서, 벤더 문서를 읽어서는 우리 구간표를 채울 수 없습니다.

같은 시스템이 회사마다 다른 구간에 들어간다

구간을 정하는 값이 시스템이 아니라 우리 조직 쪽에 있어서 그렇습니다. 지난달에 출시된 협업 서비스를 예로 들어 보죠. 공식 문서에는 토큰 발급 절차가 친절하게 적혀 있으니 표준 API 구간처럼 보입니다. 그런데 그 계정이 본사에서 일괄 계약한 것이고 관리자 권한이 본사 정보전략팀에만 있다면, 우리 팀 입장에서는 인증 벽 구간입니다.

반대 방향도 성립합니다. 십수 년 된 사내 생산관리 시스템은 연동이 어려울 것 같지만, 데이터베이스 읽기 계정을 우리 팀이 직접 만들 수 있다면 표준 API 구간에 들어갑니다. 조회용 계정 하나로 필요한 데이터가 나온다면 첫 연결이 오히려 빨리 끝나기도 하죠.

저는 연동 요청서를 받으면 시스템 이름 옆 칸에 그 계정을 발급할 수 있는 사람의 소속부터 적습니다. 목록이 다 채워지기 전에는 일정 이야기를 시작하지 않는데, 채우고 나면 대개 예상과 다른 그림이 나오기 때문입니다. 쉬울 줄 알았던 대상이 둘째 구간에 있고, 어려울 줄 알았던 대상이 첫째 구간에 있는 경우가 목록마다 한둘씩 섞여 있습니다.

이 칸을 비워 둔 채 세운 일정은 뒤에서 밀립니다. 정확히 말하면 일정이 늘어나는 것이 아니라, 처음부터 세어지지 않은 시간이 뒤늦게 모습을 드러내는 것에 가깝습니다.

칸을 채우는 방법도 어렵지 않습니다. 시스템별로 관리자 화면에 들어가 계정을 새로 만들 수 있는지 눌러 보면 그 자리에서 답이 나오고, 눌러 볼 권한이 없다면 그 사실이 곧 둘째 구간이라는 표시입니다. 확인에 걸리는 시간은 대상 하나에 몇 분이라, 목록 전체를 훑어도 반나절을 넘기지 않습니다.

첫째 구간에서 실제로 하는 일은 무엇인가?

인증은 몇 분이면 끝나고, 남은 시간은 데이터 형식을 맞추는 데 들어갑니다. 연결 자체가 아니라 양쪽 필드의 이름과 값이 어긋나는 자리를 하나씩 메우는 일이죠.

작업은 대개 네 덩어리로 떨어집니다.

인증 정보 등록: 키를 발급받아 빌더에 넣고 시험 호출로 응답을 확인합니다.
필드 대응: 보내는 쪽 항목과 받는 쪽 항목을 짝지어 두고, 짝이 없는 항목의 기본값을 정합니다.
값 변환: 날짜 형식, 금액 단위, 코드 체계처럼 표기 규칙이 다른 항목을 변환 규칙으로 적습니다.
실패 처리: 응답이 없거나 오류가 왔을 때 다시 시도할지, 멈추고 알릴지를 정합니다.

네 덩어리 가운데 세 번째가 시간을 끄는 데는 구조적인 이유가 있습니다. 코드 체계가 서로 다른 두 시스템을 붙일 때는 변환표를 사람이 만들어야 하고, 그 표를 아는 사람은 대개 개발자가 아니라 그 업무를 매일 하는 담당자니까요.

변환에서 자주 걸리는 자리도 대체로 정해져 있습니다. 거래처 코드가 양쪽에서 다르게 매겨져 있거나, 한쪽은 부가세를 포함한 금액을 주는데 다른 쪽은 공급가로 받거나, 한쪽의 필수 항목이 다른 쪽에서는 아예 존재하지 않는 경우입니다. 이런 항목은 시험 호출 한 번으로는 드러나지 않고, 며칠치 실제 자료를 흘려 보내야 어긋난 값이 눈에 띕니다. 그래서 첫 대상에서는 실행을 며칠 지켜보는 기간을 일정에 넣어 두는 편이 안전합니다.

네 번째를 건너뛰면 그날은 빨리 끝납니다. 대신 몇 주 뒤에 아무도 모르게 실행이 멎어 있는 상태를 발견하게 되죠. 실패 처리 규칙은 만드는 자리에서는 군더더기처럼 보이고, 없을 때에야 값이 드러납니다.

첫째 구간의 좋은 점은 이 네 덩어리가 대상마다 거의 같다는 것입니다. 두 번째 시스템을 붙일 때는 첫 번째에서 만든 변환 규칙과 실패 처리 방식을 그대로 가져다 쓸 수 있어서, 대상이 늘어도 작업량은 완만하게만 올라갑니다.

둘째 구간의 대기는 왜 며칠이 아니라 주 단위인가?

담당자가 늦게 답해서가 아니라, 계정을 내주기 전에 문서가 먼저 필요한 구조여서입니다. 요청을 받은 쪽은 무엇이 어디로 나가는지 적힌 서면 없이는 승인 자체를 할 수 없는 경우가 많습니다.

특히 사내 데이터를 외부 서비스로 내보내는 연결이 그렇습니다. 개인정보가 포함된 업무를 외부에 맡길 때는 목적 외 처리 금지와 기술적·관리적 보호조치 같은 사항을 담은 문서로 계약하도록 「개인정보 보호법」 제26조 제1항이 정하고 있고, 시행령 제28조 제1항이 그 문서에 들어갈 항목을 따로 열거합니다.

적용 여부는 다루는 데이터의 성격과 서비스 형태에 따라 갈립니다. 우리 파이프라인이 여기 해당하는지는 법무나 개인정보 담당과 확인할 자리이고, 그 확인 자체도 일정에 들어가는 항목입니다.

해당한다면 순서가 정해집니다. 계정 요청이 먼저가 아니라 문서 준비가 먼저이고, 문서에는 어떤 항목이 어느 서비스로 얼마나 자주 나가는지가 적혀야 합니다. 그런데 그 내용은 파이프라인을 설계해 봐야 알 수 있어서, 설계를 마친 뒤에 요청하고 승인을 기다리는 흐름이 만들어집니다.

승인 경로가 여럿이면 대기가 겹치지 않고 이어집니다. 보안 검토를 통과한 뒤 계정 발급 요청이 접수되고, 그 뒤에 권한 범위 조정이 따라오는 식이죠. 각 단계가 이틀씩만 걸려도 한 주가 지나갑니다.

요청서에 무엇을 적느냐가 왕복 횟수를 정합니다. 승인하는 쪽이 되묻는 항목은 대개 같아서, 처음부터 채워 보내면 한두 번의 왕복이 사라집니다.

어떤 항목이 나가는가: 필드 이름을 나열하고 개인 식별 정보가 포함되는지 표시합니다.
어디로 가는가: 받는 서비스의 이름과 데이터가 저장되는 위치를 적습니다.
얼마나 자주 가는가: 실시간인지 하루 몇 회인지, 한 번에 몇 건인지 적습니다.
무엇을 할 수 있는 권한인가: 읽기만인지 쓰기까지인지, 대상 범위를 어디로 제한할지 적습니다.

네 항목 가운데 승인 속도를 크게 바꾸는 것은 마지막입니다. 전체 권한을 요청하면 검토가 길어지고, 필요한 범위만 지정해 요청하면 확인할 것이 줄어드니까요. 우리 쪽에서 범위를 좁혀 적는 일이 상대의 심사 시간을 줄이는 방법이기도 합니다.

보안 쪽에서 무엇을 물어볼지 미리 알고 준비하면 이 구간이 짧아집니다. 감사 자리에서 실제로 나오는 질문 목록은 보안 감사에서 지적받기 전 점검할 항목에 따로 정리해 두었습니다.

한 가지는 미리 알아 두는 편이 낫습니다. 이 구간의 대기는 우리가 서두른다고 줄어들지 않습니다. 줄일 수 있는 것은 대기 자체가 아니라 대기가 시작되는 시점입니다.

일정은 연동 개수가 아니라 무엇의 개수로 뛰나?

열쇠를 쥔 조직의 개수만큼 뜁니다. 같은 곳에서 계정을 받는 시스템 셋은 승인 절차를 한 번만 통과하면 되고, 서로 다른 곳에서 받는 시스템 셋은 절차를 세 번 통과해야 합니다.

가상 예시로 견줘 보겠습니다. 실제 고객사 자료가 아니라 설명을 위해 지어낸 목록입니다.

구성	연결 대상과 열쇠를 쥔 곳	시스템 수	넘어야 할 벽
가상 예시 A	그룹웨어·전자결재·사내 위키(모두 정보전략팀)	3	1
가상 예시 B	그룹웨어(정보전략팀)·물류 시스템(협력사)·회계 서비스(본사 재무)	3	3

숫자만 보면 두 구성은 같은 규모입니다. 그런데 A는 승인 한 번을 받고 나면 나머지는 첫째 구간과 비슷하게 흘러가고, B는 서로 다른 세 조직의 일정에 각각 걸립니다.

여기서 견적과 일정의 통념이 하나 무너집니다. 연동 대상 다섯 개짜리 과업과 열 개짜리 과업 가운데 어느 쪽이 오래 걸리는지는 개수만으로 답이 나오지 않습니다. 다섯 개가 세 조직에 흩어져 있고 열 개가 한 조직 안에 있다면, 뒤쪽이 먼저 끝납니다.

그래서 목록을 만든 다음 할 일은 개수를 세는 것이 아니라 발급처로 묶는 것입니다. 묶고 나면 몇 개의 마디로 이뤄진 일인지가 보이고, 그 마디가 곧 일정표의 칸이 됩니다.

묶어 두면 견적을 받을 때 물을 문장도 달라집니다. 이 다섯 개를 붙이는 데 얼마가 드는지 묻는 대신, 승인 절차가 필요한 대상이 몇 곳에 걸려 있고 그 대기 기간을 일정에 어떻게 반영했는지를 물을 수 있죠. 앞의 질문에는 어느 업체든 비슷한 답이 오지만, 뒤의 질문에는 우리 환경을 실제로 살펴본 곳과 그렇지 않은 곳의 답이 다르게 옵니다.

발급처를 세다 보면 우리 쪽 준비 상태도 함께 드러납니다. 열쇠를 쥔 곳이 셋인데 그중 두 곳과는 평소에 연락할 창구조차 정해져 있지 않다면, 그것은 파이프라인 이전에 정리할 일이 남아 있다는 뜻입니다.

셋째 구간의 목표는 자동화율이 아니다

접속할 창구가 없는 시스템에서 사람을 완전히 걷어내려 하면 대개 더 비싼 방법으로 돌아갑니다. 화면을 흉내 내는 방식으로 붙일 수는 있지만 화면이 바뀔 때마다 멈추고, 그 유지 부담이 사람이 하던 일보다 커지는 지점이 있습니다.

이 구간에서 세울 목표는 다릅니다. 사람이 손대는 지점을 없애는 것이 아니라, 흩어진 지점을 한 곳으로 모으는 것입니다.

모으는 방법은 대체로 셋입니다.

입구를 하나로: 시스템마다 흩어진 입력을 양식 하나로 받아 그 뒤를 자동으로 흘려보냅니다.
시점을 하나로: 수시로 하던 확인을 하루 한 번 정해진 시각의 검토 목록으로 바꿉니다.
판단만 남기기: 자료를 모으고 정리하는 부분은 자동으로 처리하고, 사람에게는 승인 여부만 묻습니다.

셋 다 자동화율을 올리지는 않습니다. 대신 사람이 붙잡혀 있는 시간의 성격을 바꿉니다. 하루에 여덟 번 흐름이 끊기던 것이 한 번의 검토 시간으로 바뀌면, 같은 분량을 처리해도 체감이 달라지죠.

어떤 업무가 이 구간에 남는지는 두 가지로 판별됩니다. 상대 시스템이 외부 접속을 아예 열지 않는 경우, 그리고 규정이나 계약이 사람의 확인을 거치도록 정해 둔 경우입니다. 앞쪽은 상대가 바뀌면 해소되지만 뒤쪽은 시간이 지나도 그대로 남습니다.

뒤쪽을 앞쪽으로 착각해서 생기는 낭비가 적지 않습니다. 결재나 검수처럼 사람의 판단이 요건인 자리를 기술 문제로 보고 자동화 방법을 찾다 보면, 결국 원래 자리로 돌아오면서 그 사이의 시간만 사라지니까요.

셋째 구간을 이렇게 설계해 두면 나중에 그 시스템이 접속 창구를 열었을 때 옮기기도 쉽습니다. 사람이 손대는 지점이 한 곳에 모여 있으니, 그 한 곳만 자동 처리로 바꾸면 되니까요.

커넥터 목록은 어디까지 답해 주나?

우리가 만든 윈디플로는 SAP·세일즈포스·오라클을 비롯한 500개 이상의 커넥터를 갖추고 있고, 배포 위치도 클라우드·온프레미스·하이브리드 가운데 고를 수 있습니다. 다만 그 목록이 답해 주는 범위는 첫째 구간의 후보까지입니다.

커넥터가 있다는 것은 그 시스템과 주고받는 방법이 이미 만들어져 있다는 뜻이지, 우리 회사에서 그 계정을 발급받을 수 있다는 뜻이 아닙니다. 목록에 이름이 있어도 열쇠가 본사에 있으면 그 대상은 둘째 구간에 남습니다.

어느 빌더를 검토하든 커넥터 수는 같은 방식으로 읽는 편이 좋습니다. 목록에 없는 시스템은 확실히 손이 더 가고, 목록에 있는 시스템은 손이 덜 갈 가능성이 생길 뿐입니다. 가능성이 사실이 되는지는 우리 쪽 조건이 정합니다.

목록 대신 확인할 값은 따로 있습니다. 우리가 실제로 붙일 대상 다섯 개를 골라 그 다섯 개가 각각 어느 구간에 들어가는지 세어 보는 것이죠. 커넥터 500개보다 그 다섯 개의 구간 분포가 일정을 훨씬 정확하게 알려 줍니다.

한국어 화면이나 국내 서비스 지원 여부도 같은 자리에서 읽는 편이 좋습니다. 화면 언어는 담당자가 익히는 속도를 바꾸고, 국내 전자결재나 세무 서비스처럼 해외 도구가 다루지 않는 대상은 커넥터 유무가 곧 구간 배정을 바꿉니다. 다만 이것도 목록 대조로 끝나는 값이라, 우리 대상 다섯 개 안에 그런 시스템이 몇 개나 있는지를 먼저 세는 순서가 맞습니다.

구간표를 착수 순서로 바꾸면 어떻게 되나?

승인 대기가 달력에서 흐르는 동안 다른 일을 할 수 있도록, 요청은 첫날 보내고 작업은 첫째 구간부터 시작합니다. 이 두 가지가 겹쳐 돌아가는 것이 순서의 전부입니다.

업무 흐름에서 데이터가 지나는 자리를 적습니다. 시스템 이름이 아니라 어떤 값이 어디서 어디로 가야 하는지를 먼저 적어야 목록이 정확해집니다.
대상마다 계정을 발급할 수 있는 사람의 소속을 적습니다. 모르는 칸은 비워 두고, 비워 둔 칸은 그 자체로 확인할 일이 됩니다.
발급처로 묶어 넘어야 할 벽의 개수를 셉니다. 이 숫자가 일정의 마디이고, 시스템 개수는 마디 안의 분량입니다.
둘째 구간의 요청을 같은 날 전부 보냅니다. 용도와 범위, 주고받을 항목을 적은 문서를 함께 넣으면 되묻는 왕복이 줄어듭니다.
첫째 구간부터 만듭니다. 변환 규칙과 실패 처리 방식을 첫 대상에서 정해 두면 나머지가 그 규칙을 물려받습니다.
셋째 구간은 마지막에 설계합니다. 앞 두 구간이 자동으로 흐르는 상태를 본 다음이라야, 사람이 남을 자리를 어디로 모을지 판단이 섭니다.

순서에서 뒤집으면 손해가 큰 것은 네 번째입니다. 첫째 구간을 다 만들고 나서 요청을 보내면, 만드는 시간과 기다리는 시간이 겹치지 않고 이어 붙습니다. 같은 일을 하고도 완성이 몇 주 뒤로 밀리는 경우가 대개 여기서 나옵니다.

여섯 번째를 앞당기고 싶은 마음도 자주 생깁니다. 손이 많이 가는 업무일수록 먼저 손대고 싶어지니까요. 그런데 셋째 구간의 설계는 앞 구간의 결과에 따라 달라져서, 먼저 만들어 두면 대개 다시 만들게 됩니다.

첫 번째 단계를 대충 넘기면 나머지가 함께 흔들린다는 점도 적어 둘 만합니다. 시스템 이름으로 목록을 만들면 「그룹웨어 연동」 한 줄이 되지만, 값으로 적으면 「결재 완료된 지출 건의 금액과 계정과목을 회계 쪽으로」가 되어 필요한 권한의 범위가 그 자리에서 정해집니다. 앞 줄로는 어느 구간인지 판정할 수 없고 뒤 줄로는 판정이 됩니다. 요청 문서에 적을 항목도 뒤 줄에서 그대로 나옵니다.

견적서의 항목과 구간표를 맞춰 보면 무엇이 보이나?

셋째 구간에 넣은 대상이 견적서에서 어느 항목으로 잡혀 있는지가 보입니다. 대조에 쓸 공통 문서는 업계에 이미 나와 있어서, 우리 구간표를 그 옆에 놓기만 하면 됩니다.

문서 이름은 「SW사업 대가산정 가이드」이고, 2025년 개정판을 펴낸 곳은 한국인공지능·소프트웨어산업협회입니다. 여기서 구현 단계의 값은 기능점수로 잡고, 운영 단계의 값은 요율이나 투입공수라는 다른 자로 잽니다. 기획 단계에도 별도의 산정 방식이 붙어 있고요. 만드는 값과 계속 붙잡고 있는 값이 한 칸에 섞이지 않도록 처음부터 나뉘어 있는 셈입니다.

구간표를 이 구분 옆에 놓으면 확인할 자리가 생깁니다. 셋째 구간에 들어간 대상이 견적서에는 구현 항목으로만 잡혀 있다면, 매달 드는 사람 시간이 어느 항목에도 계상되지 않았다는 뜻입니다.

물어볼 문장도 짧아집니다. 이 대상은 완전 자동인지, 사람이 몇 번 개입하는 설계인지, 개입이 있다면 그 시간이 어느 항목에 들어가 있는지. 셋을 물으면 견적서와 실제 설계가 어긋나 있는지가 드러납니다.

절감액을 숫자로 세우는 일은 이 대조와 다른 작업입니다. 인건비 기준으로 효과를 계산하는 방법과 그 계산에서 자주 빠지는 항목은 ERP 연동 자동화의 절감액 산정 모델에서 따로 다뤘습니다.

쓰던 도구에서 옮길 때 무엇이 그대로 오고 무엇이 안 오나?

업무 규칙은 옮겨 오고 연결 설정은 다시 만듭니다. 어느 조건에서 무엇을 하는지를 정해 둔 부분은 도구가 달라져도 그대로 쓸 수 있지만, 인증과 필드 대응은 빌더마다 구현이 달라 새로 잡아야 합니다.

옮기기 전에 챙겨 둘 것이 셋 있습니다.

흐름도: 각 자동화가 어떤 조건에서 시작해 무엇을 거쳐 어디서 끝나는지 한 장으로 그려 둡니다.
변환표: 코드 체계나 날짜 형식을 맞추려고 만든 대응 규칙은 도구와 무관한 자산이라 그대로 옮겨집니다.
실패 이력: 지난 몇 달 동안 어디서 몇 번 멈췄는지가 새 도구에서 실패 처리를 설계할 때의 재료가 됩니다.

셋 가운데 실패 이력은 챙기지 않고 넘어가기 쉬운데, 값은 오히려 큽니다. 어느 연결이 자주 끊기는지 알고 있으면 그 대상을 첫 이관 순서에서 뒤로 미루거나 감시 규칙을 더 촘촘히 걸 수 있으니까요.

옮기는 순서도 구간표를 따릅니다. 첫째 구간의 자동화부터 새 도구에서 다시 만들어 양쪽이 같은 결과를 내는지 확인한 다음, 둘째 구간으로 넘어갑니다. 인증 정보를 새로 발급받아야 하는 대상이 섞여 있으면 그 요청도 첫날에 보냅니다.

한동안 두 도구를 함께 쓰는 기간이 생기는 것은 정상입니다. 그 기간을 없애려고 한꺼번에 옮기면, 어느 쪽에서 무엇이 돌고 있는지 아무도 모르는 며칠이 생깁니다.

겹치는 기간에는 옛 도구 쪽을 먼저 멈추지 않는 편이 안전합니다. 새 쪽에서 같은 결과가 나오는 것을 며칠 확인한 뒤에 옛 쪽을 끄면, 어긋난 값이 나왔을 때 비교할 대상이 남아 있으니까요.

옮기는 김에 정리할 것도 하나 생깁니다. 몇 년 쓰다 보면 아무도 쓰지 않는 자동화가 목록에 섞여 있는데, 그 판별은 실행 이력을 열어 보면 바로 끝납니다.

만들어 둔 파이프라인은 어디에서 먼저 무너지나

권한이 만료되는 날 멈춥니다. 발급받은 키에 유효 기간이 걸려 있거나, 계정을 만들어 준 담당자가 부서를 옮기면서 그 계정이 정리되는 경우죠.

무너지는 자리는 대체로 넷입니다.

인증 만료: 키가 기간을 다해 응답이 거부됩니다. 대개 조용히 멈추고, 며칠 뒤 결과물이 없는 것으로 발견됩니다.
화면 변경: 셋째 구간에서 화면을 읽어 오던 부분이 개편 한 번에 어긋납니다.
항목 추가: 상대 시스템에 필드가 하나 늘면서 값이 밀려 들어갑니다.
사람 교체: 실패 알림을 받던 담당자가 바뀌었는데 수신자 목록은 그대로입니다.

넷 다 만든 직후에는 나타나지 않고 몇 달 뒤에 나타납니다. 그래서 완성 시점에 해 둘 일은 감시 설정이 아니라 만료일과 수신자를 적어 두는 일에 가깝습니다.

키의 만료일을 달력에 걸어 두고, 실패 알림을 받는 사람을 개인이 아니라 팀 주소로 걸어 두면 넷 중 둘이 줄어듭니다. 나머지 둘은 발견을 빨리 하는 쪽으로 대비하는 편이 현실적입니다.

발견을 앞당기는 값싼 방법은 성공 신호를 함께 보게 하는 것입니다. 실패했을 때만 알림이 오는 구성에서는 아예 실행되지 않은 상태가 조용한 정상으로 읽히거든요. 하루 한 줄이라도 몇 건이 처리됐는지 남겨 두면, 그 줄이 며칠 비어 있는 것으로 멈춤이 드러납니다.

만들고 난 뒤 무엇을 언제부터 지켜볼지는 도입 성과를 시점별로 나눠 보는 방법에 시점 단위로 정리되어 있습니다.

세 구간 가운데 우리를 멈추게 하는 곳은 어디인가?

목록을 채워 보면 대개 한 구간에 몰려 있습니다. 몰린 곳이 어디냐에 따라 다음에 할 일이 달라지죠.

첫째 구간에 몰려 있다면 남은 것은 실행뿐이라 도구 선택이 실제로 의미가 있습니다. 둘째 구간이라면 순서가 앞으로 당겨집니다. 도구 비교보다 승인 경로 확인과 요청 문서 준비가 먼저이고, 그 둘이 끝나야 나머지가 굴러가니까요.

셋째 구간에 몰려 있는 경우에는 자동화 대상 자체를 다시 골라 보시는 편이 빠를 수 있습니다. 손이 많이 가는 업무가 눈에 먼저 띄어 목록에 올랐을 뿐, 같은 흐름 안에 첫째 구간으로 처리되는 조각이 함께 있는 경우가 있습니다.

저는 파일럿 범위를 정할 때 첫째 구간에서만 고르자고 제안하는 편입니다. 검증하려는 것이 빌더가 우리 업무를 감당하는지인데, 둘째 구간을 끼워 넣으면 승인 대기 때문에 그 판단이 몇 주 뒤로 밀리기 때문입니다. 도구의 성능과 조직의 절차를 한 번에 시험하면 결과가 나왔을 때 어느 쪽 때문인지 갈라내기 어려워집니다.

구간표는 시스템 목록과 발급처만 있으면 한 시간 안에 채워집니다. 채워 둔 목록을 무료 상담에 남겨 주시면, 어느 구간부터 손대는 편이 빠른지 그 목록을 놓고 같이 읽어 보겠습니다.

자주 묻는 질문

노코드로 만든 자동화를 나중에 개발팀이 이어받을 수 있나요?

이어받는 대상이 무엇인지에 따라 갈립니다. 업무 규칙과 변환표는 어떤 형태로든 문서화되어 있어 그대로 넘길 수 있지만, 빌더 안에서 화면으로 구성한 흐름은 코드로 자동 변환되지 않는 경우가 많습니다. 이관 가능성을 미리 재고 싶다면 설정을 파일 형태로 내보낼 수 있는지, 내보낸 파일을 우리가 읽을 수 있는지를 도구 선택 시점에 확인해 두면 됩니다.

사내 시스템에 접속 창구가 아예 없으면 화면을 읽는 방식으로 붙이면 되나요?

가능한 방법이지만 유지 부담을 함께 계산해야 합니다. 화면 구성이 바뀔 때마다 다시 손봐야 하므로, 그 시스템이 얼마나 자주 개편되는지가 판단의 기준이 됩니다. 연 단위로 안정적인 화면이라면 쓸 만하고, 분기마다 바뀌는 화면이라면 사람이 하던 방식을 유지하면서 앞뒤만 자동화하는 편이 결과적으로 손이 덜 갑니다.

연동 계정을 담당자 개인 계정으로 발급받아 쓰면 안 되나요?

당장은 돌아가지만 그 담당자가 휴직하거나 퇴사하면 파이프라인이 함께 멈춥니다. 감사 자리에서도 누가 무슨 권한으로 접속했는지 구분되지 않아 지적 대상이 되기 쉽죠. 발급 요청 단계에서 조금 더 걸리더라도 업무용 계정을 따로 받아 두면, 담당 교체 때 인수인계 항목이 하나 줄어듭니다.

시험은 실제 운영 시스템에서 해도 되나요?

읽기만 하는 연결이라면 대개 괜찮지만, 값을 쓰는 연결은 시험 환경을 따로 두는 편이 안전합니다. 시험 환경이 없는 시스템이라면 실행 조건에 특정 표시가 붙은 자료만 처리하도록 제한을 걸고 시작하는 방법이 있습니다. 첫 며칠은 자동 실행 대신 사람이 결과를 확인하고 승인하는 단계를 끼워 두었다가, 결과가 안정되면 그 단계를 걷어내면 됩니다.

구간표는 한 번 그리면 계속 쓸 수 있나요?

열쇠의 소재가 바뀌면 다시 그려야 합니다. 사내 시스템을 외부 서비스로 옮기거나, 계열사 통합으로 계정 관리 주체가 바뀌거나, 유지보수 업체가 교체되는 일이 생기면 같은 시스템의 구간이 이동하죠. 큰 조직 변화가 있을 때 목록을 한 번 훑어보는 정도면 충분하고, 그때 이미 만들어 둔 파이프라인의 인증 정보도 같이 점검하면 두 가지 일이 한 번에 끝납니다.

여러 부서의 시스템을 하나의 파이프라인에 묶어도 되나요?

묶는 것 자체는 문제가 없지만 멈췄을 때의 연락처가 여러 곳이 됩니다. 부서마다 승인 주체와 담당자가 다르므로, 하나가 끊기면 어디에 물어야 하는지부터 찾게 되죠. 부서 경계를 넘는 흐름이라면 중간에 한 번 끊어 두 개의 자동화로 나누고, 그 사이에 결과를 확인하는 지점을 두는 구성이 운영하기 수월합니다.

참고 자료

「SW사업 대가산정 가이드」 2025년 개정판 — 발행 한국인공지능·소프트웨어산업협회(KOSA), 2025년 8월 11일 게시. 구현 단계는 기능점수, 운영 단계는 요율·투입공수, 기획 단계는 컨설팅 업무량·투입공수 등으로 단계마다 대가산정 방법을 달리 정함(2026-08-27 확인): https://www.sw.or.kr/site/sw/ex/board/List.do?cbIdx=276
「개인정보 보호법」 제26조 제1항 — 개인정보 처리를 다른 곳에 맡길 때 지킬 사항(목적 외 처리 금지, 기술적·관리적 보호조치 등)을 담아 문서로 계약하도록 규정한 조항(2026-08-27 확인): https://www.law.go.kr/법령/개인정보보호법
「개인정보 보호법 시행령」 제28조 제1항 — 위탁 계약 문서에 포함할 사항의 열거 규정(2026-08-27 확인): https://www.law.go.kr/법령/개인정보보호법시행령
안효준(하마다랩스 윈디플로 프로덕트 매니저), 노코드 자동화 구축·파일럿 범위 산정 단계 관찰 — 자사 1차 자료(2026년 기준, 익명 관찰). 서술 범위: ① 연동 대상 목록에 계정 발급 주체를 적어 넣기 전과 후에 예상 난이도의 순서가 바뀌는 경향 ② 승인 요청 시점을 착수일로 당겼을 때와 구축 완료 후로 미뤘을 때 완성 시점이 갈리는 지점 ③ 파일럿 범위에 승인 대기가 필요한 대상이 섞였을 때 판단이 지연되는 양상 — 특정 고객사·특정 경쟁사 사례가 아니며 건수나 기간의 집계가 아님
하마다랩스 윈디플로 플랫폼 소개(SAP·세일즈포스·오라클 등 500개 이상 커넥터, 클라우드·온프레미스·하이브리드 배포): https://www.hamadalabs.com/platform
하마다랩스 AI 에이전트 구축 서비스 소개: https://www.hamadalabs.com/service/ai-agent

작성자

안효준 — 하마다랩스 윈디플로 프로덕트 매니저. 노코드 빌더와 구축형 솔루션을 하나의 잣대로 비교하는 일을 담당하며, 소규모 파일럿으로 본도입 여부를 가늠하는 절차, 그리고 도입한 뒤에 무엇을 지켜볼지를 다룹니다. 회사 소개: https://www.hamadalabs.com/