GitHub Action과 Playwright로 경쟁사 소식 공유 자동화 구현하기

 
서비스 기획자로 일하다 보면 자연스럽게 경쟁사 소식을 자주 찾아보게 됩니다.
신규 기능이 출시되었는지, 어떤 파트너십을 맺었는지, 혹은 어떤 업계 뉴스가 나왔는지를 꾸준히 살펴보는 거죠.
다만, 매일매일 그 일을 하는 건 현실적으로 어려웠습니다. 업무가 바쁜데 매번 검색하고, 기사 내용을 정리해 전사에 공유하는 건 꽤 많은 에너지를 소모하는 일이었거든요. 그래서 자연스럽게 루틴이 만들어졌습니다.
주 1회 주요 경쟁사 뉴스 서치 → 월 1회 정리 → 사내에 공유하는 루틴을 1년간 진행했습니다.
 
그런데 한 달치 뉴스를 모으고, 중복을 빼고, 관련된 내용끼리 묶어 공유 문서를 만드는 일은 시간 대비 효율이 너무 낮았습니다.
그렇다고 전사 직원들이 유용하게 보는 경쟁사 소식을 공유하는 것을 그만 할 수도 없었습니다.
꼭 필요하지만 비효율적인 이 업무를 어떻게 효율적으로 할 수 있을지 고민하다가, 직접 자동화를 구현해보기로 마음 먹었습니다.
이 자동화 프로젝트는 퇴근 후의 시간을 할애해 약 1개월간 진행했습니다.
 

이번 포스팅은 비개발자가 경쟁사 소식 공유 자동화를 구현한 과정에 대한 이야기입니다.

 

📰 데이터 소스 정하기

처음에는 뉴스기사를 자동으로 가져오려면 RSS를 쓰면 되겠지 라고 생각했습니다.
RSS는 사이트의 새로운 콘텐츠를 자동으로 알려주는 피드 형식이기 때문에, 이걸 잘 활용하면 사람이 검색하지 않아도 새 소식을 바로 받아볼 수 있을 거라고 생각했어요. 그래서 가장 먼저 떠올린 건 네이버 뉴스 RSS였습니다. 국내 뉴스 검색의 중심이 네이버이기도 했고, 경쟁사 관련 뉴스가 가장 많이 모이는 곳이었기 때문이죠.
하지만 막상 시도해보니 네이버 뉴스는 이미 오래전에 RSS 지원을 중단한 상태였습니다. 포털 구조상 공식 API도 제한적이었고, 자동으로 뉴스를 수집하는 방법이 없었어요. 결국 방향을 바꿨습니다.
 
구글 뉴스가 여전히 RSS 형식을 제공하고 있어서 구글 뉴스로 대체해보기로 했습니다.
일단 구글 뉴스에서도 국내 뉴스가 잘 노출되고 있었는지 확인했고, 특정 키워드로 특정 키워드로 검색한 결과를 RSS로 받을 수 있는지 확인했습니다. 구글 뉴스로 대체하는 것이 가능하다고 판단했고, “{경쟁사명} 기능 업데이트”, “{경쟁사명} 공지”, “국내 {도메인} 신기능” 같은 검색어를 등록해 놓고 자동으로 피드를 가져오도록 구성했습니다.
그 결과, 직접 사이트를 돌며 뉴스를 찾지 않아도 경쟁사 관련 최신 기사들이 자동으로 모이는 환경을 만들 수 있었습니다.
 
 

🗂️ 구조 설계하기

자동화의 기본 아이디어가 잡히자, 이제 남은 건 그 흐름을 실제로 구현하는 일이었습니다. 
단순히 데이터를 가져오는 게 아니라, 그 데이터를 정리하고 회사 협업툴에 올리는 전 과정을 자동화해야 했어요.
그래서 다음과 같은 구조를 설계했습니다. 혼자의 머리로 모든걸 생각해 낸 것은 아니고, chatGPT와 Claude의 도움을 받았어요.

이미지 직접 제작

• 데이터 설정 파일 (sources.yaml) 
  각 경쟁사별 수집 대상을 정의하는 파일. 이름, 수집 방식(RSS/Google News/HTML), 키워드 등을 정리함.
