SAP GUI를 에이전트에게 맡기면 어디를 사람이 지켜야 할까

ADT를 붙인 코딩 에이전트는 ABAP 소스를 읽고 고치고, SQL로 테이블을 조회할 수 있다. ADT가 닿는 곳은 오브젝트까지다. 트랜잭션 화면을 열어 값을 넣고, F110 같은 자동지급을 돌리는 일은 여전히 SAP GUI에서 한다. SAP GUI Scripting을 붙이면 에이전트가 그 화면까지 다룰 수 있고, 그만큼 사람이 지켜야 할 자리가 생긴다. 이 글은 그 자리를 순서대로 짚고, 각 자리를 코드와 규칙으로 어떻게 막을지 적는다.

예로 드는 사례는 설명을 위해 지어낸 가상의 예다. 가상의 회사 A, 테스트 시스템 TST와 클라이언트 400, 거래처 100100, 금액은 모두 만든 값이다. 실제 회사나 시스템에서 돌린 기록이 아니다. 화면 그림과 코드도 설명용 예시이며, 실제 시스템을 캡처하거나 실행한 결과가 아니다.

• 로그인은 사람이 하고, 에이전트는 이미 열린 SAP GUI 세션에만 붙는다. 비밀번호는 에이전트를 거치지 않는다.
• 운영 세션은 조회만 하고, 쓰기는 미리 정한 QA 클라이언트에서만 한다. 이 규칙은 스크립트가 시스템과 클라이언트로 세션을 고르게 해서 코드로 지킨다.
• 보안 창, 지급 실행, 담당자 회신처럼 되돌리기 어려운 자리는 사람이 누른다.
• 조회 데이터로 낸 첫 답은 추론이다. 사람이 따라 할 절차는 QA에서 화면을 열어 확인한 뒤에 쓴다.

에이전트는 사람이 열어 둔 GUI에 붙는다

SAP 노트

에이전트는 열린 GUI에 붙는다

로그인은 사람, 화면 조작은 스크립트

1. 01

   사람

   • SAP 로그인은 사람이 한다
   • 비밀번호는 에이전트에 넘기지 않는다
2. 02

   스크립트

   • cscript로 VBScript를 실행한다
   • 실행 중인 SAP Logon에 COM으로 붙는다
3. 03

   세션

   GetObject("SAPGUI")

   • GuiApplication, GuiConnection, GuiSession
   • 화면 요소는 findById로 찾는다
4. 04

   경계

   • 운영 세션은 조회 화면만
   • 쓰기는 미리 정한 QA 클라이언트만

그림은 일반 구성이며 특정 시스템을 가리키지 않습니다.

구성은 단순하다. 에이전트가 PC에서 cscript로 VBScript를 실행하고, 스크립트는 실행 중인 SAP Logon에 COM으로 붙는다. GetObject("SAPGUI")에서 GetScriptingEngine을 부르면 GuiApplication이 나오고, 그 아래에 연결 GuiConnection과 세션 GuiSession이 있다. 화면 요소는 findById로 찾는다. 아래는 열린 세션을 시스템과 클라이언트로 나열하는 최소 예다.

Set app = GetObject("SAPGUI").GetScriptingEngine
For Each conn In app.Children
  For Each s In conn.Children
    WScript.Echo s.Info.SystemName & "/" & s.Info.Client
  Next
Next

• 스크립트가 OpenConnection으로 연결을 새로 열게 하지 않는다. 새 연결은 로그온 화면에서 시작하는 경우가 많아, 계정 정보를 스크립트에 넘길 길이 생긴다.
• Python의 pywin32로도 같은 COM 객체를 쓸 수 있다. VBScript는 따로 설치하지 않고 시작할 수 있지만, Microsoft가 단계적으로 없애겠다고 발표한 기능이다.
• cscript의 콘솔 출력은 콘솔 코드 페이지를 따르고 한글 Windows의 기본값은 CP949라, UTF-8로 읽는 쪽에서는 한글이 깨질 수 있다. 결과는 ADODB.Stream으로 UTF-8 파일에 쓰고, 에이전트가 그 파일을 읽게 한다.
• GUI에서 바꾼 값은 데이터베이스 조회로 다시 확인한다. 화면에 저장됐다는 메시지만으로 끝내지 않는다.

스크립팅은 서버와 클라이언트 둘 다 켜져 있어야 한다

