2026년 5월 14일, 현재 CLI로 제공되고 있는 코딩 에이전트 겸 「Grok Build」의 얼리 베타(Early Beta) 버전이 출시되어, AI / Vibe Coding 업계의 SNS가 들썩였습니다.

에이전트를 오픈 소스(Open Source)로 공개하는 등 많은 뉴스와 사양 변경이 논란이 되고 있습니다.

설치:

curl -fsSL https://x.ai/cli/install.sh | bash

사용법은 작업 디렉터리에서 grok 명령어로 에이전트를 호출하고 프롬프트(Prompt)를 던지기만 하면 됩니다.

유료 플랜으로 업그레이드하면 MCP나 Skills 등을 사용할 수 있는 것으로 보입니다.

이번에는 다음과 같은 상황을 가정하여, 실제로 에이전트를 개발하고 사용감을 체험해 보고자 합니다.

안건: 어느 헬스케어 클라이언트에게 대화형 AI 에이전트(Voice, 메시지)를 도입합니다.

이용 상황: 예를 들어, 전화로 고객이 어떤 의사를 찾고 있는 상황에서, 네트워크 내의 의사 정보(이름, 전공, 기타 정보)를 통해 최적의 의사를 찾아 제공한다.

전제:

• 내부 검색 시스템 API 등이 없는 레거시(Legacy) 환경

• 현재 모든 의사 데이터는 하나의 JSON 파일에 들어 있음

업무 이해·히어링 (Hearing) (성공 지표·업무 플로우·데이터 업데이트·제약)

먼저 고객과 성공의 정의를 합의하는 단계까지 가져간다 -
병목 현상 (Bottleneck) 정리 (데이터 품질, 검색 성능, AI의 오답, 보안) -
MVP 설계 (우선 한정된 범위에서 PoC) -
기술 구성 (데이터 기반 → 검색 → AI 에이전트 → 음성) -
운영·개선 (로그 분석, 평가 지표, 지속적 개선)

• 이 프로젝트는 무엇을 위한 것인가
• 무엇을 개선하고 싶은가
• KPI/Goal은 무엇인가

최우선 사항: 정말로 해결해야 할 과제인가, 목표 정의에 대한 합의

결국 무엇을 개선·달성하고 싶은가

예)

• 통화 시간 단축인가
• 오퍼레이터 교육인가
• 의사 소개 정밀도인가
• 콜센터 인원 감축인가

따라서, 먼저 히어링을 진행합니다.

• 통화 시간을 30% 단축하고 싶다

• 오퍼레이터 교육을 줄이고 싶다

• 1차 응답률을 90% 이상으로 하고 싶다

• 누가 검색하는가 (오퍼레이터? 사용자?)

• 오퍼레이터/사용자는 현재 무엇 때문에 어려움을 겪고 있는가?

• 문의 유입 경로는 무엇인가 (SMS, 전화, WhatsApp)

• 하루에 몇 건의 문의를 받는가

• 전화를 받는 사람은 몇 명인가

• 평균 통화 시간

• 통상적인 플로우 (Flow)

• 긴급 상황 시의 플로우

• 검색에 필요한 키워드와 중요도 랭킹

• 최종적으로 제공하는 것은? 의사 정보? 예약 가능 시간? 전화번호?

• 예약은 어디에서 이루어지는가? 별도의 시스템이 있는가?

• 가장 시간이 많이 걸리는 업무는?

• 신입과 숙련자의 차이는 무엇인가?

• 현장 작업자는 시스템의 상태를 어디까지 파악하고 싶은가 (업데이트 작업이 실행되었는지 등의 알림을 원하는가)

• 오프라인 타임이 있는가

• 1회 처리의 재시도(Retry)는 몇 초 정도가 적당한가

• 해당 결과가 없는 경우 어떻게 할 것인가, 재시도는 몇 회까지인가, 유사한 결과라도 최대한 찾을 것인가, 아니면 다른 지식(Knowledge)을 참조하여 안내할 것인가

• 에스컬레이션(Escalation)이 발생하는 기준은?

• 사용하고 싶은 모델 시리즈 등이 있는가, 검증 단계와 실운용 단계에서 모델을 변경해도 되는가

• 향후 다른 자동화·DX를 하고 싶은 업무가 있는가, 있다면 함께 API 서버 등을 만들어 두면 편리함

• JSON은 몇 건인가?

• 업데이트 빈도는?

• 자동 업데이트? 수동 업데이트?

• 업데이트 반영 타이밍

• 업데이트 후의 데이터를 취득하려면

• 화면상에서 추가·변경할 수 있도록 할 것인가 여부

• 처리 중에 외부로 데이터를 내보내도 되는가

• 향후 추가하고 싶은 데이터가 있는가 (평판 등)

• 데이터를 외부로 내보내도 되는가

• 사용자별 액세스 제어(Access Control)를 수행하고 싶은가

• 어떤 데이터를 암호화(Encrypt)할 필요가 있는가

이것으로 충분한가

• 보험 적용
• 지역
• 야간 대응
• 영어 대응
• 소아 대응

이상적으론 고객과 확인하면 좋겠지만, 실제 고객도 모르는 것이 대부분입니다.

이번에는 가정이므로, 일단

• 대응 시간 단축 -> 30% 이상
• CSAT 개선 -> 4.85 이상 유지
• 정밀도 향상 -> 한 번에 적절한 의사를 제공할 확률 95%

자, 실제로 개발을 시작한다고 했을 때의 병목 현상을 생각합니다.

• 직접 검색할 수 없음

• 느려지기 쉬움

• 업데이트하기 어려움

• 버전 관리

• 실시간성

• 환각 (Hallucination)을 일으킴

• 메시지: 오타 및 탈자

• 음성: 잘못 알아듣는 경우, 이름의 철자 오류 등

