UiPath & VB.NET 트러블슈팅 모음집

FURVEN·2026년 7월 7일

Excel자동화 REFramework RPA개발 RPA운영 UIPath UiPathQueue UiPathSelector UiPath오류해결 UiPath트러블슈팅 VB_NET rpa 업무자동화

RPA

목록 보기

7/7

UiPath 개발 중 직접 겪었던 문제와 해결 방식을 정리하는 문서입니다.
단순 문법 정리가 아니라, 문제 상황 → 내가 적용한 해결 방식 → 주의한 점 → 정리한 기준 순서로 계속 업데이트합니다.

문서 기준

UiPath Studio 기준
VB.NET 표현식 기준
Windows 환경의 UI 자동화 기준
Excel, Browser, Mail 자동화 포함
프로젝트 환경, 패키지 버전, Studio 버전에 따라 액티비티 이름이나 옵션 위치는 다를 수 있음

공개 글 작성 기준

이 글은 공개 블로그용이므로 실제 운영 정보는 일반화해서 작성한다.

- 실제 업무 시스템명 → "업무 시스템", "대상 시스템"으로 표현
- 실제 URL, IP, 도메인 → example.com 또는 <도메인> 형태로 표현
- 계정명, 서버명, PC명 → <계정명>, <서버명>, <Robot PC> 형태로 표현
- 내부 패키지 경로 → <로컬 패키지 경로>, <내부 패키지 저장소>로 표현
- 방화벽 허용 정보 → 출발지, 목적지, 프로토콜, 포트, 용도 기준으로 일반화
- RDP 세션 명령어 → 실제 세션 ID, 계정명 없이 템플릿 형태로 작성

보안 관련 내용을 무조건 제외하기보다는, 실제 환경을 특정할 수 있는 값만 제거하고 구조와 판단 기준은 남긴다.

1. DataTable은 In으로 넘겨도 내부 수정이 외부에 반영된다

문제 상황

String, Integer 같은 값은 하위 Workflow에 In으로 넘기고 내부에서 바꿔도 외부 값이 바뀌지 않았다.
그런데 DataTable은 In으로 넘겼는데도 내부에서 수정한 내용이 외부에 반영됐다.

원인

DataTable은 참조 타입이다.
특히 Invoke Workflow File을 비격리(Isolated=False)로 호출한 경우, UiPath 공식 문서에서도 In 인수의 객체가 참조처럼 전달되어 하위 Workflow의 객체 내부 변경이 호출 측에도 반영될 수 있다고 설명한다.

따라서 아래 설명은 비격리 Workflow 호출 기준으로 보는 것이 정확하다.

예시:

dtData.Rows.Add(...)

또는:

dtData.Rows(0)("Status") = "완료"

주의한 점

아래처럼 새 객체를 다시 할당하는 것은 다르다.

dtData = New DataTable()

이 경우 외부 변수가 자동으로 새 DataTable을 바라보지는 않는다.
외부에도 새 객체를 전달해야 한다면 Out 또는 In/Out 인수를 써야 한다.

정리한 기준

DataTable 내부 행/컬럼/값을 수정한다 → In으로도 외부 반영 가능
DataTable 변수에 새 객체를 할당한다 → Out 또는 In/Out 필요

2. String은 참조 타입인데 왜 값처럼 보이는가

문제 상황

VB.NET에서 String은 참조 타입이라고 알고 있었다.
그런데 UiPath Workflow에서 String을 In으로 넘기고 내부에서 값을 바꿔도 외부 값은 바뀌지 않았다.

원인

문자열은 불변 객체다.
즉, 기존 문자열 자체를 수정하는 것이 아니라 변경 결과로 새 문자열을 만든다.

예시:

strText = strText.Replace("A", "B")

이 코드는 기존 문자열을 직접 수정하는 것이 아니다.
Replace 결과로 새 문자열을 만들고, 그 새 문자열을 strText 변수에 다시 할당하는 구조다.

정리한 기준

String 값을 하위 Workflow에서 바꾸고 외부에도 반영해야 한다 → Out 또는 In/Out
String을 읽기만 한다 → In
String은 참조 타입이지만 불변 객체라 값처럼 다루는 편이 안전하다

3. 시스템마다 식별 코드의 공백·선행 0 표기가 다를 때

문제 상황

같은 값을 나타내는 식별 코드인데 시스템마다 표기 방식이 달라
단순 문자열 비교에서 불일치가 발생하는 경우가 있었다.

예를 들어 코드 구조가 문자부 + 숫자부로 정해져 있는데 다음처럼 표현될 수 있다.

ABC 0012
ABC12
ABC    12

업무적으로는 같은 코드지만 문자열 자체는 서로 다르다.

반대로 문자열 안의 숫자만 무조건 추출해서 비교하면
형식이 잘못된 데이터까지 정상 코드로 받아들일 위험이 있다.

내가 적용한 방향

먼저 해당 코드가 예상한 형식인지 검증한 뒤
문자부와 숫자부를 분리해서 각각 정규화한다.

문자부 → Trim, 필요하면 대소문자 통일
숫자부 → 숫자 형식 검증 후 정수 값으로 비교

숫자부를 정수로 해석하면 아래 값은 동일하게 비교할 수 있다.

0012 → 12
12   → 12

따라서 최종 비교 기준을 문자열 원본이 아니라
정규화된 문자부 + 정규화된 숫자부로 잡을 수 있다.

왜 숫자만 바로 추출하지 않았는가

예상한 코드 구조를 확인하지 않고 모든 숫자를 뽑으면
다음처럼 비정상 문자열도 잘못 정규화될 수 있다.

