7월 29일, UiPath DevCon Tokyo의 Agentic Automation How-To 트랙에서 발표를 진행했습니다. 세션 명칭은 「'개발'만이 아니다 ― 운영 현장에서 효과적인 Coding Agent 활용술입니다.

이전 기사에서 "내용은 쓰지 않겠습니다. 여기서 써버리면 내일 들을 의미가 없어지니까요"라고 말씀드렸습니다. 이제 끝났으니, 쓰겠습니다. 회장에 오지 못한 분들이 이 기사만으로도 가져가실 수 있는 수준으로 말이죠.

먼저 세션의 약속을 다시 재현하겠습니다.

• 코드는 한 줄도 쓰지 않습니다
• 개발자가 아니어도 괜찮습니다
• Agent가 실제로 만든 것을 스크린샷이 아닌 실물로 보여드립니다

세 번째는 기사에서도 지키겠습니다. Agent가 만든 설계서 실물을 기사 마지막에 공개하고 있습니다. 프롬프트(Prompt)도 전문을 올리므로 그대로 따라 할 수 있습니다.

Coding Agent에 관한 이야기는 자주 들으시죠? 하지만 자주 들리는 이야기는 대개 "개발을 빠르게 한다"는 내용입니다. 코드 작성 속도, 테스트, 재작업. 모두 맞는 말입니다.

하지만 기억해 주세요. 우리 현장의 시간은 대부분 **운영 단계 (Operation Phase)**입니다. 만드는 것보다 돌리고, 고치고, 인수인계하는 시간이 훨씬 더 깁니다. 게다가 그곳에는 개발자가 아닌 사람들도 많습니다.

그렇다면 거기서 Coding Agent는 사용할 수 없는 걸까요? —— 사용할 수 있습니다. 운영에서는 **「읽기」와 「측정하기」**에서 효과적입니다. 이 두 가지 동사가 세션의 뼈대였습니다.

「UiPath for Coding Agents」는 향후 출시 예정인 기능이므로 모르시는 것이 당연합니다. 한 가지만 짚어두고 싶은 것은, 「UiPath Skills」 —— 말하자면 AI를 위한 UiPath의 취급 설명서 —— 가 공개되어, AI가 UiPath에 대해 "정확하게" 알 수 있게 되었다는 점입니다. 이번 이야기는 전부 이 토대 위에 올라가 있습니다.

(제품 자체에 대한 해설은, 당일 제 바로 뒤에 있었던 공식 세션 「당신의 옆에 있는 또 다른 개발자, UiPath for Coding Agents가 여는 신시대」가 본론이었습니다.)

회장에서 이렇게 물었습니다. "우리 워크플로우(Workflow)는 만든 사람이 지금도 모두 사내에 있고, 문서도 완비되어 있다 —— 하시는 분, 손을 들어주시겠습니까?"

아무도 들지 않았습니다. 당연하죠. 만든 사람은 이미 없고, 문서도 없지만, 매일 돌아가고 있습니다. 내용이 블랙박스화된 워크플로우, 분명 여러분의 손에도 있을 것입니다.

손을 대기 전에, 먼저 "읽기". 이것이 운영의 입구입니다.

이 워크플로우 (.xaml)를 읽고,
인수인계용 설계서를 Excel로 만들어줘.
실제로 구동하며 화면을 확인하면서,
...

보시는 바와 같이 상당히 대략적입니다. 시트 구성도 서식도 지정하지 않았습니다. 포인트는 두 가지만 있습니다.

결과물을 지정한다 —— "인수인계용 설계서를 Excel로" -
"실제로 구동하며 화면을 확인하면서" —— 읽게 하는 것뿐만 아니라, 라이브로 확인하게 한다

두 번째 문장이 나중에 효과를 발휘합니다.

제재는 UiPath Academy의 연습 워크플로우 「Exercise_Advanced_UIAutomation」입니다. ACME 사이트의 종업원 정보를 취득하여 Web 폼으로 전기·전송하는 것뿐인 간단한 것으로, 문서가 없고 Main.xaml 파일 하나만 있는 상태입니다.

읽게 했더니, 몇 분 만에 Excel 7개 시트의 설계서가 나왔습니다. 프로세스 개요, 변수 정의, 15단계의 처리 플로우 표.

…라고, 여기까지는 솔직히 "뭐, 이 정도는 AI라면 하겠지"라는 범위라고 생각합니다. 본령은 여기서부터입니다.

