메가테라 웹 개발자 과정 22주차 주간 회고

 

5주차 스프린트 주간 작업 목표

주간 작업 목표
: 게시판에 운동 게시글의 내용을 수정하거나 삭제할 수 있는 기능을 추가한다.

상세 목표
- 사용자는 게시글 작성 시 필수 내용을 입력하지 않으면 안내 메세지를 전달받는다.
- 작성자는 게시글을 수정하거나 삭제할 수 있다.
- 운동 게시글을 삭제하면 운동에 신청하거나 참가하던 사용자는 삭제 사실을 알 수 있다.
- 기능 구현
    - 로그인
    - 게시글 작성/수정/삭제

 

 

이번 주차 초반에는 게시글 작성/수정/삭제 기능을 목요일까지 빠르게 구현하고 금~일요일 동안 실시간 채팅을 도입해보는 목표를 세웠었다가 주차 중반에 수정했다.

 

게시글 작성 기능을 구현하는 복잡도가 예상보다 있었고, 화요일에 CSS 작업을 진행하고 나니 전달되는 정보가 직관적으로 보이게 되면서 예외처리를 구현해줘야 할 부분들이 눈에 띄게 되었다. 동작하는 핵심 기능의 완성도를 높이는 것이 중요할 것이라는 판단이 들어 예외처리 및 디테일을 높이는 작업들을 Task로 선정하고 진행했다.

 

 

5주차 스토리 포인트 사용량 및 성과 분석

사용자 스토리	작업명	예상	실제	비고
게시글 작성	게시글 작성 Form 페이지, 입력 상태 관리, API 요청	10	10	목
	게시글 작성 POST 요청 처리 및 예외처리	14	14	금-토
	시간 선택 방식 수정	3	9	토
	작성자 정보를 참가자에 추가	1	0
게시글 삭제	게시글 삭제 API 요청, DELETE 요청 처리	4	3	일
게시글 상세 정보 보기	잔여석이 존재하지 않는 경우 예외처리	2	5	일
	게시글 작성 시간 출력	4	0
로그인	Username, Password를 이용해 로그인	7	9	수
컴포넌트 CSS 배치	홈 화면, 게시물 목록 보기, 게시물 상세 정보 보기	3	6	화
	게시글 작성	2	0
인수 테스트 수정	로그인 인수 테스트 수정	2	0
기타	뒤로 가기 시 이동할 페이지 구분	1	0
	취소 관련 동작 시 동작 수행 여부를 확인하는 Modal 추가	3	0
	홈 페이지 삭제, 게시글 목록 조회 화면을 홈 페이지로 대체	4	0
합계		60	51

 

이번 주의 하루 평균 Story Point 사용량은 6일 기준 8포인트 가량으로, 스프린트 3주차 개선 이후 시점이나 스프린트 4주차에 비해 약 2포인트 떨어지는 결과가 나타났다. 이번 주의 작업은 로그인이나 게시글 작성과 같이 기본적으로 많은 예외처리가 필요한 작업과 기존 동작의 예외처리를 해주는 것이 주 목표를 이루기는 했지만 이를 감안해도 생산성이 그렇게까지 잘 나오지 못했던 느낌이 있다.

 

 

이번 주의 좋았던 점

앱이 순환한다

앱의 가장 핵심적인 기능이 동작하는 구조를 완성했다. 정적인 정보만을 전달하는 것이 아닌 이제는 사용자가 정보를 직접 작성해 전달할 수 있게 되었다. 그리고 다소 소홀히 하고 있던 컴포넌트의 CSS 작업을 수행해 정보 전달력을 개선하는 시도를 했고, 그로부터 기존에는 파악하기 어려웠던 예외처리나 디테일을 잡아줘야 할 점이 눈에 들어오게 되었다.

 

노아님께서 말씀하셨던 '가짜가 아닌 사용자가 진짜로 사용할 수 있는' 앱이 되기 위해 챙겨야 할 작업들을 작업 목록에 추가해 진행함으로써 작동하는 기능의 완성도를 높여야 한다는 필요성을 작업에 반영하게 되었다.

 

공유로부터 발견된 문제점을 개선의 기회로 삼다

작업이 끝날 때마다 각 작업을 진행한 커밋 내역의 링크를 일지에 추가로 올렸다. 공개된 소스코드를 통해 아샬님께서 REST API 설계, 테스트 코드, 단순히 데이터를 저장하는 Entity가 아닌 행위의 주체로 객체의 동작을 어떻게 설계해야 하는지 등 많은 부분을 지적해주셨다. 이를 바탕으로 소스코드를 개선할 기회를 가질 수 있게 되었다.

 

 