정상 예시: ABC 0012
비정상 예시: AB12CD34

비정상 형식까지 임의로 1234 같은 값으로 만들어 비교하면
데이터 오류를 숨기게 된다.

그래서 정규화 전에 형식 검증을 먼저 하는 구조가 안전하다.

정리한 기준

앞뒤 공백 차이 → Trim
문자부 대소문자 차이 → 필요하면 ToUpper/ToLower로 통일
중간 공백 차이 → 코드 구조에 맞게 문자부와 숫자부를 분리
숫자부의 선행 0 차이 → 숫자 형식 확인 후 정수 값으로 비교
예상 형식과 다르다 → 억지로 보정하지 않고 실패 또는 원본 유지

이 방식은 특정 업무 코드에 한정되지 않는다.
사번, 접수번호, 장비번호, 문서번호처럼 문자 Prefix와 숫자 식별자가 결합된 값을
서로 다른 시스템 사이에서 비교할 때 같은 기준을 적용할 수 있다.

4. 클래식 UI 자동화와 모던 UI 자동화의 차이

문제 상황

클래식 액티비티에서는 Browser 변수를 사용했는데, 모던 UI 자동화에서는 같은 방식이 잘 맞지 않았다.

내가 정리한 차이

클래식 방식은 보통 아래 액티비티 중심으로 구성된다.

Open Browser
Attach Browser
Classic Click
Classic Type Into

이 구조에서는 Browser 타입 변수를 직접 다루는 방식이 자연스럽다.

반면 모던 방식은 아래 구조를 중심으로 사용한다.

Use Application/Browser
Check App State
Modern Click
Modern Type Into
Table Extraction

모던에서는 Browser 변수를 직접 넘겨가며 제어하기보다, Use Application/Browser Scope 안에서 대상 애플리케이션을 잡고 처리하는 방식이 더 자연스럽다.

정리한 기준

기존 Browser 변수 기반 구조가 많다 → 클래식 구조를 유지하는 편이 변경 비용이 낮을 수 있음
Use Application/Browser, Check App State, Modern Table Extraction 중심이다 → 모던 구조가 자연스러움
한 흐름에서 섞어야 한다 → Scope 경계와 대상 지정 기준을 명확히 분리

클래식과 모던을 섞는 것이 불가능한 것은 아니다.
다만 유지보수 난이도가 올라가므로, 한 업무 흐름 안에서는 가능하면 한 방식을 기준으로 잡는 편이 낫다.

5. URL에 sessionId 같은 동적 값이 있을 때 셀렉터 처리하기

문제 상황

URL에 매번 바뀌는 값이 들어가서 셀렉터가 불안정해졌다.

예시:

https://example.com/search?sessionId=ABC123&page=1

sessionId 값은 실행마다 바뀔 수 있으므로 셀렉터에 그대로 넣으면 다음 실행에서 깨질 가능성이 있다.

내가 적용한 방식

동적으로 바뀌는 부분은 와일드카드로 처리했다.

<html app='chrome.exe' url='https://example.com/search?sessionId=*&amp;page=1' />

page 값도 바뀌면 다음처럼 처리할 수 있다.

<html app='chrome.exe' url='https://example.com/search?sessionId=*&amp;page=*' />

주의한 점

셀렉터는 XML 형식이므로 URL의 &는 그대로 쓰지 않고 &로 작성해야 한다.

잘못된 표현: &
올바른 표현: &amp;

정리한 기준

sessionId, token, timestamp처럼 매번 바뀐다 → 와일드카드 처리
업무적으로 의미 있는 값이다 → 필요한 경우만 유지
URL 전체가 불안정하다 → url 속성 의존도를 낮추고 다른 속성 검토

6. Type Into 입력 문자열에 `[`가 포함될 때 Special Keys Syntax Error

문제 상황

