AI 워크플로우 확장의 순서를 정하는 것은 데이터 흐름입니다. 다음 업무가 앞의 업무와 원천 시스템·데이터 형식·결재 경로·실패 방식 가운데 몇 칸을 공유하는지 세어 보면, 그 업무를 얹는 데 무엇을 다시 만들어야 하는지가 먼저 잡힙니다.

두 번째 업무의 견적서가 도착하면 총액부터 보게 됩니다. 첫 업무 때와 크기가 비슷하면 그 자리에서 손이 멈추죠.

첫 업무의 지표는 그사이 좋게 나오고 있습니다. 걸리던 시간이 줄었고 사람 손으로 되돌아가는 일도 눈에 띄게 내려갔는데, 그 숫자들 가운데 어느 것도 두 번째가 왜 싸지지 않는지는 말해 주지 않습니다.

확장이 잘 되고 있는지를 재는 값이 그 지표들 사이에 빠져 있기 때문입니다.

그 값은 걸음마다 무엇을 다시 만들었는가입니다. 다음 분기 안건의 순서를 정하는 자리에서 함께 결정되는 값이기도 하죠.

순서를 정할 때 손에 잡히는 것은 대개 안건지 맨 위에 적힌 팀 이름입니다. 요청이 도착한 차례대로 줄이 서 있고, 그 줄이 곧 처리 차례로 읽힙니다. 조직도를 따라 내려가는 배열이라 이상하게 여기는 사람도 드뭅니다.

그 배열은 어느 쪽이 싸게 끝나는지 말해 주지 않습니다. 부서 이름에는 그 업무가 어느 시스템에서 자료를 꺼내 어떤 결재를 지나는지가 한 글자도 담기지 않고, 확장에 드는 값을 정하는 것은 바로 그 두 가지니까요.

도입 때와 사정이 달라진 점도 하나 있습니다. 첫 업무는 무엇을 고를지가 문제였는데, 두 번째부터는 앞에서 만들어 둔 것을 얼마나 물려받느냐가 문제라는 것이죠.

확장 순서를 조직도로 정하면 무엇이 어긋나나요?

다시 만들어야 하는 항목의 개수가 부서 사이의 거리와 무관하게 정해지기 때문입니다. 부서가 가깝다는 사실은 그 개수를 하나도 줄여 주지 못해서, 옆자리 팀의 업무가 다른 층 팀의 업무보다 비싸게 붙는 일이 생기죠.

첫 업무를 자동화할 때 실제로 만든 것을 펼쳐 보면 네 덩어리입니다. 업무 로직, 시스템 연결, 권한 설정, 예외 규칙. 이 가운데 업무 로직만 그 업무의 것이고 나머지 셋은 조건이 같은 다른 업무에도 그대로 쓰입니다.

셋을 물려줄 수 있는 이유는 그것들이 업무의 내용이 아니라 업무가 놓인 자리를 정의하기 때문입니다. 어느 창고에서 자료를 꺼내고, 누가 승인하고, 막혔을 때 어디로 보내는지. 이 조건이 같으면 처리하는 내용이 달라도 같은 설비 위에서 돌아갑니다.

다음 업무를 얹는 자리에서 그 셋 가운데 몇 개가 그대로 쓰이는지가 그 걸음의 값입니다. 셋이 다 쓰이면 며칠짜리 작업이고, 셋 다 새로 만들어야 하면 첫 업무와 다를 바 없는 프로젝트가 되죠.

구매팀 발주서 입력을 먼저 자동화한 회사에 후보가 둘 남았다고 해 보죠. 하나는 같은 구매팀의 계약서 검토, 다른 하나는 영업지원팀의 수주서 입력입니다. 네 칸이 어떻게 갈리는지 보이려고 조건을 골라 세운 가상의 상황입니다.

계약서 검토가 다루는 자료는 ERP 밖 문서함에 있고, 금액 구간이 달라 결재선도 따로 갑니다. 수주서 입력은 같은 ERP에서 같은 계열의 양식을 꺼내고 실패하는 방식도 발주서와 닮았죠. 조직도로는 앞의 것이 한 칸 가까운데, 다시 만들 항목은 앞의 것이 훨씬 많습니다.

두 후보를 회의 안건으로 올리면 먼저 불리기 쉬운 쪽은 계약서 검토입니다. 같은 팀이 요청했고, 담당자도 이미 첫 업무를 겪어 봤으니 자연스러운 순서로 보이죠. 그 인상이 실제 작업량과 어긋난다는 사실은 견적을 받아 본 뒤에야 드러납니다.