설계서 안에 「실행 단계」라는 시트가 있습니다. 이것은 Agent가 브라우저에서 이 워크플로우를 "스스로" 실행하면서 만든 것입니다. 아까 프롬프트의 "실제로 구동하며 화면을 확인하면서" —— 그 한 문장의 결과가 이것입니다.

실제 화면의 스크린샷에, 조작 대상의 빨간 테두리, 절차 해설. 저는 스크린샷을 한 장도 찍지 않았습니다. Agent가 혼자서 해냈습니다.

이 시트를 처음 봤을 때, 솔직히 조금 소름 돋았습니다. "아, 이거, 내 일이 없어질지도 모르겠다"라고 생각해서요. 이전 기사에서 "검증하다가 한 번 섬뜩했던 순간이 있었다"라고 쓴 것은 바로 이것 때문입니다.

하지만 냉정하게 생각하면 —— 스크린샷을 찍고, 붙이고, 빨간 테두리를 치고, 설명을 쓰는 것. 그것은 애초에 인간이 할 일이 아니었습니다. 절차서 만들기라는 "그 작업"은 통째로 Agent의 일이 되었습니다.

나머지 시트에는 플로우차트(Flowchart)와——이 부분이 가장 흥미로운데——**「소견(所見)」**이 들어 있었습니다. 요청하지도 않았는데, 총 10건이나 말이죠.

• "본래 반복을 전제로 한 '발판'만 남아 있고, 루프(Loop)가 미구현되어 있습니다."
• "예외 처리(Exception Handling)가 없으므로, 운영 환경 적용을 위해서는 Try-Catch / Retry Scope가 필요합니다."
• "폼 입력(Form Input)이 위치 의존적이라, 항목의 순서 변경에 취약합니다."

정말 건방지지 않습니까? 그런데 분통 터지게도, 대부분 맞았습니다.

참고로 덧붙이자면, 소재가 연습용 교재였기 때문에 단순하게 만들어 놓은 것이 맞습니다. 재미있는 점은 Agent도 그 사실을 알고 있었다는 것입니다. 소견에는 "교재로서는 이것이 맞다. 다만, 실제 운영 환경에 적용한다면 이 부분을 수정해야 한다"라는 **구분(書き分け)**까지 되어 있었습니다. 이 정도로 눈치(空気)를 채다니 말이죠.

하지만. 이 지적이 맞는지, 어떻게 수정할지를 판단하는 것은 사람의 일입니다. 생성물을 무조건 맹신하지 마세요. CASE 1은 여기까지 세트로 가져가시기 바랍니다.

Before: 자료를 수작업으로 판독 —— 반나절 ~ 수일
After: 초안 생성 —— 수분. 사람은 확인 및 추가 작성만

요령은 작게 시도하는 것입니다. 갑자기 폴더 전체를 맡기는 것이 아니라, 먼저 파일 하나를 읽게 하여 정확도를 확인한 뒤 범위를 넓히는 것입니다. 이렇게 하면 실패하지 않습니다.

로봇이 돌아가고는 있지만——어느 부서가, 어떤 프로세스에서, 얼마나 사용하고 있는지 즉답할 수 있습니까?

회장에서도 이 질문에는 손을 드는 사람이 없었습니다 (저도 즉답하지 못했으니 안심하세요).

제가 한 일은, Orchestrator의 읽기 전용 "복제 열쇠" (인증 정보)를 하나 건네준 것뿐입니다. 나머지는 Agent가 스스로 로그를 가져갑니다. 로그를 다운로드하는 작업조차 하지 않았습니다.

Orchestrator의 최근 30일간
가동 로그를 조사해서, RPA 가동 상황
리포트를 슬라이드로 정리해줘.
...

CASE 1과 같은 방식입니다. 집계의 축과 출력 형식을 지정합니다. 다만, 이번에는 한 가지를 더 추가했습니다. 마지막에 **「그 외에 필요해 보이는 분석이 있다면 그것도 추가해줘」**라고 말이죠. 사람이 생각할 수 있는 범위에 가두지 않고, 여백을 주는 것입니다. ——이 한 문장이 나중에 큰 효과를 발휘합니다 (두 번째 강조입니다).

참고로 Orchestrator 화면에서도 숫자는 볼 수 있습니다. 하지만 정해진 방식대로만 볼 수 있죠. 자유로운 관점으로 묶어서 리포트까지 만들어 주는 것이 Agent의 역할입니다.

실제 최근 30일간의 가동 로그——로봇 4대, 6,828개 잡(Job), 68개 프로세스——로부터 그래프와 표가 포함된 리포트가 수분 만에 나왔습니다.

