파트너 채널에 AI 에이전트를 넣었더니, 제일 먼저 드러난 건 답변 품질이 아니었다

오늘 파트너용 ACP Agent 채널을 훑어보다가 꽤 흥미로운 장면을 봤다.

사람들은 에이전트에게 “이 기능 돼?”만 묻지 않았다.

티켓을 찾아달라고 했고, 고객 답변을 써달라고 했고, 로그를 어떻게 봐야 하는지 물었고, 심지어 “이걸 QCP로 등록해줘”까지 요청했다.

처음엔 단순 FAQ 봇처럼 보였는데, 실제로는 지원팀 옆자리에 앉은 주니어 엔지니어에 더 가까웠다. 문제는 이 주니어가 꽤 똑똑한데, 아직 회사 출입증이 어디까지 통하는지 스스로도 가끔 헷갈린다는 점이었다.

사람들은 챗봇이 아니라 동료처럼 썼다

채널에서 나온 질문들은 꽤 현실적이었다.

Headless Agent tunnel이 뭔지, qpctl과 tmux는 뭐가 다른지, KAC에서 Pod 내부 명령어까지 제어할 수 있는지, Databricks를 agentless 데이터 커넥션으로 쓸 수 있는지 같은 질문들이 이어졌다.

이건 문서 검색만으로 끝나는 질문이 아니다.

파트너 입장에서는 “고객에게 뭐라고 말해야 하지?”가 진짜 질문이다. 그래서 에이전트는 단순 설명보다 한 단계 더 들어갔다.

확인된 근거가 있으면 그 기준으로 설명한다.
근거가 없으면 없다고 말한다.
바로 답하기 위험하면 확인 포인트를 뽑아준다.
마지막에는 고객 회신안이나 내부 확인 요청 문안으로 바꿔준다.

이 흐름이 좋았다.

지원 업무에서 제일 위험한 답은 틀린 답이 아니다. 확실하지 않은데 확실한 척하는 답이다. ACP Agent는 적어도 오늘 관찰한 범위에서는 “이건 확인 근거가 없다”고 말할 줄 알았다.

그거 꽤 중요하다.

좋은 에이전트는 “모릅니다”를 예쁘게 말한다

예를 들어 어떤 질문은 이런 식이었다.

“Databricks를 QueryPie 데이터 커넥션으로 agentless 사용 가능한가?”

여기서 나쁜 답은 쉽다.

“가능합니다.”

짧고 시원하다. 그리고 위험하다.

ACP Agent는 확인 가능한 범위에서는 11.5.6에서 Databricks agentless 지원을 확답할 근거를 찾지 못했다고 답했다. 대신 화면에서 데이터소스 타입 목록을 확인하고, 연결 설정에서 Proxy/Agent 관련 필수 항목이 있는지 보고, 실제 연결 테스트를 해보라는 체크리스트를 제시했다.

이건 답을 회피한 게 아니다.

지원 업무에서는 “정확히 확인해야 할 다음 행동”을 주는 것도 답이다. 특히 파트너가 고객 앞에서 말해야 하는 상황이라면, 모르는 걸 포장하는 것보다 확인 경로를 주는 편이 훨씬 안전하다.

비슷한 장면은 AIP와 ACP 연동 질문, 11.6.0 릴리스 일정 질문, KAC의 Pod 내부 명령어 제어 질문에서도 반복됐다.

확정 근거 없음.
공개 확정본 없음.
문서상 바로 확인되지 않음.

문장만 보면 심심하다. 그런데 운영에서는 이런 심심함이 신뢰를 만든다.

트리아지는 꽤 잘했다

더 재미있는 건 장애성 질문에서 나왔다.

SAC에서 tmux를 쓰면 Command Audit 로그가 일부 남지 않는다는 문의가 있었다. 이런 문제는 대충 보면 “tmux 미지원인가?”로 가기 쉽다.

그런데 Agent는 바로 그렇게 단정하지 않았다.

대신 Prompt Separators를 봐야 한다고 했다. Command Audit이 명령 종료를 프롬프트 기준으로 판단한다면, 커스텀 프롬프트나 tmux 내부 세션 흐름 때문에 명령 종료 감지가 흔들릴 수 있다는 것이다.

쉽게 말하면 이렇다.

감사 로그 시스템이 “명령이 끝났다”는 신호를 프롬프트 모양으로 알아보는데, tmux 안에 들어가면서 그 신호가 평소와 다르게 보였을 수 있다.

이건 좋은 트리아지다.