SAP 노트

스크립팅은 양쪽이 켜져 있어야 한다

클라이언트, 서버, 지금 붙은 세션을 나눠 본다

• 클라이언트

  • SAP GUI 옵션의 Enable scripting과 레지스트리 UserScripting
  • 알림을 끌지는 사람이 정한다

• 서버

  • sapgui/user_scripting, 기본값은 꺼짐
  • RZ11로 바꾸면 다음 로그온부터 적용

• 지금 붙은 세션

  • GuiConnection.DisabledByServer
  • 세션 정보의 ScriptingModeReadOnly

• 운영에서 켜져 있다면

  • SE16N, FB03 같은 조회 화면만
  • 읽기 전용·사용자별 허용은 Basis와 검토

파라미터 이력 테이블은 지난 값의 기록이라 지금 값을 대신하지 못합니다.

클라이언트는 SAP GUI 옵션의 접근성 및 스크립팅 아래 스크립팅 화면에서 켠다. 값은 사용자 레지스트리 HKEY_CURRENT_USER\SOFTWARE\SAP\SAPGUI Front\SAP Frontend Server\Security의 UserScripting이고, 관리자가 HKEY_LOCAL_MACHINE 쪽 값을 0으로 두면 사용자는 켤 수 없다. 스크립트가 붙을 때와 연결을 열 때의 두 알림은 WarnOnAttach, WarnOnConnection이다.

알림은 스크립트가 사용자 모르게 도는 것을 막는 장치다. 끄면 작업이 덜 멈추지만 끌지는 사람이 정하고, 에이전트에게 레지스트리를 고치게 하지 않는다. 스크립트가 The control could not be found by id로 멈추면 대개 예상한 화면과 실제 화면이 다르다는 뜻이니, 떠 있는 알림이나 확인 창, 바뀐 화면부터 본다.

서버 스위치는 프로필 파라미터 sapgui/user_scripting이다. 기본값은 꺼짐이고, TRUE여야 그 애플리케이션 서버의 세션에서 스크립트가 돈다. 6.20 이후 릴리스는 RZ11에서 서버를 다시 시작하지 않고 바꿀 수 있고, 바꾼 값은 그 서버에 다음에 로그온할 때부터 적용된다. 다만 RZ11의 변경은 인스턴스를 다시 시작하면 프로필 값으로 돌아간다. 애플리케이션 서버마다 따로 켤 수 있어서, 같은 시스템이라도 로그온한 서버에 따라 결과가 다를 수 있다.

RZ11에서 현재 값을 볼 수 있지만, 에이전트가 붙은 세션이 정말 허용되는지는 그 세션에서 읽는 편이 확실하다. GuiConnection.DisabledByServer는 그 애플리케이션 서버에서 스크립팅이 켜지지 않았으면 True다. 세션 정보 GuiSessionInfo의 ScriptingModeReadOnly는 읽기 전용 모드인지 알려 준다. PAHI 같은 파라미터 이력 테이블은 기록된 시점의 값이라, 지금 붙은 서버의 현재 값을 보증하지 않는다.

For Each conn In app.Children
  WScript.Echo conn.Description & " server-disabled=" & conn.DisabledByServer
  If Not conn.DisabledByServer Then
    For Each s In conn.Children
      WScript.Echo "  " & s.Info.SystemName & "/" & s.Info.Client _
        & " read-only=" & s.Info.ScriptingModeReadOnly
    Next
  End If
Next

서버에는 범위를 좁히는 파라미터도 있다. 모두 sapgui/user_scripting이 켜진 뒤에 효과가 있고, 릴리스 조건이 따로 있다. 운영에서 스크립팅을 꼭 켜야 한다면 Basis 담당자와 이 중에서 고른다.

• sapgui/user_scripting_set_readonly: 스크립트는 속성을 읽고 읽기 전용 함수만 부를 수 있다. 서버로 보내는 화면 상태를 바꾸는 호출은 데이터베이스를 고치지 않더라도 막힌다.
• sapgui/user_scripting_per_user: 로그온한 뒤에는 권한 객체 S_SCR의 실행(16) 권한이 있는 사용자만 스크립팅을 쓴다.
• sapgui/user_scripting_force_notification: 스크립트가 그 시스템의 연결을 쓰려 할 때마다 사용자에게 허용할지 묻는다.
• sapgui/user_scripting_disable_recording: 스크립팅 이벤트를 꺼서 새 녹화를 막는다. 이미 쓴 스크립트는 돈다.