부서별 실행 시간. 저희는 사용한 부서별로 비용을 분담하는 운영 방식을 취하고 있기 때문에, 이 숫자가 그대로 안분(按分)의 근거가 됩니다. 누가 얼마나 사용했는지 눈에 보이면, 비용 문제로 다툴 일이 없어집니다.

그리고——시간대별로 로봇이 상한선에 맞닿아 있는 모습(오전 9~11시에 혼잡 집중, 피크 가동률 83%). 이것은 제가 요청하지 않았습니다. 프롬프트 마지막의 "그 외에 필요해 보이는 분석이 있다면" —— 그 한 문장으로부터 Agent가 스스로 추가한 분석입니다. 인간이 놓치고 있던 관점이 저쪽에서 먼저 튀어나오는 것입니다.

또 하나 흥미로웠던 점은 실패에 대한 심층 분석입니다. 가장 실패가 많은 프로세스를 Agent가 조사했더니, 실패 21건 중 81%는 자동화의 결함이 아니라 "다중 실행 방지(Multi-execution Guard)" —— 동일한 처리가 중복 실행되는 것을 막는 안전장치 —— 에 의한 자동 종료였습니다. 수정해야 할 것과 그렇지 않은 것이 명확히 구분되었습니다.

숫자가 보이면 다음 액션이 결정됩니다. 이것이 바로 「측정(Measure)」의 가치입니다.

같은 요령으로 응용이 가능합니다. 가장 추천하는 방법은, 「지난달과 비교해서 무엇이 변했지?」라고 한마디 묻는 비교 분석입니다. 정해진 대시보드와 달리 질문 방식은 자유롭습니다. 시간대별 혼잡도와 여유 시간, 장기간 작동하지 않는 프로세스 추출 —— 정말 아이디어에 달렸으며, 전부 같은 방식으로 할 수 있습니다.

Coding Agent는 "개발"만을 위한 것이 아닙니다. 운영에서는 「읽기」와 「측정」에서 강력한 힘을 발휘합니다.

내일의 첫걸음은 두 가지입니다. 둘 중 하나만 해도 좋습니다.

• 내용을 잘 모르는 워크플로우를 하나 Agent에게 읽혀보기
• 로봇의 가동 로그를 그 자리에서 시각화해보기

익숙해지면, 같은 방식으로 "실패한 워크플로우를 고치는" 운영 디버깅(Debugging)에도 적용할 수 있습니다. 읽고, 측정하는 다음은, 고치는 단계로 나아갑니다.

Agent가 설계서를 만든 것을 보고 깨달은 점은——병목(Bottleneck)은 AI가 아니라, 바로 나 자신이었다는 것입니다. "직접 읽는 게 더 빨라", "직접 쓰는 게 더 정확해". 그 자존심이 AI의 속도를 가장 크게 방해하고 있었습니다.

반대로, "필요해 보이는 게 있다면 추가해줘"라며 여유를 주었더니, 요청하지도 않은 분석 결과가 돌아왔습니다. AI를 방해하지 않는 것이 플러스 알파의 가치를 만들어냅니다.

그래서 지금 저의 결론은 심플합니다.

"AI는 호흡"입니다. 머리로 생각하기 전에, 먼저 AI에게 넘기세요. 이해는 AI의 출력물로부터 얻는 것으로 충분합니다.

개발을 빠르게 하는 것, "그 너머"의 단계. 운영 현장이야말로 Coding Agent의 성장 잠재력(伸びしろ)이 있는 곳입니다.

무대 위에서 QR 코드를 통해 배포했던 것과 동일합니다. 오늘 보여드린 설계서——스크린샷이 아닌 실물을 그대로 공개합니다.

(열람만 가능하며, 로그인은 필요하지 않습니다)

7개의 시트가 모두 포함되어 있습니다. 특히 봐주셨으면 하는 것은 「실행 단계(실제 화면)」 시트입니다. Agent가 스스로 움직여서 캡처하고, 빨간 테두리를 친 결과물입니다. 기사 속의 프롬프트와 함께 가져가셔서 그대로 따라 해 보세요.

행사장에서 말을 걸어주신 여러분, 감사합니다. "손을 들지 못하는 사람"과 두 번이나 함께해주신 분들도 감사합니다.

질문이나 감상은 댓글이나 X로 남겨주세요. Coding Agent에 대한 이야기는 언제든 환영합니다.

• X: @hash1moUI