그 시점에는 이미 그 후보로 예산이 잡혀 있기도 합니다. 순서를 뒤집으려면 안건을 물리고 다시 올려야 해서, 비싼 쪽이 그대로 진행되는 쪽으로 기울죠.

다음 업무를 고를 때 어떤 칸을 보나요?

네 칸입니다. 자료가 나오는 곳, 자료의 모양, 결재가 지나는 경로, 처리가 실패하는 방식.

첫째 칸은 원천 시스템입니다. 같은 시스템에서 자료를 꺼내면 계정과 인증, 연결 설정이 그대로 넘어옵니다. 시스템이 바뀌면 그 세 가지가 다시 필요하고, 계정 발급에는 대개 다른 부서의 협조와 대기가 붙죠.

둘째 칸은 자료의 모양입니다. 같은 양식 계열이면 항목을 어디에 대응시킬지 이미 정해져 있고, 값이 올바른지 보는 규칙도 재사용됩니다. 양식이 다르면 대응표를 처음부터 씁니다.

셋째 칸은 결재 경로입니다. 어느 단계까지 자동으로 처리하고 어느 금액부터 사람이 승인하는지, 누구에게 알림이 가는지가 여기 걸립니다.

넷째 칸은 실패 방식입니다. 걸러진 건이 어떤 모양으로 남고 누구에게 가는지의 문제죠.

공유하는 칸	겹치면 그대로 쓰는 것	어긋나면 새로 만드는 것
자료가 나오는 곳(원천 시스템)	계정·인증·연결 설정	계정 발급 신청부터 연결 검증까지
자료의 모양(양식·필드)	항목 대응표, 값 검증 규칙	대응표 전체와 검증 규칙
결재가 지나는 경로	승인 단계, 자동 처리 한도, 알림 대상	한도 합의와 알림 설정
처리가 실패하는 방식	예외 분류, 수신자와 시한	예외 목록과 처리 규칙

네 칸이 서로 독립인 것은 아닙니다. 원천이 같으면 양식도 대체로 같은 계열이라, 실제로는 위 칸이 어긋나면 아래 칸도 함께 어긋나는 쪽으로 무너집니다.

칸을 재는 일은 자료 조사가 아니라 질문 네 개입니다. 이 업무의 자료는 어느 화면에서 나오는지, 그 화면의 양식이 앞 업무와 같은 계열인지, 승인이 어디까지 올라가는지, 처리가 막히면 지금은 누가 받는지. 현업 담당자에게 물으면 대개 그 자리에서 답이 나옵니다.

즉시 답이 나오지 않는 칸도 하나의 정보입니다. 승인이 어디까지 올라가는지 담당자도 모르는 업무라면 셋째 칸은 겹침이 아니라 미확인으로 표시하고, 확인할 사람의 이름을 옆에 적어 둡니다. 겹친다고 가정한 칸이 나중에 어긋나면 일정이 그만큼 밀리니까요.

후보를 세울 때 한 가지는 미리 추려 내는 편이 좋습니다. 처리 규칙이 완전히 고정돼 있고 판단이 끼어들 여지가 없는 일이라면 에이전트가 아니라 다른 도구가 맞는 자리일 수 있어서, 네 칸을 재기 전에 그 구분부터 해 두면 목록이 짧아집니다.

부서가 같으면 이 칸들도 함께 겹치지 않나요?

겹치는 것은 대개 한 칸뿐이고, 그 한 칸조차 온전하지 않습니다. 같은 부서라는 사실이 확실히 말해 주는 것은 사람이 서로 아는 사이라는 정도죠.

결재 경로부터 보죠. 승인 단계를 가르는 것은 팀 경계가 아니라 금액 구간과 거래 유형이라, 한 팀 안에서도 결재선이 갈라집니다. 소액 반복 발주는 팀장 선에서 닫히는데 연간 계약은 임원까지 올라가는 식이죠. 부서가 같다는 이유로 셋째 칸을 겹친 것으로 세면 나중에 한도 합의를 다시 하게 됩니다.

원천 시스템은 더 어긋납니다. 한 팀이 하루에 여는 화면을 세어 보면 ERP와 문서함과 메일함이 나란히 나오고, 업무마다 주로 쓰는 곳이 다릅니다. 부서는 사람의 소속이지 자료의 소재가 아니니까요.

그러면 부서가 같아서 얻는 것은 무엇일까요. 사람의 익숙함입니다. 앞 업무에서 화면을 써 본 담당자가 있으면 교육에 드는 시간이 줄고, 예외가 났을 때 설명이 짧아지죠.

