프로젝트 설명 및 회고
프로젝트 소개
깃허브 링크
GitHub - lv1turtle/Studio-Recommendation-Service: A web service that recommends a studio for people who start living alone using
A web service that recommends a studio for people who start living alone using a data pipeline - lv1turtle/Studio-Recommendation-Service
github.com
진행 기간
- 2024.07.15 ~ 2024.08.19 (약 1개월)
- 진행 과정
주제
- 자취를 시작하는 분들을 위한 원룸 추천 웹 서비스
프로젝트 인원 구성
- 총 4명
- 주제 선정, AWS Infra 설계 및 구축, Airflow 서버 개발, CI/CD
- ERD 설계, 데이터 전처리 및 ELT DAG 작성, 대시보드 제작
- 다방 데이터 수집 DAG 작성, 웹 서비스 풀스택 개발
- 직방, 부동산 중개업자 데이터 수집 DAG 작성, 머신러닝 모델 학습 및 예측 DAG 작성
나의 역할
- ERD 설계, 데이터 전처리 및 ELT DAG 작성, 대시보드 제작
활용 기술 및 프레임워크
| 분류 | 활용 기술 및 프레임워크 |
| Programming | Python, SQL |
| Cloud Service | AWS (Terraform) |
| Data Storage | AWS S3, AWS Redshift, AWS RDS(MySQL, Postgres) |
| Data Processing | Apache Airflow 2.5.1, AWS Glue |
| Web Service | React, Django, Nginx, Recoil |
| AI | Python(scikit-learn) |
| Visualization | Metabase |
| Collaboration | Github, Notion, Slack, Gather Town |
데이터 파이프라인
인프라 아키텍처
데이터 소스 및 ERD
- 데이터 소스
- ERD
프로젝트 요약 및 기대효과
프로젝트 결과
- 아래 링크는 모두 깃허브 Readme에 링크
기대효과
- 사용자 친화적인 간편한 웹 서비스
- 직관적이고 사용하기 간단하게 설계된 웹 서비스
- 사용자는 어려움 없이 쉽고 빠르게 매물 추천을 받을 수 있음
- 사용자의 시간과 비용 절감
- 다양한 부동산 플랫폼(다방, 직방) 데이터를 통합하여 한 곳에서 확인 가능
- 자취를 시작하는 사람들이 매물 검색에 소요하는 시간과 비용 절감
- 자취 시작의 부담 완화 및 만족도 증진
- 맞춤형 매물 추천 서비스 제공
- 매물 가격, 부동산 안전 여부 등 다양한 요소를 고려한 신뢰성 있는 매물 추천을 받을 수 있음
- 자취를 시작할 때 발생하는 불안감 완화 및 만족도 극대화
KPT 회고
Keep
- 오버 엔지니어링에 대한 고찰과 비용 측면에서 고민
- dbt 도입 여부
- 고민 과정 : 7/19
- dbt는 분석 목적이 강하지만, 우리는 서비스를 목표로 하기에 사용하지 않는 것으로 결정
- AWS Glue, AWS Redshift Spectrum 도입 여부
- AWS Glue 개념정리
- 고민 과정 : 7/17 7/22
- 프로그래머스에서 AWS Spectrum 지원이 추가되어 재검토 및 사용하는 것으로 결정
- 사용 이유 : 다방 데이터를 external table로 사용하여 물리적 공간 확보
- 직방, 다방 데이터 병합(UNION ALL) 및 중복 제거 테이블 생성을 위한 쿼리 작성
- 대시보드 툴 선택 과정
- 고민 과정 : 8/1 (Superset vs Grafana vs Metabase vs Redash)
- 여러 가지의 툴을 찾고, 현재 상황에 어떤 대시보드 툴이 가장 적합한지 고민
- 사용 이유 : 가장 중요시 생각했던 Grid Map 시각화에서 Metabase가 적합하다고 판단
- 가장 효율적인 방법으로 진행됐다고는 말할 수 없고, 오버 엔지니어링 (대표적으로 Airflow)으로 구현된 부분은 분명히 존재한다. 그러나 지식 습득 측면에서 바라보면, 여러 기술 사용과 고민을 반복하면서 큰 성장을 할 수 있었던 것 같다. 특히 멘토님의 조언에 맞춰 이번 주에 진행한 것과 다음 주에 진행할 것을 글로 정리하며, 프로젝트 진행도를 한눈에 알아볼 수 있어 좋았다.
- 새로운 기술을 도입하거나 쿼리를 작성하며, 어떤 방법이 더 효율적인지 고민하는 습관을 가지면 어떤 일을 진행하더라도 해당 상황에서 진행할 수 있는 최선책을 적용할 수 있을 것이라 생각한다. 또한 나의 고민을 팀원과 함께 공유하여 생각의 폭을 넓히고, 프로젝트의 문제를 모두가 알게 됨으로써 올바른 방향으로 나아가게 한다는 것을 느꼈다.
- dbt 도입 여부
- XY Problem (참고 링크)
- 멘토님이 XY Problem에 대해 소개해주셨는데, 고민하는 능력과 더불어 질문 잘하는 방법을 숙지하는 것을 강조하셨다. 특히 "절대 정답을 바로 알려드리지 않아요."라고 강력히 말씀하셨고, 실제로 질문에 대한 답변을 주실 때도 각 방법의 장단점과 질문에 대한 피드백도 해주셨다.
- 구체적인 용어 (데이터 -> 매물의 총 개수)를 사용하거나 현재 상황에 적용 가능한 방식을 찾는 방법을 알려주셨다. 특히 '일반적인 방법'이 아닌 '현재 상황에 적합한 방법'만 존재한다고 들었던 것이 기억이 남고, 이 부분에 유의하며 작업을 진행하였다.
- 결국 위의 내용을 정리하면 "고민하는 능력과 습관"을 크게 향상할 수 있었던 프로젝트였다. 다른 프로젝트를 진행할 때도 이 프로젝트처럼 고민하고, 적합한 방향으로 수정하는 과정을 반복한다면 분명히 성공적인 프로젝트가 될 것이라 생각한다.
Problem
- 카카오 맵 API 호출 제한 이슈 - 직방 (10만 건)
- 각 매물 별로 카카오맵 API를 호출해야 하므로 많은 API 호출이 필요함
- 다방의 경우 문제가 없었지만, 직방의 경우 약 30만 건의 호출 요청이 필요함
- 다방과 직방 모두 S3에 적재 후 외부 테이블로서 활용하려고 했으나 해당 이슈로 불가
- 부동산 중개업자 데이터 적재 과정
- vworld 자료실에 접속해 버튼을 눌러 csv 파일을 다운로드하여야 함
- 동적 수집 방법인 selenium을 사용했지만, AWS Lambda를 사용했을 때 지속적인 에러 발생
- 백엔드 서버 초기 설정 지원
- Django Database에 RDS를 연결하는 작업 진행
- 생성된 서버(ec2)에 Django를 구축하고, Database를 연동하는 과정에서 다양한 오류 발생
- Airflow를 활용한 S3 -> RDS csv 파일 적재를 위한 DAG 작성
- S3ToMySqlOperator를 사용하려 했지만, LOAD DATA LOCAL INFILE 에러 발생
- 이 Operator는 사용 불가하다고 판단하고, 메서드의 코드를 활용하는 방식으로 진행
- Redshift -> S3 -> RDS 벌크 업데이트(LOAD) 수행
- Redshift에서 S3로 csv 형태로 UNLOAD하는 과정에서 구분자 이슈 발생
- 구분자를 ','로 설정하였지만, 값에 ','가 포함되는 경우가 존재
- 혹은 줄 바꿈(\n)이 포함돼 line을 잘못 인식하는 경우가 존재
- DAG Dependencies를 고려한 DAG 실행
- 다방, 직방 데이터가 수집된 이후 병합 테이블 생성 과정이 이루어짐
- 병합 테이블이 생성되면, 분석 테이블과 ML 모델도 갱신
- 이 과정을 어떻게 코드로 구현할지 고민
Try
- 카카오 맵 API 호출 제한 이슈 - 직방 (10만 건)
- 다방의 경우 S3에 적재 후 외부 테이블로 가져와 사용하는 방법으로 진행
- 직방은 호출 제한에 맞춰 3-4일 간 수집을 진행 (load_initial_zigbang_data)
- 이후에는 매물 id를 활용해 중복 제거 및 새로 추가된 매물만 카카오 맵 API를 호출하여 데이터 적재
- 결과적으로 직방은 Differential 방식으로 Redshift에 적재되며, 외부 테이블 방식 사용 불
- 부동산 중개업자 데이터 적재 과정
- Airflow에서 Selenium을 설치해 직접 동작하도록 작업
- 로컬 환경에서 Airflow 테스트 과정에서 이슈가 발생해 다른 팀원에게 인수인계
- chrome webdriver를 ec2 환경에 설치하여 포트(4444)를 활용해 호출하여 selenium 실행
# 4444 포트에 있는 chromedriver를 호출
# ( seleniarm/standalone-chromium을 docker container에서 띄움 )
remote_webdriver = 'remote_chromedriver'
with webdriver.Remote(f'{remote_webdriver}:4444/wd/hub', options=options) as driver:
driver.get(vworld_url)
driver.implicitly_wait(3)
time.sleep(10)- 백엔드 서버 초기 설정 지원
- 해결 과정 : 7/30
- Airflow를 활용한 S3 -> RDS csv 파일 적재를 위한 DAG 작성
- 해결 과정 : 7/31
- Redshift -> S3 -> RDS 벌크 업데이트(LOAD) 수행
- DAG Dependencies를 고려한 DAG 실행
- 다방과 직방 DAG 중 늦게 끝나는 것을 기준으로 병합 테이블 DAG 실행
- 여러 번의 실행 중 가장 오래 걸린 것보다 조금 여유 있게 병합 테이블 DAG의 schedule 조정
- 병합 테이블 DAG가 끝나면 Trigger를 활용해 분석 테이블과 ML 모델을 갱신하는 DAG 실행
배운 점 및 아쉬운 점
배운 점
- KPT 회고의 Keep 부분이 이번 프로젝트에서 얻은 가장 큰 부분이라고 생각한다. 신입으로서 기술적 지식도 중요하지만 소프트 스킬(대화, 질문, 접근법 등)도 중요하다고 생각하는데, 소프트 스킬을 크게 향상할 수 있었던 프로젝트였다.
- 처음으로 Github의 Pull-Request를 사용해 보았고, main branch와 더불어 develop branch를 생성하여 실제 개발을 진행하는 것처럼 진행하였다. 처음으로 진행한 방식이었지만, github에 대해 더 자세히 알아볼 수 있었던 시간이었다.
아쉬운 점
- 프로젝트의 완성도가 100%가 되지 못한 것이 아쉽다. 한 달이라는 기간이 짧게 느껴졌고, 특히 인공지능을 도입하는 과정에서 정확도를 향상하기 위한 시간이 부족했다. 그리고 DAG Dependencies나 성공률 등 DAG의 안정성을 확인하지 못한 것이 아쉽다.
- 프로젝트 마일스톤을 작성에서 초기 주제 선정 후 진행해야 순서 상 맞지만, 프로젝트 마지막 부분에 이를 작성하였다. 프로젝트 완성도가 아쉬운 것은 체계적으로 진행하지 않은 이유도 조금이나마 존재한다고 생각한다. 다음 프로젝트를 진행할 때는 조금 더 체계적으로, 순서와 진행도를 확인해 가며 진행해보고 싶다.
'기타 > 회고록' 카테고리의 다른 글
| [회고] 2024년 10월 (24.10.01 ~ 24.10.31) (2) | 2024.11.14 |
|---|---|
| [회고] 2024년 9월 (24.09.01 ~ 24.09.30) (4) | 2024.10.03 |
| [회고] 데브코스 3차 기간 (24.06.03 ~ 24.06.30) (0) | 2024.06.29 |
| [회고] 데브코스 3차 팀 프로젝트 (24.06.10 ~ 24.06.14) (0) | 2024.06.15 |
| [회고] 개인 프로젝트 - FC Online 공식 경기 분석 (24.05.25 ~ 24.06.05) (2) | 2024.06.08 |