• 뉴스 수집 실행 파일 (collector.py)
  실제로 데이터를 수집하는 스크립트. RSS는 feedparser로, HTML은 Playwright로, Google News는 RSS 쿼리로 처리함.
• 업로드 실행 파일 (post_to_feed.py)
  수집된 데이터를 협업툴 뉴스피드로 업로드하는 모듈. 제목·본문 길이를 검증하고, 중복을 방지하며, 예외 발생 시 로그를 남김.
• 자동 실행 설정 GitHub Actions (cron.yml)
  전체 프로세스를 원하는 주기마다 정해진 시각에 자동으로 실행시킴. 

이 구조를 그리면서 느낀 건, 코딩을 할 줄 모른다 해도 AI의 도움을 받아 충분히 자동화를 설계할 수 있다는 점이었습니다. 원하는 데이터와 자동화 구조가 명확히 있었기에 AI의 조언을 더 잘 받을 수 있었어요. 
 
 

🏹 자동화의 핵심, Playwright와 GitHub Actions

구조가 만들어졌다면, 이제는 실제로 돌아가게 만들어야 합니다.
Playwright와 GitHub Action이라는 두가지 도구로 자동화를 실현할 수 있었어요.
Playwright는 Microsoft에서 개발한 오픈소스 웹 테스트 및 자동화 프레임워크이고, GitHub Actions는 소프트웨어 개발 워크플로를 자동화하는 CI/CD 툴입니다. 
 

💻 대신 클릭해주는 Playwright 

수집된 내용을 정리해 사내 협업툴에 공유해야 했는데, 이 과정은 클릭해서 진행할 수밖에 없었습니다. 해당 협업툴의 post api를 활용하면 됐지만, 바쁜 개발자들에게 이것까지 요청하고 싶지 않았어요.
협업툴에 로그인해서 포스팅 위치를 지정하고, 수집된 뉴스 내용을 복사해 붙여넣은 뒤 게시하는 과정을 완전히 자동화하기 위해 Playwright를 사용했습니다. 
 
Playwright는 마치 사람이 직접 브라우저를 열어 클릭하는 것처럼 로그인 → 작성 페이지 이동 → 입력 → 게시 버튼 클릭 과정을 그대로 재현할 수 있습니다.
덕분에 협업툴에 게스트 계정으로 자동 로그인해 수집된 뉴스 데이터를 자동으로 업로드할 수 있었어요.
*사내 협업툴의 사용자 계정을 자동화 프로세스에 등록하게 되면 보안 이슈가 있어 제한된 권한을 가진 게스트 계정을 받았습니다
Playwright를 통해 이 자동화 프로세스가 단순히 데이터를 가져오는 수준을 넘어, 직접 ‘공유’까지 마무리하는 시스템이 되었습니다.
 

⚙️ 대신 실행 버튼을 눌러주는 GitHub Actions

GitHub Actions는 자동화의 마지막 퍼즐이었습니다.
모든 스크립트를 수동으로 실행할 수는 없으니, 정해진 시간마다 알아서 실행되도록 해야 했죠. 
그래서 cron.yml에 아래와 같이 스케줄을 설정했습니다.

on:
  schedule:
    - cron: '45 23 * * *'   # 매일 KST 08:45 (UTC 23:45-1d -> 서울 +09:00)

 
이렇게 매일 오전 8시 45분부터 9시 사이에 자동으로 뉴스가 수집되고, 정리되고, 협업툴에 업로드됩니다.
수집 과정에서 발생한 오류나 중복은 로그 파일(missing_posts.csv)로 남겨 운영 중에도 안정적으로 관리할 수 있게 만들었어요.
이렇게 구조를 짜고, 활용할 도구를 정한 뒤 코드를 짜는 일은 AI에게 부탁했습니다.
 
 

🛠️ 운영과 개선

자동화 시스템이 완성된 뒤 처음엔 모든 게 완벽해 보였습니다. 
매일 정해진 시각에 GitHub Actions가 실행되고, Google News에서 최신 기사를 수집하고, Playwright가 협업툴에 로그인해 포스팅까지 자동으로 올려줬으니까요. 하지만 며칠이 지나면서 작은 문제들이 하나둘 보이기 시작했습니다.

⚠️ 로그인 세션 만료

