CODEF 서비스에서 관리하는 API 서비스 명세서 정보가 변경되었는데, 이를 인지하지 못해 문제가 발생했다. 긴급하게 수정하여 문제를 해결했지만, 사람이 하는 일이기 때문에 언젠가는 또 발생할 수 있는 일이었다. 중요한 문제였기 때문에 해결책이 필요했다. 그래서 나는 수많은 명세서의 변경을 확인하여 결과를 알려주는 크롤러를 만들었다.
고통
현재 필자가 속한 CODEF에서 서비스 중인 데이터 중계 API는 엔진을 관리하는 팀과 협업으로 개발&운영되고 있다. 그리고 이 두 팀 간의 소통은 매우 중요하다. 대표적으로 서비스 명세서가 있다. 근데 이 서비스 명세서의 변경을 인지하지 못해 API에 문제가 발생했다.
문제가 발생한 날 우리가 문제를 인지하게 된 건 고객사에서 급하게 전화를 했기 때문이다. 고객사에서 사용 중인 API 모듈이 지속해서 에러를 발생시키고 있었다. 마침 팀 내에서 관리 중인 API 상태관리 스케줄러도 API에 문제가 있음을 알려주었다. 최악이었다.
긴급하게 로그를 살펴보았다. 고객사가 요청한 파라미터 값은 우리가 기대한 정상적인 값이었다. 하지만 대상 기관에서는 원하는 데이터 값을 주지 않았다. 이상함을 느끼고 해당 API의 서비스 명세서를 확인해보았다. 이때 필수 파라미터값이 변경되었다는 내용을 확인할 수 있었다.
문제를 인지하고 신속하게 개선하여 긴급 반영을 통해 문제를 해결할 수 있었지만, 이런 일이 발생한 것에 대한 근본적인 문제를 해결할 일이 남아있었다.
예방
회사에서 관리하는 API 서비스 명세서의 수는 대략 50개 가까이 된다. 그리고 각 명세서 파일의 첫 번째 시트에 명세서의 변경된 내용을 로그로 남긴다.
변경된 내용은 우리 팀에게 매우 중요하다. 어떤 건 API 서버에 직접적인 문제를 일으킬 수 있을 정도로 크리티컬할 수 있다. 그래서 항상 명세서 정보의 변경을 인지하고 있어야 한다. 그리고 인지하고 있을 때 이전의 고통을 예방할 수 있다.
매일 변경을 확인하기 위해 할 수 있는 일은 2가지가 있다.
- 변경된 내용을 실시간으로 소통한다.
- 매일 특정 시간마다 명세서들을 다운받아 이전 버전과 비교한다.
말은 참 간단하다. 하지만 이 방법은 현실적으로 문제가 있다.
변경된 내용을 실시간으로 소통한다.사람은 실수할 수 있고, 실제로 문제가 발생했다.매일 특정 시간마다 파일들을 다운받아 이전 버전과 비교한다.한번 할 때마다 1~2시간 정도 소요될 수 있는 업무다. 오전, 오후 두 번 한다고 하면 그건 꽤 큰 리소스 낭비다. (그리고 누가 이걸 하고 싶겠나)
현실적으로 어려움이 있는 이 문제를 해결하기 위해 일차적으로 협업팀에서 업무 내용을 메일을 통해 전달해주기로 했다. 근데 메일의 양이 매우 많고, 다른 업무도 많은 상황에서 메일을 꼼꼼하게 확인하는데 어려움이 있었다. 정리된 내용이 필요했다.
우리는 로그가 변경된 것을 파악하고, 우리에게 필요한 부분에 대해서만 대응하는게 깔끔했다. 명세서를 비교하는게 제일 좋은 방법이였다. 그래서 나는 개발자답게 하기 싫은 업무를 컴퓨터에 할당하기로 했다. ‘매일 오전, 오후 두 번 모든 명세서를 비교해서 우리에게 변경사항을 알려줘’라고 말이다.
기대효과
컴퓨터가 이 업무를 대신했을 때 기대효과는 이러하다.
- 우리가 업무를 잊고있어도 컴퓨터는 문제가 발생하지 않는 이상 잊어버리지 않는다.
- 문제가 발생해도 문제가 발생했다고 알려준다.
- 사람이 1~2시간이라는 시간이 필요할 때, 컴퓨터는 1분 안에 해결할 수 있다.
- 정말 귀찮고 하기 싫은 일을 군말 없이 한다.
- 팀원 모두는 더 생산적인 일에 집중할 수 있다.
필요한 프로세스
명세서가 존재하는 페이지에 접근하려면 먼저 로그인을 해야 한다.
<로그인 페이지>
그리고 서비스 명세서를 우클릭해서 다운로드한다.
<명세서 다운로드>
이렇게 간단하다. 로그인하고 다운로드하면 끝이다. 그리고 다운로드한 디렉토리는 zip 파일로 다운로드되고 이를 풀어주면 아래와 같다.
<명세서 다운로드 결과>
그리고 명세서 내용은 대략 아래와 같이 구성되어 있다. 앞에서도 언급했듯이 이런 파일이 50개 가까이 되고 데이터가 많은 파일도 있다.
<명세서 내용 예시>
이 데이터의 수정, 삭제, 추가된 것을 파악하면 된다.
그리고 이 파악된 정보는 현재 팀 내에서 사용 중인 슬랙으로 전송해주면 된다.
<슬랙에 결과 전송>
이렇게 내용을 전송하고 다음 비교 때 사용하기 위해 현재 받은 파일을 백업하면 마무리된다.
간단하게 정리하면 아래와 같다.
- 페이지 로그인
- 서비스 명세서 디렉토리 다운로드
- 다운로드된 zip 파일 풀기
- 파일 비교하기
- 비교 결과 슬랙으로 전송
사용할 기술을 정하자
파이썬
파이썬은 생산성이 좋고 라이브러리가 매우 훌륭하여 자주 사용하는 프로그래밍 언어다. 특히 높은 생산성과 예쁜 코드 때문에 개인적으로 좋아하는 언어이기도 하다.
앞에서 언급한 프로세스를 자동화하는 프로그램을 만드는데 파이썬이 적합하다고 생각했다. 이유는 아래와 같다.
- 생산성이 좋다.
- 크롤링할 때 selenium과 BeautifulSoup를 같이 사용하면 크롤링한 데이터를 핸들링하기 쉽다.
- 엑셀을 다룰 때 openpyxl이나, pandas 같은 라이브러리로 엑셀 데이터를 쉽게 다룰 수 있다.
- 언급한 라이브러리들의 레퍼런스가 많다.
Selenium
파이썬을 사용하여 크롤링 기술을 공부할 때 처음으로 접하는 라이브러리는 requests일 것이다. 하지만 requests는 자바스크립트를 동작시킬 수 없고, 이런 이유로 동적 렌더링 페이지의 데이터를 가져오는 데 어려움이 있다.
내가 크롤링하려는 대상 페이지는 동적 렌더링 페이지였고, 이를 크롤링하기 위해서 webdriver를 사용해야 한다. 그리고 Selenium 라이브러리가 webdriver를 사용하는 데 유용하기 때문에 선택했다.
pandas
판다스는 데이터와 관련된 분야에서 많이 사용되는 라이브러리이다. csv, xlsx 파일들을 다룰 때도 유용하다. 데이터를 비교하는 데 유용하다고 판단하여 사용했다.
slacker
팀 내에서 협업 툴로 슬랙을 사용하고 있다. 팀 내 채팅방으로 메시지를 전송하기 위해선 slacker를 사용해야 한다.
구현 코드
아쉽게도 현재 필자가 구현한 크롤러 코드를 공유할 수 없다. 사내 드라이브 서버는 비공개 서버이기 때문이다. 대신 깃허브를 가지고 예제를 공유할 것이다. 예제도 앞서 언급한 프로세스와 비슷하게 만들 것이다.
- 깃허브 로그인 후 필자의 더미 데이터 레파지토리로 이동.
- 더미 데이터 다운로드
- zip 파일 풀기
- 더미 데이터 비교
- 파일 비교한 결과 슬랙으로 전송
예제 코드는 다음 포스팅부터 작성하겠다.