AI 에이전트 도입 의사결정 체크리스트 — IT팀장이 놓치는 것

AI 에이전트 도입 결정은 기능과 가격만 맞춰서는 흔들립니다. 운영·보안·출구 조항·확장성까지 스무 개 항목을 함께 보는 AI 도입 의사결정 체크리스트를 계약 전에 세워야, 서명 뒤에 드러나는 비용과 분쟁을 줄일 수 있죠.

데모를 보고 비교표까지 만든 뒤에 오히려 결정이 무거워지는 순간이 있습니다. 기능은 얼추 비슷하고 가격도 견줘 봤는데, “이대로 사인해도 괜찮은가”라는 물음이 마지막에 남거든요.

그 불안은 대개 근거가 있습니다. 기능표와 견적서에는 담기지 않는 항목들이 도입 뒤에야 비용으로 나타나기 때문이죠. 장애가 났을 때 누가 몇 시간 안에 대응하는지, 우리 데이터가 어디서 처리되는지, 계약이 끝나면 데이터와 설정은 어떻게 회수되는지 같은 것들입니다.

저는 ERP·CRM 위에 AI 에이전트를 얹는 구축을 해 오면서, 좋은 제품을 고르고도 이 뒤쪽 항목이 계약서에 빠져 2년 차에 분쟁이 되는 경우를 여러 번 봤습니다. 아래 체크리스트는 그 빈칸을 계약 전에 메우기 위한 표입니다.

AI 도입 의사결정 체크리스트, 기능·가격 다음에 무엇을 봐야 하나요?

기능과 가격을 통과한 다음에 봐야 할 축은 네 가지입니다. 운영, 보안, 출구 조항, 그리고 확장성이죠. 이 넷은 데모에서 보이지 않고 견적서에도 잘 적히지 않아, 의식적으로 물어보지 않으면 그대로 빠집니다.

네 축이 빠지면 결정의 근거가 반쪽이 됩니다. 기능·가격은 “도입 시점의 그림”이라면, 네 축은 “도입 이후 3년의 그림”이거든요. 앞만 보고 고르면 뒤에서 비용이 새고, 뒤만 보면 결정이 늦어지죠.

축	핵심 질문	빠졌을 때의 대가
운영	장애 시 누가 얼마 만에 대응하나	장애 지연·업무 중단
보안	데이터는 어디서 처리·저장되나	감사 지적·유출 위험
출구 조항	종료 시 데이터·모델은 어떻게 되나	종속·이전 비용
확장성	전사로 늘 때 비용·성능은	재구축·예산 초과

체크리스트를 쓰는 목적은 공급사를 떨어뜨리는 데 있지 않습니다. 우리 조직에서 어떤 항목이 결정적 결함(deal-breaker)이고 어떤 항목은 협의로 풀리는지 미리 나누어, 협상과 계약서에 반영하기 위한 지도입니다.

왜 기능과 가격만 비교하면 결정이 흔들리나요?

기능·가격 비교가 위험한 이유는 그 두 축이 가장 눈에 잘 띄기 때문입니다. 비교하기 쉬운 항목이 결정을 독점하면, 정작 도입 이후를 좌우하는 항목이 시야에서 사라지죠.

외부 데이터도 조급한 도입의 위험을 가리킵니다. 가트너가 인프라·운영 책임자 782명을 조사해 2026년 4월 발표한 결과, AI 활용 사례 중 ROI 기대를 온전히 충족한 비율은 28%에 그쳤고 20%는 완전한 실패로 분류됐습니다. 57%가 통합 실패를 한 번 이상 겪었고 그 흔한 원인으로 “너무 이른 과도한 기대”를 꼽았죠.

이 수치가 체크리스트와 무관해 보이지만, 실제로는 맞닿아 있습니다. 기대가 앞선 도입은 대개 운영·보안·출구 같은 뒤쪽 항목을 건너뛴 도입이거든요. 점검 항목을 늘리는 일 자체가 과도한 기대를 실무 조건으로 되돌리는 장치입니다.

견적 편차의 원인도 여기에 있습니다. 같은 제품이라도 무엇을 연동하고 어디까지 자동화하느냐에 따라 범위가 달라지고, 그 범위가 비용과 운영 부담을 정하죠. 범위를 어떻게 정의하는지는 견적 편차와 범위 정의에서 따로 다룹니다.

