[Ciaolabella] 회고 - 2022년 마지막 프로젝트를 끝내며..

올해는 진짜 열심히 공부하며 달렸다. 그 과정에서 내 나름의 작은 성공들도 성취해볼 수 있었다.

 

특히 올 10월부터 진행한 Ciao label la 서비스를 만드는 프로젝트에서 정말 많은 공부를 할 수 있었다. 기존 챠오 라벨라 프로젝트를 확장 및 보완하는 프로젝트로 시작했으나, 많은 부분을 개선하고 확장성을 고려한 설계는 너무나 재미가 있었다.

 

https://github.com/Kyung-Deok/ciaolabella 

GitHub - Kyung-Deok/ciaolabella: ciao-labella extention project

 

이 프로젝트로 많은 것을 배울 수 있었지만 가장 크게 와 닿았던 것은 3가지 부분이다. 

 

첫번째로 설계 단계에서 치밀한 조사가 필요하다는 것, 두번째로 개발 단계에서 최대한 자원 한계에 맞춰 구축하는 것, 세번째로 팀원들과 소통 과정에서 협의를 이끌어 내려면 설득력 만큼이나 경청이 중요하다는 것이다.

 

설계 미스..메아쿨파..(내탓이오..)

---

이번 프로젝트에서 내가 욕심 냈던 것들은 대략

1. 안 써본 데이터 베이스 써보자
2. kafka 더 활용 해보자
3. Flink 사용해보자

이런 것들이였다. Flink가 네이티브 스트림으로 동작하기에 Spark Streaming 보다 성능이 좋을 것이라 판단했고, 또한 저번 프로젝트에서 사용한 Spark Streaming과 어떤 차이가 있을까 비교해보고 싶었다. 그래서 Flink를 도입해보자 설득했고 기존 로그 데이터를 집계하는 ELK 스택 대신 Kafka- Flink-Redis로 변경하고자 했다.

내가 Flink의 이론적인 내용을 준비해 팀원들 앞에서 발표하며 서로 간의 이해도를 높였고, 이후 이를 코드로 구현하고자 하는 작업을 했다. 하지만 너무나 기본적인 실수를 저질렀다. 물론 Python API가 지원 되는 것을 확인했다. 하지만 어디까지 지원되나? 는 확인하지 않았다. 완벽한. 실수. 정확히는 Python API는 window 기능을 지원하지 않았다.

 

물론 우리가 제대로 찾아보지 않아서 발생한 문제라 생각했고, 공식문서를 포함해서 말 그대로 "월드 와이드 웹"을 샅샅히 뒤져봤으나, 어디에도 Window 기능에 대한 이야기는 없었다. 결국, 시간은 시간대로 날리며, 마무리 했고, 이를 Spark streaming으로 대체했다. 너무 아쉬운 경험이였으나, 설계를 총괄한 내가 저지른 실수는 하루이틀짜리가 아닌, 일주일짜리 실수였다. 너무나 뼈아픈 실책이였고, 이를 통해 설계 시 정확한 목적에 맞는 사전조사가 필수라는 것을 깨달았다.

 

라즈베리 파이들을 착취해가며

---

아키텍처 설계가 끝나고 하나씩 우선순위에 맞춰 클러스터 구축 단계에 있었다. 라즈베리 4대에, 노트북 2대로 이뤄진 데이터 파이프라인에서 적은 자원들을 가지고 하나하나 설치해 가는 것이 얼마나 어려운 일인가, 다시 확인했다.

챠오 라벨라라는 서비스의 ETL 파이프라인에 생각보다 많은 프로세스가 동작했어야 했다. 오버테크라고 해도 틀린 말은 아니었다(포트폴리오 용으로 만든 프로젝트였으니). 그러다보니 자원할당을 꽉꽉 채워서 올려야 했다.

 

그 과정에서 많은 부분을 공부할 수 있었다. 여러 프로세스가 어떻게 동작할지 동작원리를 공부하고 미리 동작원리를 예상해서 구축해야 했다. 특히 kafka 설계 시 정말 많은 부분들을 보며 공부해 나갔다. 이렇다보니 하나를 구축하는데 기본 일주일 씩은 할애 했어야 했다.

