AI 에이전트 발표라면 보통 더 좋은 모델, 더 정교한 프롬프트, 더 많은 자동화를 기대한다. 2026년 7월 서울에서 열린 Arize AI Builder Meetup의 세 발표는 오히려 그다음을 이야기했다.
이미 만들 수 있는데 왜 현장에서는 잘 작동하지 않는가. 환각을 줄였는데 왜 고객은 더 싫어하는가. 같은 개발자가 사이드 프로젝트에서는 빠른데 회사에서는 느린 이유는 무엇인가. PoC가 성공했는데 왜 실제 배포와 사용으로 이어지지 않는가.
세 발표를 관통한 문장은 이것이었다.
이제 병목은 AI를 만드는 기술보다, AI가 실제로 일할 수 있는 평가·맥락·권한·운영 환경에 있다.
공식 행사 페이지에 확인되는 세션과 연사는 다음과 같다.
| 세션 | 연사 |
| Arize Observe 2026 후기: 지속 가능한 AI Agent를 위한 관측과 평가 | 이윤경, LG유플러스 |
| AI 시대에 1인 빌더가 가지는 Unfair Advantage | 정구봉, Team Attention |
| 2026년 상반기 대기업 현장에서 겪은 AX 프로젝트 수기와 수주 전략 | 빌더조쉬 |
첫 발표는 AI를 어떻게 평가하고 운영할지, 두 번째는 개인과 조직의 AI 생산성이 왜 달라지는지, 세 번째는 기업 내부에 AI를 어떻게 실제로 도입할지를 다뤘다.
1. 정확도가 올랐는데 제품은 나빠질 수 있다
LG유플러스 이윤경 님의 발표는 업계의 질문이 바뀌었다는 데서 시작했다. 작년까지 “에이전트를 어떻게 개발할까”가 중심이었다면, 이제는 “배포한 에이전트의 문제를 어떻게 발견하고 평가하고 계속 개선할까”가 중요해졌다는 것이다.
모델을 한 번 잘 만드는 것으로 끝나지 않는다. 실제 사용 기록에서 실패를 찾고, 이를 평가 데이터로 바꿔 수정한 뒤 다시 배포하는 순환이 필요하다.
운영 데이터 → 실패 발견 → 평가 데이터셋 → 개선 → 재평가 → 재배포
Arize Observe에서 두드러진 방향도 이 자동화였다. 과거에는 개발자가 에이전트 트레이스를 직접 읽고 문제를 찾았다. 이제는 별도 에이전트가 다른 에이전트의 실행 기록에서 반복 오류를 탐지하고, 원인을 분석하고, 수정안을 제안하고, 경우에 따라 수정 PR까지 만드는 쪽으로 발전하고 있다.
평가자도 틀릴 수 있다
LLM을 평가자로 쓰는 LLM-as-a-Judge가 널리 사용되지만, 평가자 역시 확률적으로 답하는 LLM이다. 점수 하나가 나왔다고 정답으로 취급하면 안 된다.
- 어떤 근거를 보고 판단했는가
- 판단 과정이 일관적인가
- 다른 평가 방식도 같은 결론에 도달하는가
- 사람의 실제 판단과 얼마나 일치하는가
즉 평가 대상 에이전트뿐 아니라 평가 에이전트의 트레이스도 관측해야 한다.
음성 상담은 더 복잡하다. 고객 음성 → STT → LLM 처리 → 음성 응답이라는 전체 사슬 중 어느 구간에서 품질이 떨어졌는지 연결해서 봐야 한다. 최종 텍스트 답변만 점수화하면 발음 인식 실패나 응답 지연 같은 실제 고객 경험을 놓친다.
환각 감소가 고객 만족도를 떨어뜨린 사례
가장 기억에 남은 대목은 LG유플러스의 실제 제품 사례였다. 근거 없는 답변을 줄이기 위해 LLM이 자기 답변을 다시 점검하는 Reflection 방식을 적용했다.
- 근거 없는 답변 탐지: 개선
- 기술적인 정확도: 개선
- 고객 만족도: 하락
모델이 근거만 엄격하게 따지면서 답변이 소극적이고 기계적으로 변했다. 고객이 기대한 자연스러운 상담 경험이 훼손됐고, 결국 기능을 다시 제거했다.
이 사례가 던지는 결론은 분명하다. 환각률은 중간 지표이고 고객 만족도가 제품 지표다. 정확도가 좋아졌다는 이유만으로 제품이 좋아졌다고 말할 수 없다.
출시 기준도 “평가 점수 몇 점 이상”이라는 절대 숫자만으로 정할 수 없다. 개발자, PM, 대화 설계자, 현업 담당자가 좋은 답변의 정의, 허용할 위험, 정확성과 자연스러움의 우선순위를 합의해야 한다.
평가는 모델의 정답률을 재는 일이기 전에, 우리가 원하는 제품을 정의하는 일이다.
2. 1인 빌더가 빠른 이유는 AI를 더 잘 써서가 아니다
Team Attention 정구봉 님의 발표는 “AI 시대 1인 빌더의 불공정한 우위”를 다뤘다. 처음에는 Claude Code 같은 도구를 먼저 써본 경험 자체가 경쟁력이었다. 하지만 모델이 빠르게 좋아지고 사용법이 쉬워지면서 도구 숙련은 금방 평준화됐다.
특정 모델에 맞춰 복잡하게 붙였던 플러그인과 워크플로가 최신 모델에서는 오히려 방해가 되어 상당 부분 걷어냈다는 경험도 공유됐다. 오늘의 정교한 하네스가 내일 모델 업데이트 후에는 불필요한 족쇄가 될 수 있다는 뜻이다.
AI가 “더 할까요?”라고 묻고 멈추는 문제를 단순 반복 루프로 해결한 실험은, 에이전트를 밤새 실행하고 다음 날 결과물을 발표하는 해커톤으로 확장됐다. 중요한 것은 오래 돌렸다는 사실보다 AI가 계속 시도할 수 있는 환경을 먼저 만들었다는 점이다.
같은 사람이 회사에서는 왜 느려질까
발표의 중심 질문은 이것이었다. 같은 개발자가 회사 안에서는 평범한 생산성을 보이는데, 사이드 프로젝트에서는 놀라운 속도로 결과물을 만드는 이유는 무엇인가.
답은 능력보다 권한과 맥락에 있었다.
조직에서는 한 사람이 전체 코드와 데이터에 접근하고, 고객과 직접 이야기하고, 다른 팀 시스템을 바꾸고, 업무 프로세스를 수정하고, 결과를 보고 즉시 방향을 바꾸기 어렵다. 보상도 결과와 직접 연결되지 않을 수 있다.
반면 1인 빌더는 고객 대화, 기획, 코드, 이메일, 운영 데이터, 의사결정을 혼자 연결한다. AI에도 이 전체 맥락과 실행 권한을 줄 수 있다.
따라서 1인 빌더의 진짜 우위는 “AI로 코드를 많이 생산한다”가 아니다. 전체 맥락과 실행 권한이 한 사람에게 모여 있다는 것이다.
조직이 비슷한 생산성을 얻으려면 AI 도구 계정만 지급해서는 안 된다.
- 필요한 데이터와 코드에 접근할 수 있는가
- 실제 시스템을 변경할 권한이 있는가
- 결과를 검증하는 피드백이 있는가
- 실패해도 다시 시도할 수 있는가
- 성과와 보상이 연결되는가
모델 사용법은 복제할 수 있지만 오랫동안 쌓인 고객 이해, 작업 기록, 데이터와 즉시 실행할 권한은 쉽게 복제되지 않는다. 1인 빌더의 해자는 프롬프트가 아니라 자신만의 맥락과 실행 환경이다.
코딩에서 발견으로
목표와 테스트가 이미 주어진 코딩 문제는 AI가 점점 빠르게 처리할 수 있다. 사람의 역할은 답이 정해진 구현보다 아직 답이 없는 발견 쪽으로 이동한다.
- 어떤 문제가 중요한지 선택
- 검증할 가설 설정
- 평가 기준 정의
- 새로운 연결 발견
- AI가 활동할 환경 설계
모델이 좋아질수록 복잡한 모델별 요령보다 정리된 데이터, 기억, 행동 도구, 접근권한, 피드백 구조의 가치가 커진다.
3. PoC보다 어려운 것은 기업 안에 넣고 쓰게 만드는 일이다
빌더조쉬의 발표는 2026년 상반기 대기업 AX 프로젝트를 수행하고 수주한 과정에 관한 현장 기록이었다.
처음부터 거대한 엔터프라이즈 솔루션이 있었던 것은 아니다. 직접 만든 작은 결과물을 보여주고, 빠르게 만들어준다는 평판과 소개가 쌓이면서 더 큰 프로젝트로 이어졌다.
빠른 결과물 → 소개 → 수행 기록 → 다음 인바운드
기업 강의도 단순한 강연 수익원이 아니라 영업 채널로 사용했다. 유튜브, 링크드인, 뉴스레터에 기록을 남기고 기업 강의를 하면서 역량을 보여주고, 현장의 고민을 수집하고, 담당자와 관계를 만들고, 후속 프로젝트로 연결했다.
콘텐츠 → 기업 강의 → 문제 발견 → 관계 형성 → 프로젝트 → 수행 기록 → 다음 고객
여기서 콘텐츠는 홍보 문구가 아니었다. B2B 구매자가 “이 사람이 우리 문제를 실제로 풀 수 있을까”라고 느끼는 불안을 줄이는 신뢰 자산이었다.
실무자와 임원은 다른 질문을 한다
처음에는 현업 담당자의 요청대로 에이전트의 기술 구조를 설명했지만 임원의 반응은 좋지 않았다. 임원이 알고 싶었던 것은 다른 문제였다.
- 이 시스템을 어떻게 통제할 것인가
- 보안 사고를 어떻게 막을 것인가
- 조직 전체로 어떻게 확산할 것인가
- 잘 사용하는 직원에게 어떤 권한과 보상을 줄 것인가
설명의 중심을 모델과 에이전트 구조에서 거버넌스·문화·확산으로 바꾸자 반응이 좋아졌다.
실무자는 “어떻게 만들까”를 묻고, 임원은 “왜 해야 하며 어떻게 통제할까”를 묻는다.
제품만 팔지 말고 담당자가 내부에서 다시 팔 수 있게 해야 한다
외부 환경에서 PoC를 만드는 일은 상대적으로 빨라졌다. 정작 어려운 것은 기업 보안망에 넣고, 사내 데이터를 연결하고, 접근권한을 정하고, 유지보수 책임자를 지정하고, 내부 보고와 승인을 통과하는 일이다.
Docker 이미지 전달, 내부망 설치와 검증처럼 AI와 직접 관련 없어 보이는 수작업도 많다. 그래서 고객사 담당자가 내부 승인을 받을 수 있도록 PPT, 데모 영상, 성과 설명, 보고 자료까지 함께 만들었다.
B2B에서는 계약 담당자 한 명만 고객이 아니다. 그 위의 의사결정자, 보안, 법무, IT 운영, 실제 현업까지 모두 설득해야 한다. 제품을 납품하는 것과 조직이 그 제품을 채택하는 것은 다른 프로젝트다.
약 100명을 대상으로 한 이틀간의 캠프 사례도 같은 맥락이었다. 외부인이 AI를 대신 만들어주는 것으로 끝내지 않고, 조직 안에서 계속 활용을 이끌 구성원을 챔피언으로 만드는 접근이다.
전사 에이전트를 배포해도 사용률이 낮은 이유도 단순하다. 범용 도구만 주면 어디에 쓸지 모른다. 견적서·기획서처럼 구체적인 업무를 지정하고, 현업이 직접 아이디어를 내고, 작은 성공을 만든 뒤 코칭과 확산이 뒤따라야 한다.
AI 도입의 단위는 에이전트 배포가 아니라 업무 행동의 변화다.
세 발표는 사실 같은 문제를 말했다
| 영역 | 겉으로 보이는 질문 | 실제 질문 |
| 평가 | 정확도가 몇 점인가 | 우리가 원하는 제품 결과는 무엇인가 |
| 생산성 | 어떤 모델과 도구를 쓰는가 | 맥락과 실행 권한이 연결돼 있는가 |
| 도입 | 에이전트를 배포했는가 | 조직의 행동과 책임이 바뀌었는가 |
평가, 권한, 도입은 따로 떨어진 주제가 아니다. 조직이 어떤 결과를 원하고, 어떤 위험을 허용하고, 누가 어디까지 행동하고, 결과에 누가 책임질지 결정하는 하나의 문제다.
AI는 코드와 PoC의 비용은 크게 낮췄다. 하지만 보안망 구축, 데이터 정리, 평가 기준 합의, 승인, 교육, 책임과 보상 설계 같은 조직 변경 비용까지 자동으로 낮추지는 않았다.
그래서 다음 등식들은 성립하지 않는다.
- 환각 감소 ≠ 고객 만족도 상승
- 에이전트 구축 ≠ 사용률 상승
- PoC 성공 ≠ 실제 도입
- AI 교육 ≠ 업무 방식 변화
- 많은 코드 ≠ 좋은 결과
세 발표 모두 중간 지표를 최종 성과로 착각하지 말라는 메시지로 연결됐다.
다음 주에 조직에서 물어볼 다섯 가지
- 제품 지표: 모델 점수 말고 고객 행동에서 무엇이 좋아져야 하는가?
- 맥락: AI가 필요한 데이터와 과거 결정에 접근할 수 있는가?
- 권한: 제안만 할 수 있는가, 실제 시스템을 변경할 수 있는가?
- 검증: 실패를 발견해 평가 데이터와 개선으로 연결하는가?
- 채택: 배포 수가 아니라 반복 사용하는 사람과 업무가 늘고 있는가?
이 다섯 질문에 답하지 못하면 모델을 한 단계 올려도 현장 성과는 크게 달라지지 않을 가능성이 높다.
결론
AI 시대의 경쟁력은 더 좋은 모델을 고르는 능력보다, AI가 일하고 실패하고 다시 개선할 수 있는 환경을 만드는 능력에 가까워지고 있다.
그 환경에는 기술만 들어가지 않는다. 목적과 평가 기준, 데이터와 맥락, 실행 권한, 검증과 책임, 조직의 보상, 사용자의 실제 채택이 함께 들어간다.
이 행사는 “AI가 어디까지 할 수 있나”보다 “왜 이미 할 수 있는데도 현장에서는 작동하지 않나”를 다룬 밋업이었다.
출처와 확인 범위
세션 제목·연사·순서는 공식 행사 페이지에서 확인했다. 구체적인 발표 내용과 사례는 현장 기록을 바탕으로 정리했으며 공식 녹취록은 아니다. 녹취 오류 가능성이 있는 장시간 실행 결과와 코드·논문 수치는 본문에서 제외했다. 기업 사례의 세부 수치나 내부 정책은 연사의 별도 공개 자료가 나오면 추가 확인이 필요하다.
댓글