익숙함과 재제작은 다른 값입니다. 익숙함은 교육에 드는 시간을 줄이고, 재제작 항목은 구축에 드는 시간을 정합니다. 두 값을 한 항목으로 묶어 놓으면 확장 예산이 걸음마다 어긋나죠.

그래서 부서는 후보를 모으는 데는 쓰되 순서를 정하는 데는 쓰지 않습니다. 요청을 받는 창구는 조직도를 따라 열어 두고, 순서를 매기는 자리에서만 네 칸으로 바꿔 읽는 것이죠.

한 가지 예외는 있습니다. 자료를 반출할 수 없어 부서 밖으로 내보내지 못하는 업무라면 그 제약이 첫째 칸에 그대로 반영됩니다. 이때 걸리는 것은 부서라는 소속이 아니라 그 자료에 붙은 반출 조건이고요.

확장할 때마다 다시 만들어지는 것은 무엇인가요?

연결과 권한, 예외 규칙 셋입니다. 업무 로직은 새 업무마다 새로 짜는 것이 당연하니 재제작으로 세지 않습니다.

이 셋만 세는 이유는 첫 업무에서 이미 값을 치른 항목이기 때문입니다. 같은 성격의 일을 두 번째로 하면서 같은 값을 다시 지불하는 자리이고, 그 지불이 걸음마다 반복되면 확장이라는 말이 무색해지죠.

셋 가운데 예외 규칙만 자라는 시점이 다릅니다. 연결과 권한은 구축하는 동안 크기가 정해지는데, 예외 목록은 운영이 시작된 뒤에 붙거든요. 새 업무를 얹을 때는 예외가 서너 개로 보이다가 운영이 두어 달 쌓이면 목록이 길어지고, 견적서에는 한 줄로 적혔던 것이 운영 부담으로 청구되는 항목이죠.

확장 안건지에는 업무 이름과 예상 금액, 착수 시기가 적힙니다. 제가 결재 자리에 앉아 보면 그 세 줄에서 손이 멈추더군요. 같은 금액이 첫 도입의 반복일 수도 있고 앞의 자산 위에 얹는 걸음일 수도 있는데, 안건지에는 그 둘을 가르는 줄이 없습니다. 그래서 여백에 한 줄을 손으로 적어 넣게 되죠. 이 업무가 앞의 것과 어느 칸을 공유하는지를 적는 줄입니다.

첫 업무를 만들 때 무엇을 미리 떼어 놓나요?

물려줄 셋을 업무 로직과 섞어 만들지 않도록 발주 조건에 적어 두는 일입니다. 기술 설계의 문제로 보이지만 실제로는 요구서를 쓰는 자리에서 결정됩니다.

한 업무만 놓고 만들면 셋을 섞어 만드는 편이 빠릅니다. 발주서 처리에만 쓰일 연결이라면 발주서 화면에 맞춰 붙이는 것이 손이 덜 가니까요. 두 번째 업무를 생각하지 않는다면 그 선택에 잘못은 없습니다.

문제는 두 번째가 왔을 때 드러납니다. 같은 시스템을 쓰는데도 연결을 다시 만들게 되고, 견적서에는 그것이 신규 항목으로 적히죠. 첫 업무에서 아낀 며칠이 두 번째 업무에서 몇 주로 돌아오는 셈입니다.

요구서에 넣을 문장은 길지 않습니다. 이 연결과 권한 설정, 예외 처리 규칙을 다음 업무에서 재사용할 수 있는 형태로 남겨 달라는 조건 한 줄이면 됩니다. 무엇이 재사용 가능한 형태인지는 공급사가 답할 몫이고, 발주하는 쪽은 그 답을 산출물 목록에서 확인하면 되죠.

예외 수신자를 사람 이름이 아니라 역할로 적어 두는 것도 같은 성격의 준비입니다. 담당자가 바뀌거나 부서가 늘 때 이름으로 적힌 규칙은 전부 손봐야 하지만, 역할로 적힌 규칙은 배정만 바꾸면 됩니다.

이미 첫 업무를 만들어 둔 회사라면 지금이라도 산출물 목록을 받아 보실 수 있습니다. 연결 설정과 권한, 예외 규칙이 각각 어디에 어떤 형태로 남아 있는지 물으면 되고, 답이 화면 이름으로만 돌아온다면 그 셋은 아직 업무에 붙어 있는 상태로 보시면 됩니다.

걸음의 순서는 무엇이 정하나요?

새로 깨는 칸이 뒤따르는 업무들에게 얼마나 넓게 물려지는가가 정합니다. 한 번 만든 것을 여러 업무가 나눠 쓰면 그 걸음의 값은 뒤에서 회수되고, 그 업무 하나로 끝나면 회수되지 않죠.