이번 주의 아쉬웠던 점

계획을 이전 주차처럼 치밀하게 하지 않다

이번 주는 주차가 시작되는 시점에 새로운 사용자 스토리와 인수 테스트를 구체적으로 확정하고 시작하지 않았다. 지난 주차의 작업을 마치는 시점에 게시글 작성 Task가 남아있었어서 작업을 마치면 사용자 스토리를 다시 추가하는 방향으로 작업을 다소 미룬 느낌이 있었다.

 

예외처리할 사항이 계속해서 생겨나고 작업에 추가되었지만, 기존의 내용을 보완하는 작업뿐만 아니라 전체 완성 대비 구현도를 이끌어나갈 작업 방향을 어떻게든 시간을 내서 사용자 스토리와 인수 테스트, 작업으로 추가했더라면 하는 아쉬움이 있다.

 

정말 필요한 동작을 검증하는 데 소홀하다

DatePicker 라이브러리와 관련된 컴포넌트와 Store, API 요청 동작을 구현하던 중 백엔드에서 의도한 대로 데이터를 받아오지 못하는 이슈가 있었다. 모든 영역의 단위 테스트가 정상적으로 통과하고 있었기 때문에, 문제를 찾기 위해서는 동작의 모든 지점에서 데이터가 어떻게 다뤄지는지 찾아야 했다.

 

겨우 문제를 찾고 난 뒤 알았던 점은 해당 영역은 테스트 코드에서 검증하고는 있었지만, 구체적으로 어떤 데이터를 다루는지를 검증하지 않고 전달될 것으로 예상되는 값이 주어지면 그 값을 잘 반영하는지 수준의 테스트 코드로 검증하고 있었다는 점이다

 

앱의 크기가 커지면서 소스코드의 양이 많아지고 있고, 그러면서 한 번 동작을 수정하는 데 같이 수정해야 할 테스트 코드의 범위도 점차 넓어지고 있다. 디버깅의 범위가 넓어진다는 것은 그만큼 디버깅에 소요해야 하는 시간이 이전보다 많아짐을 의미한다. 작업량이 많아지는 상황에서 디버깅에 들이는 시간이 늘어난다는 것은 치명적이다. 테스트 코드를 짤 때 처음부터 가장 위험도가 높은 영역이 어떤 영역인지 예상하면서 테스트를 작성할 수 있어야 할 것이다.

 

작업에 욕심을 부리다

6주차에 세운 Task 중 마치지 못한 작업들의 작업량과, 수행한 작업들 중 예상을 초과한 작업들의 초과 작업 시간의 작업량을 비교해보았다.

미완 작업 Story Point	수행한 작업 초과 Story Point
17	13

 

작업 시간을 현실적으로 수행할 수 있는 작업량을 고려한 buffer를 주지 않고 예상 Story Point를 선정하고 있었다. 이로 인해 예상치 못한 상황이 발생할 때 작업이 밀리게 되고, 부족해진 작업 Task 시간 내에서 남은 작업들을 조율하기 위해 압박을 받는 상황이 반복되었다.

 

...

 

마음 한 켠에 여전히 '이 시점에는 이만큼의 진도는 빼야 하는데 이번에도 못 뺐어. 다음에는 꼭 해야 돼' 싶은 마음이 남아서 계속해서 작업 계획을 무리하게 가져가는 것일까. 디자이너님께 제출한 디자인 기획안에도 그런 감정이 남아있는 것 같았다. '보여줄 결과는 없지만, 나는 이렇게 하고 싶었다' 처럼.

 

가장 고통이 큰 부분은 모두들 진도를 빼면서 필요한 가치들을 공유하고 기능을 구현하고 있을 때, 발맞춰 가지 못하고 있다는 데서 나오는 조급함인 것 같다.

 

나는 어떤 최선의 선택을 할 수 있을까? 이제는 '마감'이라는 지점이 시야에 들어오는 시점이다.

 

조급함을 떨쳐내고 2주 동안 내가 해낼 수 있는 '핵심 기능이 잘 동작하도록 하는' 작업을 선정하고 스프린트를 진행할 수 있을까? 결정에 참고할 수 있는 영역은, 스프린트 7주가 프로젝트의 끝이 아니고, 메가테라 웹 개발자 과정 24주가 개발의 끝이 아니라는 점이다. 보완은 계속되어야 한다.

 

남은 2주 동안 할 수 있는 모든 것을 다 하되, 조급해지지는 않았으면 한다.