결국 흔들리는 결정은 정보가 부족해서가 아니라, 정보의 종류가 한쪽으로 쏠려서 생깁니다. 기능·가격에 운영·보안·출구·확장성을 나란히 세우면, 비교표가 도입 시점이 아니라 3년을 담게 되죠.

운영 항목 — 장애가 났을 때 누가, 얼마 만에 대응하나요?

운영에서 먼저 확인할 것은 장애 대응의 약속입니다. AI 에이전트가 업무 흐름에 들어오면 그것이 멈출 때 업무도 함께 멈추므로, 복구 목표 시간과 통보 경로가 계약서에 숫자로 적혀 있어야 하죠.

SLA는 문서에 있느냐가 아니라 무엇을 보장하느냐가 관건입니다. 가동률 99.9%라는 숫자 하나보다, 장애 감지부터 통보·복구까지의 시간과 그 시간을 못 지켰을 때의 책임이 더 중요하거든요. 이 부분이 비면 장애가 나도 “노력하겠다”는 답만 돌아옵니다.

운영 점검 항목	확인할 내용
복구 목표 시간(RTO)	장애 시 정상화까지 약속 시간
통보·에스컬레이션	누가·어떤 경로로 언제 알리나
모니터링·로그 제공	우리가 상태·이력을 직접 보나
유지보수·업데이트 정책	변경 예고·롤백 절차 유무
우리 쪽 운영 공수	예외 처리에 드는 내부 인력

마지막 줄의 내부 운영 공수는 특히 자주 빠집니다. 에이전트가 처리하다 막히는 예외를 사람이 점검하고 되돌리는 손이 계속 드는데, 이 시간을 0으로 두면 운영비가 실제보다 가볍게 잡히죠. 도입 뒤 실제로 몇 명이 몇 시간을 쓰는지 미리 물어보는 편이 안전합니다.

모니터링과 로그 접근도 계약 전에 확인할 항목입니다. 에이전트가 무엇을 근거로 어떤 판단을 내렸는지 우리가 직접 들여다볼 수 있어야, 오작동을 사후에 추적하고 감사에도 답할 수 있거든요. 상태 대시보드와 이력 로그를 우리 쪽에서 조회할 수 있는지 물어보시길 권합니다.

운영 항목은 공급사만의 몫이 아닙니다. 장애가 났을 때 우리 조직 안에서 누가 1차로 받고 어디로 넘기는지도 함께 정해 두어야, 계약의 SLA가 실제 업무에서 작동하거든요. 이 내부 경로를 표 옆에 한 줄 붙여 두시길 권합니다.

보안 항목 — 우리 데이터는 어디서 처리되고 어디에 남나요?

보안에서 첫 질문은 데이터의 위치입니다. 우리 데이터가 어느 나라 어떤 서버에서 처리되고, 처리 뒤 어디에 얼마나 남는지가 이후의 모든 규제 대응을 좌우하죠.

두 번째 질문은 학습입니다. 우리가 넣은 데이터로 공급사의 모델이 학습되는지, 그렇다면 격리·옵트아웃이 되는지 계약서에서 확인해야 합니다. 이 조항이 없으면 사내 문서가 남의 모델에 흡수되는 경로가 열려 있는 셈이거든요.

세 번째는 배포 형태입니다. 민감 데이터를 다루는 조직이라면 클라우드 공용 환경이 아니라 프라이빗·온프레미스 배포가 가능한지가 결정적입니다. 하마다랩스가 온프레미스 배포를 지원하는 이유도, 데이터를 외부로 내보내기 어려운 제조·금융·공공 고객이 실제로 있기 때문이죠.

보안 점검 항목	확인할 내용
데이터 처리·저장 위치	국내/해외 리전, 보관 기간
학습 재사용 여부	우리 데이터로 모델 학습하나
배포 형태	온프레미스·프라이빗 지원
접근 권한·감사 로그	누가 접근했는지 추적되나
인증 보유	ISO 27001:2022·42001·SOC2

인증은 있고 없고를 넘어 무엇을 덮느냐를 봐야 합니다. ISO/IEC 27001:2022는 부속서 A에 93개 통제 항목을 두고 정보보안 관리 체계를 요구하고, ISO/IEC 42001:2023은 AI 관리 체계를 별도로 다루죠. 두 인증이 우리 도입 범위를 실제로 포함하는지 확인하는 것이 인증서 유무보다 중요합니다.

