개요

너무나 오랜만이다… 10월 말 이후로 다시 챙겨본다. 못챙긴 이유는 일단 국비 지원에서 팀 프로젝트 하느라 못챙겼었고, 이후 자체적으로 쉬다보니 이제서야 이야기하겠지만 너무 늦은 감이 없지 않나 싶다. 뭐 아무튼 이번 포스트에서는 국비 과정 팀 프로젝트 과정에 대해서 어떻게 진행했고 느꼈는지, 개인적인 평을 끄적여 본다.

S.C.Vs (Stocknews Collection Viewers)

먼저 진행한 팀 프로젝트를 소개한다. 개인화 주식 뉴스 플랫폼이란 주제를 가지고 만든 팀 프로젝트, SCVs이다. Stocknews Collection Viewers의 약자로 주식과 관련된 뉴스를 중점으로 정보들을 모아 보여주는 웹 페이지이다. 주요 기능은 다음과 같다.

• 국내 / 미국 경제 뉴스를 크롤링한 다음 번역과 가공을 통해 뉴스들을 보여주는 기능
• 관심 종목에 대한 키워드 분석과 감정 분석을 하여 해당 주식에 대한 뉴스를 긍정/중립/부정으로 평가하여 보여주는 기능
• 주식 정보와 주요 지표를 보여주고, 관심 종목에 대한 커뮤니티를 형성하여 의견을 나눌 수 있는 기능

자세한 것은 https://github.com/27kdt3team/team3 에서 확인할 수 있다.

잘한 것 & 배운 것

• 팀장으로서 GIT 관리

  일단 팀 프로젝트 팀장을 맡았다. 그리고 팀 프로잭트 주제 선정부터 기능과 예상 기한 맞추기까지 프로젝트 계획 과정을 7인 모두가 온라인으로 머리를 맞대며 진행해왔다. 그리고 ‘개발 소스를 어떻게 관리를 하는가‘가 팀장으로서 큰 책임과 임무가 있었다. 나를 제외한 전체가 모두 git에 대하여 초보자였다. 이전 직무에서 git을 사원으로서 실무적으로 사용하는 방법들을 이 프로젝트에선 장으로서 가르쳐야하는 입장이 되어 버렸다.

  이를 위해 먼저 규칙과 커밋 양식을 세워서, 개발하기 전 개발 협업 과정을 체계적으로 두는 것 부터 시작하였다. 브랜치를 main과 develop으로 나누고, develop에서 또 기능별로 나눈 다음, 반영시 pull-request를 통해서만 같이 리뷰 받는 형식을 설정하여 체계적으로 관리를 하였다. 이전 직무에서 그냥 당연하다고 느꼈었던 것이었는데, 팀 프로젝트 들어가니 그냥 당연한 것이 아닌, 당연해야 하는 부분으로 자리잡았다.

  그리고 개개인의 git 문제의 경우 내가 일일히 공유하며 문제를 해결한 부분이다. 특히 커밋 충돌같은 경우이다. PR날릴 때 충돌이 발생한 경우 github에서 가이드를 해주고는 있지만, 실제로 어떻게 해결하는 지, 그래도 또 안될때는 다른 방법으로 우회하여 해야하는 지에 대해 일대일로 같이 화면 공유하면서 가이드를 해주었다. 너도 알고 나도 아는 확실한 방법으로 협업을 하면서 코드가 하나 하나씩 커밋되어 git으로 코드 관리뿐만이 아니라 진행 상황을 알 수 있게 되었다.

  Git의 체계적인 관리 시스템을 두면서 팀 프로젝트를 진행한 후 타인의 감상평으로 GIT 관리를 어떻게 해야하는 지 경험을 했다는 것이 가장 큰 보람이자, 잘하고 배운 점이 되었다. 실제로 심사 받을 때 멘토분들께서도 아주 체계적으로 잘 관리하고 있다고 칭찬을 들으니, GIT 관리 만큼은 자신감이 생겼고, 지금까지도 남아있다.

  

