플로우차트와 시퀀스

RPA 솔루션을 쓰면 플로우차트, 시퀀스 모두를 지원하거나 혹은 하나만 지원하는 경우를 볼 수 있다.

이번 포스트에서는 플로우차트, 시퀀스의 장단점을 한번 정리해볼까 한다.

 

다음과 같은 프로세스를 상정하자. [각 알파벳은 시퀀스 집합]

a -> if a has error : a | else : b -> if b has error : b | else : c -> if Return of c is nothing : a | else : d

- a를 실행한다

- a에 에러가 있다면 a를 실행한다

- a에 에러가 없다면 b를 실행한다

- b에 에러가 있다면 b를 실행한다

- b에 에러가 없었다면 c를 실행한다

- c의 Return이 없다면 a를 실행한다

- c의 Return이 있다면 d를 실행한다

 

 

1. 시퀀스

직관적이다. 처음부터 눈에 보이는 순서대로 실행된다.

특별한 고려없이 처음부터 그대로 읽으면 돼서 가독성이 좋다.

유닛테스트 하기도 편하다.

다만 특정 컨디션에서 아래의 코드에서 다시 위의 코드로 돌아가야 할 때 소스가 복잡해진다.

Try Catch 혹은 for each 같은 컨디션으로 구현은 할 수 있다. (다만 어색하다)

a

if a has error:

  a

else:

 b

 if b has error:

  b

 else:

  c

  if c() is nothing:

   a

  else:

   d

이렇게 되면 스텝이 늘어날 수록 중복코드를 쓰거나 재시도 횟수만큼 매번 같은 모듈을 그 순서에 다시 소환해야 한다.

그렇지 않기 위해서 for each - try catch 조합을 쓴다.

for each enumerable.range(1, 3)

 try

  비지니스 로직

 catch

  if idx = 2:

   throw

  else :

   프로세스 초기화

end for each

아이러니하게도 이렇게 묶을수록 시퀀스의 장점은 사라지고 프로세스 초기화 기준으로 모든 시퀀스가 모이게 된다.

그래야 논리적인 결합을 통해 에러 시 재시도가 가능하기 때문이다.

즉, 복잡하고 길어질수록 시퀀스로만 처리하기엔 가독성이 떨어진다.

웬만한 쉬운 과제들은 시퀀스로 처리해도 무리가 없다.

특히 대부분은 시스템을 한번 방문하면 되도록 다시 방문하지 않도록 짤 거기 때문에

초기화점이 흩어지지 않기 때문이다.

 

2. 플로우 차트

플로우차트는 양날의 검이다.

잘못짜면 소스가 아니라 미로다.

그루핑된 테스트는 잘 된다. start node만 잘 옮겨두면 되기 때문이다.

잘 짜면 스텝 컨트롤이 굉장히 용이해진다.

그냥 화살표만 갖다 놓으면 되기 때문이다.

대표적인 예시가 REFramework다

이거 시퀀스로 짤려면 일단 각 State Machine을 모듈화 시켜야 정리가 될 거 같다.

Process 단에서 위의 프로세스 개발에 Flowchart를 활용한다면 아래의 느낌이다.

시퀀스는 그림을 잘 그려야 한다.

여기서 여러 시퀀스에 대해 array를 반복해야 한다면 True일 때 그 Array를 위로 밀어가면서 쓸 수 있다.

리스트 올려가면서 쓰는 예

이렇게 하면 각각 의미단위로 나눠진 시퀀스라 할지라도 가독성을 최대한 직관적으로 살리면서

각 스텝별 오류처리를 다르게 하기도 쉽다.

[ex. 1스텝은 안 되면 재시도, 2스텝은 재시도 하면 안 됨, 3스텝은 에러나면 1스텝부터 재시도]

 

 

 

3. 결론

사실 플로우차트에 대한 협의나 이해가 잘 이뤄지지 않기 때문에,

무조건 시퀀스를 초기화 시스템 기준으로 모듈화해서 개발하시는 분도 많다.

이것도 결국 장단점이 있지만 RPA 솔루션의 특성상 다른 과제에 재사용할 게 아닌 소스까지

모듈화를 너무 많이 하는 것을 권하지 않는다.

각 모듈 파일을 만날 때마다 다시 로드하기 때문에 눈에 띄게 느려지기 때문이다. ^[각주:1]

요컨대 둘 중 하나만 쓸 수는 없고, 프로세스 특성에 맞춰 쓰기를 권한다. [생산성이 좋은 방향으로]

이런 관점이 생기면 프로세스를 정리하고 컨설팅할 때도,

이 스텝에서 틀어도 되는지 아닌지, 재시도 해도 되는지 같은 것까지 수집하게 된다.

1. 이런 이유로 퍼포먼스가 필요한 몇몇 과제들은 프레임워크를 쓰지 않고 개발한다. 트랜잭션 받으러 왔다갔다 하는 게 한 싸이클만큼 길어버리기 때문이다. [본문으로]