데모는 끝났는데, 기존 시스템 앞에서 일이 멈춘다
AI 에이전트의 답변은 그럴듯한데 Salesforce 필드 하나를 바꾸려니 일이 커집니다. 어느 팀이 같은 데이터를 쓰는지, 예외 규칙은 어디에 숨어 있는지, 테스트와 승인은 누가 맡을지 다시 조사해야 하죠. 결국 엔지니어와 컨설턴트가 인터뷰를 반복하며 시스템 지도를 그리는 단계로 돌아갑니다.
이때 선택지가 ‘비싼 FDE를 투입할 것인가, AI로 대체할 것인가’ 둘뿐인 것처럼 보이지만 June의 현재 제품 설명은 조금 다릅니다. 사람이 하던 구현 작업 전체를 없애기보다 시스템 분석·계획·구축·테스트를 하나의 자동화된 작업 흐름으로 묶고, 검토와 승인은 사람에게 남겨둡니다. TechCrunch 인터뷰에서도 창업자는 June을 FDE와 컨설턴트의 완전한 대체재가 아니라 이들을 보완하는 제품으로 설명했습니다.
따라서 도입 판단의 핵심은 “FDE가 없어지는가”가 아닙니다. 우리 프로젝트에서 사람이 직접 찾아다니고 문서화하던 범위를 얼마나 줄일 수 있는가를 확인하는 일입니다.
June이 자동화하려는 건 구현의 앞뒤입니다
June은 기업 시스템을 연결해 구성과 업무 규칙, 프로세스, 의존성을 파악하는 단계에서 시작합니다. 자연어로 변경 목표를 입력하면 관련 시스템과 영향을 분석해 실행 계획을 만들고, 팀이 그 계획을 검토하거나 편집하도록 설계돼 있습니다.
계획 이후에도 범위가 이어집니다. 공식 설명에 따르면 June은 기존 팀의 도구를 이용해 변경 사항을 구축하고 테스트하며, 교육 자료와 시뮬레이션, 커뮤니케이션까지 준비합니다. 모든 변경은 검토되고 샌드박스에서 시험되며, 각 단계는 승인할 수 있도록 기록된다고 합니다.
운영 단계에서는 설계된 프로세스와 실제 실행의 차이를 찾고, 자동화 후보를 제안하며, 변경 전후의 시간과 비용을 측정하는 기능도 내세웁니다. 다만 계산식과 기준선 설정법, 실제 고객의 정량 결과는 공개되지 않았으므로 검증된 ROI로 받아들이면 안 됩니다.
| 판단 항목 | FDE·구현 전문가 중심 | June을 포함한 하이브리드 |
|---|---|---|
| 시스템 파악 | 인터뷰와 문서를 바탕으로 사람이 조사 | 연결된 시스템에서 규칙·구성·의존성 추출을 시도 |
| 변경 계획 | 전문가가 작성하고 이해관계자와 조율 | AI가 초안을 만들고 팀이 검토·편집 |
| 구축과 테스트 | 담당자가 기존 개발·관리 도구에서 수행 | 기존 도구를 이용해 구축·테스트하고 승인 준비 |
| 사람의 역할 | 조사부터 예외 처리까지 넓게 관여 | 검토·승인과 어려운 변경, 판단이 필요한 예외에 관여 |
| 현재 근거 | 프로젝트별 계약과 인력 역량을 확인해야 함 | 제품 설명과 단일 고객 증언이 중심이며 비교 데이터는 비공개 |
공개 사례는 가능성을 보여줄 뿐, 절감률을 증명하지 않습니다
공개된 CMG 사례에서는 Claude Code를 Salesforce에 통합하는 작업이 수주 동안 막혔고, June을 통해 에이전트를 어디에 배포할지 파악해 안전하게 진행할 수 있었다고 고객이 설명합니다. 하지만 배포 기간이 얼마나 줄었는지, 비용을 얼마 아꼈는지, 실제로 몇 개의 에이전트가 운영에 들어갔는지는 공개되지 않았습니다.
June은 2026년 8월 Time Ventures가 주도한 2,000만 달러 프리시드 투자를 공개했습니다. Michael Dell, Aaron Levie, George Kurtz 등도 투자자로 이름을 올렸지만, 투자 규모는 제품 효과나 시장 검증의 증거가 아닙니다.
AI 실험이 운영으로 이어지기 어렵다는 방향성은 IDC 자료에서도 확인됩니다. IDC 행사 페이지가 인용한 2025년 연구에서는 조직당 전년도 평균 23개 GenAI POC 가운데 프로덕션으로 넘어간 것이 3개라고 제시합니다. 다만 표본과 POC 정의, 같은 프로젝트를 추적했는지가 공개 페이지에 없으므로 이를 곧바로 ‘87%가 실패했다’는 실패율로 바꾸면 안 됩니다.
비교 단위를 사람 수가 아니라 구현 작업으로 잡으세요. 시스템 파악, 규칙 추출, 영향 분석, 변경 계획, 테스트, 승인, 교육을 나열한 뒤 June이 맡을 수 있는 단계와 반드시 사람이 책임질 단계를 표시하면 실제 인력 절감 가능성이 드러납니다.
도입 검토는 실제 업무 하나로 시작하세요
June에는 공개된 셀프서비스 체험 경로가 없고 공식 데모 신청만 확인됩니다. 그래서 제품 소개를 다시 듣기보다, 지금 통합이 막힌 업무 하나를 준비해 지원 범위와 인간 개입 조건을 확인하는 것이 첫 행동입니다.
- 검증할 업무를 한 문장으로 고릅니다.
예를 들어 “Salesforce의 대출 상담 후속 작업에서 중복 필드와 팀별 규칙 차이 때문에 에이전트가 다음 단계를 고르지 못한다”처럼 현재 실패 장면을 적으세요. 연결 후보 시스템과 내부 담당자도 함께 정합니다. - 공식 데모 신청 페이지에서 요청합니다.
이름(First Name), 성(Last Name), 회사 이메일, 회사명을 입력하고 약관에 동의해 제출합니다. 전화번호는 필수 표시가 없는 선택 입력 항목입니다. 가격과 최소 계약 규모는 공개되지 않았으므로 후속 상담에서 확인해야 합니다. - 시스템 분석 범위를 화면으로 확인합니다.
우리 시스템에서 읽을 수 있는 구성·규칙·의존성이 무엇인지, 어떤 권한이 필요한지 물어보세요. 제품 페이지는 분석 흐름을 설명하지만 시스템별 연결 방식과 읽기·쓰기 범위는 공개하지 않습니다. - 변경 하나가 승인되기까지 따라갑니다.
생성된 계획을 누가 수정하는지, 샌드박스 테스트 결과와 단계별 기록이 어떻게 보이는지, 승인 전후 권한과 롤백 방식은 무엇인지 확인합니다. - 사람에게 넘어가는 예외를 표시합니다.
June Expert나 내부 전문가가 개입하는 조건을 묻고, 기존 FDE 업무 가운데 줄어드는 단계와 그대로 남는 단계를 구분하세요. 성공 기준은 ‘FDE 없이 완료’가 아니라 지원 시스템·변경 범위·승인 책임·인간 개입 조건이 한 업무 기준으로 확인된 상태입니다.
계약 전에는 네 가지 빈칸을 채워야 합니다
- 연결: Salesforce·SAP·ServiceNow 같은 대상별 연결 방식과 지원 기능은 무엇인가요?
- 데이터: 필요한 읽기·쓰기 권한, 저장 위치, 보관 기간과 모델 학습 사용 정책은 무엇인가요?
- 통제: 승인 권한, 샌드박스, 롤백, 감사 로그는 실제 운영에서 어떻게 작동하나요?
- 경제성: 가격과 도입 기간은 얼마이며, 기존 방식과 비교할 시간·비용 기준선은 어떻게 정하나요?
June의 흥미로운 지점은 FDE 자리를 AI 하나로 바꾼다는 데 있지 않습니다. 구현 전문가의 머릿속과 문서에 흩어져 있던 분석·계획·테스트 과정을 제품 안으로 옮긴다는 것입니다. 이 흐름이 실제 시스템에서도 작동한다면 사람은 반복 조사보다 승인과 예외 판단에 집중할 수 있습니다. 아직 공개된 비교 데이터가 부족한 만큼, 그 가능성은 한 개의 실제 업무와 명확한 책임 경계로 확인해야 합니다.