운영 세션에서도 스크립트가 돈다면 편하지만 위험하다. 그럴 때는 규칙을 먼저 적는다. 운영 세션에서는 SE16N, FB03 같은 조회 화면만 열고, 저장·전기·지급 실행처럼 데이터를 바꾸거나 잡을 예약하는 버튼은 누르지 않는다. 쓰기는 미리 정한 QA 클라이언트에서만 한다. 규칙은 문서만이 아니라 코드에도 둔다. 쓰기 스크립트는 시작할 때 시스템과 클라이언트로 세션을 고르고, 맞는 세션이 없으면 끝난다.

조회만으로 원인을 좁힌다

가상의 회사 A에서 매입 담당자가 이렇게 묻는다고 하자. 거래처 100100에 송장 세 건(500,000원, 400,000원, 300,000원)과 대변메모 한 건(200,000원)이 있는데, 자동지급(F110)을 돌리면 송장만 지급되고 대변메모가 차감되지 않는다.

운영에서는 조회만 한다. 에이전트는 SE16N이나 FB03으로 네 전표의 지급 관련 필드를 읽는다. 지급보류(ZLSPR), 지급 방법(ZLSCH), 기준일(ZFBDT)과 지급조건(ZTERM), 파트너은행유형(BVTYP), 주거래은행(HBKID)이 먼저 볼 필드다. 화면을 읽는 스크립트는 여기서 몇 가지 함정을 밟기 쉽다.

SE16N이 컬럼을 숨길 수 있다. 사용자에게 걸린 기본 ALV 레이아웃이 있으면 결과 그리드에 일부 컬럼만 보인다. 그리드 객체 GuiGridView의 ColumnOrder는 지금 표시된 컬럼의 식별자를 순서대로 준다. 원하는 필드가 없으면 데이터보다 레이아웃을 먼저 의심한다.

선택조건의 행 번호에 기대지 않는다. SE16N 선택조건은 보이는 행 수가 정해져 있고 필드 순서는 테이블마다 다르다. 기술명 열에서 필드를 찾아 그 행에 값을 넣는다.

셀 단위 읽기는 느리다. ALV 그리드를 GetCellValue로 한 칸씩 읽으면 칸마다 COM 호출이 생겨, 행과 열이 늘수록 시간이 빠르게 늘어난다. 필요한 컬럼만 읽고 선택조건을 좁힌다. F110 제안 목록처럼 ABAP 목록으로 뜨는 출력은 OK 코드 %pc로 파일에 저장한 뒤 그 파일을 읽게 하는 편이 낫다.

팝업은 다른 창이다. 확인 창이나 추가 입력 창처럼 팝업으로 뜨는 화면은 wnd[1] 이후의 창이다. wnd[0]만 캡처하면 뒤에 깔린 화면만 남는다.

SAP 노트

제안에서 항목이 빠지는 자리

가상의 거래처 100100으로 본 네 갈래

• 지급보류

  • 항목의 지급보류 키(ZLSPR)
  • 거래처 마스터의 지급보류

• 지급 방법과 은행

  • 파라미터에 없는 지급 방법
  • 맞는 거래처 은행 정보가 없음

• 만기와 입력일

  • 다음 지급일 전에 만기가 오지 않으면 다음 실행으로
  • Docs entered up to는 입력일 CPUDT로 거른다

• 묶음과 잔액

  • 통화, 지급 방법, BVTYP, HBKID 같은 값이 같아야 한 지급
  • 대변메모만 남은 묶음은 차변 잔액이라 예외

가상의 예입니다. 거래처 번호와 값은 지어낸 것이며 실제 지급 기록이 아닙니다.

F110은 미결 항목을 고른 뒤 지급으로 묶고, 지급 방법과 은행을 정한다. 항목이 지급되지 않는 자리는 대개 네 갈래다.

