포트폴리오 주간 프로젝트 1주차 기획 중간점검

 

다음주 월요일 일과 시작 전까지 마감해야 하는 포트폴리오 프로젝트 기획 주간의 절반이 지나갔다. 지금까지 어떤 것들을 했고, 그 과정에서 어떤 것을 느꼈고, 남은 시간 동안 해야 할 것들에는 무엇이 있는지 돌아본다.

 

지금까지 한 것들

첫 UI 프로토타이핑

1기 모든 동료들과 도장에 모여서 각자 구현하고 싶은 애플리케이션의 주제를 정하고 어떤 기능을 갖는지 고민했다. 동시에 종이에 애플리케이션이 화면에 나타날 때의 내용들을 가볍게 적어보는 UI 프로토타이핑을 했다. 애플리케이션의 최소 조건은 네이버 카페와 같이 복잡한 도메인 구조를 갖거나, 구현하기 위해 도전적인 기술을 다뤄야 하는 기능이 있는 애플리케이션이었다.

 

처음에는 지도 도메인을 중심으로 가져가는 애플리케이션을 만들어보고 싶다고 생각했었고, 내가 잘 아는 도메인 중 어떤 도메인을 지도와 결합해볼까 생각했다. 야구가 떠올랐다. 야구와 같은 스포츠 경기를 하고 싶은 사람이 지도를 보면서 팀을 찾아 참가하고, 팀의 인원이 모두 차면 다른 경기를 매칭해주면서 장소까지 대여할 수 있는 애플리케이션을 생각해 대략적인 UI 프로토타이핑을 종이에 작성해나갔다. 월요일까지 약 3일의 시간을 소요해 사용자 관점에서의 UI 프로토타이핑까지 작성했다.

 

기능 리스트업 작성

UI 프로토타이핑으로 나타나는 애플리케이션의 결과 화면을 바탕으로 어떤 기능이 들어가야 할지 기능을 리스트업했다. 각 UI 화면의 제목을 기능의 제목으로 두고, 간단한 설명과 함께 UI 화면에 나타나는 내용의 조건들을 위주로 서술했다.

 

기능 구현에 필요한 기술 스택 조사

이번 프로젝트 과제는 그냥 애플리케이션을 구현하는 것이 아니라, 애플리케이션을 구현하기 위해 사용하는 라이브러리나 프레임워크의 기술 스택을 선정하고 그 이유를 제시해야 했다. 그래서 우리가 배운 프로그래밍 언어와 프레임워크들을 왜 이번 프로젝트에서 사용하는지 기술적 근거를 찾고, 다른 라이브러리나 프레임워크 대비 어떤 점이 유리한지를 찾기 위해 프론트엔드, 백엔드, 데이터베이스 등 여러 라이브러리들과 프레임워크들을 조사했다.

 

 

어떤 부분이 어려웠나?

노아 트레이너님께서 애플리케이션을 정할 때 자신이 잘 아는 도메인을 선정해야 한다고 하셨다. 처음에는 자신이 관심 있고 좋아하는 도메인이라면 충분하지 않을까 생각했었다. 평소에 야구를 자주 보는 편이긴 하지만 직접 야구 경기에 참가하기 위해 매칭 서비스를 이용해본 경험은 없었다. 그러다보니 생각했던 부분과는 달리 상황 상 충돌이 일어나는 부분이나, 직접 리스팅을 하기까지는 생각나지 않았던 내용들이 프로토타이핑이나 기능 목록을 작성하는 중간중간 나타났다.

 

기술 스택을 조사할 때는 설득을 위해 논리를 어느 깊이까지 들어가면서 펼쳐야 하는지 어려움을 겪었다. 과정에서 배웠던 프론트엔드 라이브러리 React와 백엔드 프레임워크 Spring의 특징은 무엇이고 어떤 이점이 있는지, 다른 라이브러리나 프레임워크 대비 유리한 점이 무엇인지 React나 Spring은 가지고 있다는 근거를 드는 식으로 기술 스택 선택의 논리를 가져가고자 했었다. 문제는 React나 Spring만이 가지고 있을 것이라고 생각했던 기술 상의 이점들은 다른 라이브러리/프레임워크도 가지고 있는 경우가 많았다.

 

