하마다랩스 AI 에이전트 구축 서비스 — 범위와 진행 순서

하마다랩스 AI 에이전트 서비스의 범위는 세 칸으로 갈립니다. 저희가 맡는 일, 고객사가 맡는 일, 그리고 양쪽이 마주 앉아야 정해지는 일이죠. 계약서에 또렷하게 적히는 것은 앞의 두 칸인데, 프로젝트가 어그러지는 자리는 대개 셋째 칸입니다.

미팅을 마치고 회의실을 나서는 검토자의 손에는 대개 두 가지가 남습니다. 데모 화면의 인상, 그리고 사내에 옮겨 적어야 할 문장 몇 줄이죠.

옮겨 적을 문장은 기능 목록이 아닙니다. 저 회사가 무엇을 해 주는지, 무엇이 우리 일로 남는지, 그 일에 우리 쪽 사람이 몇 주를 써야 하는지입니다. 결재 자리에서 돌아오는 질문도 대체로 이 셋에 몰려 있고요.

세 칸에 이름을 붙이는 데서 검토가 시작됩니다.

하마다랩스 AI 에이전트 서비스는 어디까지 맡고, 어디부터 고객사 일인가요?

저희가 맡는 것은 만드는 일이고, 고객사가 맡는 것은 정하는 일과 판정하는 일입니다. 그 사이에 어느 쪽도 혼자 결론 낼 수 없는 항목이 남는데, 그것이 셋째 칸이죠. 업무 진단에서 배포·교육까지 네 단계로 끊은 진행 순서는 서비스 안내에 이미 적혀 있습니다. 단계 이름 위에 세 칸을 얹으면 표가 됩니다.

국면	하마다랩스가 하는 일	고객사가 하는 일	함께 정하는 일
업무 진단	현행 처리 흐름 청취·기록, 자동화 가능 구간 구분	담당자 배정, 실제 처리 방식 설명, 예외 사례 제공	첫 대상 업무의 경계
설계	에이전트 구조·연동 방식·데이터 경로 설계	원천 시스템 계정과 테스트 환경 개방, 보안 검토 회부	배포 형태 선택
구현·테스트	시나리오 구현, 연동 개발, 테스트 케이스 작성	정답 사례 확인, 오답 지적	자동 처리와 사람 확인의 경계
배포·교육	운영 환경 이관, 관리자 교육, 운영 문서 전달	현업 공지, 사용 시작 시점 지정	예외가 났을 때 받는 사람
운영	장애 대응, 규칙 보정, 모델·연동 변경 반영	오작동 신고 경로 운영, 규칙 변경 요청	규칙을 고칠 권한을 누가 갖는지

첫째 칸이 넓다는 사실은 공급사 쪽 자랑거리로 읽히기 쉬운데, 실무에서는 반대로 작동합니다. 윈디플로 플랫폼이 갖춘 커넥터는 500종을 넘습니다. SAP와 세일즈포스, 오라클 같은 전사 시스템이 그 목록에 들어 있고, 배포 방식도 클라우드와 온프레미스 그리고 두 가지를 섞은 하이브리드 셋 중에서 고르실 수 있죠.

고를 수 있는 것이 많다는 말은 곧 고객사가 골라 주셔야 할 것이 많다는 뜻입니다. 선택지가 하나뿐이면 정할 일이 없지만, 셋 중 하나를 고르는 자리에서는 누군가 손을 들어야 하니까요. 첫째 칸이 길어질수록 셋째 칸도 같이 길어지는 이유가 여기에 있습니다.

셋째 칸이 따로 있는 이유도 같은 자리에서 나옵니다. 어떤 항목은 저희만 알아서는 답이 안 나오고, 어떤 항목은 고객사만 알아서는 실현 방법을 모릅니다. 배포 형태가 그 전형이죠. 어느 쪽이 사내 규정에 맞는지는 고객사가 알고, 그 선택이 연동과 운영에 어떤 부담으로 돌아오는지는 저희가 압니다. 두 정보가 한 자리에 놓여야 결론이 나오므로 이 항목들은 어느 칸에도 혼자 들어가지 못합니다.

