[TIL] 원티드 프리온보딩 백엔드 인턴십 Week2) 11일차, 0830

첫 커리어코칭이 온라인으로 진행되었다. 재미있고 유익한 시간이었다.
프로젝트를 진행하면서 어딘가에 쫓기듯이 옆도 보지 않고 달리기만 했는데, 오랜만에 리프레쉬가 된 느낌이다.

✔️ 오늘 한 일

• 1차 온라인 커리어코칭 참여
• Task Scheduler를 설정하여 서울시 맛집 데이터 전처리 및 저장 작업 자동화
• 데이터 파이프라인 예외처리

👀 오늘의 이슈

🔥 데이터 수집-전처리-저장 예외처리 / 자동화 예외처리 구분

• 배경
  • 2차 과제에서 데이터 파이프라인의 수집-전처리-저장을 담당하게 되었다.
    자동화는 다른 팀원분이 담당하고 있는데, 내가 담당한 부분과 자동화 부분의 예외처리를 어떻게 구분할지 판단하기 어려워, 먼저 아래와 같이 분석해본 후 팀원 분들께 도움을 요청했다.

• 분석
  > pseudocode(슈도코드) 작성을 통해 예상해보았다.

1. 초기 데이터는 for문을 통해 전체 저장한 후,
   자동화를 통해 주기적으로 update / new 데이터만 저장
   → 자동화 이전에도 예외처리가 필요한가?

1. update 데이터 저장하는 경우
if (원본맛집.최종수정일자 != 가공맛집.최종수정일자) {
	수집-전처리-저장 작업 수행;
}

2. new 데이터 저장하는 경우
if (원본맛집.관리코드 != JSON응답.관리코드) {
	수집-전처리-저장 작업 수행;
}

2. 수집-전처리-저장 단계에서는 누락된 데이터나 null 값에 대한 예외처리만 하면 되는가?
3. 영업 상태가 폐업인 가게는 초기 데이터 수집 단계에서부터 예외처리를 해야 하는가?
   → 발생할 수 있는 문제 : 폐업일자가 없던 가게에 폐업일자가 추가되었을 때, update에서 제외될 수 있는 가능성 (폐업한 가게가 가공맛집 데이터에는 계속 영업중인 것처럼 보임)

if (JSON응답.폐업일자 존재) {
	수집 제외 작업 수행;
}

• 결론
  • 수집-전처리-저장에서 자동화까지의 과정은 서로 종속적이어서, 하나의 단계에서 문제가 발생하면 전체 프로세스에 영향을 미칠 수 있다고 판단했다. 따라서, 이 단계들을 분리하지 않고 한명의 담당자가 작업하는 것이 효율적이라고 판단하여 내가 자동화까지 마무리하게 되었다.
  • 맛집 데이터 전처리 시, 원본맛집과 가공맛집의 상세영업상태코드가 다른 데이터는 가공 테이블에서 삭제여부를 true로 저장하기로 했다. (Soft Delete 방식으로 저장)
  • 각 계층의 책임을 명확히 하기 위해 수집 로직과 전처리+저장 로직을 분리하기로 결정했다.

💡 Today I Learned

1. 자동화 시스템을 구축하면 API 호출이 더이상 필요하지 않아, Controller도 불필요해진다.

2. 오랜 시간 고민되거나 해결되지 않으면, 동료들에게도 도움을 요청해보자! 좋은 해결책이 나올 수 있다.

• 스스로 한 번 더 분석해보면서 머리 속에서 내용이 정리되기도 한다.

> 도움 주신 팀원분들 모두 감사합니다 :) 🙇🏻✨

 

---

< 해당 글은 velog에서 이전하며 옮겨온 글로, 가독성이 좋지 않을 수 있는 점 양해 부탁드립니다. >

🔗 velog 버전 보기 : https://velog.io/@ryuneng2/TIL-원티드-프리온보딩-백엔드-인턴십-Week2-11일차-0830