2022년 4월 회고록

1. 공시 데이터 분석 시스템

✅ 완성된 초기 기획안을 기획팀 금융파트로 넘겼다.

기획자가 아닌 내가 기획안을 작성하게 되었던 연유도 기획팀 리소스 부족이었기 때문에, 전달 드린 초기 기획안을 썩 마땅치 않아 하시면 어쩌나 걱정했었다. 그러잖아도 신규 서비스 론칭 관련한 업무로 눈코뜰새 없이 바쁜데, 거기에 또 내가 연구소 일거리까지 얹어드리는 걸까봐서.

다행히, 초기 기획안을 받아보신 기획팀 금융 파트 담당자분들의 반응은 나의 걱정과는 180도 달랐다. '아... 좋긴 한데요...' 의 피로감 섞인 피드백 대신, '오! 좋은 것 같아요.' 의 긍정적인 피드백이었다. 그 몇 마디가 지쳐있던 내게 얼마나 큰 위안이 되었는지! 💪 내가 기획자인지, 디자이너인지, 재무분석가인지 헷갈리면서... 근 몇 개월간 갑갑한 감정을 느낄 때가 많았는데, 혼자 끙끙 앓으며 조사하고 준비해온 기획서들이 그래도 의미있는 노력이었던 듯하다! 다행이다. 😌

✅ 공시 데이터와 분석 결과를 저장할 데이터베이스를 위해 ERD 를 설계했다.

오케이. 초기 기획안이 받아들여졌다. 다음으로 내가 할 일은 공시 데이터를 어떻게 데이터베이스화할 것인지 구상하고 설계하는 것이라고 생각했다.

RDBMS 로 설계해보려고 하는데, 이 또한 경험이 없어서 따로 RDBMS 에 대해 공부해야만 했다. 강의와 인터넷상의 문서들을 통해 핵심적인 부분을 이해한 다음, 본격적으로 ERD 파일에 entity 를 생성하여 작업을 시작하면서 모르는 내용만 그때그때 찾아보는 식으로 진행해나갔다. 처음엔 좀 헷갈리는 개념 때문에 관계를 잘못 설정하거나 PK 값을 엉뚱하게 지정해주거나 하는 문제들이 있었는데, 2/3쯤 했을 때에는 더이상 그런 문제는 없었다.

데이터의 종류가 워낙 많기도 했고, 컬럼의 데이터타입을 지정하며 다시금 해당 투자 지표에 대해 공부해야하는 부분이 있었기 때문에 시간이 다소 오래 걸렸다. 대략 2주 정도. 대충 세어 보니 테이블 개수가 50 여개 정도 된다.

✅ 데이터 엔지니어링 업무 파트와 DB & ETL 구축을 논의했다.

작성 완료된 ERD 파일에 기반해 빅데이터팀 데이터 엔지니어링 업무 파트와 DB & ETL 파이프라인 구축을 어떻게 할 지 논의했다. 물론 나는 해당 업무의 실무자가 되진 않을 것이기 때문에, 자세한 개발 방식을 논의하지는 않았다.

데이터 전송 트래픽 비용을 고려했을 때 DB 를 클라우드 서버, 회사 IDC 중 어디에 올리면 좋을지, 데이터를 수집해올 때 유의해야 할 예외나 변경 사항 등은 어떤 것들이 있을지, 클러스터가 처리해야할 것으로 예상되는 데이터의 양을 얼마나 되는지, 어떤 목적으로 활용되기 위한 데이터인지 등에 대한 이야기들을 했다.

기획팀에 초기 기획안을 넘겼을 때처럼, 빅데이터팀에 ERD 를 넘길 때도 똑같은 걱정이 있었다. 그러잖아도 일이 많은데 내가 또 일을 얹어드리는 게 아닐까 하는 걱정. 다행히 빅데이터팀에서도 해당 프로젝트를 재미있게 봐주신 것 같다. 업무 로드는 늘어나겠지만, 하고 싶은 업무로 느껴진다고 말씀해주셨다.

이 좋은 사람들 같으니라고... 🥹

2. 실서비스 장애 대응

근 1년여 간 장애 발생 이력이 전혀 없었던 실서비스 딥러닝 시스템에서 장애가 발생했다는 연락을 받았다. 🤨 이전 나의 사수였던 분이 담당하여 개발했고, 그 분이 퇴사하시면서 내가 인수인계 받아 관리하고 있는 시스템이었다. 새롭게 배포한 작업이 아무것도 없었기 때문에 바로 짐작되는 원인은 없었다.

로그를 봐야겠다고 생각하고 사내 ArgoCD 로 접근하려던 중 타 부서의 뉴스 담당 개발자분이 스레드로 의심되는 원인을 달아주셨다. 아마 뉴스를 송고하는 매체사 쪽에서 사전 노티 없이 도메인명을 변경한 것 같다고. 아... input 전처리에 도메인명 활용 로직이 포함되어 있기 때문에 100% 이것이 원인일 것이라고 생각했다.