세 칸 가운데 비어 있어도 진행이 멈추지 않는 칸은 어디인가요?

셋째 칸입니다. 첫째 칸이 비면 결과물이 나오지 않고 둘째 칸이 비면 일정이 밀리는데, 셋째 칸은 비어 있어도 프로젝트가 그냥 굴러갑니다.

멈추지 않는다는 점이 문제입니다. 정해지지 않은 항목은 사라지지 않고 기본값으로 대체되는데, 그 기본값을 고르는 쪽은 구현을 맡은 저희거든요. 저희는 그 자리에서 대개 만들기 쉬운 쪽, 장애가 적은 쪽을 고릅니다. 나쁜 뜻이 있어서가 아니라 결정을 물어볼 창구가 열려 있지 않은 동안에도 손은 멈추지 않기 때문이죠.

그렇게 정해진 값이 반년 뒤 현업의 불만으로 돌아옵니다.

이 판정을 스스로 뒤집어 보려고 반례를 찾아봤더니, 셋째 칸인데도 요란하게 멈추는 항목이 실제로 있었습니다. 사내 문서가 바깥 모델을 거치는지, 개인정보가 어느 지점까지 흘러가는지 같은 항목은 보안이나 법무 검토가 붙어 있어서 답이 오기 전에는 구현이 나아가지 못하거든요. 그래서 셋째 칸은 한 줄이 아니라 두 줄로 갈라 봐야 합니다.

셋째 칸의 두 갈래	해당하는 항목	비워 두면
밖의 승인이 걸린 항목	데이터 반출 범위, 개인정보 처리 위탁, 접근 권한 등급	결재가 날 때까지 멈춘다 — 늦어지되 눈에 띈다
안에서 판단이 끝나는 항목	자동 처리와 사람 확인의 경계, 예외 수신자, 성공 판정 기준, 기록 보관 기간	표시 없이 기본값으로 넘어간다 — 운영에 들어간 뒤 드러난다

검토자가 계약 전에 붙잡아야 할 줄은 아래쪽입니다. 위쪽 줄은 어차피 사내 절차가 붙잡아 주거든요.

기본값이 어떤 모습인지는 예외 수신자 항목에서 잘 드러납니다. 이 칸이 비어 있으면 에이전트가 답을 내지 못한 건은 기록에만 남고 아무에게도 가지 않습니다. 만드는 쪽에서 보면 그것이 가장 안전한 처리이고, 실제로 장애도 나지 않죠. 다만 몇 달 뒤 미처리 건이 쌓인 것을 발견했을 때, 그 값을 누가 골랐는지는 양쪽 모두 기억하지 못합니다.

아래쪽 줄에는 공통점이 하나 있습니다. 어느 것도 기술 결정이 아니라는 점이죠. 무엇을 사람이 확인할지, 틀렸을 때 누가 받을지, 어디까지 맞으면 됐다고 할지는 업무를 아는 쪽만 답할 수 있는 물음입니다.

함께 정하는 일은 어떻게 채워야 하나요?

착수 회의에서 목록으로 뽑아 두는 것이 가장 싼 방법입니다. 항목을 세어 두기만 해도 조용히 넘어가는 자리가 사라지거든요.

목록에 이름이 오른 항목은 적어도 잊히지는 않습니다.

목록에는 세 가지를 나란히 적습니다. 정해야 할 항목, 정하지 않으면 자동으로 넘어가는 기본값, 그리고 늦어도 언제까지 답이 있어야 하는지입니다. 기본값을 미리 적어 두는 것이 이 목록의 핵심입니다. 결정이 늦어도 무엇으로 넘어가는지 양쪽이 같은 문장을 보고 있으면, 나중에 그 값이 드러났을 때 누구의 실수인지를 따지는 대화로 가지 않으니까요. 기본값을 받아들이겠다는 결정도 결정입니다.

정해야 할 항목은 대체로 열 줄을 넘지 않습니다.

