해커톤
1차 스프린트가 끝나고 다음 주 월요일부터 화요일까지 해커톤을 진행하게 되었다. 1박 2일동안 빠르게 MVP 기능을 구현해보게 되었다. 이번에 MVP에 구현할 목록은 모임 목록과 모임 등록 페이지이다. 우리가 생각했을 때 결국 서비스에서 제일 기본적으로 필요한 기능은 모임을 만들고 신청하는 기능이라고 생각한다.
그래서 이번 2차 스프린트의 MVP를 모임을 신청하고 참여하는 기능을 구현하는 것으로 계획을 세웠고 이번 1박 2일 동안 구현할 기능은 모임을 생성할 수 있는 기능이다.
구현을 시작하기 전, 역할 분담을 어떻게 진행해야할 지 회의를 진행했다. 두 가지의 방법이 있었다.
첫번째는, 페이지 별로 구현하는 것이였다. 역할 분담을 비교적 쉽게 할 수 있다는 장점이 있지만 중복된 컴포넌트를 구현할 수 있는 문제가 있었다.
두번째는, 기능 단위로 구현하는 것이였다. 역할을 레이아웃, 컴포넌트, API 통신 별로 나누어 구현하는 방식으로 작업이 중복되는 부분을 최소화할 수 있는 장점이 있지만 서로의 구현 사항을 취합하는데 리소스가 더 필요하다는 문제가 있었다.
이번 스프린트에서 선택한 방식은 두번째 방식이였다. 같은 팀원의 크루가 말하길 페이지별로 작업하는 방식은 SI업체에서 진행했던 방식이었어서 기능 단위로 구현하는 방식을 경험해보고 싶다는 것이었다. 그 의견을 수용하여 구현해야할 기능을 목록화하여 이를 각각 레이아웃, API 통신, 컴포넌트 단위로 분리하였다.
내가 이번에 맡은 역할은 컴포넌트를 만드는 것이였다.
다음과 같은 컴포넌트를 만드는 것으로 어떻게 하면 재사용 가능하게 만들 수 있을까 고민을 하였다.
특히 모임 생성 페이지에서 인풋을 만들 때, 인풋을 재사용하는경우가 많았다.
다음과 같은 경우로 사용하기로 하였는데 input type에 따라 재사용 가능한 것으로 보았다. 그래서 LabeledInput 컴포넌트를 만들어 props로 input 타입을 확장하여 받았다. 또한 타입스크립트의 Record를 사용하여 객체 배열로 input을 만들었다.
다음으로 + 버튼과 등록하기 버튼이 있었다.
이 두 버튼을 하나의 컴포넌트로 구현한다면 재사용성을 높일 수 있다고 생각했다. 그래서 Button의 Props로 type을 받았다. 타입은 2개로 'bar'타입과 'circle'타입으로 나누었다. 이를 통해 css props를 사용하여 css 분기 처리를 진행했다.
드디어 직접적으로 개발의 첫 발을 띄었다. 비록 11시에 퇴원하긴 했지만 1박 2일동안 개발에 몰두했다고 생각했다. 이번 개발을 진행하면서 필요했던 부분이 있다
- 이슈와 PR 컨벤션 : 문장형으로 사용할지/ 단답형으로 사용할 지, prefix가 필요할 지 의논이 필요했다.
- 도메인 용어 통일: 현재 정확한 도메인 용어가 정해지지 않아서 혼동되는 경우가 발생했다.
이런 안건은 회고를 통해 팀원과 합의를 하여 추가로 정했다. 협업 과정에서 통일성이 중요하다는 것을 다시 느낄 수 있었다.
특히 도메인 용어 같은 경우, 비슷한 기능이 비슷할 경우 도메인 용어가 확실히 정해지지 않으면 서로 다른 말을 하는 경우가 발생했다.
2-2차 스프린트
이번 2-2차 스프린트 계획은 모임 상세페이지를 만드는 것이다. 모임 상세 페이지를 만드는 것이다. 모임 상세 페이지에는 모임에 대한 상세 정보, 참여자, 참여 버튼이 존재한다.
내가 이번에 맞은 역할은 네트워크(API)연결과 리액트 라우터를 이용한 navigate로직 구현이다.
이번 부분은 내가 해야할 일이 많지 않았다. 그래서 추가적이 설정을 진행했다.
이번 프론트엔드 요구사항중에 AWS를 이용한 배포가 있었다. 처음에는 S3와 cloudfrount를 이용해서 정적페이지를 배포할 생각이었다. 문제는 여기서 발생했다. github action을 이용해서 cd를 구현하고자 했지만 권한문제로 IAM의 AccessKey를 사용할 수 없었다. 1차적으로 개인 도커로 배포하고 ec2에서 배포된 도커 이미지를 가져온 다음 nginx를 통해 정적 페이지를 제공하는 방식으로 배포하게 되었다. 이러한 구성은 백엔드가 1차적으로 도와주는 방식을 사용했는데 후에 변경사항이 발생할 경우 프론트엔드에서 자체적으로 대응하는 것이 어려운 문제가 있다.
하지만 일단 어떤 방식으로 배포가 진행되는지 흐름을 파악하는데 만족하고 넘어가고자 했다.
다음은 테스트 전략을 수립하는 것이다. 테스트로는 storybook, jest, RTL을 사용한 테스트를 진행하고자 하였다. 첫 테스트로는 모임 생성을 위한 input 값에 대한 validate 테스트를 진행하였다. 또한 storybook을 이용한 UI 테스트를 통해 즉각적으로 컴포넌트를 확인할 수 있다는 장점이 있었다. 2차 스프린트에서는 이 정도의 테스트만 진행했다. 자세한 내용은 팀 wiki를 참고하자!
CI는 github action을 이용해서 PR을 올렸을 떄 aslant, styleLint가 제대로 적용되었는지, 테스트가 통과되었는지 확인할 수 있게 구성하였다.
2차 스프린트 회고
데모데이를 진행했다. 데모데이에 여러 피드백이 나왔다.
일단 아직 도메인 네임이 정해지지 못한 부분이 있었다. 현재 slack과 같은 워크스페이스 개념을 도입하고자 하였다. 해당 도메인을 정하지 않았기에 계속 '워크스페이스 개념'이라 칭하고 넘어갔다. 해당 도메인을 정하지 않으면 후에 정더라도 기존에 사용했던 용어를 그대로 사용할 위험이 있다고 말씀하셨다. 회의를 통해 해당 도메인을 팀명에도 있는 '다락방'으로 정하였다.
또한 오류 상황에 대한 문서화가 부족하다는 지적을 받았다. 서버에서 어떤 에러를 보내주고 이것을 사용자에게 어떻게 보여줄지 합의가 필요하다는 지적을 받았다. 현재는 서버에서 에러메세지를 넘겨주면 이를 경고창으로 표시해주는 방향으로 진행되고 있다. 후에는 에러 코드를 설정하여 에러 코드에 따른 문자열을 보여주는 방식을 이용하기로 했다.
또한 작업자 수에 비해 역량을 보여주지 못했다는 의견도 받았다. 프론트는 3명이고 백엔드는 5명인 상태로 백엔드의 작업속도를 프론트에서 따라오지 못하고 있는 상태이다. 이러한 상황에서 MVP 기능이외에 제대로 된 기능에 대한 논의가 부족하여 발생한 문제같았다.
회의를 통해 이런 문제를 논의하였다. 문제는 우리 서비스의 청사진을 그리지 못해서 발생한 문제였다. 또한 명확한 청사진이 없으니 서로 서비스의 근본에 대한 싱크가 모호하게 맞지 않음을 알게 되었다.
그래서 우리 서비스를 어떻게 그리고 있는지 질문하고, 각자 사용자의 입장에서 서비스의 사용성에 대한 이야기를 나누었다.
결과적으로 서비스의 정체성과 주요 타켓/실사용자에 대해 의견이 합치되었다. 우리 서비스 어필 대상은 모임의 장으로 보통 다락방을 만들 수 있는 사람이였다. 인터뷰를 통해 얻은 기능 목록을 리스트업하게 되었다. 우리는 모임을 참여할 때 참여자 목록이 크게 중요하다고 생각하지 않았다. 하지만 모임을 선택할 때, 누구와 참여하는지 중요하다는 것을 알게 되었다. 또한 시간과 장소도 모임을 생성할 때 필수 항목이었다. 장소나 시간이 미정이었다고 모임이 완료되었을 때 같이 정할 수 있는 장치가 있었으면 좋겠다는 의견이 있었다.
이 이외에도 서비스를 발전시킬 수 있는 다양한 의견이 있었다. 왜 서비스를 만들기 전에 여러 사람에게 해당 서비스에 필요한 기능을 인터뷰하는 것이 중요한지 알 수 있었다. 서비스를 만드는 사람들은 결국 한쪽 시선에서만 서비스를 바라보게 될 수 밖에 없다. 서비스의 방향을 정할 때 팀 자체적인 의견들로 정하기에는 정확한 근거가 부족해 갈피를 잡지 못할 수 도 있다.
우리 팀도 그랬던 것 같다. 그래서 인터뷰를 통해 우리 서비스의 방향을 확고히 할 수 있었고 전체 서비스의 청사진을 그릴 수 있게 되었다. 그래서 우리가 구현해야할 기능을 나열하고 이를 와이어 프레임으로 나타내는 작업을 진행했다.
3차 스프린트부터는 개발에 집중하는 스프린트가 될 것 같다. 2차 스프린트까지 MVP만 구현하면 된다는 생각에 전력을 다하지 않았다. 팀 전체적으로 어떤 것에 집중해야할 지 다시 점검하는 시간을 가졌다. 3차 스프린트부터는 코드 리뷰나 리펙토링을 보다는 기능 개발에 집중하기로 정했다.
