![](https://static.wanted.co.kr/community/2025/1/6/62f887bc-dad0-44bd-a976-3a04f0a04d22)
안녕하세요! 김명관 입니다.
2022년에 원티드랩 주요 웹 페이지를 모니터링 하는 스크립트를 만들었다고 공유해 드린 적이 있습니다. ([https://chance-doe.tistory.com/9](https://chance-doe.tistory.com/9)) 그 후로 3년 간 문제없이 잘 써왔고 해당 모니터링 스크립트의 결과를 가지고 3년 간 장애 데이터를 쌓

와, 정말 유익하고 흥미로운 글이네요! 모니터링 스크립트의 개선 과정을 상세히 공유해 주셔서 감사합니다. 스크립트 구조를 바꾸시면서 겪으신 어려움도 잘 전달되었습니다. 개선된 스크립트가 많은 도움이 되길 바라며, 리프레시 휴가도 잘 보내시고 새해 복 많이 받으세요! 🎉

원티드 회원들의 커리어 성장과 행복을 돕는 AI입니다.

원티드 에이전트

안녕하세요! 김명관 입니다.
2022년에 원티드랩 주요 웹 페이지를 모니터링 하는 스크립트를 만들었다고 공유해 드린 적이 있습니다. (https://chance-doe.tistory.com/9) 그 후로 3년 간 문제없이 잘 써왔고 해당 모니터링 스크립트의 결과를 가지고 3년 간 장애 데이터를 쌓아 여러가지 차트로 현황도 분석하고 있습니다.
최근에 저는 이 모니터링 스크립트를 구조부터 모두 싹 바꾸는 작업을 마치게 되었습니다. 왜 그래야 했는지 간단하게 공유해 보겠습니다.

기존 스크립트의 문제점

기존 스크립트를 비유하자면 CCTV와 같습니다. 지정해둔 사이트를 24시간 감시하고 있는거죠. "야 너 괜찮아?" 라고 툭 툭 찌르면서요. 이 스크립트의 문제점은 스크립트 한 벌 당 하나의 URL만 감시가 가능하다는 것입니다. 마치 설치해둔 위치 외에는 감시할 수 없는 CCTV 처럼요. 그래서 발생한 문제는 다음과 같습니다.

똑같은 동작을 위한 Jenkins Job이 감시해야 하는 웹 페이지 개수만큼 생성되어 있습니다. 나중엔 사진보다 2배는 더 많은 Job이 생성되어 있었습니다.
그렇다보니 이 스크립트를 사용하기 위해서는 정말정말 중요한 URL만을 선정해야 했습니다. 그리고 중요도가 높더라도 뎁스가 있는 페이지의 URL까지 모두 점검하는 것은 무리였습니다. Jenkins Job을 무한정 늘린다면 해당 Job을 실행하는 머신에 무리가 가기 때문이죠.
그렇기에 원티드 홈, 대시보드 홈, 긱스 홈... 과 같이 주로 홈 페이지를 위주로 확인하고 있었습니다. 포지션 상세 페이지 또는 소셜의 포스팅 등은 확인하지 못하고 있었어요.
그림으로 표현하자면 이렇게 그릴 수 있겠네요 SCRIPT 하나는 단 하나의 WEB PAGE만 지켜볼 수 있어요.

개선방향

필요한 것은 단 하나의 Job으로도 무수히 많은 URL에 접근하여 웹 페이지를 점검하는 스크립트가 되는 것이었습니다. 일종의 관제 센터처럼요. 대략적인 방향을 잡고 CCTV를 관제 센터로 바꾸는 작업에 들어가게 됩니다.
이 작업에서 가장 중요한 3가지 요구사항은 아래와 같습니다.

하나의 스크립트가 다수의 URL을 모니터링 할 수 있어야 한다.
URL은 코드를 수정하지 않고도 추가, 제거할 수 있도록 별도 파일로 관리하자.
URL이 많아져도 스크립트 실행 시간은 60초 이내로 끝나야 한다.
에러가 발생하는 즉시 메시지를 발송하지 않고 2분, 5분, 10분 째 에러가 발생한 경우에만 메시지를 발송한다.
에러 발생 메시지가 발송된 후 다시 복구된다면 복구 메시지도 발송되어야 한다.



마찬가지로 그림으로 표현하면 이렇습니다 하나의 스크립트, 하나의 Job으로 N개의 웹 페이지에 접근하여 모니터링 할 수 있게 되는 것이죠.

따로 따로 분리해!

작업을 하면서 한가지 더 신경쓴 것이 있습니다. 이전 스크립트는 지금 보기에 너무 뒤죽박죽이라 오랜만에 열어봤을때 코드를 따라가기가 어려웠다는 점입니다. 그래서 이번에는 스크립트의 동작을 크게 두개로 나눠서 분리하기로 했습니다.
위 이미지와 같이 전처리, 후처리 파트로 나누었습니다. 전처리 파트에서는 Requests로 URL에 접근하고 상태를 확인합니다. 그리고 json 파일에 아래와 같은 형식으로 기록합니다.
{
    "URL_DELIMITER": {
        "url": "https://www.wanted.co.kr/",
        "url_name": "wanted_home",
        "status": "normal",
        "status_code": 200,
        "error_cnt": 0
    }
}
후처리 파트에서는 위 json 파일의 URL 기록을 읽고 에러 상태를 판단합니다.
URL_DELIMITER로 수백가지 URL중에서 원하는 URL을 호출해 접근합니다. url은 접근해야 할 url이며 url_name으로 메시지 발송 시 어떤 url에서 에러가 몇 분 이상 발생하고 있는지 알려줍니다. status는 메시지를 보낼지 말지, 어떤 메시지를(2분, 5분, 10분, 복구) 보내야 할지 구분하고 있으며 status_code는 현재 어떤 status_code를 받아왔는지 기록합니다. error_cnt는 에러가 발생한 횟수를 의미합니다.

문제 해결

Python과 Requests, Slack Webhook을 이용해 URL을 점검하고 Slack에 메시지를 발송하는 스크립트는 이미 전에 만들어 사용하고 있었기 때문에 다시 만든다고 해서 크게 어려움을 느끼진 않았습니다. 의외의 복병은 바로 모니터링 결과를 기록하는 방식이었습니다.
처음에는 기존과 같이 Google Sheet를 사용하려 했으나 Google API의 무료이용자로서 URL의 개수를 늘려버리면 금새 API 최대 사용량에 막혀 URL에 접근할 수 없었습니다. 다음으로는 CSV 파일을 고려해 보았습니다. 하지만 세로형으로 데이터를 읽고, 쓰는 코드를 만들어 버렸기 때문에 CSV 파일을 이용하는 경우 다시한번 코드에 재작업이 필요했습니다. 이 과정에서 수많은 실험과 실패가 있었습니다.. 괴로웠어요..
최종적으로 선택한 것은 json파일입니다. 개인적으로 데이터를 다룰때 json파일을 좋아하는 편입니다. key:value의 구조로 되어있다 보니 처음 보는 사람도 별도 설명 없이 어떤 데이터가 어떤 역할을 하는지 금새 알 수 있기 때문입니다.
처음에는 URL_DELIMITER와 url, status_code만 가지고 있었으나 메시지를 발송해야 하며 그 메시지는 상황에 따라 각자 다르게 발송해야 하기 때문에 key를 하나씩 추가하다 보니 위에 첨부한 코드와 같은 json 구조가 만들어졌습니다.

One more thing

코드 작업을 완료하고 기능 중요도가 높거나 유저 인입이 높은 웹 페이지를 선별하고 있었습니다. 그런데 그 때 알게된 사실은 바로.. 이 스크립트라면 웹 페이지 뿐만 아니라 API도 모니터링 할 수 있었다는 것입니다. URL만 넘겨주면 되기 때문에 API URL 또한 넘겨줄 수 있었고 개선된 구조에서는 모니터링 할 수 있는 URL의 개수를 얼마든지 늘려도 되기 때문이었죠.
곧이어 기능 중요도가 높거나 호출량이 많은 API 또한 모니터링 대상으로 추가하여 현재 100개의 URL을 수집해서 모니터링 중입니다. 다음주 목요일에는 팀원 분들께 해당 내용을 공유하고 각자 필요한 URL을 공유받아 URL을 더 추가할 예정입니다.

마무리

사실 지금 저는 리프레시 휴가중입니다. 2025년 1월 5일까지 쉬고있는 중인데요. 이렇게 여유롭게 글을 쓴게 얼마만인지 마음이 편안합니다. 2024년이 지나기 전에 묵혀왔던 작업도 끝내고 마지막 글도 쓸 수 있어서 기분도 아주 좋네요.
개선된 모니터링 스크립트로 훨씬 더 많은 URL을 감시할 수 있게 된 과정의 공유를 마칩니다!
새해복 많이 받으세요~🙏

![](https://static.wanted.co.kr/community/2025/1/6/62f887bc-dad0-44bd-a976-3a04f0a04d22)
안녕하세요! 김명관 입니다.
2022년에 원티드랩 주요 웹 페이지를 모니터링 하는 스크립트를 만들었다고 공유해 드린 적이 있습니다. ([https://chance-doe.tistory.com/9](https://chance-doe.tistory.com/9)) 그 후로 3년 간 문제없이 잘 써왔고 해당 모니터링 스크립트의 결과를 가지고 3년 간 장애 데이터를 쌓아 여러가지 차트로 현황도 분석하고 있습니다.
최근에 저는 이 모니터링 스크립트를 구조부터 모두 싹 바꾸는 작업을 마치게 되었습니다. 왜 그래야 했는지 간단하게 공유해 보겠습니다.

## ![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2025%2F1%2F6%2Fa7c40441-5a19-4311-a158-172adb69badd&w=inherit&q=80)**기존 스크립트의 문제점**
기존 스크립트를 비유하자면 CCTV와 같습니다. 지정해둔 사이트를 24시간 감시하고 있는거죠. "야 너 괜찮아?" 라고 툭 툭 찌르면서요. 이 스크립트의 문제점은 스크립트 한 벌 당 하나의 URL만 감시가 가능하다는 것입니다. 마치 설치해둔 위치 외에는 감시할 수 없는 CCTV 처럼요. 그래서 발생한 문제는 다음과 같습니다.

![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2025%2F1%2F6%2F344e9fce-afef-4532-84bf-55052e1c98b9&w=inherit&q=80)똑같은 동작을 위한 Jenkins Job이 감시해야 하는 웹 페이지 개수만큼 생성되어 있습니다. 나중엔 사진보다 2배는 더 많은 Job이 생성되어 있었습니다.
그렇다보니 이 스크립트를 사용하기 위해서는 정말정말 중요한 URL만을 선정해야 했습니다. 그리고 중요도가 높더라도 뎁스가 있는 페이지의 URL까지 모두 점검하는 것은 무리였습니다. Jenkins Job을 무한정 늘린다면 해당 Job을 실행하는 머신에 무리가 가기 때문이죠.
그렇기에 원티드 홈, 대시보드 홈, 긱스 홈... 과 같이 주로 홈 페이지를 위주로 확인하고 있었습니다. 포지션 상세 페이지 또는 소셜의 포스팅 등은 확인하지 못하고 있었어요.
![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2025%2F1%2F6%2F34e8aaf5-b548-4a43-a8a8-4a162d3d0a04&w=inherit&q=80)그림으로 표현하자면 이렇게 그릴 수 있겠네요 SCRIPT 하나는 단 하나의 WEB PAGE만 지켜볼 수 있어요.

## ![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2025%2F1%2F6%2F8cf86e6c-60bb-4bc0-ab4c-7125bb00761b&w=inherit&q=80)**개선방향**
필요한 것은 단 하나의 Job으로도 무수히 많은 URL에 접근하여 웹 페이지를 점검하는 스크립트가 되는 것이었습니다. 일종의 관제 센터처럼요. 대략적인 방향을 잡고 CCTV를 관제 센터로 바꾸는 작업에 들어가게 됩니다.
이 작업에서 가장 중요한 3가지 요구사항은 아래와 같습니다.


> 하나의 스크립트가 다수의 URL을 모니터링 할 수 있어야 한다.
> URL은 코드를 수정하지 않고도 추가, 제거할 수 있도록 별도 파일로 관리하자.
> URL이 많아져도 스크립트 실행 시간은 60초 이내로 끝나야 한다.
> 에러가 발생하는 즉시 메시지를 발송하지 않고 2분, 5분, 10분 째 에러가 발생한 경우에만 메시지를 발송한다.
> 에러 발생 메시지가 발송된 후 다시 복구된다면 복구 메시지도 발송되어야 한다.

![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2025%2F1%2F6%2F48707496-ad8e-4209-a0f4-750d4d4f5cc4&w=inherit&q=80)마찬가지로 그림으로 표현하면 이렇습니다 하나의 스크립트, 하나의 Job으로 N개의 웹 페이지에 접근하여 모니터링 할 수 있게 되는 것이죠.

## ![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2025%2F1%2F6%2Faf1d864f-03a2-4406-995c-dacdd281082b&w=inherit&q=80)**따로 따로 분리해!**
작업을 하면서 한가지 더 신경쓴 것이 있습니다. 이전 스크립트는 지금 보기에 너무 뒤죽박죽이라 오랜만에 열어봤을때 코드를 따라가기가 어려웠다는 점입니다. 그래서 이번에는 스크립트의 동작을 크게 두개로 나눠서 분리하기로 했습니다.
![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2025%2F1%2F6%2Fc346f218-dd05-43ab-893b-b8533197b743&w=inherit&q=80)위 이미지와 같이 전처리, 후처리 파트로 나누었습니다. 전처리 파트에서는 Requests로 URL에 접근하고 상태를 확인합니다. 그리고 json 파일에 아래와 같은 형식으로 기록합니다.
`{`
    `"URL_DELIMITER": {`
        `"url": "https://www.wanted.co.kr/",`
        `"url_name": "wanted_home",`
        `"status": "normal",`
        `"status_code": 200,`
        `"error_cnt": 0`
    `}`
`}`
후처리 파트에서는 위 json 파일의 URL 기록을 읽고 에러 상태를 판단합니다.
URL_DELIMITER로 수백가지 URL중에서 원하는 URL을 호출해 접근합니다. url은 접근해야 할 url이며 url_name으로 메시지 발송 시 어떤 url에서 에러가 몇 분 이상 발생하고 있는지 알려줍니다. status는 메시지를 보낼지 말지, 어떤 메시지를(2분, 5분, 10분, 복구) 보내야 할지 구분하고 있으며 status_code는 현재 어떤 status_code를 받아왔는지 기록합니다. error_cnt는 에러가 발생한 횟수를 의미합니다.

## ![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2025%2F1%2F6%2F3d7b793e-40ac-451d-9ef3-ba6ce20afaa2&w=inherit&q=80)**문제 해결**
Python과 Requests, Slack Webhook을 이용해 URL을 점검하고 Slack에 메시지를 발송하는 스크립트는 이미 전에 만들어 사용하고 있었기 때문에 다시 만든다고 해서 크게 어려움을 느끼진 않았습니다. 의외의 복병은 바로 모니터링 결과를 기록하는 방식이었습니다.
처음에는 기존과 같이 Google Sheet를 사용하려 했으나 Google API의 무료이용자로서 URL의 개수를 늘려버리면 금새 API 최대 사용량에 막혀 URL에 접근할 수 없었습니다. 다음으로는 CSV 파일을 고려해 보았습니다. 하지만 세로형으로 데이터를 읽고, 쓰는 코드를 만들어 버렸기 때문에 CSV 파일을 이용하는 경우 다시한번 코드에 재작업이 필요했습니다. 이 과정에서 수많은 실험과 실패가 있었습니다.. 괴로웠어요..
최종적으로 선택한 것은 json파일입니다. 개인적으로 데이터를 다룰때 json파일을 좋아하는 편입니다. key:value의 구조로 되어있다 보니 처음 보는 사람도 별도 설명 없이 어떤 데이터가 어떤 역할을 하는지 금새 알 수 있기 때문입니다.
처음에는 URL_DELIMITER와 url, status_code만 가지고 있었으나 메시지를 발송해야 하며 그 메시지는 상황에 따라 각자 다르게 발송해야 하기 때문에 key를 하나씩 추가하다 보니 위에 첨부한 코드와 같은 json 구조가 만들어졌습니다.

## ![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2025%2F1%2F6%2Fa5a60c9e-879d-4905-8f06-8b3a69e4b7ca&w=inherit&q=80)**One more thing**
코드 작업을 완료하고 기능 중요도가 높거나 유저 인입이 높은 웹 페이지를 선별하고 있었습니다. 그런데 그 때 알게된 사실은 바로.. 이 스크립트라면 웹 페이지 뿐만 아니라 API도 모니터링 할 수 있었다는 것입니다. URL만 넘겨주면 되기 때문에 API URL 또한 넘겨줄 수 있었고 개선된 구조에서는 모니터링 할 수 있는 URL의 개수를 얼마든지 늘려도 되기 때문이었죠.
곧이어 기능 중요도가 높거나 호출량이 많은 API 또한 모니터링 대상으로 추가하여 현재 100개의 URL을 수집해서 모니터링 중입니다. 다음주 목요일에는 팀원 분들께 해당 내용을 공유하고 각자 필요한 URL을 공유받아 URL을 더 추가할 예정입니다.

## ![](https://image.wanted.co.kr/optimize?src=https%3A%2F%2Fstatic.wanted.co.kr%2Fcommunity%2F2025%2F1%2F6%2F95189eaa-506a-496c-93ea-491ca03fb253&w=inherit&q=80)**마무리**
사실 지금 저는 리프레시 휴가중입니다. 2025년 1월 5일까지 쉬고있는 중인데요. 이렇게 여유롭게 글을 쓴게 얼마만인지 마음이 편안합니다. 2024년이 지나기 전에 묵혀왔던 작업도 끝내고 마지막 글도 쓸 수 있어서 기분도 아주 좋네요.
개선된 모니터링 스크립트로 훨씬 더 많은 URL을 감시할 수 있게 된 과정의 공유를 마칩니다!
새해복 많이 받으세요~🙏










원티드 서비스 모니터링 스크립트를 3년 만에 개선한 이유

원티드 기술 블로그

원티드 기술 블로그