기한을 적는 자리에서는 저희 일정이 아니라 그 항목이 필요해지는 단계를 기준으로 삼습니다. 배포 형태는 설계가 끝나기 전에, 자동과 수동의 경계는 구현이 절반을 지나기 전에, 예외 수신자는 배포 전에 답이 있으면 됩니다. 이렇게 적어 두면 모든 항목을 착수 첫 주에 몰아 결정할 필요가 없어지고, 결재 주기가 긴 조직도 순서대로 따라올 수 있습니다.

목록을 만들 때 흔한 실수는 항목을 잘게 쪼개는 것입니다. 스무 줄을 넘어가면 결정을 요청받는 쪽이 우선순위를 잃고, 회의 한 번에 전부 훑고 넘어가는 자리가 되죠. 굵게 묶어 열 줄 안쪽으로 두고 그 아래 세부는 저희 설계 문서에 남기는 편이 결정에 좋습니다.

목록은 회의록이 아니라 한 장짜리 문서로 남기시길 권합니다. 회의록에 섞여 들어간 미결 항목은 다음 회의록에 다시 적히지 않으면 그대로 잊히거든요.

고객사 몫으로 남는 일은 왜 넘길 수 없나요?

넘기는 순간 그 결정이 저희 쪽으로 옮겨 오기 때문입니다. 대신해 드리는 것 자체는 어렵지 않은데, 대신한 만큼 업무 지식이 저희 문서에만 쌓이거든요. 몇 해 뒤 담당자가 바뀌거나 운영사를 바꾸려 할 때, 정작 필요한 문서가 사내에 없다는 사실은 그제야 드러납니다.

고객사 몫	대신할 수 없는 이유
대상 업무의 규칙을 한 문장으로 확정	담당자마다 다르게 말하는 상태에서는 저희가 하나를 고르게 되고, 고른 쪽이 현업의 방식과 어긋나면 만들어 놓고 쓰이지 않는다
원천 시스템 계정·권한 발급	사내 승인 절차라 외부에서 대신 신청할 수 없다
결과의 정오 판정	무엇이 맞는 답인지는 그 업무를 하는 사람만 안다
예외를 받는 사람 지정	사람을 배치하는 일이라 조직 안에서만 정해진다
이관 후 운영 담당	지식이 남을 자리를 정하는 결정이다

저는 회사를 대표해 이런 계약에 서명하는 쪽에 서 있으면서도, 상담 자리에서는 저희가 대신하지 않을 항목부터 먼저 말씀드립니다. 넘겨받는 범위가 넓어질수록 저희 매출은 늘지만 고객사에 남는 것은 줄고, 남은 것이 없으면 다음 결정에서 고르실 수 있는 길이 좁아지니까요.

둘째 칸에서 실제로 무겁게 걸리는 것은 결정이 아니라 시간입니다. 현업 담당자가 자리에 붙어야 하는 국면은 셋인데, 진단 단계의 청취와 구현 단계의 오답 지적, 그리고 배포 직전의 교육입니다.

이 셋은 대신해 드릴 수 없고, 줄일 수는 있습니다. 청취를 한 번에 몰지 않고 짧게 나눠 잡거나, 오답 지적을 화면에서 표시만 하도록 만들어 두는 식이죠. 상담 자리에서 이 시간을 미리 말씀드리지 않으면 착수 뒤에 현업의 반발로 돌아옵니다. 일정에 적히지 않은 시간은 결국 누군가의 야근으로 채워지니까요.

운영이 시작된 뒤 현업의 하루가 어떻게 달라지는지는 현업 담당자의 하루가 달라지는 지점에 따로 적어 두었습니다. 이관 담당자를 언제 정할지는 그 변화를 보고 판단하시면 됩니다.

구축은 어떤 순서로 진행되고, 단계마다 무엇이 남나요?

업무 진단, 설계, 구현·테스트, 배포·교육 네 단계입니다. 단계마다 손에 남는 문서가 다르고, 그 문서가 다음 단계의 입구 노릇을 합니다. 서비스 안내에는 네 단계의 이름이 적혀 있습니다. 이름만으로는 그 단계가 끝났는지 판단하기 어려워서, 끝났다는 표시를 옆에 적어 두는 편이 낫습니다.