보안 항목은 도입 뒤에 감사에서 지적받기 전에 잡는 편이 훨씬 쌉니다. 감사 대응과 온프레미스 전환을 항목별로 점검하는 방법은 보안 감사·온프레미스 점검에 따로 정리해 두었습니다.

출구 조항 — 계약이 끝나면 데이터와 모델은 어떻게 되나요?

출구 조항은 IT팀장이 가장 자주 빠뜨리는 항목입니다. 도입을 결정하는 자리에서 종료를 이야기하기가 어색해, 계약서에 반환·파기·이전 조항 없이 서명하는 경우가 많거든요.

종료 시점에 확인할 것은 세 가지입니다. 우리 데이터를 어떤 형식으로 언제까지 돌려받는지, 남은 데이터가 실제로 파기됐다는 증빙을 받는지, 그리고 우리가 만든 프롬프트·설정·커스텀 모델 자산을 가지고 나올 수 있는지죠.

출구 점검 항목	확인할 내용
데이터 반환	형식(표준 포맷)·기한·비용
데이터 파기	완전 삭제 증빙 제공 여부
자산 이전	프롬프트·설정·커스텀 모델 소유
종속·마이그레이션	다른 환경으로 옮길 경로 유무

이 조항이 비면 종속(lock-in)이 협상력을 가져갑니다. 데이터를 표준 포맷으로 못 받고 설정 자산도 두고 나와야 한다면, 재계약 협상에서 우리 쪽 카드가 사라지죠. 종료 조항은 쓸 일이 없기를 바라며 넣는 보험이지만, 넣는 순간 협상 내내 힘이 됩니다.

구축을 하다 보면 이전(migration) 경로가 처음부터 설계돼 있는지가 갈림길이 됩니다. 데이터와 설정을 표준 형식으로 내보내는 기능이 제품에 있으면 출구가 열려 있는 것이고, 그렇지 않으면 계약서 문구만으로는 실제 이전이 어렵거든요. 문서 조항과 제품 기능을 함께 확인하시길 권합니다.

가상 시나리오로 감을 잡아 보겠습니다. 한 회사가 2년을 쓴 뒤 다른 제품으로 옮기려 했는데, 데이터는 돌려받았지만 그동안 다듬어 온 프롬프트와 업무 규칙이 공급사 형식에 묶여 그대로 두고 나와야 했던 상황이죠. 이 예시는 출구 조항의 공백이 어떻게 비용이 되는지 보여 주기 위한 가상 상황이며, 실제 고객 사례가 아닙니다.

확장성 항목 — 한 부서가 전사로 늘 때 무엇이 걸리나요?

확장성은 지금이 아니라 내년을 보는 항목입니다. 한 부서 파일럿으로 시작한 도입이 성공하면 전사 확대가 뒤따르는데, 이때 비용·성능·연동이 어떻게 움직이는지가 처음 계약에 이미 담겨 있어야 하죠.

가장 먼저 볼 것은 비용 곡선입니다. 사용량이 늘 때 비용이 선형으로 오르는지, 어느 구간부터 단가가 완만해지는지에 따라 전사 확대의 예산이 크게 달라지거든요. 요금은 연동 범위와 사용량에 따라 달라져 여기에 특정 단가를 적지는 않지만, 사용량 구간별 곡선의 모양은 계약 전에 물어볼 수 있습니다.

확장 점검 항목	확인할 내용
비용·성능 곡선	사용량 증가 시 단가·응답 속도
연동 확장	시스템·부서 추가 시 방식
권한·멀티테넌시	부서별 데이터·권한 분리

연동 확장은 시스템 구조에서 특히 민감합니다. 처음엔 ERP 한 곳만 붙였다가 나중에 CRM·그룹웨어까지 늘릴 때, 표준 연동을 지원하는 제품이면 붙이기 쉽고 아니면 매번 개발이 필요하죠. 하마다랩스가 500개 이상 외부 시스템 연동을 다루는 것도 이 확장 국면을 미리 줄이기 위해서입니다.