새로 깨는 칸	새로 만드는 일의 성격	뒤 업무들이 물려받는 폭
원천 시스템	계정 발급·인증·연결 검증. 다른 부서 협조와 대기가 붙는다	그 시스템을 쓰는 모든 업무
자료의 모양	항목 대응표 작성, 값 검증 규칙 세우기	같은 양식 계열의 업무들
결재 경로	자동 처리 한도 합의, 알림 대상 지정	같은 결재 구간의 업무들
실패 방식	예외 분류와 수신자·시한 정하기	대체로 그 업무 하나

아래로 갈수록 폭이 좁아집니다. 첫 걸음의 순서를 두고 고민할 값어치가 있는 것은 위 두 칸이고, 아래 두 칸은 그 시점에 후보를 가르지 못하죠. 셋째 칸은 같은 결재 구간의 업무들에게 물려지긴 하지만 그 구간이 열리는 것은 걸음이 몇 번 쌓인 뒤이고, 넷째 칸은 대체로 업무마다 새로 만듭니다.

여기서 나오는 답은 단순합니다.

폭이 넓은 칸을 먼저 깨 두면 그 뒤의 업무들이 전부 그 위에 서고, 좁은 칸부터 깨면 넓은 칸은 나중에 그대로 남아 있어 아무것도 물려주지 못합니다.

그러면 가장 넓은 칸부터 깨야 하나요?

총량으로는 그렇고 결재로는 그렇지 않습니다. 반대쪽에서 한 번 따져 보면 앞의 답이 그대로 서 있기 어렵다는 것이 보입니다.

폭이 가장 넓은 칸은 새 시스템을 뚫는 일인데, 그것이 확장의 첫 걸음이 되면 첫 걸음이 가장 비싸고 가장 오래 걸립니다. 계정 발급 하나에 몇 주가 붙는 회사도 있죠. 두 번째 확장의 승인 조건은 첫 확장의 성적인데, 첫 걸음이 길어지면 그 성적이 늦게 나옵니다.

그래서 판정을 이렇게 좁힙니다.

순서를 한 걸음 단위로 정하면 두 답이 부딪히고, 두 걸음을 짝으로 묶어 정하면 부딪히지 않습니다.

첫 걸음은 네 칸을 최대한 공유하는 업무로 둡니다. 다시 만들 것이 적으니 빨리 끝나고, 그 결과가 두 번째 예산의 근거가 되죠. 두 번째 걸음에서 폭이 넓은 칸을 깹니다. 첫 걸음이 벌어 준 시간과 신뢰가 그 비용을 감당하는 자리에 놓입니다.

한 가지가 더 따라옵니다. 첫 걸음의 후보를 단독으로 평가하지 않는다는 것이죠. 재제작이 적은 후보가 둘이라면 그중 두 번째 걸음이 그 위에 올라설 수 있는 쪽을 고릅니다. 확장 안건을 한 건이 아니라 두 건 묶음으로 올리는 근거가 그것입니다.

앞의 가상 예시를 이어 보면 짝이 어떻게 잡히는지 보입니다. 수주서 입력은 네 칸 가운데 셋이 발주서와 겹치는데, 셋째 칸에서는 그 자리에서 답이 나오지 않았다고 해 보죠.

영업지원팀의 승인 한도를 아는 사람이 회의실에 없었던 것인데, 그럴 때는 겹침으로 세지 않고 미확인으로 적은 뒤 확인해 줄 팀장의 이름을 옆에 붙입니다. 겹치는 칸 셋에 미확인 한 칸이면 첫 걸음 후보로는 넉넉하고, 한도는 착수 전에 그 한 사람에게서 받아 두면 됩니다.

그래서 첫 걸음에 수주서 입력을 두면 ERP 연결과 양식 대응표가 그대로 쓰이니 짧게 끝나고, 두 번째 걸음으로 문서함을 여는 계약서 검토를 두면 그 걸음에서 뚫은 문서함 연결이 뒤이을 품의서·검수서 처리로 이어집니다.

순서를 뒤집으면 같은 두 업무인데 값이 달라집니다. 계약서 검토를 먼저 하면 문서함 연결에 몇 주가 붙는 동안 성과가 나오지 않고, 그 사이 수주서 입력은 손도 대지 못한 채 대기하죠. 걸음의 내용이 아니라 배열이 만든 차이입니다.

