코린이형준

팀협업 프로젝트를 하며 초반에 무슨 준비를 해야할지 고민이 많았다.

혼자서 프로젝트를 진행할때와 달리 나는 서버만 만들고 클라이언트 개발자, 기획자, 디자이너가 서로 분업을 하기 때문에 초반에 세팅에 관해 모를 분들을 위해 백엔드(서버)개발자의 관점에서 글을 정리한다.

1. 팀 협업 레포지토리 및 소통 수단 협의

-팀 협업 레포지토리

선택의 부분인데 따로 레포지토리를 파도 문제는 없지만 추후 공식적인 부분을 고려해 처음부터 organization으로 팀레포지토리를 만들어 서로 레포지토리를 공유한다.

위의 블로그글을 보고 레포지토리를 파면 된다.

나의 경우, 위와 같이 만들어 하나의 레포지토리안에 client와 server를 분리하여 만들어 뒀다. 이부분은 팀원끼리 협의를 하면된다.

-소통 수단 협의

전체적인 팀협업 진행률 같은 경우, 노션을 만들어 매주마다 회의록을 적었으며 그주차에 해당하는 목표치를 todo형식으로 만들어 서로 진행률을 체크하며 프로젝트를 진행한다. 그리고 slack을 많이 사용한다고 하는데 이부분은 서로 대화가 가능한 수단을 만들어야 하는것이기 때문에 카톡이든 따로 문제는 없으니 협의를 통해 결정하면된다.

2. api 서버 개설 및 인프라 구축

-api서버 개설

GCP, AWS와 같은 클라우드 서비스를 이용해 추후 배포할 서버를 먼저 개설한다. 여기서 중요한것은 로컬에서 진행은 API가 유효한지 테스트로 활용후 테스트가 통과되면 배포서버에 즉시 업데이트를 해줘야 클라이언트에서 바로바로 테스트가 가능하기 때문에 로컬-POSTMAN(자가 테스트) -> 배포 서버-클라이언트 개발자 순으로 자가테스트를 한후 클라이언트 개발자와 테스트를 진행하게 된다. 즉, 처음엔 NGINX와 같은 웹서버를 통해 본인의 프로젝트를 공유한뒤 SWAGGER와 같은 명세서 자동화 라이브러리를 활용하여 API명세서를 찍어준다. 

명세서는 들어갈내용이 API주소, request, response data내용등이다. 이부분은 클라이언트 개발자가 개발을 할때 타입을 지정해줘야하기 때문에 서로 협의를 통해 필요한 데이터를 결정하고 예시를 적어준다고 생각하면 된다. 위의 블로그를 참고하면 좋다.

-인프라 구축

개발을 본격적으로 들어가기전에 인프라구축의 경우 nginx, apache와 같은 웹서버를 통한 배포 https적용, DB서버, S3연동등 앞으로 개발간에 바뀌지 않을 부분등을 미리 설정해주는 편이 좋다. 중간에 DB가 바뀌면 많이 곤란한 상황이 생기니 DB서버먼저 연결을 잘해줘야하며, 웹 기반 프로젝트의 경우, 가장먼저 cors지정을 해줘야 클라이언트와 협업이 가능하니 이부분을 먼저 허용해주고, 앱 기반 프로젝트의 경우, 경험상 따로 지정을 해주지 않아도 문제는 없다. 그리고 https즉 인증서 적용의 경우, 요즘 보안상 필수이니 적용을 해주어야 하면 route53과 같은 서비스를 통해 도메인 까지 ip에 연결해주면 모든것은 끝난다.

3. 기획자와 디자이너

사실 개발 관련한 사항은 준비할점이 많지만 왠만하면 기획자, 디자이너 분들과는 많은 소통을 하며 최대한 맞춰주는것이 좋다. 개발 관련 지식은 모르면 구글링을 통해 왠만하면 도움을 얻을수 있지만 기획과 디자인 모두 상당한 스트레스를 요구하게 된다고 느꼈다. 그래서 왠만하면 협업 툴이나 회의 관련한 피드백은 최대한 맞춰주는것이 프로젝트 진행사항이 긍정적인 방향으로 흐를수 있는 방법이 아닐까?생각한다.

4.정리 (백엔드 개발자)

-레포지토리 개설

-배포시(s3,db,etc...)인증서를 적용한 배포

-클라이언트 개발자와 통신 확인(웹 기반 프로젝트의 경우, cors확인필수, 방화벽도 꼭 확인)

