Coze 워크플로우의 서드파티 Python 라이브러리는 가져올 수 없고, 문제는 '패키징하지 않았다'는 것처럼 보이지만, 실제로는 그렇게 간단하지 않은 경우가 많습니다. 공개 이슈에서는 '요청'이 'code_server' 컨테이너에 설치되더라도 런타임 가져오기가 실패했다고 언급되었습니다. 가장 쉬운 함정은 라이브러리를 설치하는 환경과 실제로 워크플로우가 실행되는 환경이 다르다는 점입니다.
Coze Studio의 공식 오픈소스 저장소는 아직 https://github.com/coze-dev/coze-studio 상태입니다. 공식 README의 전반적인 아이디어는 워크플로우, 플러그인, 지식 베이스, 코드 실행을 별도의 '네이티브 Python 환경'이 아닌 완전한 연결고리로 취급한다는 것입니다.
왜 "이미 설치했습니다"라는 말이 아직도 작동하지 않는 이유
워크플로우 노드는 보통 격리된 환경에서 실행되기 때문에, 수동으로 컨테이너에 넣고 패킹한 레이어를 직접 재사용하지 않을 수도 있습니다. shell에 설치한다고 해서 실행 노드, 이미지 계층, 런타임 이미지에도 이 패키지가 있다는 뜻은 아닙니다. 특히 온프레미스 배포 시나리오에서는 컨테이너, 이미지, 코드 실행 서비스가 분리되어 있어 '분명히 설치했는데 시스템이 여전히 안 된다'는 착각이 가장 자주 발생합니다.
지역사회에서 흔히 사용하는 치료 아이디어
- 먼저, 내장 라이브러리로 해결 가능한지 확인하고, 서드파티 패키지에 의존하지 마세요.
- 서드파티 라이브러리를 꼭 사용해야 한다면, 현재 셸이 아니라 어떤 실행 중인 이미지에 설치되어 있는지 확인하세요.
- 복잡한 로직을 외부 서비스에 넣고, 모든 로직을 파이썬 노드에 몰아넣지 말고 Coze가 인터페이스를 조정하도록 하세요.
매우 실용적인 판단 방식입니다
같은 코드가 컨테이너에서 네이티브나 수동으로 실행할 수 있지만 워크플로우 노드에서는 실행이 안 된다면, 문제는 Python 자체가 아니라 실행 컨텍스트에 있습니다. 이 시점에서는 워크플로우 런타임, 이미지 레이어, 의존성 화이트리스트를 확인하는 것이 반복적인 'pip install'보다 보통 더 효과적입니다.
공개 이슈에서 이러한 문제에 대한 피드백은 매우 일관적입니다: 설치 작업에만 집중하지 말고, 코드가 어떤 환경에서 실행되는지 확인하세요. 실행 환경을 이해한다면, 많은 '패키지 가이드 실패'가 실제로 '잘못된 설치 위치'로 이어질 수 있습니다.
한 문장 결론
Coze 워크플로우의 Python 패키지가 작동하지 않는 이유는 보통 설치하지 않아서가 아니라 잘못된 환경을 설치했기 때문입니다. 먼저 실행 컨테이너를 확인한 후, 의존성 설치에 대해 이야기하면 훨씬 효율적입니다.
