좋았던 점

다들 적극적으로 의견을 제시하고 자신이 조금 더 아는 분야는 자기 파트가 아니더라도 조금씩 도움을 주면서 단점을 메꾸려 했습니다. 대표적으로 도커 컴포즈 파일을 구성하는 데 유독 MySQL 탑재가 안 되었던 부분을 포트 문제, 아이피 설정 등의 대안을 제시하면서 결국 해결한 적이 있습니다.
건강 문제나 휴가 등으로 목/금에 한 명씩 빠지면서 프로젝트를 진행했는데 아직까지는 큰 걸림돌 없이 차근차근 진행되는 것 같습니다.
멘토님과는 수요일에 오프라인에서 한 번, 일요일에 온라인으로 한 번 뵈었는데 이 분도 현직에서 10년 이상 근무하셨던 만큼 저희가 놓치고 있었던 부분을 짚어주면서 프로젝트의 방향성을 상기시켜주셨습니다. 특히 어떤 데이터를 사용할 것이고 어떻게 수집할 것인지, 그 특성에 맞는 모델을 어떤 것을 사용할 지, 프로젝트 아키텍처와 데이터 플로우의 중요성 등등을 세세하게 첨삭해주셨습니다. 대부분의 사항들이 실무에서는 이렇게 일이 굴러간다는 것을 체득시켜 주고자 하는 부분이었습니다.

아쉬웠던 점

커뮤니케이션의 문제가 여전히 발목을 잡는 것 같습니다. 의견 조율 등의 교통정리가 어느 정도 되었다고 생각하는데 막상 혼자서 딴소리를 하거나, 큰 틀에서의 이야기를 하고 있는데 너무 자세한 사항에 매몰된다거나 하는 부분은 반드시 개선해야겠습니다.

배운 점

파이널 프로젝트

협업/TL

이번 프로젝트에서는 각 조원들에게 마치 실제 회사에서 하는 것처럼 직책을 부여하는 과정이 있습니다. PM(프로젝트 매니저), TL(테크 리더), 애자일 매니저 등이었는데, 저는 이번에 TL을 맡게 되었습니다.
TL의 업무는 프로젝트 진행 기간 중 새 버전 출시를 기점으로 마일스톤(milestone, 체크포인트의 개념)을 작성하고, 필요한 기술 스택과 진척 상황에 따라 추가로 마일스톤을 배치/기존의 마일스톤을 수정/도저히 구현할 수 없거나 필요 없는 부분은 삭제하는 역할을 담당합니다. 이 때문에 전반적인 기술 스택을 골고루 이해하고 전체적인 진척을 잘 파악할 수 있는 능력이 중요합니다.

현재 깃허브의 공용 계정에는 리포지터리에서는 이슈 탭에서 마일스톤(Milestones)을 선택하면 프로젝트의 마일스톤을 생성/수정/삭제할 수 있습니다. 이 이미지에서 보여지는 마일스톤 중 확정된 것은 v0.1.0과 v1.0.0 버전으로 각각 화요일 오전에 있을 데모 페이지 시현과 최종 발표 마일스톤에 해당합니다. v0.6.0은 샘플로 만들어 본 것으로 수정될 수 있습니다.
현재 가장 시급한 부분은 v0.1.0의 데모 페이지 작성으로, 앞으로 우리가 어떤 기능을 어떤 기술을 이용해 구현할 것인지를 간략하게 보여줘야 합니다. 정 안 되겠으면 ppt로 이미지라도 만들어서 올리라는 주문은 덤이었습니다. 강의실에 마련된 tv에 세 팀의 데모 페이지를 항상 실행시켜 놓고, 새로운 버전이 배포가 될 때마다 실시간으로 데모 페이지가 바뀌게끔 구성하라는 강사님의 주문이 있었습니다.

멘토링 첨삭

다른 무엇보다 프로젝트에서 사용자의 요청이 어떤 경로를 통해 각 서버에 전달되고 그것이 어떻게 동작되어 다시 사용자에게 원하는 정보를 줄 수 있는지를 먼저 정의해야 한다고 했습니다. 앞서서 언급했던 아키텍처와 데이터 플로우를 정의하는 것이었죠. 의외로 모델의 선정보다는 이러한 아키텍처와 데이터 정제에 더 신경을 많이 써야 한다는 첨삭이었습니다. 저희가 느끼기로는 이 코멘트가 상당히 의외였고, 따라서 프로젝트의 방향을 수정하는 데에도 큰 영향을 주었습니다.
데이터가 많아질 것을 생각해 하이브의 사용도 염두에 두고 있었는데, 현재 예상치는 많아봐야 10만 개 정도의 데이터를 사용하는 것이고 이 정도 스케일이면 그냥 SQL이나 csv로 바로 올려도 괜찮을 것 같다는 코멘트가 있었습니다. 그 이상 넘어갔을 때에야 스파크를 사용하면서 하이브를 사용할 때 효율이 늘어난다는 코멘트도 추가해주셨습니다.

앞으로 바라는 점

금요일에 하루 휴가를 내서 하루 동안의 진행 상황은 그 다음 날 슬랙과 깃허브를 보면서 경과를 대략적으로 파악했습니다. 아직 사흘 정도 밖에 진행되지 않아서인지 큰 틀에서의 진행 정도만 파악하는 데는 무리가 없었지만, 프로젝트가 본격적으로 커지면 어떻게 회고를 작성하고 워크플로우를 수정해야 한 눈에 업무 진척상황을 보고받고 개선시킬 수 있을지 고민할 필요가 있을 것 같습니다.
팀원 중 한 분이 급한 마음에 자신이 아는 것을 모조리 쏟아내려다가 옆길로 새서 제지당하고, 그것 때문에 자신감이 없어지는 악순환이 이어지고 있습니다. 한 가지 크게 걸리는 부분이라면 제3자가 볼 때는 자기 능력에 비해 너무 많은 것을 해낼 수 있다고 호언장담하는데 프로젝트와는 맞지 않는 부분이고, 정작 그 능력이 도움이 안 되냐고 하면 오히려 그 반대라는 점이라서 어떻게 해야 올바른 방향으로 이끌 수 있을지 고민이 많이 됩니다. 저도 연구실에서 나오기 전까지 계속 잘못된 판단을 하다가 지금의 그 분과 비슷한 상황에 놓이고 효율이 떨어지는 경험을 해봤기 때문에 이 한 달 안에 완전히 고치지는 못하더라도 최대한 프로젝트의 내실에 충실한 방향으로 이끌 수 있었으면 하는 바람입니다.

저작자표시 비영리 동일조건