-api명세서 구체화

-기획자와 디자이너분들의 니즈 최대한 맞춰드리기!!

기술스택 선정

시작전, 기술스택에 관하여 알아보던중 django, AWS정도만 결정했음 된거 아냐? 라고 생각했는데 구글링을 하다보니 그게 아니였다... 클라우드 서버, 웹 서버, 웹 프레임워크, 데이터베이스 이렇게 크게 4가지를 결정해야 했다.

-클라우드 서버

AWS vs GCP 여기서 결정을 해야했다. 전세계적으로 인지도 AWS승! 서버다운 시간 AWS승! 성능은 무승부!(성능의 판단요소가 너무 많다.) 사실상 뭐든 클라우드 서버 특성상 비슷하기 때문에 많이쓰는 AWS를 써보자 라고 결정했다. GCP같은경우는 나중에 경험해 보기로ㅎㅎ

-웹 서버

사실 이부분이 가장 어려웠다. 왜냐! 장고는 python manage.py runserver만 입력하게 되면 이미 웹서버를 구동시켰고 따로 웹서버가 필요 한걸까? 라는 생각을했다. 자세히 알아보니 장고 github를 통해 힌트를 얻을수 있었다.

HTTP server that implements the Python WSGI protocol (PEP 333, rev 1.21).
Based on wsgiref.simple_server which is part of the standard library since 2.5.
This is a simple server for use in testing or debugging Django apps. It hasn't
been reviewed for security issues. DON'T USE IT FOR PRODUCTION USE!

해당 runserver는 보안 이슈에 대해 체크 하지 않았으면 배포용으로 사용하지 말라고 경고 하고 있습니다. 즉, runserver를 통해 실행되는것은 테스트 용으로만 사용하라는 뜻이였습니다.

그래서 알아본 결과 apache, NginX를 알게 되었습니다.

-apache

아파치는 가장 전톡적인 웹서버이며, 이에따라 웹서버 점유율또한 다른것들과 비교불가능한 독보적인 프로그램입니다. 클라이언트의 요청하나당 스레드 하나가 처리하는 구조이기 때문에 메모리와 cpu소비량이 많습니다. 하지만 점유율과 역사가 있다보니 제공되는 모듈도 많고 호환성과 안정성이 뛰어납니다.

-NginX(엔진엑스)

만년 2등의 포지션이지만 현재 신흥강자로 취급받고 있습니다. 비동기 이벤트 기반으로 요청을 처리하며 무엇보다 아파치보다 효율적으로 요청을 처리할 수 있는 아키텍쳐입니다. 

-웹 프레임워크

Django, Django restfreamwork를 사용하기로 하였습니다. spring, express.js와 같은 프레임워크이 선택지또한 있긴하지만 현재로서는 저 포함 팀원이 익숙하게 사용가능한 웹프레임워크는 django라서 선택하게 되었습니다.

-데이터베이스

ORM을 사용하는 django의 특성상 RDMS를 사용하는것이 적절한데 선택지는 크게 Postgersql, Mysql 2가지였다. 

-Postgresql

• 오픈소스로 무료로 사용 가능하다.
• 다양한 join방법을 제공한다.
  • nested loop join, hash join, sort merge join등
• update를 할때 과거행 삭제후 변경된 데이터를 가진 새로운 행을 추가하는 형태라서 update가 느리다.
• 처리속도를 빠르게 하기 위해 여러 cpu를 활용한 쿼리를 실행한다.

-MYSQL

• update기능이 postgresql보다 우수하다.
• nested loop join기능이 postgre보다 우수하다.
• 문자열 비교에서 대소 문자를 구분하지 않는다.
• 간단한 처리 속도를 향상시키는것을 추구한다.

등의 2가지 sql의 특장점이 있는데 결론적으로 간단한 동작을 구현하는 서비스- mysql, 복잡한 쿼리를 요구하고 insert위주의 대규모 서비스인 경우 Postgresql이라는 결론이다. 우리가 만들 서비스가 복잡하지는 않겠지만 새로운것에 대한 초점을 맞췄을때 Postgresql을 사용하여 프로젝트를 진행하기로 결정하였다.

+) redis

-캐시의 필요성

캐시는 필수가 아닌 선택이다. 기본적으로 서비스는 WEB-WAS-DB의 3구조를 띄고 있는데 사용자가 늘어나게 되면 DB에 무리가 가기 시작한다. 데이터베이스는 물리 디스크를 직접 쓰기 때문에 서버에문제가 발생하여 죽더라도 데이터가 손상되지는 않지만 매 요청마다 물리 디스크에 접근해야 하기 대문에 부하가 상당히 많아진다.

