자동화, 어떻게 해야할까?

• 시작하기 전에 먼저…
  • 자동화로 얻을 손익을 따져보자
  • 어떤 순서로 작업할지 생각해보자
• 자동화해보자
  • 수동 작업 과정을 문서화해보자
  • 자동화에 쓸 기술을 정하자
  • 자동화 발동 조건을 고려하자
  • 수동 작업을 자동화하자
  • 잘 동작하는지 테스트로 확인하자
• 마치며
  • 자동화를 통해 얻은 것

 

개발자는 반복적인 작업을 자동화함으로써 더 중요한 업무에 집중할 수 있다. 토이 프로젝트이던, 회사에서 하는 업무던지 간에, 프로그램을 짜다보면 ‘이거 자동화하면 편할 것 같은데?’ 싶을 때가 종종 있다. 하지만 실제로 자동화하려고 할 때 어떻게 진도를 나갈지 막막한 적이 많았고, 그럴 때마다 ‘이럴 때 도움 될 만한 글이 있었으면 좋겠다’고 생각하곤 했다.

최근 수동 배포 작업을 자동화하면서 여러가지 시행착오를 겪었다. 이 과정에서 알게 된 점이 몇가지 생겼고, 이런 점을 미리 알았다면 더 수월하게 자동화할 수 있지 않았을까 생각이 들었다. 배포 작업 자동화 과정과 함께 자동화를 어떻게 해야할지 처음 고민하던 그때로 돌아갈 수 있다면 나에게 알려주고 싶은 이야기를 글로 정리해봤다.

 

시작하기 전에 먼저…

자동화로 얻을 손익을 따져보자

다른 작업과 마찬가지로 자동화 작업 역시 시간과 노력이 들어가는 작업이다. 만약 작업에 들이는 시간에 비해 자동화했을 때 얻을 이익이 크지 않다면 차라리 자동화하지 않는 게 나을수도 있다.

어쩌면 자동화하지 않는 게 나을지도 모른다1

 

배포 작업도 자동화에 시간이 많이 들어가는 작업이었다. 그런데도 자동화하기로 결정했던 몇 가지 이유가 있었다.

• 작업 빈도가 높았다. 기능을 구현하거나 버그를 고치려고 소스 코드를 변경하면 서버에 배포해서 변경 사항을 반영해야 했기 때문이다.
• 작업 시간이 오래 걸렸다. 작업 중 입력해야 할 명령이 길었고, 반복적으로 명령을 입력하다가 잘못 입력할 때도 있기 때문이다.
• 프로젝트에 스케일 아웃을 도입하면서 배포 과정에 드는 시간이 두 배로 늘어났고, 덩달아 관리할 민감 정보도 두 배로 늘어났다. 그래서 작업 빈도와 시간 모두 더 늘어났다.

실행 명령을 스크립트로 만들어서 작업 시간을 줄여보려고도 했지만, 오히려 스크립트 관리에 시간이 들어가서 그다지 깔끔한 해결책은 아니었다. 배포 작업을 자동화하면 이런 문제점을 더 깔끔하게 해결할 수 있을 것으로 생각되어 자동화하기로 결정했다.

 

어떤 순서로 작업할지 생각해보자

자동화하려면 뭐부터 해야할까? 처음 작업을 시작할 때, 모르는 건 많고 해야 할 건 많아보여서 뭐부터 해야할지 정하기가 어려웠다. 일단 생각나는 것부터 뭐라도 만들어보자니 무슨 기술을 쓸지도 정해지지 않았고, 뭐부터 만들어야할지 결정하기도 힘들었다. 기술 문서부터 읽어보자니 그 양과 깊이에 지쳐버렸다. 이런 고민을 해결할 힌트를 예전에 읽었던 책에서 얻었다.

<시스템 관리자를 위한 시간관리 전략> 2

 