확장성 항목은 작게 시작하는 결정과 짝을 이룹니다. 처음부터 전사로 크게 벌이면 검증 없이 예산이 커지지만, 한 부서로 좁혀 효과를 확인하고 넓히면 확장 조건을 실측으로 채운 뒤 계약을 조정할 수 있죠. 파일럿 설계 단계에서 확장 항목을 미리 계약에 걸어 두는 편이 유리합니다.

스무 개 항목을 하나의 표로 어떻게 정리하나요?

앞의 네 축에 계약·신뢰 축을 더하면 스무 개 항목이 한 장에 들어옵니다. 축마다 항목을 나누고, 각 항목을 충족·부분·미충족으로 표시하면 여러 후보를 같은 자로 비교할 수 있죠.

축	항목
운영(5)	복구 목표 시간 / 통보·에스컬레이션 / 모니터링·로그 / 유지보수·롤백 / 내부 운영 공수
보안(5)	데이터 위치 / 학습 재사용 / 온프레미스 / 접근·감사 로그 / 인증 범위
출구(4)	데이터 반환 / 파기 증빙 / 자산 이전 / 마이그레이션 경로
확장(3)	비용 곡선 / 연동 확장 / 권한 분리
계약·신뢰(3)	공급사 안정성 / 책임·배상 / 레퍼런스 검증

계약·신뢰 축의 세 항목은 제품이 아니라 공급사를 봅니다. 재무가 안정적인지, 장애·유출 시 책임과 배상 범위가 어디까지인지, 우리와 비슷한 규모·업종의 도입 사례를 실제로 확인할 수 있는지죠. AI 도입이 몇 년을 함께 가는 계약인 만큼, 제품만큼 공급사의 지속성이 결정에 든든한 근거가 됩니다.

스무 개를 다 채우기 어렵다면 우선순위를 세 단계로 나누면 됩니다. 없으면 계약하지 않을 결정적 결함, 협의로 풀 수 있는 항목, 있으면 좋은 항목으로 나누어, 결정적 결함부터 협상 테이블에 올리는 순서입니다. 표 오른쪽에 이 우선순위 열을 하나 더 두면 협상 자료가 그대로 완성되죠.

계약·신뢰 축 — 제품이 좋아도 공급사가 흔들리면 어떻게 되나요?

계약·신뢰 축은 제품이 아니라 함께 갈 파트너를 봅니다. AI 도입은 한 번 사고 끝나는 구매가 아니라 몇 년간 운영·업데이트가 이어지는 관계라, 공급사가 그 기간을 버틸 수 있는지가 결정의 바닥에 깔리죠.

먼저 재무 안정성입니다. 초기 스타트업 제품이 기능은 앞서도 서비스가 몇 년 안에 멈추면, 우리 업무에 들어온 에이전트도 함께 위태로워지거든요. 투자·매출 흐름과 고객 지속성 같은 신호를 도입 전에 확인해 두는 편이 뒤탈이 적습니다.

다음은 책임과 배상 범위입니다. 장애로 업무가 멈추거나 데이터가 새면 어디까지 책임지는지가 계약서에 적혀 있어야, 사고가 났을 때 대화가 성립하죠. 배상 상한이 지나치게 낮으면 그 조항은 이름만 있는 셈입니다.

재무 안정성 — 투자·매출·고객 지속성 등 서비스 지속 신호.
책임·배상 — 장애·유출 시 책임 범위와 배상 상한.
레퍼런스 검증 — 우리와 비슷한 규모·업종의 실제 도입 사례.

레퍼런스는 로고가 아니라 통화로 확인합니다. 비슷한 규모·업종의 도입 고객과 짧게라도 이야기해 보면, 제안서에 없던 운영의 실제가 드러나거든요. 하마다랩스가 도입 상담에서 유사 사례를 연결해 드리는 것도 이 검증을 돕기 위해서죠.

체크리스트에서 부분 충족 항목은 어떻게 처리하나요?

부분 충족은 흑백으로 자르지 않는 것이 요령입니다. 온프레미스를 지금은 지원하지 않지만 로드맵에 있다거나, 데이터 반환은 되는데 형식이 표준이 아닌 경우처럼, 조건을 붙이면 통과할 수 있는 항목이 많거든요.