• 실전 Spring 구조 및 API 활용

  국비교육 과정에서 이론과 실습만으로 배웠던 Spring 구조를 실제로 활용하고 적용한 것이 팀 프로젝트에서 가장 큰 수확이라 생각된다. Spring boot를 활용하여 스프링 프로젝트를 설정한 다음, 계획했던 대로 그리고 배운대로 스프링 프로젝트의 큰 구조를 세워서 진행했었다.

  

  위 그림과 같이 Controller - Service - Repository 층으로 구분을 하고, 그 층에 맞게 기능들을 같이 구현하다 보니. 큰 구조 그림을 상상하면서 패턴화된 개발을 진행할 수 있었다. 개개인의 코드 스타일이 달라도, 구조에 맞게 개발하다 보니 진정한 스프링 개발을 할 수가 있었다.

  또한 주식 정보 크롤링 하는 부분을 맡으면서 외부 API 활용하는 방법을 익혔었다. 당시 한국투자증권 API를 활용하여, 먼저 계정 정보로 토큰을 받은 이후 주가 정보를 받는 API의 body에 토큰과 필요 요청 값을 같이 보내며 한국 투자 증권의 정보를 크롤링할 수 있었다. 거기에 더하여 이 과정을 파이선으로 다시 만들어 스프링 웹과 별개로 크롤러만 따로 돌 수 있게끔 변현하는 것을 도와주었다. 이 부분이 팀 프로젝트의 킥이었다.

아쉬운 것 & 배워야 하는 것

• 문서와 일정 컨트롤

  팀장을 맡다 보니 팀원에 비해 해야하는 것이 기대 이상으로 많이 있었다. 그 중 하나는 문서이다. 개발 산출물로 관리해야 하는 것이자, 이 문서를 가지고 개발을 해야하는 필수 조건이었다. 계획부터 UI 설명, DB 설명, 요구사항, 기능 등등 문서화 하는 것들이 꽤나 많았다. 물론 나 말고도 부팀장 및 팀원분들도 같이 문서화 작업에 적극적으로 동참하였다. 그러나 최종 검수를 해야하는 입장에 있다보니 막판에 놓치는 점을 발견하기도 하고, 또 개발에 완연히 집중하지 못하는 상황에도 처한 적이 있다.

  그리고 처음 2주동안 뭐 할지 계획하는 과정에서 일정도 예측을 하였지만, 개발은 예측한대로 되지 않은 점에 대해서 아쉬운 적이 있었다. 이전 직무에서도 예상치 못하게 시간이 오래 걸려서 애를 먹은 적이 있었지만, 팀원들이 그렇게 된다면?

• 프로젝트 완성도

  기능은 제대로 작동 되기는 한다. 그러나 프론트 족에서 아쉬운 점이 있다. 주로 백앤드만 다뤄봤기에 프론트 앤드는 각자 알아서 맡았었다. 물론 개발전 피그마를 통해 UI 설계는 해왔지만, 정확한 수치까지는 정하지 않은 상태였다. 그리고 페이지 설계를 구현해보니 해상도에 따라 UI가 달라지고, 또한 기능별로 UI가 통일되지 않는 부분이 있었다. 만약 프론트 앤드 팀이 있다면, UI부분은 그 쪽에 맡기고 백앤드 부분을 더 볼 수 있었지 않을 까 싶다.

  또한 외부 오픈소스의 기간 제한적인 사용으로 인해 프로젝트 이후 관리도 염려되는 부분이었다. 크롤링하는 과정에서 네이버 오픈소스 사용이 필수적인데, 이제 프로젝트 기간 이후 오픈소스 사용이 불가함이 있어서 후속 대치까지는 생각하지 못한 상황이다. 그리고 네이버 서버 서비스를 이용하여 외부 IP로 올리는 것 까지는 되었지만 진정한 호스팅 서비스를 적용하지 않았다는 것도 완성도 면에서 아쉬움이 남는다.

결론

이렇게 적어보니 이번 팀 프로젝트에서 좋았던 점, 좋아야 하는 점이 분명하게 보이긴 한다. 이 경험을 토대로 추후 직무에서도 강점을 더 발전하고 보완해야 하는 부분을 곱싶으면서 성장하는 개발자가 되고 싶다.