세 번째 걸음부터는 선택지가 늘어납니다. 두 시스템이 열려 있으니 후보 대부분이 첫째 칸을 공유하게 되고, 그다음부터는 결재 경로와 실패 방식이 순서를 정하는 자리로 올라옵니다.

짝으로 묶는다고 해서 두 걸음을 동시에 발주한다는 뜻은 아닙니다. 첫 걸음의 결과를 보고 두 번째를 확정하되, 후보를 고르는 시점에는 두 번째까지 보고 고른다는 것이죠. 첫 걸음이 기대와 다르게 나오면 두 번째 후보는 바꾸면 됩니다.

한 걸음에 여러 부서가 함께 들어와도 되나요?

같은 양식을 쓰고 같은 방식으로 실패하는 업무라면 부서가 셋이어도 한 걸음입니다. 지사 셋이 각자 채우던 같은 서식이 그런 경우죠.

데이터 흐름으로 단위를 잡으면 확장의 모양이 달라지는 지점이 바로 여기입니다.

조직도 순서로는 세 걸음이 될 일이 한 걸음이 되고, 반대로 한 부서 안에서도 흐름이 셋이면 세 걸음이 됩니다.

다만 부서가 늘면 넷째 칸과 셋째 칸은 부서 수만큼 늘어납니다. 예외를 받는 사람이 지사마다 다르고 승인 한도도 따로 정해져 있으니까요. 앞의 두 칸은 나눠 쓰고 뒤의 두 칸은 곱해지는 셈입니다.

하마다랩스에서 만나 온 확장 사례를 보면, 이 조합이 걸음 하나에 담을 수 있는 범위를 실질적으로 정합니다. 건수나 기간을 집계해 둔 것은 아니고 상담 자리에서 반복해 마주친 인상입니다. 앞의 두 칸은 부서가 늘어도 한 벌이면 되는데 뒤의 두 칸은 부서마다 합의할 상대가 따로 생기고, 그 합의들이 한꺼번에 열리지는 않더군요. 부서를 하나 더할 때마다 걸음의 길이는 그만큼 뒤로 밀리는 쪽으로 기웁니다.

그래서 부서를 묶을 때는 앞의 두 칸이 정말 같은지부터 확인합니다. 같은 이름의 서식이라도 지사마다 항목을 하나씩 더해 쓰는 경우가 있어, 양식 파일을 나란히 놓고 대조해 보는 편이 안전하죠. 항목이 갈리면 그 지사는 다음 걸음으로 미룹니다.

한 걸음에 부서를 몇이나 담을지는 결국 합의에 쓸 수 있는 시간이 정합니다.

확장 국면의 예산 대화는 도입 때와 무엇이 다른가요?

첫 도입에서 가장 높던 벽이 이미 넘어져 있고, 그 사실이 오히려 질문을 어렵게 만듭니다. 없어진 항목을 근거로 쓸 수 없기 때문이죠.

조사 하나가 그 사정을 보여 줍니다. AI 도입의 걸림돌로 초기 비용 부담을 든 곳이 44.2%로 가장 많았고, 답한 502곳은 스마트공장을 이미 돌리고 있는 중소기업이었습니다. 조사 주체는 중소기업중앙회이고, 결과는 2025년 10월 19일에 공개됐죠. 이들이 말한 것은 AI를 들이기 전이나 막 들이던 시점의 사정입니다.

1순위로 꼽힌 이 항목이 확장 국면에서 다르게 놓이는 이유는 비용의 성격에 있습니다. 초기 비용은 걸음마다 되풀이해 치르는 값이 아니라 첫 결재에서 한 번 넘는 값이거든요. 서버든 라이선스든 구축 용역이든 첫 업무에서 이미 한 번 결재를 통과했죠.

그러니 확장을 논하는 자리에서는 가장 높던 항목이 뒤로 물러납니다. 조사가 잡아낸 1순위 장벽을 그대로 들고 와 확장 예산을 설명하려 하면 앞뒤가 맞지 않게 되는 것이고요.

그런데도 두 번째 업무의 견적이 첫 번째와 비슷한 크기로 돌아오는 일이 있습니다. 그 견적서는 이미 치른 값을 다시 청구하고 있을 가능성이 큽니다. 재제작 항목이 줄지 않으면 확장은 첫 도입의 비용 구조를 그대로 갖고, 회사는 한 번 넘은 벽을 걸음마다 다시 넘습니다.

예산서에서 이것을 보이게 만드는 방법은 항목을 둘로 나눠 적는 것입니다. 여러 업무가 나눠 쓸 공통 기반이 한 줄, 이번 업무에만 쓰이는 몫이 다른 한 줄. 걸음이 쌓이는데도 앞줄이 줄지 않는다면 자산이 붙지 않는 상태라는 신호죠.