• 지급보류. 항목의 지급보류 키나 거래처 마스터의 지급보류가 있으면 지급되지 않고, 제안의 예외 목록이나 로그에 남는다.
• 지급 방법과 은행 정보. 파라미터에 넣은 지급 방법이 항목이나 거래처 마스터의 지급 방법과 맞지 않거나, 그 지급 방법에 필요한 거래처 은행 정보가 없으면 항목은 지급 방법을 받지 못한다.
• 만기와 입력일. 다음 지급일 전에 만기가 오지 않는 항목은 다음 실행으로 넘어간다. 파라미터의 Docs entered up to는 전기일이 아니라 입력일(CPUDT)로 거른다. 송장 참조(REBZG)가 없는 대변메모는 지급조건과 상관없이 기준일에 만기가 된다.
• 묶음과 잔액. 통화, 지급 방법, 파트너은행유형(BVTYP), 주거래은행(HBKID) 같은 값이 같은 항목끼리 한 지급이 된다. 거래처 마스터에 그룹핑 키가 있으면 그 키가 가리키는 필드도 묶음을 가른다. 거래처 마스터에 개별 지급(Pay all items separately)이 켜져 있으면 항목마다 따로 지급된다. 대변메모만 따로 묶이면 그 묶음은 차변 잔액이라 지급할 수 없고 예외로 남는다.

가상의 예에서 원인이 묶음이라고 해 보자. 대변메모에만 BVTYP 0002가 있고 송장 세 건은 비어 있다. 그러면 송장 셋은 한 지급이 되고, 대변메모는 따로 묶여 차변 잔액으로 남는다. 담당자가 말한 증상과 같은 모양이다.

원인을 확인할 때는 F110의 추가 로그(Additional Log) 탭에서 만기 확인과 지급 방법 선택 로그를 켜고, 그 탭의 로그 대상 거래처 범위와 파라미터의 거래처 범위에 그 거래처만 넣어 제안을 돌린다. 항목이 빠진 이유가 로그에 남는다. 제안은 전표를 만들지 않지만 잡을 돌리는 일이라, 운영에서 돌릴지는 사람이 정한다. 에이전트는 QA에서 돌린다.

입력일도 본다. 입력일은 입력한 사람의 현지 날짜가 아니라 애플리케이션 서버의 날짜로 찍힌다. 예를 들어 서버 시간대가 입력자보다 8시간 앞서 있으면, 입력자 현지 16:00부터 입력한 전표는 서버 날짜로 다음 날이 된다. 현지 날짜를 Docs entered up to에 넣고 당일 지급을 돌리면 그 전표는 빠진다.

첫 답이 틀리기 쉬운 자리

조회 데이터만 보고 쓴 첫 답은 원인을 맞혀도 절차에서 틀리기 쉽다. 가상의 예라면 이런 답이 나올 수 있다.

1. “FB02로 대변메모의 BVTYP를 지우면 된다.” 그 칸이 FB02 화면에서 열리지 않을 수 있다. 항목의 필드 상태는 전기키와 조정계정의 필드 상태 그룹이 함께 정하고, 전기 뒤에 바꿀 수 있는 필드는 전표 변경 규칙이 정한다. 사람이 따라 할 절차라면 그 칸이 정말 열리는지 화면에서 먼저 본다.
2. “QA에는 같은 데이터가 없다.” ABAP SQL은 기본으로 로그온한 클라이언트의 데이터만 읽는다. ADT 프로젝트가 다른 클라이언트에 로그온해 있으면 데이터가 없어 보인다. 로그온 클라이언트를 확인하고, 필요하면 USING CLIENT로 클라이언트를 지정한다.
3. “반제하고 남은 잔여 항목에서 값을 맞추면 된다.” 잔여 항목은 새 항목이다. 전기키, 은행 필드, 지급보류가 원 항목과 같다고 가정하지 않는다. 새 항목에 어떤 값이 들어가는지는 시스템 설정에 따라 다르다. 새 항목을 FB03으로 열어 확인한다.

답을 여러 번 검토하더라도, 조회한 데이터만으로 낸 결론은 추론이다. 원인을 맞히는 일과 따라 할 절차를 맞히는 일은 다르고, 뒤의 것은 화면을 열어 봐야 안다.

QA 클라이언트에서 하나씩 확인한다

SAP 노트

QA 클라이언트에서 하나씩 확인한다

계획의 예시, 쓰기는 미리 정한 QA 클라이언트만

1. 01

   재현

   • 운영과 같은 모양의 테스트 전표
   • 그 거래처만 제안하고 예외 목록과 로그 확인
2. 02

   하나만 바꾸기

   • BVTYP만 다른 쌍, 지급 방법만 다른 쌍
   • 예상을 먼저 적고 제안 결과와 비교
