개발 환경 세팅부터 첫 실행까지

Об этом предложении

구현 시작 할 일 단계 할 일 코드 작성 1 Python, Git, VS Code 설치 없음 2 프로젝트 열고 테스트·dry-run 없음 3 키 발급, Slack 연결, 실제 실행 없음 4 GitHub에 올리고 자동 실행 없음 — 운영하면서 코드 공부 병행 읽기 위주 5 MVP1 마무리: 수집 결과를 주간 리포트 파일로 저장 직접 작성 6 MVP2: 주간 보고 스킬 만들기 SKILL.md 작성 위 모든 명령어는 windows + PowerShell 기준으로 작성할 것이다. 1단계. 개발 환경 설치 일단 vscode 랑 python, git 등을 암것도 없는 내 회사 노트북에 설치해주었다. (해당 내용들은 생략) 도구 역할 Python 3.12 수집 프로그램을 실행하는 언어 Git 코드 변경 기록 관리 VS Code 코드 편집기 회사 노트북이라 관리자 권한이 없어서 셋 다 내 계정에만 설치하는 방식 을 골랐다. 2단계. 프로젝트 첫 실행 # (1) 자동 실행 설정 파일을 GitHub이 읽는 위치로 옮기기 mkdir .github move workflows .github\workflows # (2) 가상환경 만들기 python -m venv .venv # (3) 라이브러리 설치 .venv\Scripts\python -m pip install -r requirements.txt pytest # (4) 테스트 .venv\Scripts\python -m pytest -q # (5) Slack 없이 화면에만 출력 .venv\Scripts\python -m radar competitors --dry-run 한 줄씩 무슨 뜻인가 명령 하는 일 왜 필요한가 (1) .github\workflows 로 옮기기 자동 실행 설정 파일( radar.yml , tests.yml ) 위치 맞추기 GitHub은 이 경로에 있는 파일만 읽고 실행한다 (2) venv 이 프로젝트 전용 Python 공간 만들기 프로젝트마다 라이브러리 버전을 따로 관리. Java의 Gradle 의존성 관리와 비슷한 역할 (3) pip install -r requirements.txt 필요한 라이브러리 설치 requests (HTTP 호출), PyYAML (설정 파일 읽기) 두 개가 전부 (4) pytest 테스트 실행 인터넷·API 키 없이도 코드가 의도대로 동작하는지 확인 (5) --dry-run 실제로 수집하되, 보내지도 저장하지도 않음 결과만 눈으로 먼저 확인 activate 대신 .venv\Scripts\python 을 직접 부른 이유: PowerShell의 Activate.ps1 은 회사 PC 스크립트 실행 정책에 막히는 경우가 많다. 정책을 바꾸지 않고도 같은 효과를 낸다. 테스트 13개는 뭘 확인하나 인터넷에 실제로 접속하지 않고, 가짜 응답(Fake) 을 넣어서 코드의 판단 로직만 검사한다. 대상 확인하는 것 나라장터 수집 여러 키워드 결과 합치기와 중복 제거, 제외 키워드, 100건 넘을 때 페이지 넘기기, 인증키 오류 메시지 CVE 수집 CVSS 7.0 미만 거르기, 최신 점수 체계 우선 사용 페이지 감시 Oracle 패치 링크 찾기, 페이지 구조가 바뀌면 "0건"이 아니라 오류로 알리기 비교표 "EOL"이 "geolocation"에 걸리지 않게 단어 단위로 매칭, 오래된 칸 찾기, AI 판단이 실패하면 키워드 결과로 돌아가기 전체 흐름 같은 공고는 두 번 알리지 않기, 첫 실행엔 기준선만 저장, 한 출처가 실패해도 나머지는 계속 dry-run 결과 키가 없어도 NVD, GitHub, Oracle, Tomcat은 공개돼 있어서 실제 데이터가 나올 수 있다. NVD는 키가 없으면 요청 사이에 6.5초씩 쉬게 해 두어서 1분 정도 걸린다. 사내망에서 외부 사이트가 막혀 있으면 '수집 실패'가 보이는데, 이것도 정상이다. 멈추지 않고 실패를 보고하도록 만들었기 때문이다. 3. 이 프로그램은 어떻게 동작하나 흐름 python -m radar competitors │ ▼ __main__.py 명령어 해석, 설정(config.yaml)·비밀값(.env) 읽기 │ ▼ jobs.py 전체 순서 지휘 │ ├─▶ collectors/ 출처별로 데이터 수집 │ g2b.py 나라장터 API │ nvd.py CVE (NVD API) │ github_releases GitHub 릴리즈 │ page_watch.py API 없는 페이지 감시 │ ├─▶ state.py 이미 알린 것 거르기 (state/seen.json) ├─▶ comparison.py 비교표에서 다시 볼 칸 찾기 └─▶ notify/slack Slack으로 전송 │ ▼ 전송 성공 후 "본 것"으로 기록 → seen.json 저장 핵심 설계 네 가지 모든 수집기는 같은 모양( Item )을 돌려준다. 출처가 달라도 뒤쪽 단계는 데이터가 어디서 왔는지 신경 쓰지 않는다. 새 출처를 붙일 때 수집기 하나만 추가하면 된다. 같은 걸 두 번 알리지 않는다 (멱등성). 알린 항목의 ID를 state/seen.json 에 기록한다. 몇 번을 실행해도 새 것만 알린다. Slack 전송이 성공한 뒤에 기록한다. 전송이 실패하면 기록도 안 하니까, 다음 실행 때 다시 시도된다. 한 출처가 죽어도 나머지는 돈다. 출처마다 오류를 따로 잡아서, 실패한 사실은 Slack 메시지 맨 아래에 남긴다. 조용히 실패해서 "이번 주는 조용하네"로 착각하는 일을 막는다. 4. 배치 파이프라인이 정확히 뭔가 두 단어를 나눠 보면 이렇다. 용어 뜻 이 프로젝트에서 배치(Batch) 사람이 요청할 때마다가 아니라, 정해진 시간에 한꺼번에 처리하는 작업 평일 08:30, 월요일 09:00에 실행 파이프라인 데이터가 여러 단계를 차례로 거치는 흐름 수집 → 중복 제거 → 비교표 대조 → 전송 → 기록 그래서 배치 파이프라인 = 정해진 시간에 깨어나서, 데이터를 여러 단계로 처리하고, 끝나면 종료되는 프로그램. 반대 개념은 웹 서버 같은 상시 실행 서비스 다. 서버는 계속 켜져서 요청을 기다리지만, 배치는 할 일을 마치면 꺼진다. 이 프로젝트는 서버가 없다. 실행될 때만 잠깐 존재한다. 5. GitHub Actions의 역할, 그리고 이게 CI/CD인가 GitHub Actions란 GitHub이 제공하는 자동 실행 환경 이다. 정해진 조건(코드 push, 정해진 시간 등)이 되면 GitHub이 임시 가상 컴퓨터를 하나 빌려서 지정한 명령을 실행하고, 끝나면 그 컴퓨터를 버린다. 이 프로젝트에서 맡는 역할은 두 가지 파일 언제 실행되나 역할 이름 붙이면 tests.yml 코드를 push할 때마다 테스트를 자동으로 돌려서 깨진 코드가 들어오는지 확인 CI radar.yml 평일 08:30, 월 09:00 (cron) 수집 프로그램 실행 → Slack 전송 → seen.json 커밋 배치 실행 환경 (스케줄러) radar.yml 이 실행될 때 일어나는 일: GitHub이 임시 가상 컴퓨터(Ubuntu)를 켠다 저장소 코드를 내려받는다 Python을 설치하고 라이브러리를 설치한다 python -m radar bids 실행 (API 키는 GitHub Secrets에서 주입) 바뀐 state/seen.json 을 저장소에 커밋한다 → 다음 실행이 기억을 이어받는 방법 가상 컴퓨터는 사라진다 실행할 때마다 컴퓨터가 새로 만들어지고 사라지기 때문에, "이미 알린 것" 기록을 git 커밋으로 남겨야 한다. DB 대신 git 저장소가 상태 저장소 역할을 하는 셈이다. 그래서 CI/CD인가? 반은 맞고 반은 아니다. 용어 뜻 이 프로젝트 CI (Continuous Integration, 지속적 통합) 코드가 바뀔 때마다 자동으로 빌드·테스트 ✅ tests.yml CD (Continuous Delivery/Deployment, 지속적 배포) 테스트를 통과한 코드를 서버 등에 자동으로 배포 ❌ 배포할 서버가 없음 스케줄 배치 정해진 시간에 작업 실행 ✅ radar.yml radar.yml 은 CI/CD가 아니라 GitHub Actions를 스케줄러(cron) 대신 쓴 것 이다. 보통 회사에서는 Jenkins나 서버의 cron, Spring의 @Scheduled 로 하는 일을, 서버 없이 GitHub에 맡겼다. 정리하면: GitHub Actions는 도구이고, CI와 배치 실행은 그 도구로 하는 일 이다. 참고 GitHub의 cron 시간은 UTC 기준 이다. 한국시간 평일 08:30은 UTC로 전날 23:30이라 30 23 * * 0-4 (일~목)로 적었다. 예약 실행은 GitHub 사용량에 따라 몇 분~수십 분 늦어질 수 있다. 무료 계정의 Private 저장소는 월 사용 시간 한도가 있지만, 이 정도 작업이면 충분하다. 막혔던 것과 해결 문제 : 내 추측 : 실제 원인 : 해결 : 새로 배운 것 git config 는 GitHub 연결이 아니라 커밋 이름표다 배치 = 정해진 시간에 한꺼번에 처리하고 끝나는 작업, 파이프라인 = 단계를 차례로 거치는 흐름 GitHub Actions는 도구고, CI와 스케줄 배치는 그걸로 하는 일이다. 이 프로젝트에 CD는 없다 실행마다 사라지는 환경에서 상태를 이어가려면 어딘가에 저장해야 한다 (여기선 git 커밋) 다음 할 일 공공데이터포털 키 발급, Slack 웹훅 연결 로컬에서 실제 실행 → GitHub에 올리고 자동 실행 걸기