두 줄로 나눠 적으면 결재 자리의 질문도 달라집니다. 총액 한 줄만 있으면 비싸다 싸다로 대화가 흐르는데, 앞줄과 뒷줄이 갈려 있으면 앞줄이 왜 아직 이만큼인지를 묻게 되죠. 그 질문에 답하다 보면 어느 칸이 매번 어긋나고 있는지가 드러납니다.

이 구분은 회수 기간을 볼 때도 쓰입니다. 공통 기반은 뒤 업무들이 나눠 지는 값이라, 첫 업무 하나에 전부 얹어 두면 회수 기간이 실제보다 길게 잡힙니다. 3년 총소유비용으로 계산할 때 이 몫을 어디에 배분하는지가 확장 국면의 숫자를 좌우합니다.

확장을 멈추고 다시 봐야 하는 신호는 무엇인가요?

걸음마다 다시 만든 항목의 개수가 줄지 않는 것입니다. 세 번째 업무에서 다시 만든 항목이 두 번째와 같다면 확장을 세 번 한 것이 아니라 도입을 세 번 한 것이죠.

원인은 대개 둘 중 하나입니다. 후보를 조직도로 골라 네 칸이 매번 어긋났거나, 첫 업무를 만들 때 연결과 권한과 예외를 업무 로직에 붙여 만들어 떼어 낼 수 없거나.

앞쪽이면 순서를 바꾸는 것으로 풀립니다. 뒤쪽이면 다음 업무를 얹기 전에 그 셋을 업무에서 떼어 놓는 작업이 먼저 들어가야 하고, 그 작업은 새 기능을 만들지 않아 눈에 보이는 성과가 없습니다. 확장을 한 걸음 미루는 결정이 필요한 자리죠.

둘을 가르는 방법은 지난 걸음의 작업 목록을 펼쳐 보는 것입니다. 새로 만든 연결이 매번 다른 시스템을 향했다면 후보 선정이 원인이고, 같은 시스템인데도 연결을 또 만들었다면 첫 업무의 구조가 원인입니다. 두 경우가 섞여 있으면 후자를 먼저 처리하는 편이 낫습니다. 구조를 두고 순서만 바꾸면 다음 걸음에서 같은 자리로 돌아오니까요.

미루는 결정이 결재 자리에서 설명되기는 쉽지 않습니다. 이번 분기에 얹기로 한 업무가 하나 줄어드는데 그 대가로 보여 줄 화면은 없으니까요. 그럴 때 쓸 수 있는 근거는 다음 걸음들의 예상 재제작 항목입니다. 지금 떼어 놓으면 뒤이을 서너 걸음에서 같은 항목이 빠진다는 계산이 서면, 한 걸음의 지연이 무엇을 사는 값인지가 숫자로 남죠.

확장 안건을 보며 제가 오래 잘못 짚었던 것은 옆 팀 요청이 들어온 순서를 처리 순서로 읽은 일입니다. 요청의 순서는 그 팀이 소문을 들은 순서일 뿐이라 재제작 항목과 아무 관계가 없었는데, 목소리가 먼저 도착했다는 이유로 목록의 위쪽에 놓곤 했습니다.

비용을 실제로 줄인 회사들에게서 반복해 발견되는 공통점도 이 지점과 닿아 있습니다. 한 번 만든 것을 다음 업무가 물려받는 구조를 먼저 세워 두었다는 것이죠.

확장이 잘 되고 있는지는 무엇으로 재나요?

걸음마다 다시 만든 항목의 개수를 세면 됩니다. 첫 업무를 볼 때 쓰던 성과 지표는 그대로 두고, 확장 국면에는 그 한 줄을 더합니다.

새 도구는 필요 없습니다. 걸음마다 받은 견적서와 작업 목록에 이미 적혀 있으니, 연결·권한·예외 세 항목이 각 걸음에서 신규였는지 재사용이었는지만 옆에 표시하면 목록 한 장이 됩니다.

그 목록을 회의에 들고 들어가 펼치면 성과 보고서에는 없던 줄이 눈에 들어옵니다. 세 걸음 내내 신규 표시가 붙은 항목이 있는데, 같은 세 걸음의 성과 지표는 걸음마다 좋게 나와 있죠. 업무는 하나씩 성공했고 회사에 남은 것은 걸음 수뿐인 상태가 그 한 줄에서 드러납니다.

성과 보고서만 놓고 보면 이 상태는 보이지 않습니다. 지표가 재는 범위가 그 업무의 안쪽이라, 걸음과 걸음 사이에서 무엇이 옮겨 갔는지는 지표가 닿는 자리 밖에 있거든요.