도구 이름에 꽂히지 않고, 그 도구가 시스템의 어느 가정과 충돌하는지 본다. “tmux가 범인입니다”가 아니라 “명령 종료 인식 방식이 흔들렸을 수 있습니다”라고 문제를 재정의한다.

Cloud Provider 동기화 후 DB Instance에는 이름이 있는데 Host가 비어 있는 사례도 비슷했다.

처음에는 “생성 중이라 아직 endpoint가 안 채워졌나?”처럼 볼 수 있다. 하지만 추가 맥락을 받고 나서는, 단순히 생성 중 리소스를 skip한 정상 상황이라기보다 Instance 메타데이터가 불완전하게 반영된 예외 상황에 가깝다고 정리했다.

여기서도 핵심은 단정이 아니라 구분이다.

정상적으로 skip됐다면 Instance 자체가 생성되지 않아야 한다.
반대로 Instance를 반영했다면 Host까지 채워져야 한다.
그 사이에 걸쳐 있으면 후속 설정 변경에서 Instance information is required 같은 오류가 날 수 있다.

이 정도면 에이전트가 단순 검색기가 아니라 1차 분석가 역할을 하고 있는 셈이다.

그런데 “초안 작성자”와 “실행자” 사이에서 자꾸 미끄러졌다

오늘 가장 큰 문제는 답변 품질이 아니었다.

경계였다.

사용자는 자꾸 이렇게 말했다.

“QCP 티켓으로 등록해줘.”
“기존 티켓 체크해줘.”
“11.5.6에 기보고된 이슈 정리해줘.”

이 말은 사람에게는 꽤 자연스럽다. 파트너 채널에 있는 에이전트라면 당연히 티켓도 보고, 등록도 해줄 것 같기 때문이다.

하지만 실제 Agent는 여러 번 멈췄다.

초안은 만들 수 있다.
등록용 제목과 본문은 정리할 수 있다.
검색 키워드도 뽑아줄 수 있다.
하지만 지금 이 대화 환경에서는 실제 QCP 티켓을 생성했는지 검증할 수 없다.
실시간 Jira 이력을 바로 조회할 수도 없다.

이 태도 자체는 맞다. 못 했는데 했다고 말하면 안 된다.

다만 사용자 경험은 매끄럽지 않았다. 사용자는 “등록해줘”라고 했고, Agent는 한참 문안을 만들다가 마지막에 “실제 등록은 되지 않았습니다”라고 말했다.

이건 마치 식당에서 주문을 받더니 레시피를 예쁘게 써주고, 마지막에 “요리는 주방에서 해주세요”라고 하는 느낌이다.

레시피가 훌륭해도 배고픈 사람은 당황한다.

첫 화면에 써야 할 문장

이 문제는 기능보다 표현에서 먼저 고칠 수 있다.

파트너 채널의 첫 안내는 이렇게 나뉘어야 한다.

바로 가능한 일
- 제품/운영 문서 기반 답변
- 고객 회신안 작성
- 확인 체크리스트 작성
- QCP/Jira 등록용 초안 작성

인증 후 가능한 일
- 제한된 내부 참고 자료 기반 안내
- 기보고 이슈 확인 요청 문안 작성

현재 직접 실행하지 않는 일
- 실제 QCP/Jira 티켓 생성
- 실시간 티켓 상태 검증
- 근거 없는 지원 여부 확답

이렇게 쓰면 기대가 맞춰진다.

“티켓 등록 지원”이라는 말은 너무 넓다. 사용자는 실제 등록까지 기대한다. 지금 단계에서는 “티켓 등록 초안 작성” 또는 “등록 요청 문안 생성”이 더 정확하다.

나중에 진짜 Jira write가 붙으면 그때 표현을 바꾸면 된다.

그때도 바로 등록은 위험하다.

좋은 흐름은 이거다.

초안 생성
→ 사용자 확인
→ 실제 등록
→ QCP 번호와 링크 반환

에이전트가 업무를 대신할수록, 마지막 액션에는 증거가 필요하다. “등록했습니다”는 말보다 QCP-XXXX 링크 하나가 훨씬 강하다.

인증은 보안 기능이면서 첫인상이다

오늘 인증 흐름도 많은 걸 보여줬다.

회사명, 성함, 회사 이메일, 구분을 받고, 회사 이메일로 6자리 코드를 보내는 구조는 좋다. 파트너 채널에서 내부 지원 정보를 아무에게나 열어줄 수는 없으니까.

문제는 UX였다.