<시스템 관리자를 위한 시간관리 전략> 에서 저자는 어떤 작업을 자동화할 때 밟아나갈 단계를 제안한다. 간단하게 정리하면, 먼저 수동 작업을 문서화하고, 단계별로 자동화와 테스트를 반복해 점진적으로 구현해나가라고 한다.

책에 나온 내용을 참고해서 해야 할 작업을 계획했다. 책에서 제시하는 작업 순서에 맞춰 작업할수도 있겠지만, 나는 꼭 그대로 따라할 필요는 없다고 생각한다. 우선 어렵지 않게 해볼 수 있는 단계를 적용하고, 나머지 단계는 나중에라도 필요해지면 적용했다. 또 필요하면 다른 작업을 추가하거나 작업 순서를 바꾸기도 했다. 작업은 이런 순서로 진행되었다.

1. 수동으로 작업하는 각 단계를 문서화한다
2. 자동화에 쓸 기술을 정한다
3. 자동화 발동 조건을 정한다
4. 각 단계를 자동화한다
5. 자동화한 코드가 올바른지 테스트한다

 

 

자동화해보자

작업마다 자세히 알아보자.

 

수동 작업 과정을 문서화해보자

우선 수동으로 배포 작업하는 과정을 문서로 정리했다. ‘자주 해서 이미 잘 아는데 굳이 문서로 정리할 필요가 있을까?’ 하는 생각이 들 수 있다(내가 그랬다). 하지만 손에 익은 작업이더라도 문서로 만들면서 생각이 정리되었고, 미처 몰랐던 부분도 알게 되었다.

정리해보니 나는 수동 배포 작업을 이렇게 하고 있었다.

1. 로컬 머신에서 빌드 도구로 소스 코드를 빌드해 jar 파일(이하 아티팩트)을 만든다
2. ftp 앱으로 원격 서버에 접속해서 로컬 머신에 있는 아티팩트를 원격 서버로 전송한다
3. 로컬 머신에서 ssh로 원격 서버에 접속 후 애플리케이션을 실행한다

 

자동화에 쓸 기술을 정하자

어떤 기술을 써서 자동화해야할까? 작업을 자동화하는 데 쓸 수 있는 기술에 다양한 선택지가 있을 수 있다. 배포 작업을 자동화하는 데 쓸 수 있는 기술도 여러가지였다.

어떤 기술을 써야할까? 3

 

다양한 기술 중 구현에 쓸 것을 결정할 때, 나는 구현에 드는 시간을 절약해줄만한 점을 기준으로 삼았다.

• 자동화하려는 작업에 프로젝트에서 이미 쓰고 있는 기술을 적용할 수 있는가?
• 자동화해야 하는 작업을 직접 구현하지 않고도 플러그인 형식으로 가져다 쓸 수 있도록 제공되는 경우가 있는가?

이런 점을 고려해 깃헙 액션을 이용하기로 결정했다. 프로젝트에서 이 기술을 이미 쓰고 있었고, 미리 구현된 플러그인(액션)을 제공해 작업을 자동화할 때 활용할 수 있을 것으로 기대했다.

 

자동화 발동 조건을 고려하자

작업을 언제 자동으로 실행해야할까? 책 <실용주의 자동화>⁴에서는 자동화의 발동 조건을 다음 세 가지로 분류한다.

• 명령 입력 시 실행하거나
• 특정 시간마다 실행하거나
• 어떤 이벤트 발생 시점에 실행하거나

프로젝트 상황을 생각했을 때 어떤 조건을 골랐을 때 가장 생산적일지를 고민해봤다. 프로젝트는 PR 단위로 기능을 구현하고 있었고, 기능 구현 완료 시점에 배포 작업이 실행되도록 하는 게 가장 효율적이라고 판단했다. 따라서 PR를 메인 브랜치에 병합하는 (이벤트가 발생하는) 시점에 배포 작업을 자동으로 실행하기로 했다.

 

수동 작업을 자동화하자

다음으로 문서화한 단계를 자동화했다.

