[Best Of the Best 활동기] 1차 팀 프로젝트 후기 - 팀 빌딩 및 협업의 고민

오늘은 BoB 10기 보안제품개발 트랙의 보안 솔루션 제작 수업에서 한달동안 진행한 1차 팀 프로젝트에 대해서 이야기해보려 한다.

해당 글은 총 2부작으로 팀 빌딩과 협업 과정 그리고 서비스 설명 및 개발 과정 으로 나뉘어져 있습니다.

• 1차 팀 프로젝트 팀 빌딩 및 협업의 고민들
• 1차 팀 프로젝트 프론트엔드를 개발하며 했던 고민들
• 1차 팀 프로젝트 백엔드를 개발하며 했던 고민들
• 1차 팀 프로젝트 인프라를 개발하며 했던 고민들

프로젝트 github 바로가기 -> 보안 위협 트래픽 분석 솔루션 github

GitHub - dhslrl321/L7-monitor: 🔐 L7 에서 동작하는 Access Log 기반 트래픽 분석 및 보안 위협 분석 서비스

---

 

BoB 커리큘럼의 큰 흐름은 다음과 같다.

 

공통 교육(7월) -> 전공 심화 교육(7월 ~ 9월) -> 2차 팀 프로젝트(9월 ~ 12월) -> 2차 심화 교육(12월 ~) -> 수료

 

현재는 전공 심화 교육 시즌이고 심화교육 내에서 2차 팀 프로젝트를 위한 간단 몸풀기? 느낌의 1차 팀 프로젝트를 진행한다.

 

학교가 대전에 위치해 있어서 여러 연합 동아리나 큰 팀에 소속되어있던 경험이 드물던 나에게는 이번 팀 프로젝트가 매우 흥미로웠고 새로웠다.

 

그래서 간단한 프로젝트라고 생각하지 않고 여러 사람들과 만나는 첫 프로젝트라는 생각에 더욱 열심히 해보고 싶었다.

 

1차 팀 프로젝트는 크게 팀 빌딩 -> 기술 선정 -> 멘토 피드백 -> 개발 -> 시연 및 평가 로 이루어진다.

 

1차 팀 프로젝트는 전공 교육과 함께 진행되어 일정이 매우매우 빡빡하고 안 그래도 많기로 유명한 BoB 과제 스택에 팀 프로젝트 까지 진행하게 되는데 정말 일정이 생각 이상으로 안 나온다.

 

나는 과제에 크게 의미를 두고 있지 않기 때문에 그나마 괜찮았지만 BoB 인증자를 노리는 인원들에게는 지옥 그 자체였다고 한다..

 

팀 빌딩

 

팀 빌딩은 보안 솔루션 개발 수업 시간에 멘토님이 안내해주시는 대로 진행되고 팀 인원은 1인팀 부터 5인팀 까지 자율적으로 인원이 구성된다.

 

첫 주 부터 각자 관심있는 분야를 정하고 그 인원들끼리 또 팀원을 선정하였는데, 우리는 트랙 반장님 께서 각자 관심 분야를 조사하여 멘토님에게 전달해드렸다.

 

각자 관심 분야는 크게 해킹 방어, 권한 제어, 분석 도구, 교육, 취약점 으로 나뉘어진다.

 

 

나는 마이크로서비스의 인증과 권한이나 컨테이너 환경에 관련된 프로젝트를 하고싶었고 멘토님에게 분산 환경에서의 토큰 릴레이 서비스를 제안하여 여쭤봤더니 그건 BoB 에서 할만한 주제는 아닌것 같다는 피드백이 와서 다른 주제를 고민했어야 했다..

 

BoB 에서 친해진 동료 한 명과 함께 다른 주제를 생각하던 도중 모니터링은 어떻겠냐는 의견이 나오게 되어서 분석 도구 주제로 들어가게 되었다.

 

마침 BoB 외에 진행하던 팀 프로젝트에서도 모니터링 관련 도구의 도입이 필요했어서 나름 흥미로운 주제였던것 같았다.

 

그러던 와중에 BoB 들어오기 전에 인턴쉽을 진행했던 회사에서 사내 모니터링 솔루션을 직접 개발했던 동료 교육생이 있어서 그 분과 또 군대에서 여러 모니터링 툴을 다뤄봤던 분과 함께 팀을 꾸리게 되었다.

 

운이 좋게 나는 4명의 천사 팀원들과 함께 모니터링 도구 개발이라는 목표를 갖는 팀이 구성되었다!

 

진짜 팀원 운이 너무너무 좋았던것 같다... 사랑해요 보리밥..

 

비대면 팀 회의

 

BoB 10기 전공 교육을 듣는 현재는 코로나 상황으로 사회적 거리두기 4단계가 진행되어 100% 비대면으로 협업이 진행되었다..

 

아쉬웠던 것들은 많았지만 비대면 회의를 진행하면서 이득인 부분도 있기에 그나마 장점을 꼽자면 다음과 같다.

 

• 문제 발생에 대한 빠른 피드백과 자유로운 회의
• 회의 부담 감소로 생산성 증가
• 잠옷 차림으로 회의 가능

 

잠옷 차림은... 좀 그렇지만 일단 각자 교육 일정과 과제 덕분에.. 컴퓨터 앞에 앉아 있을 확률 100% 이기 때문에 급하게 회의가 가능하냐고 물어보면 가능하다고 대답해준다.

 

그래서 문제에 봉착하거나 의논할 주제들이 있다면 바로바로 Google Meet 을 개설해서 회의를 진행한다.

 

 

우리는 첫 팀 회의에서 바로 주제를 선정하고 심화에 들어갔다.

 