멘션 없이 정보를 주면 처리가 안 되고, 인증 메일이 오지 않고, 이미 인증된 사용자에게 다시 인증을 요구하는 장면이 있었다. 심지어 메일 수신 거부 목록 때문에 인증 메일이 막힌 사례도 있었다.

보안상 필요한 절차라도, 사용자가 처음 만나는 장면이 “왜 안 되지?”로 시작하면 신뢰가 깎인다.

여기서 필요한 건 거창한 AI가 아니다.

작은 친절이다.

“반드시 ACP Agent를 멘션해주세요”를 더 짧고 강하게 보여주기
인증 요청 전 기존 인증 상태 먼저 확인하기
메일 미수신 시 스팸함, 프로모션함, 수신 거부 여부, 재발송 요청 경로 안내하기
일정 시간 이상 인증이 막히면 운영자에게 알림 보내기
인증 상태를 스레드가 아니라 사용자/회사 단위로 기억하기

AI 에이전트의 첫인상은 모델 성능이 아니라 이런 흐름에서 결정된다.

빈 답변과 내부 상태 메시지는 생각보다 치명적이다

몇몇 스레드에서는 빈 답변처럼 보이는 메시지나 Interrupting current task 같은 내부 상태 메시지가 노출됐다.

개발자 입장에서는 별일 아닐 수 있다.

“아, 런타임이 작업을 끊고 새 요청을 처리했구나.”

하지만 파트너 채널에서는 다르게 보인다.

“얘 지금 뭐 하는 거지?”

에이전트가 사람처럼 일할수록, 실패도 사람에게 읽히는 언어로 바뀌어야 한다.

내부 상태 메시지는 숨기고, 사용자에게는 이렇게 말하면 된다.

확인 중입니다. 최대 1~2분 정도 걸릴 수 있습니다.

실패했다면 이렇게 말해야 한다.

현재 티켓 조회 도구가 연결되어 있지 않아 실제 조회는 진행하지 못했습니다.
대신 바로 전달 가능한 검색 조건과 요청 문안을 정리했습니다.

실패 자체보다 더 나쁜 건, 어디서 실패했는지 모르는 것이다.

결국 이 에이전트의 정체는 무엇인가

오늘 본 ACP Agent는 “혼자 모든 지원을 끝내는 에이전트”는 아니었다.

오히려 이런 역할에 가깝다.

1차 접수자
기술 문안 작성자
근거 기반 트리아지 보조자
실행 전 안전장치

이 포지셔닝이 맞다.

파트너가 던진 흐릿한 질문을 정리하고, 고객에게 보낼 수 있는 문장으로 바꾸고, 확인해야 할 로그와 조건을 뽑고, 위험한 확답을 막아준다.

그것만으로도 충분히 가치 있다.

다만 앞으로 한 단계 더 가려면, 다음 두 가지가 필요하다.

첫째, 실행 경계를 더 선명하게 보여줘야 한다.

둘째, Jira/QCP read-only 검색부터라도 붙여야 한다.

읽기만 가능해져도 “기보고 이슈가 있나?”라는 질문의 체감 가치는 크게 달라진다. 쓰기는 그다음이다. 쓰기는 반드시 확인 단계를 둬야 한다.

내가 남긴 체크리스트

이 채널을 계속 운영한다면, 당장 아래 항목부터 보면 좋겠다.

채널 안내문에 “ACP Agent 멘션 필수”가 명확한가?
인증 완료 사용자가 반복 인증을 요구받지 않는가?
인증 메일 미수신 시 fallback 경로가 있는가?
빈 응답이나 내부 runtime 메시지가 노출되지 않는가?
QCP/Jira 조회 가능 여부와 등록 가능 여부가 분리되어 안내되는가?
티켓 생성 요청 시 실제 생성 전 사용자 확인 단계가 있는가?
실제 생성 후 QCP 번호와 링크를 반환하는가?
고객 회신용 답변에서 내부 구현 세부나 불확정 로드맵이 빠지는가?
같은 주제의 후속 스레드에서 이전 맥락을 이어받을 수 있는가?

좋은 AI 에이전트는 멋진 답변을 길게 쓰는 도구가 아니다.

사람이 다음 행동을 안전하게 하도록 만드는 도구다.

오늘 파트너 채널에서 본 ACP Agent는 그 방향으로 가고 있었다. 이제 남은 숙제는 똑똑해지는 것보다, 어디까지 할 수 있는지 더 정직하고 선명하게 말하는 것이다.