RPA, 바이브코딩 실습이 업무 자동화에 그대로 통하지 않는 이유

바이브코딩 실습과 실제 업무 자동화는 무엇이 다른가?

RPA를 바이브코딩 실습으로 직접 만들어 쓰는 것과 업무 자동화는 끝나는 지점이 다르다. 실습은 코드가 화면에서 동작하는 순간이 끝이고, 업무 자동화는 그 결과를 다른 사람이 매일 확인하고 쓰는 순간부터가 시작이다.

바이브코딩 실습은 원하는 동작을 문장으로 쓰고 AI가 만든 코드를 실행해 보는 것까지가 범위다. 입력은 자신이 직접 치고 출력도 자신이 눈으로 확인하므로, 실습 중에는 '이상한 입력'이 들어올 일이 없다.

업무 자동화는 입력이 다른 사람이 만든 파일이나 화면에서 온다. 입력을 만드는 사람과 자동화를 쓰는 사람이 달라지면, 실습 때는 없던 예외가 자동화의 경계가 된다.

실습에서 돌아가던 코드는 업무에서 어디서 막히나?

막히는 지점은 대개 자동화 도구가 아니라 입력을 받아들이는 규칙이다. 실습 데이터는 깨끗하지만 업무 데이터는 형식이 제각각이라, 이를 전제하지 않은 코드는 예외가 나오는 순간 멈춘다.

업무 데이터에는 셀 병합, 빈 값, 표기 방식이 다른 날짜와 전화번호가 섞여 있다. 코드는 이런 값을 만나면 어떤 값이 정답인지 판단해야 하는데, 그 기준이 어디에도 없으면 판단을 사람에게 돌려준다.

판단이 돌아오는 일이 반복되면 자동화는 코드에 사람의 예외 처리가 덧붙은 구조가 된다. 이 구조는 실습에서 보지 못한 것이어서, 만들 때 기대한 것과 실제 운영이 다르게 느껴지는 지점이다.

업무 자동화에 적용하려면 무엇부터 고정해야 하나?

적용하려면 코드를 짜기 전에 입력 규칙, 출력 규칙, 예외 규칙을 문서로 고정해야 한다. SGK 스튜디오 구축 표준도 자동화할 규칙을 먼저 확정한 뒤에 도구와 구조를 정하도록 되어 있다.

입력 규칙은 어떤 항목을 어떤 형식으로 받을지, 출력 규칙은 결과를 어디에 어떤 모습으로 낼지, 예외 규칙은 기준에 맞지 않는 입력을 어떻게 처리할지다. 이 세 가지가 고정되면 코드는 그 규칙을 실행하는 일만 남는다.

규칙이 고정된 반복 작업이라면 실습에서 만든 코드를 검증 수단으로 쓸 수 있다. 규칙이 고정되지 않은 작업이라면 코드를 아무리 고쳐도 운영하는 사람의 판단이 매번 필요하다.

규칙이 이미 문서로 존재하는 업무일수록 자동화 후보로 검토하기 쉽다. 반대로 규칙이 사람 머릿속에만 있는 업무는 코드보다 규칙 정리가 먼저다.

바이브코딩은 RPA 자동화에서 어느 위치를 맡을 수 있나?

바이브코딩은 자동화를 만드는 수단 중 하나로, 자동화 대상과 운영 구조를 정하는 일은 대체하지 않는다. 규칙이 고정된 일이라면 프로토타입을 만들어 검증하는 데 쓸 수 있고, 규칙이 잡히지 않은 일이라면 코드보다 먼저 기준을 정하는 작업이 남는다.

자동화에서 먼저 결정되는 것은 도구가 아니라 범위다. 어떤 업무를, 어디까지, 어떤 기준으로 자동화할지가 정해지면, 그다음에 그것을 코드로 옮길지 상용 도구를 쓸지가 정해진다.

실습에서 생기기 쉬운 착각은 코드가 만들어지면 자동화가 된다고 보는 것이다. 실제로는 코드를 운영하고 검증할 주체가 남아 있어야 자동화로 완성된다.