이런 항목은 조건을 계약서 문구로 바꾸는 편이 안전합니다. “언제까지 어떤 기능을 제공한다”를 부속 합의로 적어 두면, 구두 약속이 이행 의무가 되죠. 부분 충족을 그냥 통과로 넘기면 나중에 “그건 계획이었을 뿐”이라는 답을 듣게 됩니다.

판단이 어려운 항목은 다른 눈에게 검산을 맡기면 숨은 낙관이 드러납니다. 제품을 검토한 사람과 다른 담당이 각 항목의 근거를 되물으면, 부분 충족을 충족으로 후하게 잡은 칸이 보이거든요. 도입 상담에서 저희가 먼저 하는 일도 고객이 매긴 점수의 근거를 함께 짚는 작업입니다.

IT팀장이 가장 자주 놓치는 항목은 무엇인가요?

현장에서 반복해 비는 항목은 대체로 정해져 있습니다. 아래 다섯 가지는 기능·가격에 가려 결정 자리에서 언급조차 되지 않는 경우가 많죠.

출구 조항 — 종료 시 데이터·자산 회수 조항이 계약서에 아예 없는 경우.
내부 운영 공수 — 예외 처리에 드는 우리 쪽 인력을 0으로 둔 경우.
학습 데이터 재사용 — 우리 데이터가 공급사 모델 학습에 쓰이는지 안 물어본 경우.
확장 시 비용 곡선 — 파일럿 단가만 보고 전사 확대 비용을 안 따진 경우.
마이그레이션 경로 — 종속을 협상력으로 넘겨주는 줄 모르고 지나친 경우.

다섯 중 파급이 가장 큰 것은 출구 조항과 확장 비용입니다. 출구가 비면 재계약에서 협상력을 잃고, 확장 비용을 안 따지면 전사 도입 단계에서 예산이 갑자기 부풀거든요. 두 항목은 도입 시점엔 조용하다가 2년 차에 목소리를 냅니다.

이 항목들이 자주 빠지는 이유는 어렵기 때문이 아니라, 물어볼 생각을 안 하기 때문입니다. 체크리스트가 하는 일이 바로 이 “물어볼 생각”을 표로 강제하는 것이죠. 항목이 표에 적혀 있으면, 어색해서 넘기던 질문도 절차가 되어 자연스럽게 던지게 됩니다.

놓친 항목을 되살리는 비용은 시점에 따라 크게 벌어집니다. 계약 전이라면 문구 한 줄로 끝나지만, 서명 뒤에 발견하면 부속 합의나 재계약이 필요해 협상이 다시 열리거든요. 그래서 이 다섯 항목은 후보를 좁히는 단계에서 미리 표에 박아 두는 편이 낫습니다.

체크리스트를 임원 보고와 계약에 어떻게 연결하나요?

체크리스트는 점검으로 끝나지 않고 두 문서로 이어집니다. 하나는 임원 보고용 사업성 문서이고, 다른 하나는 실제 계약서·SLA죠. 점검 결과가 이 둘로 흘러가야 결정이 문서로 남습니다.

임원 보고에는 체크리스트의 결정적 결함과 그 대응을 요약해 담습니다. “기능·가격은 A가 우위지만 출구 조항이 비어 B로 정했다”처럼, 점검 항목이 결정의 근거가 되면 보고가 취향이 아니라 기준으로 읽히거든요. 이 문서의 구조는 임원 보고용 사업성 분석서 구조에 정리해 두었습니다.

계약서에는 체크리스트의 각 항목을 조항으로 옮깁니다. SLA의 복구 시간, 데이터 처리 위치, 출구 반환 형식, 확장 단가 구간을 문구로 적으면, 점검이 이행 의무로 바뀌죠. 표의 칸 하나하나가 계약서의 한 줄이 되는 셈입니다.

어떤 항목을 결정적 결함으로 볼지, 부분 충족을 어떤 조건으로 계약에 담을지 함께 설계하고 싶으시면 도입 상담·점검 문의로 현재 검토 중인 후보와 우리 조직의 제약을 보내 주세요. 체크리스트를 우리 상황에 맞게 함께 채워 드립니다.

자주 묻는 질문

체크리스트는 몇 개 항목이 적당한가요? 스무 개가 너무 많지 않나요?

규모에 맞게 줄여도 됩니다. 항목이 적은 소규모 조직은 각 축에서 결정적 결함에 해당하는 항목만 골라 열 개 안팎으로 써도 충분하죠. 관건은 개수가 아니라 운영·보안·출구·확장이라는 네 축을 한 항목이라도 반드시 포함하는 것입니다.

