2025 06 02 프로젝트 첫 회의 - devyzz/datajob-insight GitHub Wiki

Today's Agenda

프로젝트 목표 및 분석 범위 / 개발 범위 확정

1) 분석 범위 및 주제

주제명 분석 내용 분석 방법 목적
기업규모·유형별 요구 스펙 분석 - 기업 유형별로 요구 기술스택, 학력, 우대조건, 필수요건 등을 비교- 대기업/중견/중소, 공기업/스타트업 구분 - 키워드 빈도 분석 - 기술 분포 비교- 조건별 통계 시각화 - 기업군별 채용 특성 이해- 맞춤형 구직 전략 수립
채용 트렌드 및 인기 기술 분석 - 최근 1~2년간 자주 언급되는 기술/도구 파악- 직군별 기술 트렌드 비교 - 워드 클라우드- 군집화- 시계열 키워드 분석 - 기술 학습 방향 결정- 기술 간 연관성 파악
개발자 vs 데이터직군 수요 비교 - 직군별 공고 수, 연봉, 기술 요구사항 등 비교- 시계열 수요 변화 추이 확인 - 직군별 필터링- 채용 항목별 통계 비교- 비교 차트 시각화 - 기술 직군 간 수요 이해- 커리어 방향 탐색

2) 개발 범위 (End-to-End / 웹 (아직 논의중 추가예정))

  • 분석 결과를 시각화하여 사용자에게 직관적으로 보여주는 웹 기반 인터페이스 구성
구성 요소 설명 주요 기능
1.로그인 기능 사용자의 개인화된 이용을 위한 인증 기능 - 로컬 로그인- 유저별 즐겨찾기 저장- 필터 조건 저장 기능- 권한에 따라 기능 차등지급
2.채용공고 통합 테이블 수집한 채용 데이터를 통합해 보여주는 메인 테이블 - 기업명 / 직군 / 기술스택 / 경력 / 마감일 등 필드 포함- 다중 조건 필터링 (예: "백엔드" + "Spring" + "3년 이상")
3.기술 트렌드 시각화 기술 키워드 기반의 트렌드 분석 결과를 시각적으로 제공 - 워드 클라우드- 바 차트 / 라인 차트- 시계열 기술 키워드 추이 분석
4.직군 비교 분석 탭 웹/앱 개발자와 데이터 직군 간의 채용 정보 비교 - 직군별 채용공고 수, 연봉, 요구 기술 비교- 변화 추이 시각화 (시계열 분석)
5.실시간 집계 탭 (분산처리에 유리한 무언가 구성) 논의중

⚠️ 기술 아키텍쳐 조사 이후 재 논의 예정

- 수집 대상 플랫폼 선정 및 조사 - 기술 스택 및 아키텍처 확정 - Github 초기세팅 구성

📍Upcoming Tasks (Due: 목요일 16:30 (중간점검) / 차주 월요일 16:30)

작성해주시는 문서는 프로젝트 아키텍처에 대한 팀원들의 전체적인 이해를 돕는 것은 물론 향후 포트폴리오로 활용되어 면접 시 기술적 질문에 효과적으로 대응하는 자료로도 활용될 예정입니다. 성실하고 정성스럽게 작성해주시기 바랍니다 👍

김정은 – 채용 플랫폼 분석 (사람인 / 점핏 / 원티드)

해야 할 일

  • 각 플랫폼의 채용공고 구조 분석 (HTML 기반인지 / API 제공 여부 등)
  • 수집 가능한 필드 정리 (기술스택, 경력, 기업명, 위치 등)
  • 과거 데이터 수집 가능성 및 범위 확인
  • 플랫폼 간 특성 차이 비교

참고

  • 데이터 수집 시 법적/기술적 제약 여부
  • 수집 필드 표준화 가능성

인진석 – NoSQL vs RDBMS 비교 분석

해야 할 일

  • NoSQL (예: MongoDB) 사용 시 저장 방식, 조회/필터링 방법 정리
  • RDBMS 사용 시 DB종류 장/단점 비교 및 데이터 테이블 설계 예시 포함
  • 두 방식(NoSQL / RDBMS)의 장단점 정리 (유연성, 확장성, 쿼리 편의성 등)
  • 우리 프로젝트에 어떤 방식이 더 적합한지 명확히 결론 도출

참고

  • 예제나 실제 구성 예시를 시각적으로 보여주는 이미지가 함께 있으면 더 이해하기 쉬울 듯!
  • PostgreSQL 등 구체적인 DBMS 제안 시 장점도 함께 설명
  • 데이터 분석/시각화 단계까지 고려한 선택 요망

김예지 – Docker 및 Python 환경 구성

해야 할 일

  • docker 사용법 및 도입 장점 문서화
  • docker 환경구성 및 디렉터리 구조 설계 (아키텍쳐 흐름 기반)
  • GitHub 기반 개발환경 구성
    • 초기 레포 구조 세팅

참고

  • 아키텍처 흐름에 맞춘 Docker 연동과 폴더 구조 구성
  • GitHub와 EC2 환경에서 그대로 작동 가능한 형태로 설계
  • 문서화는 실제 사용자(팀원)가 혼자 보고 실행할 수 있도록 상세히 작성
  • 향후 메시지 브로커, 데이터베이스, 워크플로우 툴 연동을 고려한 유연성 확보

이재진 – 메시지 브로커 비교 (Kafka / RabbitMQ / Redis)

해야 할 일

  • 각 메시지 브로커의 특징, 장단점 비교
    • 메시징 모델 / 속도 / 장애 복구 / 확장성
  • Python 연동 가능성 및 사용 라이브러리 조사
  • Docker, GitHub Actions, EC2와의 연동성 분석
  • 본 프로젝트에 적합한 브로커 선정 및 이유 정리 문서화

참고

  • 실시간성, 분산처리 구조, 유지보수 편의성 관점에서 판단
  • 향후 Airflow 또는 배치 처리 연계 가능성 고려