Playwright가 협업툴에 로그인할 때 사용하는 세션이 일정 시간이 지나면 만료되었고, 그때마다 “인증 실패”로 포스팅이 누락되는 일이 생겼습니다. 로그인 정보는 GitHub Secrets에 저장돼 있었지만, 브라우저 쿠키가 새로 생성되지 않으면 정상 작동하지 않았죠.
그래서 이 문제를 해결하기 위해 매번 새 세션으로 로그인하도록 코드 구조를 변경했습니다.
즉, Playwright는 로그인 정보를 저장하지 않고 매 실행마다 ‘처음부터 로그인 → 글 작성 → 로그아웃’하는 방식으로 수정했어요.

⚠️ 중복 게시

뉴스 피드가 매일 실행되다 보니, 같은 기사가 중복해서 업로드되는 문제가 생기기도 했습니다.
이를 막기 위해 각 게시물의 제목 + 링크 조합으로 해시값을 생성하고, 이미 업로드된 뉴스는 자동으로 제외하도록 로직을 추가했습니다.

⚠️ 예외 케이스

때로는 Google News RSS에서 제목만 있고 본문이 비어 있는 기사나, 리디렉션 링크가 걸린 뉴스가 섞여 들어오기도 했습니다.
그래서 업로드 전에 본문 길이와 URL 유효성을 검사하고, 누락된 데이터는 자동으로 missing_posts.csv에 기록되도록 만들었어요.

⚠️ 좀더 업그레이드 하고 싶은 부분

위 오류사항들을 개선하고 나니 1개월간 매끄럽게 돌아가고 있긴 합니다. 매일 아침 9시 경에 포스팅이 자동으로 등록되는데, 휴일에도 계속 게시물이 등록되고, 휴일에 이미 등록된 경쟁사 기사는 중복 방지 조건때문에 다시 등록되지 않습니다. 휴일에는 아무도 협업툴에 접속하지 않기 때문에 이 때 등록된 내용은 잘 확인하기 어렵습니다. 그래서 한국의 휴일에는 등록되지 않는 조건을 추가하고 싶어요. 하지만 후순위라서 아직 방법을 찾아보지 않았습니다.  그리고, 관련성이 낮아 보이는 기사도 간혹 가져오기도 합니다. 검색 키워드를 좀더 정교화할 필요성도 있습니다.
 
 

💡 자동화는 문제정의에서 시작된다

이 프로젝트를 처음 시작할 때만 해도 코딩을 할 줄 모르는 내가 이걸 할 수 있을지 확신이 서지  않았습니다.
하지만 끝까지 해보니, 저에게 중요한 건 코드를 잘 짜는 법을 공부하는 것이 아니었어요. 진짜 중요한 건 “무엇을 자동화해야 하는가”를 명확히 정의하는 일이었습니다.

• 내가 매달 반복적으로 하고 있는 일은 무엇인지
• 그 과정에서 데이터 흐름은 어떻게 이동하는지
• 사람이 개입하지 않아도 흘러가게 하려면 어떤 단계를 연결해야 하는지

이런 질문을 스스로에게 던지면서, 자동화를 설계할 수 있는 사고 구조를 갖추게 되었습니다.
자동화의 핵심은 코드를 직접 작성하는 것이 아니라 흐름을 설계하고 예외를 정의하는 일이었어요.
RSS, 스크립트, GitHub Actions 같은 기술 요소는 결국 도구일 뿐입니다.
데이터가 어디서 오고 어디로 가는지만 명확히 이해하면, 충분히 하나의 자동화 파이프라인을 설계할 수 있었습니다.
그리고, 가끔씩 로그인 실패나 중복 같은 작은 오류들이 생길 수 있기 때문에 자동화가 스스로 무너지지 않게 운영할 수 있는 구조를 만드는 것이 중요하다고 느꼈습니다.
 

---

 
처음엔 단순히 ‘뉴스 검색을 자동화해보자’는 생각으로 시작했습니다.
하지만 지금은 매일 아침 자동으로 경쟁사 뉴스가 협업툴에 업로드되고, 팀원들은 그 소식을 자연스럽게 확인합니다.
이번 작업을 통해 자동화의 본질은 기술이 아니라, 문제를 정의하고 구조를 설계하는 사고력에 있다는 것을 깨달았습니다.
앞으로도 반복되는 일을 하나씩 구조화하고 시간을 아껴주는 시스템을 만들어보고 싶습니다.