에이전틱 오케스트레이션이 처음이신가요? 여기서 시작하세요.
현실적으로 말해봅시다. AI 에이전트는 구축하고 배포하기 쉽지 않습니다. 하지만 일단 임베디드되면 임팩트는 엄청납니다. UiPath 고객인 아이나라 에체안디아 사가스티(Ainara Etxeandia Sagasti), 란틱(Lantik) 디지털 서비스 책임자가 "RPA, 생성형 AI, 에이전틱 기술을 결합해 공공 서비스를 그 어느 때보다 접근 가능하고 효율적이며 시민 중심으로 만들고 있다"고 말한 것을 듣는 게 기쁩니다. 이미 UiPath 플랫폼™에서 10,000개 이상의 AI 에이전트가 구축되었습니다. 에이전트는 프로세스 효율성과 수익성을 변혁할 수 있지만, 강력한 오케스트레이션과 자동화, 루프 내 인간의 도움이 필요합니다.
이 블로그 포스트에서는 AI 에이전트를 규모 있게 구축, 테스트, 배포할 때 가장 흔한 고통 지점을 다룰 것입니다. 또한 통제된 자율성과 상호운용성에 기반한 오케스트레이션 접근법이 어떻게 이를 완화할 수 있는지 설명하겠습니다.
개발자와 사용자는 AI 에이전트의 신뢰성 부족을 프로덕션 진입 장벽으로 자주 꼽습니다. 대규모 언어 모델(LLM)은 에이전트를 유연하고 적응력 있게 만들지만, 이는 일관되지 않은 출력으로 이어지기도 합니다. 이는 개발과 테스트를 좌절시킵니다. 한 엔지니어는 "내 에이전트는 때론 완벽하게 작동하다가 비슷한 입력에서 완전히 실패한다. 엣지 케이스를 시뮬레이션하고 실패를 일관되게 재현하는 더 나은 방법이 필요하다... 시간이 지남에 따라 에이전트 '드리프트'를 모니터링하는 건 진짜 골칫거리다"라고 말했습니다.
또 다른 과제는 할루시네이션입니다. 에이전트가 사실이나 도구 입력을 꾸며내 프로세스를 멈추게 합니다. AI 워크플로를 구축하는 한 사용자는 "우리가 발견한 가장 큰 고통점은 반복성과 할루시네이션이다... 동일하거나 유사한 쿼리에 대해 LLM 에이전트가 궤도를 벗어나 다른 도구에 할루시네이트된 입력을 주지 않게 보장하는 것"이라고 공유했습니다. 이 예측 불가능성은 광범위한 테스트와 검증을 필요로 하지만, 에이전트 테스트 도구는 미성숙합니다. 오류 발생 시 불투명한 모델 추론 때문에 진단이 어렵습니다. 이는 팀이 변경에 극도로 신중하게 만듭니다: "시스템 프롬프트 변경을 너무 경계하게 됐다. 에이전트에게 무언가를 하지 말라고 했더니 갑자기 이상하게 행동하기 시작해서... 여러 번 당했다."
기저 AI 모델의 성능도 또 다른 문제입니다. 큰 모델은 리소스 집약적이거나 느릴 수 있고, 작은 모델은 성능이 떨어질 수 있습니다. 적절한 균형을 찾는 게 어렵습니다.
일관되고 신뢰할 수 있는 출력 부족은 광범위한 안전장치 없이 미션 크리티컬하거나 고객 대면 작업에 AI 에이전트를 신뢰하기 어렵게 만듭니다. 실제로는 에이전트 행동을 단순화하거나, 엄격한 제약을 도입하거나, 폴백(끊임없는 인간 개입 등)을 둠으로써 높은 신뢰성을 달성하곤 합니다. 하지만 이런 조치는 에이전트 자율성, 효율성, 그리고 따라서 가치를 더하는 엔터프라이즈 시나리오에서의 유용성을 손상시키는 경향이 있습니다.
AI 에이전트가 복잡한 작업을 자동화할 수 있지만, 개발자는 인간 감독과 협업이 필수적임을 발견합니다. 적절한 균형을 맞추는 건 어렵습니다. 완전히 손을 떼는 자율성은 에이전트가 실수하거나 불명확한 결정을 내릴 수 있어 종종 비현실적입니다. 기업은 자율성 정도를 통제해야 하며, 이는 에이전트가 더 정확하고 신뢰할 수 있게 되면서 시간이 지남에 따라 증가할 수 있습니다.
일반적 접근은 특정 승인이나 예외 처리를 위해 '인간 인 더 루프'를 두는 것이지만, 잘 오케스트레이션되지 않으면 프로세스를 늦출 수 있습니다. 그런 다음 '인간 인 더 루프'는 특정 승인, 중요한 결정, 예외 처리를 위해 호출됩니다. 한 AI 엔지니어는 에이전트를 제약하고 인간을 개입시키는 것이 더 나은 결과로 이어진다고 지적했습니다: "인간 감독 하의 엄격하게 제약된 LLM은 중간 복잡도 작업에 좋은 결과를 낼 수 있다... [완전] 자율적 범용 에이전트 [규모 있게]는 아직 현실적이지 않다."
반면, AI가 너무 엄격하게 통제되거나 끊임없는 확인을 요구하면 ROI를 내지 못합니다. 때로 에이전트는 워크플로를 방해하거나 절약하는 것보다 더 많은 노력을 만듭니다. 예를 들어 한 개발자는 코딩 코파일럿이 수동 수정을 강요해 생산성을 방해했다고 설명했습니다: "시작은 하지만 끝내지 못한다... 나는 태그, 괄호 등을 확인하고 닫기 위해 주의를 돌려야 한다. 내 흐름을 방해해 속도를 늦춘다."
과제는 에이전트가 일을 처리하지만 판단이 필요할 때 추가 마찰 없이 매끄럽게 인간에게 넘겨주는 하이브리드 워크플로를 설계하는 것입니다.
AI 에이전트 ROI는 사용이 확장됨에 따라 반복되는 우려입니다. LLM API(와 이를 실행하는 인프라)는 비쌀 수 있습니다. 팀은 에이전트가 최적화되지 않으면 비용 폭증을 걱정합니다. 한 사용자는 현재 에이전트가 "성취하는 것에 비해 너무 비싸다"고 주장했습니다. 신뢰성이 낮으면 ROI 측정이 어렵습니다. 에이전트가 부분적으로만 성공하면 그 실패 비용(과 수동 수정)이 이점을 능가할 수 있습니다.
기업은 모델 최적화와 사용 정책 같은 방법으로 비용을 통제하려 합니다. 한 사용자는 반복 호출을 줄이기 위해 캐싱을 구현하고, 출력 효율을 높이기 위해 고품질 데이터를 신중히 소싱한다고 설명했습니다. 다른 이들은 작업에 적합한 모델 선택에 집중합니다: "프롬프트를... 모든 다른 모델에서 실행해 [가장 좋고 저렴한 것을] 찾는 프레임워크가 있으면 좋겠다. 지금 내 AI 에이전트는 200개 넘는 프롬프트 템플릿을 쓰는데, 모두 테스트하고 재테스트하는 건 비싸다." 궁극적으로 프롬프트 엔지니어링과 모델 실험은 실제 비용을 발생시킵니다.
공급업체 가격 모델(토큰당, 호출당 등)도 역할을 합니다. 예를 들어 모든 것에 GPT-4를 쓰는 건 오버킬일 수 있지만, 더 싼 모델을 쓰면 품질이 떨어질 수 있습니다. 팀은 ROI를 정당화하기 위해 균형을 맞춰야 합니다. 게다가 명확한 승리(매출 증대나 자동화로 인한 비용 절감)가 없으면 지속적인 클라우드 AI 서비스나 특수 인프라 지출을 방어하기 어렵습니다. 따라서 비용 최적화와 ROI 증명이 최우선입니다. 팀은 "내 돈으로 최고의 효과를" 보기 위해 모델을 혼합·매칭하면서 고가치 유스케이스에 집중하려 합니다.
조직은 AI 에이전트에 보안, 컴플라이언스, 윤리 가이드라인을 시행해야 하지만, 이는 말보다 어렵습니다. 데이터 프라이버시는 최우선 관심사입니다. 많은 기업이 민감 데이터 유출 확신이 들 때까지 클라우드 AI 서비스를 금지하거나 제한합니다. 한 개발자는 직장에서 ChatGPT 같은 도구를 지적 재산 위험 때문에 금지한다고 공유했습니다: "안 된다. IP 위험이 너무 크다, [우려:] 우리 비밀이 새거나 타인 저작권 침해 가능." 서드파티 AI API 사용 시 실수로 고객 데이터가 해당 서비스로 전송될까 걱정합니다.
보안도 또 다른 이슈: 자율 에이전트는 적절히 샌드박싱되지 않으면 위험을 초래합니다. 팀이 에이전트 플랫폼 위에 추가 보호 장치를 얹은 보고가 있습니다. 예: "리드 생성 에이전트 배포 시 [보안] 레이어를 추가해야 했다... [그리고] 비용 최적화를 위해 캐싱(Redis) 사용." 즉시 사용 가능한 솔루션엔 종종 엔터프라이즈급 보안 제어나 비용 관리가 부족해 기업이 직접 거버넌스를 덧대야 합니다. 또한 에이전트 프레임워크가 감독을 위한 후크를 제공하지 않으면 규정(GDPR, HIPAA 등) 준수와 조직 정책 준수를 보장하기 어렵습니다.
이런 우려로 이해관계자는 신중해집니다: AI 에이전트가 강력하길 원하지만, "중립적이고 보편적으로 인정된 프로토콜"로 투명하고 통제되길 원합니다. "데이터 사용 방식을 숨기는 독점 시스템"이 아닌. 요컨대, 견고한 거버넌스 기능(감사 로그, 권한 제어, 인간 오버라이드 등) 없이는 많은 조직이 광범위한 에이전트 배포에서 벽에 부딪힙니다.
AI 에이전트를 개념 증명에서 프로덕션으로 옮기면 여러 이슈가 생깁니다. 사용자는 통제된 데모에서 작동하던 것이 실제 규모, 볼륨, 복잡성에서 고전한다고 보고합니다. 흔한 우려에는 지연 시간과 처리량(LLM 기반 에이전트는 고트래픽이나 실시간 애플리케이션에 너무 느릴 수 있음), 시스템을 안정적으로 운영하는 운영 오버헤드가 있습니다. 아드리안 크렙스(Adrian Krebs), Kadoa 공동창업자 겸 CEO는 "오케스트레이션 프레임워크를 쓰든 안 쓰든 기저 이슈가 AI 에이전트가 [너무] 느리고, 비싸고, 신뢰할 수 없다면 중요하지 않다"고 말했습니다. 팀은 효율성을 위해 재설계가 필요합니다(캐싱 사용, 모델 교체, 에이전트 로직 단순화 등) - 그저 성능 요건을 맞추기 위해.
일관성을 유지하면서 환경 간(클라우드, 온프레미스, 에지 디바이스) 배포하는 것도 과제입니다. 엔터프라이즈 환경에서 모든 부서가 같은 도구를 원하진 않아 표준화된 배포를 더 어렵게 만듭니다. 모니터링, 로깅, 현장 에이전트 업데이트 같은 운영 확장 이슈도 마찬가지로 미개발 상태입니다. 한 레딧 사용자는 기본 디버깅조차 "악몽... 에러 로그가 종종 암호적이고 명확한 트러블슈팅 가이드가 없다"고 지적했습니다. 이는 많은 에이전트가 배포될 때만 더 힘들어집니다. 이 모든 게 에이전트 도입을 늦출 수 있습니다. 주요 공급업체조차 고객이 "이제 막 시작하는 중"이고 의미 있는 규모 있는 결과는 아직 나오고 있다고 인정했습니다.
여러 AI 에이전트가 협업하는 시스템을 구축하는 건 까다롭습니다. 개발자는 에이전트 역할 조정, 공유 상태 관리, 에이전트가 루프에 빠지거나 서로 충돌하는 것 방지에 고전합니다. 오케스트레이션 프레임워크가 있어도 한 에이전트 출력의 실수가 전체 워크플로를 탈선시킬 수 있습니다. 한 개발자는 "사람들은 그저 실험 중이다. 예측 불가능성이 여전히 주요 이슈다: 자기회귀 생성 과정에서의 어떤 탈선도 에이전트에게 치명적일 수 있다"고 주장했습니다. 다른 이들은 자가 치유나 복원력 있는 워크플로 생성의 어려움을 강조합니다. 예: 실패 단계 재시도나 인간 개입 로직 추가.
이런 오케스트레이션 과제는 팀이 한 이슈를 고치면 다른 게 나타나는 '두더지 잡기' 같은 상황에 빠지게 합니다: "가끔 두더지 잡기 같다. 프롬프트 엔지니어링으로 한 이슈를 고치면 세 개가 더 생긴다."
시장을 지배하는 단일 AI 에이전트는 없습니다. 조직은 오늘 오픈AI를 쓰고, 내일 오픈소스 모델로 바꾸고, 다양한 서드파티 도구를 통합할 수 있습니다. 하지만 호환성과 원활한 통합은 주요 과제입니다. 도구와 모델 통합엔 종종 커스텀 어댑터나 접착 코드가 필요합니다. 예를 들어 에이전트를 독점 데이터베이스나 내부 API에 연결하는 건 프레임워크가 그걸 염두에 두지 않았다면 상당한 노력이 들 수 있습니다. 개발자는 많은 프레임워크가 "무겁고" 모든 유스케이스에 맞지 않는 가정을 가진다고 주장합니다: "불행히도 이런 프레임워크 다수는 기초만 필요할 때 꽤 무겁다."
반대로 "프레임워크 불가지론"을 택하면 종종 처음부터 많은 보일러플레이트를 써야 합니다. 사용자는 바퀴를 재발명하지 않으면서도 락인(lock-in)당하지 않길 원합니다. 한 개발자는 호환성을 극대화하기 위해 더 유연한 라이브러리에 정착했다고 설명했습니다: "여럿 시도했다... 결국 [Instructor] 사용에 정착했다. LLM을 빠르게 전환할 수 있었기 때문 – 로컬/오픈소스와 독점 모두 – 그리고 어디서든 같은 정형 입출력을 가질 수 있었다." 이는 진화하는 니즈를 충족하기 위해 AI 모델이나 서비스를 쉽게 교체할 수 있는 에이전트의 필요성을 강조합니다.
또 다른 흔한 니즈는 기존 소프트웨어 스택과 워크플로에 에이전트 통합입니다. 표준 인터페이스 부족으로 각 새 에이전트마다 새로운 통합 노력이 필요할 수 있습니다. 빠진 예제와 고급 설정이 이를 방해할 수 있습니다. 게다가 한 컴포넌트 업데이트(예: LLM API 변경)가 에이전트 로직을 깨뜨리는 호환성 이슈도 생깁니다. 팀이 적극적으로 관리해야 할 부분입니다. 요컨대, 실무자는 플러그앤플레이 상호운용성을 원합니다: 광범위한 커스텀 엔지니어링 없이 다양한 모델, 데이터 소스, 시스템과 연결되는 AI 에이전트.
AI 모델과 프레임워크는 빠르게 변합니다. 많은 팀이 베스트오브브리드(best-of-breed)를 원하고, 단일 공급업체 AI 에이전트 솔루션 선택이 나중엔 경직되게 만들까 걱정합니다. 에이전트 프레임워크가 폭발적으로 늘어나 각자 고유한 API와 고려사항을 가집니다. 한 개발자는 자바스크립트 프레임워크 광풍에 비유했습니다: "몇 달 뒤 우리 버전의 '100가지 JS 웹 프레임워크로 만든 TODO 앱'이 나올 거다... 그냥 그것들을 다 이해하는 것만도 거대한 작업이다."
단일 생태계에 커밋하면 유연성이 제한될 수 있습니다. 특정 라이브러리는 특정 공급업체를 선호합니다. 예: 한 좌절한 사용자는 자신의 프레임워크 선택이 "주로 깨진다"고 경고하며, 일부 도구가 암묵적으로 특정 모델이나 서비스에 당신을 가둔다는 점을 지적했습니다. 위험은 공급업체 비전 주위에 구축했다가 나중에 "락인 – 업데이트, 가격, 정책에 의존, 실행 가능한 대안 없음" 상태가 되는 것입니다. 상호운용성은 기존 소프트웨어 스택에 에이전트 통합 시에도 우려됩니다. 개발자는 에이전트를 이미 사용하는 언어와 클라우드 서비스에 연결할 "명확한 예제"가 없어 다양한 팀에서 이 도구들 도입을 더 어렵게 만든다고 종종 발견합니다.
이러한 많은 과제는 유연하고, 상호운용 가능하며, 인간 중심적인 에이전틱 오케스트레이션 솔루션의 필요성을 가리킵니다. 에이전틱 오케스트레이션은 사람, 로봇, AI 에이전트 간 작업과 책임을 그들의 역량에 따라 효과적으로 관리, 할당해 운영이 매끄럽고 효율적이며 비즈니스 전략적 결과와 정렬되게 합니다.
신뢰할 수 있는 AI 에이전트, 결정론적 자동화, 인간 입력을 효과적으로 통합하는 오케스트레이션 레이어는 여러 이점을 제공합니다:
결정론적 백스톱을 통한 신뢰성 향상: 오케스트레이션 접근법의 이상적 최종 상태는 통제된 자율성으로, 과도한 수동 개입 없이 최적 효율을 허용합니다. 이는 기업급 도구, 결정론적 로봇, 편안한 수준의 인간 검토로 프로세스에서 신중하게 제약된 특화 AI 에이전트 오케스트레이션에 의존합니다. AI 에이전트를 결정론적 자동화 스크립트나 규칙과 결합함으로써 오케스트레이션 레이어는 항상 폴백 경로가 있음을 보장합니다. 예: AI 에이전트 출력이 특정 정확도 임계값을 충족하지 못하면 사전 정의된 규칙이 그 케이스를 처리(또는 최소한 플래그)합니다. 이 하이브리드 접근은 AI의 창의성을 가드레일 내에서 활용합니다. 시간이 지나면 오케스트레이션 플랫폼은 결과 모니터링을 통해 어떤 에이전트가 어떤 작업에 가장 신뢰할 수 있는지 학습하고, 그에 따라 작업을 라우팅해 성공률을 최적화할 수도 있습니다. 순 효과는 단일 블랙박스 에이전트보다 워크플로 전체 신뢰성이 높아지는 것입니다. 한 개발자가 지적했듯, "엄격하게 제약된 [에이전트]에 인간 감독"과 잘 정의된 프로세스가 신뢰할 수 있는 좋은 결과를 낳습니다. 정확히 오케스트레이션이 가능하게 하는 것입니다.
중앙화된 거버넌스와 보안: 공급업체 중립적 오케스트레이션 레이어는 모든 AI 활동에 보안과 컴플라이언스를 균일하게 시행할 수 있습니다. 각 에이전트로 전송되는 데이터를 모니터링하고, 민감 정보를 스크러빙하거나 익명화하며, 모든 에이전트 결정을 감사 목적으로 로깅하는 게이트웨이 역할을 할 수 있습니다. 이는 거버넌스 우려를 해결해 조직에 단일 통제 지점을 줍니다. 예: 관리자는 특정 데이터를 처리하도록 허용된 AI 모델을 구성하거나, 프라이버시 정책 때문에 특정 쿼리는 항상 온프레미스 모델이 처리하도록 요구할 수 있습니다. 그런 시스템은 역할 기반 에이전트 행동 제어를 위해 IAM(신원 및 접근 관리)과 통합될 수도 있습니다. 정책(속도 제한, 비용 예산 등)을 전역적으로 적용할 수 있습니다. 이 모든 역량은 기업이 원치 않는 데이터 유출이나 악성 행동을 방지하는 감독 레이어가 있음을 알기에 AI 에이전트를 더 자신 있게 도입하게 합니다.
상호운용성과 락인 회피: 중립적 오케스트레이션 레이어는 팀이 필요에 따라 다른 AI 모델이나 서비스를 꽂을 수 있게 해 단일 공급업체 생태계에 묶이지 않게 합니다. 이는 공급자 전환 시 모든 것을 재구축해야 할 공포를 완화합니다. 한 엔지니어가 주장했듯, 목표는 최종 사용자가 "공급업체 락인 걱정 안 하게... AI 시스템이 단일 공급업체 생태계에 사용자를 가두는 대신 플랫폼 간 원활히 작동하게" 하는 것입니다. 여러 AI 백엔드(오픈AI, 앤트로픽, 오픈소스 모델 등)에 '공통 언어'로 말함으로써 오케스트레이션 레이어는 항상 작업에 가장 적합한 도구를 선택하고 기술이나 가격 변화 시 피벗할 수 있게 합니다.
멀티 에이전트 조정과 특화: 오케스트레이션 플랫폼은 각자 서브태스크에 특화된 에이전트 팀을 관리하고, 그들의 상호작용을 결정론적으로 조정할 수 있습니다. 이는 실무자 복잡성을 줄입니다. 오케스트레이션 레이어가 태스크 라우팅, 상태 관리, 에이전트 간 오류 복구를 처리하기 때문입니다. 모든 걸 시도하는 단일 모놀리식 에이전트(종종 예측 불가능하게 실패) 대신, 특정 역할에 집중한 더 단순한 에이전트들을 두고 오케스트레이션 레이어가 이들을 연결할 수 있습니다. 그런 설정엔 AI가 필요하지 않은 작업을 위한 규칙 기반 자동화나 전통적 소프트웨어 컴포넌트도 포함될 수 있어, AI가 가치를 더하는 곳에만 쓰이게 합니다. 결과는 한 컴포넌트가 실패하거나 불확실한 출력을 내면 오케스트레이션 플랫폼이 잡아낼 수 있는(검증, 재시도, 폴백 등을 통해) 더 견고한 시스템입니다.
비용 최적화와 리소스 유연성: 공급업체 중립적 플랫폼은 성능 니즈를 충족하면서 비용을 최소화하도록 다양한 모델이나 경로를 동적으로 선택할 수 있습니다. 예: 간단한 쿼리엔 더 싼 로컬 모델을 쓰고, 복잡한 케이스에만 더 비싼 API를 호출 - 최종 사용자에게 투명하게. 요청 배치, 결과 캐싱, 에이전트 실행 빈도 조정도 가능합니다. 한 팀은 수동으로 이걸 했습니다(캐싱 추가, 특정 작업에 더 싼 모델 사용). 지능형 오케스트레이션 플랫폼이 그런 최적화를 자동으로 처리할 수 있습니다. 또한 단일 공급업체에 묶이지 않음으로써 가격 경쟁 이점을 취할 수 있습니다. 한 공급업체가 가격을 올리면 더 비용 효율적인 서비스로 전환. 이 유연성은 오케스트레이션이 리소스를 가장 효율적인 방식(사용자가 원하는 "각 작업에 가장 좋고 싼" 모델)으로 쓰게 하므로 ROI를 개선합니다.
'에이전틱 오케스트레이션 결정판 가이드' 읽기.
요약하자면, 검증되고 신뢰할 수 있는 에이전틱 오케스트레이션 레이어는 많은 고통 지점을 직접 해결합니다:
실제 고충(반복성 이슈, 통합 두통, 보안 공포, 비용 초과)에서 배움으로써 그런 솔루션은 실무자가 훨씬 덜 마찰과 위험으로 AI 에이전트를 활용하게 할 수 있습니다. 결과는 더 신뢰 가능하고, 적응 가능하며, 비즈니스 니즈에 정렬된 AI 에이전트 생태계로, 팀이 인프라와 싸우는 대신 문제 해결에 집중하게 합니다.
다음 편:
자동화 제어 시스템
유엔이 올해 초 전자폐기물 억제를 위한 약속을 하면서 전자폐기물에 대한 인식이 커지고 있습니다. 2100년까지 전 세계적으로 발생하는 폐기물 양은 현재 연간 13억 톤에서 40억 톤으로 급증할 것으로 예상됩니다. 그러나 종종 간과되는 측면은 빠르게 증가하는 전자폐기물의 기여량입니다. 국제전기통신연합(ITU)에 따르면, 전자폐기물 수준은 2016년 4,470만 미터톤에 달했습니다. 우려스럽게도 ITU는 이것이 2021년까지 5,220만 미터톤으로 증가할 것으로 예측합니다. 이는 이미 포화 상태인 매립지, 소위 전자폐기물 무덤에 상당
비즈니스 오너는 자체 GTM(Go-to-Market) 전략 수립에 익숙합니다. 신제품 출시 방식, 타겟 오디언스, 마케팅 플랜, 세일즈 전략을 담은 공식 계획이죠. 하지만 제품, 산업, 시장마다 다릅니다. 특히 제조·산업계에선 더 그렇습니다. Thomas의 중소기업 설문에 따르면, 미국 중소기업의 15.69%만이 디지털 마케팅을 주된 마케팅 전술로 활용합니다. 하지만 작년부터 더 많은 리더가 세일즈와 마케팅의 디지털 트랜스포메이션을 추진하고 있습니다. 다음 단계는 디지털 마케팅과 새로운 세대의 바이어에 부합하는 더 나은 성장 방식으