3. 03

   조치 확인

   • 사람이 따라 할 순서대로 화면에서
   • 새 잔여 항목은 FB03으로 다시 연다
4. 04

   실행은 사람

   • 지급 실행은 QA에서도 전표를 만든다
   • 지급매체를 만들지도 사람이 정한다

계획의 예시입니다. 실제 시스템에서 돌린 결과가 아닙니다.

쓰기부터는 막을 곳이 필요하다. 아래의 GetSession은 앞의 나열 코드로 직접 만드는 헬퍼다. 정한 시스템과 클라이언트의 세션만 잡고, 맞는 세션이 없으면 WScript.Quit 1로 그 자리에서 끝나게 쓴다. 작업을 시작할 때와 저장 직전에는 Guard로 시스템과 클라이언트를 한 번 더 본다. 아래 Guard에는 구멍이 있고, 뒤에서 다시 다룬다. 시스템 이름과 클라이언트 번호는 가상 값이다.

Const QA_SID = "TST"
Const QA_CLIENT = "400"
Set session = GetSession(QA_SID, QA_CLIENT)

Sub Guard()
  If session.Info.SystemName <> QA_SID _
    Or session.Info.Client <> QA_CLIENT Then
    Err.Raise vbObjectError + 9, "Guard", "not QA"
  End If
End Sub

QA에서 확인하는 순서는 이렇게 잡는다. 아래는 계획의 예시이고, 실제 시스템에서 돌린 결과가 아니다.

1. 증상을 재현한다. QA 클라이언트에 운영과 같은 모양의 테스트 전표를 만든다. 송장 세 건은 BVTYP를 비우고, 대변메모에만 0002를 넣는다. 그 거래처만 넣고 제안을 돌려, 대변메모가 따로 묶여 예외로 남는지 본다. 근거는 제안 목록, 예외 목록, 추가 로그다.

제안 목록이나 로그를 파일로 저장하려 하면 SAP GUI 보안 창이 뜰 수 있다. 파일 쓰기를 허용할지 묻는 창이라 에이전트가 대신 누르지 않는다. 스크립트는 거기서 멈추고, 사람이 이유를 듣고 정한다.

2. 한 번에 하나만 바꾼다. 의심되는 값이 둘 이상이면 하나씩 떼어 본다. BVTYP만 다른 전표 쌍과 지급 방법만 다른 쌍을 따로 두고 제안을 다시 돌리면, 각 값이 혼자서도 묶음을 가르는지 볼 수 있다. 예상을 먼저 적어 두면 추측과 관찰이 섞이지 않는다.

3. 조치를 확인한다. 조치 후보가 FB02 변경이든 F-44 반제든, 사람이 따라 할 순서대로 화면에서 해 본다. 반제로 잔여 항목을 만들었다면 그 항목을 FB03으로 다시 열어 전기키, 은행 필드, 지급보류를 본 뒤 제안을 다시 돌린다.

4. 지급 실행은 사람이 정한다. QA라도 지급 실행은 지급전표를 만들고 항목을 반제한다. 지급 실행과 은행 파일·출력물 같은 지급매체는 사람이 정한다. 스크립트는 일정 팝업에 예상 밖의 선택지가 보이면 취소한다.

조건이 오류 나면 Then으로 들어간다

SAP 노트

조건이 오류 나면 Then으로 들어간다

VBScript의 And와 On Error Resume Next

• 한 줄로 쓴 조건

  Type = checkbox And Selected

  • And는 양쪽을 모두 평가한다
  • 체크박스가 아니어도 Selected를 읽는다

• 오류 뒤의 If

  • 조건 오류가 나면 Then이 실행된다
  • Then이 진행이면 검사를 그대로 지나간다

• 호출부의 Resume Next

  • Guard의 Err.Raise는 호출부로 올라간다
  • 호출부가 무시하면 다음 줄인 저장이 실행된다

• 다시 쓴 가드

  • 가드 안에서 판정하고 WScript.Quit
  • 세션 선택을 첫 방어선으로 둔다

코드는 설명을 위한 예시이며 실제 시스템에서 돌린 기록이 아닙니다.