점점 공부를 하며 구현을 하는 작업들이 힘들어져 갔지만, 그만큼 뒤에 따라오는 성취감은 배가 되었다. 이후 성공적으로 동작하고 다른 어플리케이션과 연동이 되었을 때는 정말 뿌듯했다.

 

하지만 이러고 끝인가? 절대 아니다. 동작하는 프로세스들은 어느순간 어떠한 원인으로 죽는다. 프로젝트 중간 중간 직접 확인해가며 해결해가며.. 이때 딱 한가지 느꼈다.

 

자동화 시스템이 필요해..!

고심했고, 해당 에러를 찾아 해결해나간 흔적들..

사실 쿠버네티스를 운용하기엔 자원이 턱없이 부족하다. 마스터 하나 올리는데 4코어를 집어먹는 쿠버네티스는 절대 활용할 수 없을 것 같다. 대체로 Docker-compose를 활용해 봤으나 관리포인트만 늘어났다. docker container로그가 너무 많이 쌓여, 디스크가 꽉 차면서 컨테이너가 죽어버리는 등 세심한 관리가 필요하기 때문이다.

 

앞으로 계속 고민해볼 문제다. 엔지니어로서 만든 파이프라인은 내가 책임져야 한다. 하지만 이것만 붙잡고 있을 수만은 없잖은가. 계속 고민해보자.. 안정적인 인프라를 위해..계속 고민해보자.

 

 + 해당 글들은 다음에 올리겠다.

 

 

상대방 이야기를 경청해야 한다. 우린 사람이니까.

---

내 이야기를 남에게 설득시키고자 한다면, 그렇다면, 남의 이야기를 먼저 듣고 그 이야기를 먼저 고민해봐야 한다. 이번에 정말 크게 느꼈다. 그 어떤 것보다도.

내 이야기가 설득력이 있다고 한들, 아니 백번 양보해서 내 이야기가 무조건 맞다 한들, 무조건 적인 주장은 고집 밖에 안된다. 개인적인 판단 시 고집은 긍정적일 수 있으나, 협업 시 고집은 보통 긍정적인 영향을 주지 못하는 것 같다. 

 

내가 해보고 싶은 것, 내가 생각하기에 효율적인 것들이 상대방도 그렇게 생각할 것이라는 것은 정말 어리석은 생각이였다. 머리론 알고 있었으나 나는 무의식 중에 그렇게 행동하고 있더라. 너무나도 멍청한 행동이였다. 모두가 깊은 생각을 하고 있을텐데 오로지 나만 그만큼 혹은 그 이상 생각하고 있을 것이라 생각한 듯 했다.

 

이 것을 깨닫게 해준 팀원들에게 너무 감사하다. 그리고 그들은 너무나 친절하게 나에게 화를 내고 짜증을 내기보다 내가 스스로 잘못했음을 깨닫게 해줬다. 다른 자료들을 가져와서 다른 가능성을 제시했고, 내 얘기를 경청하며, 나 역시 그렇게 행동할 수 있도록 유도 해줬다.

 

너무 부끄러운 경험을 한 이후로 나는 최대한 다 듣고자 했다. 늘 확신에 가까운 주장 보다 가능성을 의견 뒤에 달았고, 의견을 제시하기 보다 의견을 한번 종합해서 정리한 후 내 생각을 이야기 했다. 물론 그 전에 많은 근거자료들을 찾아보며 이를 뒷받침했다. 다시 한번 팀원들에게 감사하단 말을 전하고 싶다. 정말로 협업 간 멋진 태도를 보여줬기 때문이다. 나도 이제부턴 대화를 할 때 태도를 유지하기 위해 집중할 예정이다.

 

끝으로

---

기술을 설계하고, 선택을 하고, 판단을 해보며 분명 이론 공부를 하는 것과는 다른 경험을 했다. 물론 끝에는 체력이 바닥나며 집중력이 떨어지고 예민해졌다. 하지만 멋진 경험이였음엔 틀림이 없다.

 

이 경험을 토대로 앞으로 더 공부해 보자. CS기초를 보며, 더 공부하고, SQL과 Python 알고리즘은 틈틈히 공부하자.

그러면서 ciaolabella를 통해 많은 실험도 해볼 수 있는 한해가 되었음 좋겠다.

 

그리고 이제 취업이 되었음 좋겠다..제발!