오늘 오후에 팀원분들과 노아 트레이너님과 자리를 갖고 기획 프로세스의 예시를 보면서 남은 시간 동안 무엇을 해야 할 것인지 방향을 잡는 시간을 가졌다.

 

기획에 참고할 내용

 

 

앞으로 해야 할 것들

지금까지 정의한 기능을 포트폴리오의 목적에 맞도록 재구성 >> 2차 UI 프로토타이핑 작성

첫 날 주제를 선정하고 기획을 시작할 때, 이번 포트폴리오 프로젝트의 결과로 실제 배포 혹은 출시가 이뤄질 수도 있음을 고려하고 있었다. 그래서 UI를 프로토타이핑하고 기능을 리스트업하면서 '모집글로 사용자를 모을 때, 사용자를 먼저 다 모으고 장소를 대여하는 게 맞는가? 아니면 먼저 장소를 대여하고 사용자를 모으는 게 맞는가?'에 대해 무엇이 맞는 것인지 고민한 부분이 있었다.

 

이제는 포트폴리오의 목적이 애플리케이션을 실제로 출시하는 것은 아님이 명확해지다 보니, 해당 부분에 대한 고민을 계속 이어가기보다는 관련된 동작 자체를 다시 정의하는 쪽으로 방향을 선회해야겠다는 생각이 들었다.

 

동작을 다시 정의해보고, 노아님께서 얘기해주셨던 종이에 프로토타이핑하는 것과 웹 화면에서 프로토타이핑하는 것을 교차로 작성하면서 UI 프로토타이핑을 구체화해 볼 계획이다.

 

추가적으로 현재 정의된 사용자 관점에서의 기능을 관리할 수 있는 관리자 관점에서의 기능을 정의하고 프로토타이핑을 진행해보려 한다.

 

각 사용자 스토리마다의 가치 제시

사용자의 입장에서 이 애플리케이션을 쓰는 이유를 생각해봐야 한다. 사용자의 입장에서 애플리케이션의 기능을 사용할 때 어떤 가치를 얻을 수 있을지 생각해보는 과정이 필요할 것이다. 예를 들면 현재 구상하고 있는 기능 중 '상대 팀 매칭하기'의 기능이 무엇인지 스스로 확신이 잘 서지 않는 상태이다. '상대 팀 매칭하기' 기능을 통해 사용자가 어떤 가치를 얻을 수 있는지 고민해보면서 가치로부터 기능을 도출해볼 계획이다.

 

프로세스 구조도 작성

UI 프로토타이핑과 기능 리스트업을 바탕으로 동작과, 동작에 따른 화면 표출을 구조도로 나타내는 과정을 진행할 예정이다. 구조도를 작성할 때 '액션'이나 '조건'을 구조도에 포함시킬 것인지는 고민 중에 있다. 가능한 많은 내용을 전달할 수 있어야 할까? UI와 동작만을 나타내는 것으로도 충분할까?

 

기술 스택을 선정한 이유를 구체화하고 범위 나누기

이번 프로젝트는 출시와는 관련은 없지만, 복잡한 구조의 도메인의 상호작용 및 도전적인 기술의 사용이 목표가 되는 프로젝트이다. 즉 애플리케이션의 테스트 역시 충분히 많은 양의 데이터를 임의로 삽입해 테스트를 진행하는 부하 테스트가 이루어질 수도 있다. 따라서 마주하게 될 상황을 가정하는 방식으로도 기술을 선택한 근거를 확립할 수 있을 것이다.

 

한편 기획서의 내용 제안은 개발자뿐만 아니라 비개발자도 확인할 수 있는 사항이고, 기술적인 내용만으로는 비개발자가 기술 스택의 선정 이유를 보더라도 이해하지 못할 수 있다. 뿐만 아니라 기술의 사용 동향, 시장 상황, 인지도 등의 이유도 기술을 선택하는 주요 이유가 될 수 있으므로, 비기술적인 이유도 기술 스택에 일정량 추가된다면 논리 근거 확립에 도움이 될 것이라 생각한다.