[기술적 이슈] 존버의 민족 (실시간 주가 관람 웹사이트)

프로젝트 정보 : https://sanghoonly.tistory.com/103

[미니 프로젝트] 실시간 주식 관람 웹사이트 (Feat. Flask)

 

프로젝트를 진행하면서 마주했던, 주요한 이슈들은 다음과 같다.

1. 처음 협업을 해 보는 팀원들과, 어떻게 문제없이 협업을 진행할 것인가?
2. 서비스 아키텍처는 어떻게 구성할 것이며 배포는 어떻게 진행될 것인가?

 

각각의 이슈들에 있어, 필자가 채택한 방식은 다음과 같다. 

1. 먼저 나서서 코드를 짜기보단, "팀원들이 짠 코드들의 마찰을 최소화하는 환경"을 우선적으로 구축하는 방식을 채택하였다.
   팀원들의 코드 마찰을 최소화하기 위해 서비스 아키텍처 및 어플리케이션 아키텍처를 구성하는 것을 최우선적으로 수행하였다.
2. 따라서 서비스 아키텍처를 아래와 같이 구성하였고, 자동화 & 무중단 배포 방식을 채택하였다.

 

---

 

1. 처음 협업을 해 보는 팀원들과, 어떻게 문제없이 협업을 진행할 것인가?

팀원들이 대부분 협업이 처음이었다.

• 팀원들이 서로 깃을 자유롭게 사용하는 것을 두려워하였고(타인의 코드가 날아갈 수도 있어서),
• 프론트 백엔드 역할 분담이 없어 각자 작업의 범위가 명확하지 않기에, 팀원들 서로 눈치보며 마음 편히 코드 짜기가 힘든 상황이었다. 
• 강의에선 구현하는 모든 기능들을 app.py에 집어 넣었기에, 4명 동시에 app.py에서 작업하는 것은 대혼란을 야기할 것이 뻔한 상황이었고 그렇다고 한명이 app.py에서 작업하는 동안 다른 3명은 놀 수도 없는 상황이었다.

 

때문에,

"코드 마찰을 줄이는 방식을 도입하여, 팀원들이 부담 없이 자신들의 코드에 집중할 수 있는 것"

이 본 프로젝트의 핵심이자 최우선 과제였다.

 

 

"부담 없이 자신들의 코드에만 집중할 수 있는 환경"을 만들기 위해,

통합 및 배포 등 코드 외적인 부분은 자동화할 필요성을 느꼈고, 따라서 Github Actions 및 Code Deploy를 통한 빌드 & 배포 자동화를 도입하였다. 

코드 마찰을 줄이기 위해선, 필수적으로 app.py의 기능들을 나눠야 했다. 4명이서 하나의 app.py에 접근하여 각자 자기만의 로컬에서 자기만의 함수를 구현하다간 app.py가 짬뽕이 돼 버릴 것이 뻔했기 때문이다. 

app.py의 함수(로직)들을 나누는 기준은 여러 가지가 될 수 있다. 단순히 app.py 파일 자체를 함수 단위로 분할할 수도 있으며, 각각의 함수들이 담당하는 기능(view 기능, DB에 접근하여 데이터를 가져오는 기능, 로그인 인증 기능 등) 별로 나눌 수도 있다. 필자는 후자의 방법을 채택하였다. 그 이유는 다음과 같다.

1. 현재 app.py 내의 각 함수들은 너무나 많은 기능들을 수행하고 있다.

request를 받아 request에 맞는 로직을 처리한 후(DB에 접근하여 값을 가져오는 것 까지 포함) 결과값을 가공하여 다시 response로 돌려주는 일련의 과정들이 하나의 함수에 구현되어있다. DB접근, JWT 등에서 필수적으로 처리해야하는 try except 문까지 하나의 함수에서 전부 담당하고 있으니, 가독성도 불편할 뿐더러 디버깅하기 또한 힘들다. 무엇보다 다른 팀원 코드를 이해하는 것이 정말 힘들다.

2. 재사용성

또다른 큰 문제점은 이런 복잡한 로직들이 상당한 부분에서 중복된다는 것이다. 또한, 만일 단순히 app.py 파일 자체를 나누는 방식을 채택했을 시엔, 중복되는 로직을 팀원 각자가 각자만의 언어 각자만의 방식대로 구현할 것이다. 이는 "코드의 마찰을 줄이자"라는 취지에 부합하지 않는다. 

 

따라서, 위의 문제들을 해결하기에 적합한 방식으로 MVC 패턴 및 Layered Architecture