예전에 구축해 놓은 시스템은 shell과 perl, jar로 구성되어 있다. 누구나 접근하기 쉽기도 하지만 사용해야 하는 다른 시스템도 대부분 shell과 perl로 되어 있었기 때문에 빠른 시간안에 구축하기 위해 선택한 방안이었다.
문제는 script 들로 구성되어 있다보니 재사용성이 낮았고 여기저기 파편화되어 구축 이후의 관리에 애를 먹게 되었는데 이번에 전체적으로 개선할 수 있는 기회가 만들어져서 이전의 문제들을 줄일 수 있는 방법들을 고민하게 되었다.
재사용성이 떨어지는 script 들을 가능한 줄이되 script를 이용하는게 더 효율적인 부분은 groovy를 사용해보기로 마음을 먹게 되었는데 깊은 부분을 몰라서 그런 것도 있지만 해결하기 어려운 부분이 생겼다. 임시 방안으로 땜질해 놓긴 했지만.
1. Groovy의 장점
1-1. 구조적인 script
Shell이나 perl과는 다르게 구조적으로 작성 가능하다는게 가장 큰 장점이라고 생각한다. 일단 표면에 내세운 것도 Object Oriented 인데, 실제 클래스 구현과 객체 생성이 가능하다. 재사용성을 높이면서 동시에 지저분해지기 쉬운 script를 간결하게 정리할 수 있다. 물론 본인이 마음을 먹어야 가능한건데, 작성방식에 따라 다른 script처럼 만들 수도 있겠다.
1-2. Java와의 유사성
기본 문법이 Java와 꽤 유사하다. 예약어나 접근 제한의 의미는 약간 다르고 문법적인 규칙의 강도는 Java에 비해서는 약한 편이다. 예를 들어 세미 콜론은 붙여도 되고 안붙여도 무방하며, println의 경우 괄호로 내용을 감싸도 되지만 풀어놔도 괜찮다. return도 마찬가지로 꼭 넣을 필요가 없고, data type을 굳이 명시하지 않고 def로 표현해도 되는데 이 부분은 Javascript와도 닮은 부분이다.
2. 문제가 되는 부분
2-1. Bash command
나의 경우엔 groovy에서 외부 프로세스를 생성해서 호출해야만 하는 상황이 여럿 존재하는데, 그 중에 source command로 메모리에 올려두고 다음 shell script에서 사용해야 하는 경우는 정말 방법이 없어보였다.
2-2. 연속된 command의 호출
연속된 shell script의 호출이나 command의 호출은 && 연산자로 어떻게 해볼 수는 있겠지만 근본적으로 깔끔하게 groovy에서 해결할 수는 없었다. groovy로 그 기능들이나 내용을 다시 구현하지 않는 이상.
3. 해결
결국은 기존의 shell script가 꼭 필요한 경우는 그대로 쓰기로 하고 groovy는 wrapping 하는 정도에서 마무리하게 되었다. Wrapping이야 shell script로 불가능한 것은 아닌데 훨씬 좋아진 점은 가독성이고, shell script가 위에서부터 아래 방향으로 순차적으로 해석되어 실행되는 것에 반해 groovy는 그렇지 않기 때문에 필요한 함수를 script 하단에 정의할 수도 있었기 때문에 훨씬 정리된 script를 만들 수 있었다. 특히 사용 가능한 라이브러리 (예를 들어, json 관련 클래스)가 많아서 짧게 구현하는데 유용했다.