덕분에 원인 파악은 금방 되었고, 소스를 수정하여 prod 브랜치에 커밋 푸쉬 했다. 이제 git CI/CD 에 등록해둔대로 새로 빌드된 이미지가 쿠버네티스 클러스터에 배포만 되면 되는데... 이게 웬걸. 어째서인지 안 된다.

두 번째 문제의 원인은 ArgoCD 에 있었다. 어떤 연유에서인지 Pod 가 자꾸만 새로 빌드된 이미지 위에서 띄워지지 않고, 이전 버전의 이미지 위에서 실행을 시도하다가 죽어버리는 것이다. 결국 인프라팀의 담당자분이 해당 pod 의 이미지 주소를 수동으로 직접 변경하셨다. 그러고 났더니 다시금 pod 가 정상적으로 작동하기 시작했다. 👍

서비스는 정상화 되었지만, 두 번째 문제의 근본적인 원인 파악을 위해 인프라에서는 계속 보고 계시는 중이다.

3. Airflow 팀 스터디

✅ 빅데이터팀 사내 스터디를 시작했다.

주제는 Airflow. 현재 사내에 cron 으로 돌고 있는 많은 배치 잡들이 있는데 이들을 Airflow 로 옮겨 조금 더 체계적이고 효율적으로 데이터 파이프라인을 관리하고자 하는 것이 목적이다. 사실 정확히 말하자면, 그것이 이 스터디를 시작하게 된 데이터 엔지니어링 파트 분들의 목적이다.

나를 포함한 3명의 데이터 사이언티스트들은 이 스터디에 참여하는 목적이 조금 다르다. 우리는 앞으로 우리가 소비하게 될 데이터 자산들이 어떤 플로우를 거쳐 우리가 개발한 모델의 Input 에까지 도달할 것인지 이해하고 싶다. 그래서 잘못된 데이터 피딩으로 인한 장애가 발생했을 때 해당 문제가 어디에서 기인한 것인지 빠르게 파악하여 신속하게 트러블슈팅할 수 있기를 원한다. 또, 현재 데이터 엔지니어링 파트 리소스가 상당히 부족한 상황이므로, 우리 업무에 필요한 간단한 ETL 은 직접 DAG 를 작성하여 데이터 엔지니어의 검수만 거친 후 등록되는 방식으로 효율적이게 업무가 진행될 수 있으면 그것도 좋겠다고 생각하고 있다.

이번 주 수요일에 첫 주차 스터디를 했는데, 확실히 혼자 공부하는 것과 그 혼자 공부한 내용을 다함께 정리하는 과정을 거치는 것은 다르다. 강의와 책을 통해 습득한 정보가 머릿속 여기저기에 분산되어 있다면, 그것들이 발표하고 서로 질문하는 과정에서 서로 짝과 순서를 찾아 제자리를 찾아가는 느낌이랄까.

한 마디로, 너-무 좋다! 🤩

데이터 사이언티스트 + 데이터 분석가 직무를 위한 스터디도 하나 진행하고 싶다는 생각을 계속 하고 있었는데 그 생각이 더욱 강해졌다. 주제를 어떻게 잡으면 좋을까 고민이 되어 아직 본격적으로 말을 꺼내지는 않고 있다. 다른 분들의 의견도 들어보고 싶다. 차주쯤 사내 카페에서 커피를 마시며 이야기해보면 어떨지 팀원들에게 물어봐야겠다.

4. 프로그래머스 알고리즘 스터디

✅ 프로그래머스 알고리즘 스터디를 100% 수료했다.

지난 달부터 진행한 프로그래머스 알고리즘 파이선 스터디를 100% 달성율로 수강했다. ㅎㅎ

당장 내가 하고 있는 실무와의 접점은 없는 것 같이 느껴지지만, 기본기를 탄탄히 하는 것은 알게 모르게 결국 모든 것에 도움이 된다고 믿고 있다. 오랜만에 알고리즘 문제들을 풀어보니 퀴즈를 푸는 것 같이 느껴져서 재밌기도 했다. 특히 다른 사람들이 내 코드에 의견을 달아주는 부분이 가장 흥미롭고 도움이 많이 되었다. 완벽한 코드를 짰다고 생각해도 빈틈이 있고 또 있었다.

겨우 한 달 남짓한 짧은 코스였지만, 나름 느끼고 배운 점들이 많았다. 너무 당연하지만 당장의 실무에 치여서 잊고 있던 기본기들 말이다. 예를 들어, '가독성 있는 코드 짜기' 나 '내 코드에 문제가 없더라도 더 좋은 방법이 없는지 계속해서 고민하는 것' 등.