약 8분 읽기
안녕하세요, RPA 엔지니어 황민입니다. 오늘은 제가 겪었던, 어쩌면 많은 IT 담당자들이 마주했을 법한 난관에 대한 경험담을 풀어볼까 합니다. 바로 온프레미스 환경에 구축된 UiPath Orchestrator에 외부 AI 챗봇을 연동하는 시도였죠. 특히 내부망이라는 폐쇄적인 환경에서 외부 서비스를 끌어오는 일은 늘 도전의 연속이었습니다. 이번에는 Dify라는 오픈소스 AI 챗봇 플랫폼을 활용해보기로 마음먹었습니다. 과연 이 둘의 조합은 성공적이었을까요? 솔직하게 제 경험을 공유해 드리겠습니다.
도전 과제: 온프레미스 UiPath Orchestrator와 외부 AI 챗봇 연동
제가 담당하고 있는 프로젝트는 온프레미스 환경에서 운영되는 UiPath Orchestrator를 사용하고 있었습니다. 이는 곧 모든 데이터와 프로세스가 외부 인터넷망이 아닌, 내부망 안에서만 처리되어야 함을 의미합니다. 여기에 최신 AI 기술 트렌드에 발맞춰 챗봇 기능을 도입하려 했고, 그 대상으로 Dify를 선택했습니다. Dify는 직접 구축하고 커스터마이징하기 용이하다는 장점 때문에 매력적이었죠. 문제는 이 둘을 어떻게 연결하느냐였습니다. 특히 내부망에서 외부 서비스를 호출하는 것은 보안상의 이유로 여러 제약이 따르기 마련입니다.
첫 번째 난관: Swagger URL의 허와 실
외부 서비스와 연동할 때 가장 먼저 확인하는 것이 API 문서, 그중에서도 Swagger(OpenAPI) 명세입니다. Dify 역시 API를 제공하고 있었기에, 이를 통해 UiPath에서 Dify의 기능을 호출할 수 있을 것이라고 기대했습니다. 하지만 온프레미스 환경의 제약은 여기서부터 시작되었습니다. Dify를 내부망에 설치했음에도 불구하고, Swagger URL에 접근하는 것부터가 쉽지 않았습니다. 내부에서 외부로 나가는 트래픽은 허용되더라도, 외부에서 내부의 특정 서비스로 들어오는 트래픽은 철저히 차단되어 있었기 때문입니다. 결국 Swagger URL을 단순히 외부에서 접근 가능한 URL이라고 생각했던 제 오산이었습니다. 내부망에서 Dify의 API를 호출하기 위한 방법을 찾아야 했습니다. 다행히 Dify는 자체적으로 API 엔드포인트를 제공하고 있었고, 이를 내부망에서 직접 호출하는 방식으로 접근을 수정했습니다. 하지만 이 과정에서 API 엔드포인트가 정확히 무엇인지, 어떤 형식으로 요청을 보내야 하는지에 대한 깊은 이해가 필요했습니다. Swagger 문서가 없더라도 API 명세만 있다면 충분히 가능하지만, 명확한 문서화가 되어있지 않다면 디버깅에 더 많은 시간을 쏟아야 했을 겁니다.
두 번째 난관: 테넌트와 인증의 복잡성
UiPath Orchestrator는 테넌트라는 개념을 사용하여 여러 조직이나 팀이 하나의 인스턴스를 공유할 수 있도록 합니다. Dify 역시 사용자 및 애플리케이션 관리를 위한 인증 메커니즘이 필요했죠. 문제는 이 둘의 인증 방식을 어떻게 일치시키느냐였습니다. UiPath에서 Dify API를 호출할 때, Dify가 요구하는 API 키나 인증 토큰을 어떻게 안전하게 전달할 것인가가 관건이었습니다. 처음에는 단순히 Dify에서 발급받은 API 키를 UiPath의 Credential Manager에 저장하여 사용하는 방식을 고려했습니다. 하지만 이는 관리 측면에서 비효율적일 뿐만 아니라, API 키가 노출될 경우 보안상 큰 위험이 될 수 있었습니다. 결국, Dify의 사용자 인증 방식을 좀 더 깊이 파고들어야 했습니다. Dify는 OpenAI API 키를 사용하여 LLM 모델을 호출하는 방식과 자체적인 API 키 발급 방식을 모두 지원하고 있었습니다. 저는 Dify에서 직접 API 키를 발급받아 UiPath의 Credential Manager에 안전하게 저장하고, 해당 API 키를 사용하여 Dify의 특정 엔드포인트로 요청을 보내는 방식으로 해결했습니다. 이 과정에서 각 테넌트별로 다른 API 키를 발급받아 관리하는 방안도 고려했지만, 초기 단계에서는 단일 API 키로 통합하여 관리하는 것이 더 효율적이라고 판단했습니다.
세 번째 난관: 네트워크 구성의 묘수
이 프로젝트에서 가장 큰 허들이었던 부분은 바로 네트워크였습니다. 내부망에 있는 UiPath Orchestrator가 내부망에 설치된 Dify의 API 엔드포인트를 호출하는 것은 비교적 간단했습니다. 하지만 이 시나리오에서 제가 실제로 마주했던 문제는, 외부 인터넷망에 있는 LLM 모델(예: OpenAI)을 Dify를 통해 호출하는 것이었습니다. Dify는 자체적으로 LLM 모델을 호스팅할 수도 있지만, 외부의 강력한 모델을 사용하는 것이 일반적입니다. 문제는 UiPath Orchestrator가 위치한 내부망에서 외부 LLM 모델 서비스로 직접 통신하는 것이 차단되어 있다는 점이었습니다. 이를 해결하기 위해 몇 가지 방안을 시도했습니다.
- 프록시 서버 활용: 가장 먼저 떠올린 방법은 내부망에서 외부로 나가는 트래픽을 중계해 줄 프록시 서버를 구축하는 것이었습니다. UiPath Orchestrator가 프록시 서버를 통해 Dify API를 호출하고, Dify는 다시 프록시 서버를 통해 외부 LLM 모델에 접근하도록 구성하는 방식입니다. 하지만 이 방법은 프록시 서버 자체의 구축 및 관리 부담이 크고, 네트워크 설정이 복잡해진다는 단점이 있었습니다.
- NAT 게이트웨이 구성: 내부망의 특정 서버에 NAT(Network Address Translation) 게이트웨이 역할을 수행하도록 설정하여, 해당 서버를 통해서만 외부 인터넷으로 통신하도록 하는 방식도 고려했습니다. 이는 비교적 간단한 네트워크 설정으로 외부 통신을 가능하게 할 수 있다는 장점이 있지만, 특정 서버에 부하가 집중될 수 있다는 단점이 있었습니다.
- Reverse Proxy (Nginx 등) 활용: 최종적으로 제가 선택한 방법은 Nginx와 같은 리버스 프록시 서버를 활용하는 것이었습니다. Dify 서버 자체에 Nginx를 설치하고, 외부 LLM 모델과의 통신을 위한 프록시 설정을 추가했습니다. 즉, Dify는 내부망에서 작동하지만, 외부 LLM 모델에 접근해야 할 때는 Nginx를 통해 마치 외부에서 접근하는 것처럼 통신하도록 구성한 것입니다. 이 방법은 별도의 서버를 구축할 필요 없이 Dify 서버에서 모든 것을 처리할 수 있다는 점에서 효율적이었습니다. 물론 Nginx 설정 파일 작성에 대한 이해가 필수적이었습니다. API 키 관리, SSL 인증서 설정 등 추가적인 고려사항도 있었지만, 내부망에서 외부 서비스로의 접근을 제어하는 데 가장 유연한 방법이었습니다.
이 과정에서 가장 중요했던 것은 네트워크 담당자분들과의 긴밀한 협업이었습니다. 내부망 환경에 대한 이해와 보안 정책을 바탕으로 최적의 솔루션을 찾아나가야 했기 때문이죠. 단순히 기술적인 문제 해결을 넘어, 조직 내 다른 팀과의 소통과 협업의 중요성을 다시 한번 느낄 수 있었습니다.
결론: 가능하지만, 철저한 준비가 필요하다
최종적으로 온프레미스 UiPath Orchestrator와 Dify 챗봇의 연동은 성공적으로 마무리되었습니다. 내부망이라는 제약 속에서도 Swagger URL, 테넌트 및 인증, 그리고 네트워크 구성이라는 세 가지 주요 난관을 극복할 수 있었습니다. 특히 네트워크 구성 부분에서는 리버스 프록시 활용이 가장 효과적인 해결책이었습니다.
이 경험을 통해 몇 가지 교훈을 얻었습니다. 첫째, 온프레미스 환경에서는 외부 서비스와의 연동 시 항상 네트워크 제약을 최우선으로 고려해야 합니다. 둘째, Swagger 문서가 없더라도 API 명세만 있다면 충분히 연동이 가능하지만, 명확한 문서화는 개발 시간을 단축시키는 데 큰 도움이 됩니다. 셋째, 테넌트 및 인증 방식에 대한 깊이 있는 이해는 보안과 관리 효율성을 동시에 높이는 열쇠입니다. 마지막으로, 이러한 기술적인 도전은 혼자만의 힘으로는 어렵습니다. 네트워크, 보안 등 관련 부서와의 긴밀한 협업이 필수적입니다.
만약 여러분도 비슷한 환경에서 AI 챗봇 연동을 고민하고 계신다면, 오늘 제가 공유해 드린 경험이 작은 도움이 되기를 바랍니다. 쉽지 않은 과정이었지만, 그만큼 값진 경험이었고, 앞으로 더 복잡한 자동화 시스템을 구축하는 데 든든한 밑거름이 될 것이라고 생각합니다. 다음에는 또 어떤 흥미로운 자동화 이야기로 돌아올지 기대해 주세요!