세 걸음쯤 쌓이면 이 목록이 다음 후보의 순서까지 알려 줍니다. 어느 칸이 자주 어긋났는지가 보이고, 그 칸을 미리 깨 두면 뒤가 편해지는지도 함께 보이니까요.

목록을 보고할 때는 걸음마다의 소요 기간을 옆에 붙이시면 좋습니다. 재사용 항목이 늘 때 기간이 함께 짧아졌다면 자산이 실제로 일하고 있다는 뜻이고, 재사용은 늘었는데 기간이 그대로라면 시간을 잡아먹는 것이 구축이 아니라 합의나 대기 쪽이라는 신호죠. 두 경우에 손댈 자리가 다릅니다.

숫자 두 줄이면 확장의 상태가 대체로 설명됩니다.

이 값은 앞으로의 계획을 약속하는 숫자가 아니라 지나온 걸음을 기록하는 숫자입니다. 다음 걸음에서 재제작 항목이 몇 개로 줄어들지는 그 업무의 조건이 정하는 것이라 미리 단정할 수 없죠. 다만 줄어드는 방향인지 아닌지는 걸음이 끝날 때마다 확인할 수 있고, 방향이 뒤집히면 그 자리에서 원인을 찾는 편이 낫습니다.

다음 분기 확장 안건은 어떻게 적나요?

후보 목록을 부서가 아니라 칸으로 다시 적는 데서 시작합니다. 이름 옆에 네 칸의 겹침 여부를 표시하면 순서는 대체로 저절로 정해집니다.

• 지금 도는 업무가 쓰는 시스템·양식·결재 경로·예외 유형을 한 줄로 적습니다.
• 후보마다 그 네 칸과 겹치는지를 표시합니다. 모르면 모른다고 적고 확인할 사람을 옆에 씁니다.
• 겹침이 가장 많은 후보를 첫 걸음에 둡니다.
• 두 번째 걸음에서 깰 칸을 미리 고르고, 첫 걸음이 그 위에 올라설 수 있는지 확인합니다.
• 예산서를 공통 기반과 이번 업무 몫으로 나눠 적습니다.

이 다섯 줄을 채우는 데 필요한 것은 이미 손에 있는 자료뿐입니다. 새로 조사할 것은 없고요. 첫 업무의 작업 목록과 견적서, 그리고 요청을 보낸 팀장들의 메일 몇 통이면 대체로 채워집니다. 자리에 앉아 반나절이면 끝나는 일이 다음 분기의 순서를 바꿔 놓기도 하죠.

다섯 줄 가운데 답이 막히는 자리가 지금 확장이 걸려 있는 곳입니다. 지금 돌고 있는 업무와 다음 후보 목록을 성과 점검 상담에 적어 보내 주시면, 어느 칸이 겹치고 어느 칸이 어긋나는지 그 목록을 놓고 함께 읽어 보겠습니다. 하마다랩스는 개발 인력 없이 AI 에이전트를 만드는 플랫폼 윈디플로를 내놓았고, 이런 확장 국면을 상담 자리에서 함께 다뤄 왔습니다.

자주 묻는 질문

첫 업무에서 아직 손이 덜 떨어졌는데 확장 요청이 들어오면 어떻게 하나요?

예외 규칙이 아직 늘고 있는 중이라면 기다리는 편이 낫습니다. 확장의 이득은 앞에서 만든 것을 물려주는 데서 나오는데, 아직 흔들리는 규칙을 물려주면 두 업무의 규칙을 동시에 고치게 되거든요. 판단 기준은 기간이 아니라 예외 목록입니다. 새로 추가되는 예외가 눈에 띄게 줄어들면 물려줄 것이 굳었다는 신호로 봅니다.

부서장이 순서에서 밀렸다고 문제를 제기하면 무엇으로 설명하나요?

네 칸 표를 그대로 보여 주는 편이 빠릅니다. 겹치는 칸의 개수가 순서를 매겼다는 사실이 표에 드러나고, 부서의 중요도는 그 표 어디에도 들어가 있지 않으니까요. 덧붙일 것이 있다면 뒤로 밀린 업무가 앞 걸음에서 무엇을 물려받게 되는지입니다. 나중에 하는 쪽이 더 짧게 끝난다는 점이 설명되면 순서 자체가 손해로 읽히지 않습니다. 몇 번째 걸음에 놓이는지를 함께 적어 두면 대화가 더 짧아집니다.

공급사가 확장은 쉽다고 하는데 그 말을 어떻게 확인하나요?