• 언어의 제약

• 표현의 모호함

• 정보 보호 법률

• 시설 특유의 규칙 등

• 사용자나 영업소 등에 따라 동일한 고유명사라도 부르는 방식이 다를 가능성이 있음, 이 경우 어떻게 이해해야 하는가

• 복수 조건인 경우 어떻게 검색할 것인가

위 사항들을 고려하면, 가능한 한 느슨한 결합 (Loose Coupling) 상태로 만들고, 에이전트가 중간중간 루프 (Loop)를 돌며, 정밀도가 확보된 상태에서 이용자의 동의를 얻은 후 다음 단계로 진행하는 것이 좋다고 생각합니다.

SMS text message / Voice Call-in, start the process
↓
Twilio
...

먼저 2 - 10개 시설, 100 - 1000명의 의사를 대상으로 KPI를 확인

• 통화 시간

• 성약률 (Conversion Rate)

• 답변 정밀도

• 실제 KPI 달성률

• CSAT (고객 만족도)의 변화

• 에스컬레이션 (Escalation) 비율

• 시스템 안정성 모니터링

• DB, 네트워크의 시간/부하 추이도

• 고빈도 프로세스

• 감사 로그 (Audit Log)

• DB 인덱스 (Index)

• 비용

• 토큰 (Token) 소비량

• LLM 선택

• 가용성 (Availability)

• 동시성 (Concurrency)

이러한 점들을 바탕으로 다음과 같은 설계서를 작성했습니다.

처음으로 Grok Build를 사용하기 때문에, 언어 이해 성능에 따른 영향을 배제하기 위해 우선 영어로 작성하고 있습니다.

# Health Care call center AI agent
## Why building this?
Currently our call center is peforming low efficent on dealing with phone calls and text contact from patients
...

SMS text message / Voice Call-in, start the process
↓
Twilio
↓
Speech to Text
↓ If no match/hard to understand
Input Validation -----------------|-----|-----|-----> Escalation
・Confidence Score | | |
・Medical term | | |
・Fuzzy Matching loop loop |
・Confirmation flow | | |
↓ | | |
Ask questions and confirmation ----| | |
↓ | |
Final Confirmation -----------------------| |
↓ |
Intent / Planner |
↓ loop
Doctor Search Tool |
├─ Structured Search |
└─ Semantic Search |
↓ |
LLM Re-ranking and Response |
↓ |
Text to Speech / SMS Response |
↓ Retry | If still not satisfied
Confirm with patient to reserve or not --------|----> Escalation
↓ If yes ↓ Finish the call or message session timeout
Reserve Doctor ↓
↓ ↓
End the process

## Technologies
### Requirements
- Docker
...

ENT
↓
Otolaryngology
Pedia
↓
Pediatrics

3. Data Ingestion

JSON
↓
Validation
↓
Normalizer
↓
DB
↓
Set Index

4. DB
- SQLite - POC
- PostgreSQL - Production
...

Voice
↓
STT
↓
Intent Detection
↓
Planner
↓
Tool Calling
↓
FindDoctor() (Region, gender, expertise)
↓
Re-ranking (Region, available time, )
↓
Response

6. Operator login(Not required in Poc Phase)
- Auth on Congnito/Azure AD/ Custom user pool auth
7. Logging Queue

Doctor Search
│
┌──────────────┴──────────────┐
│ │
▼ ▼
PostgreSQL Audit Queue(SQS)
│ │
▼ ▼
LLM Response Log Worker
│ │
▼ ▼
Text to Speech Audit Log

8. Security
- Access level control (액세스 레벨 제어)
- Audit Log (감사 로그)
...

이것을 Description.md라는 이름으로 작업 디렉터리에 저장합니다.

작업 디렉터리에서 다음 프롬프트를 입력하여 '맡기기 모드(omakase mode)'로 시작합니다.

Please create a cli agent tool and related batch sripts descriped in Description.md in current directory. Please make sure the agent could run by setting up .env file and running `docker compose up` command, ingestion batch and database updating batch when JSON data updated

작업 내용을 실시간으로 표시해 줍니다.

대략 10분 정도 만에 완성품이 나타났습니다.

Worked for 10m5s

.env.sample에서 .env 파일을 복제하여 각종 API 토큰 등을 설정합니다.

cp .env.example .env

# LLM (SpaceXAI / xAI)
XAI_API_KEY=your_xai_api_key_here
LLM_MODEL=grok-4.5
...

docker compose up

한 번에 에러 없이 기동되었습니다!

예약 테스트

$ docker attach healthcare-agent

> I need a male doctor who can help on my fever
Agent: I understood (confidence 100%): General Practice, male.
I need a bit more information:
...

이번에는 Grok Build를 모의 프로젝트 베이스로 체험해 보았습니다.

세부적인 부분까지는 아직 살펴보지 못했지만, 무료 플랜에서도 응답 시간, 코딩 속도, 품질 등 전반적으로 나쁘지 않은 느낌이었습니다.

실제 대응 내용도 일반적인 서포트나 헬프 데스크와 유사한 느낌이라 괜찮다고 생각합니다.

특히 생성 중에 작업 내용을 확인할 수 있다는 점과, 한 번에 Docker가 에러 없이 실행되었다는 점에 감동했습니다.

아무래도 500K까지는 무료로 사용할 수 있을 것 같으니, 이번 달은 이것저것 마음껏 사용하며 테스트해 보려고 합니다.

재미있는 발견이 있으면 보고하겠습니다.

千住Meetup!에는 많은 엔지니어, 디자이너, PM이 모여 매일 최신 AI 트렌드에 대해 토론하고 있습니다.

부디 여러분과 교류할 수 있으면 좋겠습니다.

편하게 참여해 주세요.