먼저 기술(깃헙 액션)을 어떻게 써야할지 익혔다. 이때 블로그나 깃허브, 기술 문서의 튜토리얼에서 소스 코드를 가져와 실행할 수 있는 환경을 만들어 피드백을 재빨리 얻을 수 있도록⁵ 하고, 내 프로젝트에 맞게 바꿔나가면서 모르는 부분이 나오면 공식 문서를 참고했다.

깃헙 액션을 적용하면 기존 배포 과정은 다음과 같이 달라지게 된다.

1. 로컬 머신은 수정한 소스 코드를 깃허브에 push⁶한다
2. 깃헙액션 서버는 로컬 머신이 깃허브에 push한 최신 커밋의 소스 코드를 받아온다
3. 깃헙액션 서버는 빌드 도구로 소스 코드를 빌드해 아티팩트를 만든다
4. 깃헙액션 서버는 ftp 앱으로 원격 서버에 접속해서 아티팩트를 원격 서버로 전송한다
5. 깃헙액션 서버는 ssh로 원격 서버에 접속 후 애플리케이션을 실행한다

기존에는 로컬 머신이 모든 작업을 담당했지만, 깃헙액션 서버가 이 역할을 담당하도록 바뀌었다. 위 다이어그램의 점선 내 영역을 보면 로컬 머신만 깃헙액션 서버로 바뀌었을 뿐 수동 작업 과정과 동일하다는 것을 확인할 수 있다. 이제 로컬 머신은 변경한 소스 코드를 원격 저장소에 푸시해서 배포 발동 조건을 만드는 역할만 하도록 바뀌었다.

이 단계에 맞게 배포 작업의 각 단계를 자동화했다. 이때 쓸 수 있는 플러그인이 있다면 활용하고, 없을 경우 셸 스크립트를 구현해서 깃헙액션 스크립트에 넣었다.

 

잘 동작하는지 테스트로 확인하자

구현한 코드가 잘 동작하는지 확인하려면 테스트가 필요하다. 나는 배포 자동화를 테스트할 테스트용 브랜치를 만들어 테스트했다. 소스 코드를 원격 저장소에 push했을 때 자동 배포 작업이 실행되도록 한 뒤, 예상한 동작을 하는지 확인하고, 문제가 있으면 코드를 바꿔 다시 테스트했다.

 

나는 모든 단계에 대한 자동화 코드를 전부 짠 상태에서 테스트를 시작했는데, 이러면 문제의 원인이 되는 곳을 찾기가 어려워서 테스트하기가 번거로웠다. 확인하려는 단계만 남기고 주석처리해서 번거로움을 완화할 순 있었지만, 가능하다면 단계별로 구현하고 바로 테스트하는 편이 나은 것 같다.

테스트할 때 피드백 주기가 짧은 것이 유리하다. 피드백 주기가 길면 테스트 횟수가 많아질수록 구현까지 드는 시간도 그만큼 늘어나기 때문이다. 배포 작업을 실행할 조건은 PR을 메인 브랜치로 머지했을 때였지만, 이 조건에선 테스트 결과를 한 번 확인하는 데 시간이 너무 오래 걸렸다. 대신 테스트할 때만 배포 작업 실행 조건을 원격 저장소에 push하는 것으로 바꿔서 피드백 주기를 짧게 했다.

 

 

마치며

자동화를 통해 얻은 것

• 배포 자동화로 배포 작업에 소모되는 시간을 다른 더 중요한 작업에 사용할 수 있게 되었다.
• 실수할 가능성이나 작업 빈도에 구애받지 않고 배포할 수 있게 되었다. 새 작업 내용을 빠른 시간 내에 테스트해본다거나 다른 팀원과 공유하는 등의 작업이 용이해졌다.
• 스케일 아웃 등 프로젝트 인프라가 확장되더라도 배포 작업에 드는 시간이 늘어나지 않게 되었다.⁷

 

---