소프트웨어 개발 사이클

개인 프로젝트를 했었던 경험들을 보면서, 한가지 놓치고 있었던 점이 있었다.

그것은 기능정의 없이 냅따 맨바닥 헤딩식을 개발을 해왔던 경험이다.  나중에 다른 개발자와 협업을 했을 때, 혼란이 올 것이라는 생각이 있었다. 그래서 오늘은 개발을 하기 전 기능 정의를 어떻게 진행하는가에 대해 알아보려고 한다.

 

무조건 아래의 Step을 따르라는 법은 없지만, 대부분 사용하고 있는 순서이기 때문에 참고해서 적용하길 바랍니다.

 

프로젝트 순서도

 

Step1. 아이디에이션

먼저, 프로젝트의 목적과 목표를 설정해야한다. 팀원들의 아이디어를 모아 브레인스토밍과 같은 아이디어 기법으로 무슨 프로젝트를 할 것인지 생각하고 백엔드와 프론트엔드의 기술 요구사항을 고려해 프로젝트를 기획해본다. 보통 이 단계에서도 툴이나 스택을 결정하는 경우도 있다.

• 목표 설정 : 보통 어떤 문제를 해결할 것인지와 어떤 서비스를 제공할 것인지 측면에서 목표를 설정한다.
• 브레인스토밍 : 아이디어를 제시할 때, 필요한 방법으로 가능한 모든 아이디어를 모아낸다. 브레인 스토밍이외에도 48가지 이상 아이디어 발상법이 있으니 참고하길 바란다.

목적
새벽에 운영하는 술집을 찾기 쉽도록 한다.

메인 타겟 유저
새벽까지 연인 혹은 친구와 데이트를 하거나 야식을 먹고 싶은 사람들을 위해

 

Step2. 기능 명세

이 프로젝트를 하려면 무엇이 필요한가?를 생각하여 프로젝트의 기능을 정의한다. 백엔드가 필요하는 기능과 프론트엔드가 필요로 하는 기능을 나누어 API 엔드포인트와 데이터 구조를 어떻게 작성할지 논의한다.

• 요구사항 분석 : 시스템이나 서비스에 대한 기능적 요구사항과 비기능적 요구사항을 명확하게 정의한다.
• Use Case 정의 : 각 사용자 그룹들이 프로젝트를 어떻게 사용할지 정의한다.
• 필수 기능과 선택 기능 구분 : 필수 기능과 선택(부가적인) 기능을 나누어 우선순위를 정한다.

 

경우에 따라 다르겠지만, 개인 프로젝트에서는 `.rst` 파일에 작성하는 경우도 많다. 만약 협업을 한다거나 `.rst`에 친숙하지 않은 사람들도 있으니 Notion이나 Github Disscussion, Google Spread Sheet를 사용하는 경우도 있다.

 

보통 기능을 정의할 때 기능 명세서 혹은 기능 정의서를 작성한다고 한다. 이는 어떻게 개발할지를 정의하는 것이다. 기능명세서는 구체적일수록 좋은데 개발자가 기능 명세를 작성할 때 중요한 팁들이 있다.

 

• 스토리 보드를 통해 보충 설명을 할 수 있게끔 만들어야 한다.
• 개발자가 충분히 이해할 수준으로 작성해야하며 완성된 모습을 상상할 수 있어야 한다.
• 커뮤니케이션의 빈도를 줄이기 위해 구체적으로 작성하는 편이 좋다. 

만약 복잡한 앱을 만들지 않을거라면 `IA`를 작성할 필요는 없다. IA는 개발 영역을 나누거나 복잡한 화면을 관리하기 위해 작성하는데 규모가 작은 프로젝트는 많지 않으니 넘어가도 되는 부분이다.

 

Reference

https://mklab-co.medium.com/작성법-화면흐름도-screen-flow-chart-와-ia-information-architecture-2a3facc3bf96

https://minery.tistory.com/8

 

Step3. WireFrame, UXUI 작성하기

주로 프론트엔드 개발자가 UXUI 디자이너와 협력하여 화면 설계와 와이어 프레임을 작성한다. 그리고 백엔드 개발자는 프론트엔드 개발자와 어떤 데이터가 필요한지 API 요청과 응답을 검토한다.

대표적인 와이어프레임 도구로 Miro나 whimsical , Adobe XD 등이 있다.

 

• 화면 설계 : 화면 구성과 디자인을 결정한다.
• 프로토 타입 : 이해관계자(Stakeholder)들끼리 프로토타입을 제작한다. 물론 사용자의 피드백도 중요하다.

Step4. API 및 데이터베이스 설계

백엔드 개발자는 프론트엔드가 필요로 하는 데이터를 고려해 API를 설계한다. 그리고 데이터베이스 모델링을 위해 데이터베이스 스키마(Schema)를 정의하고 API의 엔드포인트를 작성한다.

 

• API 설계 : 백엔드 개발자가 프론트엔드 개발자에게 데이터를 어떻게 제공할지 정의한다. RestfulAPI 설계를 고려하거나 GraphQL를 고려해 설계한다.
• DB 모델링 : 데이터베이스 스키마를 정의하고 각 테이블의 관계를 설계한다.
  • 보통 ERD 툴을 많이 사용하는데 GitMind, Draw.io, ERDCloud, DBDiagram 등 다양한 무료 도구들이 있다.