이때, DB서버의 부담을 덜어주기위해 등장한것이 캐시서버의 도입인데 캐시는 한번 읽어온 데이터를 임의의 공간에 저장하여 다음에 읽을 때는 빠르게 결과값을 받을 수 있도록 도와주는 공간이다. 같은 요청이 여러번 들어오면 캐시서버에서 바로 결과 값을 반환해주기 때문에 DB부하를 줄일수 있음과 동시에 속도또한 빨라지게된다.

물론, 캐시서버는 물리디스크가 아닌 주로 메모리를 사용하기 때문에 속도가 빨라지는 장점의 이면에 서버에 장애가 날경우 메모리가 날아갈수 있는 단점이 존재한다. 그렇더라도 캐시는 거의 필수적으로 알아야하는 개념이기와 캐시서버로 널리 쓰이고 있는 redis에 대해 알아봐야한다.

-redis란?

redis는 키-값으로 이뤄진 캐시시스템으로

• List, Set, Sorted Set, Hash등과 같은 collection지원
• Race Condition에 빠질수 있는것을 방지
  • Single Thred기때문에 Atomic보장
• 캐시의 단점을 커버할수 있는 persistance를 지원하여 서버가 꺼지더라도 다시 데이터를 불러들일수 있음

위와 같은 기능과 장점이 있다. 즉, redis는 다시말해 하나의 캐시시스템이며 우리가 사용할 postgre를 도와주는 역할 정도로 이해할수 있다. 캐싱을 전체에 적용하기보단 간단한 로직에 선택적으로 도입하는것이 적절할것으로 판단된다.

django-redis 사용법

-firebase

firebase는 채팅앱을 구현할때 사용하려고 한다. socket형식의 realtime db로 구현을 해야하는것인데 이러한 어려움을 쉽게 해결해주는것이 firebase이다. 기본적으로 서버에 채팅서버db만 따로 빼놨다고 생각할수 있는것 같은데 이것같은경우는 백엔드단에서 처리도 가능하겠지만 프론트단에서 전부 처리하는것이 편리해보인다. 

새롭게 프로젝트를 시작하며 개발전 1주일간 3파트로 프로젝트 사전 준비를 하였다.

(1) 프론트, 백엔드 통신방법

(2) 기술스택 선정, 협업 노하우

(3) token, django user, 소셜로그인

위의 3가지를 사전지식으로 먼저 조사하고 시작하기로 하였다.

RESTAPI

API는 데이터베이스와 사용자 인터페이스 즉, 프론트엔드 영역 사이에서 중간다리 역할을 해준다고 생각하면 된다. 백엔드단에서 만든 JSON,XML과 같은 형식의 데이터를 URI에 나타내어 프론트엔드는 URI에 있는 데이터를 가져다 쓰는 역할을 하는것이다. RESTAPI는 HTTP Method(GET, POST, PUT, DELETE)로 표현된 행위와 /accounts/2와 같은 주소를 합쳐 GET accounts/2와 같이 나타내어 프론트엔드가 데이터를 쓰도록 도와준다. 그리고 HTTP응답을 상태코드로 나타내는데

위와 같은 상태코드로 나타낸다.

즉, RESTAPI는 

1.HTTP METHOD

2.데이터 주소

3.상태코드

크게 3가지를 통해 데이터를 표시하고 프론트가 적절하게 사용하게끔 도와주는 역할을 한다.

DjangoRESTFramework가 바로 RESTAPI인것이다.

프론트와 백엔드 연동방식(REACT-DRF)

-연동원리

1. 장고와 데이터베이스를 연결합니다.

2. 장고 ORM을 통해 데이터를 받습니다.

3. 받아온 데이터를 DjangoRESTFramework를 활용해 json객체로 만들어줍니다.

4. json객체를 특정 url에 뿌려줍니다.

5. React에서 fetch를 통해 특정 url로부터 json객체를 받아옵니다.

6. 받아온 데이터를 리액트식 문법으로 가공/사용하여 프론트엔드단을 꾸밉니다.

-연동방법

이를 실습으로 연결하는것은 실제 프로젝트를 진행하며 포스팅하기로 하고 8000포트의 django서버, 3000포트의 react서버를 사용하는 두프레임워크를 연결하기위한 사전준비에 대해 다뤄보려한다. 크게 2가지인것 같다.