단계	이 단계에서 하는 일	끝났다는 표시	고객사 손이 필요한 지점
업무 진단	현행 흐름 기록, 자동화 구간 구분	대상 업무 한 줄 정의와 제외 목록	예외 사례를 모아 주는 일
설계	구조·연동·데이터 경로 설계	연동 대상 목록과 데이터 경로도	계정 발급, 보안 검토 회부
구현·테스트	시나리오 구현, 연동 개발, 테스트	테스트 케이스와 통과·실패 기록	오답 지적과 정답 확인
배포·교육	운영 환경 이관, 관리자 교육	운영 문서와 관리자 계정	현업 공지, 시작 시점 지정

셋째 열이 이 표의 쓸모입니다. 문서가 손에 없으면 그 단계는 아직 닫히지 않은 것이고, 닫히지 않은 채 다음으로 넘어가면 대개 되돌아옵니다.

단계마다 그 문서를 받아 둘 사람을 고객사 쪽에서 정해 두면 확인이 훨씬 쉬워집니다.

되돌아오는 모양은 단계마다 다릅니다. 진단이 얇으면 설계 도중에 예외가 쏟아져 대상 업무를 다시 그리게 되고, 설계에서 연동 대상 목록을 확정하지 않으면 구현 중에 시스템이 하나씩 늘어납니다.

테스트 기록 없이 배포한 경우에는 현업이 오답을 발견해도 그것이 새로 생긴 문제인지 처음부터 있던 것인지 가릴 방법이 없죠. 되돌아오는 값은 뒤로 갈수록 커지므로, 앞 단계의 문서를 얇게 넘기는 선택이 일정을 앞당기는 일은 거의 없습니다.

운영은 네 단계 뒤에 별도로 붙습니다. 구축 계약에 안정화 기간까지만 포함하고 그 뒤를 운영 계약으로 나누는 방식과, 처음부터 운영을 묶는 방식이 갈리는데, 어느 쪽이 맞는지는 사내에 운영을 받을 사람이 있는지에 달려 있습니다. 받을 사람이 아직 없다면 운영을 묶어 시작하되, 언제 넘겨받을지를 계약서에 함께 적어 두는 쪽이 안전합니다.

같은 범위인데 기간이 갈리는 이유는 무엇인가요?

작업량이 아니라 대기 시간이 기간을 정하기 때문입니다. 저희 쪽 작업일수는 범위가 정해지면 대체로 가늠되는데, 달력에 찍히는 날짜는 그것과 다르게 흘러갑니다. 그 차이를 만드는 것은 저희 손이 아니라 고객사 안에서 답이 오가는 속도입니다.

기간을 늘리는 자리는 셋으로 좁혀집니다.

자동화할 업무의 규칙이 문서로 적혀 있는가. 없으면 진단 단계에서 그 문서를 함께 만들어야 하고, 그 작업은 현업의 시간을 씁니다.
원천 시스템의 계정과 테스트 환경이 언제 열리는가. 신청부터 발급까지 몇 주가 걸리는 회사가 있습니다.
결정 회의가 몇 주 간격으로 열리는가. 앞에서 본 셋째 칸이 바로 여기에 걸립니다.

셋째 항목이 가장 자주 어긋납니다. 함께 정하는 일은 저희 일정표에 올라와 있지만 실제로는 고객사 결재 주기 위에서 움직이거든요. 격주로 열리는 회의체에서 정할 항목이 넷이라면, 저희가 손을 놓고 있지 않아도 산술적으로만 여덟 주가 흘러갑니다.

달력을 줄이는 가장 확실한 수단은 계정과 테스트 환경 신청을 계약 전에 걸어 두는 것입니다.

그래서 기간을 숫자로 먼저 약속드리지 않습니다. 몇 주라고 적어 드릴 수는 있지만 그 숫자는 위 세 조건이 갖춰졌다는 가정 위에 서 있고, 가정이 어긋나면 숫자만 남거든요. 조건별로 어디가 얼마나 늘어나는지를 적어 드리는 편이 검토 자리에서 실제로 쓰입니다.