후보 업무 하나를 지목해 네 칸 가운데 무엇이 새로 필요한지 목록으로 달라고 요청해 보십시오. 쉽다는 답이 견적 조건인지 기술 판단인지가 그 목록에서 갈립니다. 계정 발급이나 한도 합의처럼 우리 쪽이 해야 하는 일이 빠져 있다면, 그 일감은 사라진 것이 아니라 우리 담당자의 다음 달 일정으로 옮겨 간 것입니다.

확장 걸음마다 계약을 새로 해야 하나요?

계약 형태보다 먼저 볼 것은 공통 기반의 소유와 재사용 조건입니다. 첫 업무에서 만든 연결과 규칙을 다음 업무에 쓸 때 추가 비용이 붙는지, 그 조건이 계약서에 적혀 있는지를 확인해 두면 걸음마다의 협상이 짧아집니다. 조건이 명확하면 확장은 대개 기존 계약의 범위 조정으로 처리됩니다.

한 번에 여러 업무를 동시에 얹으면 시간을 아낄 수 있지 않나요?

네 칸이 같은 업무들이라면 그것은 이미 한 걸음이라 동시에 하는 것이 맞습니다. 칸이 서로 다른 업무들을 묶는 경우가 문제인데, 무엇 때문에 늦어졌고 무엇이 재사용됐는지가 뒤섞여 다음 걸음의 순서를 정할 근거가 남지 않습니다. 시간은 조금 아끼고 판단 근거를 잃는 거래인 셈이죠. 굳이 묶어야 할 사정이 있다면 업무별로 작업 목록을 따로 받아 두시면 근거는 지킬 수 있습니다.

앞 업무의 공급사와 다른 곳에 다음 업무를 맡겨도 되나요?

가능하지만 공통 기반을 누가 관리하는지가 먼저 정리돼야 합니다. 연결과 권한 설정이 앞 공급사의 환경 안에만 있으면 다음 공급사는 그 위에 얹지 못하고 자기 것을 새로 만들게 되고, 그 순간 재제작 항목이 셋 다 살아나죠. 계약 전에 확인할 것은 기술 이력이 아니라 앞 걸음의 산출물을 넘겨받아 쓸 수 있는지입니다. 넘겨받지 못하는 조건이라면 견적이 낮아도 확장이 아니라 두 번째 도입이 됩니다.

사내 시스템 없이 외부 서비스만 쓰는 회사도 같은 순서인가요?

칸의 이름은 그대로이고 첫째 칸의 성격만 바뀝니다. 외부 서비스는 계정 발급이 빠른 대신 요금제에 따라 접근 범위가 갈리는 경우가 있어, 연결 자체보다 어느 요금 구간에서 무엇까지 꺼낼 수 있는지가 확인 항목이 되죠. 나머지 세 칸은 사내 시스템을 쓸 때와 같은 방식으로 셉니다.

참고 자료

• 하마다랩스 대표 방승애 — 확장 안건 결재와 도입 상담 자리에서의 관찰(2026년 기준, 익명·건수 미집계). 다룬 범위는 넷입니다. 안건지에 적히는 항목과 결재에 필요한 항목이 어긋나는 형태, 운영이 쌓인 뒤 예외 목록이 늘어나는 형태, 요청이 도착한 순서와 재제작 항목의 무관함, 부서를 더할 때 뒤의 두 칸에서 합의가 길어지는 경향. 개별 고객사의 사례가 아닙니다.
• 한국일보 보도 — 중소기업중앙회가 스마트공장 구축 중소기업 502개사에 실시해 2025년 10월 19일 공개한 ‘AI 도입에 대한 의견조사’ 결과(AI 도입이 어려운 이유: 초기 비용 부담 44.2%·전문인력 부족 20.5%): https://www.hankookilbo.com/News/Read/A2025101911550001829
• 하마다랩스 서비스 안내 — AI 에이전트를 구축하고 운영하는 범위: https://www.hamadalabs.com/service/ai-agent

작성자

방승애 — 주식회사 하마다랩스의 대표이며 공동 창업자입니다. 벤처 투자와 액셀러레이팅, 사업 운영을 거쳐 2023년 11월에 회사를 세웠습니다. 개발 인력을 따로 두기 어려운 중소·중견기업이 AI 에이전트를 들이고 넓혀 가도록 윈디플로라는 노코드 플랫폼을 이끌고 있습니다. 도입 로드맵과 실패를 피하는 기준, 투자 판단의 근거를 경영자 자리에서 다루고 있습니다. 회사 안내: https://www.hamadalabs.com/