온프레미스를 지원하지 않는 공급사는 후보에서 빼야 하나요?

우리 데이터의 민감도에 달렸습니다. 외부 반출이 규제로 막힌 데이터를 다룬다면 온프레미스·프라이빗 배포가 결정적 결함이 되지만, 그렇지 않다면 접근 권한과 학습 재사용 조항으로 위험을 낮출 수 있죠. 데이터 등급을 먼저 나눈 뒤 이 항목의 무게를 정하시길 권합니다.

출구 조항은 계약서 어디에 어떻게 넣나요?

일반 조항이 아니라 데이터·자산 항목으로 구체적으로 적는 편이 안전합니다. 반환 형식과 기한, 파기 증빙, 프롬프트·설정 자산의 소유 주체를 각각 문장으로 명시하면 종료 시점의 다툼이 줄어들죠. 표준 포맷으로 내보내는 제품 기능이 있는지도 함께 확인하세요.

작은 회사도 SLA를 요구할 수 있나요?

요구할 수 있고, 요구하는 편이 낫습니다. 규모가 작다고 장애 대응 시간과 통보 경로를 비워 두면 정작 사람이 적어 장애의 타격이 더 크거든요. 완벽한 조항이 아니라 복구 목표 시간과 통보 경로 한 줄이라도 계약에 넣는 것이 시작입니다.

체크리스트 점검은 도입 전 어느 시점에 하나요?

후보를 두세 곳으로 좁힌 뒤, 계약서 초안을 받기 전에 하는 것이 좋습니다. 이 시점에 점검하면 결정적 결함을 협상 테이블에 올릴 시간이 남고, 부분 충족 항목을 계약 문구로 바꿀 여지도 생기죠. 서명 직전에 하면 발견해도 되돌리기 어렵습니다.

여러 후보를 같은 체크리스트로 비교하면 편향이 생기지 않나요?

같은 자로 재는 것이 오히려 편향을 줄입니다. 후보마다 다른 기준으로 평가하면 인상이 결정을 좌우하지만, 스무 개 항목을 같은 척도로 채우면 강점과 약점이 항목 단위로 드러나죠. 점수를 매긴 근거를 항목마다 한 줄로 적어 두면 비교의 객관성이 한층 올라갑니다.

참고 자료

가트너(Gartner), “Gartner Says AI Projects in I&O Stall Ahead of Meaningful ROI Returns”, 2026년 4월 7일 보도자료 — 인프라·운영 리더 782명 조사, AI 활용 사례 중 ROI 온전 충족 28%·완전 실패 20%, 실패 1회 이상 경험 57%(원인으로 과도한 기대 다수 지목)(2026-07-22 확인): https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-says-artificial-intelligence-projects-in-infrastructure-and-operations-stall-ahead-of-meaningful-roi-returns
ISO/IEC 27001:2022, “Information security management systems — Requirements” — 부속서 A 93개 통제 항목 기반 정보보안 관리 체계 요구(2026-07-22 확인): https://www.iso.org/standard/27001
ISO/IEC 42001:2023, “Information technology — Artificial intelligence — Management system” — AI 관리 체계 국제표준(2026-07-22 확인): https://www.iso.org/standard/81230.html
하마다랩스 자체 도입 구축 관찰(2026년, 기술총괄): 좋은 제품을 고르고도 출구 조항·내부 운영 공수·확장 비용이 계약서에 빠져 2년 차에 분쟁·예산 초과로 이어진 반복 패턴 — 익명 집계, 특정 고객 사례 아님
하마다랩스 플랫폼·회사 소개(500개 이상 외부 시스템 연동·온프레미스 배포 지원): https://www.hamadalabs.com/platform · https://www.hamadalabs.com/about

작성자

이득기 — 하마다랩스 공동 창업자이자 기술총괄(CTO). 기존 ERP·CRM을 교체하지 않고 AI 에이전트를 연동하는 구축 방식, SAP·더존 등 전사 시스템 통합, 데이터가 외부로 유출되지 않는 온프레미스 보안 아키텍처와 도입 전 점검 항목을 시스템 구조 관점에서 다룹니다. 회사 소개: https://www.hamadalabs.com/