구축 계약을 권하지 않는 네 가지 경우

제가 상담 자리에서 착수를 미루시라고 답한 경우를 되짚어 보면 대체로 아래 넷 가운데 하나였습니다. 실패한 도입의 원인을 뒤늦게 찾는 일보다, 착수하지 않을 이유를 앞에서 찾는 편이 양쪽 모두에 쌉니다.

업무 규칙이 아직 사람마다 다르게 말해지는 단계. 만들 것을 정하는 일이 먼저입니다. 이 상태로 착수하면 규칙을 저희가 고르게 되고, 앞에서 본 셋째 칸의 문제가 프로젝트 전체 크기로 커지죠. 규칙을 모으는 데 걸리는 시간은 대개 구축 기간보다 짧습니다.

연결할 시스템이 한둘이고 사내에 만들 사람이 있는 경우. 직접 만드시는 편이 빠릅니다. 외부에 맡기면 요구를 설명하는 시간이 만드는 시간보다 길어지는 구간이 있거든요.

손으로 처리해도 하루 일과에 묻히는 양. 자동화가 돌려주는 시간이 그 일을 만드는 시간을 넘지 못합니다. 처리량이 늘어난 뒤에 다시 보셔도 늦지 않죠. 판단의 기준은 불편함이 아니라 반복되는 횟수입니다.

반년 안에 원천 시스템 교체나 조직 개편이 예정된 경우. 연동은 붙어 있는 시스템이 바뀌면 다시 만듭니다. 교체 일정이 이미 잡혀 있다면 그 뒤가 착수 시점입니다.

넷 가운데 하나에 걸린다고 해서 이야기가 끝나지는 않습니다. 규칙이 흩어져 있으면 그것을 모으는 일부터 짧게 잡을 수 있고, 시스템 교체가 예정돼 있으면 교체 뒤에 붙일 자리를 지금 설계에 반영해 둘 수 있죠. 착수를 미루자는 답과 아무것도 하지 말자는 답은 다릅니다.

넷 어디에도 해당하지 않는데 예산이 부담되신다면 길이 하나 더 남아 있습니다. 구축 계약 대신 노코드 플랫폼만 쓰는 방식인데, 담당자가 화면에서 직접 흐름을 짜므로 만드는 능력이 사내에 남고 대신 그 담당자의 시간이 듭니다.

세 가지 형태 가운데 우리 회사는 어디에 해당하나요?

지금 확정되지 않은 것이 무엇인지가 형태를 정합니다. 만들 것이 미정인 회사와 만들 사람이 없는 회사는 같은 서비스를 받을 이유가 없거든요.

아직 확정되지 않은 것	맞는 형태
만들 것 자체 — 수요와 아이디어	소규모 검증부터 — POC·MVP 제작
연결 방법 — 기존 시스템에 붙이는 일	맞춤형 에이전트 구축
만들 사람 — 업무와 연결 방법은 이미 정해짐	노코드 플랫폼 사내 도입

SaaS 도입 안내에 적힌 대상은 직원 50~300명, 매출 100억~1,000억 원 규모의 제조·유통·물류·서비스 기업입니다. 규모가 이 구간을 벗어나면 대상이 아니라는 뜻은 아니고, 이 구간에서 가장 자주 맞아떨어진다는 표시로 읽으시면 됩니다.

형태가 갈리면 계약 문서도 갈립니다. 검증 단계는 기간과 판정 기준이 계약의 뼈대가 되고, 구축은 범위와 산출물이, 플랫폼 도입은 사용 조건과 지원 범위가 뼈대가 되죠. 형태를 정하지 않은 채 계약서부터 받으면 무엇을 확인해야 할지부터 흐려집니다.

형태를 바꿔 타는 경우도 드물지 않습니다. 검증으로 시작해 구축으로 넘어갈 때 그대로 이어지는 것은 업무 규칙과 예외 목록이고, 다시 만들게 되는 것은 대개 연동과 권한 설정입니다. 검증 단계에서 임시로 뚫어 둔 통로는 운영 환경의 보안 기준을 통과하지 못하거든요. 그래서 검증 결과를 정리하실 때는 만들어 본 화면보다 그 과정에서 확인된 규칙과 예외를 문서로 남겨 두는 편이 다음 단계에서 값을 합니다.