• API 문서 작성 :  API의 엔드 포인트나 메서드, 매개변수 등을 문서화하여 개발자간 소통을 원활하게 합니다.

DB 모델링

ERD

 

대강 와이어프레임이 완성되면 이에 맞춰 DB와 API 명세를 시작한다.

• ERD를 설계할 때, 주의할 점이 있는데 우선, 어떤 DB를 사용할지 먼저 선택해야한다. 각 DB마다 장단점이 존재하니 사전에 미리 알아두고 판단하는 것이 좋다.
• `char`과 `varchar`의 차이를 명확하게 알아두자. 이 둘은 고정형이냐 가변형이냐의 차이인데 속도를 생각해서 `char`를 사용하는게 좋지 않은가할 수 있겠지 고정형이라 공백이 생겨 메모리 낭비가 생길 수 있는 단점도 있다.

API 문서 작성

API 문서를 작성하는 이유는 근본적으로 API가 왜 필요한지 부터 적용해보면 좋다. 백엔드 개발자는 API에 맞게 기능을 구현할 것이고 프론트엔드 개발자는 API를 통해 어떤 값을 가져와 화면을 구성할지 문서를 통해 알 수 있기 때문이다.

 

API 문서 예시

예를들어서, Django를 이용해 프로젝트를 진행한다고 가정했을 때 프론트엔드와 백엔드 끼리는 Notion API 문서로 서로 소통을 하고 백엔드 개발자 끼리는 `swagger`나 `drf_yasg`를 통해 서로 공유할 수 있다.

 

Django Swagger와 drf_yasg

 

💡 ERD(Entity-Relation Diagram)
개체 속성과 개체 간 관계를 그림으로 표현한 것이다. ERD를 작성하지 않으면 협업할 때 어떻게 어떤 방식으로 설계했는지 매번 확인해야하기 때문에 어려워진다.

 

 

Reference

https://velog.io/@director20844/ERD-작성하기

 

Step5. 일정 및 마일스톤 설정

프론트엔드 개발자와 백엔드 개발자가 일정을 조율하며 각 단계에 대한 마일스톤(MileStone)을 정의한다.

Github에서는 이슈들을 하나로 모아 일정 관리를 할 수 있는 마일스톤 기능을 지원한다. 개발 목표에 대한 마일스톤을 만들어 두고 관련 이슈들을 생성하면 Open / Close로 프로젝트의 진척상황을 퍼센트로 보여준다. 

Step6. Coding with Test

이제부터는 데이터 구조와 API에 맞춰 코드를 작성해야한다. 서로 코드 리뷰를 오가며 코드를 개선해나간다.

코드를 작성하면서 테스트 또한 안정성을 위한 중요한 작업이다.

테스트에는 기능 테스트, 유닛테스트(단위테스트), 통합 테스트로 나눈다.

• 기능 테스트 : 사용자 관점에서 애플리케이션 외부를 테스트하는 것을 의미하며 상위 레벨의 개발 주도 방식이다. `Selenium`으로 웹 브라우저에서 제대로 동작하는지 확인할 때 쓰인다.
• 유닛 테스트 : 개발자 관점에서 애플리케이션 내부를 테스트하는 것을 의미하며 하위 레벨의 개발 주도 방식이다. 모듈의 동작을 테스트할 때 사용된다.  모델 개체를 생성하면 개체 수가 맞는지 확인할 때 쓰인다.
• 통합 테스트 : 유닛 테스트와 비슷한 점이 있으나 다른 컴포넌트나 모듈이랑 통신할 때 제대로 통신이 되는지 확인하는 테스트이다. 

테스트를 할때 다양한 테스트 패턴을 사용해 개발을 하게되는데 그 중 대표적인 두가지 패턴이 있다.

 

BDD(Behavior Driven Development)

행위 주도 개발은 TDD에서 파생된 개발 방법으로, 시나리오를 바탕으로 개발하는 방식을 의미한다. 행위 주도 개발은 시나리오를 중심으로 개발하기 때문에 함수 단위로 테스트를 하지않고  Feature, Scenario, Given, When, Then 방식으로 개발한다. 자세한 내용은 이 포스팅에서 다루지 않겠으나 아래 파이콘 2019년 영상을 참고하면 좋을 것 같다.

 

 

TDD(Test Driven Development)

테스트 주도 개발은 실패하는 테스트를 작성 후 최소한 코드로 테스트를 실행한 후 리팩토링을 수행하는 방식이다. TDD 방식을 사용하면 디버깅을 하는 시간이나 원인 파악이나 좋은 방법이지만 개발 속도를 느리게하고 예외가 생길 수 있다는 단점이 있다.

 

 

Reference

https://media.fastcampus.co.kr/knowledge/dev/tdd/

https://youtu.be/3CfxhnDjtQQ?t=866&feature=shared

 

Step7. Release

프로젝트가 종료되면 배포를 진행하고 이 프로젝트에 관한 유지보수 계획을 세운다.

그리고 유지보수를 진행하면서 해당 프로젝트를 개선해나간다.