새로운 프로젝트 시작: 개요와 목표

🚀  새로운 프로젝트 시작

지난 여름에 정말 마음이 잘 맞는 동료들을 만나서 너무 즐겁게 진행하던 프로젝트가 있었는데, 취준/해외/직장 등 다들 시간적 여유가 없어 흐지부지 되었더랬다. 그냥 알고리즘에나 집중하자 하고  근 한두달간 공부 중이었는데, 우연히 새로운 프로젝트를 시작하게 되었다.

DRF 기반의 backend API 설계와 서버 구축을 맡을 예정이다.
프로젝트 시작 전에 내가 이 프로젝트 경험을 통하여 지식적으로 성장하고자 하는바와 목표에 대하여 기술해보려한다.

 

💥  목표 설정하기

1. 정규화 규칙을 따르는 DB 설계

현업에서 일해본 경험이 없어서 좋은 DB구조/확장성 있는 설계에 대한 정확한 기준은 세울 수 없지만 스스로 설정한 규칙을 지키면서 모델링을 진행해보려 한다. (보통 정규화 3단계까지를 프로덕션에 많이 적용한다고 한다) 초기 설계 이후, 개발을 진행하며 마주하는 비정규화, transaction 등의 문제를 개선해나가며 발전시킬 예정.

 

2. 로그 시스템 사용

이전 프로젝트에서는 .txt 파일로 요청 로그를 남기는 방식을 사용했었다.
로그 시스템을 설계한 것은 아니었기 때문에 서버에 직접 열어가서 로그 파일을 뜯어보지 않는 이상, 어떠한 에러가 발생했는지 파악하기가 어려웠다. 그래서 프론트엔트 팀원분과의 즉각적인 소통에서 어려움을 겪었었다. 에러 응답이 날아오면, 팀원분이 나에게 메세지를 보내고.. 나는 한참 뒤에 확인하고... 그러면 팀원분의 작업속도는 느려지고.. 협업이 더뎌지고... 뭐 그런.
구글링해보니 에러 로그 시스템으로는 Sentry 가 가장 많이 쓰이는 듯하여, 이 툴을 사용해볼 예정이다.

Integrating Sentry Application Monitoring - PyCharm Guide

 

3. TDD 개반의 개발

Postman으로만 동작 여부를 검증하고, 이후 프론트 단에서 이상적인 서비스 유저 플로우에 대한 테스트(happy path testing이라 한다)만 진행하며 개발을 해왔다. 버그가 발생한 경우는, 깨진 부분에 코드를 덧붙이는 방식으로 오류를 해결했었다. 코드의 재사용성이 떨어지고 언제 어떠한 케이스에 대하여 에러가 발생할지 예측할 수 없어 불안정했다.
이번 프로젝트에서는 반드시 테스트 코드를 작성하여 TDD 기반의 개발을 진행하려 한다. (일단 깃허브에 issue부터 생성해둔다ㅎ 계속 눈에 밟혀서 미룰 수도 없게 만들어버릴 거다)

 

4. 배포 자동화

CircleCI나 AWS CodeDeploy를 사용하여 CI/CD 파이프라인을 구축해볼 것. 
이전 프로젝트는 정립된 배포 프로세스 없이 docker 컨테이너만 돌아가고 있는 구조였다. 새로운 PR이 merge되면, 갑자기 컨테이너가 터지기도 하고 로그가 다 날아가기도 하고 뭐 그랬었다. 그 때는 docker의 개념을 익히는데도 급급했기에 새로운 툴을 도입할 여유조차 없었던 것 같다.
제대로된 배포 프로세스를 구축해보고 싶다. 이 부분에 대해서는 내 지식이 그리 깊지 않다고 판단되어, 조금 더 공부한 뒤에 구체화하는 것으로.

 

5. API 문서 자동화

자동화된 API 문서를 관리할 것.
별도의 문서를 통해 관리하면 동기화가 제때제때 되지 않아 프로젝트의 생산성이 저하된다. 노션 테이블로 처음 api 문서를 작성한 순간부터 이러한 문제를 느껴서 바로 도입했었다. 개인적으로 커스터마이징이 용이하여 swagger보다는 drf-yasg를 선호한다.  field-level, response format/error까지 커스터마이징했던 예시이다. 저 세상 가독성을 자랑한다... 너무좋아

 

6. git issue와 PR을 통한 task 관리

github내에서 issue와 PR을 활용하여 task를 체계적으로 관리할 예정이다. 이건 이미 하고 있다. 순차적으로 task를 처리하기에도 용이하고 구조화하기도 매우 좋은 것 같다. 별도의 문서(노션)을 이용하면 종종 코드 상의 진행상황과 동기화가 되지 않을 때가 있었는데 그럴 일이 없다는 것도 큰 장점이다.
추가적으로 Project의 칸반차트도 사용중인데 아주 직관적이고 마음에 든다. task가 쌓일수록 진가를 발휘할 것 같다.

 

task 기반의 issue를 생성, label 지정	issue기반의 PR생성	칸반차트(todo, inprogress, done)

 

7. 개발 환경 및 코딩 컨벤션에 대한 팀규칙 설정하기

필수다. 핵심만 가지고 가기로 했다.
리뷰를 활성화하고 싶지만, 팀원이 프론트1+백2으로 구성된지라 쉽지 않을 것 같아서 우선 통신규약, github 사용규칙, django 코딩컨벤션에 대해서만 문서를 작성하였다.

 

8. 크고 작은 의사결정 과정에서 확실한 근거 세우기

구글에 쳐보니 대부분의 사람들이 이러한 방향으로 진행하길래, 단순히 이 기술을 사용해보고 싶어서 등등
타인에게 '내가 세운 논리의 흐름'을 말로 설명해낼 수 없는 의사결정은 하지 않으려고 노력하려 한다. 계속 질문을 던져야 한다!

'툴/모듈을 도입한 이유는 무엇인가'
'쿼리를 어떻게 짜야 수행시간을 최적화할 수 있을까'
'리팩토링이 필요하다고 생각한다. 왜? 코드의 가독성이 떨어지는가? 불필요한 쿼리가 있는가?'
'내장 모듈을 사용한다고 할 때, 장고가 제공하는 기능을 100분 이해하고 내가 원하는 대로 커스터마이징할 수 있을 것인가'
'과연 이 코드는 파이선이라는 언어의, 장고라는 프레임워크의 특장점을 잘 반영했다고 볼 수 있는가'

 

👩🏻‍💻  잘해보자!

무언가를 새로 만들어나가는 과정은 늘 사람을 설레이게 한다.
이번 경험을 통해서 또 나는 새로운 것들을 배우며 수많은 난관들을 마주하고 또 극복해나갈 것이다.
쉽진 않겠지만! 다시 새로운 동력을 얻을 수 있게 되어 기쁘다.