금액과 계약 조건은 어떤 순서로 정해지나요?

범위가 문장으로 확정된 다음입니다. 순서를 바꿔 물으시는 경우가 많은데, 확정 전에 나온 숫자는 견적이 아니라 짐작이거든요. 짐작으로 예산을 잡으면 결재를 두 번 받게 됩니다.

금액을 움직이는 항목은 대체로 다섯입니다. 연결할 시스템의 수, 시나리오의 수, 배포 형태, 운영 계약의 유무, 그리고 수정 라운드의 횟수죠. 이 다섯이 문장으로 적히면 산정이 되고, 하나라도 방향으로만 적혀 있으면 착수한 뒤에 다시 계산하게 됩니다.

총액만 먼저 알려 달라는 요청도 자주 받는데, 그 요청에 숫자로 답하면 양쪽이 손해를 봅니다. 넉넉히 부른 숫자는 검토를 거기서 끝내 버리고, 좁게 부른 숫자는 착수 뒤 증액 협의로 이어지거든요. 대신 드릴 수 있는 것은 위 다섯 항목을 회사 조건으로 채운 다음의 산정 근거입니다.

숫자보다 먼저 필요한 것은 그 숫자를 만든 문장입니다.

산정 결과는 회사마다 다르게 나오므로 문의 창구에서 개별로 전해 드립니다.

들이는 값의 반대편, 그러니까 줄어드는 인건비를 세는 쪽에는 셈법이 따로 있습니다. 인건비 절감액을 계산할 때 빠지는 함정에 그 계산과 흔한 착오를 적어 두었습니다.

문의 전에 손에 들고 있으면 좋은 네 가지

아래 넷이 있으면 첫 회의에서 세 칸의 초안이 나옵니다.

대상 업무의 이름과 지금 처리하는 방식
연결해야 할 시스템의 이름
결과를 판정할 사람
언제까지 결정해야 하는지

네 가지를 모으는 데 새 조사가 필요하지는 않습니다. 지금 그 업무를 하는 분과 잠깐 앉으면 앞의 둘은 나오고, 나머지 둘은 조직도와 일정표에 이미 있으니까요. 그래도 채워지지 않는 칸이 있다면 그 칸이 이 프로젝트에서 가장 먼저 정리해야 할 자리입니다.

빈칸은 비었다고 적어 보내 주셔도 됩니다. 무엇이 비어 있는지가 첫 회의의 안건이 되니까요.

세 칸을 조직에 맞게 채워 보는 자리가 필요하시면 구축 범위 문의에 위 네 가지를 적어 보내 주십시오. 첫 회신으로 드리는 것은 견적서가 아니라 채워진 분담표 초안입니다. 그 표를 손에 놓고 착수할지 미룰지를 정하시면 되고, 미루는 쪽이 답이라면 그렇게 판단한 이유도 같은 표 위에 적혀 있을 겁니다.

자주 묻는 질문

사내에 개발 인력이 전혀 없어도 되나요?

구축과 운영을 맡기는 형태라면 개발자 없이도 진행됩니다. 다만 업무를 설명하고 결과를 판정할 사람은 반드시 있어야 하고, 그 자리는 개발 역량과 무관하게 업무를 아는 분의 몫입니다. 이관 뒤 규칙을 직접 손보고 싶다면 노코드 화면을 다룰 담당자를 한 명 정해 두시는 편이 낫습니다.

계약 전에 우리 데이터를 넘겨야 하나요?

진단 단계에서 필요한 것은 데이터 자체가 아니라 처리 흐름의 설명입니다. 실제 데이터는 설계와 구현 단계에서 테스트 환경을 통해 다루고, 그 전에 반출 범위와 처리 위탁 관계를 문서로 정리합니다. 사내 규정상 원본을 내보낼 수 없다면 가려진 표본이나 온프레미스 환경에서 다루는 방식으로 갈음할 수 있습니다.