지급 실행 팝업을 검사하는 조건을 한 줄로 썼다고 하자. 팝업의 자식을 돌며, 체크박스이면서 켜져 있으면 중단하는 조건이다. VBScript의 And는 양쪽을 모두 평가하므로, 체크박스가 아닌 요소에서도 Selected를 읽다 오류가 난다. On Error Resume Next 아래에서 If 조건이 오류 나면, 실행은 Then 안의 다음 문장으로 넘어간다. Then이 취소라면 스크립트가 엉뚱하게 멈추고, Then이 진행이라면 검사를 그대로 지나간다.

그래서 안전 검사는 중첩 If로 쓴다. 위험한 것을 찾으면 중단하는 대신, 예상한 것 외에 하나라도 보이면 중단하는 허용 목록으로 쓴다.

앞의 Guard도 같은 구멍이 있다. 쓰기 스크립트가 On Error Resume Next를 켠 뒤 Guard를 부르면, Guard 안의 Err.Raise는 호출한 쪽으로 올라가 거기서 무시된다. VBScript의 오류 처리 모드는 프로시저 단위라서, 호출부의 다음 줄인 저장이 그대로 실행된다. 이때 남는 방어선은 헬퍼가 세션을 고르는 첫 단계다. 맞는 세션이 없으면 GetSession이 WScript.Quit 1로 끝나므로, 다른 시스템의 세션으로 저장까지 가지는 않는다.

가드는 오류를 던지지 않고 스스로 끝내게 쓴다. 판정이 실패해도 멈추는 쪽으로 떨어진다. 아래는 설명을 위한 예시 코드다.

Sub Guard()
  Dim ok : ok = False
  On Error Resume Next
  ok = (session.Info.SystemName = QA_SID _
    And session.Info.Client = QA_CLIENT)
  On Error GoTo 0
  If ok = True Then Exit Sub
  WScript.Quit 1
End Sub

사람이 지킬 자리와 막히면 먼저 볼 것

사람	에이전트
SAP 로그인	열린 세션 찾기, 화면 조작, 캡처
스크립팅 허용과 알림 설정	DisabledByServer, 읽기 전용 모드 확인
SAP GUI 보안 창에서 허용 여부	막힌 이유 설명 후 대기
QA에서 재현할지 판단	재현 설계, 테스트 전표, 제안, 로그 정리
지급 실행과 지급매체	일정 팝업 검사, 허용 목록 밖이면 취소
담당자에게 회신	원인 분석, 안내 초안, 데이터베이스 대조

사람이 맡는 일은 몇 개 되지 않지만, 모두 되돌리기 어렵거나 책임이 따르는 자리다. QA에서 같은 모양의 데이터를 만들어 확인할지는 사람이 미리 정해 둔다. 에이전트가 QA에 데이터가 없다고 보고하면 그대로 받아들이지 말고 로그온 클라이언트부터 확인한다. 담당자에게 보낼 화면 캡처에서 이름과 계좌를 가리는 일도 사람이 확인한다.

증상	먼저 볼 것
컨트롤을 찾지 못함	떠 있는 알림·확인 창, 바뀐 화면
SE16N 컬럼이 일부만 보임	ColumnOrder, 기본 레이아웃
셀 읽기가 오래 걸림	필요한 컬럼만, 목록은 %pc
스크립트가 끝없이 대기	SAP GUI 보안 창은 사람이 클릭
한글 출력 깨짐	UTF-8 파일로 쓰고 파일을 읽기
조건 오류인데 Then 실행	중첩 If, 허용 목록
Guard가 저장을 막지 못함	가드 안에서 Quit, 세션 선택이 먼저
QA 데이터가 없어 보임	로그온 클라이언트와 USING CLIENT
거래처가 제안에서 빠짐	지급보류, 지급 방법·은행 정보, 만기, 묶음 필드, 추가 로그
당일 입력 전표가 지급에서 빠짐	서버 날짜로 찍힌 입력일 CPUDT

원칙은 네 가지다. 로그인은 사람이 한다. 운영은 조회만 한다. 쓰기 스크립트는 정한 시스템과 클라이언트의 세션만 잡는다. GUI에서 바꾼 값은 데이터베이스로 다시 확인한다. 하나를 더하면, 안전장치도 코드라서 일부러 실패시켜 멈추는지 한 번은 본다.

같은 틀은 업무 매뉴얼을 만들 때도 쓸 수 있다. QA에서 업무 순서를 돌리며 화면과 조작을 문서로 남기는 일도, 사람이 경계를 정하고 에이전트가 화면을 다루는 같은 모양이다.