그럼에도 불구하고

들어가며

지난 포스트에는 개발방법론과 이를 실현하기 위한 툴들에 대한 내용을 작성하였다. 이번에는 새로운 프로젝트에서 문제를 정의한 과정에 대해서 알아보도록 하겠다.

1. 시작

교수님께서 소개해주신 스타트업 대표님과 개발팀장님께 자문을 받았을 때 가장 인상깊었던 말씀은 클라이언트, 팀원들 간의 생각 차이를 줄이는게 가장 중요하다는 것이었다. 자세히 말하면 같은 내용을 얘기하고 있어도 미묘하게 비즈니스 로직이나 유저 스토리에 대한 이해에 차이가 발생할수 있으며 이를 바로잡지 않으면 나중에 개발을 진행할 때 문제 정의로 회귀하여 다시 개발을 진행할 수도 있는 나비효과가 발생한다는 것이었다. 따라서 이번 프로젝트에서는 생각 차이를 줄이는데 집중하여 아래와 같이 3가지 문제정의 방법을 사용하고 검증했다.

2. User Story

가장 처음에는 영상의학과 교수님들과 대학원생 분들과의 미팅에서 구현되었으면 하는 요구사항을 정리하고자 User Story를 아래와 같이 작성했다.

각자의 User Story에는 개발 시 구현 방안을 간단하게 노트로 작성했고 구체적인 내용을 테스크로 정의하고 내부 페이지에 작성하였다.

3. 디자인

이 후에는 User Story를 바탕으로 디자인 초안을 작성했다. 이를 작성할 때는 Figma를 선택했는데, 그 이유는 Kakao oven, Sketch 등과 달리 Google에서 사용하는 다양한 Material UI Component를 무료로 이용할 수 있었기 때문이다. 그리고 Material UI Component를 사용한 이유는 향후 프론트 프레임워크를 React를 사용할 예정이었는데 React MUI 라이브러리에 이미 Material UI를 준수하는 Component들이 만들어져 있어 디자인보다 로직에 집중 할 수 있었기 때문이다. (실제로 1.0.0 버전의 프론트 코드에는 CSS와 관련된 코드가 거의 작성하지 않아 로직에 집중된 코드를 작성할 수 있었다.)

또한 디자인을 통해서 다시 클라이언트와 소통할 때, 잘못 이해한 User Story를 바로잡을 수 있었고 개발 방향을 다시 점검 할 수 있었다.

4. 비즈니스 로직

본인은 이 부분이 문제정의에서 가장 중요한 부분이라고 생각한다. 왜냐하면 개발 코드를 작성하는데 직접적으로 연관이 있기 때문이다. 유즈케이스 다이어그램과 비슷하게 비즈니스 로직을 UML로 구성하였는데 이 부분에서 효율적인 개발을 위한 토론이 가능했고 또 역할 할당이나 협업 방식등을 정리하기에도 수월했다. 그리고 디자인에서도 점검한 유저 스토리에 대한 논리적인 오류를 발견하여 개발전 빠른 조치까지 가능했다. (나중에 개발을 할 때, 이 부분은 무슨일이 있어도 작성해야겠다고 다짐했다.) 또한 한눈에 프로그램의 동작과정을 파악 할 수 있었기 때문에 개발 팀원들간의 생각 차이를 줄이는데도 한몫했다.

UML형태로 작성한 비즈니스 로직의 또 다른 장점은 확장성이다. 애자일 형식으로 개발할 때는 스프린트 형태로 주마다 새로운 기능을 추가하는 형태로 개발했는데, 이 때 UML 컴포넌트를 기존의 비즈니스 로직에 추가하여 쉽게 확장 내용을 기술 할 수 있었으며 다시 논리적인 오류를 검증하여 기존 기능과의 병합을 안정적으로 진행할 수 있었다.

5. 후기

유저 스토리, 디자인 그리고 비즈니스로직을 작성하면서 클라이언트의 요구를 점검하는 과정들을 통해 실제 프로젝트를 개발하는데 오류를 줄이고 개발방향을 확고히 함으로써 코드 재작성이나 수정 과정을 대폭 줄이는 효과를 얻을 수 있었다. 그러나 이런 과정도 완벽하지는 못하다. 중간까지의 개발과정에서 클라이언트의 요청이 아예 변경될 수도 있기 때문이다. 실제로 그런 경우가 있었고 이미 작성한 기능을 삭제하거나 수정해야 했다. 앞으로는 이런 상황에도 대비하기 위한 문제정의 방법을 계속 공부하거나 개발해야 할 것 같다.