만든 뒤에 우리가 직접 고칠 수 있나요?

흐름과 규칙은 노코드 화면에서 담당자가 고칠 수 있는 범위로 넘겨 드리는 것을 기본으로 합니다. 연동 코드나 인증 설정처럼 손대면 장애로 이어지는 구간은 저희가 맡되, 무엇이 어느 쪽 소관인지를 이관 문서에 적어 경계를 남깁니다.

다른 업체가 만든 자동화를 이어받기도 하나요?

가능한 경우와 다시 만드는 편이 싼 경우가 갈립니다. 기존 흐름의 문서와 계정 권한이 남아 있으면 이어받는 쪽이 빠르고, 화면만 있고 규칙이 사람의 기억에만 있으면 진단부터 다시 하는 편이 결국 짧습니다. 판단은 인수 자료를 함께 열어 본 뒤에 드립니다.

진행 중에 범위를 줄이거나 멈출 수 있나요?

단계 사이가 그 지점입니다. 진단이 끝난 자리에서 대상 업무를 줄이거나 착수를 미루는 결정이 가장 값싸고, 구현이 절반쯤 지난 뒤의 축소는 이미 만든 부분의 정산 문제가 됩니다. 그래서 단계마다 산출물을 남기고 그 자리에서 계속 여부를 묻습니다.

어느 부서가 이 프로젝트를 맡아야 하나요?

업무를 하는 부서가 맡고 정보시스템 담당이 옆에 붙는 형태가 대체로 굴러갑니다. 시스템 부서가 단독으로 맡으면 규칙 확정과 정오 판정이 계속 미뤄지고, 현업이 단독으로 맡으면 계정과 보안 검토에서 멈추거든요. 두 부서의 이름이 모두 적힌 착수 문서가 있으면 셋째 칸이 훨씬 빨리 채워집니다.

참고 자료

하마다랩스 윈디플로 플랫폼 안내 — 커넥터 500종 이상(SAP·세일즈포스·오라클 등), 클라우드·온프레미스·하이브리드 배포 지원(2026-08-27 확인): https://www.hamadalabs.com/platform
하마다랩스 AI 에이전트 구축 서비스 안내 — 진행 4단계(Work Audit 업무 진단 · Architecture Design 설계 · Build & Test 구현 및 테스트 · Deployment & Training 배포 및 교육) 표기(2026-08-27 확인): https://www.hamadalabs.com/service/ai-agent
하마다랩스 SaaS 도입 서비스 안내 — 대상 기업 규모(직원 50~300명 · 매출 100억~1,000억 원)와 업종(제조·유통·물류·서비스), 진행 4단계(맞춤형 기획 · 시스템 통합 · 보안 안정화 · 운영 지원) 표기(2026-08-27 확인): https://www.hamadalabs.com/service/saas
하마다랩스 도입 상담·구축 진행 관찰(2026년, 익명·범위 표기) — 서술 범위는 셋입니다. ① 결정 요청 창구가 열려 있지 않은 항목이 구현 편의 쪽 기본값으로 정해지는 형태 ② 계정 발급과 결재 주기가 착수 이후 일정을 좌우하는 형태 ③ 착수를 미루자는 답으로 이어진 상담의 유형. 특정 고객사 사례가 아니며 건수·기간을 집계한 수치가 아닙니다.
하마다랩스 문의 창구: https://www.hamadalabs.com/contact

작성자

방승애 — 하마다랩스의 대표이자 공동 창업자입니다. 벤처 투자와 액셀러레이팅, 사업 운영과 해외 프로젝트를 거쳐 2023년 11월에 회사를 세웠고, 지금은 내부 개발팀을 두기 어려운 중소·중견기업이 AI 에이전트를 들이고 운영하도록 노코드 플랫폼 윈디플로를 이끌고 있습니다. 도입의 단계별 로드맵과 실패를 피하는 기준, 투자 판단의 근거를 경영 의사결정 자리에서 다룹니다. 회사 안내: https://www.hamadalabs.com/