Type Into에 전달하는 일반 문자열 안에 [ 문자가 들어 있었는데
아래와 비슷한 오류가 발생했다.

Special keys syntax error

문자열 변수 자체에는 문제가 없는데 Type Into에서만 실패했다.

원인 판단

Type Into는 일반 문자뿐 아니라 Tab, Enter 같은 Special Key 입력도 같은 입력 영역에서 처리한다.
그래서 입력 문자열에 대괄호 같은 문자가 포함된 경우,
사용 중인 Type Into 방식에서는 일반 텍스트가 아니라 Special Key 문법으로 해석되어 오류가 날 수 있었다.

중요한 점은 String 자체의 문제가 아니라
Type Into가 입력 문자열을 해석하는 단계에서 발생하는 문제라는 것이다.

내가 적용·검토한 방식

1. 대상 컨트롤이 지원하면 Simulate 입력 방식 검토
2. 단순 텍스트 입력이면 Set Text 사용 가능 여부 확인
3. 원문을 그대로 보내야 하면 Clipboard 붙여넣기 방식 검토
4. 기존 Type Into 방식을 유지해야 하면 `[` escape 방식이 실제 환경에서 동작하는지 테스트

기존 Type Into 방식을 유지하는 경우에는 환경에 따라 아래처럼 [를 이스케이프하는 방식도 사용할 수 있었다.

strText.Replace("[", "[[")

다만 이 표현을 모든 Type Into/Input Mode의 공통 규칙으로 보기보다는
현재 사용하는 액티비티와 Input Mode에서 재현 테스트 후 적용하는 것이 안전하다.

정리한 기준

String에는 정상인데 Type Into에서만 실패한다 → 입력 문자열 해석 문제 확인
`[` 같은 문자가 포함되어 있다 → Special Key 문법 충돌 여부 확인
단순 텍스트만 넣는다 → Set Text 또는 Simulate 입력 검토
원문 보존이 중요하다 → Clipboard 방식도 검토
escape를 적용한다 → 실제 Input Mode에서 먼저 테스트

7. 화면에는 전체 목록이 있는데 Table Extraction 결과가 일부 행만 나올 때

문제 상황

웹 화면의 목록은 스크롤하면 계속 항목이 보이는데,
Modern Extract Table Data로 추출하면 화면에 현재 렌더링된 일부 행만 가져오는 문제가 있었다.

예를 들어 한 번에 약 15개 정도만 추출되고,
스크롤을 내리면 기존 행이 사라지고 새로운 행으로 바뀌는 형태였다.

반면 조회 요청의 JSON 응답에는 전체 데이터가 들어 있었다.

원인 판단

이 경우 데이터가 이미 모두 로딩되어 있더라도, 화면 DOM에는 일부 행만 유지하는 가상 스크롤(virtualized list/grid) 구조를 먼저 의심할 수 있다.

가상 스크롤 UI는 전체 데이터를 가지고 있더라도
DOM에는 현재 화면 주변의 행만 만들어 두고 스크롤할 때 기존 DOM을 재사용하거나 교체할 수 있다.

따라서 화면상으로는 전체 목록처럼 보여도
UI 기반 Table Extraction에서 현재 렌더링된 행만 식별되는 상황이 생길 수 있다.

UiPath의 일반 Table Extraction 문서도 No Limit을
화면에서 식별 가능한 테이블을 기준으로 설명한다.
일부 프레임워크에는 가상화 테이블 전용 지원이 추가되어 있지만,
모든 웹 그리드가 자동으로 전체 데이터를 추출해 주는 것은 아니다.

확인 방법

스크롤 전후에 DOM 행 개수가 일정한지 확인
스크롤하면 기존 행의 텍스트만 교체되는지 확인
Table Extraction Preview의 행 수 확인
화면에 보이는 행 수와 추출 행 수가 비슷한지 확인
Network 응답에는 전체 데이터가 있는지 확인

대응 방향

방법 1. UI 기준으로 현재 보이는 Batch를 추출하고 스크롤하면서 누적
방법 2. 페이지/Next 버튼이 실제로 존재하면 Table Extraction의 페이지 이동 사용
방법 3. 대상 시스템이 제공하는 공식 API나 허용된 데이터 인터페이스가 있으면 UI 대신 사용

브라우저의 내부 API를 직접 호출하는 방식은 인증 토큰, 세션, 보안 정책에 영향을 받으므로
단순히 JSON이 보인다는 이유만으로 바로 운영 로직에 넣는 것은 피하는 편이 좋다.

정리한 기준

No Limit인데 일부만 나온다 → 단순 Row 제한보다 DOM 가상화 여부 확인
스크롤할 때 행 자체가 교체된다 → 가상 스크롤 가능성 높음
Next 버튼이 있다 → 페이지 기반 추출 우선 검토
JSON에는 전체 데이터가 있다 → UI와 데이터 계층이 분리된 구조일 수 있음

8. “입력 내용이 화면 경계를 벗어납니다” 오류

문제 상황

UiPath 실행 중 아래 오류가 발생했다.

입력 내용이 화면 경계를 벗어나므로 UI 엘리먼트에 보낼 수 없습니다.

내가 확인한 원인

이 오류를 만났을 때 입력 문자열만 확인해서는 원인을 찾지 못했다.
UiPath의 해상도·배율·대상 가시성 관련 문서와 실제 실행 환경을 기준으로 아래 항목을 우선 점검했다.

아래 항목은 이 오류의 단일 원인 목록이라기보다 트러블슈팅 체크리스트로 보는 편이 정확하다.

대상 엘리먼트가 화면 밖에 있음
창이 최소화되어 있음
브라우저 또는 프로그램이 비활성 상태임
해상도 또는 배율이 다름
셀렉터는 잡혔지만 실제 좌표가 비정상임
스크롤이 필요한 위치에 대상이 있음
원격 세션 상태가 UI 자동화에 적합하지 않음

내가 적용한 대응

1. 창을 Maximize 처리
2. 대상 창 Activate
3. 필요한 경우 Scroll Into View
4. Element Exists 또는 Check App State로 대상 확인
5. 입력 방식 변경 검토
6. 운영 PC의 해상도와 배율 확인
7. 원격 세션 종료 방식 확인

정리한 기준

개발 PC에서는 되는데 운영 PC에서 실패한다 → 해상도, 배율, 화면 상태 확인
가끔 실패한다 → 로딩 대기, Activate, Scroll 처리 추가
항상 실패한다 → 셀렉터 또는 대상 컨트롤 상태 확인
원격 접속 종료 후 실패한다 → 세션 유지 방식 확인

9. Excel COM 오류: RPC_E_DISCONNECTED

문제 상황

Excel 자동화 중 아래 오류가 발생했다.

호출된 개체가 해당 클라이언트로부터 연결이 끊겼습니다.
HRESULT: 0x80010108 (RPC_E_DISCONNECTED)

내가 확인한 방향

RPC_E_DISCONNECTED는 COM 개체와 호출 측의 연결이 끊긴 상태를 나타내는 오류다.
다만 UiPath 공식 문서가 Copy/Paste, 파일 잠금, Scope 복잡도를 이 HRESULT의 직접 원인으로 규정하고 있지는 않다.

따라서 아래 항목은 직접 원인으로 단정하지 않고, 오류가 발생했을 때 함께 점검한 실행 환경과 작업 패턴으로 정리하는 편이 정확하다.

Excel 프로세스가 비정상 종료되었는지
Excel이 응답 없음 상태였는지
동일 파일을 다른 프로세스가 사용 중인지
UI/클립보드 기반 Copy/Paste 비중이 높은지
Excel Scope의 생성·종료가 지나치게 반복되는지
Save/Close 시점과 Excel 프로세스 수명이 맞는지

내가 적용한 방향

가능하면 화면 기반 Copy/Paste를 줄이고 DataTable 기반 처리로 바꿨다.

Read Range
Write Range
Append Range
DataTable 조작
Workbook 기반 처리

정리한 기준

대량 데이터 복사/붙여넣기가 많다 → Read/Write Range 등 데이터 기반 처리 검토
간헐적 COM 연결 오류 → Excel 프로세스 상태와 Save/Close 순서 확인
항상 같은 구간에서 발생한다 → 해당 구간에서 Excel 개체가 종료·재생성되는지 확인
운영 PC에서만 오류 → Office 버전, 권한, 프로세스 상태 등 실행 환경 비교

10. 패키지 의존성 오류

문제 상황

다른 PC에서 가져온 UiPath 프로젝트를 열었더니 패키지 의존성 오류가 발생했다.
패키지 복구를 눌러도 제한된 네트워크 환경에서는 복구가 되지 않았다.

내가 확인한 항목

project.json의 dependencies
Studio의 Manage Packages 설정
로컬 패키지 경로
기존 개발 PC의 패키지 캐시
사내 라이브러리 패키지 존재 여부
패키지 소스 우선순위

내가 적용한 방식

실제 내부 경로나 저장소 정보는 공개하지 않고, 해결 흐름만 정리하면 다음과 같다.

1. 기존 개발 PC에서 필요한 패키지 파일 확인
2. 대상 PC에서 참조 가능한 로컬 패키지 경로 구성
3. Studio 패키지 소스에 로컬 경로 추가
4. project.json의 dependencies와 실제 패키지 버전 확인
5. Restore 재시도

정리한 기준

인터넷이 가능한 개발 환경 → 공식 피드에서 Restore 가능
제한된 네트워크 환경 → 로컬 패키지 또는 내부 패키지 저장소 필요
프로젝트만 복사했다 → 패키지 누락 가능성 높음
사내 라이브러리를 쓴다 → 해당 라이브러리 패키지도 같이 이관 필요
패키지 버전이 다르다 → project.json 기준으로 맞춰야 함

11. 방화벽 제한 환경에서 UiPath 패키지 복구가 안 될 때

문제 상황

UiPath 프로젝트를 열었을 때 패키지 복구가 필요했지만, 네트워크 제한 때문에 패키지를 다운로드하지 못했다.
처음에는 단순히 “인터넷이 안 된다” 정도로 봤지만, 실제로는 Studio, Robot, Orchestrator, 패키지 피드 간 통신 경로를 구분해서 봐야 했다.

내가 정리한 확인 방식

방화벽 요청은 단순히 “열어주세요”가 아니라 아래 항목으로 정리하는 게 좋았다.

구분	작성 예시
출발지	`<개발 PC>`, `<Robot PC>`
목적지	`<Orchestrator URL>`, `<패키지 피드 URL>`, `<Automation Cloud 관련 URL>`
프로토콜	HTTPS
포트	443
용도	Studio 로그인, 패키지 복구, Robot-Orchestrator 통신, 라이선스 확인 등
대상 프로그램	UiPath Studio, UiPath Robot
비고	프록시, 인증서 검사, 내부망 정책 확인 필요

내가 적용한 표현 방식

공개 글에서는 실제 도메인이나 내부 URL을 쓰지 않고 아래처럼 일반화한다.

출발지: <개발 PC 또는 Robot PC>
목적지: <UiPath Orchestrator 또는 패키지 피드>
프로토콜: HTTPS
포트: TCP 443
용도: 패키지 복구, Robot 연결, Studio 로그인

방화벽 이슈를 의심한 기준

Studio에서 패키지 Restore가 실패한다
Manage Packages에서 피드 목록은 보이지만 다운로드가 실패한다
개발 PC에서는 되는데 운영 PC에서는 안 된다
Robot이 Orchestrator에 연결되지 않는다
로그인 또는 라이선스 확인 단계에서 실패한다

내가 정리한 대응 방향

1. 패키지 복구 실패인지, Orchestrator 연결 실패인지 구분
2. Studio PC와 Robot PC의 네트워크 정책이 같은지 확인
3. 공식 피드 사용인지 내부 패키지 저장소 사용인지 확인
4. 폐쇄망이면 로컬 패키지 또는 내부 패키지 저장소 방식 검토
5. 방화벽 요청 시 출발지, 목적지, 포트, 용도를 명확히 정리

정리한 기준

패키지 다운로드만 실패한다 → 패키지 피드 접근 확인
Robot 연결만 실패한다 → Orchestrator 접근 확인
Studio 로그인만 실패한다 → 인증/라이선스 관련 통신 확인
개발 PC만 정상이다 → 운영 PC의 방화벽, 프록시, 인증서 정책 확인
폐쇄망이다 → 외부 다운로드 전제 구조를 버리고 로컬 패키지 전략 필요

방화벽 관련 내용은 보안상 삭제할 것이 아니라, 실제 도메인과 내부 경로를 제거하고 통신 구조 중심으로 일반화해서 정리하는 것이 적절하다.

12. Job은 실행되는데 Orchestrator에 실행 로그가 보이지 않을 때

문제 상황

Robot에서는 Job이 실제로 실행되고 있었지만 Orchestrator의 Job/Logs 화면에는 실행 로그가 나타나지 않았다.

특히 Robot PC의 디스크 공간이 부족한 상태에서 디스크 정리를 수행한 뒤부터 증상이 나타나,
처음에는 Orchestrator 연결 자체가 끊어진 것인지 의심했다.

먼저 구분한 것

Job 자체가 실행되지 않는다
vs
Job은 실행되는데 실행 로그만 올라오지 않는다

두 경우는 원인이 다를 수 있다.

Job이 실행되고 있다면 Robot-Orchestrator 연결 전체가 끊긴 것으로 단정하기보다
Robot의 로컬 실행 로그 처리/전송 경로를 따로 확인하는 것이 좋다.

확인할 항목

UiPath 공식 문서 기준으로 Robot은 Orchestrator에 로그를 보내지 못하는 경우
로컬 로그 저장소에 실행 로그를 보관했다가 연결이 복구되면 전송할 수 있다.

또한 로컬 로그용 LiteDB가 손상되면
프로세스는 실행되는데 Orchestrator에 새 실행 로그가 표시되지 않는 증상이 발생할 수 있다.

1. Robot.log에 로깅 관련 오류가 있는지 확인
2. "Logging database abandoned." 같은 메시지 확인
3. Robot Service 상태 확인
4. 로컬 실행 로그 저장소의 디스크 여유 공간 확인
5. Orchestrator/Assistant의 Logging Level 확인

LiteDB 손상이 확인된 경우 UiPath 문서에서는 Robot Service 재시작을 해결 절차로 안내한다.

정리한 기준

Job도 실행되지 않는다 → Robot/Orchestrator 연결 및 실행 환경부터 확인
Job은 실행되지만 로그만 없다 → 로컬 로그 DB와 로그 전송 경로 확인
디스크가 가득 찬 이력이 있다 → 로그 저장소 손상/쓰기 실패 여부 확인
Robot.log에 Logging database abandoned가 있다 → LiteDB 문제 의심

주의

디스크 정리를 했다는 사실만으로 LiteDB 손상이 원인이라고 단정하면 안 된다.
실제 Robot.log 메시지와 Robot Service 상태를 확인한 뒤 결론을 내리는 것이 맞다.

13. 짧은 주기 스케줄에서 Job이 겹칠 때 먼저 확인할 것

문제 상황

짧은 주기로 Trigger를 실행하면 이전 Job이 끝나기 전에 다음 실행 시각이 올 수 있다.
처음에는 프로세스 내부에 별도 실행 잠금 로직을 반드시 넣어야 한다고 생각했지만, 먼저 Orchestrator 자체의 Job 큐잉 동작을 확인할 필요가 있었다.

확인한 내용

Orchestrator는 실행 대상과 할당 방식에 따라 겹치는 Trigger의 Job을 Pending 상태로 큐잉한다.
같은 프로세스를 같은 Robot에 여러 번 예약해 실행 시간이 겹치는 경우에는 대기 Job을 무한히 누적시키는 방식으로만 동작하지 않는다.

따라서 짧은 주기 Trigger = 무조건 내부 Lock 구현으로 볼 필요는 없다.

내부 방어가 추가로 필요한 경우

여러 Trigger나 여러 Robot이 동일 외부 자원을 동시에 처리할 수 있음
업무적으로 절대 동시 실행이 허용되지 않음
Orchestrator 외부에서도 동일 프로세스를 시작할 수 있음
Job 큐잉보다 더 엄격한 업무 단위 중복 방지가 필요함

이런 경우에는 Asset, 파일 Lock, DB 상태값 등 별도의 동시성 제어를 검토할 수 있다.
다만 Lock을 직접 구현하면 비정상 종료 후 잠금이 남는 문제까지 설계해야 한다.

정리한 기준

Trigger 주기가 짧다 → 먼저 Orchestrator의 Pending/할당 동작 확인
같은 Robot의 같은 프로세스다 → 실제 큐잉 동작을 확인한 뒤 추가 방어 판단
여러 실행 주체가 동일 자원을 건드린다 → 별도 Lock 검토
직접 Lock을 구현한다 → 비정상 종료 시 해제/만료 전략 필수

14. Queue와 단순 반복 처리의 차이

문제 상황

Queue가 단순히 List를 반복하는 것과 무엇이 다른지 헷갈렸다.

내가 정리한 차이

Queue는 단순 반복문이 아니다.
Orchestrator에서 처리 건을 상태로 관리하는 구조다.

대표적으로 아래와 같은 상태 흐름을 가진다.

New
In Progress
Successful
Failed
Retried
Abandoned
Deleted

상태 종류는 UiPath 버전과 설정에 따라 표현이 달라질 수 있으므로, 글에서는 “대표적으로”라고 표현하는 것이 안전하다.

Queue가 적합한 경우

처리 대상이 건 단위로 명확함
실패 건을 재처리해야 함
성공/실패 상태를 Orchestrator에서 보고해야 함
여러 Robot이 나눠 처리할 수 있음
트랜잭션 단위 로그가 중요함

Queue가 과할 수 있는 경우

웹사이트에서 실시간으로 조회함
조회 결과가 없으면 바로 종료함
Input 데이터가 사전에 쌓여 있지 않음
단순 상태 확인성 프로세스임
건별 재처리 필요성이 낮음

정리한 기준

건별 상태 관리가 필요하다 → Queue
재처리와 Retry가 중요하다 → Queue
단순 조회 후 있으면 처리, 없으면 종료 → While 반복 구조 검토
결과만 취합하면 된다 → Queue가 과할 수 있음

15. REFramework를 무조건 Queue 구조로 볼 필요는 없다

문제 상황

REFramework를 사용하려고 했지만, Input 데이터가 Queue에 미리 쌓여 있는 구조가 아니었다.
웹에서 실시간으로 조회한 뒤, 처리할 건이 있으면 진행하고 없으면 종료하는 업무였다.

내가 정리한 구조

기본 REFramework 구조는 다음과 같다.

Init
Get Transaction Data
Process Transaction
End Process

하지만 모든 업무가 Queue 기반에 맞는 것은 아니다.

공식 프로젝트 구성 가이드에서도 REFramework의 입력 소스는 Orchestrator Queue로만 한정되지 않는다.
Queue가 아니라 다른 입력 소스에서 다음 Transaction을 가져오는 구조로도 설계할 수 있다.

실시간 조회형 업무라면 먼저 아래 두 구조를 비교하는 편이 정확하다.

A. Transaction 단위로 다루고 싶다
   Get Transaction Data
     - 웹/파일/DB 등에서 다음 처리 건 조회
     - 없으면 종료
   Process Transaction
     - 한 건 처리

B. 조회 결과 전체를 하나의 Batch로 다룬다
   Process
     - 대상 조회
     - 없으면 종료
     - 있으면 내부 반복 처리

B처럼 Process 내부에서 While로 전부 처리하는 것도 가능하지만,
이 경우 REFramework가 제공하는 건별 Transaction Retry, 건별 예외 흐름, TransactionNumber 기반 관리의 이점을 일부 포기하게 된다.

따라서 단순히 “Queue가 아니므로 While”로 결정하기보다 무엇을 한 건(Transaction)으로 볼지를 먼저 정하는 것이 중요하다.

처리 대상이 없는데 후속 시스템까지 접근하지 않는다는 판단은 그대로 유효하다.

정리한 기준

Queue가 아니어도 REFramework 사용 가능 → 다른 입력 소스에서 Transaction 조회 가능
건별 Retry/로그가 중요하다 → Get Transaction Data에서 한 건씩 공급
전체 조회 결과를 한 Batch로 처리해도 된다 → Process 내부 반복도 가능
처리 대상이 없다 → 불필요한 후속 시스템 접근 전에 종료

16. RDP 세션 종료 후 UI 자동화가 실패할 때

문제 상황

원격 환경에서 UiPath를 실행할 때, RDP 접속을 종료한 뒤 UI 자동화가 실패하는 경우가 있었다.
특히 화면 클릭, 입력, 엘리먼트 인식 같은 작업은 원격 세션 상태에 영향을 받았다.

내가 확인한 원인

UI 자동화는 실제 화면 상태에 의존하는 경우가 많다.
따라서 원격 세션을 그냥 닫거나 화면이 잠기면 아래 문제가 생길 수 있다.

화면 렌더링 중단
해상도 변경
창 비활성화
엘리먼트 좌표 계산 오류
입력 대상이 화면 밖으로 인식됨

내가 정리한 대응 방식

운영 환경에서는 가능하면 Unattended Robot 구성을 우선 검토한다.
불가피하게 원격 세션 기반으로 실행해야 한다면, RDP 세션 종료 방식도 운영 절차에 포함해야 한다.

일반적으로 확인할 항목은 다음과 같다.

1. Robot 실행 계정으로 정상 로그인되어 있는가
2. 실행 중 화면 잠금이 발생하지 않는가
3. 해상도와 배율이 고정되어 있는가
4. RDP 종료 후에도 UI 자동화가 가능한 상태로 세션이 유지되는가
5. 관리자 권한이 필요한 명령을 쓰고 있지는 않은가
6. 작업 스케줄러 실행 계정과 실제 로그인 계정이 일치하는가

세션 상태 확인

실제 계정명이나 세션 ID를 공개하지 않고 세션 상태를 확인하려면 다음과 같은 Windows 명령을 사용할 수 있다.

query user <계정명>

이 명령으로 사용자 세션 이름, Session ID, 상태 등을 확인할 수 있다.

과거에는 tscon ... /dest:console 방식으로 RDP 세션을 콘솔 쪽으로 넘기는 우회 방식을 검토했지만,
Microsoft의 현재 tscon 문서는 console session에 연결할 수 없다고 명시하고 있다.
따라서 이 명령을 모든 Windows/UiPath 운영 환경에서 사용할 수 있는 일반적인 해결책으로 블로그에 제시하는 것은 적절하지 않다.

특정 환경에서 실제로 동작을 검증한 내부 운영 절차라면 별도로 기록할 수 있지만,
공개 글의 기본 해결책은 UiPath가 권장하는 Service Mode/Unattended 세션 구성과 Robot의 Windows Session 설정을 우선하는 편이 안전하다.

정리한 기준

운영 UI 자동화다 → UiPath Unattended/Service Mode 세션 구성을 우선
RDP 종료 후 실패한다 → 화면 렌더링 중단 가능성 확인
세션 상태가 필요하다 → query user 등으로 Session ID/State 확인
tscon 우회 방식 → 범용 해결책으로 단정하지 말고 환경별 검증 필요

RDP 관련 내용도 무조건 숨길 필요는 없다.
다만 실제 계정명, 서버명, 세션 ID, 내부 접속 방식은 제거하고, “원격 세션 상태가 UI 자동화에 영향을 준다”는 구조 중심으로 작성하는 것이 안전하다.

17. 운영 PC 환경에서 확인한 항목

문제 상황

개발 PC에서는 정상 동작했지만 운영 PC 또는 원격 환경에서는 UI 자동화가 실패하는 경우가 있었다.

내가 확인한 항목

해상도 고정 여부
디스플레이 배율
절전 모드 여부
화면 잠금 정책
브라우저 업데이트 영향
UiPath 브라우저 확장 프로그램 설치 여부
Windows 업데이트 후 재부팅 영향
Robot 실행 계정 권한
다운로드/임시 폴더 접근 권한
Office 버전
Outlook 프로필 설정
원격 세션 종료 방식

정리한 기준

UI 자동화가 간헐적으로 실패한다 → 해상도, 배율, 화면 잠금 확인
브라우저 셀렉터가 갑자기 깨진다 → 브라우저 업데이트 영향 확인
운영 시간 중 실패한다 → 재부팅 또는 세션 상태 확인
Excel/Outlook 오류가 난다 → Office 버전, 프로필, 권한 확인
원격 환경에서만 실패한다 → RDP 세션 상태와 실행 계정 확인

운영 PC 문제는 소스 코드 문제가 아니라 실행 환경 문제인 경우가 많았다.
따라서 개발 완료 후에는 운영 PC 기준으로 별도 점검표를 두는 것이 좋다.

18. HTML 메일 서식이 깨질 때

문제 상황

UiPath에서 HTML 메일을 작성해 보냈는데, Outlook에서 테이블 서식이 깨지는 경우가 있었다.

내가 확인한 원인

메일 클라이언트는 일반 브라우저와 HTML/CSS 렌더링 방식이 다를 수 있다.
특히 Classic Outlook은 Word 기반 HTML 렌더링의 제약 때문에 일부 CSS가 브라우저와 다르게 표현될 수 있다.

반면 New Outlook/Web Outlook은 렌더링 구조가 다르므로, 글에서는 단순히 “Outlook 전체가 동일하게 CSS를 제한한다”고 표현하지 않는 편이 정확하다.

내가 적용한 방식

중요한 스타일은 인라인으로 넣었다.

<table style='width:800px; border-collapse:collapse;'>
    <tr>
        <td style='border:1px solid #999; padding:4px;'>값</td>
    </tr>
</table>

VB.NET 문자열 안에서 HTML을 만들 때는 큰따옴표보다 작은따옴표를 쓰는 편이 편했다.

<td style='padding:4px;'>값</td>

동적으로 행을 추가할 때는 새로 생성되는 모든 td에 스타일을 직접 넣었다.

strRows = strRows &
"<tr>" &
"<td style='border:1px solid #999; padding:4px;'>" & value1 & "</td>" &
"<td style='border:1px solid #999; padding:4px;'>" & value2 & "</td>" &
"</tr>"

정리한 기준

Classic Outlook에서 서식이 깨진다 → 인라인 CSS와 테이블 기반 레이아웃 우선 검토
브라우저에서는 정상인데 Classic Outlook에서 깨진다 → Word 기반 HTML/CSS 제한 확인
동적 테이블 일부만 깨진다 → 생성된 td/tr에 스타일 누락 확인
HTML이 텍스트로 보인다 → UiPath의 Body as HTML / IsBodyHtml 설정 확인

19. 최종 판단 기준 요약

변수와 인수

String을 하위에서 바꾸고 외부에도 반영 → Out 또는 In/Out
DataTable 내부 내용 수정 → 비격리 Workflow 호출에서는 In으로도 외부 객체에 반영될 수 있음
DataTable 새 객체 할당 → Out 또는 In/Out 필요
String은 참조 타입이지만 불변 객체 → 값처럼 다루는 편이 안전

데이터 정규화

시스템마다 같은 코드 표기가 다르다 → 원본 문자열 그대로 비교하지 않기
문자부 차이 → Trim, 필요하면 대소문자 통일
숫자부 선행 0 차이 → 형식 검증 후 숫자 값으로 비교
예상 형식과 다르다 → 무리하게 보정하지 않고 실패/원본 유지

UI 자동화

동적 URL → 와일드카드 처리
URL 셀렉터의 & → &amp;로 작성
기존 Browser 변수 기반 구조 → 클래식 유지 시 변경 비용 검토
Use Application/Browser 중심 → 모던 구조가 자연스러움
Type Into에서 특수문자 오류 → Special Key 해석과 Input Mode 확인
No Limit인데 일부 행만 추출 → DOM 가상화 여부 확인
스크롤할 때 기존 행이 교체됨 → 가상 스크롤 구조 의심
화면 경계 오류 → 해상도, 배율, Activate, Scroll 확인
셀렉터 불안정 → 동적 속성 제거, 안정 속성 위주로 재구성
원격 환경 실패 → 세션 상태와 화면 렌더링 확인

Excel 자동화

RPC_E_DISCONNECTED → Excel COM 개체 연결 상태부터 확인
Copy/Paste 비중이 높다 → Read/Write Range 등 데이터 기반 처리 검토
간헐적 COM 오류 → Excel 프로세스 상태와 Save/Close 순서 확인
운영 PC에서만 실패 → Office 버전, 권한, 실행 환경 비교

패키지와 네트워크

패키지 Restore 실패 → 패키지 소스와 버전 확인
제한된 네트워크 환경 → 로컬 패키지 또는 내부 패키지 저장소 필요
방화벽 요청 → 출발지, 목적지, 프로토콜, 포트, 용도 기준으로 정리
Robot 연결 실패 → Orchestrator 접근 확인
개발 PC만 정상 → 운영 PC의 네트워크, 프록시, 인증서 정책 확인

Orchestrator와 실행 관리

Job도 실행되지 않는다 → Robot/Orchestrator 연결과 실행 환경 확인
Job은 실행되는데 로그만 없다 → 로컬 로그 DB와 전송 경로 확인
디스크가 가득 찬 이력이 있다 → 로그 저장소 쓰기 실패/손상 여부 확인
짧은 주기 Trigger → 먼저 Pending/할당 동작 확인
여러 실행 주체가 동일 자원을 처리 → 별도 Lock 필요성 검토

Queue와 REFramework

건별 상태 관리 필요 → Queue
실패 건 재처리 필요 → Queue
Queue가 아니어도 REFramework 사용 가능 → 다른 입력 소스에서 Transaction 조회 가능
건별 Retry/로그가 중요 → Get Transaction Data에서 한 건씩 공급
전체를 한 Batch로 처리해도 됨 → Process 내부 반복 검토
처리 대상이 없으면 → 불필요한 후속 시스템 접근 전에 종료

운영 환경

UI 자동화 운영 PC → 해상도, 배율, 절전, 잠금 정책 확인
브라우저 자동화 → 브라우저 업데이트 영향 확인
RDP 종료 후 실패 → 화면 렌더링과 Windows Session 상태 확인
운영 UI 자동화 → Unattended/Service Mode 세션 구성 우선 검토
Attended를 Unattended처럼 사용 → 운영 리스크가 커질 수 있음

마무리

UiPath에서 반복적으로 문제가 되는 지점은 단순 문법보다 실행 환경과 자동화 구조의 경계에 가까웠다.

1. Workflow 인수와 참조 타입의 동작 차이
2. 시스템 간 데이터 표기 차이와 정규화
3. 클래식/모던 UI 자동화, 동적 셀렉터, 가상 스크롤
4. Excel, Outlook, Browser 같은 외부 애플리케이션 의존성
5. 패키지, 방화벽, Orchestrator 로그와 운영 환경 차이
6. Trigger, Queue, REFramework의 실행 구조 판단
7. 원격 세션과 화면 렌더링 문제

RPA는 개발 PC에서 한 번 성공했다고 끝나는 작업이 아니다.
운영 환경에서 반복 실행되기 때문에 코드보다 세션, 화면 상태, 패키지, 네트워크, 데이터 형식, 실행 구조가 장애 원인이 되는 경우도 많다.

그래서 트러블슈팅은 단순히 “이렇게 하면 됨”으로 끝내기보다 아래 형식으로 정리한다.

문제 상황
내가 적용한 해결 방식
주의한 점
정리한 기준

단순 사용법은 별도 문법 정리로 분리하고,
이 문서에는 원인 판단과 운영 기준까지 남길 가치가 있는 문제를 중심으로 계속 추가한다.

FURVEN

슬로우스타터 개발자 일지

이전 포스트

UiPath & VB.NET 트러블슈팅 모음집

RPA

문서 기준

공개 글 작성 기준

1. DataTable은 In으로 넘겨도 내부 수정이 외부에 반영된다

문제 상황

원인

주의한 점

정리한 기준

2. String은 참조 타입인데 왜 값처럼 보이는가

문제 상황

원인

정리한 기준

3. 시스템마다 식별 코드의 공백·선행 0 표기가 다를 때

문제 상황

내가 적용한 방향

왜 숫자만 바로 추출하지 않았는가

정리한 기준

4. 클래식 UI 자동화와 모던 UI 자동화의 차이

문제 상황

내가 정리한 차이

정리한 기준

5. URL에 sessionId 같은 동적 값이 있을 때 셀렉터 처리하기

문제 상황

내가 적용한 방식

주의한 점

정리한 기준

6. Type Into 입력 문자열에 [가 포함될 때 Special Keys Syntax Error

문제 상황

원인 판단

내가 적용·검토한 방식

정리한 기준

7. 화면에는 전체 목록이 있는데 Table Extraction 결과가 일부 행만 나올 때

문제 상황

원인 판단

확인 방법

대응 방향

정리한 기준

8. “입력 내용이 화면 경계를 벗어납니다” 오류

문제 상황

내가 확인한 원인

내가 적용한 대응

정리한 기준

9. Excel COM 오류: RPC_E_DISCONNECTED

문제 상황

내가 확인한 방향

내가 적용한 방향

정리한 기준

10. 패키지 의존성 오류

문제 상황

내가 확인한 항목

내가 적용한 방식

정리한 기준

11. 방화벽 제한 환경에서 UiPath 패키지 복구가 안 될 때

문제 상황

내가 정리한 확인 방식

내가 적용한 표현 방식

방화벽 이슈를 의심한 기준

내가 정리한 대응 방향

정리한 기준

12. Job은 실행되는데 Orchestrator에 실행 로그가 보이지 않을 때

문제 상황

먼저 구분한 것

확인할 항목

정리한 기준

주의

13. 짧은 주기 스케줄에서 Job이 겹칠 때 먼저 확인할 것

문제 상황

확인한 내용

내부 방어가 추가로 필요한 경우

정리한 기준

14. Queue와 단순 반복 처리의 차이

문제 상황

내가 정리한 차이

Queue가 적합한 경우

Queue가 과할 수 있는 경우

정리한 기준

15. REFramework를 무조건 Queue 구조로 볼 필요는 없다

문제 상황

내가 정리한 구조

6. Type Into 입력 문자열에 `[`가 포함될 때 Special Keys Syntax Error