1. django

- cors 문제를 해결하기 위해 django-cors-header 설치

-setting.py

• INSTALLED_APPS에 ‘corsheaders’ 추가
• MIDDLEWARE에 ‘corsheaders.middleware.CorsMiddleware’ 추가(가장 위에 놓으라는 말도 있고 CommonMiddleware 위나 밑에 놓으라는 말도 있다.)
• CORS_ORIGIN_WHITELIST = [‘http://127.0.0.1:3000’ ,’http://localhost:8000’] 추가

2. react

app/package.json 하단에 proxy를 사용해 localhost:8000의 /api에 접속할수 있도록 해준다.

"proxy": {
	"/api": {
		"target": "http://localhost:8000"
}

위의 2가지 방식중 한가지로 설정을 하면 3000포트에서 8000포트에 있는 데이터를 자유자재로 가져올수 있다.

이후부터는 프론트단에서 axios통신을 사용해 fetch로 데이터를 가져와 행위에 맞게 데이터를 사용하면된다.

(프로젝트를 진행하며 계속 추가하도록 할 예정입니다.)

참고

프로젝트 목차에서 가장 먼저 설명해야 할것은 일단 개발자들이 협업때 소통하는 방식이다.

필자의 경우, 가장 중요한 팀원들을 캠퍼스픽 이라는 대학생 스터디 모집란에서 모집하였다.

가장 쉬운 방법은 it연합동아리에 들어가는 것인데 일단 어느정도 실력이 갖춰진 사람들을 모집하기 때문에 처음 프로젝트 팀원을 모집할때는 캠퍼스픽을 통해 구하는것도 나쁘지 않아보인다.

처음 협업을 하다보니 어떻게 무엇부터 해야할지 몰랐지만 일단 크게 3가지의 협업 방식이 있다고 생각한다.

첫번째는 깃허브다. 

위와 같이 한명이 레포지토리를 만들어 각각의 팀원들을 초대하고 그곳에 서버, 디자인, 웹, 안드로이드의 디렉터리를 생성후 각자의 브랜치를 만들어 서로 만나지 않을때는 그주차에 해당하는 작업량을 수행할때마다 자신의 브랜치에 push를하고 정기적으로 정해진 날짜에 맞춰 서로의 코드를 확인하고 문제가 없다고 생각될때 master브랜치에서 merge를 하는 식으로 협업을 진행하였다.

두번째 방식부터는 협업을 좀더 원활하게 해주는 역할이므로 깃허브가 필수 였다면 이제부터는 선택의 분야이다.

두번째는 노션이다.

노션은 개발자들의 협업 뿐만아니라 스타트업들도 각자 회사의 정보나 채용 공고를 보여주는데 많이 사용이 된다.

필자의 경우 크게 팀작업 공간, 개인작업 공간, 일정으로 나눈후 팀작업 공간에는 위와 같이 ToDo라는 페이지에서는 현재 프로젝트에서 진행해야할 업무를 나열하고 진행전, 진행중, 작업완료로 나눠 전체적인 진행 상태를 나타냈고

개인 작업공간에서는 팀원 각자의 진행률 페이지를 만들어 각자 작업상태를 나타내는데 사용하였다. 노션을 사용하는 가장 큰 이유라고 생각된다. 

세번째는 슬랙이다.

사실 필자의 경우, 대부분의 소통을 카카오톡으로 진행하기 때문에 아직까진 제대로 활용을 하지는 않고 있지만 주된 기능중하나가 코드를 가져올수 있어 피드백을 하는데 도움이 되고, 무엇보다 노션에서 변경사항이 있다면 슬랙에 즉각적으로 알림이 가기때문에 많이 사용한다고 생각된다. 이외에도 슬랙이 가지는 이점들이 많을 텐데 이건 조금씩 이용을 해보며 알아가봐야겠다. 

후기

사실 프로젝트 팀원을 필자가 처음 모집하였고 팀장이라는 직책을 가지고 있다보니 팀원들보다 협업의 방식에 대해 좀더 공부가 되어있어야 한다고 생각되서 알아본건데 무조건 위의 세가지 방식을 사용해라! 라기보다는 팀원들과 소통을 하며 각자에게 도움이 되는 방식을 적용시키는것이 가장 중요한것이라 생각된다. 위의 방식은 도구일뿐 협업에 있어서 가장 중요한것은 실제로 일어나는 소통에 집중을 하여야 한다는것을 잊어서는 안된다.