주제 선정 - Access Log 기반 모니터링 툴 제작

 

사실상 모니터링에 관심있는 사람들이 모인 자리라서 주제는 모니터링으로 바로 정해졌다.

 

하지만 여기에 보안을 어떻게 접목시킬지 계속해서 이야기를 했었다.

 

그래서 나온 이야기가 바로 Application Layer 에서 돌아가는 웹 공격 모니터링 대시보드 이다.

 

원래 계획은 웹 공격 분류와 패킷 카운팅을 이용한 DDos 탐지 기법을 접목하여 실시간 탐지와 차단이 모니터링 대시보드, 근데 이제 access.log와 SaaS를 곁들인 프로젝트를 계획했었다.

 

하지만 Application Layer 에서의 실시간 차단이 어렵다는 피드백과 여러 일정상 문제점 때문에 단순 공격 분류와 실시간 모니터링 대시보드만 제공하기로 결정이 되었다.

 

이걸 누가 써? 라고 할 수 있지만 잠시 진정해주세요

 

우리가 겨냥한 고객은 바로 DevSecOps 를 채용하기 부담스러운 스타트업이나 기업을 대상으로 하는 서비스였다.

 

그래서 SaaS 형태로 서비스가 제공되고 별 다른 설정 없이도 기존에 운영 중이던 서비스에 쌓이는 Access Log 만 있다면 바로 시각화가 가능하다는 점을 강조하며 프로젝트를 진행했다.

 

결국 시간에 못 이겨서.. SaaS도 포기하고 On-Premise 로 가게 되긴 했지만..

 

주제가 빠르게 정해져서 우리는 개발을 좀 더 빠르게 시작할 수 있었다.

 

기술 선정

 

기술은 당연히 팀 내부에서 익숙한 언어와 기술이 가장 먼저 정해졌다.

 

Web Application

 

나는 Spring Boot 를 이용한 백엔드 개발에 가장 자신이 있었고, 팀원들에게는 말하지 않았지만 React, Next.js 프로젝트 리딩 경험이 여럿 있어서 프론트도 크게 문제가 없었다.

 

내가 Back End가 너무 하고싶다고 간절히 바랬던게 팀원들에게 느껴졌는지 내가 Backend를 맡게 되었고, 다른 팀원 한 명이 Front를 맡게 되었다.

 

하지만 팀원들 중에 Front 개발을 주로 해왔던 팀원이 없었기에 Front 는 순수 HTML과 BootStrap 을 이용하기로 했는데, 이후 Data Fetching 이나 Render 등 다양한 문제가 발생했고, 내가 익숙한 React 를 이용하는 대신 Front도 개발하는 것으로 결정이 났다.

 

분석 Daemon & 로그 전송 Agent

 

분석 Daemon과 로그 전송 Agent는 문자열 파싱에 강한 이점과 팀에서 익숙한 Python 을 이용하기로 했었고 전에 경험이 있던 팀장과 팀원 한 명이 각각 일을 분담하기로 했었다.

 

배포 및 인프라

 

웹 애플리케이션은 하나의 Computing Engine 에서 두 개의 서버를 동시에 돌릴 수 있도록 Reverse Proxy 가 도입되었다.

 

그리고 각각의 Application 은 도커를 이용해서 컨테이너화 하였으며 멀티 도커 컨테이너를 관리하기 위해서 docker-compose 가 사용되었다.

 

그래서 결론은?!

 

그래서 결국 기술 스택과 언어 및 환경은 위와 같이 선정되었고 다들 맡은 바를 너무 열심히 잘 해주었다.

 

협업 및 일정 관리

 

협업을 위한 문서화 도구는 거의 당연?? 하게도 Notion 으로 선정되었다.

 

나는 노션을 사용하는 것을 어꺠 넘어로 봐 왔기 떄문에 잘 사용하지는 못하지만 우리 팀장님이 노션에 일가견이 있으셔서 아주 예쁘게 잘 구성해주셨다.

 

 

API 문서나 DB 스키마도 깔끔하게 잘 구성해놓았고, 이게 생각보다 생선성을 매우 증가시켜준다.

 

나는 원래 Github Issue나 Wiki 를 주로 사용했었는데, 이게 주 목적이 프로젝트 관리 목적이라기 보다 소스 코드의 version control 의 목적이다 보니 뭔가 문서화 도구로 사용하기에는 조금 애매한 부분이 있었다.

 

특히 UI가 크게 다가왔다.

 

 

깃헙의 UI는 뭔가 뭉뚝뭉뚝하고 개발자스러운데, Notion 은 전혀 다르다.. 뭔가 멋있는 문서같다.

 

 

이렇게 문서화를 정리하였고, 깃 브랜치 전략은 Gitflow를 사용했다.

 

우리는 Gitflow 의 Hotfix 나 release 브랜치는 사용하지 않고 적합하지 않아서 Hotfix와 Release 를 사용하지 않는 방향으로 갔다.

 

 

gitflow 를 사용하다가 한 번 Conflict 가 발생했던 적이 있는데, 사실 강제로 Conflict 를 발생시키고 Github 에서 수정하려고 했었는데, 바뀐 코드가 파일 변경이 아닌 디렉토리 변경 이라 Github 수정이 불가능했었다.

 

그래서 결국 충돌 해결 브랜치를 따로 빼서 작업을 해놨는데.. 그 순간 뇌절이 와 버리는 바람에 한 시간? 정도를 그냥 날렸던것 같다..

 

---

 

이렇게 프로젝트 협업과 팀 빌딩에 대해서 이야기했는데, 다음 시간에는 서비스가 어떤 방식으로 구성되고 개발되었는지 좀 더 기술적인 관점에서 이야기해보려 한다!