[프로젝트 진행하기 #3] 기획의 고도화

프로젝트 진행과정 3탄이다. 이번 포스팅에서는 2탄에서 한 기획을 바탕으로 고도화를 하는 과정을 간단히 다뤄보고자 한다.

 

🗨️시작하기전에

기획의 고도화가 왜 필요할까? 2탄에서도 말했지만, 명확한 기획이 아주 중요하다. 기획이 부실하면, 서로 이해한 내용이 다르고, 혼란스러워지고, 우리가 지금 하고 있는 프로젝트가 왜 필요한지 의문도 들 것이다.

 

💡Use Case 그려보기

Use case란 시스템이 사용자와 상호작용을 어떻게 하는지 방식을 설명하는 그림이다. 이를 통해, 서비스의 요구사항을 명확히 알 수 있고, 또한 사용자가 우리 서비스를 이용하는 시나리오를 알 수 있다.

 

위 그림은 제가 "국민대학교를 위한 스트리밍 플랫폼, Kwitch"를 개발할 때 그렸던 Use case Diagram이다. 이런식으로, 유저가 우리 서비스에 할 수 있는 행위들을 Use Case 로 그려보자. 그러면, 우리 서비스의 시나리오가 한눈에 보이고 기획이 더 쉬워진다. 이때, Use case는 정상적으로 처리되는 비즈니스만 그려야지, 예외처리까지 다 그리는 것이 아니다!!

 

🖊️ Domain Modeling

이제 Use Case Diagram을 통해서 우리 서비스의 전체적인 시나리오를 알았으니, 우리 서비스의 주요 Entity가 무엇이고, 그것들이 어떠한 관계를 갖는지 Modeling을 사전에 해둬보자. 이 작업이 왜 중요하냐면, Order라는 Entity가 있다고 해보자. 그런데 이 Order라는 것이 고객의 주문을 의미하는 건지, 순서를 의미하는 건지, 시스템이 내린 작업 명령을 뜻하는 것인지 개발자가 생각하기 나름이다. 이렇듯, 나는 A라는 의미를 생각했으나, 다른 사람은 B로 생각할 수 있다. 그래서, 사전에 이런 단어를 명확히 하는 것이 Domain Modeling의 핵심이다.

 

• 주문(Order)
  • 속성: 주문번호, 주문일, 배송지 주소, 총 금액, 상태(처리 중, 배송 중, 완료 등)
  • 관계: 하나의 고객(Customer)에 속하며, 여러 주문 항목(Order Item)을 가질 수 있음
• 고객(Customer)
  • 속성: 이름, 이메일, 주소, 전화번호, 회원 아이디
  • 관계: 여러 주문(Order)을 할 수 있음

 

위와 같이 Order라는 Entity에 대해서 명확하게 그 속성을 디자인하고, 다른 Entity와의 관계를 정의 해두는 것이다.이러면, 개발할 때 혼란이 없을 것이다. 실제로... 내가 이음 프로젝트를 진행하는데, 이 과정을 생략했더니 프론트와 백엔드 사이에서 혼란이 좀 많이 왔다. Domain Modeling의 필요성이 꽤나 느껴지는 순간이었다.

 

🖥️ 화면별 기능 정의

이제 우리가 운영할 서비스에 화면이 몇개 나오고, 각 화면은 어디서 어디로 이동하는지, 그리고 어떤 기능을 가지고 있는지 정의할 차례이다. 이 과정이 왜 중요하냐면, 디자이너와의 협업 때문이다. 디자이너와 함께 어떤 화면이 필요하고, 어떤 기능이 필요한지 정의해보자.

 

 

이런식으로, 디자이너에게 어떤 화면에는 어떤어떤 기능이 있고, 해당 화면에서는 어디로 이동할 수 있는지 문서로 정리해서 넘겨주면, 이를 바탕으로 이제 Figma로 UI를 제작하는 것이다.

 

📒 기술 스택 정하기 및 서비스 아키텍처 설계

자 이제 기획이 명확해지고, 어떤 기능이 들어갈 것인지 확실해졌으니 우리에게 맞는 기술 스택을 정하면 된다. 개인적으로, 이 부분이 꽤나 초심자한테 힘들 수 있다고 생각한다. 경험이 많이 없으면, 어떤 기술 스택이 필요하고 아키텍처를 설계해야되는지 정하기 매우 어렵기 때문이다. 이 부분은, 다른 프로젝트들을 참고 많이 하면서 스스로 깨닫는 수 밖에 없다고 생각한다.

 

개인적으로 살짝만 방향을 한번 잡아주자면

 

프론트

• 웹을 개발 할 것이다 : React, Vue.js 등을 이용한다.
• 앱을 개발 할 것이다 : 단지 커뮤니티 등의 가벼운 앱이다?(크로스 플랫폼) Flutter, React Native 등 : 핸드폰의 세부적인 기능을 많이 사용해되는 무거운 애플리케이션이다? (Android, iOS 따로 개발) Native Android, Swift 등

백엔드

• 빠른 개발을 지향한다 : Express, Ruby On Rails 등
• 체계적인 개발을 지향한다 : Spring (그런데 되도록이면 Spring 쓰는 것을 추천합니다.)
• AI가 주된 서비스이다 : FastAPI, Flask 등

진짜 개인적인 의견이지만, Django는 빠르게 개발하기엔 너무 타이트하고, 체계적으로 개발하기엔 Spring보다 별로고, 참 어중간한 프레임워크라고 생각한다. 진짜 개인적인 의견이다.

 

그외

• 배포 : Serverless인가? AWS Lambda를 이용한다. : 그렇지 않다? AWS EC2, AWS ECS 등 (일반적으로 AWS EC2를 이용합니다.)
• 사진, 파일 등을 저장할 공간 : AWS S3
• 데이터 베이스 : 관계형 데이터 베이스인가? MySQL, PostgreSQL 등 :No SQL이 필요한가? MongoDB :자주 접근하는 데이터라서 캐싱이 필요하다? Redis, Memcahced 등 :대용량 데이터를 고성능으로 처리가 필요하다? Apache Cassandra (학부 레벨에선 필요할리가...) → DB는 한 종류만 쓰는게 아니라 여러개 쓸 수도 있습니다.
• 컨테이너화 : Docker (그냥 업계 표준 수준)
• 테스트 도구 : Apache Jmeter, Locust, Ngrinder 등
• 도메인 연결 및 인증서 : AWS Route 53, 가비아 도메인(굉장히 저렴합니다), Certbot 등
• 리버스 프록시 서버 : Nginx
• CI/CD : Git Actions, Jenkins, ArgoCD
• 컨테이너 오케스트제이션 : Kubernetus, Docker Swarm
• 메시징 : Kafka, RabbitMQ (둘이 큰 차이가 있으니깐 알아보고 쓰십쇼)
• 검색엔진 : Elastic Search
• API 통신 : REST, gRPC
• API 문서화 : Swagger 등
• 로그 관리 : ELK Stack
• 인프라 모니터링 : Prometheus + Grafana, Datadog
• 인프라 스트럭처 : Terraform
• 애플리케이션 모니터링 : Jaeger
• 대규모 데이터 처리와 분석 : Hadoop, Spark

제가 유튜버 코딩애플님의 영상을 보다가 인상깊게 봤던 댓글이 있었다.

 

기술을 선택할 때는 필요성에 따라 기술을 추가해야된다. 아니면 위에 상황처럼 오버엔지니어링이 발생한다. 공부하려고 쓰는건 사실 상관없지만, 어쨋든간에 도입하기 이전에 필요성을 분명히 하고 도입해야됨을 명심해라!! 중요한 것은, 기술이 추가되면 추가될 수록 유지 보수 해야될 부분이 늘어난다!! 

 

그럼 이제 기술 스택을 다 정했으니, 전체적인 서비스가 진행될 아키텍처를 그려보자.

저는 Draw.io라는 툴을 이용하여 그렸다. 해당 아키텍처는 제가 진행했던 외국민 서비스의 아키텍처 이니다. 해당 아키텍처에 대한 자세한 설명은 해당 글을 참고 바란다.

 

참고로 아키텍처는 필요성에 따라 변경될 수 있으니, 지금은 약간 전체적인 틀만 잡아놓는 다는 느낌으로 하면 좋겠다.

 

📜 문서화는 어디부터 어디까지?

문서화는 도대체 어디부터 어디까지 해야될까? 이건 사람마다 다르겠지만 내 개인적인 의견을 적어보겠다.

 

우선 이 두가지는 반드시 문서화가 필요하다. 기획에 대한 모든것과 회의록. 이 두개는 전 글에서도 문서화를 강조했으니 생략하겠다. 그러면 이제 나머지 문서화에 대해 알아보자.

 

• Git Conventon : 우리들의 Git Convention에 대해서 문서화 정리는 필수이다. 협업할 때 Convention 아주 중요하다. Git Convention에 대해서는 이 시리즈 5화에 다룰 예정이다.
• Code Convention : 변수 네이밍을 CamelCase로 할 것인지, 함수명은 어떻게 할 것인지 등등 전반적인 코드에 대한 컨벤션이다. 또한, 우리 Spring 버전은 무엇인지, Project 빌드 도구는 Gradle인지 Maven인지, 자바 버전은 무엇인지, 패캐지 구조는 무엇을 따를 것인지 이런 것들을 문서화 해두자.
• 계정 : AWS 계정, RDS 계정 등 다같이 쓰는 팀의 계정 정보를 문서화 해두면 좋다. (그대신 신뢰관계가 있어야...)
• 개발 참고자료 : 개발에 관련된 참고자료를 문서화 해두면, 나중에 비슷한 내용의 문제가 발생했을 때 빠르게 찾을 수 있어서 좋다.
• Secret : ENV로 따로 관리하는 환경 변수들을 문서화 해두자. 그리고, ENV가 추가됐을 때 꼭 업데이트하자.

문서화는 이 정도면 충분하다고 본다. 개인적으로, 자주 업데이트 해야되는 부분에 대해서는 문서화를 지양하고 다른 방법을 모색하는 편이다. 예를 들어서 API 문서를 싹다 문서화 해본다 가정해보자. 그런데 API 명세는 개발 과정에 따라 자주 바뀔 것이다. 그러면 그때마다 새로 업데이트 해주고, 굉장히 시간을 많이 잡아먹는다. 또한, 최신화가 되지 않는다면 굉장히 치명적이다. 이런식으로, 자주 업데이트 해야되는 부분은 문서화를 최대한 지양하고, 다른 방법을 모색하자. 예시로 몇가지를 들어보겠다.

 

• API 문서화 : Swagger 같은 것들을 사용하자. 자동으로 우리 API 문서를 만들어주고, 최신화까지 해준다. 또한, 웹에서 바로 API 테스트까지 가능하다.
• 해야될 일 목록 : Git에 Issue 기능을 활용하자. commit 메시지에 #45 이런식으로 Issue 번호 넣으면, 자동으로 내역에 추가되기도 하고, PR을 쓸데 연관지을 수 있어서 훨씬 좋다. 이 내용은 추후 자세히 다룰 예정이다.
• 작업 현황 : Git에 Project 기능을 활용하자.